On May 24th 2019 I received an invitation to a private program on HackerOne. This isn’t unusual, but the program name caught my eye. It was an invitation to the “Uber H1–4420 2019” program. Now, I can’t talk specifically about the program details, but after agreeing to a three year NDA with Uber I was able to see everything people invited to the live hacking event “H1–4420” needed, including non-public information. I didn’t, however, receive any details about the event itself. It very much looked like HackerOne had invited me to one of their events (and it would’ve been the first time they did so), so I sent them a DM on Twitter to ask if details would be sent out in the coming days.

As it turns out, someone screwed up. I had received that invitation by mistake. A few hours later I received the following email:

Well, that sucks. I had started thinking about my travel plans and the logistics of leaving my Airbnb in Malaysia to fly to London for a few days, and all the awesome hackers I’ve been wanting to meet.

A few days passed and I sort of forgot about it. Mistakes happen. Then, I received a DM from HackerOne stating I “should be receiving additional information shortly”. I was also told to disregard the previous email and to expect another.

A day or so later I received a DM from someone at HackerOne inviting me to come and hack at H1–4420. I suppose they were trying to honour their word and make things right. However, after a confusing discussion it turns out they had to take back that invite and the only reason they invited me was because they thought I was already in the London area. This seemed odd considering HackerOne regularly hosts live events and invites hackers from all over the world to hack at their events. It’s also odd because I’ve never lived in or near London, and I’ve been quite public about the fact I’ve been living in South East Asia for a few months now. I also know at least one hacker isn’t able to attend because of visa issues, so it really does make you wonder if you’re just not worth the ROI.

Ironically, between the time I was told I would be receiving additional information and being invited (again), HackerOne tweeted out a link to my blog post on mental health:

HackerOne on Twitter

We also wanted to share this insightful blog post by @NathOnSecurity: https://t.co/HoJZTgWW2u. "Find what works well for you, but look after yourself at the same time." We couldn't say it better. 👏🏾

Unfortunately, my blog post didn’t cover situations such as this, but venting on Medium seems to be working well.

My message to HackerOne: You tried to make things right, but you ended up making it worse. The first time was a mistake, the second was a punch to the back of the head. I don’t know how many other hackers were mistakenly invited, but I hope this is an isolated incident.

About Me

Hi, I’m Nathan, and I’m a (now) full time bug bounty hunter. Since 2015 I’ve been participating in bug bounty programs and I’ve earned tens of thousands of dollars in rewards. I’ve worked with some amazing companies and found some really neat bugs, and I’ve also completely burned out and gone months without even attempting to find a vulnerability. Having heard similar stories from other bounty hunters, I wanted to share my personal experiences in the hope someone will benefit.

The Sell

Bug bounties are a great way to make money. Google, Facebook, PayPal, Imgur, Uber, and many more companies give monetary rewards for valid vulnerability reports. What’s not to love?!

Bug bounty programs have changed lives. They’ve certainly changed mine for the better. I’ve seen hackers on Twitter who’ve bought cars, houses, holidays, computer gear, paid off loans and debt, donated to charity, all with money they’ve earned from bug bounties. You have no boss, you choose which companies you want to work with, when you want to work, and how often. You don’t need a computer science degree or have to pass a test. You pick a program (or twelve), read their rules and scope, and start hacking. Particularly for people who are less fortunate and don’t have the same opportunities others might, bug bounties are a great source of money, experience, and enjoyment.

Personally, I’ve earned enough money to travel the world while continuing doing what I love. The last few years have been amazing.

But It’s Not All Plain Sailing

Bug bounty programs have their downsides too. It’s a highly competitive scene. You can feel pretty down when you discover someone reported the same vulnerability a day, a week, or a month before. If the team is slow to fix bugs then they’re more likely to get duplicate reports, and it can feel like time wasted for everyone.

Sometimes communication with the team will break down. You might get a bounty lower than expected. Perhaps the team has a different opinion on the severity of what you’ve reported, or maybe the program silently dies and you don’t even receive a reward. These are all real scenarios that I or others have experienced, and often it’s out of your control.

If you’re not finding bugs at all it’s very easy to feel like an imposter and start questioning your abilities. Maybe you need to improve your skills, maybe you’re searching in the wrong place, or maybe you’re just unlucky. Bounty hunters will spend the majority of their time learning about the application they’re testing, understanding how it responds to different input, and often not finding anything. This, I believe, is the main source of stress and anxiety when it comes to finding bugs.

