Course Overview

Course Overview

Welcome to this Play by Play with Pluralsight. A Play by Play is a course where we sit down
with an expert and take on a technical challenge in real time. In this Play by Play, we sit
down with security expert, Troy Hunt to discuss some of the highest profile hacks in recent
history, including TalkTalk, Ashley Madison, Sony Pictures, and Nissan. We discuss the
hacks, we explore the mechanics of how these exploits happened, and discuss ways that we
as security professionals, developers, and admins can mitigate these risks in our own
environments. This course is the perfect supplement to Pluralsight's Ethical Hacking series
where you can dive deeper into each of the topics we discuss. Whether it be criminal, in
capital gains, or hacktivism, our apps, networks, and data are under attack. Join us as we
learn from the misfortunes of others to help improve our own safety in this digital world.

SQL Injection: TalkTalk

Introduction

Well I'd like to welcome back Troy Hunt, independent security expert, Microsoft regional
director, MVP and, of course, Pluralsight super-author. So Troy, thank you for joining us
today. Thanks Gary, good to be back. So, in today's play by play we're going to approach
things a little bit different. We're going to talk about all the fun that's going on in the news.
We figured it was a good time, now that we've wrapped up the certified ethical hacker series,
so now say, okay, you know what, there's all these high profile hacks going on out there.
How do we actually think about these as security professionals, as admins, as developers?
What are the things that we should be learning from those other high profile hacks, so they
don't happen to us? And maybe what are some of the techniques that we can use to help
mitigate those risks? I mean, let's just sort of start off, and maybe at a high level share what
you're thinking about discussing with us today. Yeah, so look, like you say, I mean it's a good
time, right? We've wrapped up this ethical hacker series, this mammoth piece of work which
is now complete. And at the same time we've seen, even since we last did a play by play,
probably only about seven or eight months ago, there's been so many other events that have
happened online. And I thought now's a really good time to sort of do a combination of take
some of these events that are happening, that are fairly recent, put them in the context of
some of the things that we've done in the ethical hacking series. So you know, we'll pick like
SQL injection stuff. And also use the opportunity to sort of try and dispel some of the myths
that we see about security. And I love images like the one on my screen at the moment. You
know, the hacker walks into the data center, and he's got a container of viruses, and he tips
the viruses onto the surface (laughs). Maybe these are like those dormant cyber pathogens,
yeah, I don't know what they are. But this is a good opportunity to go let's just cut through
some of that and have a look at how some of these attacks actually worked, or conceivably
could have worked. And talk about some defenses as well, because defenses are always good,
too. So, what level should we be thinking as a viewer of this play by play? Like, where do I
need to be? What understandings do I need to have to really be able to follow along today? I
think the level for today is you have an interest in security, you have some sort of
responsibility for making things secure, whether you're a developer, or a management, or
architect, whatever it may be. We're not going to go into a whole bunch of low level detail,
we're going to talk more about these are the things that we're seeing in the industry, these are
some of the ways that they're happening. We're going to keep it sort of, reasonably high level,
I hope reasonably entertaining as well. Absolutely. And then obviously if someone is spurred
on by any of this, there's more content available Oh yeah, yeah. in some of your other courses
in the series. There's a lot of content (laughs). Yeah, absolutely. There is much, much content,
at great detail, as well. So every one of these five things we're going to look at today, there
are dedicated courses that go for many hours each. Perfect.

TalkTalk Hack

All right, Troy. So let's go ahead and dive into our first hack that we're going to discuss about
today. TalkTalk and the British telco hack that happened last October, I believe. Yeah, so
TalkTalk was really big news around the world. It is a local British telco, but it made
headlines for a few different reasons. And we're going to talk about SQL injection in a
moment, but I thought we might start, and this sort of speaks to the intro where it's interesting
to see how attacks are represented in the press, versus what actually ends up happening. And
I like this article because it illustrates the point. So this article's talking about a 'cyber jihadi'
group (chuckles) being the attackers. And in fact, a little bit further down this page there's
one particular quote here which says, "They're claiming to be Russian Islamic cyber jihadis. "
The people who broke into TalkTalk. And what I find sort of equal parts amusing and
disturbing about this is it's sort of picking every sort of fear that people have online. You
know, there are words here that are meant to sort of shock and give emotional reaction. And
when we look at that against what the reality of it was, and the reality of it was more like this:
the 15 year old boy in Northern Ireland who broke into the system, and suddenly it's not quite
so scary. Like it's still a bad event, but the nature of the attackers is very different. So the 15
year old boy was one. There was also a 16 year old boy, so a little bit older. A much older
gentleman, as well, was in there, he was 20. So one other thing as well, that happened with
this, is allegedly when the attack first happened, there was a ransom demand. And apparently
they wanted somewhere in the order of 80, 000 pounds in order to hand over the vulnerability
and the data to TalkTalk and not to go public. And of course the whole thing did ultimately
go public, and one of the things we saw when it went public, as well, is we saw the data being
sold online. And we see this a lot these days, so we see these dark marketplaces, or darknet
marketplaces, which is essentially websites stood up over tor. And often these websites, you
will be able to go in there, you will be able to buy data breaches next to buying weapons and
drugs. And this is the class of commodity that these data breaches have now become, which
kind of puts the actors who are breaking into them in a bit of context, when they're in there
with gun runners and drug dealers. So we're often seeing this stuff pop up on the dark
markets, and very frequently the attack vector to get this data out of the system is SQL
injection. And I thought what we should do is we should talk through the mechanics of SQL
injection for a moment. And SQL injection is important because it's still classified as the
number one risk on the web today. It's very, very easily exploitable, that's why there's a 15
year old kid on here. It's very easy to discover resources at risk of SQL injection. And it has a
really high impact as well, because if you get all the data out of the system, that is massively
impactful on the organization.

SQL Injection 101

So how about we run through some SQL injection 101, and it will be fairly high level, so we
understand how the thing works. And then I'm going to show you some of the tools that make
it really easy for these sorts of adversaries to get the data out as well. Sounds good. All right,
so I'd normally run through it, there's sort of a little bit of a 101 of SQL injection which goes
like this. So imagine that we have a URL, and the URL might be something like a shop, and a
parcel's a product ID, product ID number 3. Now, the way to think about this is that we've got
a resource, which is the URL. And off the end of that we've got a query string. And of course
you could change the query string from product ID 3 to product ID 4, and you get a different
product. Now what tends to happen when we build data-driven websites is these URLs
translate down into queries that look something like this. So there's going to be a SQL
statement underlying the whole thing. And in this case it might be saying grab product ID
number 3, and then what happens is we've got a query, which is this piece of code, which is
hard coded somewhere into the app, and we've also got the parameter, which is what's come
from the query string. So we're sort of thinking about these in two different paths, both the
URL and the actual SQL statement itself. And the way to consider this is that everything on
the left of the screen here is trusted, so it's hard coded into the app. It's always going to do
what it is. We can't really go and change, for example, the statically coded SQL statement.
But everything on the right part is untrusted. And when we say it's untrusted, and this concept
of untrusted data in particular, we're saying that it could be modified, could be changed to
whatever we want to change it to. And the problem is, if you imagine someone starts
tampering around with that query string, and they change the three, and they possibly put a
semicolon after the three, which would terminate the SQL statement, and then they write a
new SQL statement. Now if that, in the query string, comes all the way down and it actually
appends to that query we see at the bottom line there, well then we've got a problem, because
suddenly you're starting to run arbitrary queries after this. Now the interesting this is, this is
the mechanics of how these attacks work, but very frequently the adversaries, the 15 year old
kid in his bedroom, have got no idea of exactly how this actually works under the covers.
What that sort of adversary understands very well is how to use tools like this. So they know
how to use things like sqlmap. Now sqlmap is a very, very efficient SQL injection tool. It's
freely available on sqlmap. org. You can use it for very ethical purposes. You can use it for
testing your own apps. It's very efficient at pointing at either a URL of your app or a series of
URLs of your app, and then just saying you're going to go nuts, right? Like, see what you can
find. But the problem is is that you got no idea whether it's someone doing it ethically or
whether it is someone pointing it at something like TalkTalk, and sucking out all the data. So
one of the really interesting things with sqlmap, and this kind of gives you an idea of how
kids these days can get themselves into trouble. When we go down and look at some of the
features, there's a wiki over here. Quite a bit of extensive documentation. One of the
interesting things here in the documentation is that you can see there's a section here that
talks about Google Docs. So the idea of a Google Doc is a Google Doc is just a very carefully
crafted query, which is obviously sent to Google, so Google takes the query, searches for
content, returns results. Now think about the ability to create your own Google query, plug it
into sqlmap, sqlmap goes and runs the query, gets a bunch of results, which could be a bunch
of results like everything that is on my website. Okay, that would be good, that would be
ethical. It could be a bunch of results which are from other peoples' websites. Kids get the
tool, they point it at the Google Doc, they set it running, they go outside and play for a while,
they come back, the data's hacked. You know, everything is a mess. And that's how easy the
whole thing can become. So, SQL injections are not a new attack. I mean, this vector's been
around for really as long as I can think of, I mean as long as we've been creating dynamic
webpages with databases. Yeah. Why is it that this is still the number one attack vector?
Well, it's interesting. And look, it remains number one because there's a couple sort of
immutable facts about SQL injection. One being it's very easy to discover, and the other
being it's very easy to exploit. I guess the thing that we would have hoped would have
changed by now is we would be building less apps with SQL injection in them. Now on the
one hand, it's easier than ever not to have SQL injections. So for example, a lot of
applications these days, when they're doing their querying of databases, they're using object
relational mappers, they're using ORMs. ORMs properly parameterize queries such that
there's almost no chance of having a SQL injection risk. But we still see a lot of people hand
coding their own queries. I use a blog post that someone wrote that we won't go through here,
but one that was written only last year, only in 2015, that is a tutorial about how to do a
password reset in ISP. net. And it has a really serious SQL injection risk in it. So here's
someone creating a brand new tutorial, putting it on the web, there are comments there saying
thank you, this was very useful. So people are taking this code, they're building their own
apps. So we still got a lot of advice out there, a lot of information which is bad, and of course
we've got a very, very long tail of legacy web apps, as well. There is still a lot of classic ASP
out there, you know, well over a decade after we moved, theoretically moved from ASP to
ISP. net. Because a lot of organizations have legacy systems, a lot of organizations didn't
move to newer technologies. We've also got a lot of very junior people coming in, getting
really easy access to technologies. Now something like PHP is really easy to get started in,
very, very low bar of entry. Now what that means is there's a lot of people that have very,
very entry level skills start building applications. They're not aware of risks like this. And,
you know, on the one hand it's great that the technology is so accessible. On the other hand,
that kind of creates this risk, where we have situations like this.

