Bug Bounties: Security Isn’t the Only Attack Vector November 1, 2016

With the ever-growing popularity of bug bounty programs, I thought I would take a moment to share another consideration outside of security when bug-hunting, and that is matters affecting a company’s bottom line (e.g., access to files you’d otherwise have to pay for).

I’ll begin with the results of my last successful bug bounty report: $500 in my bank account and a loophole closed that allowed anyone to download any game from a certain popular digital game merchant without paying or authentication of any sort.

The Method of Discovery

This is going to be one of those moments where you think to yourself, “MAN, that was so EASY; why couldn’t I have been the one to find that!?”

All I did initially was fire up Fiddler and watch traffic related to the download of a game I’d just purchased. With the direct link to the game archive in hand, I looked for what I thought could be patterns used within the URL’s structure between games. Sure enough, I found that by changing the name of the game and sometimes the extension of the archive being downloaded, I had carte blanche: any game, any time.

The Bug in Detail

As an outsider with absolutely no insight into how their game delivery method took place, my only barrier to entry was making a purchase.

With that piece of the puzzle, I was able to discover what I did about the URL’s relation to every game on the server, of which I could then give any game’s direct URL to anyone and they would be able to download it without even so much as authentication required.

To note, the download URL began with http. That alone spoke volumes to me about the lack of security/authentication implementations, possibly with other servers across the company, but that’s a topic for another post.

There were no unique identifiers within the URL structure beyond the name of a game and its respective archive file type (.iso, .zip, etc.), so the attack surface was incredibly high.

Download URL Example:

http://populargamevendor2016.com/s0m3numb3rsh3r3/server1/brutal-fps-v1.3.3.7.iso

Interestingly, I needed to keep the version number exactly the same across downloads, even if I knew the games weren’t that version. If I changed it to, say, v1.0.0.0, that wouldn’t work. So for another game, the URL ended up looking like this:

http://populargamevendor2016.com/s0m3numb3rsh3r3/server1/breathtaking-rpg-v1.3.3.7.7z

Note the change in game title and file type (bolded for emphasis), the latter of which being the only thing I had to play guesswork with when I ran into the snag of changing game names not always working.

No Bug Bounty Program? No Problem.

As some of you know, many of the more high-profile bug bounty programs out there (Facebook, Google, Microsoft, etc.) have EXTREMELY stringent requirements that, if not meticulously followed, could result in non-payment for a legitimate bug discovery or even legal woes for crossing lines with, say, user data.

The company in my scenario had no bug bounty program in place when I contacted them, so I had to tread delicately initially. Although I was poking around in completely passive ways, not every company appreciates that, even if it’s the good guys doing the poking around.

After inquiring if they had a bug bounty program and briefly explaining what it was, the individual I dealt with said they didn’t have one in place but would happily reward me based on the scope of my findings. I told them the impact and result of the oversight, of which their interest was piqued, and then I provided a professional report that detailed every single step and nuance of my process. I even took the time to build hyperlinks for a large number of games so they could instantly verify an actionable sampling.

To help my chances of being immediately seen as a person and not some cloaked, villainous hacker emerging from the shadows, I included a phone number, Skype handle, and LinkedIn profile link in my email signature. I wanted them to be able to see who I was and to reach out to me via other means if they so chose.

This company could have very well snubbed me once I handed them the goods, but they were outstanding and instantly (within a day of me submitting the report) offered me a $500 reward. But even better than the cash reward was the opportunity to network with this company, open their eyes to the prospect of bug bounties, and ultimately build trust with them.

Conclusion

In the age of increasing bug discovery complexity and reliance upon automated testing, there are peripheral manual aspects that hark back to an older day of Google hacking and URL traversal. As someone steeped in those methods, it’s something I tend to focus on when the opportunity arises. It seems obscure enough these days that most of my would-be competition simply overlooks it, whether it’s a matter of technical nature, knowledge, or the prospect of a big payday.

In terms of technical difficulty, this is low-hanging fruit, but at $500-a-pluck, that’s fruit I’ll gladly pick all day long!