Cloudflare TV
On Air
Schedule
Shows
No results were found
Powered by Stream
Making the World Better by Breaking Things
Share
Copy Link
Email
Facebook
LinkedIn
Twitter
Start at
Originally aired on
June 13, 2020 @ 8:30 PM - 9:00 PM EDT
Best of: Internet Summit 2017
Ben Sadeghipour - Technical Account Manager, HackerOne
Katie Moussouris - Founder & CEO, Luta Security
Moderator: John Graham-Cumming - CTO, Cloudflare
English
Internet Summit
Transcript
(Beta)
This is a test. This is a test. This is a test. This is a test. This is a test. This is a test.
This is a test. This is a test. This is a test. This is a test. This is a test.
This is a test. This is a test. This is a test. This is a test. This is a test.
Hello! All right, roll out, roll out.
We're going to talk a little bit about hacking, and in order to do that, I've got some people who know what they're talking about.
So right next to me is Katie. Katie is the founder and CEO of Luta Security, which is a company that helps people understand how to handle the process around vulnerabilities, which, of course, everybody's worried about.
But she also created something called Hack the Pentagon and helped the U.S.
Department of Defense understand how to interact with hackers to improve things.
And she created Microsoft's Bug Bounty program and their vulnerability research program.
Ben is technical account manager at HackerOne, which is a very popular bug bounty service, and he's also a hacker at night.
I'm going to talk about that.
To give you an idea of his hacking career, he's found over 500 security vulnerabilities in hundreds of web and mobile apps for Yahoo, Airbnb, Snapchat, the Department of Defense, Yelp, GitHub, and more.
So we're going to have a bit of chat about these subjects.
The title of this was about breaking things to make the world better.
So I'm going to start with you, Ben. You say you're a hacker by night.
What is that, and isn't that illegal? So, you know, I think it depends on who you ask, but if you ask people that encourage hacking the legal way, it all comes down to who you are and what you do it for.
For people that are like me, who participate in bug bounties, or the ethical hackers, what we call them, or white hat hackers, we mainly do it for a good reason.
So hacking could be illegal if you're going and doing something that's illegal and hacking without permission, but for my case, I'm working with companies that are allowing me, they want me to actually hack into their web applications or get into their infrastructure.
So you have a job, and you go home, and then you say goodbye to your family, and you sit down and you stay up all night, is that...?
Yeah, so I lock myself in the room in the basement and put my hoodie on, and I start typing really fast.
Do you have gloves on? Do you wear gloves to type? Yes, all black. All black.
And I have to make sure the hoodie's on, I'm typing very, very quickly.
Now, if you're not wearing a black hoodie, it doesn't count. That's why I'm no good at it.
Okay. Katie, why don't you tell us about Hack the Pentagon? That also sounds like something a bit suspicious.
How did that come about? So Hack the Pentagon was an interesting development in the world of vulnerability coordination and bug bounties.
I was first invited to brief the Pentagon when I still worked at Microsoft, and they were very interested in the very first sort of old -fashioned software company taking up this new idea of bug bounties, which wasn't actually a new idea, right?
Netscape had been doing it for 20 years. But the adoption of bug bounties was really slow, and so the Pentagon was interested in the implementation of this idea in a very large, complex organization like Microsoft.
So they invited me to brief them. And then over a series of meetings over time, you know, for a while I was policy officer at his company, you know, we just furthered the conversation.
Then when the Secretary of Defense had stood up something called DDS, Digital Defense Service, he was very keen to have a visible win in the space of bringing some of the best, you know, ideas from the private sector and implementing them in the Pentagon.
So I remember helping the internal team at the Pentagon answer a bunch of questions.
Won't the hackers just hack us and hold on to the vulnerabilities and not tell us?
Guess what, that's what they're doing right now.
You're already getting a free pen test, you're just not getting the report is the common quote, right?
What if, you know, what if, well, the funniest resistance was, well, fine, we're going to do it, but there's absolutely no way on earth we're going to call it hack the Pentagon.
That is out of the question, never going to happen.
But, you know, the whole impetus and the movement in this space was really around trying to engage with the hacker community, trying to provide a legal avenue, as Ben was talking about, a legal avenue by which for the first time, you know, it was legal to report, you know, if you see something, say something, right, to the Department of Defense.
I also think it was very important for it to be arguably the largest and most powerful military organization the world has ever known, admitting that even with all of its boundless resources, it could not necessarily find all the bugs.
And that was a very important kind of distinction.
It kind of gave everybody permission to say, yeah, me too.
And actually he was one of the people, right? Yes, you were one of the hackers.
Yeah, I actually got to legally hack into some of the military websites that are owned by the U.S.
government. And if you go back even two years ago or three years ago, that would have been a surprise to be able to say, oh, yeah, I'll hack the government.
You wouldn't hear people openly talk about it. But now it's a gift that I can actually go and work with these military websites.
In other words, they hacked the Air Force, hacked the Army, and they hacked the Pentagon.
And the Navy? Has the Navy done it yet? That's something we don't know yet.
So I got to interject one fun story. So the coins, you get challenge coins if you are a successful hacker.
So the hack the Pentagon coins had a little binary around it that said, I hacked the Pentagon, right, when you translated it.
So when we were about to launch hack the Army, then Secretary of the Army said, oh, for our coins, could it say beat Navy around, right?
And it did. And they did. So, I mean, the power of hacking is incredible, right?
But you mentioned something interesting, which is that what you're doing is not illegal, but there are laws against this type of behavior.
So let's talk about that. How does that work? Because it's kind of a gray area, but somebody's inviting you to hack something.
How are you not breaking the law?
So typically with these kind of programs, there are expectation sets in the beginning.
So they explain to us what the rules are, what we can do and what we can't do.
And as long as you stay on this side of the line, when you actually are following the policy and you're not doing anything malicious with the vulnerabilities that you find, then you'll be perfectly fine.
You're not weaponizing this against anybody or against anybody's data.
So you'll be okay as long as you're following all the instructions and all the policies that they have set with you in the beginning.
Is that typical? That's what the line is?
It's you're not exploiting it or you're not revealing it? So it comes to a little bit of a gray area, because often you'll see these scopes say, describe the vulnerability, steps to reproduce it, and then the potential impact.
When you get to that potential impact question, that's where typically your well-meaning hacker will actually go out of scope.
Because they will start trying to use what they found in bug number one and essentially increase their access.
And so you end up with some conflicts. We've seen some of it played out in the public sphere with opportunities to clarify the scoping rules, let's just say.
But it tends to go differently when you're a nation state versus a private company.
So obviously in the United States, private companies would be governed under computer fraud and abuse acts.
That is the thing that you're essentially giving permission to the hacker when you're setting up either a vuln disclosure program or a bug bounty program.
You're giving permission. You are providing that authorization.
But that's only authorization in the civil sense. Technically, there's still a felony crime that could be prosecuted, even without the quote unquote victim cooperating.
We've actually seen some of these cases play out.
But when you're thinking about it from the Department of Defense, what do you actually need to preserve in the legal language of the scope?
You need to preserve, while you're giving permission for wonderful, good-hearted white head hackers to go into their basements for you and come up with all the bugs.
While you're giving that permission, you need to preserve the ability to go after a nation state, criminal actor, or any other bad actor.
It is a different kind of equity that you have to keep in mind when you're creating the legalese.
That was part of the work that I did with DOD and the Department of Justice in helping them formulate that ongoing policy.
It's what I do now with the UK government as well, in mapping it to the UK-specific laws that are very, very similar to the laws we have in the United States.
But it's preserving that litigative power while giving that permission that's important.
All right. Ben, let's just talk about bug bounties themselves.
First of all, some people in the audience won't know what that is and how it works.
Do you want to chat about that and tell us about how it works? A short description of a bug bounty would be pretty much allowing hackers to hack on your programs and having an open communication line with them.
So whether you're doing it on your own, you're doing it platform, it's just taking that step to allow hackers to legally be able to look at your web application and find flaws in them.
And some of this is financial reward, right? So you'll get paid if you find a vulnerability in Facebook, they'll pay you some money.
So there's a market for this stuff out there.
Who's competing in this market? So we do hear talk about the black market for vulnerabilities and exploits.
I dislike that term. I prefer the offense market because those vulnerabilities and exploits are actually being purchased in order to be used for offensive purposes.
They can be used by nation state, criminals, etc.
But the big factors there is that it's the highest prices are usually in the offense market.
But it's not just that they're paying for this expertise or the work.
What they're actually paying for is the longevity of the bug, meaning they're paying for silence.
So when you're thinking about it in terms of what a hacker might do with a vulnerability that may be very valuable on this market, they're not necessarily operating like we want to sell it to the highest bidder.
All of us have a mix of motivations, right? It's not just money. For hackers, I call it compensation, recognition, and pursuit of intellectual happiness.
Can they get all three? Well, that's where the defensive market, the bug bounty market, comes into play.
The defensive market tends to be lower paid, and there's actually a good reason for this.
There is a logical ceiling above which defensive bug bounty prices cannot exceed.
Otherwise, you create perverse incentives.
So where I hear the play on the markets, it drives me nuts because I've been thinking about this for a long time.
We did some system dynamics modeling with MIT Sloan School on these markets.
Price is not the competition factor. You will create a situation if you bump your bug bounty prices too high where you cannot afford to employ the people to write new software and fix the bugs.
Think about if your QA engineers could make $200 ,000 a pop for something that you pay them a regular salary for, you are going to run out of QA engineers real fast.
So there is that logical ceiling, and there's different things that these markets are paying for.
So what I look at is how do you actually find different levers than just price?
Okay. So, Ben, you do hack things. So what was your motivation for getting into that in the first place?
The first place I went was just curiosity. I was curious enough to understand how things work and how I could possibly break them.
The second thing was to be able to actually help. I mean, for me, it was mostly, like she said, it was the happiness of knowing that I could make a change, make a difference.
And the third one, again, is the money aspect of it. You see people, there's hackers out there that are just focusing on doing bug bounties full-time and making a salary out of it without having a daytime job.
I personally went through that for a year myself when I actually put myself out of college for the last year of my studies where I just did bug bounties for the entire year, and I just supported myself with doing that.
So that was a good indicator that this whole bug bounty thing, being a white hat hacker, is actually working out for me.
Okay.
So there are people like Ben out there who we could probably get access to with the right bug bounty program.
How do we go about creating one if we're a company that wants to do that?
Well, you know, my company now, I joke, but it's true, I prevent premature bountification.
In a lot of organizations, they come to me and they say, we want to do a bug bounty.
And I say, that's great. How many bugs do you normally handle during your regular vulnerability disclosure process?
And they say, we've never had a bug reported to us ever, you know?
And I say, that's lovely. So picture Lucy and Ethel in the chocolate factory, okay?
They are about to have a flood of wonderful, delicious chocolate bugs, and they are going to run out of places to stuff it.
So how do I approach this? I make sure that all the Lucys and the Ethels have as much automation on the back end, and that there are more efficient ways than necessarily starting a bug bounty program to discover vulnerabilities.
I mean, if you think anyone a fan of G.I. Joe, knowing is half the battle, right?
The other half of that equation is how do you fix it, and then how do you wrap that back in such that you're making fewer of those mistakes in the future, incorporate the knowledge into your software development life cycle.
This is much more than how you found out about the bug, right?
So that's it. When companies or governments come to me and say, we're ready to do this, I kind of take them through a maturity model exercise, for lack of a better term.
And isn't there also a question of how do you motivate the right hackers to work on your thing?
Because what I've seen with some bug bounty things is you say, I've got this bug bounty, you get a lot of low -hanging fruit reported to you, which takes time.
It gives you some benefit, but maybe the real thing is actually very hard to find.
So how do you find the right hackers? That is a great question. So everyone has heard, you know, with open source, many eyes make all bugs shallow.
Well, then how do you explain Heartbleed that was sitting in the code for two years in a popular, highly deployed, and essential, critical library in open source?
There are so many more examples of this. So how do you attract skilled eyes and focus them on exactly where you want?
And that was kind of the basis of, you know, the first bug bounty programs of Microsoft.
Microsoft was already receiving over 200,000 non-spam email messages a year coming to secure at Microsoft of people who were trying to report vulnerabilities for free to the biggest software company in the world.
So they didn't suffer from a lack of eyes. They were suffering from how do we get those right eyes focused on our problem?
And so, you know, we use different market dynamic tactics, timing tactics, things like that.
I could spend an entire however many minutes we have left talking about it, but it was about understanding the markets, understanding the behavioral economics at play as opposed to just looking at it like we just need to gauge how much, you know, this particular thing is worth, and we'll set a price tag, and we'll hope for the best.
Ben, when you think about what's recently happened to Equifax, having yourself broken into a lot of things, obviously we don't know the details of what happens there, but I think they are an example of a class of companies who are online but aren't necessarily super technically savvy.
What can people like that do to protect themselves from people like you?
That's a very broad question. We have 13 minutes.
So for me, essentially, the stuff that I look for with Equifax, it's a huge attack surface.
They have a bunch of properties. God knows how many of them are out there.
For me, it's one of the most basic things I look for are unpatched websites or products that have known vulnerabilities, and the second one is looking for default settings or default credentials.
So those two alone, as we have heard in the media, could be one of the two reasons that Equifax got hacked.
We don't know if that's the case, but there are predictions that that could be one of them.
So for me, it would be having the process, like we mentioned, having the process of actually keeping these things updated, eliminating if they're not being used, or actually changing those settings from default to something that's fit for the company in a secure way helps get the basics done.
As soon as you say that, because one of the things I've noticed is that in a lot of things that get broken into, it's not a super sophisticated, amazing hack done by geniuses.
It's actually that the company didn't update their software and are using a really old version, or they had a terrible password on things.
That seems to be extremely common.
Do bug bounties help with that kind of thing? Do you get people who will help you just figure that out?
And are there better ways than bug bounties? Would bug bounties help with that?
Yes, but it wouldn't be the only solution. I could use an example with bug bounties that Equifax isn't the only one that's probably had default passwords and unpatched services.
With bug bounties, hacking on some of the programs that I've hacked on, I see that happening on a regular basis.
When in passwords like admin, admin work, or maybe if it's an instance that has default passwords, the default password has been sitting there for years and no one's bothered to change them.
So with bug bounties, find those, possibly, if the hackers are allowed to go within that scope of the work, if they can actually access those systems.
But they shouldn't be the only solution to that. Right. And we talked a little bit before that, when we talked about bug bounties, you said there's other things, right?
Bug bounties are one of a number of tools you could use.
So what else? How else can I get hackers to help me get stronger? Well, there's getting hackers to help you, but what I was talking about, what I was alluding to earlier, is that no matter how you find out about the bug, so whether it's a bug bounty or some other mechanism, maybe it's a customer reporting it to you.
Maybe it's an agency in the government reporting it to you.
Maybe it's somebody in your supply chain, a partner.
Wherever you learn about the vulnerability is not necessarily the hard problem to be solved in this whole equation.
But to your point, if you're seeking external sources that are not under contract or other partner relationships, etc., if you're looking for that, there are a number of different ways that you can approach this.
A bug bounty is one. But if a bug bounty shows a ton of low-hanging fruit, guess what?
You probably could have had an intern run the same free tools that the bug bounty hunters outside just ran for you, and that would have been a much more efficient use of that money.
Plus, you've got an intern. Yay!
And you can have them do all kinds of server maintenance and coffee and stuff. But yeah, there are more efficient things that you can do, but in a lot of ways, a bug bounty is very useful in giving you a quick snapshot.
Sometimes it's deliberately used as a shock to the system, right?
Deliberately, where you're getting the pentest reports, you're seeing the same vulnerabilities, but as a professional pentester in a previous life, we would struggle with convincing people that it was likely that someone was going to find it and exploit it.
So that's one way a bug bounty is actually kind of useful, because you let loose the bug hunters of war, and you can prove a point that maybe you were trying to make internally, that yes, we knew about some of these vulnerabilities, the likelihood of them being discovered by somebody else, now we know that for sure, because we did this bug bounty.
So companies were deluding themselves, basically. They were thinking, we know there's a problem, and no one's going to find that, it's too complicated.
Well, or what is the likelihood? I mean, if you think about it, there is an inundation of bugs that we all have to deal with, right?
That we all have to deal with, even if we don't create software.
We use software, we deploy software, so there are going to be bugs that affect us, even as consumers.
So how do you make the decisions of which ones you fix?
How do you, as a consumer, make a risk-based decision on letting the reboot happen that will upgrade your personal system or your phone, et cetera?
You make those decisions all the time. Corporations and governments also make those kind of risk trade-off, functionality trade-off decisions around their bugs.
Because bug bounties can sometimes help focus them on the things that are most likely to get triggered and help them, you know, kind of reconfigure where they're putting some of those fixing resources.
I think a lot of people hear in the news that something was hacked by the Chinese or the Russians.
And actually, during the presidential debates last year, I thought Donald Trump put it quite well that it could also be, you know, a guy in his basement doing it.
People laughed about that, but there was some truth to that. So who is hacking things?
Is it the Chinese and the Russians? Everybody is hacking everything.
And the way that I remind people, especially when it was du jour to blame, you know, China, et cetera, you know, now it's du jour to blame everything on Russia.
We got the word espionage from the French. So let's just not forget about the fact that everybody is spying on everyone.
Hacking is just a new tool in the espionage toolbox.
So let's just put it in perspective for what it is. Everybody is hacking everyone, yes.
We just happen to have our own equities that we need to protect along with our allies.
And also, on one of the earlier panels, they were talking about the kind of the...
There's an information imbalance between some countries.
So North Korea is rumoured to have actually a team of hackers, and they have almost no connectivity to the rest of the world.
So you can't go the other way and hack them very easily.
I wonder if there... You know, if you think about spying as being the second oldest profession that's always been around, it seems like hacking must have been around for a very, very long time.
You know, it's never going to go away.
We need to engage with hackers. If you were to say to somebody, look, you've got a business which is online, because every business is online now, how do I protect myself?
What would be your advice? You know, I'm completely new to this.
What do I do about protecting myself from this world of people?
As a business? Yes, as a business, yeah. I mean, I can't emphasize enough nailing the basics, right?
I mean, we've seen this over and over again. So we keep talking about vulnerability coordination, right?
And the act of a bug being found and a vendor fixing the bug.
What about that fixed deployment? What just happened with the WannaCry ransomware?
That was a fixed deployment problem. So were the original worms that ripped through the Internet.
Blaster, Slammer, those patches existed, and they hadn't been applied yet.
So those worms just started ripping through, and we're seeing this resurgence again.
So how do we deal with that as a company?
Nail the basics. Figure out your patch management strategy, your risks and trade-offs, and then figure out the regulatory environment in which you sit.
And ideally, you're able to put mitigations in place when, for example, if you're in a highly regulated environment, you have to perform a number of different deployment tests before you're allowed to deploy that patch.
So it gets complicated for you.
What are your mitigations to protect you from the next, you know, kind of WannaCry or whatever broad spread ransomware wormable thing while you're in this highly regulated environment?
So it depends, but nail the basics is my advice. Okay, we're going to get very close to having some questions, but Ben, I wanted you to just give the audience a sense for what it feels like to hack into something.
It feels great.
It's a great feeling to be able to figure things out blindly, going into an application that I've never used before, never interacted with it, and trying to figure out what it does, how it works, and how you can eventually break it and abuse the things that are already built into the application itself against itself.
And we can see the motivation on your face there where you smile about how nice it is.
All right, let's take some questions from the audience for Katie and for Ben.
One over there. When I buy a car, I can look at the ratings from the Insurance Institute for Highway Safety.
And if I see a five-star rating, it doesn't mean I will be entirely safe, but it means that I'm less likely to be killed in the event of my car is in a crash.
Is there any prospects for an Insurance Institute for Computer Security where if I see a five-star rating, I know the company is more likely to have software that has better security than software with a four -star rating?
Gosh, wouldn't that be a great world? I would love that world. No, I think there's been some talk about doing...
What is it? Yeah, the... You just said it.
Yes, the CyberUL. So essentially those consumer-type ratings, right, for quality, et cetera.
It gets very complicated very quickly. So just the element of counting bugs, as an example.
Do you count one bug, you know, root cause bug as one bug, where there are several vectors to exploit that bug?
Are those all different bugs?
I mean, just the element of how do you... The taxonomy, how do you count?
How do you rate? And then let's say you had a perfect rating. What does that mean?
It's just a snapshot in time. And then, you know, that product, as new vulnerabilities are found and new exploitation techniques are discovered, so previously unexploitable vulnerabilities are now exploitable, how do you deal with that product with the five stars slapped on it?
It is different. And good God, when it is our toaster, I'm just going to have a dumb toaster.
That's my solution to that problem.
I agree with that. Stupid toaster. I agree with that. Are there other questions from the audience?
Okay, there's one over here. Can you re-explain the difference between the offensive market and the defensive market?
I could. Offense market is essentially the purchasing of vulnerabilities or exploits in order to use them for an attack.
This can happen at the nation state level, criminals, et cetera.
The defense market are things like bug bounty programs, right?
So things... Or third-party vulnerability acquisition services like ZDI, the Zero Day Initiative, where they have a protection product.
So essentially, I define them by their use case.
What are you buying the vulnerability for? And then you have other characteristics like who is buying them and you have other characteristics like the prices.
So I can talk to you more about it later. All right.
Are there any more questions from the audience? Yes. There's one right here. Pass, pass.
So it seems like a lot of policy and regulatory aspects to this problem.
If you're a voter who has a potential to influence their local politicians or the government or vote for policies that kind of make all this better, is there anything in particular we should be looking out for or asking about when it comes to these regulations and policies?
Yeah, so there was a recent proposed bill that DHS should run a bug bounty.
I am opposed. You should be too. The reason for this is that that smooth duck that you saw floating over the Department of Defense's hack the Pentagon, there were a lot of activities going on under there that were not just preparatory but actually during the execution that made it go that smoothly.
You cannot legislate a smoothly running bug bounty program.
And so what I worry about is that it is, you know, it's very alliterative as a marketing term.
You know, I'm partially responsible for this. I'm so sorry, you know, of popularizing that one element, that one method of acquiring vulnerabilities.
What I worry about is I see these regulators thinking that everything is now a hammer that can be hit by a bug bounty nail.
And so absolutely, so that's one.
And then another is there are some proposed legislations that are going right now about wanting to know an ingredient list of all of your software before the federal government buys software with no, you know, basically trying to prevent the federal government from buying software with known vulnerabilities in it.
Now take that to its logical conclusion. A manufacturer of a submarine or an airplane now will have to not just know the ingredient list of every subcomponent, but they're supposed to basically somehow produce this in order to do procurement.
Complex, unwieldy, not practical. Sounds great, but it's the same thing as the five stars.
It's that same concept of this is going to be very, very difficult.
So what should you keep your Congress folks in tune with? Just, you know, essentially putting pressure on them to make smart new technology and policy choices, not necessarily the ones that sound great because they saw, you know, a news article in Politico that said it was great.
All right, Ben, Katie, thank you for keeping us safe by breaking things for us and telling us how to engage with hackers.
Thanks so much. Thank you. Thank you.