Mitigating the Risks of SQL Injections

So from an admin's perspective, I mean you mentioned, and you actually shared a tool
already with the sqlmap as a tool that you can actually do your own penetration testing on
your web apps and websites. Are there other tools out there? You started to mention search
engines out there that you can help to do this on a broader scale across your own websites,
ethically. Yeah, and let us just make that caveat clear, right. So, do this with your own things.
And this is really the premise of the ethical hacking, isn't it? It's like, look, you need to have
some form of offensive capability in order to discover a lot of these risks. But we really want
you to sort of do it to your own stuff, not to other peoples'. There are a lot of really good tools
out there, like dynamic analysis tools. So dynamic analysis tools would be a tool where you
can say, look, I want to give you a URL, and you're going to go to the URL and you're just
going to pull the whole thing to pieces, and it's going to look for SQL injection and cross site
scripting and all these other common things. They're tools like Netsparker and Acunetix.
There's other ones like Fortify on Demand, Web Inspect, all these different dynamic analysis
tools which understand the patterns of SQL injection and are able to exploit it. A little bit
later on we're going to look at another major framework that had a serious SQL injection risk
in it as well. And you'll see that sometimes it can actually be really hard to identify where the
risk is. But certainly low-hanging stuff, like this password reset example I referenced before,
would have been very simple to discover with a lot of these tools. - Yeah, I think it all comes
down to the risk reward. And if we can get rid of the script kiddies' access to being able to
copy paste stuff onto the site, you're starting to win and starting to, again, mitigate that risk
further down the pipeline. And I think that, sort of reflecting on this whole module, when we
think back to the fact that a major multi-billion dollar organization is getting owned by a 15
year old kid with access to a free tool, that's when you start to go, okay, there is probably a
part of the process there that is missing. Because, you know, if you have good security
people, good developers who understand these patterns, then really you shouldn't be getting
into that situation to begin with. No. So from the dev side, I mean, as you're starting to build
out apps, I mean, what are your sort of best practices? Because I mean we all say, oh, you
know what, I'm going to fix this before it goes into production. And how many times does
that prototype code end up actually in production. So I mean what would you say your best
practices are just on the SQL injection, to mitigate SQL injections? - Well, you know, so that
situation in particular, the one where you go, I'm just going to fix it before the end. One of the
things we know about building software is that the end is the most critical time of the project,
because that's when your often running late, and you're often running over budget. That's the
time when you don't want to find new stuff. And one of the problems we got with the
industry is very frequently, particularly within the enterprise, there'll be security teams who
say build the whole thing, and then just before you go live, at that critical time, then we'll take
a look at it. And that's the worst possible time. So for developers, you know, there's a couple
of different things. So obviously number one is we want them to understand what the patterns
of SQL injection are. So what does vulnerable code look like? Really want them to
understand how to exploit it as well, because developers get a lot more engaged when they
see the mechanics of it. I show a couple of tools in the ethical hacking SQL injection course,
where there are tools that literally do what are referred to as SQL injection. Some are even
gooey based. You just copy the URL, you paste it into the gooey. I did a video a while ago
with my three year old son, showed him how to do it. Just for demonstration purposes. But
that's the level we're talking at (laughs). Can you copy and paste? Yes. So getting them to
recognize those patterns very early on. And then obviously there are frameworks out there
that will help them fall into the pit of success. So things like using stored procedures. It's
much harder to have a problem with SQL injection if you're using stored procedure. Using
those object relational mappers. And some people have philosophical reasons why they don't
like them, but, you know, then there's the stored procedures. You can still have inline SQL
statements, they just got to be parameterized properly. But SQL injection is not hard to
prevent, particularly not the sort of risks that we so frequently see.

Session Hijacking: Valve

The Attack on Valve

So let's shift gears here a little bit and talk about Valve and the hack that happened right at
the, I believe it was the end of 2015. Yes, so Valve had the little issue that you can see on the
screen here in December of 2015. You may notice that that date is sort of between Christmas
and New Year which is the time when you have a lot of kids at home, a lot of kids just got
new gaming machines, gotten new games. The last couple years there's just been something
about particular groups of online attackers targeting gaming systems right around Christmas.
And as best I can figure it out they're basically the Grinch, right? Because they're waiting
until the kid gets their new machine and then they're DDoSing these services and taking them
offline. And we're going to talk more about DDoS later on as well, but what I particularly
wanted to look at here is the events that unfolded after the DDoS. So this is just after
Christmas. We've got Valve's gaming engine, Steam, and Steam's coping Distributed Denial
of Service attack, which is making it really hard for them to support legitimate traffic. And
what they've done is they've gone, "Okay, we'll weather this out with capacity, right? "We'll
just put on more infrastructure, more caching. " What they did is they put on a bunch of
caching, which is a good sort of first layer of defense, I suppose, against a DDoS, you know,
suck up all the malicious traffic that's coming in. But what ended up happening is, what
you're seeing here where they say, "Logged-in users were seeing account data "that didn't
belong to them. " And that's kind of worrying, you know. That is not something a DDoS itself
would cause. What eventuated is that the way their caching implementation worked, you
were starting to get users not being attached back to the correct session for them. And in fact
what this resulted in is things like partial credit card numbers being disclosed, which is really
sensitive. Even though PCI says that partial card numbers aren't even being encrypted. Partial
card numbers are the thing that you use to identify yourself to all sorts of other services. It's a
bit of an identity verification attribute. And those phone numbers and email addresses, billing
addresses, all this stuff that you just don't want leaked. The interesting thing here is that it
really came down to session affinity and if we think for a moment about how sessions are
managed on web servers, what inevitably happens is the user goes to a website, the website
decides to put something in session state. It might be personal information about the user, it
might be the fact that they're currently authenticated, often an authenticated state is persisted
by the session state. Goes in the session state, the user gets a copy, should be a nice
cryptographically strong copy that just attaches them back to the session state stored on the
server. So long as they get their session state and all the other users get their own session
state, everything is magic and it works beautifully. Now inevitably the caching
implementation has resulted in a lack of this session affinity. So someone's come along and
they've said, "Hey, here I am, this is my session ID, give me my content. " Which would
include my billing info, et cetera. And the caching engine has gone, "Sure, here's someone
else's. " And we've lost the session affinity. So this is a really good example of a very sort of
implicit session hijacking attack. They obviously didn't set out to cause some people to see
other people's data, the attack was set out to knock the servers offline. But Valve,
unfortunately by their own doing, ended up leading to an unintended session ID attack.

Cryptographically Safe Cookies and Cross-site Scripting (XSS)

So, let's take a step in a little deeper there. You talk about the cryptographically safe cookies.
Yes, so, what we're trying to do here, when we talk about the way sessions are managed, on
the server side, when something is put into session state, it normally gets stored in-process,
possibly in a database, possibly in some sort of a state machine. Inevitably then we have a
user who comes back to the site and says, "Look, give me some of my information. " They
need to have the session identifier that attaches them back to the data that is stored in session
state. Now, that identifier is really important because if someone else can guess that
identifier, and this is one way session hijacking happens, like if your identifier for your
session is 257, that's not a very good identifier because the attacker's going to get, "I wonder
what would happen if I change my "cookie for my session ID to 258 "or 259, what would I
get? " Normally these are cryptographically strong or pseudo-random values that, within any
reasonable bounds, shouldn't be guessable. So you might find that it's going to be 30 bytes of
various random characters. When that's the case we shouldn't have a situation where someone
is able to guess someone else's. And so long as there aren't other vectors about and awake and
steal someone else's session ID, we'll talk about how we can do that in a moment, you should
be okay. In Valve's case they just simply returned the wrong stuff from the server when the
right session identifier was provided. But in other session hijacking attacks we see various
other mechanisms involved in actually stealing the session. A very popular one is cross-site
scripting. So if there is a cross-site scripting risk and the attacker can run arbitrary JavaScript
in the victim's browser and that JavaScript can access the session cookie, then it might be
able to send it back to the attacker. So that would be a way of an attacker very specifically
saying, "I want to start getting session IDs for this particular website. "