If you push yourself too hard, you’ll get burned out. You’ll lose motivation, run into writer’s block, and feel like it’s impossible to continue. It might be days, weeks, or even longer before you feel confident enough to start again. It sucks. Burning out multiple times is not unheard of, either.

Self Care Is Important

How you approach bug bounties can have a big effect on how stressful you find it and how fast and often you burn out. As bounty hunters we want to find vulnerabilities and the more pressure we put on ourselves the worse our mental health is going to suffer.

Found a duplicate? That’s awesome! Congrats friend, you found a valid vulnerability. Yes, it sucks that you’re not getting paid, but you will next time. The time you’ve spent finding that vulnerability has been time spent learning and challenging yourself. It’s experience, and experience is a big factor when it comes to finding vulnerabilities, especially more obscure ones. Take it as a win, not a failure.

Forgoing sleep for a few more hours of searching is something I’m very familiar with, but it does nothing but wreck your sleeping pattern and make you feel worse when you’re awake. Waking up with a clear mind and feeling well rested will make testing less of a chore and you’ll be able to think straight. Anybody worth their salt will tell you how important sleep is.

Productivity isn’t how many hours you work, but how efficient those hours are. If you’re using your energy to try and find a bug, but you’re tired as fuck, you’re less likely to find one. These days, as a full time bug hunter, I treat my work like I used to treat coding back when I was a kid. I do it for fun. I throw on some music, open burp suite, and see what I can find. When I’m feeling stressed or tired, I’ll stop and do something else. Have a glass of water, sit outside, go for a walk, browse Twitter, anything which gives my brain a chance to cool down. Before jumping straight back into it, I might even read a few blog posts about different techniques to give myself new ideas and to pull myself away from what wasn’t working. When you’re your own boss you don’t need to be an asshole to the person doing the work.

I tried giving myself deadlines and daily goals, but it just didn’t work for me. Now I give myself a monthly goal of how much I want to earn. Without the daily pressure I find myself hitting and even exceeding my goal. YMMV, but forcing yourself to find bugs isn’t going to be enjoyable in the long run.

Instead of daily goals, I use the “eat that frog” technique.

Eat a live frog first thing in the morning and nothing worse will happen to you the rest of the day. — Mark Twain

I get my work done in the morning, but I don’t push myself to find a vulnerability. With time I’ll find one, and I won’t be carrying 12 hours+ worth of stress when I report it. If you’re doing bug bounties full time, or planning to, try not to do them every single day. Giving yourself a normal weekend is completely fine and you deserve the time off.

Final Thoughts

My experience is going to be different from yours, and no two hunters are the same. Find what works well for you, but look after yourself at the same time. It’s okay to not find bugs. It’s okay not understand a certain technique. That’s just a part of the job. It’s not okay to overwork yourself and sacrifice your mental health for additional stressful. You will find a bug. There always will be bugs. You can absolutely do this. More importantly, you need to look after yourself, and I definitely do too.

NB: I’m not a writer. I’m just guy with a Macbook Pro that I bought with bug bounty money.

If this has been helpful, please share with others. Did I miss something? What are your thoughts? Please, let me know.

As always, I’m @NathOnSecurity on Twitter. Thanks for reading.

On the 25th of October, 2016, I woke up and thought to myself “How easy would it be to hack the NHS?”. By lunch time I was writing a report.

I started by looking on Shodan for any Internet-facing machines which might be of interest. It came to my attention that the NHS had its own ASN (AS41373 — NATIONAL HEALTH SERVICE) which made my quest far easier. Shodan has an ASN filter to limit results to a specific ASN. After a few minutes I discovered a webserver (194.176.105.219, also known as monitor.nhs.uk) with a simple login form. From here I could have gone multiple routes, but I decided to test for SQL injection first. My favorite tool for the job is sqlmap, a powerful open source toolkit for detecting and exploiting SQL injection vulnerabilities.

$ python sqlmap.py -u 'https://194.176.105.219/login.php' --random-agent --data='username=test&password=test&btnLogin=Login' --batch --dbs

I wasn’t hopeful, but it was worth a shot, and it certainly paid off.

