My name is Ed. I am a web designer, developer, and security researcher. I am currently studying computer science at the ETH Zürich and work for HackerOne as a security analyst. My interest in security actually started with photography — I went from photography, slowly became interested in design, development, and then finally got into security. How do you manage your personal life, work, and bug bounties? Do you do bug bounties as a job or a hobby?
Bug bounty hunting is something that I do in my spare time. I do not depend on it so it is fairly easy to balance it with my everyday life as a student. That being said, if I would like some pocket money then I might invest a bit more time into hunting.
Timewise, I currently spend about four hours. I used to invest a lot more time, but I have found that in order for my interest to remain healthy I must not overdo it and spend ages hunting. I believe I find about three bugs a month on bug bounty programs.
My first fairly significant issue was on a non-platform based bug bounty program and was discovered a couple of months after having started bug bounty hunting. Admittedly, I had already been interested in security beforehand, but the whole bug bounty concept was new to me.
I cannot single out on specific vulnerability, to be honest. There are so many that I love looking back at and reminding myself of the fun story behind the bug. My favourite vulnerabilities tend to be the ones that really have a story behind them. For instance, I recently came up with the idea of looking into namespaces and seeing whether or not certain targets reserve them. At first, the issue was purely theoretical, but then applying it into context and being surprised by the fact that the little idea I had in my head actually works in practice is what sticks with me.
DEF CON and H1-702 were the turning points in my career. I felt compelled to share the various things that I had learned so far on my bug bounty journey and motivated to look further in order to discover more.
For general trends, I follow Twitter, blogs, Slack channels, Hacker News, and the Hacktivity feed on HackerOne. On top of that, I love chatting with people and attending local events in order to stay updated.
All the time! Ben Sadeghipour gave me one of the biggest pieces of advice during H1-702 and that is to collaborate with other members of the industry. I find myself hacking with people all the time from all around the world. Usually, we collaborate by messaging each other, but sometimes we even go so far as to hack via a video call or in person. The people that I collaborate the most with are Gerben Javado and Tom Hudson. Even @mongobug gives me some advice every now and then. The security industry is full of people that want to help and collaborate; all you have to do is get in touch with them and network.
I love experimenting! This means I spend quite a lot of time practicing in a controlled environment and looking for unusual, but good ways of approaching a target. By doing research on reconnaissance processes I am able to find techniques that popular tools do not use and then scripting them myself. Talking about scripting, it is vital that hunters automate as much of the reconnaissance process as possible. This will give you the upper hand when approaching a target, especially a competitive one or a target with a large scope. My personal reconnaissance wrapper script finds subdomains, open ports, various directories, checks the target’s DNS records, takes screenshots of all the endpoints, and much more. Once my reconnaissance wrapper is done scanning, it stores the results in a git commit. Some of these features are included in the megplus script.
Talking about automation, an aspect that I did not include in my process for a long time was monitoring — mainly keeping track of variations in your reconnaissance script’s output. I now use the results in the git commits to notify me of any changes. A quick
git diff is all it takes to find differences in your script’s results.
No, definitely not. I find that my approach varies based on the target. From experience, I have noticed that patterns arise when hunting on certain types of targets. For instance, companies from the financial sector that handle payments will require certain functionality that when implemented incorrectly cause certain issues. On top of the target type, I also look for certain features that could potentially open the target to various issues. When I stumble across webhooks, my immediate thought is Server-Side Request Forgery, since the integration has to connect to an external instance with a user-supplied address.
Whenever I cannot find a tool that covers a certain task, I code it myself. In my opinion, knowing the default set of tools that come with your Linux distribution is key to making your life easier while hunting. Common third-party tools that I use when targeting web applications include Sublis3r, knockpy, dirsearch, meg (actually any tool developed by Tom), LinkFinder, virtual-host-discovery, wpscan, webscreenshot, twitterBFTD, broken-link-checker, and Frans Rosén’s little parameter collection bookmark thingy:
Aside from these tools that I used during the hunting phase, I find it is important we do not forget about tools that can help you during the reporting process. Frans Rosén has a template generator project that allows me to quickly put together reports by simply filling in the blanks. This is especially useful for reporting issues to competitive programs, as the tool will save you a lot of time. For low hanging fruit I do not even bother writing a report any longer.
Make sure you are very familiar with your proxy of choice, and practice finding these type of issues in CTFs and in lab environments. Often times, writing my own vulnerable software has helped me get a better understanding of how to exploit server-side vulnerabilities.
Time and time again. I understand the mental barrier that a popular and competitive target presents, but I am constantly amazed by what I find on these popular programs. If you are really struggling on a competitive program, I highly recommend keeping track of new code and features being pushed. This can be achieved by either following the development news feed or coming back to the same target and double-checking to see if a new feature was added. On top of that, sometimes targeting the core functionality of the application and looking for logic flaws can be extremely rewarding on older programs. Take my recent Keybase reports, for instance, Keybase’s program has been around forever; all I did was target the main component of the application and ask myself about which design issues might not have been considered when creating Keybase. The reason why these issues are sometimes overlooked is because, for one they are not your everyday vulnerability, and two we often assume that the core functionality will be the most rigid component of the application.
Yes, absolutely. Although not a requirement — as I have seen with some successful bug bounty hunters — having a background in a technology-related field might give you a head start. Whenever someone asks me how to get started, I always respond with a very simple philosophy: “Learn to make it; then break it”. By this I mean, learn how to build the components you will be breaking. You are more likely to notice patterns in targets and better understand what is required to exploit the issue. On top of that, being able to code might also help you when writing detailed proof of concepts or a tool to help automate part of your hunting process. In my experience, my development and design background has helped me create unusual and convincing proof of concepts.
I listen to a wide variety of music. In my spare time, I like to play the guitar so I love listening to Jimi Hendrix, Guns & Roses, and Van Halen, but I also find myself listening to electronic music including Dubstep and EDM trap.
Swimming, playing the guitar, studying, going to security-related events, and photography.
I can finally fly to the US, hack the US Airforce, and not get arrested at the border. How crazy is that?
Not necessarily hacking related, but currently, I am more focused on better understanding the fundamental concepts of technology. Studying computer science is really helping me with that. I find the bits and bytes that power our technology to be a fascinating topic that I really want to learn so much more about.
I have had cases where the target has threatened to sue me, but one of my earliest experiences with disclosing a vulnerability was to a company that was very grateful for my report and then suddenly asked me where I lived. Immediately, I thought something was up. Why would a company want to know where I live? Were they trying to take legal action against me? Were they going to call the feds on me? After about ten emails trying to figure out what they were after, I finally realised they wanted to offer me a job. I am pretty sure after about the fifth email they lost interest in me because I could not put two and two together.
On a serious note, for a long time it was filedescriptor and then that dream became a reality. It was a very successful session.
I could write a book on this subject that is how many features I would like to see implemented on bug bounty platforms.
Sublime Text and Vim. I used to be a hardcore Atom user but had to give up and move to Sublime Text.