Preventing Session Hijacking and Man in the Middle Attacks

So then as a admin or a developer, we know this is another vector, how do we go about

looking at our own environments, and making sure that we aren't easily susceptible to these?
Right. So there's a few different vectors by which session hijacking can happen and obviously
Valve's situation was quite unique. Something went wrong with the caching implementation.
I just mentioned XSS, so Cross-Site Scripting is another popular way. Cross-site scripting
though requires that the session cookie be accessible via client script and it never should be.
This is why we have the HTTP-only flag on a cookie because if the cookie is HTTP-only
then JavaScript can never actually access it, it can only be accessed by the server when it's
sent back in a request. So that would be one way. Other ways that we can see session
hijacking happen that we can prevent as admins and devs is man-in-the-middle attacks. If
you're communicating over an insecure connection, you've already logged on, passwords and
things are gone, that's fine, but now you've got this identifier, this cookie that's going
backwards and forwards, and if someone else gets this cookie they gets to take your session,
you've got to protect it. So you can't send that backwards and forwards over an insecure
connection. Some years ago there was an attack against Facebook. It was a Firefox add-on
called Firesheep. This was sort of a bit of a watershed moment where we all sort of went,
"Wow, we've actually got to look after "these session identifiers. " Because what Firesheep
did is you could install it on Firefox, you go to the Wi-Fi cafe, you've got a network card that
can look at the traffic around you, which is pretty common, and then while you're there in the
Wi-Fi cafe, which doesn't have an encrypted network, it's looking for people's Facebook
session IDs, and it sees one and it shows you their profile and then you click on it and it takes
their session ID, puts it in your browser, shows you their Facebook, you're logged in as them,
and then you leave them a little message and say you probably shouldn't be here at the cafe,
or something like that. But that was the point where when I care about surely session
identifiers also got to be secure. And they've got to be secure both insofar as they should only
be sent backwards and forwards over HTTPS. But they should also be flagged as secure, so I
mentioned you could flag a cookie as HTTP-only as an attribute of the cookie, there's another
attribute called secure, and when you've got the secure flag on a cookie it will never go over
an insecure connection. So that's two major ones, Cross-Site Scripting and Man-in-the-
Middle attacks. Another one is we sometimes see session identifiers stored in logs and then
logs disclosed. There are some very popular logging frameworks which people use
particularly in things like ASP. net applications, and they automatically log things like
unhandled exceptions. They log them all to the database and then they don't secure the page
which then allows you to review the logs. And the logs have got all of the request headers,
and the request headers include the cookies which includes the session identifier. So you can
sort of literally browse through these publicly accessible log files, go, "I'm going to take that
person's session ID, "recreate it in my browser, and now I'm them. " Effectively then it's
impersonation. So we've been talking about the session hijacking here. But as you can see in
the headline this was also a DDoS attack. How do those two play together? It's interesting.
We often see DDoS attacks being used as a diversion as well because DDoS attacks are very
disruptive, right? They are actually stopping traffic, legitimate traffic from getting to the site.
We'll go into that more in a moment as well in the DDoS module, but what we're often
finding is that that is a veil for something else that's happening behind the scenes. In Valve's
case it looks like it was their own misconfigured caching, but we're seeing many other
examples where whilst this DDoS attack is going on, someone's mounting a SQL injection
attack over there, or they've gotten root on a server over somewhere else. This DDoS is sort
of keeping people busy there while other people working over there. I think one of the really
important things to remember here is that often these attacks are not isolated events. They are
part of a broader range of malicious activity happening against the site.

Evading IDS, Firewalls, and Honeypots: Ashley Madison

and Sony Pictures
The Ashley Madison Hack

So let's shift some speed again, and this time, look at a hack that really had some major
implications beyond just the financial impact on a given company, and actually had some
personal ramifications, the Ashley Madison hack. Yeah, so Ashley Madison, it just remains
this unprecedented data breach in so many ways. We've seen bigger data breaches since. I
mean, in some ways, it was small. It was only 30 million people. And we've just seen
Myspace, 360 million people. So, you look it at that way and go, well, it's not so big. But the
thing about Ashley Madison was just how big of an impact it made on so many people, and
not just the people that were in the data breach, but the impact it made on their families,
impact it made on the press. It was all over the consumer news. And this is going back to
about August 2015, when the data eventually went public. A month earlier, it had been
hacked out of the system. Hackers said, "Shut the thing down, otherwise we're going to dump
it all. " And of course they didn't shut down, so they dumped it all. And it was just an
absolute frenzy of media poking through the data, stories that we just found this politician in
there who was having an affair in this way, and sort of everyone's dirty laundry being aired
publicly. And one of the things that it really sort of makes you think at the time, as an end
user, not necessarily as a builder of systems, is that how you're going to handle it if all of
your data out of various systems get leaked, because this is often what's happening. We're
seeing really sensitive information, not necessarily related to infidelity, which was what
Ashley Madison was there for but things like Social Security numbers in the U. S., things like
other personal identifiable attributes, birth date, gender, sometimes sexually, ethnicity, other
things that everyone has the right to keep private. And unfortunately, they not only turn up
hacked out of systems, but then very often leaked publicly. So this is what happened with
Ashley Madison. We had somewhere in the order of 25 gigabytes of data out of the database,
not only hacked, but then taunted as fast as possible to as many people as possible. So it got
redistributed in an absolutely massive unprecedented way. And I think this really brings a,
not only the personal component to the individuals who are being part of the hacks and their
data is being leaked, but also to the professionals, the developers, the IT admins, and sort of
our responsibility to our clients and our users and making sure that this data is secured and so
let's dig in a little bit more on this particular hack and see if we can't share some of the
learnings with everyone. Yeah, well, I think the point you've made there about as technology
professionals being aware of our responsibility to secure it, indeed being aware of the impact
on people.

The Human Impact of Data Breaches

One of the things I want to sort of think about as technology professionals and what I want to
show you will hopefully help us think about users in a more human way, because after we say
users, it's like there's some sort of amorphic, nonhuman kind of thing, but they're real people,
right, they have feelings. I read a blogpost after the Ashley Madison data breach and it was
"Here's what Ashley Madison Members "have told me. " And I encourage people to go and
have a look at this, just to try and understand the human impact of data breaches like this and
I'm going to scroll down the page to one quote in particular, and in fact, what this is is a
bunch of different emails that I receive from people. I literally got thousands of emails from
Ashley Madison members wanting to understand more about the data breach. But have a look
at this one. So this is the one that really got made. So this was a guy who found himself in the
Ashley Madison data breach. Many different sites made the data publicly searchable and he
was petrified that his wife would find out that he was on the site, having an affair, and
obviously he was aware he'd done the wrong thing, but saying, "Tell your wife and kids you
love them tonight. "I shall do the same as I really don't know "if I will have any more chances
to do so. " And suddenly it goes, as much as I don't condone what he was doing on the site,
the technology decisions that were made in the way this site was put together and the way the
infrastructure was secured, is leading to the point where people's relationships are breaking
up and obviously there are other factors involved here, but somewhere this is the impact that
technology is now having on lives and you'll see many more quotes from people on here.
Quotes along the lines of, look, I was never actually using the site. I'm sure some of them
probably were, some of them probably weren't, but because their data was in there, because
all you got to do is enter an email address and now you have an account on the site, people
were vindicated as being members and had really serious impact on their lives. Multiple
people committed suicide out of this. And I don't think we often think as developers that the
systems that we build and as IT pros, the systems that we're actually running and protecting,
can actually have such massive impact on people's lives. So I'd encourage you to go and have
a look at this. It's really eye-opening in many ways. I appreciate that. So I think one thing that
was unique about this breach as well was the type of data that was hacked away from their
servers. And this sort of starts to lead us to the point of the ethical hacking discussion here,
which is when you look at this data breach, we've got somewhere in the order of 25 gigabytes
worth of database data, so this has come out of a database. It is a very large amount of data,
25 gigabytes. We're also looking at the entire code base of the application, so now, this is not
the database server, so if, for argument's sake, if it was a SQL injection risk, it would have
got the data. Something else got the code base, so there was another attack vector that
actually got the web application from a system somewhere, either the live system or a source
control repository or a test system or a backup or something like that. So let's pause on that
component right there. So basically, you're saying if you were in a bloody fight to get first
mover's advantage with another company, that that other company could theoretically, using
a hack similar to this, if you had the same exploits available, get your entire source code and
take any advantages that they might have, I mean, they'd have to decipher through how
everything was written and everything, but they could literally have your company, your
digital assets. Yeah, and it's worse then, because it's not just the source code, it's the entire
database as well, but you could have their company, their entire IP that their entire business
model is built around and you could take all of their customers and set the whole thing up
again somewhere else. So, I mean, the impact that some of these hacks have are catastrophic
to a company, and as we saw with-- Oh, absolutely, yeah. Ashley Madison's parent company,
I mean, it did not kill them, but it definitely wounded them. They actually just in recent days,
before recoding, they have totally reinvented themselves, I went and had a look at their
website today, purely for research purposes, and now, it's actually a much classier affair, as
weird as that sounds, but it's much less about the salacious affair and now they're talking
about, I think they say, "Have an experience. " But anyway, they're trying to reinvent
themselves.

