Search What is Detectify?
×

Undetected e.02 recap: Fredrik N. Almroth - Bug Bounties

Jocelyn Chan / May 5, 2020

Bug bounties – some argue that this is one of the buzzwords of the decade in the cybersecurity industry. Whatever you want to label it, it’s a trend that we can’t ignore these days. A lot of companies are taking part in it, so what’s it all about? 

There were many valuable soundbites to take from this, and especially from podcast guest, Fredrik N. Almroth (@almroot) because he’s hacked all the tech giants and more. If you can name it, he’s probably hacked it. We’ve taken highlights from this bug bounties episode, and the dialogue has been edited for brevity. Let’s dive in:

Detectify Co-founder and security researcher Fredrik Nordberg Almroth

Image: Fredrik Nordberg Almorth, Detectify co-founder and world-class bug bounty hunter

Undetected – a web security podcast is a Detectify production that uncovers different depths of web security. You can listen to the full length of Episode 2 on SimpleCast or your preferred podcast platform. The video version is also available online.

Fredrik and his take on the evolution of web security

Fredrik: Well, I’m a security researcher and co-founder of Detectify and… I hunt for bug bounties, which kind of correlates to how we do things in Detectify. I started already in high school … when I met my fellow co-founders of Detectify. By that point we realized that, well the Internet is quite broken. This was back in 2006 when we first met and by 2008, we decided to start a consultancy business doing penetration testing. But one thing led to another and we started automating things and this idea kind of grew. So we all went to university and dropped out one after another. And by this point, some ideas started to stick, like crawling is pretty good to find your URLs on the website and if you have query parameters in URLs then you can start looking for SQL injection.

Then Cloud started becoming a buzzword around here in Sweden. So we figured why not make a new company doing something else.

Laura: We have taken quite huge strides when it comes to security in these past few years as well. How do you feel that automation, for example, played into this?

Fredrik: You can say that some vulnerabilities come and go, SQL injection was a lot more out there a couple of years ago, but now it’s mostly been abstracted that way by different frameworks and so forth. But at the same time, you now have like server-side template actions, and it’s basically the same kind of injection attack state. 

They come and go, but in different forms over the years. Now there’s more out on the internet, more services, more technologies in general. There are more things, hence more things can break, but at the same time, the vulnerabilities that exist back then, are not as common nowadays except for XSS.

Laura: It (web security) really evolved and the hacks in general. The Tesla hack you did was a cross-site scripting attack. Right?

Tesla DOOM DOM XSS

Fredrik: Tesla was running Drupal at the time, and Drupal was bundled with a “what-you-see-is-what-you-get” kind of editor called CK editor, and this library bundles with an example file. So using this example file you could do a drag-and-drop XSS where you can drag something that looks okay on one website onto some other place, and it executed in Tesla’s origin… And then you have cross-site scripting – Tesla DOM DOOM XSS. So what I demonstrated was you could play Doom on Tesla’s website, and I replaced the entire window with the game Doom.

Laura: That sounds like fun. Couldn’t play Doom anywhere else?

Fredrik: Yes, it’s, well I packed away this payload because it was fun. So I use it every now and again in various cross-site scripting demonstrations.

Getting read access on Google

Laura: Also a bigger vulnerability that you found previously was back in 2014 when you found an XXE vulnerability in Google. Basically you were able to run your own code on Google’s server. 

Fredrik: While the company wasn’t low on cash yet, Mathias Karlsson (a co-founder) and I figured that bug bounty actually works as a way to collect some money. So what’s the most bang for the buck? What companies are out there that we can hack and get the most money for the least amount of effort? Facebook or Google.  

Well, Facebook is not very fun to target, so we went for Google. Our approach was: we should find the newest features and products or go for the really old legacy stuff that they might’ve forgotten. So using Google search itself, we found a feature that dated earlier than 2008 called the Google toolbar button gallery. So if you remember this way back in the Internet Explorer, you had this toolbar from Google and companies could upload their own buttons to this toolbar and that was the feature we attacked. This was an XML file uploaded to Google.

