Hey listeners and welcome back to Undetected.
Thanks for all your feedback and comments
you gave us over Twitter at Detectify and
also by email Undetected@detectify.com. This
time I am here with Fredrik Almroth and we
are going to discuss one of the buzzwords
of this decade or the upcoming decade, which
is bug bounties and bug bounties are just
one facet of crowdsource security, but it's
a trend that we can't really ignore these
days and a lot of companies are taking part
of it, but what are bug bounties as in, what
are they useful for and what are they not
that useful for. This podcast is brought to
you by Detectify.
We are going to talk about all this with Fredrik
today, but before we get into that, I'd like
to share some details I've found about you
while stalking you online or your online presence.
So it seems like you've been onboard with
crowdsource security for quite some time.
And I found out that you were registered in
HackerOne already back in 2013. Is that right?
That's right.
Okay. And you're also one of the founding
fathers of Detectify. I was checking your
public HackerOne profile and it seems like
you have quite a bit of submitted findings
in there as well.
Yeah. That checks out.
Sounds familiar.
Yeah.
That's good. But I think most interestingly
you have in the past you've found findings
or vulnerabilities in Tesla's website and
in Google. But let's get back to that in a
second. But first, I would like you to tell
me why are you here today?
Why am I here today? Well, I'm a security
researcher and co-founder of Detectify and
as you mentioned, I do quite a bit of bug
bounty, which kind of correlates to how we
do things in Detectify. So I suppose that's
why I'm here.
But you had been interested or in security
for quite some time already.
Yeah. So it started already in high school
I suppose when I met my fellow co-founders
of Detectify. By that point we realized that,
well internet is quite broken. This was back
in 2006 when we first met. So by 2008 we decided
to start a consultancy business doing penetration
testing. But one thing led to another and
it started automate things and this idea kind
of grew. So we all went to university and
dropped out one after another. And by this
point, well 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 secretly
actions. And the cloud started becoming a
buzzword around here in Sweden. So we figured
why not make a new company doing something
else.
Yeah, that's cool. So the, when you first
got into security, back in like 2000 was is
eight?
Yeah, something like that.
So I...
Mid 2000.
Yeah. Was there a lot of like, well, I suppose
that the world was quite different at the
time.
That's right.
And we have taken like quite huge strides
when it comes to security in this just past
few years as well.
Yeah.
So how do you feel that automation, for example,
played into this?
I mean, for example, you can say that some
vulnerabilities come and go, secretly action
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 service
side template actions, it's basically the
same kind of injection attack state. They
come and go, but in different forms over the
years. So I don't know, it's more things now
that out on the internet, more services, more
technologies in general. It's a big web, that's
packed in.
Yeah.
So I don't know what to say. It's more things,
hence more things can break, but at the same
time, the vulnerabilities that exist back
then, it's not as common nowadays with the
exception of XSS.
Yeah. Yeah. So it has really evolved and the
hacks in general. And as I mentioned before,
the Tesla hack for example, is that that was
a cross site scripting attack. Right?
Right. So Tesla was, I don't know if they
still are, but they were running Drupal, one
of the biggest CMS systems and Drupal, they
bundle with this, what you see, what you get
kind of editor called CK editor and this library
it bundles with an example file. So using
this example file you could do a kind of drag
and drop XSS where, well it takes a few clicks
for an outsider, but you can drag something
that looks okay on one website onto some other
place and it will execute in Tesla's origin.
And then you have cross site scripting. So
what I demonstrated then was, well you can
play Doom on Tesla. So AAA is the entire window
with the game Doom in those sparks virtualized
in JavaScript.
Yeah. Okay. That sounds like fun. Couldn't
play Doom anywhere else?
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.
Yeah. Yeah. But that's a fun way to demonstrate
it. Also a bigger one. I would say a vulnerability
that you found previously, this was back in
2014 you found a XXE, X X E vulnerability
in Google. So that's external entity. What
is it sort of short for?
XML , external entity.
XML external entity? Yeah.
Yeah.
Injection. So basically you were able to run
your own code on Google server. So do you
want to elaborate what that means in this
case.
Yeah, so all right. They was, Mathias Karlsson
and I. Mathias is early co-founder of Detectify.
We were not that tight on cash by that point.
This was in the, I think it was late spring
and we figured bug bounty it's actually works.
We get some money from this. So what's the
most bang for the buck? What companies are
out there that we get most money for least
amount of effort? And we thought Facebook
or Google and we were like Facebook. That's
not very fun to target, to approach. So we
went for Google. And then we've found, or
our approach was really like we should find
the very 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 from, yeah, earlier
than that 2008 or something called the Google
toolbar button gallery. So if you remember
this way back in the Internet Explorer, you
had this toolbar from Google.
Yeah, I remember. Yeah.
Yeah. So it turns out companies could upload
their own buttons to this toolbar and that
was the feature we attacked.
Okay.
So, and this was an XML file uploaded to Google.
So which button in that?
Yeah, so I can't remember the details per
se, but you as a website owner could add your
own button to the toolbar so that other users
could find you. Something along those lines.
Okay. Interesting.
Yeah. And well this button definition was
an XML file and an XML is, quite frankly,
you can do a lot of weird things in a plain
vanilla XML file. One of them being an external
entities.
Yeah.
So what we did was we uploaded a file, we
gave it some name and description and things,
but we added this weird kind of, I don't know
what to say, a definition, that instructed
Google to try to read another file from their
local file system. So we tr ied to pull in
the see possibility, the normal user file
on Unix systems and uploaded it and it worked.
It was accepted. We're like, "Okay, did anything
actually happen?" So we, I mean you basically
got done okay, it's uploaded and that nothing
else. Like, "All right, so now what, what
do we do with this?" So then it made an other
attempt where we changed the title, because
you could search on Google for other buttons.
So the title contains some text like 'hello
world'. And I never searched on Google or
for toolbar buttons containing 'hello world.'
And the description then was contained the
contents of their possibility file.
Yeah. Oh, so you basically search for the...
So we searched our own thing that we just
uploaded.
Okay. So that's kind of like local file inclusion.
Yeah, that's basically the impact. So we got
read access on ....Google.com.
Yeah. Okay. That's, that's sounds quite wild.
And also an interesting feature that was there
back then by Google.
indeed.
Yeah.
So this was quite fun. So from Start to stop
took us like four hours, five days and exploited
and have it reported.
Yeah.
That's nice.
Yeah. If you're interested to hear more about
this, Google XXE, there is a blog post about
it and I will link it in the description so
you will find it there. But the interesting
thing is that, well were these all like basically
bug bounty programs or were they public programs
that you enrolled in or how did you stumble
across these?
Right. So this was about the time that we
actually founded Detectify and backbone to
start to becoming something you spoke about
on Twitter. So Google, in my world, that's
the first company I saw that had this kind
of policy, meaning anyone can hack Google
if they manage and Google accept it as a new
unique vulnerability. You get money for it
and afterward you can speak about it. So this
is pretty nice if you're an early stage startup
and they want some material to be seen and
heard.
Yeah, definitely.
So that's how it went. And this has been growing
ever since.
Yeah. How do you feel that people, especially
back in the day for you publicly spoke about
hacking Google or hacking Tesla like 2014,
2013 how did people react to that?
Yeah, that's a good question. Various like
people in the Valley, they know about this.
It's, that's kind of where it started this
entire industry. But over here in Sweden,
he was unheard of that this was even a possibility.
So a friend's friend of mine happens to work
in the Swedish police and I was telling him
like, "Oh yeah, I was stay in Singapore. And
I hacked the Dropbox." And he was like, "What?
You can't do that? That's criminal." I was
like, "No, no, no, you missed the point."
I'll to elaborate a bit on what it is and
so forth.
yeah. So the point is that it's not criminal.
I don't have to go to jail. Please don't arrest
me. When was this?
This was just a, I think one, one and a half
year ago.
Really?
Was quite recent. Yeah.
Yeah. It's interesting that...
I don't know.
Yeah.
Not too far ago.
Yeah, but people still like to these days,
maybe not like, I think in our bubble of infosec,
everyone knows what a bug bounty is or what
a responsible disclosure is, but maybe out
there like outside of this immediate bubble
of people, it is not that obvious what it
is. So can you tell me what is your short
description of bug bounties?
So bug bounty is really, it's freelance, the
penetration testing in a way. So anyone on
the internet can go to a company, find a vulnerability
and have a streamlined process of reporting
it to the company. And well, if it's a unique
vulnerability and you are the first one to
submit it, then you get some monetary reward
at the end. And that's kind of how it started.
And since then, there have come up some platforms
and marketplaces to facilitate this among
vendors and researchers like you know by crowd,
the HackerOne and Synack and so forth.
Yeah, yeah. So basically for a bug bounties
you can have a standalone bug bounty on your
own company website for example, offering
reward in exchange of or swag or something
in exchange of a vulnerability.
Right.
Or you have these spot firms as you mentioned,
HackerOne, Bugcrowd, Synack. Then there is
like bounty factory, open bug bounty hack
trophy, and like a lot of like different kind
of platforms who more or less operate the
same, right?
Yeah, that's true.
Yeah. So it's kind of like as you said that
your friend or your friend's friend who told,
thought that you were an absolute criminal,
how these bug bounties have basically lifted
hackers out of the darkness as well. And now
hackers can actually talk about what they
have found and they can disclose it and naturally
depending on the program, the rules on that.
But it's also shedding a more positive light
on hackers as a group of people.
Yeah, indeed. But I think it's quite important
to speak a bit about responsible disclosure
programs as well. It's basically the first
stepping stone in order to do something like
this.
Yeah.
It's just to have an email address or a contact
forum where someone can submit vulnerability
information. That's all it takes.
Yeah.
More often than not, you know it yourself
that there are vulnerabilities all over the
place, but it's can be quite tricky to report
it.
Yeah. Yeah. You don't always have to offer
swag or money.
Right, exactly. You just have a channel to
accept it.
Yeah. So there is, for example, the practice
of putting a security dot TXT file in your
domain so that people know, like you put the
contact information of your security personnel
there or then you can put info on your company
website.
Yeah. Exactly.
Do you think that, what would be the minimum
thing that a company should do in terms of
responsible disclosure?
I think get a security as a very good starting
point. Have that set up a security@company.com
email.
Yeah?
That's it really.
Yeah.
That's a good starting point.
Yeah. So you don't need to go on HackerOne
and open bug bounty program there?
No, I think that should come a bit later once
you have matured your, well yeah. So you know
what you get basically. It can be quite overwhelming
I would assume if you go directly to one of
these platforms, open a bug bounty publicly
to the world, everyone will start reporting
straight away.
Yeah. So do you think that there is like,
well there's the open programs or the public
programs and then there's the private programs,
but do you think that a company who enlists
in a public program will get tons and tons
of reports right from the get go?
Yeah, I think so.
Yeah.
More in the beginning and then it should probably
slow down.
Yeah. So it would make sense then to do some
kind of security assessment before that?
Yes. I think you should only start with responsible
disclosure. Once you've had your pentest reports,
some automated scanning and you should have
an organization that is able to handle the
security reports.
Yeah.
Only then do something like responsible disclosure
or a private bug bounty program and only after
that make it public.
Yeah. Let's say that you are relatively mature
in terms of security as a company. Do you
feel that bug bounty platforms or not even
platforms, but bug bounties, are all of the
companies out there?
Yeah, I think so. As long as you have some
kind of online presence, it would be hard
otherwise. Then again, if you are a manufacturer
of hardware for example, it's becoming quite,
I don't know, it's growing at least with IOT
vendors for example, open up in, I'll have
bug bounty programs and so forth as well.
Yeah.
But I don't know, it has to be something technical.
It's quite hard to have a bug bounty otherwise.
Yeah. I'm just trying to think of something
that would be, so like that wouldn't have
an online presence these days like you would
have.
Everything have, right?
Yeah. Everything has at least like a company
website. If nothing else.
Exactly. You always have something that's
important to your business and you can probably
make a bounty program around that. What are
you trying to protect?
Yeah.
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.
Yeah.
A bank probably the money.
Yeah, and just the online banking and everything.
Yeah, so then it doesn't really matter if
it's say a website or that one domain. That's
the scope for your program. You should really
try to think about this. What am I trying
to protect and then make a policy thereafter.
Yeah. Do you, you mentioned just a scope,
so a scope in a bug bounty program is defined
by the company and they are basically stating
that, okay, this is basically in scope of
the program, so it can be a domain or source
code or some device.
Yeah, it can. It's usually along those lines.
It one or several domain names can be mobile
apps, GitHub repositories, if it's a hardware
manufacturer, could be their devices to sell
to consumers, for example. It's a lot of blockchain
compensator that would be attacking the blockchain
technology itself.
Yeah. What do you feel is the best scope for
you as a tester?
For me privately, the bigger scopes, the better.
So it's quite a, I mean, being our security
researcher, you, you have a bit of an arbitrage.
The more things that are exposed and that
you can, well audit, the more things will
break, as simple as that. So the bigger company,
the easier it is in my opinion, at least.
So more or a bigger scope means more critical
vulnerabilities and that's more business impact.
So it will help you as a company even more.
So what happens if you go outside of a scope
in a bug bounty program?
That really depends on the organization. I
mean what really matters if you have a bug
bounty program is the business impact that
an outsider can have, right?
Yeah.
So unless something is explicitly out of scope,
it could be fine to report a vulnerability
if it really have impact.
Yeah.
That's my take on it. Although that could
also be considered scope creeping if you are
on one of these...
What was the word?
Scope creeping.
Scope creeping. What does that mean?
I mean you kind of, you go a bit out of scope
and in again.
Okay, so.
Yeah, exactly. More often than not, that's
usually more accepted on these live hacking
events. So if one of these platforms, they
collect a group of people in person to hack
a company over a day or two, then usually
more accepted than if you are to do it right
now. You find something on, I don't know,
Adobe and you go outside to some local subsidiary
or something and then back into scope.
Yeah.
That's not usually that good.
Maybe live hacking events, the overall environment,
it's more easier to control than hacking inside.
Yeah, then you have all the stakeholders at
one place they can communicate about it.
Do you feel that some security researchers,
for example, do not report something if it's
out of scope, but, and if it's not that critical,
for example.
I 100% I really believe so. So open redirects
for example, it's no longer on the OWASP Top
10.
Yeah.
But having an open redirect somewhere on some
sub domain that might be explicitly out of
scope and you're, and you know it's there.
I at least wouldn't report it.
Yeah.
With the risk of losing a score or a reputation
or whatnot on the one these platforms.
Yeah.
But at the same time if they have O off and
misconfigured, I can use it to well do some
kind of authentication bypass or in some sensitive
tokens that's a different story. Then all
of a sudden you go out of scope, wanted to
go in again and you might have an account
takeover and that would be usually considered
critical.
Yeah.
And that companies would accept.
So it really depends on the impact as well.
Yeah.
If you can demonstrate the impact and I think...
Exactly. That's, I think that's the moral
of the story. It's the impact that matters.
Yeah. Any bug bounties. Yeah. It's always
the...
You need a proof of concept. Otherwise it's
kind of void report.
Yeah. Because I used to work as a pen tester
so for a pen tester you basically, you have
such limited time as well, so you don't necessarily
always have to provide with the proof of concept
and also pen testers, maybe they look at it
from a kind of wider angle and they can like
see white box and see the infrastructure and
the servers and so on. So it's interesting
like how I would say impact-driven bug bounty
community is.
Really.
It's a good thing naturally as well.
Yeah.
Yeah. And speaking of bug bounties, it's,
it is a big industry like in terms of the
platforms and everything, but it has also
gotten some criticism or scrutiny over how
many active researchers there actually is.
So there's a lot of people who sign up to,
for example, HackerOne but never submit a
report, for example. So I found this, this
was written in Dark Reading by Robert Lemos,
I don't know, maybe butchered the name there,
but back in 2019 in August, he wrote how the
bug bounty, how bug bounties continue to rise.
But market has its own 1% problem. So he's
basically stating that the more, more than
half a million hackers have signed up for
HackerOne manage the challenge, but only 5000
are really doing well. And this was actually
a quote from Mårten Mickos who is the CEO
of HackerOne. So it is quite a well known
fact that a lot of people sign off to these
platforms and try them out, but don't necessarily
get any money out of it. Right?
Yeah. That I believe is true.
Yeah. And he's kind of like, I think it's
a lot of these bug bounty hunters, they get
a lot of coverage in like Twitter or in media,
but 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 Robert Lemos's
article that was most likely a quote from
Mårten Mickos that not everyone is going
to succeed. And then there's the people who
succeed and then are really, really good at
what they do.
Right. I don't know what to add to that. I
think it's true. A lot of people are drawn
into the, well they see on Twitter and in
media that this is growing, this is a thing.
People go around on these live events and
it's an open environment and everyone always
finds something critical, which is true. But
to get there, that's the hard part.
Yeah.
So I think a vast majority might not have
a professional take on how to report vulnerabilities
and then it might be people like yourself
coming from pen testing background, you submit.
And having all of them rejected.
Yeah, that's the thing. Right? So if you go
in with the mindset of our pen tester, than
I don't think you will do very good. It's,
it will probably be a bit discouraging and
only once you get the grasp of this, then
you need it to be built the rest that are
in the game. So I think it could be, it's
quite a steep curve to get into. Well actually
getting some vulnerability and then have them
accepted.
Yeah, and having to compete with like people
like you who have been around from 2013 for
example on HackerOne and like on other platforms
as well. So it's kind of like you were, you're
well ahead of people who are already starting
out or only starting out now. And even though
there is a way of making money out of these
platforms, even though you've started just
now, but it's still like, I think it needs
kind of like, is it good, good to remind people
that don't be disheartened when you try out
bug bounties?
No, absolutely not. I mean, learning by doing.
Submit reports and see how it works and when
it works.
Yeah.
Yeah. There are a lot of good resources out
there.
Yeah.
There are a bunch of streamers now coming
up.
Yeah.
Well, you know, speak about how to do bug
bounty and educate people on what to look
for.
Yeah. Do you have any specific recommendations
for our listeners of the resources that they
should go for?
I'm going to be a bit biased here. I going
to recommend our fellow coworker, Tom.
Yeah.
TomNomNom .
Yeah.
And also Stök, Swedish researcher.
Yeah.
Yeah. I liked their streams. They're good.
Yeah. I'm going to add links to their material
in the description. So if you want to look
it up then you can after the show or even
right now if you want to. We have had now,
quite a long discussion what bug bounties
are and what they are good for and how companies
should basically think of them. So do you
have something in mind that would be something
that bug bounties are not really good for?
Not good for. I mean, we kind of touched upon
it. It's not a silver bullet to your security.
Yeah.
It's a nice addition to an already quite mature
organization in terms of security. I mean
it's the many ice principle.
Yeah.
More people looking and trying to break something
and someone will eventually be able to do
that.
Yeah.
And that's, I think that's what bug bounty
really brings to the table.
Yeah.
If you start a bit premature with doing bug
bounties as a company, chances are that it
will be a bad experience for researchers.
It sucks for me, for example, if I am to report
a vulnerability and it gets flagged as a duplicate,
chances are I'm not the first one to be flagged
as a duplicate.
Yeah. Or if the companies are slow to respond
for example.
Yeah. I mean it must be horrible for the company
as well. They get the overwhelming amount
of reports as they can't act on it fast enough,
so then it's not nice for anyone.
Yeah.
So I think you should be a bit careful with
that.
Yeah.
Start with private and then the slight slightly
expand the scope and amount of people that
participate in your program and have it as
an addition.
Yeah. Yeah. So it's basically a, to put it
in other words as well, it's good way of getting
rid of those absolute like low hanging fruits
and understanding what you're exposing there.
And...
No, on the contrary, I believe the backbone
to community, they will find all of it. I
mean they will find their XSS's. If you can't
fix the XSS fast enough, then you will have
a problem.
Yeah. You will have multiple reports on the
same XSS, yeah.
Yes, you will.
Yeah.
And the best researchers, they tend to go
for more creative vulnerabilities, you know,
hard to find things down in your system and
that's where you want them to be looking.
Yeah.
I mean.
Do you think that all companies get equal
treatment from bug bounty hunters as well?
No, I don't think so. It's absolutely a monetary
interest. There are more and more companies
joining these platforms and I mean there's
only that many researchers that provide value.
Yeah.
So then you have to compete somehow to have
researchers look at your stuff.
Yeah, definitely.
I mean there are various ways you can have
like campaigns one over these two weeks you
pay more money for example, or you send away
a T-shirt if for an accepted report, like
you do a bit of gamification that usually
brings attention.
Yeah. And I think some bug bounty hunters
are there. They're just like, it's not their
livelihood and it's more like a hobby. So
they are up for our challenge either way.
Yeah, right.
Yeah. So I think we had multiple takeaways
for our listeners in this episode already,
but do you have any like one big takeaway
that our listeners could take with them after
this episode?
One big, I don't know if you're a company,
start small, expand. Researchers love big
scopes, so try to reach that eventually. If
you're starting off doing bug bounty, 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.
Yeah, that's nice. And yeah, to all listeners
out there, don't be disheartened and keep
going on with your bug bounty adventures.
Thank you for listening to our episode and
feel free to drop us any ideas, questions,
or thoughts at Detectify, Twitter account
or undetected@detectify.com email. Thank you
for tuning in and catch you next time. Bye
bye.
Bye.
