MonkeHacks #43

Year in Review, Technique Drop, Taking Care

Author

Monke
December 13, 2024

MonkeHacks #43

While the week started off very well, things unfortunately took a turn for the worse - most of my bugs were either marked informative, or were lowered. I did get one unexpected payout, though, so my motivation was renewed a bit. It’s one of those times where you just need to plod onwards and fight through the slow period.

Not entirely unrelated to the above, I had my first appointment with a therapist. I am of the opinion that every man (and woman, although I think my audience is mostly men) should see a therapist at least once. My introductory session went well and I’m glad I made that choice. Take care of yourself!

Towards the end of this issue, I’ve dropped a fun gadget for bypassing redirect checks. I don’t know if it’s a new technique but I thought it was really cool when I found it, so I hope you find it as cool as I do!

I found this brave squirrel in the Botanical Gardens in Edinburgh. My friend named him Terry.

Weekly Ideas / Notes 

  • The year isn’t over yet but I’ll probably finish it with ~40 vulnerabilities on HackerOne, of which 4 were Critical and 9 were High. I had sporadically reported more vulns across other platforms too so the total is probably around 50 bugs. This is less bugs than last year, but I made around twice as much, so the average bounty has been much, much higher. I tend to stop hacking once I’ve made enough to get by, rather than pushing myself to my limits (with the exception of live hacking events, of course). In 2025, I aim to change this and hack more consistently.

  • In retrospect of 7-8 months of full time bug bounty: I definitely struggle with consistency quite a bit. September and December were my most productive months. My output is quite good if I look at the number of hours I work, but getting that consistency has been difficult for me. It remains to be seen if I’ll continue full-time bug bounty through 2025.

    • My growth since the start of 2024 has been absolutely insane:

      • I quit my job and started doing bug bounty full-time in April, which has been liberating.

      • I got very deep into client-side hacking from May-ish, which was a great choice and paid off big time. I have learned so, so much and I finally have the confidence and self-belief to hack anything.

      • I competed in H1-0131 and found some really cool stuff, and I went to Italy for the European Cybersecurity Challenge for the fourth consecutive year.

      • I moved from The Hague to Edinburgh, which was also one of the best decisions I’ve ever made.

      • I started writing this newsletter, which has also been really fulfilling.

      • I gave a talk to Edinburgh Napier University on bug bounty.

      • I started bouldering consistently, and going to the gym, which has been really good for my health.

      • I visited 10+ countries, including some interesting places like Seoul in South Korea and Strasbourg in France! And the North Korean border, which was surreal.

  • Bebiks wrote a Param Miner equivalent for Caido. It’s still in beta, but this is a big step forward for the Caido ecosystem.

  • As a kind of early Christmas gift to you all, and as thanks for reading my newsletter, here’s a fun gadget/differential that I found in October that I see a lot of potential in. I found this gadget on a very large target, but unfortunately it was blocked by the webserver configuration - on any other target, I’m confident that it would’ve worked.

    • Consider the following scenario: let’s suppose that you can abuse the OAuth flow on victim.com to redirect the victim to any URL under victim.com/*, and you can also exfiltrate the OAuth code. However, the code can only be redeemed on the page that is specified by the redirect URI. What’s the problem here? Well, if you can redeem the code on the page it lands on, it gets consumed immediately, which is useless. If you can abuse the URL in such a way that the code isn’t consumed, well, then as an attacker, you also cannot redeem the code, because it’s tied to the redirect URI. So this situation is seemingly impossible. If you can exfil it, it’s unusable, and if you don’t exfil it, it’s consumed. But what if I told you that I found a way to exploit this by making one URL point to two different locations?

    • The concept behind this technique is a simple browser-server differential. The browser will normalise all %2E characters to . in the URL, but this is not the case if you do not use a web browser to access this URL. What does this mean? Well, if you craft your redirect URL with these characters, you can cause a situation where:

      • The victim’s browser will normalise victim.com/%2E%2E/codenotused to victim.com/codenotused and the code will not be redeemed.

      • The attacker, who has the same URL, can visit the same URL via their proxy, and the normalisation will not happen. The specific behaviour here will depend on the configuration of the webserver - some servers will normalise these characters too, but often they also normalise %2F or %5C, so you cause the server to treat your request differently. In my case, the JS to redeem the code was present on 404 pages too, so this technique would have executed perfectly if the webserver configuration had not blocked it.

      • The final scenario is that the redirect URI is set to victim.com/%2E%2E/codenotused and for the victim, the code isn’t consumed due to normalisation, but sending the same URL via your proxy would redeem the code due to the 404 response and successfully passing the server-side check!

  • This won’t be the last technique I drop in this newsletter, so if you’re not already subscribed, click that subscribe button. It’s free, I do this newsletter as a passion project, so you’ve got nothing to lose by subbing.

  • 2025 is going to be awesome. I’ve got several projects in the works that I’m looking forward to launching. But more on that next year!

Resources