Firewalls, Intrusion Detection System (IDS), and Honeypots

But where we're going with this is that 25 gigabytes worth of data, the entire web application,
13 gigabytes worth of email as well, and here's the interesting thing there. Email is again a
very different class of data. It is not running there on the same server as the web application,
which was not running on the same server as the database. So someone has managed to
infiltrate these systems to the extent where they're able to probably pivot around within the
network and grab different things from different places and then exfiltrate the whole thing
out. And this brings us to this whole concept of IDS firewalls and honeypots, which is one of
the ethical hacking courses and we got to think about these three defenses in very different
ways. So for example, firewalls are very good at doing basic packet filtering, so we're going
to allow HTTP over port 80 and port 443 for HTTPS, and that's it. Nothing else goes through.
Now, that's fine to a degree, but you can still use SQL injection through port 80, through that
rule, so there are still lots of holes in that. So then we sort of start to get into more
sophistication and we get into the realms of things like web application firewalls or WAFs,
where we start getting these devices that are much more intelligent and they still sit there and
play a firewall role where they have the ability to block traffic. But now they're saying, we
understand what, say, known good patterns look like and a known good pattern to, say, run
the search on the website looks like this. If it starts looking like something else that may be a
SQL injection attack, then we're going to block it and you know, it's much more intelligent
than just filtering out packets. So, once we start to get into this sort of IPS IDS realm, so
intrusion protection system, which can actually block traffic, versus intrusion detection,
which is going to look for it and raise alerts. We start to get more intelligent again. Now, one
of the ways that they commonly work is they work on a signature basis, where they say, these
are known bad signatures of potentially malicious attacks and I'll give you a good example of
this. There is a very, very popular open source free IDS called Snort. It's here with the pig,
hence the snort, enormously popular intrusion detection slash intrusion protection system,
and Snort works on signatures. And what we saw after things like the Heartbleed incident in
2014, where we found vulnerabilities in SSL, is we get signatures like this one, in this case
released by U. S. Department of Homeland Security. So, they actually said, okay, this is a
signature, in fact, this is the Homeland Security website. It's an FBI Snort signature and this
signature says this is what a malicious TCP out-pay request looks like, which is attempting to
exploit vulnerabilities related to Heartbleed. So, you find your IPS IDS is now starting to use
these signatures, which you have to keep updated because there's new ones that come out all
the time and it starts to look for malicious traffic that matches it. Problem there is it doesn't
take much to modify your traffic such that it no longer meets the signature but it still meets
the intended purpose. You move a few bots around, you put your payload a little bit further
down the packet somewhere, and now you're got a problem. So very often now what we're
starting to see is things like statistical anomaly analysis, where we're saying this is what is
normal traffic, in a very sort of heuristic way. It's not that this is the signature and it looks
exactly like that. It's that these are normal behavioral patterns and if those behavioral patterns
divert from what we expect, well then that raises the flag and then we can either block or alert
or do whatever we want to do. For sake of not getting into too many buzzwords here, but
knowing that there's a lot floating around in this space specifically, as you talk about that
heuristics of traffic. You're starting to see more and more products deemed as artificial
intelligence, machine learning in this space, I mean, do you see that type of technology
benefiting the IDP IPS? Yeah, absolutely, and again it does come back to trying to identify
what is anomalous. And we often see this with antivirus today as well. So a lot of antivirus is
struggling to keep up with the rate at which new malicious software is being discovered
because they're literally discovering hundreds of thousands of variants a day. It's very, very
hard to create signatures for all these things and one of the problems with creating signatures
if you've got to see it go wrong somewhere before you know that there's something malicious
and that you have to create a signature and load it into your AV or your IDS or your IPS. So
this whole idea of heuristics of what can we sort of define as being normal and then when
there's a deviation from normal, we're going to identify it and there's a degree of AI in that as
well, so there's artificial intelligence in this. That seems to be where the bar is moving now,
but as we know, AI is not an easy thing to do, either, it is extremely difficult. And of course,
what it does is it just continues to move the bar, like it just gets a little bit harder, the attackers
find another way and the whole thing moves on again. So it's moving us forward, but it's not
fool-proof either. Right. And I think the other thing that this section sort of highlights is the
fact that we've been talking about everything to this point as isolated, this is one attack or it's
actually I think of each of them as sort of grown, so this is one vector here, this next one had
two vectors. And now when you really look at this, like, we have to be aware, as security
professionals to make sure that we aren't thinking about just one or the other. This needs to be
a holistic approach to security. Yeah, and when you think about what we've just been talking
about here, we've discussed firewalls and IDS's as well. We're talking about two very
different kinds of defense too, so this sort of holistic approach is not just being aware that
there are multiple types of attack, but that we need multiple layers of defense that do different
things and the third part of that defense, which we cover in this particular course is
honeypots. And honeypots are a really interesting implementation because honeypots don't
set out to try and stop anything bad from happening. They're there to try and help you
discover as early as possible and the relevance to things like Ashley Madison is all of that
data probably didn't just slip out of the network in a very, very short period, you know, it may
well have been, the tech was in there for awhile, browsing around, trying to traverse, figure
out what was where and what a honeypot does is it sits there and it looks like a real, live
device. Now that device could be a Windows Server, it could be a Cisco firewall, it could be
anything that you plug into your network and the honeypot will emulate this device and it
will wait for someone to connect to it and then when they connect to it, the honeypot will
raise an alert and say, hey, someone's connecting to me and they were never meant to be here.
There was no reason for you to connect to the honeypot. It has no functional value. So that's a
type of device that we don't see in a lot of organizations yet, but can actually be really
powerful, so long as people recognize that it is there to help you respond early after
something goes wrong.

Utilizing Honeypots to Prevent Attacks

So, let's dive into that a little bit further. So, you now as, let's say, you're the security
professional, you're doing a penetration test, you have that information from the honeypot.
How are you utilizing that to help improve your overall systems security? So, what you'd be
doing with the honeypot, again, when the honeypot starts making noise, that's when you
know there's a problem, because someone is already in there that shouldn't be there. Now,
that may just be someone who is unintentionally browsing around the network without
malice, right, but it's the sort of thing that needs to be investigated, so as the person
responsible for the honeypot, you'd be saying, alright, so who is in there? So wherever they
come from, you'd have their IP address, you'd have things like the user agent strings if they're
browsing via web browser, and you'd be able to look at what it is they're trying to access,
what the tool is they're using, and then once you have the IP address, and particularly when
it's on an internal network, then obviously you're going to go and have words, right?
(laughter) You're going to say, funny thing happened today. We saw you in our honeypot,
what happened? Now, that may be someone's IP address, legitimate IP address and they've
got malicious software on their machine. It's malicious software that was installed via USB so
it never came in through the firewall, wasn't identified by the IPS because the IPS is at
network boundaries, looking at things moving backwards and forwards, it's within there, in
the network, and they've just stuck it in their machine. So the honeypot is good for finding
that sort of risk, and there are a number of different honeypot products out there, but one of
the ones I talk about in the course that I really like is made by a company called Thinkst and
Thinkst is a South African company. They make a product called Canary and the reason I
really like this Canary is because of what it actually does and how easily it does it. So this is
what a Canary looks like, and it's a really simple little device and we can see a little ethernet
cable here being plugged into it and a power cable and that's it. And you plug it in your
network and then you go in through the admin interface, and I show you how this looks in the
IPS and honeypots and firewalls course. You go in, you say, I want this to be a Windows
Server 2012 and you set that and then you set the notification address it's got to go to if
someone's in there and then you leave it. And you might put a few of them in there, so you
might put in a Linux box, you might put in a Cisco firewall as well, and then when someone
eventually browses to it, and they touch it, it notifies you, but it's a nice sort of turnkey
solution that any organization could grab, plug in, set it up, and pretty much forget about it.
Ballpark, what does a Canary cost? I think they're a few grand. Somewhere between, I think
around about two and half thousand, maybe three thousand dollars each. But when you're
thinking about a grand scheme of it, the cost associated with a device like this and allowing
you to just plug and play. Yeah. Is a lot less than the fallout from any sort of hack. Oh, man.
Ask Ashley Madison how many Canaries it could have bought (laughter) with the money that
it cost for security professionals. Yeah, so look, they're a wise investment. They're really not
very much money. And of course, the maintenance and overhead is so low as well, so that the
lifetime cost of them is minimal. Yeah. And I think you started to elude to this. With that
information that's gathered from that honeypot, you can then make sure that your systems are
patched, updated, that your applications are secure to the type of attacks that they're trying on
these honeypots. Yeah, I mean, this is all part of the broader ecosystem, right, so it's not like
you put the Canary and then you go, oh, I don't need to patch anymore, so, it's led us to all of
these together and we go back to this whole defense in depth and layers and layers of security
sort of thing where having this along with all the other good practices is a good thing.

