MonkeHacks #21

It was, again, a busy week. I had some super insightful conversations with Mikey96 about some topics like hackbots. I walked around the Royal Botanic Gardens, which were super cool - I found a ruin next to a swamp! I also found the time to return to bouldering after a month or so of absence and loved it - but now my hands are a bit cut from it. I’m back to my old routine now. I was nerd-sniped with an interesting behaviour by one of the folks in the Critical Thinking server (an1msh), and that led to one of the craziest client-side chains of my hacking career so far. I had two 12-hour hacking days back-to-back. It was so complex that I spent a whole day writing the report. I’m sure Mikey found it entertaining, though, as the ADHD kicked in at 100% hyperfixation. I’ll definitely write about this bug eventually.

On a slight tangent, I attended the online training for the Irish European Cybersecurity Challenge team (ECSC), which was great. I also bought a rice cooker, which is my preferred cooking appliance.

100-Hour Challenge Updates

Here are this week’s statistics:

While I meant to do 10 more hours… those two 12-hour days absolutely knocked the energy out of me. That was a mistake! I need to regulate my energy a bit better.

Weekly Ideas / Notes 

• I’m continuing to improve at client-side hacking at a rapid pace. Client-side hacking is mostly gadget-based; if you can learn how each piece works, then this type of hacking is reduced to problem-solving using these components. Some of these components can be specific to the program that you’re hacking on (such as GitLab). This is why deep-diving is so important! It unlocks more gadgets for these types of issues.

• To learn to hack, you must first learn to “learn to hack”. To find complex vulnerabilities, you must first learn to find the pieces and identify their value in the context of the web application. How can you build chains if you don’t know what you’re building with?

• Secondly, my hacking is primarily oriented around probabilities. There is probably an XSS here, which probably means that there’s more here. This way, I can allocate my time more effectively. Why test for secondary context if there’s no proxy? Test with intention! I think my methodology has evolved to become a kind of “probability-based gadget hacking”. I can do a blog post on this topic if there's interest.

• This doesn’t mean that you shouldn’t test for unlikely bugs. The worst thing that could happen is that you learn something new. Unlikely doesn’t mean impossible. If you’re unable to compete just yet on technical ability, then you can get an advantage over other hackers by testing for things that people with more experience would usually overlook. Look how many simple IDORs have existed on Meta and HackerOne! Or Snapchat! They’re out there. And the top folks almost certainly do not test for them that often.

Resources

What a week for awesome client-side articles!

• LavaDome bypass by detecting character height: LavaDome allows you to effectively isolate certain DOM elements (subtrees) within a page. The legendary Masato Kinugawa figured out a brilliant way to bypass this and subsequently leak text from the isolated context.

• Universal Code Execution by Chaining Messages in Browser Extensions: Flawed design patterns in browser extensions led to multiple vulnerabilities, ranging from SOP bypasses to universal XSS to RCE.

• Exploiting Client-Side Path Traversal to Perform Cross-Site Request Forgery - Introducing CSPT2CSRF: Some cool research that spotted how client-side path traversal issues can be somewhat reused by other contexts to lead to unexpected side effects.