POST parameter 'username' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N
sqlmap identified the following injection point(s) with a total of 454 HTTP(s) requests:
---
Parameter: username (POST)
    Type: boolean-based blind
    Title: MySQL RLIKE boolean-based blind - WHERE, HAVING, ORDER BY or GROUP BY clause
    Payload: username=test' RLIKE (SELECT (CASE WHEN (3915=3915) THEN 0x74657374 ELSE 0x28 END))-- MgVq&password=test&btnLogin=Login

Type: error-based
    Title: MySQL >= 5.0 AND error-based - WHERE, HAVING, ORDER BY or GROUP BY clause (FLOOR)
    Payload: username=test' AND (SELECT 5095 FROM(SELECT COUNT(*),CONCAT(0x716b707171,(SELECT (ELT(5095=5095,1))),0x716b7a6a71,FLOOR(RAND(0)*2))x FROM INFORMATION_SCHEMA.PLUGINS GROUP BY x)a)-- ppwP&password=test&btnLogin=Login

Type: AND/OR time-based blind
    Title: MySQL <= 5.0.11 OR time-based blind (heavy query)
    Payload: username=test' OR 4720=BENCHMARK(5000000,MD5(0x6d7a554b))-- GVLM&password=test&btnLogin=Login
---

sqlmap detected the “username” parameter was vulnerable to SQL injection, and proceeded to list the databases with ease. Curious how much damage could be done, I began exploring the primary database and unsurprisingly found a “users” table. It had 73 rows, so clearly access was limited to a select number of people. The first user was the person who originally wrote the application, a consultant from the UK. I could tell straight away the passwords were hashed with MD5, and sqlmap automatically cracked the hash for me. His password was “test”.

Using his username and password, I proceeded to login to the application.

Let’s backup for a second — What the fuck is N3, anyway? Why is there a BT share price graph?

N3 is the national broadband network for the English National Health Service (NHS), connecting all NHS locations and 1.3 million employees across England. In 2004, BT was awarded the contract to deliver and manage the IT project on behalf of the NHS. N3 was preceded by NHSnet, becoming N3 in 2006. — Wikipedia

Oh.

I had just hacked the monitoring tool of the N3 Internet gateway. Not only was I logged in, but I was logged into the application as a privileged administrator. I had the ability to manage users, edit configurations, execute system commands, and more, all from a leftover developer account with a password weak enough to guess.

The other users in the database were BT employees, some of who were indeed using weak passwords too.

The application was loaded with many tools. I could view gateway metrics (Broadband, DNS infrastructure, VPN tunnels, Firewalls, etc), visualize traffic (GCSX, datacenters, PoPs, gateways, etc), view logs, HTTP probes, and alerts, look up N3 IP addresses, and much more. Although I’m limited to what I can share, here’s a few things I found.

Local file inclusion in the log viewer

I was able to read arbitrary files from the filesystem, including source code. Having read the system hosts file I saw some other interesting machines on the network, though I didn’t go as far as to probe them.

The log viewer limited how many lines I could view, but fortunately for me I discovered a simple but notable slip up…

Source code disclosure

The server had directory indexes enabled, which allowed me to view the contents of the “includes” directory. Someone had made a backup copy of “common.inc.php” and named it “common.inc.php.old”. The server (rightly) didn’t recognize this extension, and prompted me to download the file instead. It’s quite common (no pun intended) for developers to append “.old” or “.bak” to older file revisions, however these files are easily enumerated and can pose a serious risk. It’s messy and lazy, and they should never make their way into production.

I didn’t bother to look for any more SQL injection or XSS vulnerabilities as I had already come to the conclusion the application should be nuked from orbit. I’d be surprised if the application hadn’t already been hacked in the past.

I first reached out to the consultant, however to this day I still haven’t received a reply. I next contacted a BT employee who was a user of the application, and he passed my message along to BTCERT who contacted me the next day.

I wrote up a report of everything I had found and sent it along, and I received a reply a few hours later stating they had taken the application down.

I’m pleased with BT’s response to the situation, and please to hear they have a incident response plan. There’s lots to take away from this post, but the main points are:

• You don’t need NSA exploits to breach sensitive systems. A chain is only as strong as its weakest link.
• Know your assets, and know them well. If you’re not in control, who is?
• Don’t allow your internal applications to face the Internet, even if they require authentication.

Unlike my previous post, Hacking Imgur for Fun and Profit, my only goal here was to have fun and see where my curiosity took me. The NHS provides myself, my family, and my friends with free healthcare, and it’s vital services such as the NHS are adequately protected.