The Sony Pictures Hack and the Hard Cost of Breaches

Is there anything else you want to add around the Ashley Madison hack? Well, I think with
Ashley Madison, in fact, in the course, I talk about Ashley Madison, I talk about Sony as
well, so if we remember Sony Pictures, they had that incident a couple years back where they
had a really serious attack which installed malware on the computers, there were skulls and
crossbones, movies released, emails taken, just stuff from all over the network and allegedly,
the attackers were in there for a year. Now, when we think about something like the honeypot
on the screen here, a little Canary, when an attacker's in there for a year, okay, I don't want
them to be in there, for say, a week, but if we had to had something which would have started
to chirp, once they hit it, after one week, as opposed to letting them in there for a year and
suck out the amount of data they did, that would have made a really big difference. So, the
sort of attacks that this defends against, we do see time and time again. Yeah. If nothing else,
the Sony hack reminded us all that when we're writing emails, write them as if they are public
because one day they might. (laughter) You know, after that, I started thinking, and here's the
scary thing, right, because you think about how many years of emails you got and I'm
thinking, I've got a couple of decades worth of emails and files and I went through this thing
of what if everything was public? Did I do something really bad in like 1997, which I might
now be embarrassed about? And the worrying thing is I don't know and if it did all go public,
I'm sure someone would eventually troll through it all and find it, too. All joking aside,
though. That does bring up a very hard cost to these hacks that we haven't necessarily felt
because, I mean, the quantity of data that is being collected and ultimately being hacked out
and resold on dark markets and everything has only increased over the last few years. And
the reality is it's digital data, it doesn't decay, it's not a piece of paper that has to be
photocopied 10, 000 times to get it to 10, 000 different people. The file can transfer instantly.
We don't even know what some of the costs are associated with these hacks 10, 15, 20 years
down the road. And we'll never know because we never know the personal costs to
individuals, either. But it made me think when you said that. One of the problems we've got
as well is that because storage is so cheap, we keep everything and in fact, in the Ashley
Madison situation, one of the reasons the attackers allegedly broke into the system in the first
place, or one of the reasons they alleged they broke into the system was because Ashley
Madison was charging people to delete their data, which was, look, it wasn't a nice thing to
do in the first place, right, to say, hey, if you want to be removed from our system, give us
money. So they would give Ashley Madison money and then Ashley Madison would delete
them and what the attackers managed to demonstrate is that Ashley Madison weren't deleting
all the traces of them because the payment record associated with the cost of removing them
actually had their unique identifiers in there, so it had their name and their physical address
and email address and stuff like that and it was just, keep all the data, you know, they were
just retaining information which they never needed to retain, which seems to be the catalyst
for the attack in the first place.

Hacking Web Servers: Drupal

The Drupal Vulnerability

So, let's shift again, and, this time, going towards, going right at the web servers, so, we have
the Drupal situation, would you like to elaborate on that hack? Yeah, so let's talk about
Drupal. Yeah, so, Drupal, in fact what I thought we'd do is we would use Drupal as a way of
talking about the hacking web servers course, because this is sort of related to that, and, in
fact, I use this Drupal example many, many times when I run workshops, because it's a really
good representation of some of the risks of applications leaking framework versions, or what
the underlying framework is. And, I thought we'd start here, so Drupal had this highly critical
public service announcement, in other words, a really, really bad vulnerability back in 2014.
And, if we scroll down a little bit on this page, there's a bit of information about this, and the
thing that really strikes me is this sentence, which says, "You should proceed under the
assumption "that every Drupal 7 website was compromised "unless updated or patched
"before October 15th, 11 PM UTC, "that is seven hours after the announcement. " So,
imagine this, seven hours, right? Like, you got a bed at night, and everything is fine. The
world is good. And, by the time you wake up, you have already exceeded the window of
opportunity to patch your servers before all your things are owned. Like, that is a really,
really small window of opportunity and it raises this question about how well equipped are
you to actually patch your infrastructure if you need to. So, this was a really interesting
incident, and, as you can also see here on the screen, it was related to a SQL injection attack.
Now, thinking about that seven hour time-frame, and how quickly things work, we saw
exploits for this vulnerability appear really, really quickly, and we can now jump over and
see things like the exploit database website, which tells you exactly where the risk was, and
we can actually see here on line 12 that there's a bit of post-data that's set here, and it was
kind of a funky SQL injection risk in that it wasn't just an outright simple exploit. You had to
change a parameter or an array here that would set as part of the post-data, and inject at just
the right point with just the right values, and then you had SQL injection, and then it was kind
of a game over, because SQL injection can do all the things that we spoke about a little bit
earlier on. But, I just found it fascinating that you only had this really, really small window of
opportunity, and these exploits were available so quickly.

Inventorying and Keeping Frameworks Up-to-Date

Yeah, and that brings up a, almost a deeper discussion that we can just have around. How do
you inventory all the frameworks that you are using as an organization and keep up to date on
these type of things? Not within seven hours but even within seven days or seven weeks? I
mean, I'm pretty sure we can walk through any organization in the building and be like,
"What frameworks are you guys running? " Get a whole lot of confused looks on our face.
And think about how far frameworks go now as well, because it's not just like, well we've got
some Drupal and some ISP on it, there are JavaScript frameworks with vulnerabilities, so
what version of jQuery are you running? What version of Angular are you on? And, there's
probably two ways of answering this, and one way is that a lot of big organizations have
great, big inventory databases, and I've spent a lot of time in big organizations and seen these
databases, and know that they are very, very poorly maintained, because the technology
moves much faster than people's ability or willingness to actually keep them up to date. So,
that's one way of answering it, but the other way I'd answer it, and this is sort of the light at
the end of the tunnel, is I really like the ability to use manage services, particularly platform
as a service, cloud offerings, in fact, we're not going to do it in this play-by-play, but the last
ethical hacking course I did was cloud security, and one of the things I talk about there is that
when you go to a managed platform, responsibility for this stuff gets delegated to someone
else. So, for our own sake, if you're using a managed Drupal hosting service, and it was
managed by a professional Drupal hosting organization, this is their responsibility. Now,
they've still got to patch it, right? The vulnerability is still there, but, now, you've got one
organization that specializes in doing this often for thousands or tens of thousands of
customers, and they've got people 24/7 able to apply these patches so that you can have a
good night's sleep, get up the next day, yes there was a bad problem, but someone has
patched my things for me. Excellent.

Using Shodan to Explore Vulnerabilities