You as a website owner could add your own button to the toolbar so that other users could find you. This button definition was an XML file and quite frankly, you can do a lot of weird things in a plain vanilla XML file, and an external entity is one of those.

Fredrik: We uploaded a file and gave it some name and description, etc, but we added a definition that instructed Google to try to read another file from their local file system. So we tried to pull the normal user file on Unix systems and uploaded it and it worked. But we asked, “Okay, did anything actually happen?” 

We made another attempt where we changed the title to something like “hello world”, and then searched on Google or for toolbar buttons containing “hello world.” … meaning we searched for what we just uploaded.

Laura: That’s kind of like local file inclusion.

Fredrik: Yeah, that’s basically the impact. We got read access on Google.com. This was quite fun. So from start to stop, it took us four hours to identify, exploit and have it reported.

Start of bug bounty career:

Laura: Were these all bug bounty programs or were they public programs that you enrolled in or how did you stumble across these?

Fredrik: This was about the time that we actually founded Detectify and bug bounty started becoming something you spoke about on Twitter. So Google, in my world, was the first company I saw that had this kind of policy, meaning anyone can hack Google. If they manage to do it and Google accepts it as a new unique vulnerability, you get money for it and afterward, you can speak about it. As an early-stage startup, this was nice to have some material to be seen and heard.

Laura: How did people react to your work on bug bounties back then?

Fredrik: It varied. People in Silicon Valley know about this as that’s kind of where this entire industry started. But over here in Sweden, it was unheard of that this was even a possibility. For example, a friend’s friend of mine happens to work for the Swedish Police and I told him about the Dropbox hacking event which I attended in Singapore, and his response was, “What? You can’t do that? That’s criminal.” I said, “No, no, no, you missed the point.” I had to elaborate a bit on what bug bounty is and so forth.

Laura: In our bubble of Infosec, everyone knows what a bug bounty is or what responsible disclosure is, but outside of this immediate bubble, it is not that obvious. What is your short description of bug bounties?

Fredrik: Bug bounty is freelance penetration testing in a way. Anyone on the Internet can go to a company, find a vulnerability and have a streamlined process of reporting it to the company. If it’s a unique vulnerability and you are the first one to submit it, then you get a monetary reward at the end. Now we have platforms and marketplaces to facilitate this among vendors and researchers such as Bugcrowd, HackerOne and Synack.

Laura: Yes and bug bounties are offering a [monetary] reward in exchange for the vulnerability report or swag.

Responsible Disclosure Policy – that’s all it takes:

Laura: These bug bounties have basically lifted hackers out of the darkness, and now hackers can actually talk about what they have found. They can disclose it, depending on the program. It’s also shedding a more positive light on hackers.

Fredrik: Indeed. But I think it’s quite important to speak a bit about Responsible Disclosure programs as well, since it’s basically the first stepping stone to do something like this. It could be as simple as having an email address or a contact form where someone can submit vulnerability information. That’s all it takes.

More often than not, you (an ethical hacker) know it yourself that there are vulnerabilities all over the place, but it can be quite tricky to report it.

And you (application owner), you don’t always have to offer swag or money. You just have a channel to accept it.

Laura: A common practice out there is putting a security.txt file in your domain so that people find the contact information of your security personnel there for reporting.

Is this the minimum thing that a company should do in terms of Responsible Disclosure?

Fredrik: Security.txt is a very good starting point. With that, you can set up a security@company.com email (to receive reports).

Laura: So you don’t need to go on a commercial bug bounty platform and open a program there?

Fredrik: No, I think that should come a bit later once you have matured your security processes, so you know what you get basically. It can be quite overwhelming if you go directly to one of these platforms, open a bug bounty publicly to the world because everyone will start reporting straight away.

Laura: Do you think that a company who enlists in a public program will get a ton of reports right from the get-go?

Fredrik: More in the beginning, and then it should probably slow down.

Laura: Would it make sense then to do some kind of security assessment before that?

