Sensitive data exposure by requesting a resource with a different content type
I am Yogendra Jaiswal also known as Vulnholic (hackeone)
It had been some time since I received invitations to private programs on HackerOne, so I decided to see if I could find some bugs elsewhere. I used some Google dorks to find some sites, but these didn’t interest me as much. A Twitter search for #bugbounty gave me some results as well. There was one particular tweet that stood out saying that they were offering money for security vulnerabilities. I immediately jumped on it and started looking for vulnerabilities.
After some time I found a couple vulnerabilities and reached out to them over email. The next day I received a reply from them that they were running a private program on HackerOne and if I could report them through the platform. I was excited, because this would help get me new reputation on HackerOne!
When I reported the vulnerabilities through HackerOne I noticed that a lot of HackerOne top 100 hackers were participating in this particular program. I was slightly discouraged because I didn’t think I was able to find security vulnerabilities if they already participated. Then I realized that HackerOne always says “#TogetherWeHitHarder” and thought by myself that I should keep digging to proof I’m capable of doing so.
So, I went back to their site and started looking again. I was SO excited when I found an IDOR (Insecure Direct Object Reference) vulnerability! I submitted it to their program. The next day they closed it as informative. I guess the impact wasn’t immediately clear of the IDOR. I went back and did my best to explain the impact as best as I could. They must’ve understood, because they figured out what I meant and close my report .
This particular site had a way to view user-uploaded files. A unique token is generated for these files. Some of these files are only accessible by certain users. They access the files at https://example.com/folder/unique_token. When I tried to access a file belonging to someone else’s account, I’d see an error that I wasn’t allowed to access the file.
However, I figured out that there were so-called Atom feeds in the application
What is Atom ?
All Atom feeds must be well-formed XML documents, and are identified with the
application/atom+xml media type.
Atom is the name of an XML-based Web content and metadata syndication format, and an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. Some of these Atom feeds were accessible by appending .atom to files. So, I went back to the file and requested the same file, but this time with .atom appended to it: https://example.com/folder/unique_token.atom. Now, instead of showing a 403 Forbidden error, it would respond with private data about the file. It would return a thumbnail, which was especially interesting when requesting images.
More Info for atom https://validator.w3.org/feed/docs/atom.html
The next day, the vulnerability was triaged and I received a bounty for my finding!
6th September 2017 Reported
7th September 2017 Got Response from team
7th September 2017 Triaged
7th September 2017 Rewarded Bounty (cool bounty)
13th September Resolved