So, here's what I want to go with this though, and I mentioned framework disclosure before.
So, this was a version of Drupal 7, in fact, we can see here line seven that says, "Drupal core
7. x versions prior to 7. 32. " You can easily search for websites that are running vulnerable
versions of software by using a tool like this. So, Shodan is kind of cool because, as we can
see on the screen, you can search for webcams, you can search for buildings, search the web,
which is fine, you expect to do that, search for refrigerators. What do you reckon you do once
you find a refrigerator, Shodan? I mean, there's always making the mild go bad, I guess. How
can you do, like, can a fridge do that? You've got to have the mechanic-- You know what I
have heard of home devices like TVs actually being used to spam email, and, so you can
actually, there have been, well, there's just been research out there in the wild, instances
where you can use applications to do things that are malicious in nature, and not even know it
as an owner of said device. It's a brave, new world isn't it? Actually, you know, I saw one the
other day where they're using, I think they're using webcams to DDoS. So, you could actually
get webcams, look, why you would want to do that, I don't know, in fact, why'd you even
want to connect your fridge, I'm still not entirely sure. But, regardless, Shodan has become a
little bit infamous as a tool which searches for connected devices, and we've seen it in the
news a lot, being able to do things like find instances of MongoDB that don't have any
authentication on them. So, we've seen a bunch of MongoDBs compromised, all the data
extracted out, because Shodan has enabled someone to go on a search, find the instance,
identify that it doesn't have any authentication on it, all the data gone. Now, what I thought
I'd do on here is we'll bring it back to Drupal 7, and then we'll talk about some of the other
things you can find on Shodan as well. If we were to go on here and search for Drupal 7, and
inevitably by now, you would hope that all of the Drupal 7 as a major version, stuff is
patched, we know it won't all be patched, but a lot of it you'd hope is patched. If you went
and searched for Drupal 7 within that seven hour period of that new critical vulnerability
being announced, chances are you would find a lot of stuff that was vulnerable, and we can
say, actually, up at the top here, it says, "Total results over 60 thousand, 60, 943 results, " and
it's finding these sites because Drupal 7 has returned on the responses setup. So, the web
servers are configured to broadcast the underlying platform. So, when a crawler like Shodan
comes along, and says, "Hi, what are you running? " and the website turns around, and it's got
a response header that says, "This is exactly what I'm running, " that gets indexed, and it's
now very, very easy to find. And, in fact, I ask in the workshops, mentioned your opinion,
too, and when I do this, I say, "Why do websites broadcast the server? "Why do we have a
response header that says "'This is the server it's running on'? " My assumption would be so
that the client connecting to it actually knows how to interact with it, because there are
different potential ways that I might want to interact with you, knowing what you're running,
but I actually don't know. What is the reason? But, I mean, this is one of the things people
say. My responses to that is, one, if you're doing that, that's really bad, and it's really bad
because, for example, if you're programming your client to behave differently if it's IIS as
opposed to patch your engine x or something, there is probably some bigger underlying risk,
and I don't think it's like, yeah, you're in Internet Explorer, and you browse across and the
server says it's IIS, and Internet Explorer goes, and it's nice, it's from the same family, and
they have a better-- Yeah. Doesn't work like that. The only reason I've ever been able to come
up with of any substance whatsoever, is that it's good for stats. So, it's good for the vendors to
appear in Netcraft stats because they're broadcasting their hitters, that's the way we know
what server it is. But, it is a problem, because it puts you on the front page of search engines
like this, and we will see many, many other cases like this Drupal 7 vulnerability, and I
reckon turning off these unnecessary banners that disclose not just server, but powered-by, all
these other response hitters, ISP. NET spits out a lot of them, IS spits out a lot of them. Turn
them off, it's not stuff you need to broadcast. Yeah, you know what, I'd love to throw that out
to our viewers as well, if they have a known reason why that information is in there, Get in
touch, I'm curious. please share, because... hopefully it's not just one of those things where
it's, well, we've always done it that way, so we just keep doing it that way, because, honestly,
that's what leads us down the road of a lot of these bad habits with security. We've always
done it that way. And, well, for viewers who are out there thinking of reasons why you would
return response headers, do a bit of a Google around for some of the things you can find on
Shodan. There's some really good talks I've seen where people have shown some of the
things they've discovered, and it's things like, obviously, webcams, and, jeez, people don't
realize how easily accessible their webcams are. Webcams and the baby webcams, and other
places you probably shouldn't have webcams. Things like breweries, you can find breweries
on there, like, literally breweries that have things like VNC remote control software,
unauthenticated, running where you can control components of the brewery. (chuckles) One I
saw recently, I probably shouldn't even laugh at this, is a crematorium, a crematorium
discover-able on Shodan, with VNC open that you can remote into, with buttons to turn on
things with flames, and it's discover-able on this website. So, it's just amazing how much
stuff we're putting out there, and how much stuff is getting indexed and is easily discover-
able Yeah. And, I've heard a lot of individuals be like, "Well, why is this site like Shodan
even exist? "This seems like it's completely unethical, " and my response to them is always,
you know what? Just because you don't know it's happening, doesn't mean that someone else
doesn't. Yeah. So, I think that it's important to share with the admins and developers out there
to actually use this as a tool to help you find your own servers and your own IP addresses,
and see what known vulnerabilities are there that you can then go and address. It'll certainly
do that, I think probably one of the greatest goods that Shodan does is awareness. It's a very
good way of highlighting just how easy it is to discover these things, because, the reality of it
is, if someone wants to go through and scan the IP for address range, it's not necessarily a
hard thing to do. It's not too tricky, it's going to be a little bit harder as we go to IPv6, but for
the moment, if they want to go and just start scanning the address range, and looking for open
Mongo servers, you know, they don't need Shodan to do that. This is not an uncommon
practice in the academic world, where they do do these full internet scans, and then create
repositories of that, so... I guess, it's just one of those things where we need to make sure
people are, like you said, aware of this tool. Yep, that's it, and look, do go and do a bit of
research, because it's amazing some of the stuff you'll see on there. Excellent. So, if you do
find information on Shodan or through whatever framework notification, beyond patching, is
there anything else that you need to be thinking about in this process? For your own things,
well, the likes of Shodan is very good at identifying stuff like open ports, and one of the
things you want to think about is, do I really need that port open? Or, do I really need that
protocol open? One of the ones that I often saw come back in security scans of Microsoft's
servers is you've got WEBDEV running. Do you need WEBDEV? And, it's sort of a good
opportunity, and Shodan can show us some of this, or other port-scanning tools can show
this, good opportunity to say, this is all the stuff that's currently accessible on this machine,
ports, protocol, all this sort of thing, how much do you actually need? Can we get to this sort
of principle of least privileged position where we are only running exactly what we need and
only allowing just who needs access to it to get in? So, I think it's a good time to have a
sanity check with that.

Addressing the Vulnerabilities in a Network

So, then, you're an admin at a office, and you do have a connected refrigerator or whatever
else, and... Get in touch with me, Let me know what it does. And there's a known exploit for
that software, and that vendor hasn't patched it, or there isn't an easy way, I don't even know
how you would update the firmware on your refrigerator, if there's a USB plug in the back or
something. Yeah. But, you're in that situation, how do you then address that situation as a
security professional? Well, a couple of different ways, one way is to consider disconnecting
the fridge and, if it was a fridge, I imagine that you could disconnect it, not from the power,
because then you will have the milk problem, but disconnect it from the internet, just until
you get a patch. A little bit harder when it is actually a critical system, or an important piece
of infrastructure you got to run, and that kind of brings us back again to firewalls and
intrusion detection systems, where we might say, look, as a stopgap, can we get a signature
for whatever vulnerability it is that's on there, add that to our, say, intrusion protection
system, where it can actually block that incoming connection, and will that sort of suffice
until we can get the underlying vulnerability patched? You also don't really want to end up
with an IPS that's just got an endless set of signatures for vulnerabilities and software rather
than getting the underlying problem fixed, but that could be a stopgap for you. Excellent.

Distributed Denial of Services (DDoS): Nissan

The Nissan Attacks

We've got one more hack here today and I know, as a car guy, this one's got a little special,
for you because it is Nissan. Yeah, or as we would say Nissan. So let's have a little talk about
what happened with Nissan earlier on in 2016. So the situation with Nissan and we might talk
about a couple of Nissan related security things, now that I think about it. The one I wanted to
start with here was around Nissan getting a distributed denial of service attack by
Anonymous earlier on in the year. You know Anonymous is this sort of, it's a very loose term
these days, because anyone can say, "Hey, we're Anonymous. " So who knows who it really
was. But this group that was allegedly Anonymous, decided to DDoS Nissan in January
2016. And in fact, I'll ask you, this is sort of an interesting question and it speaks to the
motives of hacktivists sometimes, why do you think hacktivists would want to DDoS Nissan?
That's a great question. What does Nissan do that is so wrong, that is so recalcitrant that you
would want to DDoS them? Someone had a bad experience at their local dealer? I don't
know. Well this is Anonymous right? It's a collective of people. So they DDoS:ed Nissan
because of the whales. Okay. (Laughing) Bear with me, so Nissan is Japanese, alright. And
Japan still has whaling, which many of us would like to see ended. Obviously Anonymous in
particular would like to see ended and they thought, "The way we're a going to do that, "is we
are going to DDoS a Japanese company "and that will stop the whaling. " The only thing that
has stopped since the DDoS, is the DDoS itself, which didn't go on for very long. Because
ultimately a DDoS does tend to be a little bit of a short term thing. It's this attack that comes
on, defenses are laid over and then everyone moves on and gets on with their jobs and there's
some amount of traffic that's lost in the interim.

Breaking Down a Distributed Denial of Service (DDoS) Attack