Fredrik: Once you’ve had your pentest reports, some automated scanning and an organization that can handle the security reports, then you should consider a Responsible Disclosure Policy or a private bug bounty program. After that, you could make it public.

Laura: Do you feel that offering a bug bounty program is appropriate for all sorts of companies out there?

Fredrik: Yes, I think so as long as you have some kind of online presence. But it has to be something technical. It’s quite hard to have a bug bounty otherwise. Even manufacturers of hardware, for example, are growing with IoT applications. These could open up as bug bounty programs.

Laura: Yeah. I’m just trying to think of something that wouldn’t have an online presence these days.

Fredrik: But Everything has, right?

Laura: Yeah. Everything has at least a company website, if nothing else.

Fredrik: Exactly. You always have something important to your business and you can probably make a bounty program around that. Ask yourself, what are you trying to protect? Say you are Dropbox. The most sensitive things would be your users and their files, right? If you’re Apple, well, it’s basically everything, that’s a bad example I guess. For a bank, it’s probably the money.

So then it doesn’t really matter if it’s only one domain. That’s the scope for your program. You should really try to think about this, “what am I trying to protect?” and make a policy thereafter.

Setting the scope of your disclosure program:

Laura: You mentioned “Scope”, and the scope in a bug bounty program is defined by the company and it can be a domain or source code or some device.

Fredrik: Yes, it’s usually along those lines. It’s one or several domain names that can be mobile apps, GitHub repositories, etc. If it’s a hardware manufacturer, it could be their devices to sell to consumers. There are a lot of blockchain companies that would be attacking the blockchain technology itself.

Laura: What is the best scope for you as a bug hunter?

Fredrik: For me privately, the bigger scopes the better. Being a security researcher, you have a bit of an arbitrage. The more things that are exposed and that you can audit, the more things will break, as simple as that. The bigger the company, the easier it is in my opinion, and that’s because a bigger scope means more critical vulnerabilities and that’s more business impact. So it will help you as a company even more.

Laura: So what happens if you go outside of a scope in a bug bounty program?

Fredrik: That really depends on the organization. What really matters in a bug bounty program is the business impact that an outsider can have. So unless something is explicitly out of scope, it could be fine to report a vulnerability if it has a proven impact.

That’s my take on it. Although that could also be considered scope creeping if you do this.

Laura: What is scope creeping?

Fredrik: You go a bit out of scope and in again. For example, if you find something on Adobe and you go outside to some local subsidiary or something and then back into scope. More often than not, it’s generally accepted on these live hacking events. 

Laura: Maybe at the live hacking events, the overall environment is easier to control than hacking otherwise.

Fredrik: In these events, they collect a group of people to hack a company over a day or two in person. Then you have all the stakeholders at one place they can communicate about it.

Laura: Do some security researchers not report something if it’s out of scope and if it’s not that critical?

Fredrik: 100%. I really believe so. For example, Open Redirect is no longer on the OWASP Top 10. Finding an open redirect somewhere on a subdomain that might be explicitly out of scope and while you know it’s there, you wouldn’t report it with the risk of losing a score or a reputation or what-not on one of these platforms.

But at the same time ,if they have Oauth and misconfigured, I can use it to do some kind of authentication bypass or steal some sensitive tokens. Then all of a sudden you’re out of scope, then go in again, and you might have an account takeover and that would be usually considered critical.

And that companies would accept.

Laura: So it really depends on the impact and if you can demonstrate the impact.

Fredrik: Exactly. That’s, I think that’s the moral of the story. It’s the impact that matters. You need a proof of concept. Otherwise it’s kind of a void report.

Laura: Yeah. Because I used to work as a pentester and during an assignment you have limited time as well, so you don’t always have to provide the proof of concept. Pentesters look at it from a wider angle and they can see white box, the infrastructure, the servers and so on. So for me, it’s interesting how impact-driven the bug bounty community is. It’s a good thing.

Bug bounty is a growing industry

Laura: Bug Bounties have become a big industry but it has also gotten some criticism or scrutiny over how many active researchers there actually are, like this Dark Reading article by Robert Lemos on how bug bounties continue to rise. But the market has its own 1% problem

