MonkeHacks #34

Apologies for the huge delay - it was a crazy week. I competed in the European Cybersecurity Challenge with Team Ireland, and we placed 16th of 30+ teams - this is our best result yet! I met Dreyand (Team Serbia) and DrBrix (Team Poland), which was super fun.

On Monday I’m flying to Basel for two days, and then taking the train up to Freiburg im Breisgau in Germany. I’m still aiming to be productive in that time. Now that ECSC is over, I need to focus on bug bounty again for a while and put some hours in. I’m looking forward to doing some travelling again, with my old routine of sleeping in hostels and working from my laptop in the daytime.

I’m typing this from Scotland - I’m making a brief stop home to drop off my unnecessary bags (i.e ECSC swag). I’ll try to post again by Wednesday to avoid missing a week in this newsletter.

Weekly Ideas / Notes 

• Google VRP triaged my systemic misconfiguration from the last issue. No bounty decision yet, but their triage process was very smooth and fast, and there was a lot of feedback at each step of triage. It was a breath of fresh air compared to the usual triage experience.

• I competed in ECSC 2024 in Turin, Italy with Team Ireland. I have two years of eligibility left, so I can compete next year in ECSC 2025 in Warsaw, Poland if I so choose. CTF at this level is a good reminder that no matter how good you become, there’s always a bigger fish. cough, cough, JustCatTheFish…

• ECSC challenges always remind me that there are some insane client side techniques out there that I haven’t mastered yet. As far as rabbit holes go, client side hacking is a deep one. Especially with XS-leaks and such, I think that there is a ton of potential.

• I passed 0xacb in the bathroom in Turin airport. I don’t think he recognised me.

Proxy XSS 

As an extra segment this week, I’ll describe a simple technique I used to make it easier to build POCs for postMessage vulnerabilities.

In a typical postMessage XSS scenario, the vulnerable component is an iframe that insecurely handles user input and passes it to an XSS sink. The problem is: how do you know which iframe on the page is the right one to target? Sometimes, there can be a lot of “noisy” iframes that don’t interest us, and due to SOP restrictions, we can’t see the URL of the vulnerable iframe from our attacker origin- and therefore the only easy way to exploit your bug is to send the postMessage to every iframe on the page. This isn’t very efficient nor elegant.

To combat this, you can iframe the vulnerable component yourself and exploit the XSS on your own iframe, if the framing restrictions allow. This serves as a kind of “proxy” for your exploit Javascript, where the same code runs but the origin is different.

With the proxy origin, you can now use SOP to view the window properties (including localStorage and sessionStorage) and “snoop” on them from your domain remotely, and target specific iframes with your exploit because you can view location.href of the vulnerable iframes on the victim’s page. This is far more elegant and flexible as a gadget than just guessing.

Resources

• Ruby-SAML / GitLab Authentication Bypass (CVE-2024-45409): A relatively simple but highly effective authentication bypass on Gitlab that abuses a nuance of how the server was extracting XML elements.

• CSP Bypass Search: A site developed by Renniepak that lists public CSP bypass domains.