I’m Arne Swinnen from Belgium, 28 years old. I started hacking with the CTF-team of my University KU Leuven around 10 years ago. My bug bounty endeavours began in the summer of 2015, namely Instagram (Facebook bug bounty program). Currently, I work on bug bounty platforms HackerOne, Bugcrowd, Intigriti, Zerocopter and Bounty Factory, besides the well-established “standalone” programs from Facebook, Google, Paypal and some others.
I’m doing bug bounty hunting full-time since August 2016, so for a good year now. The year before I was still a full-time employee, so I only dedicated evenings, weekends and holidays to bug hunting back then.
I roughly spend between 40-50 hours a week on bug bounty hunting and reading the latest write-ups, 10 out of 12 months a year. I could certainly spend even more time on bug hunting, but I want to avoid burning out like some other hunters have experienced.
I don’t report an overly lot of bugs, I have an average of 15-20 bugs per month. I do tend to focus mostly on server-side issues, which are somewhat less prevalent than client-side ones. I’m also allergic to informative and N/A, so I only report issues of which I’m 99% sure the company will appreciate and resolve it. Issues of which I’m not 99% sure are set aside to combine in a chained PoC with higher impact to ensure they are accepted (e.g. open redirect & login CSRF in Authentication bypass on Airbnb via OAuth tokens theft).
It did take quite some time for me to find my first high impact vulnerability on Instagram, I would say roughly four weeks of effort. Usually I do a couple of “sweeps” on a bug bounty program, and it was only during the second and third sweep on Instagram that I located several Authentication Brute-Force vulnerabilities and an Account Takeover vulnerability without user interaction.
Personal favorite: How I Could Steal Money from Instagram, Google and Microsoft Most technically interesting: Authentication bypass on Uber’s Single Sign-On via subdomain takeover Most impact: - RCE via PHP Object Injection (thanks Ambionics) on private H1 program - Race condition via Burp Intruder (thanks Josip Franjković) on private H1 program
As mentioned before, I CTF’ed a lot during my time at University, which triggered my interest in hacking. After I graduated I worked as a penetration tester for four years. During this time I noticed that I could really enjoy hunting bugs continuously, whereas some of my colleagues got bored after hunting for a while and took another career path.
As for most bug bounty hunters, the beginning was the hardest. I picked out Instagram since I didn’t find too many write-ups about it online at the time, and I really gave it my all, given my penetration testing background. This eventually yielded 10+ different bugs, after which the bug bounty story really started for me and I discovered the bounty platforms.
I’m always on the lookout for new write-ups in the #blogs BBF slack channel and on Twitter. Besides, I regularly visit reddit.com/r/netsec to keep up with general IT Security news.
I personally haven’t collaborated much with other hackers up until now. Belgian bug hunters @intidc, @preben_ve, @jeromekleinen and myself did have a test run for #teambelgium during the latest H1-702 event with promising results, so I’m looking forward to collaborate more with other hackers in the future.
Recon-wise, I’ve setup a semi-automated system to discover as many subdomains as possible of a target that has a wildcard, e.g. *.example.com. Nothing extremely fancy, just the regular combination of tools such as Sublist3r, MassDNS and scans.io parsing. I do give more attention to CNAME and NS records for takeover vulnerabilities. More information about automation of these techniques can be found here. CNAME records also often reveal the hosting infrastructure, which can be very helpful for additional exploitation, e.g. SSRF.
Up next, I browse the application a first time while keeping an eye on burp history (or Logger++) constantly while doing so. A HD screen which can display multiple open windows (burp & several browsers) really helps during this process to maintain an overview of what’s happening. I always look at session management and authentication mechanisms first on all auth-related endpoints I can find (website, mobile API, developer API, etc), as the attack surface often is big and these vulnerabilities are generally high impact. Hereafter, I’ll deep-dive and start hunting for server-side issues (see question below).
I also work in sweeps, it helps me to understand the application a lot better. During the first sweep I try to find all functionality and its related endpoints fast while looking for common bugs such as simple IDORs or SSRFs. I’ve noticed in my Instagram endeavours that, during a second and third sweep, more complex bugs can be discovered, since you already know the application’s base functionality and technologies from the previous sweeps. It allows you to recognize exotic behaviour more easily and thus dig much deeper on the most interesting parts.
No. I only actively look for issues that require (almost) no user interaction, such as RCE, XXE, SSTI, Authentication Bypass, SSRF, IDOR, Privilege Escalation and Blind XSS. I believe that these are the kind of issues that are doing companies the most harm currently next to social engineering, but the latter is typically out of scope for bug bounty programs.
I have only reported a handful of client-side vulnerabilities such as reflected XSS and CSRF, as I tend to only report them when they literally blow up in my face, or can aid in a chained PoC with increased impact (e.g. overly scoped cookie in Authentication bypass on Ubiquity’s Single Sign-On via subdomain takeover).
I mainly use Burp and some of its popular extensions from the bApp store, including Active Scan++, Additional Scanner Checks, Authmatrix, Backslash Powered Scanner, Collaborator Everywhere, Logger++ and JSON Decoder. Occasionally I write my own burp plugin when necessary (e.g. Instagram). I use Burp’s Active Scanner a lot on selected parts of requests via the helpful Scan Manual Insertion Point plugin to gain some time during testing. I also regularly use the Burp Collaborator Client which is built-in in Burp Suite. It allows quick detection of a myriad of vulnerabilities via out of band techniques, mostly through DNS lookups & HTTP requests.
Besides burp and its plugins, I also have my own DNS and webserver setup for out of band exploitation through e.g. blind RCE or XXE. Additionally, I use the open-source FakeDns github project from @crypt0s to perform the “Time-of-check to Time-of-use” SSRF attack which is mentioned in Orange Tsai’s awesome SSRF Black Hat USA 2017 presentation.
Next to that, I have two rooted Android phones and a jailbroken Iphone at my disposal to test mobile applications.
RCE-wise, I’ve been having some luck lately with deserialization issues (both Java & PHP) and SSRF exploitation via Amazon metadata. SQLi-wise, I don’t really try this a lot manually anymore as they are becoming less and less prevalent, unless I know the technology stack of my target is particularly vulnerable (looking at you, PHP+MYSQL). I generally leave this up to Burp Scanner in other cases.
Blind XSS-wise, I mainly throw standard payloads from XSSHunter.com in fields that I believe may be displayed in back-end admin panels and hope for the best. For STTI, I use the standard payloads mentioned in Portswigger’s extensive blogpost on the matter. XXE and SSRF are always tested manually in combination with Burp Collaborator Client for blind cases (egress filtering). Authentication bypass is typically specific to the target itself, except for brute-force. I always test IPv6 support, but few companies have adopted it so far. To evade uniqueness checks on user UUIDs during registration to achieve Account Takeover, I’ve had some luck with unicode-related tricks.
Pretty often. This is basically the real strength of crowdsourced security: the more eyes that look at a target, the more vulnerabilities are found. Everyone has a different angle to approach a target, no individual hacker is perfect. This is very important to keep in mind while bug hunting on established programs. It’s hard to accept as a hunter, but my personal goal is to make the number of server-side vulnerabilities that I overlook as small as possible, hereby knowing that 100% will most likely never be achieved.
Having a pentesting background definitely helped me. On one hand, I already had knowledge about the most common web vulnerabilities. On the other hand, it learned me how to write a decent report.
It ranges from Rock to Tropical Dance, it really depends on my mood.
Spend time with family and friends.
Pretty major impact. I’m doing this full-time now for more than a year. Bug bounty hunting allows me to work from home as opposed to spending 2-3 hours commuting on a daily basis. I have a lot more time and less stress now.
I became a full-time bug bounty hunter after having participated in only three bug bounty programs, namely Instagram, Uber and one private program. It was kind of a risky move, but I haven’t regretted it for a second so far.
Persist. There’s always something that has been overlooked.
I do wish to improve my mobile reverse engineering skills, as this often yields a larger attack surface in terms of endpoints. I am also considering more low-level bug hunting, such as fuzzing for heap overflows in browsers and other targets, but this is a whole different ball game.
I don’t eat toast.
I’ve received the “informational” status for two reports on the same program of which I’m still convinced they highlighted an actual security issue. Apart from that, I’ve come across the occasional disagreement about bounty amounts, but that being said, I consider myself lucky to not have experienced major disappointments during my bug bounty hunting endeavours so far.
It would be @mongo. His stats on Bugcrowd are mighty impressive, month after month, year after year.
I would like to have the ability to reach out to a program, to ask whether they consider certain behaviour to be a security risk worthy of reporting or not. Currently, I often do not immediately report in such situations, as I’m allergic to information and N/A statuses. I currently do this on an ad-hoc basis with some programs I’ve been active on for a while now, but I believe platforms could foresee this functionality in the future.
I’m a Vim person.