My name is Ibram Marzouk, and I usually go by @ibram or @0xibram. I’m 15 years old and currently living in Virginia. I started as a web developer about 4 years, but then got interested in bug bounties because I thought the idea of getting paid for hacking applications was awesome. I have been doing bug bounties for about 18 months now and I usually hack on Bugcrowd and HackerOne.
I only do bug bounties for fun and to improve my skills (and some extra cash as well ;)). It’s really just a hobby for me, however when I first started I used to spend all my time doing bug bounties and that impacted my personal life and I didn’t have time for anything else so I had to switch to part time. I don’t have a job so my day is basically going to school and then I would start hacking or work on other projects at night.
I usually spend about 20 to 30 hours a week hunting for bugs. This changes a lot though and it really depends on the amount of free time I have, my schedule, etc. I usually report 10 to 20 bugs every month but that usually increases when, for example, I receive more invitations to private programs.
My first high severity bug was discovered about 6 months into bug bounty. It was an IDOR vulnerability that I discovered in an internal API endpoint. This IDOR vulnerability allowed me to access support tickets by other users which usually contained PII.
It all started after I noticed they were using
api.example.com/v1 in all API calls so I decided to run wfuzz on
api.example.com/* and see if they have anything else on that subdomain. The tool found
/v1 which was expected, however, it also found
/internal. As you’ve probably guessed, this was an internal API. Running wfuzz on
api.example.com/internal/* returned some interesting results. One of the results was
/internal/docs which was a Swagger UI instance and it contained everything about this internal API. From there, I was able to test all the endpoints and the only interesting endpoint was
/get_tickets which returned all the support tickets of a user.
I was awarded a $3k bounty for this issue.
This is one of my favorite bugs just because I learned a lot about AWS while trying to exploit it and it was really fun.
So it all started when I noticed that the application I was testing had the option to use webhooks to get notifications. Such functionality is usually vulnerable to SSRF (btw, check out Jobert’s awesome post on SSRF). I already knew that the app was running on Amazon EC2 so the first that came to my mind was, of course, EC2 Instance Metadata. Cloud providers such as AWS, Google Cloud Platform, and DigitalOcean allows users (or applications) to retrieve information about the machine using a local address, which is 169.254.169.254 in the case of AWS.
So, after reading the EC2 metadata docs for a couple minutes, I tried to fetch the
/latest/meta-data/hostname endpoint which returns the hostname of the machine… but it didn’t work unfortunately. My guess was that the application was comparing my input to some kind of list with dangerous IPs. About 20 minutes of trying to bypass that blacklist, I got the idea of setting up a domain that points at 169.254.169.254 and then using that domain as my webhook url hoping that application won’t check what the domain is pointing to. And it actually worked (yay!). So right now I had access to the EC2 instance metadata and I was ready to write my report.
I sent the report to the company’s team and they triaged it in less than an hour. However, I didn’t want to stop there and wanted to see how far I can go with this bug. I asked the team for permission to try to explore and see what can be done with this and they agreed.
After reading the docs even more and doing some research, I had access to the credentials of this AWS account using the
/latest/meta-data/iam/security-credentials/* endpoint. While still trying to go further, I stumbled upon this talk by Andres Riancho which talked about a very similar case to mine. Using his tool, nimbostratus, I was able to access the database of the application using the snapshot-rds module which uses the RDS API to create a snapshot of the DB, restores it, changes its password, and then changes its policy so that anyone can connect to it.
This bug was fixed in a couple of hours and the team was pretty happy about it!
I knew bug bounty, and hacking in general, is something that I want to do for living after I got my first bounty and knowing that I’m actually helping companies out there secure themselves while getting paid. One of the problems that I had when I was starting was that I never tried to dig deeper or think differently and always looked for common vulnerabilities which were usually duplicates. This is a very common problem for people who’re starting in bug bounty… so don’t look for common vulnerabilities!
I always start by doing recon. I start by using sublist3r, altdns, subbrute, censys.io to discover subdomain and hosts related to the target. Then, I’d start port scanning using masscan or nmap on the list of subdomain that I found in the previous step. While doing port scanning, I’d use gobuster or wfuzz for content discovery some of the lists from SecLists. I also look at robots.txt and previous versions of it on archive.org (thanks @zseano) because it will most likely contain interesting endpoints. While waiting for the previous stuff to finish, I’d start exploring the application and get to know it more. I use builtwith.com to try to find information about the technology stack that is being used because it might be helpful in exploiting some vulnerabilities later. Also, I try to find any developers blog or docs to help me understand the application even more.
I should have some decent information about the target by now and should be ready to find some vulnerabilities.
I usually look for most vulnerabilities types when testing a web application but sometimes this changes. So for example, if it’s an old program then I will test for high severity bugs only because the chance of finding them will be higher than low severity bugs. Also, it depends on the functionality that I am testing so if I’m dealing with a request that I think interacts with the server then I would test for the appropriate vulnerabilities only. I recently started reporting P1 and P2 bugs only just because I want to increase my average severity on Bugcrowd and signal and impact on HackerOne.
Most of the tools that I use are listed in the previous answers and all of them are for recon as I like manual testing. Here is a small list of the tools that I use: nmap, masscan, gobuster, sublist3r, altdns, censys.io, google, wpscan, sqlmap.
As I said before, the types of vulnerabilities that I test for depend on the specific functionality or request that I’m currently testing.
For example, if it’s a request that allows downloading files then I would test for LFI and if it’s an API that retrieves user information with a given user id then I would check for SQLi and so on…
When testing for vulnerabilities like RCE, SQLi, LFI and most server-side vulnerabilities I try to look for weird behaviours. Does sending
’ gives you an error or different content and sending
\’ gives no error and displays normal page? if yes, then you probably have SQLi (backslash powered scanning ftw).
It’s just a matter of observing and guessing what happens on the back end and then testing for vulnerabilities that might work in this specific case.
Very often. It’s very likely that you will find bugs in old programs because they push new code all the time which means new vulnerabilities are possible. I usually start testing new features (posted on their twitter account, blog, etc…) on old programs first just because less hackers have probably tested it.
I personally think that it helps a lot. For example, having experience with the programming language or technologies that are being used by the target will definitely help in exploiting some vulnerabilities.
I actually prefer to hack in very quiet environments but when I decide to listen to music, I just listen to piano or Spotify’s Top 50.
Playing video games (Overwatch mostly), hanging out with friends, shopping, and playing sports.
Bug bounties have helped me financially and also in improving my hacking skills.
Binary exploitation and reverse engineering. I’ve actually started working on this recently.
I don’t really have any very bad experiences so I don’t have an answer.
It’s really hard to pick only one hacker, but I’d choose Orange Tsai, he is just amazing!
The ability to split bounties with other hackers.
Vim and Sublime Text.