It’s kind of like the same as being a professional in anything, like a professional basketball player. And I think that was also something that was said here in Lemos’ article that was most likely a quote from Mårten Mickos that not everyone is going to succeed. And then there’s a group who succeed are really, really good at what they do.

Fredrik: Right. A lot of people are drawn into what they see on Twitter and the media that bug bounty is a growing thing. People go around on these live events where it’s an open environment and everyone always finds something critical, which is true. But to get there, that’s the hard part.

A vast majority might not have a professional take on how to report vulnerabilities, and then it might be people like yourself coming from pentesting background without experience on the same style of reporting.

Laura: … And having all of them rejected.

Fredrik: That’s the thing, right? If you go in with the mindset of a pentester, then I don’t think you would grasp it well, and it probably would be a bit discouraging. And once you get the grasp of it, then you need it to beat the rest that are in the game with vulnerabilities that will be accepted. So I think it could be a steep curve to get into.

Laura: You have been active since 2013 so you’re well ahead of people who are only starting out now. What are tips you have for beginners when trying out bug bounties?

Fredrik: Learn by doing. Submit reports and see how it works, and when it works. There are a lot of good resources out there and streamers that speak about how to do bug bounty, and educate people on what to look for.

Laura: What do you recommend?

Fredrik: I’m going to be a bit biased here, and recommend our fellow coworker, TomNomNom. I also like STÖK, a Swedish researcher.

Anything that Bug Bounties aren’t good for?

Laura: What is something that bug bounties are not really good for?

Fredrik: It’s not a silver bullet to your security. It’s a nice addition to an already quite mature organization in terms of security. It’s the many-eyes principle meaning you have more people looking and trying to break something – and someone will eventually be able to do that. 

If you start a bit premature with doing bug bounties as a company, chances are that it will be a bad experience for researchers. For example, it sucks for me if I report a vulnerability and it gets flagged as a duplicate. I’m probably not the first one to be flagged as a duplicate.

Laura: Or if the companies are slow to respond?

Fredrik: Yes. It must be horrible for the company as well. They get an overwhelming amount of reports as they can’t act on it fast enough, so then it’s not nice for anyone.

Start with private and then slowly expand the scope and amount of people that participate in your program and have it as an addition.

Laura: It’s a good way of getting rid of those low hanging fruit and understanding what you’re exposing there?

Fredrik: No, on the contrary. The bug bounty community will find all of it. They will find the XSS’s. If you can’t fix the XSS fast enough, then you will have a problem.

Laura: You will have multiple reports on the same XSS.

Fredrik: Yes, you will. The best researchers tend to go for more creative vulnerabilities and you want them to be looking deep into your system and catching hard-to-find things.

Laura: Do you think that all companies get equal treatment from bug bounty hunters as well?

Fredrik: No, I don’t think so. It’s absolutely a monetary interest. There are more and more companies joining these platforms, and there’s a limited amount of researchers that provide value. So then you have to compete with other programs to have researchers look at your stuff.

Researchers like big scopes

Laura: We’ve had multiple takeaways for our listeners in this episode already, but do you have any like one big takeaway for our listeners?

Fredrik: If you’re a company, start small, then expand. Researchers love big scopes, so try to reach that eventually. 

If you’re starting off with bug bounty hunting, don’t give up too soon. It takes time and practice to get into this, but it’s not impossible. Anyone can do it. Really. It’s just problem-solving.

 

You’ll find the full video episode on the Detectify Youtube channel:


Did you like the highlights of this episode? Check out the full episode in the web player. It’s also available on Spotify, Apple Podcasts, Google Podcasts or another preferred podcast platform.

——

Keeping up with the fast-pace of web security is a challenge if you are only relying on standard CVE libraries and annual security checks. Detectify works with some of the best ethical hackers in the world to deliver security research and modules from the forefront of security, so you can stay on top of emerging threats. Interested in giving Detectify a go? Start your 14-day free trial today.