My name is Patrik Fehrenbach I am from Germany and i live in the beautiful City of Freiburg located in southern germany near the black forest. I started hacking with about 14 years when my father first decided it was a good idea to limit internet access to two hours a month. So what i did then was trying to bypass the restriction again and again. My first success in public programs was in the early Paypal bug bounty and the Google VRP. The very first platform I started with was Bugcrowd and i have submitted my first won’t fix bug on 2013-03-27 (it really was a won’t fix, I am ashamed), shortly after i signed up for hackerone, last year for Zerocopter and after a long signup process proudly made my way to the Synack SRT.
I do bug bounties as a side project to my everyday 9 to 5 job (working as a mobile pentester focused on iOS) along with my master studies of computer science. During my bachelors degree it was easy to find some “quality time ;-)” for bug bounty hunting, but nowadays I only spend a couple of hours a week and try to be as efficient as I can.
I spend roughly about 10 hours per week hunting for bugs (both, in bug bounties but also to hunt for fun in commonly used software). In terms of found bugs it highly depends on the targets launching so it can vary from 40 reports a month to 0 reports. On average i had 15 reports per month over the last two years.
It took me about a year to step up from the low quality bugs and invest more time and effort to find the better stuff, once I crossed that line better bugs came in. The most important thing is to gain experience, to read a lot, and to understand the technique the companies are using. Once you have mastered these abilities, findings good bugs is just a matter of time.
Looking back, I think the most interesting bugs i found was together with Nahamsec discovering the XXE vulnerabilities in the OOXML parsing of OSX. Another interesting one was the remote code execution at Uber and the disclosure of a .htpasswd file in a huge company.
Basically I started bug hunting in my first year of university, I was a broke student and could barely afford food/rents. Since I hate lending money from other people I decided to change something, programming was not an option since it’s not my strongest suite. What i did was starting to create websites and sell them, providing webspace, and do little (web) programming tasks. Soon after gaining insight about web technologies i discovered i was better breaking things than to actually building them. So i started to invest my time in reading and understanding the OWASP Top 10, started to play around with all sorts of vulnerable vms and websites (DVWA,bWAPP). After spending a couple of weeks hunting bugs for Paypal I was able to pay my rent, pay for my student loans and afford it to buy a car. So you could literally say, it changed everything for me. The biggest problem for me in the beginning were duplicates, and I had a lot of them. Also I got somehow a little bit too addicted to bug bounties and my studies didn’t went that well at the time. My advice for you starting bug bounties, focus on your studies/school!
A really good way to keep yourself updated is subscribing to security newsletters (ThreatPost) or read recently published reports by hackerone (@PubliclyDisclosed) is tweeting about them. Another great resource is the Slack Group @BugBountyForum especially the channel #Blogposts which will keep you updated about all the latests Blogpost about new techniques and findings.
In the beginning I rarely collaborated with other hackers, in an industry with a lot of money involved you better choose the right persons to work with. Nowadays i do and it keeps me motivated: Nahamsec, Smiegles, Ziot, Mongo | -Frans rosen- (only to ensure he hasn’t found the bug earlier)
In the best case (at least for me) the bounty program is offering a huge scope with everything in scope they own.
I open up my notepad and I try to collect as many information as I can find, to do so I start with finding out if the company has its own IP space, you can find that out using publicly available databases like RIPE, ARIN, APNIC etc. those are the registers for the IP space.
Once I have found out which IP spaces belong to them i do an nmap scan to see which of them are responding on TCP or UDP ports (beware UDP might take ages, but it’s worth looking!). After I have a list with IP addresses i do a reverse IP lookup on the domain (basically to check if there is a vhost assigned to the website).
For subdomain discovery I love to use dnscan which is super powerful and fast or a very nice tool called sublist three R. The results of your subdomain bruteforce is really depending on the list you feed your tool, my suggestion would be choose the one that fits best for your needs, a good resource to start is the repository SecLists by Daniel Missler and Jason Haddix, or the great AXFR research by Bitquark. Once I have enumerated the subdomains, I run a tool that I wrote myself which is basically checking if a subdomain is responding on the commonly used for web applications both on the IP and the FQDN.
Once I know something that is alive, I threw the results in a headless Burp Suite running on a very powerful server and spider the website for POST and GET requests, after it is finished with indexing what is there I look at the results and look what is juicy. Depending on the requests sent, you may want to look for stuff that looks like it’s communicating with a database such as id?=, user?=, you name it, there is a fair chance of a SQL Injection there or for stuff that looks like it is reflecting in the context of the website for example is the username displayed somewhere? Try to XSS it, is some error text submitted in a GET request and displayed? Try to XSS it.
Another approach is to google dork for juicy stuff.
The easiest dork you can use for subdomain enumeration is : site: *.domain.com but what if you want to search for a sub subdomain? Easy: site:*.*.domain.com you see a website popping up multiple times and you want to have it excluded? site:*.domain.com -website. Another interesting technique is to use google dorks for finding outdated SWF files which may can be abused to trigger some XSS :-) (you ask yourself how? @smiegles has written a great blogpost about it! ) for using that just do: site:*.domain.com filetype:SWF or if you look for PHP related stuff site:*.domain.com filetype:php or for aspx? site:*.domain.com filetype:aspx. Another nifty trick (which may is stolen from some Detectify blog) is to look for old websites using Google, as bug bounty hunters we do not want to travel the path everyone else is going right? We want to find that old, abandoned subdomain some intern built in php3 way before you were born. For doing so: Again Google dork for site:*.domain.com, click on Tools, and the third column allows you to set a specific period of time, my advice is look when the company was founded, and start there you’d be amazed what you can find.
Another really awesome tool to do your OSINT/Recon is recon-ng, the tool allows you to collect information about your target and combine all the information in one platform. If you like to experiment with really innovative tools have a look at shubs (Infosec-au) Github repositories altdns and assetnote are really really helpful tools, if you are familiar with python you can easily extend them and adjust them to your needs.
Absolutely not, when I first see a web application i start to figure out how the website works. You first start with 1.) What is the website built for? (almost) every website has some kind of use, either way you upload photos, write something etc etc. 2.) You start to figure out what the website was built with (one cool tool is builtwith) but the more websites you have tested, the better you get an impression what the website is built with.
(Other than burp) Do you use any tools? Do you have your own tools that you have written to automate/facilitate your work? What Burp extensions do you use? Is there a tool that not a lot of people use that you think they should?
I use the following extensions for Burp Suite:
Public:
Private:
I am using the following tools besides of Burpsuite:
Outside of burp I love to use Needle for iOS testing, recon-ng for OSINT, sqlmap for SQL Injection pwnage, portia for crawling, wpscan for Wordpress issues, joomscan for Joomla issues, deen for file conversion, dvcs-ripper for exploiting publicly available .git, .cvs, .svn files.
Its really hard to find a general answer for this question, basically it helps to understand how the platform interacts with the underlying services. On places where it is likely that some record has to be touched in the database I actively test for SQL-Injections. When it comes to RCE vulnerabilities I mainly focus on requests wherein objects are transferred, understanding the data structure is one of the most important things you need to focus on. For IDOR vulnerabilities, I basically focus on everything which may relate to some kind of ongoing ID and try to manipulate it on every endpoint possible, one time I found a IDOR bug in an application where access controls were implemented perfectly on every endpoint, but one! So never give up and keep on searching. For XXE related findings I look for POST requests which either send the content type XML or JSON. Even if the POST request does only contain JSON data, try to change the content type to XML and observe the response of the server, also try to send the same data in JSON transformed to XML, if the server accepts it, there is a fair change that the developers did not disable external entities and you are good to go. Also, if a website is processing a specific filetype, it could be based on XML (you’d be amazed how many are!) For example: XLSX, DOCX, PPTX, SVG, MPEG7, GPX(…) those are all potentially usable to exploit a XXE Injection.
Whenever a Bug Bounty starts I wait for approximately 24 hours before I do any testings. You can be entirely sure that the Reflected Cross Site Scripting in the Search field has already been reported, I don’t like the stress around it. In my experience it didn’t make any difference if you were invited late for a bounty, there is always plenty of stuff overseen. For example, I got invited to a bounty running for almost two years and hundreds of reports, still I was able to find a path traversal in a central component of the website. So don’t be upset if you are late for the party, just try harder and you will succeed.
I personally don’t think you need to be a web developer or a pentester to be successful in bug bounties, it sure helps but it’s definitely not the only property you need. Personally, I think what matters most is the inner fire you have. You have to motivate yourself to look for bugs for multiple hours with the possible output of nothing, but that’s the game.
I love listening to some metalcore such as (+Killswitch Engage, 36Crazyfists, I also love Swedish Melodic Death Metal with Bands like Dark Tranquillity, In Flames, Amon Amarth, Norther, Ensiferum. For Bug hunting I mainly listen to Post-Rock (This Will Destroy you, God is an Astronaut, Mono, Caspian…) If you want to tune in: w0rk Playlist
I love flying drones, especially my DJI Mavic Pro which is so much fun. I love to edit the footage which can be found here and upload the pictures here and if my account is not compromised here is my flicker profile. Apart from that i really enjoy travelling to different countries, reading books, spending time with friends. A good work - life balance is essential to be successful :-).
Bug Bounties really changed my entire life, back in 2011 when I started my first studies my plans were to be a teacher for english and history. After I failed the history exam I got exmatriculated from the university and I needed to find a plan B. Since I was interested I started to study informatics, got into bug bounties, got a job in information security and was able to finance my studies and living with bounties.
I think the most important advice is to be patient, security sometimes can be a slow process. Although you may think that the company should instantly fix your bugs, the process of doing so is sometimes more complicated than finding it. Especially in platform with thousands or even millions of users it is very important not to break the whole platform with one failed fix. Bug fixes have to pass multiple steps before they go live, allow them some time. Lets imagine a program just started and you submitted your very awesome chain of bugs which leads to a full compromise of every account on the website, and you haven’t heard back in a couple of hours: Always remember there is someone on the other side that looks into your, and maybe hundreds or even thousand of other bugs. This person may only have a couple of hours each day to go through all the submissions they receive and is possibly overwhelmed with such a big amount of submissions. Again be patient in that process and don’t pressure them with the tenth “Update???” question. The next and most important rule: DONT be rude, we all know the TAXI DRIVER legendary report a perfect example of how not to argue in a professional way. There may be misunderstandings here and there but in the end, you and the other side of the report want the same thing - the vulnerability to be fixed. If you write a report, try to be a specific as you can, if you cannot proof a certain issue, go ahead and spend some more time on it to make it beautiful. Be technical - show the security team what would be possible if someone exploits the vulnerability you found, include as much information as you can offer. Be fair and respect the scope of a program. Also read closely the program rules and don’t violate them with your actions.
As a final word, don’t go where the money is, don’t hunt just for money, hunt for knowledge, hunt for fun and make the world a safer place :-)
I am very interested in reverse engineering, understanding the flow of the code writing badass exploits :-).
If someone with basic technical background asked you, “where should I start?”, what are 3 things you would recommend they do before diving into bug bounties?
Read Read Read Read Read - All what’s available start with Web Hacking 101 by Peter Yaworski, show some love and buy it :-), also a must read is the Web Application Hackers Handbook Build your own arsenal of Tools, get yourself the free version of Burp Suite, and if you like it don’t be a scumbag and pirate it, but invest the money for the professional version, it will pay back in less than a week. Understand the principles of Bug Bounties, get familiar with the terminologies, what companies want to see (in terms of vulnerabilities) and what they don’t want to see (e.g. best practice stuff, Clickjacking, you name it)
Avocado (I am somehow addicted) with tomatoes.
I honestly never had a bad experience with any bug bounty platform so far. I have several reports open for almost a year but that’s just a lesson you have to learn once, to never look again for the security of that company.
I have seen some of mongo’s bugs, but he never told me how he found them, so yes it’s mongo :-)
I would really looking forward for a collaboration feature, wherein it is possible to work together on a target, share the points and the bounty.