As a bug bounty hunter, and even as a human being who wants to save time, you always want a way to simplify certain tasks and then to automate those simple and usually tedious activities. It’s mostly out of a desire to spend the saved time on probably something else that is technically a waste of time (i.e. video games, binge-watching whatever movies and shows etc.), but that’s all part of being human eh?

What happens when you automate anything? Initially, it ends up as a disaster unless if you somehow managed to account for every possible scenario. And as a bug bounty hunter the automation tends to be a complex bash script or equivalent that is actually a row after row of simple tasks, but stringing them all together is usually the source of the problem. And, that problem announces itself once you run the script, and if it’s on a large list of targets… well, I hope you have a VPS with a large hard drive.

But, sooner or later, the mistakes are corrected and the script does its thing. All you need to do is sit back and watch some Netflix show or if you’re not ordering stuff via Amazon, but you have the prime membership, you can spend that time digging to see what is free to watch. Eventually, you check the results. And if the script was testing for some RCE or SSRF, you really want your burp collaborator or wherever you’re monitoring the pingbacks to show you aws owned IP or any IP that isn’t google cache or similar.

And then it happens. A pingback from IP that you know from experience has to be from aws. You do the usual host x.x.x.x and there it is, you have verified that the IP address is coming from aws. You may be getting excited by this point, hands shaking, because the next step is the verification and then finally PoC.

In this real-world example, the pingback was achieved through XXE inside the uploaded file. The verification was done by taking the file with XXE payload and editing it with my VPS IP address and an xxe.xml file that was nonexistent at the time in order to verify the GET /xxe.xml in the logs. And it’s 404 in the logs, but it did the thing. Now, it was time to write a PoC. But, as I was starting to dig around for XXE payload that does something more than a pingback I had some time to think, to process what was happening, but also what could happen. And then, a justifiable fear: what if someone else gets this as well and they submit the bug? Naturally, I submitted the initial finding to buy some time and to ensure it won’t be wasted on PoC, because I could have been too late already.

Sometime later. I get the email, the excitement is spiking because it makes it or breaks it, and they ask me to provide a PoC, a proper PoC where it actually demonstrates the ability to read the data from their aws. And I’m ready. I have my VPS, I have an XML file that I used earlier to test the pingback, it’s open in nano and I’m entering the XXE payload that will prove the impact. And it’s done. I have the file with XXE payload part 1 ready, I double-check that I have entered my VPS IP address correctly and that the xxe.xml is xxe.xml and not xxe.dtd or vice versa (some of you will know what I’m talking about). And It’s all good. I then upload the file and I’m checking my apache log for GET request to a string found in a specific aws file. Nothing. 15 minutes and still nothing. I check the earlier test when I didn’t have xxe.xml ready, and I do the math, and it checks out: it took maybe 5 minutes then. What is happening? It’s a P1 bug, it’s the first one of XXE type for me, and I’m messing it up.

#bug-bounty-tips #technology #information-security #bug-bounty #writeup