So we've talked about DDoS once already, but just for those who are new to security, what is
a distributed denial of service, DDoS attack? Glad you asked, let's go through the slides. So
we have a couple of slides here that I thought we'd talk through. And the first slide is about
DoS and the second slide is about DDoS. And it's important to understand the distinction and
it will become clear as we go through this. And of course, this again denial of service is one
of the ethical hacking series of courses. So let's sort of think about a denial of service attack
like this. We've got a pizza shop, so we're going to put this in sort of in real life terms. And
this pizza shop takes phone calls, you can call up, order your pizzas, so we've got an attacker
and what the attacker decides to do is pick up their phone and call up the pizza shop. And
then when they call they just rant, they don't order pizza, they just waste the time of the pizza
shop owner. Now whilst the pizza shop owner is there on the phone, he eventually figures out
that, hey this is not going to go my way, the guy's not going to order a pizza, hangs up.
Attacker calls back, pizza shop hangs up again, attacker calls back again and the thing just
keeps going over and over again. So what's happening is, every single time the attacker is
talking to the pizza shop, they're tying up the line. Now if we bring in a customer and the
customer actually wants to order a pizza, and they try to get through, the line's tied up, DoS
attack happens. So this is a denial of service, the legitimate user of the service is denied
access to it by virtue of an attacker tying up the resources. Now this is one attacker with one
line who's disrupting everything. And obviously when it comes to being resilient to a denial
of service attack, a pizza shop with one line doesn't have much redundancy. So let's move on
and we'll talk about DDoS So now we're talking about a distributed denial of service attack.
So in this case, the pizza shop goes, I'm going to fix this. I'm going to have multiple different
phone lines. And then the attacker comes in, except it's not just one attacker. It's going to be
multiple attackers, all with their own phone, all dialing into the pizza shop and they're all
tying up the resources. It's distributed because there is more than one attacker. And of course
when there is more than one attacker, the effective bandwidth that they have, and in this case,
the bandwidth is the number of phone lines they can use, increases. Now what this means is
our customer gets denied service again. When we put it back in technology terms and we talk
about a distributed denial of service attack, we're normally talking about multiple different
nodes across the internet and multiple can mean thousands and thousands of nodes. Sending
as much bandwidth as they possibly can to the target that they want to take offline. Now there
are different ways of doing denial of service attacks, with different protocols they can mount
it over, TCP, UDP, ICMP. All of these different protocols that can be used, they can do
things like amplify the attacks, using tricks such as DNS reflection attacks and other ways of
making small requests that then turn into large responses that get sent to the target site. A lot
of data and nuts and bolts we won't get into now, but the one premise is that in a DDoS, so
much traffic gets sent from so many different places that the site just gets overwhelmed and
they can't respond to legitimate requests. Okay, makes a lot of sense. So how did this actually
approach the Nissan attack? Well what it meant for Nissan is that they kept getting hammered
by these rogue packets and their website went under. They couldn't keep the website up
whilst that DDoS attack was being mounted. And then you get into this situation, once a
DDoS attack is happening, what's going to give first? So is the attacker, at some point in
time, going to stop the attack? So for example, if they're paying for a service to mount the
DDoS attack, and we'll have a look at a service that does this sort of a thing in a moment. Do
they get to the point where they go look, I can't justify paying for it anymore. Problem is the
services are really cheap. Particularly when the services are just using infected machines that
are part of a bot net and often this is the way DDoS attacks work. There might be a bot net
with 10, 000 machines that have been infected, the bot master says, okay all you 10, 000
machines, you're all going to start sending packets over to this one source. Now that's not
really costing the bot master and I think because they've stolen the resources of the computer
anyway. And they might only charge dollars per hour to run. The other thing that might give
is the target, in this case Nissan, may fend it off by a variety of different techniques. So one
thing they may do is they may scale up resources to absorb the attack. So particularly in the
era of cloud computing, it's easy to say, just add more service. Add more resources and yes,
we're going to pay for it, but if we add more resources such that they can absorb the attack
that's coming in, well then they can stay online. Now that starts costing them money, so at
some point in time, they want to go back to normal, but it keeps them going. There are other
mechanisms as well, so there are, particularly in recent times, where DDoS attacks have
become very, very big, we're seeing the emergency services like Cloudflare. And Cloudflare's
become very well known for fending off DDoS attacks. So they wrap around your
infrastructure, all the requests go through them and because they're absolutely ginormous and
there is a Pluralsight course on beginning Cloudflare security as well, by the way. Because
they're ginormous, they can absorb all of those attacks and they can protect that origin's
server and still allow legitimate traffic to come through.

Coordinating a DDoS Attack with Low Orbit Ion Cannon (LOIC)

So I mean, you just mentioned that it doesn't always necessarily have to be people in
individual systems, some of this is actually done through, as you pointed out, the bot nets and
you can collect a lot of nodes very cheaply, but then also sometimes there's actual
coordinated attacks as well amongst groups. So I mean, from a admin's perspective, is there a
different way to think about it or is it really, you know what, a denial of service is a denial of
service, I just need to figure out how to get enough resources that either the pipe's big enough
or it's deflected? Yeah, good question, and let me answer actually, something else you just
said, because it made me think of another slide I want to show you, then we'll talk about the
admin. You talked about a coordinated group of individuals as part of the denial of service
attack, which I guess is a bit like the slide here with the attackers all phoning at the pizza
shop. One of the things that we've seen many times before is tweets like this and we're seeing
here, we're seeing Anonymous and hacktivists, lots of "Fire your lasers. " Targets, and we're
seeing this acronym LOIC, which is the Low Orbit Ion Canon. And I want to show you what
LOIC is, because it's a tool that's really extensively used by activists mounting DDoS attacks.
So this is the LOIC tool, it's a free software, you can go and grab it from SourceForge. Don't
go and grab it from SourceForge, because it doesn't have any legitimate purpose, other than
to show people how easy denial of service attacks are. So this is the first tool that we're
showing today that really, there's nothing ethical about it. Yeah, now that you've seen this,
don't do this, don't run it. Now having said that, if you run it as an individual, it is not a
distributed denial of service attack, it is just a denial of service attack. And your chances of
taking anything at all offline are pretty minimal, but here's how it works. Just so that we can
understand how these attacks are being mounted against particularly large web assets. What
you do is you put in some sort of a URL, example. com, for example. And you lock it on and
it resolves it to an IP address. And then you say, okay well look, I'm going to choose, what
sort of method we want, so you know, what sort of protocol do we want to throw packets at it
with, it might be HTTP, you choose a number threads and then you just go and hit the
"IMMA CHARGIN MAH LAZER" button and as it says there, "I sincerely hope "you can
guess what this button does. " I sincerely hope that you know what you're doing, if you're
using this tool in the first place, because it's not going to work out well for you. But this is
how simple it is. Now when we see these tweets in the background here, when you can get a
critical mass of people that are all running this tool at the same time and you've organized
them together via social media, for example, and they all point it at something like PayPal,
which is what we saw happen some years ago, in protest of the fact that PayPal stopped
taking Wikileaks donations, and it was actually pretty effective. They actually took down
very large sites, because they had 100s if not 1, 000s of people at the same time, hammering
away with as many requests as possible, as many simultaneous threads at a particular website
and they were effective and then consequently a lot of them got arrested, too.

Exploring Automated Tools for DDoS Attacks and How to Prevent Attacks

So we just looked at LOIC and LOIC is a very manual service. You've got to get enough of
your mates together, invested enough in attacking a site to make it work. I thought I'd show
you just one example of an automated tool and there are a few of them around. And I've just
gone to the URL, but one of the curious things about this is that this is not the service, what
we're actually looking at is Cloudflare, who I've mentioned a couple of times before and
Cloudflare are very good at providing DDoS prevention services for when someone is
mounting a DDoS attack on you. Unfortunately a number of attackers also use them to
protect their DDoS service which is used for mounting DDoS attacks on other services.
Which is paradoxical I know, however, we've just got to prove that we're not a robot and we
should be able to tick that box. This time it's not really confident that I'm genuinely not a
robot, so we grab everything that's got some grass on it, which is those guys, verify and now
we can go through. Now burying data centers since 2015, and this is sort of a good example
of the way these organizations represent themselves and to be fair, when we say
organizations, they're usually a group of individuals who do a very good job at keeping their
identities anonymous because what they're doing can be rather illegal. You often hear them
referred to as stressors or booters and you might see various verbiage on the site, which talks
about stress testing. What they don't normally explicitly say is you're stress testing other
people's stuff. Like this is not for stress testing your own websites, these are not legitimate
services by any means and in fact, there's quite a bit of info on this page that then, makes it
quite clear what the intention is. But the reason these are powerful, is because they'll have a
number of different cloud services, sometimes they'll have bot nets behind them. You go in,
you usually pay in anonymous crypto-currency, like bitcoin, you declare who your target's
going to be, how long you want the attack to go on and then that's it. And you pay a little bit
of bitcoin and you go about your business, job done. And it's worrying just how easy it is to
mount a DDoS attack using these services. And then you compare that to how hard it can be
and how expensive it can be for the organizations protecting their assets to actually fend off
the DDoS attack. Are there technology advancements that can come from new approaches to
infrastructure or other things that could actually mitigate these even having any value in the
future. There are certainly advancements around things like dedicated DDoS prevention
devices that can do things like the statistical anomaly analysis that we spoke about before
with the IPS where they say, we know what good traffic looks like, this doesn't match the
pattern of good traffic, probably bad traffic, therefore we'll block it. So there are devices that
do that but again and I know I keep harping on the Cloudflare thing and it's not just them,
there are other organizations that do it. I love the DDoS prevention as a service model where
you wrap it around, you pay for it when you need it and that's it. So there are various different
options that you guys have when you're actually protecting your infrastructure. You can go
down and get the physical devices, you can get the virtual services. We've got options
available, but they're the things that you need to think about well in advance. Particularly if
it's going to be something physical to you ship to your premise. I think that the one thing that,
just to really emphasize here, is the fact that there is an illegal component. It's 100% illegal
but also the fact that it's not as effective now with the proper mitigation. And so from an
admin's perspective, this is why you're setting up proper DDoS mitigation. And at first to
make sure that someone can't sit in their room and just take down your site. From an admin's
perspective, distributed denial of service is something that you want to be thinking about
before it happens. Because once it does happen, your site is offline now. And in the DDoS
ethical hacking course, I show some figures about how much it costs websites that are offline
and the figures can be absolutely staggering, particularly if you're an e-commerce website
and you're relying on customers to pay you money. Even if you're a media site and you're
relying on add revenue as well. Once that traffic dries up, it can get really expensive, really
quickly. So the thing they're talking about in the course that can be really useful, I mentioned
before, absorbing the attack, so do you have infrastructure that you can scale out on demand?
Modern cloud infrastructure, very, very good at doing that. Are you ready to use DDoS
mitigation services. So, I've mentioned Cloudflare, which I think does a really good job of the
way they work. Is Cloudflare the sort of model that you may want to sit behind in advance of
an attack, because if you wait until the attack happens, you're going to have outage, for some
period of time. And it's probably not just going to be minutes, because you need to do DNS
re-delegation and stuff like that as well. So one thing that we've talked about on these
previous hacks is like as a developer, you need to make sure that you are thinking about this
stuff before it actually happens. In this case, there's really nothing that has to be created
incorrectly on your web app, in order to make this viable. Yeah, so this is the bit which is
hard for those of us who are developers. This is not exploiting a risk in your code. Not
directly, I'll come back to it, it's a little bit of a caveated statement there. But this is not like
SQL injection, where you've got a fundamentally flawed piece of code or XSS, same thing
you know, you've got to have bad code, in order for it to happen. This is, you have a website,
it is online. You know, criteria met, tick, move on. Now having said that, if you're going to
mount a distributed denial of service attack against a web application, you would be looking
for a component of the web application which is the most resource intensive possible piece of
the software. So for example, if you were being very security conscious and using a slow
hashing algorithm and it took several 100 milliseconds to log on and high CPU overhead,
you'd target that as an attacker. And this is the paradox, because we want slow hashing
algorithms, that take 100s of milliseconds to log on but that becomes a really attractive target
for a DDoS attack. So the mitigation there might be, do we actually need to think about
logging on via a different infrastructure to which we then use to browse the rest of the
website. Do we need to add other mitigations such that the actual hashing of the password
only happens once we have a degree of confidence that it's not an automated attack. Do we
even need to feature toggle the app so that we can turn on a recapture at a moment's notice at
the log on page. We don't want to have recaptures on the log in page but I really don't want to
be DDoS:ed either. So that might stop that attack from happening, frustrate people a little bit
then the attack goes away and you turn it back off. So there are design decisions that
developers can make but again they're the sort of decisions you've got to make in advance of
the attack happening because it's kind of too late, once it begins.