If you liked this post, give me a follow on Twitter for more security talk and memes.

Thanks for reading.

I’ve been meaning to write about this for a while. It all started back in July 2015 when I decided to look for vulnerabilities in Imgur, an incredibly popular image sharing platform.

The reason I chose Imgur was because I frequently visited the site and I was already familiar with how the site worked. After a quick survey, I managed to identify some common vulnerabilities: XSS, clickjacking, and a whole load of CSRF issues.

Reporting the issues proved to be a little difficult. The only way I could see to contact Imgur was through their support system which wasn’t suitable for reporting security issues. Eventually, August 1st, I wrote up a report detailing the issues, shipped an email off to security@imgur.com, and waited. But not for long.

A couple of hours later, I received an email from Imgur’s founder and CEO, Alan Schaaf, thanking me and offering me some swag as a reward. Over the next few days I continued to forward them reports of vulnerabilities I discovered, including one which would later earn me over $5,000.

Things were quiet for a while. I occasionally checked to see if any of the issues had been fixed, and sure enough, many were. It was nice to know they were taking the issues seriously, and that I was helping secure the platform.

Then, in late September, Imgur got hacked. Someone was able to upload an HTML file with malicious Javascript to Imgur and proceeded to target 8chan users.

This was quickly fixed, however it was widely reported and clearly something Imgur wished hadn’t happened. In response, Imgur finally launched their bug bounty program a week later.

This was great news, as now people had a way of securely reporting issues. I contacted Alan once more asking if any of my reports were eligible for a bounty, and he put me in touch with one of Imgur’s developers, who confirmed I was eligible and asked me to create a report on HackerOne. For all the vulnerabilities I had reported — 20+ in total — $50 was my reward. The reason being “for the most part, we’re offering swag for CSRF reports, so you’re more of the exception here”.

Before Imgur created their bug bounty program, Imgur was riddled was CSRF vulnerabilities. Some, which have now been fixed, include: the ability to update the user’s bio, the ability to generate a new client secret for a given Imgur app, and the ability to change the redirect URL for a given Imgur app. These were some of the issues I had initially reported, so to be rewarded with only $50 was quite disheartening.

However, the developer was clear: the program was new, and they were still learning and trying to improve it. With that in mind, I gave him a list of the issues I had reported and he confirmed there was much more in the reports than he had realized.

In the few weeks between discussing the issues and getting an additional reward, I discovered something else interesting.

During my initial research, I looked through Imgur’s HTML source code and found the following snippet:

$(function() {
 if(!/^([^:]+:)\/\/([^.]+\.)*imgur(-dev)?\.com(\/.*)?$/.test(document.referrer)) {
 Imgur.Util.jafoLog({ event: ‘galleryDisplay’, meta: { gallerySort: ‘viral’, galleryType: ‘hot’ }});
 }
 });

This led me to perform some recon on imgur-dev.com, which turned out to be the domain Imgur uses for internal development. A quick Google search for site:imgur-dev.com revealed Google had indexed the subdomain “alan.imgur-dev.com” which contained a development version of Imgur. The server, however, was down at the time. I was able to view a cached copy of the page which revealed some interesting information, including database tables and column names in SQL queries output by Kohana’s profiler.

Fast forward to November, I decided to take another look at imgur-dev.com again. Boom! alan.imgur-dev.com was live and accessible. What did I find? It was essentially Imgur as you know it with a couple of users and a few test posts. What’s notable is it’s a developer’s environment — I could see stacktraces which included parts of Imgur’s source code, PHP warnings and notices, details about the environment, database queries, and full paths to configuration files.

With these details I created another report on HackerOne and waited for a response. Two days later, I took yet another look at alan.imgur-dev.com. This time I decided to use SubBrute on alan.imgur-dev.com to see if there were any sub-subdomains which may be of interest.

Not longer after starting the scan, I got a hit: es.alan.imgur-dev.com. A quick visit showed it was an Elasticsearch server which hadn’t been updated in a while. In fact, after searching around for an Elasticsearch vulnerability, I discovered CVE-2014–3120.

The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execute arbitrary MVEL expressions and Java code via the source parameter to _search.

Naturally, I grabbed a proof-of-concept script and tried reading /etc/passwd. Bingo. File read successfully. Now, the safe thing to do here would be to report the issue and move on. Not this time. Imgur was at the stage of offering $50 rewards and swag. I wasn’t happy with that. I decided to go further and see how badly I could pwn Imgur if I wanted to.