Corporate Espionage and Troy's Vulnerability Discover with Nissan

So outside of the two cases for DDoS attacks we've talked about one is sort of that hacktivists
approach and the other is, I guess I'll call it the illusionist approach of, look over here while I
take your wallet out of your pocket. Is there any other reason that we see these type of
attacks? Well there's corporate espionage. So if you were an organization that, let's be honest,
would be on the shadier side of things and you decided that you wanted to take down a
competitor and you went and you paid for one of these services that can mount these attacks
and I'll show you one of those in a moment as well. And you paid some small amount of
money and you did it very anonymously and you took the competitor down, there'd be a
competitive advantage to that. Again, very, very shady activity, but we've certainly seen it
being done before. So as we've go through this, we've sort of talked about, one hack or two
hacks, or two ways of attacking a given vendor. Now Nissan has been exploited in a couple
of different ways over the years, so how about you share a little bit of your findings of
something you discovered with the help of some others recently. Yeah, so in fact this is
interesting from the perspective of how easy it is to find vulnerabilities. So I was running a
workshop in Norway earlier this year and one of the modules that I do on my workshop is it's
effectively hack your API first, so there's one of the Pluralsight courses is the same thing,
where we look at how can we intercept traffic from a mobile device to an API and then have
a look at what's going on with the traffic. And one of the guys in my workshop, he did this
and then he got inspired or something like that and he went back to his hotel room and
discovered that when he was controlling his Nissan Leaf and he was controlling the climate
control features, pulling back his trip history, doing all of this with his phone, the only way he
was identifying the vehicle that he wanted to talk to, or rather the app was identifying it, was
via the VIN number. And the VIN number is a very predictable series of letters and numbers,
it's printed in the windscreen of every vehicle and it's easily enumerable and the theory we
had was, that you would be able to change this to another VIN number and you would be able
to control someone else's climate control and pull back their trip history. And he came into
the workshop the next day, very excited. We established that that was the case, we managed
to find one other vehicle where we could passively look at the state of the battery and at that
point we went okay, that's enough. We've established that this is a risk and we ended up
disclosing it quietly to Nissan and it did take awhile, but eventually they shut down the
service and they were offline for quite awhile, whilst they fixed their Nissans.

Thinking Defense in Depth and Educating the Masses

So this brings up sort of the discussion around defense in depth, we've talked about things
isolated, but I think that it's really important that we sort of start to wrap up this discussion
making sure that people realize that these are not always isolated things. We can't think about
things as, I'm going to buy something off the shelf, install it and it's going to fix all my
security woes. So like, what is your approach to the defense in depth model, in mindset?
Yeah, so the off the shelf thing, there is no security in a box folks. Like, you don't just, you
don't buy it, there's nothing that you can install which will do everything. There is no physical
appliance you can put in your infrastructure that will fix everything. There are people who
will sell it to you, don't get me wrong. But it won't work, it doesn't work like that. So, yeah,
you've got to be thinking about where all those weak spots are. And I think as we talked
about DDoS, that was actually a really good example. So defense in depth for DDoS is, do
you have the ability to absorb the attack if you need to as an immediate defense? Are you
already set up with a provider who is able to give you DDoS protection, if you need it? The
application built by the developers, does that have functions which may be at greater risk of a
DDoS attack? Can we extract those out to places where it doesn't take the whole system
offline if that happens. And this is just for one risk and we've just gone through five different
sections in this course. So there are plenty of different places that can happen but the defense
in depth is looking at the physical infrastructure, the design of the app, the logical
infrastructure, if you're on cloud services and trying to find all those different weak spots
within there that you can strengthen one by one. And as a security professional, how do you
educate non security focused admins, developers, business leaders, decision-makers of these
situations because we're all in resource constrained environments. Security always seems to
be the last part of the development lifecycle or sort of the afterthought, whatever it might be.
What are your lessons that you've seen work that we can pass along to individuals to help
with that. So the biggest thing that I've seen resonating with every level of an organization is
impactful demonstrations. And look, I mean, if you've watched other play by plays or other
Pluralsight courses you've probably seen impactful demonstrations. You and I have done the
Pineapple thing before right? Great example, $100 Wi-Fi Pineapple, you start hijacking
people's phones. It's a hipper phone, it's very educational as well. Do so ethically. So that's a
good example of showing in other courses things like using Havij and SQLMap, it's a GUI
where, an in fact I mentioned it earlier on, I did a video where I showed my three year old
how to use it just for the sake of showing that if someone knows how to copy and paste a
URL and I had him mount a SQL injection tag. So that's something when I demo it, I
normally get someone from the audience or someone from the room to come up and I'll go,
"Okay, I'm going to teach you how to do hacking. " You know, go to here, copy and paste
this URL into there, press that button, job done, there's all your data. So I think the most
effective way of educating people, is to let them actually see what happens and for us as
technology professionals, I'd be saying have a think about what are the things that you can
demo in this way. There are sites out there that are designed to be deliberately insecure,
specifically for these purposes. There's one that I use in a lot of my courses. There are these
tools that you can buy, like the Pineapple. I think we did the Rubber Ducky at one stage as
well. They're very good at demonstrating these things. Very, very impactful tools and that is
just a great way of making an impact. Well in addition to impact is also education of the
masses i think. And we touched on this in the talk talk, we also touched on this just in the
way that you approached proper disclosure with Nissan, but as a security researcher, how do
we get this information out to the public in a way that does catch traction, but also doesn't
create unneeded fear for, we joke around, cyber Armageddon. Yeah right. An unneeded fear
at that too, because we want to be responsible so we're not the boy who cried wolf. I guess we
see this in the headlines sometimes right, where you see a headline and you're sure the world
is going to end, like this hack is so bad, we're never going to recover from this and you can
understand why the press wants to do it right, they want to sell headlines. So, I think there are
multiple things and one thing is, for us as professionals not to overly sensationalize things.
Look, you want to make an impact and you want to make sure that people understand how
serious some of these things are. But yeah, let's not make it into something that it's not, like
you're still going to get home, everyone's going to be healthy and happy. It's a piece of
technology, let's just properly account for what the risk is, what the impact is and then sort of
deal with it in a rational way. It frustrates me no end, when we see headlines, recently we saw
headlines around things like 217 million emails hacked out of Gmail and Hotmail and Mail.
ru and it all turned out to be fake: That just wasn't the case at all and obviously this had been
perpetuated by the media and probably by some security folks who hadn't gotten their facts
quite right. So I think for us as professionals, we've got to make sure that we're objective,
we're rational, we explain what the actual risk is, and we also have confidence in the
legitimacy of it. So I see a lot of data breaches turn up and very often the data breaches are
fake. You know there's one allegedly from Twitter, doing the rounds recently, 30 million
Twitter accounts and one look at the data and you go, that's not from Twitter, no chance. But
that's what the headlines say. So we've got to be a bit responsible as security professionals as
well.

Conclusion

Well, I appreciate the time today. I mean, obviously we've covered a lot of things at a very
high level. I would assume many of your courses, actually I know many of your courses go
much deeper into all of these things with our ethical hacking series, so if there's anyone who
is interested in diving deeper on any of theses topics or many more definitely go to the path
that covers the ethical hacking series. As well as, you mentioned your Cloudflare security
course, I trying to think are there any other things that we'd like to highlight today, as follow
ups? There are a lot of courses. (laughing) Look I think you've summarized it pretty well.
Pretty much everything we've discussed is there in a course that is specifically about that
subject. Excellent, and then of course troyhunt. com and That's still there. @troyhunt on
Twitter. That's still there, yeah. Perfect, well Troy, thank you very much for coming in today.
Thanks Gary.