One configuration file I noticed earlier on was called “keys.php”. I decided to try and read it as I had done /etc/passwd, and once again it was a success. This file contained everything I needed. API keys for Fastly and MailChimp, mobile app API keys, even reCAPTCHA API keys. Sweet. But that’s not all… the file also contained the credentials used to connect to both the local and remote MySQL servers. Whoops.

The problem now was that I didn’t know the hostname of the remote MySQL server, and I can’t connect to the local one remotely. Wat do?

I went back to the scan of subdomains, and there was another hit. sql.alan.imgur-dev.com. Oh yes, you know what’s about to happen…

I visited the domain and was greeted by phpMyAdmin. Now, usually you’d expect to enter only the username and password to login. Luckily for me I was given a choice of hosts to connect to. One was the local server, and the other was a remote server hosted on Amazon AWS. I selected the remote server, entered the credentials, and I had full access to Imgur’s production database.

Well, there you have it, it was fun to write about… Oh, you thought that was it? That’s not all, folks.

The configuration file also contained two sets of Amazon AWS access keys — one set for development and one set for production. So what did I do next?

Nothing.

Although I know I could have used the keys to spin up new servers, SSH into existing ones, or completely destroy them, I decided against even testing whether they worked.

An important part of security research is knowing when to stop.

I went far enough to prove how serious the issue is, and demonstrate what a malicious attacker could do, while not being overly careless or intrusive.

This needed to be fixed, and fast. I updated the HackerOne report with my new findings, and emailed Alan urgently to bring it to his attention. Within half an hour the server was offline. The next morning, Alan replied letting me know that access to the server was disabled while they figured out the next steps. I was incredibly impressed with how they handled it.

A security group configuration error allowed Imgur development environments to face the public internet. Typically these environments were protected behind a special endpoint which would open access to authenticated Imgur employees for a short time window. Since the development environments were configured in such a manner to make development easier, some keys and environment variables were exposed. While most of these pieces of sensitive information were limited to the development environments, some production information was also exposed. Since this report was published, security around development environments has been completely re-worked and they now reside behind a VPN.

Moving forward to early December, for both the multiple vulnerabilities and the high risk issue I had reported, I was rewarded with $500. Needless to say, I wasn’t impressed. I decided to write a email to Alan giving my feedback on the program so far, and also explaining why $500 wasn’t enough.

Bug bounties are like hiring mercenaries. Cheaper than a standing army of pentesters. But don't complain when they swap sides for more gold.

A week later Alan replied, agreeing with the points I had made, and said the team would have a meeting about the program soon. I was pleased to hear my feedback was taken seriously. Sometimes it helps to talk to the CEO directly for real change to happen.

Forward once more to January 2016, Alan sent me a final email.

Hey Nathan,

Happy new year! I was finally able to sync up with my team and come to a conclusion on this. Since your exploit went above and beyond (contained several exploits all chained together, access to production data, etc), we want to go above and beyond for you too, and have agreed to offer you an additional $5,000. This is so much higher than anything we've ever offered before, but again, this exploit was so much higher than anything that has
been found before, so I think it's deserving and I hope it's sufficient for you.

Thanks so much for protecting us and properly reporting it to us. Best of luck in the new year.

Best,
Alan

This was fantastic news to receive. Not only did Imgur change their bug bounty program to pay out fairly to researchers, the additional $5,000 has helped myself and others incredibly. Half of that went to people in need, including Lauri Love, a hacker facing extradition to the United States, and a close friend who was recently made homeless. Various charities and researchers also benefited from it.

I’ve continued to participate in Imgur’s bug bounty program, and while it’s not perfect, it’s responded and paid out nicely to myself and others. I hope other teams can learn from Imgur’s willingness to take on feedback and improve, as communication around security is so very important.

What’s next for me? I hope to continue learning and work to make the Internet a safer, securer environment for future generations. The Internet is tiny compared to what it will be in 10 years time. The battle isn’t over, and war is yet to come.

If you’re looking for a challenge, I highly recommend checking out Imgur’s bug bounty program and others on HackerOne.

You can follow me on Twitter where I tweet about security, the terrible British weather, and memes. Yeah. You know you want to… :-)

Hacking Imgur for Fun and Profit was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.