Builders versus breakers
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Hunt, Troy
Is it just me, or are we seeing more online attacks leaking more data year by year? Actually it’s not just me because the statistics are there to prove it. In fact the largest online breach we’ve seen to date was less than six months ago when Adobe became the victim of a 152 million record attack. A couple of months later and Target saw 110 million credit cards stolen making it the largest theft of financial data ever. In fact all told, we’re looking at in the order of over 822 million records gone missing in 2013 alone. The thing is though, when we look back at recent attacks with the clarity of hindsight, they’re almost always easily preventable. Somewhere, somehow, someone had a major oversight in their code – or often many major oversights – that somehow slipped through the cracks, made its way into a production system and was consequently pounced on by someone with malicious intent. In this session we’re going to look through 10 examples of online attacks that should never have happened. Sometimes it’s a single easily preventable flaws in code, sometimes it’s social engineering of people with access to valuable data and other times it’s a chaining of individual risks knitted together in order to compromise the target. We’re going to systematically work through each of these 10 attacks, understand what went wrong and then assess how each system could have been built to be resilient to the attack. The lessons learned in this webinar are intended to help you better secure your systems by learning from the mistakes of those who have gone before you.
 All right, welcome everybody. Sorry about our little technical dramas there. You're losing about 10 pixels of my right hand side, but that's going to matter. So hello, everybody. My name is Troy Hunt. I'm from Australia. I'm going to talk more about Australia on Friday. I've got another session on Friday that's going to go into a lot of detail about some attacks. We're going to break some stuff on Friday. But today I want to talk about a bunch of attacks that we've seen in the past, how they've worked, and what we can learn from them, what we can do differently in future. And where I like to try and start these talks is to take a little bit of a look at why it is that we're bothering to talk about web security. So I have this slide where I put a whole bunch of company logos on. And every time I do this talk, the logos have to get smaller and smaller and smaller because there's so many more of them. So I've got things like eBay from a couple of weeks ago. Didn't have that last time I did this. So it's an ever-expanding list. And what I find really interesting about this list is the diversity of organizations that are represented. So we're seeing everything from shopping centers to telco to military contractors like Lockheed Martin. I'm not sure what things like prong.com are, but there's a really broad range of websites that are represented. So it's not discriminatory in terms of who's getting attacked. Also not discriminatory in terms of why people are getting attacked. If it's on the internet, it's pretty much fair game. So before I jump into the actual attacks themselves, one thing that I think is quite interesting is the way attacks are changing in terms of scale and volume. And one of the things that I find really stark is this graph here about attacks over time. So this goes from about April 2010 through to about the middle of last year. And I picked this range because I did a course on this recently for PluralSight in terms of the changes between versions of the OWASP top 10. Is anyone here familiar with OWASP? Just show of hands. And it's maybe a third, not too bad. So just a quick diversion. OWASP is the Open Web Application Security Project. And they're not for profit organization. And they create a bunch of material to help us build safer websites. And one of the things they create is a document called the Top 10 Web Application Security Risks. And it talks about things like SQL injection and cross-site scripting, how they're executed, how to protect yourself against them, and how to do it in different languages as well. So a lot of the stuff that I talk about and write and create material on is around OWASP. So I'm going to come back to them a few times. So anyway, this was the difference between web security in the OWASP 2010 version and the OWASP 2013. And what I was trying to show is just how much the attacks are increasing. So up until about the middle of that graph, we're under about 100 different attacks a month. We get through it at the last half and now we're up around that 250 plus mark. So we're seeing a lot more. This data is from datalossdb.org. It's a great site for listing breaches that have occurred and it explains who did it and how they happened. It also only explains the ones we know. So there's 6,000 breaches there that they've recorded that we know of. There's a hell of a lot more that we don't know of. Now one of the other interesting things beyond just the volume in terms of the number of breaches is the amount of data that gets disclosed and compromised in each one of those breaches. So what we're seeing here is that the records that attackers are getting their hands on are increasing dramatically. 822 million records last year, nearly doubling previous hype. So that's really significant. We're getting towards a billion records there in 2013 alone. So I think it's some of the big ones. 2013, everyone probably heard Adobe got attacked. 152 million accounts from Adobe alone. Most people know Target had huge issues. 110 million credit cards in 2013, in about December. And already this year we got eBay. So eBay says we've had 145 million active users compromised. But I don't tell you how many inactive users. I don't know how many it is, maybe 300 million. It's a lot, significantly higher than 145. So we might find that 2014 is the bumper year in terms of data breaches. So last thing before we get into some of the attacks. And this sort of looks at what were the top 10 breaches in terms of the records that were compromised and when did they happen? And there's an interesting little pattern here. When you have a look at the dates, five of the top seven were in the last 10 months. So that's massive. This is tracking stuff that goes all the way back to the 80s. But five of those top seven attacks happened since August last year. So we've got this problem where they're getting more and more and more attacks and they're getting bigger. Each one is getting bigger. And again, 145 million from eBay, plus all the other ones I don't tell us about. All right, so let's jump in. We're gonna look at 10 different attacks that have happened over recent years, happened online, and we're gonna look at how they happened and what we can do to stop them from happening again. So the first one, pretty simple run of the mill SQL injections. This is Bell in Canada. This is a telco in Canada. Earlier this year, they got popped by a SQL injection attack. And what ended up happening was about 22,000 records that were compromised, no cryptography at all on passwords, no encryption, no hashing. Very important difference between those two as well that we'll talk about on Friday. Now, so we've got 22,000 records, they all get exposed and because it's a hacktivist, what a hacktivist do? They whack it all on paste bin. And of course, this is terrible for a company because not only did they get hacked, but now all their users credentials are somewhere public. Now we know it was SQL injection because the attackers told it was SQL injection. They posted a really nice screen grab. The thing about hacktivists, they love telling you how they did it because it's so intelligent, it's so clever. Look at what I did. This is a free plugin to Firefox called Hackbar. And what Hackbar lets you do is do a little bit of fuzzing on HTTP request. So what I mean by that is that you go to a website, you make a legitimate request. So this is a password recovery page. It was making a post request which inevitably has something like the email address you want to recover the password for. I really hope they didn't actually just email the password but I reckon they probably did because they're all in plain text anyway. So anyway, you make the request and then you use Hackbar to capture that request, manipulate some of the parameters and see if you can get the web application to actually throw some exceptions. Now in this case, we can see down below it is actually throwing an exception, Microsoft OLEDB provider. And it's giving a conversion failure where what's actually happened is the attackers have tried to get the version of the SQL server. And we can see it is Microsoft SQL server 2008 R2, blah, blah, blah, blah, blah, blah, blah, blah, blah, and cast it to an integer. Now it's a string, why it cast to an integer? It's got lots of letters and things that really aren't conducive to integer. So SQL servers thrown an exception and the exception is bubbled up into the web browser and disclose the fact that this is what the database is. That doesn't sound too bad, but that technique is then used to get the table names and the column names and the data. And if that sounds hard, on Friday, I'll show you how any of you can do it with your own websites. Very, very simple. So there's a few things that we can take away from this attack. And the first thing is SQL injection is the number one attack on the web. And it's a number one attack for a few different key reasons. Number one is it is really, really prevalent. There is so much SQL injection out there, it is not funny. And one of the things I'll also do on Friday is show you how to find sites with SQL injection and just how easy it is just via Google search. So number two is that it is extremely easy to exploit. If you can copy and paste, you can mount a SQL injection attack because there are free tools that just make it dead, dead simple. Because it is so simple, that's why we see kids turning up at court with their mums who are always really pissed that their kids have been hacking websites. And it's these kids that don't necessarily know anything about SQL injection or web security, but they know how to run these free tools. Now, the third thing is it is easy to exploit. Those tools have easy, easy exploits and the impact is really, really high. So if you get all your data exposed publicly, or your customers passwords, for example, that is a massively high impact. Cross-site scripting isn't great, but it's a much lower impact than something like SQL injection. So we're also seeing a lot of automation. So I mentioned that there's a tool that I'll show on Friday, very easily available tool. You copy, you paste, you put a link in your hacker website. Talk to my three-year-old how to do it, that's how easy it is. Now, unfortunately, we do have these problems because as developers, we're doing some pretty sucky things with the web. We're building these vulnerabilities into the applications. Now, we know about these things. They're in iOS, they're very well documented. We've all seen the news about how many websites get breached. But we do keep building the same risks. Now, the other thing you wouldn't have seen, possibly wouldn't have seen on the previous slide, is the URL was a.asp extension, classic asp. This is the thing that was done 12 years ago. We replaced it with.net. It was from a much more innocent era. It's not designed to be as resilient to these sort of attacks as things like modern asp.net and other modern frameworks. So running on technology that old is always gonna make things harder. It's always gonna put you behind the eight ball. So that was SQL injection. Next one I'll talk about is Matt Honan and his epic Apple hack. Now, Matt was a reporter for Gizmodo and Wired. And Matt got up one day and his iPhone powered down and consequently wiped itself, which is never good. And what eventually it was that the attackers had managed to compromise his Apple account. But how they did it is the interesting bit. So the attackers called up Amazon and they said, hi, I'm Matt. I would like to put a new credit card on my Amazon account. And they go, okay, cool, what's your name? What's your email address? What's your physical address? So three pieces of data. And then they go, okay, cool, give us the credit card and we'll put that on your account. So he does that. And then the attacker calls up the next day and says, hi, I'm Matt. I'd like to change the password of the account. And they go, okay, well, to do that, we need your name, your address, and your credit card number. Oh, interesting. So you can actually call up Amazon or you could at the time and set a new credit card and then call them back and say, I would like to verify my identity by giving you the information that I just gave you yesterday. So that allowed him to get access to that Amazon account. Now, once he had the Amazon account, he could then go through and find the last four digits of Matt's other legitimate credit cards. Not the whole thing because that would be insecure. But he could go in and see the other cards and all of us can do this on many of our accounts. Go in there and your card ends in three, two, one, five, whatever it may be. You can get those last four digits. Now, with those last four digits, the attacker could call up AppleCare and say, oh, funny thing, I forgot my password. And they go, all right, well, what's the last four digits of your credit card? Glad you asked. Here we go. So you see how he's starting to jump from one service to the other. So once he's in AppleCare, then you're into iCloud and you're into Apple's ecosystem because he's got that account. So he managed to get a temporary password, get access to the Apple account, and once you got access to the Apple account, you can start doing things like wiping devices. And we'll have a look at that in this demo as well today. So he's wiping devices. The other thing about Apple is Apple has the me.com email service. And Matt unfortunately used me.com as a password reset channel for his Gmail. So you forget your Gmail password. You add a secondary account that they can send a reset to. So he managed to reset Matt's Gmail account. So once you can reset the Gmail account, he can get into there and then he can do things like reset the Twitter account, which apparently was the ultimate goal to begin with. And the attacker went and sent a whole bunch of racist tweets and then deleted the Gmail account as well. So it didn't end up real well for Matt. And as Matt puts it, it only took an hour. His entire digital life was destroyed because the attacker basically just had four digits of a card number. So pretty nasty stuff. There's a few interesting things with that. And the first one is, and we're gonna see there's a bit of a theme today, the interlinking of accounts can be really problematic. So the fact that the attacker was able to explore the vulnerability with Amazon's verification system ultimately meant that he could take over the guy's Twitter account. I mean, that's several hops. But because we have all these things so intrinsically linked together, it often leaves us more vulnerable. There are also different views of the sensitivity of the data from different companies. So Amazon was happy to just accept something like a card and then read it back to you. But Apple, that's their verification process. So Apple had a very, very high level of sensitivity on those last four digits of the card. And it's probably got you thinking now, how many places have I got four digits of the card? If it's four digits, it doesn't come under PCI DSS, it doesn't all have to be encrypted. You can read display it back to people. It's on a lot of your receipts. Go through the garbage bin. You'll find a lot of four digits. Now the other thing is, and this was a couple of years ago, so a little bit before two-factor authentication became really popular, but there was no two-factor authentication on the Gmail account, on the Apple account, on the Twitter account. So there was no second channel beyond just knowing the passwords. That's all they take in need of the password. So where you have two-factor available, turn it on. So Apple and Twitter, I mentioned things like GitHub. A lot of people here probably use GitHub. They've got two-factor authentication. They've had brute force attacks against people's accounts. You definitely want to have it on there. And of course, the other thing is, is that as people, we are vulnerable to social engineering. A lot of security professionals say that really the people are the biggest problem. We can only do so much with the systems, and the systems will pretty much do what we tell them to do, but the people are the one that keep getting exploited by the attackers. And there are many, many different ways that we can socially engineer them. We'll have a look at a couple more throughout this preso. So who remembers MySpace? It was a thing. Some time ago, it was the thing. It was the thing in 2005 when a bloke called Sammy decided he needed some more mates. Now, for most of us, we'd try and be popular and we'd try and socialize a little bit and maybe do things that other people are interested in. But Sammy was a bit of a gun with cross-site scripting. And he decided it would be much more effective if he wrote a nice self-propagating cross-site scripting worm. Now, what it meant is he could write this worm with a whole heap of XSS. He could put it on his MySpace page. Someone comes along, they look at the MySpace page, and they automatically befriend him because there's script that he's put on the page which fires off the request to actually befriend the guy, and it puts a message on the person's page that says, and most of all, Sammy is my hero. So this was great. So people that came and saw his profile would get that on their page. But because he was a smart guy, everybody who then came and viewed their pages also got compromised. So it kind of spread. It hit a million people in less than 24 hours. That is a very, very bloody, effective cross-site scripting attack. And it looks like this. So clearly cross-site scripting can actually be rather complex. Now, the idea is not to read what's in here, but it's to make a point that this is actually pretty sophisticated. Now, this was 2005 as well. So we've well and truly moved into the space of much more sophisticated cross-site scripting attacks since then. So that was an interesting one. And it told us a few really interesting things. And one of them is that cross-site scripting is very serious. So a lot of the time when we do maybe a proof to demonstrate that a site is at risk of cross-site scripting, we'll pop up an alert box. Hey, follow this link. Oh, alert. Funny cats, whatever it may be. There's actually a Twitter account called XSSKittens. And it links all of these links to reflected cross-site scripting. You click on them, you go to a shopping website, and there's cats all over it. And he just goes nonstop because there's so much stuff out there at risk of XSS. But it can be very serious. So other proofs we often see for XSS is doing things like taking a copy of authentication tokens in cookies and sending it off to an external service because the cookies weren't flagged as HTTP only, and the XSS was enabled on the site because they weren't encoding and all sorts of other things. So it can actually be very, very serious. I mentioned before, it's also in that I was top 10. It's number three in 2013. It was number two in 2010. So it's gotten kind of a little bit better. But it's still a serious, serious problem. Now, protecting against XSS is also very easy. And this is sort of a common theme. Things like SQL injection and XSS, it's not hard to stop it if you know what to look for. So a couple of things there that make it very easy to protect against XSS is validating untrusted data. So when a user provides a URL, or say query string and parameters, or when they submit a form, or when you read request headers, when you read the language of the browser, or when you read the user agent, all of that is untrusted data. And validating that it conforms to an expected pattern is really important. In the one we'll have a look at on Friday, you can take integers and start attacking via integers because they're not actually checking that when the integer goes to the website that it is actually an integer. They just go, oh, look data. We'll take that and we'll put it in our query. Encoding all output is the other big thing. So frameworks like ASP.NET MVC do a very good job of encoding by default. So what I mean by that is if you try and send a script tag to the site and the site reflects it back, so like when you do a search and it says you searched for, instead of actually rendering script tags into the HTML source, it'll encode it. So you get amp for send less than amp for send greater than and then in your browser, you actually see rendered script tags. So they're really two very, very simple things. And again, a framework like MVC does it for you automatically. Framework like classic ASP doesn't. That's why every time you see a dot ASP extension, almost for sure you'll find SQL injection, you'll find cross-site scripting. Very easy done. All right, so HB Gary Federal. Now this was an interesting one because these guys were security professionals and they were providing services to the US government. And the bloke running that, Aaron Barr, was very proud of the fact that he believed that he had unmasked Anonymous, the ring leaders of Anonymous. And he made the mistake of telling them that he thought that he had unmasked them and they didn't take too kindly to that. So they hacked them. And the way they did it is they found a SQL injection vulnerability in the content management system of their website. This may have been one that was known already. It may be one that they found on their own. Either way, they managed to get credentials out of the database. And again, it can be really, really easy to do this. So they got usernames, emails, and they got hashed passwords. MD5 hashed passwords. MD5 hashed passwords are useless. SHA1 salted hashed passwords are useless as well. And if you're doing that, we're going to have a look at that on Friday and we're going to break a heap of them and probably upset a bunch of people. But you need to see how easy it is to break bad hashing implementations of credentials. Now, because it was just an MD5 hash, the attackers could use rainbow tables to convert the hashes back to plain text. Well, they don't really convert them. But what they do is they take these pre-computed tables where it says, for all these plain text strings, these are the MD5 hashes. And then it just matches the hashes with the ones out of the database and says, well, that must have been the password. Now, as the CEO of a serious security firm, clearly he had a very good password, which is this one just here, which is all our case with two numbers. And because it makes life really, really, really convenient, he reused it across everything. So that wasn't good. So there, the attackers have the password in plain text and it's reused across every account. So that allowed them to do things like gain, shell access to the Linux machine that their web application was running on. And then because these guys weren't actually patching their environment, exploit a risk that had been publicly disclosed, patched months earlier, exploited it, elevated privileges, and started pulling down gigabytes and gigabytes of emails and other documents and things like that off this public website. Now, the guy behind all that was this bloke, Sabu, was the handler he went under, the leader of Lowell's Sec. Now, this guy is a very, very old hacktivist. He was actually in his late 20s. So very, very old for a hacktivist. But a bunch of his mates were teenagers that did end up in court. Sabu ended up being caught by the feds. He got turned, he became a snitch. He then allegedly helped them bring down 300 other attackers or potential attackers. And in fact, just a couple of weeks ago, he finally was released with a suspended sentence after effectively having his life ruined because he liked SQL injecting some websites. So that didn't end up well for him. Didn't end up well for HB Gary either. Obviously as a security organization, if you do these sort of things and get caught, it's probably not real good for your reputation. Now, a few different things that we can take away from this. And a little bit like the Matt Honen thing before, security risks do tend to be chained. And in this case, there was a lot of pivoting. So they'd break into one system via a SQL injection attack and then get enough information to move onto the next and then get enough information to move onto the next. And we often see this happen. And one of the reasons why that's important is because I'll often hear people say, and I'll take an example, it might be that they've got a SQL injection risk in the admin section of their website. And they go, it's not really a problem because you've got to be logged on as an admin anyway. So, you know, it's okay. But it's this whole thing of not having these single points of failure. Because all of that assumes that the attacker can't get into the admin system. One person reuses a password, gets published, SQL injection gets exploited. So it's about having defense on top of defense, defense in depth. Again, we know these risks. So we know things like SQL injection. And we particularly know things like bad cryptographic storage. Using MD5, bad, using salted char one, bad. Again, I'll show you why on Friday. It's unbelievably easy to crack that. Choosing bad passwords. So it's probably obvious, but somehow we keep doing it. And even the security pros are choosing weak passwords and reusing weak passwords. And that is just opening up this treasure trove of other stuff that attackers can get their hands on. Now, the final thing about these hacktivists is that they're often young. They're often clever, maybe not particularly intelligent, but they're very, very resourceful. And when you don't have a job and you live with your mum, you've got a lot of time in your hands so they can find ways into these systems. And it's interesting when you look at the sort of discussions these kids, and often they are kids, legally, not even 18. You look at the sort of discussions they're having. So I've done some videos on things like automated SQL injection. And when I'm Googling around trying to find information, there's all these other videos that people have made about how to use tools like Havage and SQL Map. And it's just telling that every time the people on the videos have voices that haven't broken yet. True story. So they have a lot of time on their hands and they can be very resourceful. All right, Sony. So Sony had a really, really bad time of it in 2011. And they just kept getting attacked and attacked and attacked and attacked. And a lot of this started with PlayStation Network. So PlayStation Network went offline and everyone was like, where's PlayStation Network? And Sony just doesn't say anything. It just goes on and on and on. A week later they go, oh yeah, we got hacked. So it was quiet for a long time. We've been hacked but it's okay. And then they got hacked again. So the first time was about 77 million accounts. The second time was about 25 million accounts. So they were starting to have a very, very bad month of it. This was only a couple of weeks later. But it's okay, we got under control. Then they got hacked again. And this time it was Sony Pictures. Now what's interesting about this is that Sony Pictures is not PlayStation Network. This is a very different part of the organization. This is now getting into production and film studios and things like that. So clearly there was something about Sony that led to them continually getting owned over and over and over again. Now several very interesting things came out of it. And one of them is that communicating early was really important. And these guys just weren't doing it. They're literally people sitting around going, what the hell's happened? I need my PlayStation, it doesn't work. And they weren't telling people. Even eBay two weeks ago, just in the last couple of days I've had people tweet me saying, oh, eBay finally told me they got owned and I need to change my password. What does it take two weeks? I mean, I know that they've got a huge audience but they've got a lot of resources and a lot of systems behind that. So think about it for yourselves as well. For the systems that you manage, if there is an incident and none of us can assume that we'll never have an incident, if you've got a million customers, are you equipped to actually get them communication fast and early? You know, can you do it in a day or two? Are we gonna be sitting here in a week going, we're still trying to figure out how to email 20 million people? Because that can be a difficult problem to solve. Now with Sony, it was also pretty cultural. So we're looking at very independent parts of a global multinational, developers in different places, systems in different places, different technologies. Hell, it's PlayStation versus a little website somewhere for a promotional campaign. But they all kept getting owned. So clearly there was something in the organization that just didn't have a focus on security. Maybe they didn't have the training for the developers. Maybe they didn't have security reviews or penetration tests or things like that. But it was a cultural thing and you often see this become a pattern. And I particularly find it interesting, you look at a website after it's been breached and you go, well, yeah, you've got like cross-site scripting and you've got other vulnerabilities and you're returning too many headers and you've got directory browsing. You've got all these sorts of things that may not have been the way the attacker got in, but it's part of the broader picture of, hey, these guys probably aren't thinking a lot about security. A little bit of where there's smoke, there's fire going on. Now for Sony as well, it was also massively expensive. 170 million bucks apparently went in to solving their security problems. And one of the challenges we often have in security is that it's really not viewed as a feature. Not in so far as it's not something you give to customers and they use and we're gonna get an immediate sort of value in return on that. It's like an insurance policy. And a lot of companies don't like to spend on it. Even though in many cases, it's simple. Protecting from SQL injection is easy. You just gotta know where to look. Companies aren't looking at that. And I think part of the problem is that they don't see the potential downside. They see there's gonna be an immediate cost, which is to train developers or get a penetration test. But then it's gonna be sort of offset by this potential that we may lose a heap of money later on and that's hypothetical and, oh, look, something new and they move on. So being conscious that there are real, tangible costs when it goes wrong. So number six, Gorka. Gorka was an interesting one a few years ago and it was another sort of case of, in this case, Nick Denton who headed up Gorka, having a bit of argy-bargy, I think it was with 4chan at the time, the sort of precursor to Anonymous. And it was one of these sort of online ego wars, which generally don't tend to end well for the guys that are public and for the most part doing the wrong thing because the attackers don't generally tend to play by the rules. But anyway, Gorka got hacked. They had a very poor cryptographic implementation on their credentials, which made it very easy for the attackers to convert that data back to plain text. So there's nothing too unique about that, but where it got interesting was what started happening to Twitter. So why would you get Twitter spam from people who had just been hacked by Gorka? Any guesses? Reused passwords? Yes? Okay, so people reuse passwords. We touched on that a little bit earlier on with HBGarry, but this was interesting because it was a very sort of broad attack that targeted a lot of people. So clearly the attackers have got their hands on this great big dump of compromised passwords, and then they've gone on a spam campaign. Makes you wonder how complicit Asahi were in that. I don't think they'd be real happy knowing that their brand was being promoted in this way. But the interesting thing about this is it shows how we do kind of become responsible for the security on other accounts. Whether we like it or not, we're sort of implicitly responsible. So several things that came out of that, and one of them is clearly that not all cryptographic storage is equal. And when I was talking about cryptography, they talk about insufficient cryptographic storage. It's not like, do you have it or do you not have it? It's have you done a good job of it. So I know there are a lot of times where people go, oh yeah, we use cryptography or encryption or hashing or whoever they want to phrase it, and they can say yes, we've done it, and they've ticked the box and the auditors are happy and the compliance team is happy, but it's crap. They've done a really bad job. It's not all equal. As developers, we often think when we do do a good job of it, or when we do put a focus on cryptography and the way we store and handle passwords, we think that we're protecting our system. And we are, but what we've got to understand is that we do have some responsibility for protecting other people's systems as well. The other systems where these users reuse their passwords, and as much as we all like to jump up and down and say yeah, well nobody should reuse their passwords, a lot of people do. We've all done it at one time or another as well. I know none of us do it now, but we've certainly all done it, and it is something that happens. So we do have this sort of projected responsibility on these other websites. So the other thing that's a bit interesting here as well is that from Twitter's perspective, this was just people logging into Twitter. Okay, so it looked legitimate. It wasn't brute forcing. It wasn't let me take this username and 5,000 passwords and see if any of them work. It was username, password bang, straight in because they already had the credentials. But people were abusing Twitter. So I guess the sort of the question to think about there is how do you protect your system against attackers using legitimate credentials? In Twitter's case, does it really make sense to have the same spammy looking message go out 5,000 times? You know, maybe that should have set a flag off there. And finally, two factor. So two factor keeps coming up again and again and again. And two factor is the thing that saves you when the thing that we know is disclosed, but the thing that we have is not. So that is a very common theme. So the next one here is quite interesting because it sort of forces you to challenge what you think you know about HTTPS and SSL. So this was Tunisia government and Facebook. And this was a few years ago. And the story here was that at the time, Facebook would load the login page over HTTP. So you'd be looking at HTTP, call it and force it, force it, Facebook.com bang, here's a login form. Now a lot of the time people look at that and they go, oh, you're clearly not secure, right? It's not SSL. But the form posted to HTTPS. So the counter argument is, well, the credentials were protected when they were sent to the server and they're right. The credentials were encrypted when they got sent to the server. If you had have intercepted those packets, you couldn't have done anything with them. So that's good. The problem, of course, is that SSL is about much more than just encryption. So there's only three things I talk about with SSL. And one of them is authenticity. So when you go to a website and you see a padlock in the address bar and you can inspect the certificate and you can see it says Facebook.com, you have a pretty high degree of confidence that it is Facebook. And just by the by, if you put a bitmap of a padlock icon somewhere in the web page, that doesn't make it secure. That's a fricking bitmap. It's not the same as the one that's in the address bar. People do that, believe me. So that was number one, authenticity. Number two is integrity. So when you load something over an HTTPS connection and SSL does its thing, you can have confidence that the content of the page hasn't been manipulated. And that's where it went wrong with Tunisia because it wasn't loaded over HTTPS. You could have no confidence that the page hasn't been manipulated. We're gonna do this Friday as well. We're gonna find a nice site that does that and steal credentials in an ethical way, mostly. And finally, it is also about confidentiality. So the third point was, you do get your data's protected when it goes over HTTPS. People can't actually read what is in there. Now the interesting thing is, is that here's what happens. So this is the way the attackers, and in this case, the attacker is the nation state. This was before we were worried about the Americans, who we know like doing a lot of this sort of stuff, like most other big governments, no doubt. Anyway, what they were doing was they were putting this JavaScript in the page. It doesn't matter too much the detail of this, but what was quite tricky about it is that they were forcing an asynchronous request on submitted the credentials. And that asynchronous request was actually going off to facebook.com, but it was appending the credentials in an encoded query string, and it was also sending them to an HTTP address on facebook.com. And because it was going to an HTTP address, the attackers, the government, could view the contents of it. But if anyone else looked at it, they'd go, what the hell is Facebook doing? Oh, it looks encrypted, of course it's not, it's encoded. Looks okay, but it is going to Facebook. So it was a nice sort of tricky little way for getting around that. Now, there's a few different things that we can take out of this. And one of them is that a little bit like cryptography, SSL is not a have you done it or have you not done it, it is have you done it right. So you cannot load anything over an HTTP connection and not expect it to be manipulated or observed. So you cannot load login pages over HTTP without expecting them to have been changed. You cannot let people view an authenticated page and send an auth cookie over an HTTP connection without expecting it to be sniffed and the session hijacked. So there are nuances to the way that SSL is done that make it very, very easy to do it insufficiently. And this is what I was talking about, they say insufficient transport layer protection. So there's like this degree. And there are certainly degrees of making it even more secure again. So does anyone see fire sheep a few years ago? Man, that was fun. So what fire sheep did is it was a little plug-in to Firefox. And the idea was that you could go into an internet cafe with your laptop. In fact, you could go into here. This place is great because there's no encryption on the wireless. So apparently what you could do here is you could use fire sheep. And what it would do is it would look at the network traffic around you because when you're not on an encrypted network, it is possible to observe other packets on the same network. And it would look for packets. It would look for requests being made to Facebook where the authentication token was being sent over an HTTP connection. And because it was a very nice plug-in and very user-friendly, you'd load the web browser and you'd get a list of all the people in the cafe. You get the photos. So you could look around you and go, oh, there's that guy. Here he is on Facebook. And you could click on him and steal their session because the cookie wasn't protected. So fire sheep was a bit of a watershed moment where people started going, OK, we know we could do this. But when you see it packaged together so nicely and made so easy, yeah, maybe we'd better actually take a little bit of attention and fix it, which is what Facebook has done. Because now everything on Facebook is SSL. Certainly anything that needs to be secure is sent over HTTPS. And I guess that's a good question for you to go away with as well. In your own assets, what are the things you're doing over HTTP that may put you at risk? And again, the classics, loading a login form over HTTP, sending cookies that are not flagged as secure, and they're auth tokens. So if that's a foreign concept, that's one of the things I'll talk a lot about in the PluralSite courses, looking at things like HTTP only, secure attributes of cookies. Because if you don't have those two things, you've got a whole world of potential trouble. Did you note a rest in peace? Did you note that it was a Dutch certificate authority? And a few years ago, did you know it got owned rather seriously by some attackers that managed to start issuing rogue certificates? So the whole premise of this sort of public key infrastructure of certificate authorities is that they're a handful of trusted ones. And they have the ability to issue certificates under certain organization's name. So any of us can go along to somewhere like VeriSign. If you want a free one, go to start SSL. You can get a free certificate, and they will verify your identity, and that you own the domain, and then they'll give you a certificate. What that means is that you can stand up a website, you can make it HTTPS, you can serve that certificate up, and that will give people confidence that you are who you say you are, and everything gets encrypted so it can't be observed or manipulated. Now when an attacker compromises a certificate authority, they can start creating certificates for whoever they like. And these guys decided that they liked Google. So they created certificates for Google. They created certificates for some of the other big ones that Google has. But Google was the really prominent one, because once you can create a certificate for Google, if you can get in the middle of the traffic, then the client still sees an HTTPS connection, still sees a valid certificate by a valid CA, but the person who's doing the man in the middle of attack can intercept all the traffic. And of course that means they can change it or read it. So what was observed when all this washed up, and the guys did start looking at what was happening inside DigiNotar, is they noticed a whole heap of certificate validation checks coming from Iran. They called OCSP checks, and they make sure that the certificate hasn't been revoked. Now DigiNotar was not the CA for Google. So of course the question is, why are we getting OCSP requests for Google from Iran? There should not be a DigiNotar certificate for Google. So chances are it was the government. And a little bit like the Tunisia situation, I guess we could expect that it might happen somewhere like Iran. Government gets control of the connection. Government gets a compromised certificate from DigiNotar somehow, signs their own traffic, and for all intents and purposes, makes it look like a legitimate connection. You get the padlock, the real padlock, not the bitmap, and the government gets all of the traffic. So good for the government. Not so good for DigiNotar, because when you are a security company and you base your entire operation around being a secure certificate authority, and then you're not, you go bankrupt. So it didn't end real well for DigiNotar. Really bad for the Dutch government too, because the Dutch government was very, very dependent on their local CA, which you can kind of understand, but in retrospect, maybe not such a good idea. Komodo also had similar sort of issues. Looks like the same attacker, but Komodo didn't ultimately go under. They weren't owned quite as badly. So a few things here. We do depend on certificate authorities as sort of the fabric of SSL. So we put our trust in the fact that when we see certificates, things are valid and we can trust the connection for the three reasons I mentioned. But certificate authorities can get owned. It does happen, and it's a big event when it happens. I mean, DigiNotar was serious, serious stuff, but it does happen. We have also seen other attacks against SSL. Beast and Crime, most recently Heartbleed. Heartbleed wasn't really an attack against SSL per se, but it was a vulnerability in open SSL. So if you're trying to implement SSL on your application and you used open SSL, which is on about two-thirds of machines on the internet, then you potentially had problems. So some of the things that we can do as well to protect against vulnerable implementations of SSL are things like cert pinning. So for example, if you use Google Chrome and you go to Gmail and the Iranian government, let's imagine you're in Iran, Iranian government has owned your connection and they got rogue certificates. If they don't serve up the right certificate with the right thumbprint that Google Chrome expects, so Google Chrome has that certificate pinned, then it throws its hands up and says, no, there's something wrong, we're not gonna give you any data or anything like that. Often see this in mobile apps with banks as well. It has a very easy way to check. You can proxy your traffic through Fiddler, you can install a self-signed certificate on your device, and you can look at that traffic, and a lot of banking apps will say, no, this isn't any good, even though the certificate chain is valid because it is not the right thumbprint, you're out of here. We'll have a look at that on Friday as well, we're gonna proxy some traffic and see how that works. What is a little bit difficult there though is you can't really do it on your own website. So it works for Google with Chrome because they own the client and they own the server. Most of the time when we build web apps, we don't own the client. We're depending on people using whatever browser it is they use and we can't actually pin certificates there. PFS or Perfect Forward Secrecy is another good example of how it can be strengthened, where instead of having one private key that signs everybody's traffic, effectively every connection gets its own private key and if you have a heart bleed and keys are leaked, it doesn't put everybody at risk. And there's a really, really pragmatic, easy piece of advice here as well, which is don't have stuff you don't need to. The number of times people have got data classes that they have to store in the database and protect in transit that they never need is nuts. I have this discussion often, things like do you really need people's religion? What are you gonna do with people's religion? This is sensitive personal information. Not the sort of stuff you wanna leak. If you don't have it, you can't lose it. And finally, clearly in a case like did you know that, it can be game over. And a tag like this can be the end of the organization. Not just 170 million bucks like Sony got hit. And I guess 170 for Sony maybe isn't, I mean it's notable, but it's not a whole lot. It can actually bring you down entirely. So it didn't end well for did you notar. So a more recent one, so the Twitter at N account. This was one that happened a little bit earlier this year. Now apparently single digit or single character Twitter accounts are very valuable. This guy said his account was worth 50 grand. People had offered him $50,000 for his account. I guess you can kind of imagine it. You've only got about 140 characters. If you have a one character, maybe it's like number plates and the really short ones are valuable. So anyway, this account was very valuable and an attack out wanted to take his account. So he did it by hacking the guy's GoDaddy account. Now the reason why that works is first of all, the guy managed to call up PayPal, social engineer PayPal and get the last four digits of the credit card. Now he never disclosed how he social engineered PayPal to get that, but I think we've seen enough examples to understand that that's well and truly within the realms of possibility. So he's got the last four digits of this guy's credit card. So then he calls up GoDaddy and says, look, I've been locked out of my account and my email address and stuff has changed and I need to verify my identity. And GoDaddy says, okay, well give us the last six digits of your credit card account. And the guy goes, well I've got four. And GoDaddy says, well, you do want to guess? Just guess the other one. Is it one? No. Is it two? No. Is it three? Yeah, three. Okay, what about the other one? And then they just let him guess. So GoDaddy is just like, keep giving out free chances. So good on GoDaddy. Now what ended up happening was the guy got access to the GoDaddy account. He went into this victim's GoDaddy account, changed all the contact details. So no longer does the GoDaddy account look like it belongs to the victim. Email addresses, names, physical addresses, contact details. And then he contacted the legitimate owner of the at-n account and said, give me your at-n account or I kill all your domains and I delete your websites and I do all the other stuff I can do when I have control of your DNS. And this guy was trying to get in touch with GoDaddy and said, look, it's me. Can you give me the account back? And they go, well, it's not you. Our record say you're, that guy over there is just stolen your account. Because we let him guess your bloody credit card number. So this was a really sort of interesting social engineering attack against GoDaddy. What's interesting when we look at GoDaddy, this is today, it was two weeks ago, I assume it's still the same today. So what's wrong with this? Where's the HTTPS? No HTTPS? It posts to HTTPS, but we know from Tunisia that that's not sufficient. Now on the plus side, with GoDaddy, you can get two-factor authentication. Actually, you probably can't and I probably can't because you've got to be American to get it. So they've got two-factor authentication, but unless you're in that small percentage of the worldwide internet populations in the US, you can't use it. So GoDaddy, not so good on a couple of fronts there. So the things that we get out of this is that again, we're getting into this sort of thing where it's you're pining one account and then you jump to the other one and you've got that and you've got that. And in this case, it was actually a ransom. You know, it's not even like he managed to pivot. But we do see compromising one accounts leading to this cascading effect of other accounts being compromised. Untrustworthy humans again. Guessing credit card numbers? That's nuts. Come on. Who lets you keep guessing? That's crazy. Actually, I'll tell you who lets you keep guessing. Quantas lets you keep guessing and I'll show you on Friday. That's another topic. Two-factor authentication, we just keep going through this again and again and again. It's nice that GoDaddy has it. It's bad that nobody outside the US gets it. Inevitably, that's where their predominant audience is. But give it to other people. I mean, geez, everyone else can figure it out. You can get it on Twitter and Facebook and everything else. Why can't you get it on GoDaddy? Now, Twitter also really wasn't very helpful. Twitter should have sort of done the mass after he'd given the account away and said, well, actually, yeah, we can see this is your account and here's the paper trial of everything that happened. Here you go. Have it back. And they, by all accounts, were pretty useless. Eventually, they came to the party and they did give him his account back after he'd surrendered it to the attacker. But it took him a long time. And I guess the lesson there is it is a free service. Even if it's a valuable single character account, it's a free service. How much support do you actually expect from Twitter? Last one I thought we'd look at is very topical. So this was just last week. And this is what a lot of people in Australia woke up to last week. And they were woken up to this at about 2 AM in the morning for many people. And allegedly, as you can see here, Oleg Pliss has locked their phone. And he's done all of this remotely and he's now demanding money. He's demanding a ransom. A lot of sort of everyday mum and dads in Australia got hit by this, certainly hundreds. I don't know quite how they're going to figure out how to use MoneyPak or Ucash or PaySafe card when their phone is locked. And it may be the only thing they have. But somehow, Oleg or whoever it is who was impersonating Oleg was expecting them to know that. So let me explain how he actually did this. So I've got to thumb in my blog from last week, breaking this down, showing you how an attack like this works. So the first thing is the attacker logs into their iCloud. Now, how the hell does an attacker log into an iCloud? That is a question that is not yet answered. For some reason, a bunch of Australians and some people from overseas as well, but very predominantly Australians. And Australia has less than 1% of the global internet audience. So I don't know why we featured so much. But somehow, the attacker has got enough information to log into the victim's accounts. So for example, it may be that we had an Aussie service compromised last week. And it may be that the attacker got a whole bunch of localized usernames and passwords and then just started going through them, holding them all for ransom. Now, he may have automated the whole thing much more than this. But this is how you would manually go and hijack someone's account. So on the right-hand side, we have the attacker. So he's pulled out his iPhone or his iDevice or whatever it is he's got. And he's logged onto the victim's iCloud account. That allows you to see where their device is. So here, I've got my attacker hat on, and I'm looking at Troy's iPhone. And I want to hijack that device. So what I do is I start a lost mode process. So if you've got iCloud and iOS devices and you've used Find My Phone, you may have seen this before. The theory is that if you legitimately lose your phone, you can see where it is on the map. And then you can turn on lost mode. Now, when you turn on lost mode, you can set a pin on the phone. Now, you can only do this if the phone doesn't already have a pin. So all of these people that got owned by this attack last week didn't have a pin on their phone, which means the attacker can enter their own pin into the lost phone mode. Now, when they do that, they can also put in a phone number. And the theory is that if you legitimately lose your phone and someone picks it up, they see a message, which is normally a lot friendlier than the one you see here on the left side of the screen. And they see a phone number that they can click on and use your phone to call your wife or your husband or whoever it may be at home on their other phone. That's the way it's meant to work. This guy was using it as a code, which he inevitably wanted to accompany the payment so that he could verify who had actually paid him. And then in theory, unlock the phone. I don't like the chances of you ever getting your phone unlocked by the way, if you send money to someone called Oleg Pliss, who has just held your phone to ransom. So anyway, he'd put a number on. And then he would put a message like this. Now, after adding the message, he could also hit the great big play sound button, which means that whether the phone is on mute or whether the volume's turned all the way down, doesn't matter. The phone would go absolutely nuts. And all these people being woken up at 2 AM in the morning with their phone irretrievably locked. You cannot unlock it short of a vulnerability in iOS, of which there have been a whole heap at different times. But it's probably not the sort of thing that mum and dad are going to be able to sort of circumvent and get their phone back online. So incidentally, the only thing that people could do is restore from backup. So they could restore, say, from a local backup of iTunes. They could just blitz the device and restore from iCloud if the guy doesn't actually destroy their entire iCloud account. You can't remotely unlock. So even if you've still got access to your iCloud account, you can't unlock this phone by sort of reversing the process and turning off lost mode. Once the pin is set, the pin stays there. So actually, I mean, the guy's kind of ingenious. It's a reasonably good attack in terms of the ease and the effectiveness. Now clearly, there were a few things that came out of this. So one of them being security basics. This was hard stuff. So there are multiple things that consumers had to have not done in order to fall victim to this attack. If they had done any one of these next three things I'm going to read off, it wouldn't have been a problem. So one of them was they almost certainly reused passwords. Apple released a statement about this. And as Apple is prone to do it, it was very curt and very direct and said, don't use passwords. Please go away. It was something to that effect. It was basically saying, look, we don't know. It's your fault. I suspect they actually know a lot more than that. I mean, they see this happen inevitably on the back end. But they've put it down to password reuse. So number one, password reuse. At number two, they didn't have pins on their devices. Even just a four-digit pin, and it would have been OK. So I don't know. Maybe it was that they were giving it a little site. iPads, and it's the kid's iPad. But I've got little kids, and I tell you, well, they can figure out a four-digit pin pretty easy. So that shouldn't be a barrier. And the third thing was no two-factor authentication. If there was two-factor, this must be the fourth time we've said this now. If there was two-factor, assuming this is the way the guy got in and there wasn't some unknown vulnerability in iCloud, this could not have happened. Now, iCloud is enormously convenient, and hackers love it. They loved it with Matt Honen because they could wipe his devices. They love it with these sort of people as well. This is why someone probably sitting in the Eastern Block summer in Europe is able to wake up Aussies at 2 AM and lock their phones. It is enormously convenient. Of course, the reality of it is, if the attacker has access to iCloud, they could have also taken the backups that go to iCloud, because backing up to iCloud is so convenient. It's also convenient for the attacker. He could have taken those backups, restored them to his device, accessed things like the keychains that get synced across your Apple devices, because that's also very convenient. And basically, just taking over people's lives, or as Matt Honen said, basically destroyed their digital world. So an enormous amount of potential for hackers. Now, the ransom one is a bit interesting too. Clearly, that did possibly give the attacker opportunities to do other things, but ransoms are this sort of other class of software we're seeing. Often seen called ransomware. Things like crypto lockers in the news a lot at the moment, where attackers will get more wear onto PCs, generally do a pretty good job of encrypting all their data, and then say, look, if you want to decrypt it, you've got to send me $200. So ransoms are becoming a thing. But from Apple's side as well, you do have to wonder, just how many devices should someone be able to lock with a message from Oleg Plyst demanding a ransom before Apple go, maybe this shouldn't happen? Now, I know that they're massive, and they have all sorts of resets and things go on, but this is a sort of fraud pattern that they probably should be detecting. And the question for you guys is in your apps, where there are critical functions, things like being able to take over people's devices, maybe just knowing your username and password isn't really enough to let people do that. So wrapping up, there are a few things here that were really common patterns across the whole thing. And one of them is, is that all of these risks are really well known. They're really well documented. Heaps of free material out there, heaps of stuff like my PluralSight courses, I've got free ebook on Troyhunt.com, numerous blog posts, all of this stuff is known by many security professionals, known by many developers as well. So a lot of this is not new, yet we keep building vulnerable apps. A clearly interlinked accounts is another biggie. So we keep having problems where we create these interdependencies between accounts. And I think almost as a consumer, the thing we've got to think about is do we really want to allow this account to be reset by that one? Or should you be able to authenticate over there and do something over there? Convenient, yes. Secure, yeah, can have issues. We've seen some very bad humans throughout this process. Humans are notoriously bad at security. And I mentioned social engineering is one of the biggest risks that we have. Computers are very good at doing what they're told to do. Sometimes they're not told to do the right thing, which is another issue altogether. But certainly they are more predictable in this way than humans. So don't forget the social engineering aspect. And finally, it does come back to us as the devs. So what sort of training are we getting to understand these risks? For those of us managing teams or delivering on behalf of organizations, what sort of processes do we have around penetration testing? Even automated scans. So he put tools out there. You can just point at a website, it'll come back and say here's 50 things that are wrong with it. So there are very easy ways to do it, but we as developers have got to take some responsibility for it. So with that, thank you very much. I did refer a number of times to Friday where I am going to do demos and show things to get broken. And because I'm in Norway and a lot of people said I should do this in Norway, we're also going to look at Pony Swedish websites, which I believe is quite popular. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Thank you very much. Any question time? Couple of minutes, any questions? Over here. Can you pass the response after the class? You don't need that. I don't have any. Do you have any vulnerability? All right, so the question is about password managers. And the gentleman mentioned key pass. Key pass is one, last pass is another. I use one password. Do they have any vulnerabilities? Probably, do I know of any no? I think password managers are about the best mouse trap we have for managing passwords. Because if we want to be strong, so it has to be long and random and all these sort of things, and we want to be unique, we've only got so much memory mass to be able to do that. So we certainly can't do that across the breadth of accounts, particularly people here probably have, because we create so many accounts online. So I personally feel that the best balance is to get a good password manager, last pass, key pass, one password, and use that as much as you possibly can. Any other questions? Nope. Okay, well, do remember, oh, up there, sorry, you're behind the light. Ah, good question. So what is the hashing algorithm in the SQL membership provider? So it depends on the version of ASP.NET. So the one that we're going to break on Friday is the ASP.NET implementation that you would get with the Visual Studio 2010 project, which gave you one round of SHA-1 with Assault, which is totally useless, and we will hack that at a rate of 10 million passwords a second on Friday. And that's slow, because it's on this. We can do $4 billion at home on a good machine. Newer versions have different implementations. I think the latest one is doing a thousand rounds of PDKDF2 with SHA-512. So even that, by many people, is viewed to be insecure. So the short answer is it's getting better, but go back a few years, and it was very bad by today's standards. Anybody else? Okay, look if everyone could fill out the evals on the way as well. We'll do a... That's the green card on the end. Don't worry about those. Thank you very much, everyone. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
 All right, welcome everybody.  Sorry about our little technical dramas there.  You're losing about 10 pixels of my right hand side,  but that's going to matter.  So hello, everybody.  My name is Troy Hunt.  I'm from Australia.  I'm going to talk more about Australia on Friday.  I've got another session on Friday  that's going to go into a lot of detail about some attacks.  We're going to break some stuff on Friday.  But today I want to talk about a bunch of attacks  that we've seen in the past, how they've worked,  and what we can learn from them, what we can do differently  in future.  And where I like to try and start these talks  is to take a little bit of a look at why it is that we're  bothering to talk about web security.  So I have this slide where I put a whole bunch of company  logos on.  And every time I do this talk, the logos  have to get smaller and smaller and smaller  because there's so many more of them.  So I've got things like eBay from a couple of weeks ago.  Didn't have that last time I did this.  So it's an ever-expanding list.  And what I find really interesting about this list  is the diversity of organizations that are represented.  So we're seeing everything from shopping centers to telco  to military contractors like Lockheed Martin.  I'm not sure what things like prong.com are,  but there's a really broad range of websites  that are represented.  So it's not discriminatory in terms of who's getting attacked.  Also not discriminatory in terms of why people are getting  attacked.  If it's on the internet, it's pretty much fair game.  So before I jump into the actual attacks themselves,  one thing that I think is quite interesting  is the way attacks are changing in terms of scale and volume.  And one of the things that I find really stark  is this graph here about attacks over time.  So this goes from about April 2010  through to about the middle of last year.  And I picked this range because I did a course on this  recently for PluralSight in terms of the changes  between versions of the OWASP top 10.  Is anyone here familiar with OWASP?  Just show of hands.  And it's maybe a third, not too bad.  So just a quick diversion.  OWASP is the Open Web Application Security Project.  And they're not for profit organization.  And they create a bunch of material  to help us build safer websites.  And one of the things they create  is a document called the Top 10 Web Application Security Risks.  And it talks about things like SQL injection and cross-site  scripting, how they're executed,  how to protect yourself against them,  and how to do it in different languages as well.  So a lot of the stuff that I talk about and write  and create material on is around OWASP.  So I'm going to come back to them a few times.  So anyway, this was the difference between web security  in the OWASP 2010 version and the OWASP 2013.  And what I was trying to show is just how much the attacks  are increasing.  So up until about the middle of that graph,  we're under about 100 different attacks a month.  We get through it at the last half  and now we're up around that 250 plus mark.  So we're seeing a lot more.  This data is from datalossdb.org.  It's a great site for listing breaches that have occurred  and it explains who did it and how they happened.  It also only explains the ones we know.  So there's 6,000 breaches there that they've recorded  that we know of.  There's a hell of a lot more that we don't know of.  Now one of the other interesting things  beyond just the volume in terms of the number of breaches  is the amount of data that gets disclosed and compromised  in each one of those breaches.  So what we're seeing here is that the records that attackers  are getting their hands on are increasing dramatically.  822 million records last year, nearly doubling previous hype.  So that's really significant.  We're getting towards a billion records there in 2013 alone.  So I think it's some of the big ones.  2013, everyone probably heard Adobe got attacked.  152 million accounts from Adobe alone.  Most people know Target had huge issues.  110 million credit cards in 2013, in about December.  And already this year we got eBay.  So eBay says we've had 145 million active users compromised.  But I don't tell you how many inactive users.  I don't know how many it is, maybe 300 million.  It's a lot, significantly higher than 145.  So we might find that 2014 is the bumper year  in terms of data breaches.  So last thing before we get into some of the attacks.  And this sort of looks at what were the top 10 breaches  in terms of the records that were compromised  and when did they happen?  And there's an interesting little pattern here.  When you have a look at the dates,  five of the top seven were in the last 10 months.  So that's massive.  This is tracking stuff that goes all the way back to the 80s.  But five of those top seven attacks happened  since August last year.  So we've got this problem where they're getting  more and more and more attacks and they're getting bigger.  Each one is getting bigger.  And again, 145 million from eBay,  plus all the other ones I don't tell us about.  All right, so let's jump in.  We're gonna look at 10 different attacks  that have happened over recent years,  happened online, and we're gonna look at how they happened  and what we can do to stop them from happening again.  So the first one, pretty simple run of the mill  SQL injections.  This is Bell in Canada.  This is a telco in Canada.  Earlier this year, they got popped by a SQL injection attack.  And what ended up happening was about 22,000 records  that were compromised, no cryptography at all  on passwords, no encryption, no hashing.  Very important difference between those two as well  that we'll talk about on Friday.  Now, so we've got 22,000 records, they all get exposed  and because it's a hacktivist, what a hacktivist do?  They whack it all on paste bin.  And of course, this is terrible for a company  because not only did they get hacked,  but now all their users credentials are somewhere public.  Now we know it was SQL injection  because the attackers told it was SQL injection.  They posted a really nice screen grab.  The thing about hacktivists,  they love telling you how they did it  because it's so intelligent, it's so clever.  Look at what I did.  This is a free plugin to Firefox called Hackbar.  And what Hackbar lets you do  is do a little bit of fuzzing on HTTP request.  So what I mean by that is that you go to a website,  you make a legitimate request.  So this is a password recovery page.  It was making a post request  which inevitably has something like the email address  you want to recover the password for.  I really hope they didn't actually just email the password  but I reckon they probably did  because they're all in plain text anyway.  So anyway, you make the request and then you use Hackbar  to capture that request,  manipulate some of the parameters  and see if you can get the web application  to actually throw some exceptions.  Now in this case, we can see down below  it is actually throwing an exception,  Microsoft OLEDB provider.  And it's giving a conversion failure  where what's actually happened  is the attackers have tried to get  the version of the SQL server.  And we can see it is Microsoft SQL server 2008 R2,  blah, blah, blah, blah, blah, blah, blah, blah, blah,  and cast it to an integer.  Now it's a string, why it cast to an integer?  It's got lots of letters and things  that really aren't conducive to integer.  So SQL servers thrown an exception  and the exception is bubbled up into the web browser  and disclose the fact that this is what the database is.  That doesn't sound too bad,  but that technique is then used to get the table names  and the column names and the data.  And if that sounds hard, on Friday,  I'll show you how any of you can do it with your own websites.  Very, very simple.  So there's a few things that we can take away  from this attack.  And the first thing is SQL injection  is the number one attack on the web.  And it's a number one attack for a few different key reasons.  Number one is it is really, really prevalent.  There is so much SQL injection out there, it is not funny.  And one of the things I'll also do on Friday  is show you how to find sites with SQL injection  and just how easy it is just via Google search.  So number two is that it is extremely easy to exploit.  If you can copy and paste,  you can mount a SQL injection attack  because there are free tools that just make it dead, dead simple.  Because it is so simple,  that's why we see kids turning up at court  with their mums who are always really pissed  that their kids have been hacking websites.  And it's these kids that don't necessarily know anything  about SQL injection or web security,  but they know how to run these free tools.  Now, the third thing is it is easy to exploit.  Those tools have easy, easy exploits  and the impact is really, really high.  So if you get all your data exposed publicly,  or your customers passwords, for example,  that is a massively high impact.  Cross-site scripting isn't great,  but it's a much lower impact  than something like SQL injection.  So we're also seeing a lot of automation.  So I mentioned that there's a tool that I'll show on Friday,  very easily available tool.  You copy, you paste, you put a link in your hacker website.  Talk to my three-year-old how to do it, that's how easy it is.  Now, unfortunately, we do have these problems  because as developers,  we're doing some pretty sucky things with the web.  We're building these vulnerabilities into the applications.  Now, we know about these things.  They're in iOS, they're very well documented.  We've all seen the news about how many websites get breached.  But we do keep building the same risks.  Now, the other thing you wouldn't have seen,  possibly wouldn't have seen on the previous slide,  is the URL was a.asp extension, classic asp.  This is the thing that was done 12 years ago.  We replaced it with.net.  It was from a much more innocent era.  It's not designed to be as resilient to these sort of attacks  as things like modern asp.net and other modern frameworks.  So running on technology that old  is always gonna make things harder.  It's always gonna put you behind the eight ball.  So that was SQL injection.  Next one I'll talk about is Matt Honan  and his epic Apple hack.  Now, Matt was a reporter for Gizmodo and Wired.  And Matt got up one day and his iPhone  powered down and consequently wiped itself,  which is never good.  And what eventually it was that the attackers  had managed to compromise his Apple account.  But how they did it is the interesting bit.  So the attackers called up Amazon and they said,  hi, I'm Matt.  I would like to put a new credit card on my Amazon account.  And they go, okay, cool, what's your name?  What's your email address?  What's your physical address?  So three pieces of data.  And then they go, okay, cool, give us the credit card  and we'll put that on your account.  So he does that.  And then the attacker calls up the next day and says,  hi, I'm Matt.  I'd like to change the password of the account.  And they go, okay, well, to do that,  we need your name, your address,  and your credit card number.  Oh, interesting.  So you can actually call up Amazon or you could at the time  and set a new credit card and then call them back  and say, I would like to verify my identity  by giving you the information that I just gave you yesterday.  So that allowed him to get access to that Amazon account.  Now, once he had the Amazon account,  he could then go through and find the last four digits  of Matt's other legitimate credit cards.  Not the whole thing because that would be insecure.  But he could go in and see the other cards  and all of us can do this on many of our accounts.  Go in there and your card ends in three, two, one, five,  whatever it may be.  You can get those last four digits.  Now, with those last four digits,  the attacker could call up AppleCare and say,  oh, funny thing, I forgot my password.  And they go, all right, well, what's the last four digits  of your credit card?  Glad you asked.  Here we go.  So you see how he's starting to jump  from one service to the other.  So once he's in AppleCare, then you're into iCloud  and you're into Apple's ecosystem  because he's got that account.  So he managed to get a temporary password,  get access to the Apple account,  and once you got access to the Apple account,  you can start doing things like wiping devices.  And we'll have a look at that in this demo as well today.  So he's wiping devices.  The other thing about Apple is Apple has the  me.com email service.  And Matt unfortunately used me.com  as a password reset channel for his Gmail.  So you forget your Gmail password.  You add a secondary account that they can send a reset to.  So he managed to reset Matt's Gmail account.  So once you can reset the Gmail account,  he can get into there and then he can do things  like reset the Twitter account,  which apparently was the ultimate goal to begin with.  And the attacker went and sent a whole bunch of racist tweets  and then deleted the Gmail account as well.  So it didn't end up real well for Matt.  And as Matt puts it, it only took an hour.  His entire digital life was destroyed  because the attacker basically just had  four digits of a card number.  So pretty nasty stuff.  There's a few interesting things with that.  And the first one is, and we're gonna see  there's a bit of a theme today,  the interlinking of accounts can be really problematic.  So the fact that the attacker was able to explore  the vulnerability with Amazon's verification system  ultimately meant that he could take over  the guy's Twitter account.  I mean, that's several hops.  But because we have all these things  so intrinsically linked together,  it often leaves us more vulnerable.  There are also different views of the sensitivity  of the data from different companies.  So Amazon was happy to just accept something like a card  and then read it back to you.  But Apple, that's their verification process.  So Apple had a very, very high level of sensitivity  on those last four digits of the card.  And it's probably got you thinking now,  how many places have I got four digits of the card?  If it's four digits, it doesn't come under PCI DSS,  it doesn't all have to be encrypted.  You can read display it back to people.  It's on a lot of your receipts.  Go through the garbage bin.  You'll find a lot of four digits.  Now the other thing is, and this was a couple of years ago,  so a little bit before two-factor authentication  became really popular,  but there was no two-factor authentication  on the Gmail account, on the Apple account,  on the Twitter account.  So there was no second channel  beyond just knowing the passwords.  That's all they take in need of the password.  So where you have two-factor available, turn it on.  So Apple and Twitter, I mentioned things like GitHub.  A lot of people here probably use GitHub.  They've got two-factor authentication.  They've had brute force attacks against people's accounts.  You definitely want to have it on there.  And of course, the other thing is,  is that as people, we are vulnerable to social engineering.  A lot of security professionals say  that really the people are the biggest problem.  We can only do so much with the systems,  and the systems will pretty much do what we tell them to do,  but the people are the one that keep getting exploited  by the attackers.  And there are many, many different ways  that we can socially engineer them.  We'll have a look at a couple more throughout this preso.  So who remembers MySpace?  It was a thing.  Some time ago, it was the thing.  It was the thing in 2005 when a bloke called Sammy  decided he needed some more mates.  Now, for most of us, we'd try and be popular  and we'd try and socialize a little bit  and maybe do things that other people are interested in.  But Sammy was a bit of a gun with cross-site scripting.  And he decided it would be much more effective  if he wrote a nice self-propagating cross-site scripting worm.  Now, what it meant is he could write this worm  with a whole heap of XSS.  He could put it on his MySpace page.  Someone comes along, they look at the MySpace page,  and they automatically befriend him  because there's script that he's put on the page  which fires off the request to actually befriend the guy,  and it puts a message on the person's page that says,  and most of all, Sammy is my hero.  So this was great.  So people that came and saw his profile  would get that on their page.  But because he was a smart guy,  everybody who then came and viewed their pages  also got compromised.  So it kind of spread.  It hit a million people in less than 24 hours.  That is a very, very bloody,  effective cross-site scripting attack.  And it looks like this.  So clearly cross-site scripting  can actually be rather complex.  Now, the idea is not to read what's in here,  but it's to make a point  that this is actually pretty sophisticated.  Now, this was 2005 as well.  So we've well and truly moved into the space  of much more sophisticated cross-site scripting attacks  since then.  So that was an interesting one.  And it told us a few really interesting things.  And one of them is that cross-site scripting  is very serious.  So a lot of the time when we do maybe a proof  to demonstrate that a site is at risk of cross-site scripting,  we'll pop up an alert box.  Hey, follow this link.  Oh, alert.  Funny cats, whatever it may be.  There's actually a Twitter account called XSSKittens.  And it links all of these links to reflected cross-site  scripting.  You click on them, you go to a shopping website,  and there's cats all over it.  And he just goes nonstop because there's so much stuff  out there at risk of XSS.  But it can be very serious.  So other proofs we often see for XSS  is doing things like taking a copy of authentication tokens  in cookies and sending it off to an external service  because the cookies weren't flagged as HTTP only,  and the XSS was enabled on the site  because they weren't encoding and all sorts of other things.  So it can actually be very, very serious.  I mentioned before, it's also in that I was top 10.  It's number three in 2013.  It was number two in 2010.  So it's gotten kind of a little bit better.  But it's still a serious, serious problem.  Now, protecting against XSS is also very easy.  And this is sort of a common theme.  Things like SQL injection and XSS,  it's not hard to stop it if you know what to look for.  So a couple of things there that make it very easy  to protect against XSS is validating untrusted data.  So when a user provides a URL, or say query string  and parameters, or when they submit a form,  or when you read request headers,  when you read the language of the browser,  or when you read the user agent,  all of that is untrusted data.  And validating that it conforms to an expected pattern  is really important.  In the one we'll have a look at on Friday,  you can take integers and start attacking via integers  because they're not actually checking  that when the integer goes to the website  that it is actually an integer.  They just go, oh, look data.  We'll take that and we'll put it in our query.  Encoding all output is the other big thing.  So frameworks like ASP.NET MVC do a very good job  of encoding by default.  So what I mean by that is if you try and send a script tag  to the site and the site reflects it back,  so like when you do a search and it says you searched for,  instead of actually rendering script tags  into the HTML source, it'll encode it.  So you get amp for send less than amp for send greater than  and then in your browser, you actually see rendered script  tags.  So they're really two very, very simple things.  And again, a framework like MVC does it for you automatically.  Framework like classic ASP doesn't.  That's why every time you see a dot ASP extension,  almost for sure you'll find SQL injection,  you'll find cross-site scripting.  Very easy done.  All right, so HB Gary Federal.  Now this was an interesting one because these guys were  security professionals and they were providing services  to the US government.  And the bloke running that, Aaron Barr,  was very proud of the fact that he believed  that he had unmasked Anonymous, the ring leaders of Anonymous.  And he made the mistake of telling them  that he thought that he had unmasked them  and they didn't take too kindly to that.  So they hacked them.  And the way they did it is they found a SQL injection  vulnerability in the content management system  of their website.  This may have been one that was known already.  It may be one that they found on their own.  Either way, they managed to get credentials out  of the database.  And again, it can be really, really easy to do this.  So they got usernames, emails, and they got hashed passwords.  MD5 hashed passwords.  MD5 hashed passwords are useless.  SHA1 salted hashed passwords are useless as well.  And if you're doing that, we're going to have a look at that  on Friday and we're going to break a heap of them  and probably upset a bunch of people.  But you need to see how easy it is to break  bad hashing implementations of credentials.  Now, because it was just an MD5 hash,  the attackers could use rainbow tables  to convert the hashes back to plain text.  Well, they don't really convert them.  But what they do is they take these pre-computed tables  where it says, for all these plain text strings,  these are the MD5 hashes.  And then it just matches the hashes  with the ones out of the database and says,  well, that must have been the password.  Now, as the CEO of a serious security firm,  clearly he had a very good password,  which is this one just here, which is all  our case with two numbers.  And because it makes life really, really, really convenient,  he reused it across everything.  So that wasn't good.  So there, the attackers have the password in plain text  and it's reused across every account.  So that allowed them to do things like gain,  shell access to the Linux machine  that their web application was running on.  And then because these guys weren't actually patching  their environment, exploit a risk that had been  publicly disclosed, patched months earlier,  exploited it, elevated privileges,  and started pulling down gigabytes and gigabytes  of emails and other documents and things like that  off this public website.  Now, the guy behind all that was this bloke,  Sabu, was the handler he went under,  the leader of Lowell's Sec.  Now, this guy is a very, very old hacktivist.  He was actually in his late 20s.  So very, very old for a hacktivist.  But a bunch of his mates were teenagers  that did end up in court.  Sabu ended up being caught by the feds.  He got turned, he became a snitch.  He then allegedly helped them bring down  300 other attackers or potential attackers.  And in fact, just a couple of weeks ago,  he finally was released with a suspended sentence  after effectively having his life ruined  because he liked SQL injecting some websites.  So that didn't end up well for him.  Didn't end up well for HB Gary either.  Obviously as a security organization,  if you do these sort of things and get caught,  it's probably not real good for your reputation.  Now, a few different things  that we can take away from this.  And a little bit like the Matt Honen thing before,  security risks do tend to be chained.  And in this case, there was a lot of pivoting.  So they'd break into one system  via a SQL injection attack  and then get enough information to move onto the next  and then get enough information to move onto the next.  And we often see this happen.  And one of the reasons why that's important  is because I'll often hear people say,  and I'll take an example,  it might be that they've got a SQL injection risk  in the admin section of their website.  And they go, it's not really a problem  because you've got to be logged on as an admin anyway.  So, you know, it's okay.  But it's this whole thing  of not having these single points of failure.  Because all of that assumes  that the attacker can't get into the admin system.  One person reuses a password, gets published,  SQL injection gets exploited.  So it's about having defense on top of defense,  defense in depth.  Again, we know these risks.  So we know things like SQL injection.  And we particularly know things like bad cryptographic storage.  Using MD5, bad, using salted char one, bad.  Again, I'll show you why on Friday.  It's unbelievably easy to crack that.  Choosing bad passwords.  So it's probably obvious, but somehow we keep doing it.  And even the security pros are choosing weak passwords  and reusing weak passwords.  And that is just opening up this treasure trove  of other stuff that attackers can get their hands on.  Now, the final thing about these hacktivists  is that they're often young.  They're often clever, maybe not particularly intelligent,  but they're very, very resourceful.  And when you don't have a job and you live with your mum,  you've got a lot of time in your hands  so they can find ways into these systems.  And it's interesting when you look at the sort of discussions  these kids, and often they are kids, legally, not even 18.  You look at the sort of discussions they're having.  So I've done some videos on things like  automated SQL injection.  And when I'm Googling around trying to find information,  there's all these other videos that people have made  about how to use tools like Havage and SQL Map.  And it's just telling that every time  the people on the videos have voices that haven't broken yet.  True story.  So they have a lot of time on their hands  and they can be very resourceful.  All right, Sony.  So Sony had a really, really bad time of it in 2011.  And they just kept getting attacked and attacked  and attacked and attacked.  And a lot of this started with PlayStation Network.  So PlayStation Network went offline  and everyone was like, where's PlayStation Network?  And Sony just doesn't say anything.  It just goes on and on and on.  A week later they go, oh yeah, we got hacked.  So it was quiet for a long time.  We've been hacked but it's okay.  And then they got hacked again.  So the first time was about 77 million accounts.  The second time was about 25 million accounts.  So they were starting to have a very, very bad month of it.  This was only a couple of weeks later.  But it's okay, we got under control.  Then they got hacked again.  And this time it was Sony Pictures.  Now what's interesting about this  is that Sony Pictures is not PlayStation Network.  This is a very different part of the organization.  This is now getting into production and film studios  and things like that.  So clearly there was something about Sony  that led to them continually getting owned  over and over and over again.  Now several very interesting things came out of it.  And one of them is that communicating early  was really important.  And these guys just weren't doing it.  They're literally people sitting around going,  what the hell's happened?  I need my PlayStation, it doesn't work.  And they weren't telling people.  Even eBay two weeks ago, just in the last couple of days  I've had people tweet me saying,  oh, eBay finally told me they got owned  and I need to change my password.  What does it take two weeks?  I mean, I know that they've got a huge audience  but they've got a lot of resources  and a lot of systems behind that.  So think about it for yourselves as well.  For the systems that you manage,  if there is an incident and none of us can assume  that we'll never have an incident,  if you've got a million customers,  are you equipped to actually get them  communication fast and early?  You know, can you do it in a day or two?  Are we gonna be sitting here in a week going,  we're still trying to figure out  how to email 20 million people?  Because that can be a difficult problem to solve.  Now with Sony, it was also pretty cultural.  So we're looking at very independent parts  of a global multinational, developers in different places,  systems in different places, different technologies.  Hell, it's PlayStation versus a little website somewhere  for a promotional campaign.  But they all kept getting owned.  So clearly there was something in the organization  that just didn't have a focus on security.  Maybe they didn't have the training for the developers.  Maybe they didn't have security reviews  or penetration tests or things like that.  But it was a cultural thing  and you often see this become a pattern.  And I particularly find it interesting,  you look at a website after it's been breached  and you go, well, yeah, you've got like cross-site scripting  and you've got other vulnerabilities  and you're returning too many headers  and you've got directory browsing.  You've got all these sorts of things  that may not have been the way the attacker got in,  but it's part of the broader picture of,  hey, these guys probably aren't thinking a lot  about security.  A little bit of where there's smoke, there's fire going on.  Now for Sony as well, it was also massively expensive.  170 million bucks apparently went in  to solving their security problems.  And one of the challenges we often have in security  is that it's really not viewed as a feature.  Not in so far as it's not something you give to customers  and they use and we're gonna get an immediate  sort of value in return on that.  It's like an insurance policy.  And a lot of companies don't like to spend on it.  Even though in many cases, it's simple.  Protecting from SQL injection is easy.  You just gotta know where to look.  Companies aren't looking at that.  And I think part of the problem is that they don't see  the potential downside.  They see there's gonna be an immediate cost,  which is to train developers or get a penetration test.  But then it's gonna be sort of offset by this potential  that we may lose a heap of money later on  and that's hypothetical and,  oh, look, something new and they move on.  So being conscious that there are real,  tangible costs when it goes wrong.  So number six, Gorka.  Gorka was an interesting one a few years ago  and it was another sort of case of,  in this case, Nick Denton who headed up Gorka,  having a bit of argy-bargy,  I think it was with 4chan at the time,  the sort of precursor to Anonymous.  And it was one of these sort of online ego wars,  which generally don't tend to end well for the guys  that are public and for the most part doing the wrong thing  because the attackers don't generally tend to play  by the rules.  But anyway, Gorka got hacked.  They had a very poor cryptographic implementation  on their credentials,  which made it very easy for the attackers  to convert that data back to plain text.  So there's nothing too unique about that,  but where it got interesting was what started happening  to Twitter.  So why would you get Twitter spam  from people who had just been hacked by Gorka?  Any guesses?  Reused passwords?  Yes?  Okay, so people reuse passwords.  We touched on that a little bit earlier on with HBGarry,  but this was interesting  because it was a very sort of broad attack  that targeted a lot of people.  So clearly the attackers have got their hands  on this great big dump of compromised passwords,  and then they've gone on a spam campaign.  Makes you wonder how complicit Asahi were in that.  I don't think they'd be real happy knowing  that their brand was being promoted in this way.  But the interesting thing about this is it shows  how we do kind of become responsible  for the security on other accounts.  Whether we like it or not,  we're sort of implicitly responsible.  So several things that came out of that,  and one of them is clearly  that not all cryptographic storage is equal.  And when I was talking about cryptography,  they talk about insufficient cryptographic storage.  It's not like, do you have it or do you not have it?  It's have you done a good job of it.  So I know there are a lot of times where people go,  oh yeah, we use cryptography or encryption  or hashing or whoever they want to phrase it,  and they can say yes, we've done it,  and they've ticked the box  and the auditors are happy and the compliance team is happy,  but it's crap.  They've done a really bad job.  It's not all equal.  As developers, we often think when we do do a good job of it,  or when we do put a focus on cryptography  and the way we store and handle passwords,  we think that we're protecting our system.  And we are, but what we've got to understand  is that we do have some responsibility  for protecting other people's systems as well.  The other systems where these users reuse their passwords,  and as much as we all like to jump up and down  and say yeah, well nobody should reuse their passwords,  a lot of people do.  We've all done it at one time or another as well.  I know none of us do it now,  but we've certainly all done it,  and it is something that happens.  So we do have this sort of projected responsibility  on these other websites.  So the other thing that's a bit interesting here as well  is that from Twitter's perspective,  this was just people logging into Twitter.  Okay, so it looked legitimate.  It wasn't brute forcing.  It wasn't let me take this username and 5,000 passwords  and see if any of them work.  It was username, password bang, straight in  because they already had the credentials.  But people were abusing Twitter.  So I guess the sort of the question to think about there  is how do you protect your system  against attackers using legitimate credentials?  In Twitter's case, does it really make sense  to have the same spammy looking message go out 5,000 times?  You know, maybe that should have set a flag off there.  And finally, two factor.  So two factor keeps coming up again and again and again.  And two factor is the thing that saves you  when the thing that we know is disclosed,  but the thing that we have is not.  So that is a very common theme.  So the next one here is quite interesting  because it sort of forces you to challenge  what you think you know about HTTPS and SSL.  So this was Tunisia government and Facebook.  And this was a few years ago.  And the story here was that at the time,  Facebook would load the login page over HTTP.  So you'd be looking at HTTP,  call it and force it,  force it, Facebook.com bang, here's a login form.  Now a lot of the time people look at that and they go,  oh, you're clearly not secure, right?  It's not SSL.  But the form posted to HTTPS.  So the counter argument is,  well, the credentials were protected  when they were sent to the server and they're right.  The credentials were encrypted  when they got sent to the server.  If you had have intercepted those packets,  you couldn't have done anything with them.  So that's good.  The problem, of course, is that SSL  is about much more than just encryption.  So there's only three things I talk about with SSL.  And one of them is authenticity.  So when you go to a website  and you see a padlock in the address bar  and you can inspect the certificate  and you can see it says Facebook.com,  you have a pretty high degree of confidence  that it is Facebook.  And just by the by, if you put a bitmap  of a padlock icon somewhere in the web page,  that doesn't make it secure.  That's a fricking bitmap.  It's not the same as the one that's in the address bar.  People do that, believe me.  So that was number one, authenticity.  Number two is integrity.  So when you load something over an HTTPS connection  and SSL does its thing,  you can have confidence that the content of the page  hasn't been manipulated.  And that's where it went wrong with Tunisia  because it wasn't loaded over HTTPS.  You could have no confidence  that the page hasn't been manipulated.  We're gonna do this Friday as well.  We're gonna find a nice site that does that  and steal credentials in an ethical way, mostly.  And finally, it is also about confidentiality.  So the third point was,  you do get your data's protected  when it goes over HTTPS.  People can't actually read what is in there.  Now the interesting thing is, is that here's what happens.  So this is the way the attackers,  and in this case, the attacker is the nation state.  This was before we were worried about the Americans,  who we know like doing a lot of this sort of stuff,  like most other big governments, no doubt.  Anyway, what they were doing  was they were putting this JavaScript in the page.  It doesn't matter too much the detail of this,  but what was quite tricky about it  is that they were forcing an asynchronous request  on submitted the credentials.  And that asynchronous request  was actually going off to facebook.com,  but it was appending the credentials  in an encoded query string,  and it was also sending them to an HTTP address  on facebook.com.  And because it was going to an HTTP address,  the attackers, the government,  could view the contents of it.  But if anyone else looked at it,  they'd go, what the hell is Facebook doing?  Oh, it looks encrypted, of course it's not, it's encoded.  Looks okay, but it is going to Facebook.  So it was a nice sort of tricky little way for getting around that.  Now, there's a few different things  that we can take out of this.  And one of them is that a little bit like cryptography,  SSL is not a have you done it or have you not done it,  it is have you done it right.  So you cannot load anything over an HTTP connection  and not expect it to be manipulated or observed.  So you cannot load login pages over HTTP  without expecting them to have been changed.  You cannot let people view an authenticated page  and send an auth cookie over an HTTP connection  without expecting it to be sniffed and the session hijacked.  So there are nuances to the way that SSL is done  that make it very, very easy to do it insufficiently.  And this is what I was talking about,  they say insufficient transport layer protection.  So there's like this degree.  And there are certainly degrees of making it even more secure  again.  So does anyone see fire sheep a few years ago?  Man, that was fun.  So what fire sheep did is it was a little plug-in to Firefox.  And the idea was that you could go into an internet cafe  with your laptop.  In fact, you could go into here.  This place is great because there's no encryption on the wireless.  So apparently what you could do here  is you could use fire sheep.  And what it would do is it would look at the network traffic  around you because when you're not on an encrypted network,  it is possible to observe other packets on the same network.  And it would look for packets.  It would look for requests being made to Facebook  where the authentication token was being sent over an HTTP  connection.  And because it was a very nice plug-in and very user-friendly,  you'd load the web browser and you'd get a list of all the people  in the cafe.  You get the photos.  So you could look around you and go, oh, there's that guy.  Here he is on Facebook.  And you could click on him and steal their session  because the cookie wasn't protected.  So fire sheep was a bit of a watershed moment  where people started going, OK, we  know we could do this.  But when you see it packaged together so nicely  and made so easy, yeah, maybe we'd better actually  take a little bit of attention and fix it, which  is what Facebook has done.  Because now everything on Facebook is SSL.  Certainly anything that needs to be secure  is sent over HTTPS.  And I guess that's a good question for you to go away with  as well.  In your own assets, what are the things you're  doing over HTTP that may put you at risk?  And again, the classics, loading a login form over HTTP,  sending cookies that are not flagged as secure,  and they're auth tokens.  So if that's a foreign concept, that's  one of the things I'll talk a lot about in the PluralSite  courses, looking at things like HTTP only,  secure attributes of cookies.  Because if you don't have those two things,  you've got a whole world of potential trouble.  Did you note a rest in peace?  Did you note that it was a Dutch certificate authority?  And a few years ago, did you know  it got owned rather seriously by some attackers that  managed to start issuing rogue certificates?  So the whole premise of this sort of public key infrastructure  of certificate authorities is that they're  a handful of trusted ones.  And they have the ability to issue certificates  under certain organization's name.  So any of us can go along to somewhere like VeriSign.  If you want a free one, go to start SSL.  You can get a free certificate, and they will verify  your identity, and that you own the domain,  and then they'll give you a certificate.  What that means is that you can stand up a website,  you can make it HTTPS, you can serve that certificate up,  and that will give people confidence  that you are who you say you are,  and everything gets encrypted so it can't be  observed or manipulated.  Now when an attacker compromises a certificate authority,  they can start creating certificates for whoever they like.  And these guys decided that they liked Google.  So they created certificates for Google.  They created certificates for some of the other big ones  that Google has.  But Google was the really prominent one,  because once you can create a certificate for Google,  if you can get in the middle of the traffic,  then the client still sees an HTTPS connection,  still sees a valid certificate by a valid CA,  but the person who's doing the man in the middle of attack  can intercept all the traffic.  And of course that means they can change it or read it.  So what was observed when all this washed up,  and the guys did start looking at what was happening  inside DigiNotar, is they noticed a whole heap  of certificate validation checks coming from Iran.  They called OCSP checks, and they make sure  that the certificate hasn't been revoked.  Now DigiNotar was not the CA for Google.  So of course the question is,  why are we getting OCSP requests for Google from Iran?  There should not be a DigiNotar certificate for Google.  So chances are it was the government.  And a little bit like the Tunisia situation,  I guess we could expect that it might happen somewhere  like Iran.  Government gets control of the connection.  Government gets a compromised certificate  from DigiNotar somehow, signs their own traffic,  and for all intents and purposes,  makes it look like a legitimate connection.  You get the padlock, the real padlock, not the bitmap,  and the government gets all of the traffic.  So good for the government.  Not so good for DigiNotar,  because when you are a security company  and you base your entire operation  around being a secure certificate authority,  and then you're not, you go bankrupt.  So it didn't end real well for DigiNotar.  Really bad for the Dutch government too,  because the Dutch government was very, very dependent  on their local CA, which you can kind of understand,  but in retrospect, maybe not such a good idea.  Komodo also had similar sort of issues.  Looks like the same attacker,  but Komodo didn't ultimately go under.  They weren't owned quite as badly.  So a few things here.  We do depend on certificate authorities  as sort of the fabric of SSL.  So we put our trust in the fact that when we see certificates,  things are valid and we can trust the connection  for the three reasons I mentioned.  But certificate authorities can get owned.  It does happen, and it's a big event when it happens.  I mean, DigiNotar was serious, serious stuff,  but it does happen.  We have also seen other attacks against SSL.  Beast and Crime, most recently Heartbleed.  Heartbleed wasn't really an attack against SSL per se,  but it was a vulnerability in open SSL.  So if you're trying to implement SSL on your application  and you used open SSL,  which is on about two-thirds of machines on the internet,  then you potentially had problems.  So some of the things that we can do as well  to protect against vulnerable implementations of SSL  are things like cert pinning.  So for example, if you use Google Chrome  and you go to Gmail and the Iranian government,  let's imagine you're in Iran,  Iranian government has owned your connection  and they got rogue certificates.  If they don't serve up the right certificate  with the right thumbprint that Google Chrome expects,  so Google Chrome has that certificate pinned,  then it throws its hands up and says,  no, there's something wrong,  we're not gonna give you any data or anything like that.  Often see this in mobile apps with banks as well.  It has a very easy way to check.  You can proxy your traffic through Fiddler,  you can install a self-signed certificate on your device,  and you can look at that traffic,  and a lot of banking apps will say,  no, this isn't any good, even though the certificate chain  is valid because it is not the right thumbprint,  you're out of here.  We'll have a look at that on Friday as well,  we're gonna proxy some traffic and see how that works.  What is a little bit difficult there though  is you can't really do it on your own website.  So it works for Google with Chrome  because they own the client and they own the server.  Most of the time when we build web apps,  we don't own the client.  We're depending on people using whatever browser it is they use  and we can't actually pin certificates there.  PFS or Perfect Forward Secrecy is another good example  of how it can be strengthened,  where instead of having one private key  that signs everybody's traffic,  effectively every connection gets its own private key  and if you have a heart bleed and keys are leaked,  it doesn't put everybody at risk.  And there's a really, really pragmatic,  easy piece of advice here as well,  which is don't have stuff you don't need to.  The number of times people have got data classes  that they have to store in the database  and protect in transit that they never need is nuts.  I have this discussion often,  things like do you really need people's religion?  What are you gonna do with people's religion?  This is sensitive personal information.  Not the sort of stuff you wanna leak.  If you don't have it, you can't lose it.  And finally, clearly in a case like did you know that,  it can be game over.  And a tag like this can be the end of the organization.  Not just 170 million bucks like Sony got hit.  And I guess 170 for Sony maybe isn't,  I mean it's notable, but it's not a whole lot.  It can actually bring you down entirely.  So it didn't end well for did you notar.  So a more recent one, so the Twitter at N account.  This was one that happened a little bit earlier this year.  Now apparently single digit or single character  Twitter accounts are very valuable.  This guy said his account was worth 50 grand.  People had offered him $50,000 for his account.  I guess you can kind of imagine it.  You've only got about 140 characters.  If you have a one character,  maybe it's like number plates  and the really short ones are valuable.  So anyway, this account was very valuable  and an attack out wanted to take his account.  So he did it by hacking the guy's GoDaddy account.  Now the reason why that works  is first of all, the guy managed to call up PayPal,  social engineer PayPal and get the last four digits  of the credit card.  Now he never disclosed how he social engineered PayPal  to get that, but I think we've seen enough examples  to understand that that's well and truly  within the realms of possibility.  So he's got the last four digits of this guy's credit card.  So then he calls up GoDaddy and says,  look, I've been locked out of my account  and my email address and stuff has changed  and I need to verify my identity.  And GoDaddy says, okay, well give us the last six digits  of your credit card account.  And the guy goes, well I've got four.  And GoDaddy says, well, you do want to guess?  Just guess the other one.  Is it one?  No.  Is it two?  No.  Is it three?  Yeah, three.  Okay, what about the other one?  And then they just let him guess.  So GoDaddy is just like, keep giving out free chances.  So good on GoDaddy.  Now what ended up happening was the guy  got access to the GoDaddy account.  He went into this victim's GoDaddy account,  changed all the contact details.  So no longer does the GoDaddy account  look like it belongs to the victim.  Email addresses, names, physical addresses,  contact details.  And then he contacted the legitimate owner  of the at-n account and said,  give me your at-n account or I kill all your domains  and I delete your websites and I do all the other stuff  I can do when I have control of your DNS.  And this guy was trying to get in touch with GoDaddy  and said, look, it's me.  Can you give me the account back?  And they go, well, it's not you.  Our record say you're, that guy over there  is just stolen your account.  Because we let him guess your bloody credit card number.  So this was a really sort of interesting  social engineering attack against GoDaddy.  What's interesting when we look at GoDaddy,  this is today, it was two weeks ago,  I assume it's still the same today.  So what's wrong with this?  Where's the HTTPS?  No HTTPS?  It posts to HTTPS, but we know from Tunisia  that that's not sufficient.  Now on the plus side, with GoDaddy,  you can get two-factor authentication.  Actually, you probably can't and I probably can't  because you've got to be American to get it.  So they've got two-factor authentication,  but unless you're in that small percentage  of the worldwide internet populations in the US,  you can't use it.  So GoDaddy, not so good on a couple of fronts there.  So the things that we get out of this is that again,  we're getting into this sort of thing  where it's you're pining one account  and then you jump to the other one  and you've got that and you've got that.  And in this case, it was actually a ransom.  You know, it's not even like he managed to pivot.  But we do see compromising one accounts  leading to this cascading effect  of other accounts being compromised.  Untrustworthy humans again.  Guessing credit card numbers?  That's nuts.  Come on.  Who lets you keep guessing?  That's crazy.  Actually, I'll tell you who lets you keep guessing.  Quantas lets you keep guessing  and I'll show you on Friday.  That's another topic.  Two-factor authentication,  we just keep going through this again and again and again.  It's nice that GoDaddy has it.  It's bad that nobody outside the US gets it.  Inevitably, that's where their predominant audience is.  But give it to other people.  I mean, geez, everyone else can figure it out.  You can get it on Twitter and Facebook  and everything else.  Why can't you get it on GoDaddy?  Now, Twitter also really wasn't very helpful.  Twitter should have sort of done the mass  after he'd given the account away and said,  well, actually, yeah, we can see this is your account  and here's the paper trial of everything that happened.  Here you go.  Have it back.  And they, by all accounts, were pretty useless.  Eventually, they came to the party  and they did give him his account back  after he'd surrendered it to the attacker.  But it took him a long time.  And I guess the lesson there is it is a free service.  Even if it's a valuable single character account,  it's a free service.  How much support do you actually expect from Twitter?  Last one I thought we'd look at is very topical.  So this was just last week.  And this is what a lot of people in Australia  woke up to last week.  And they were woken up to this at about 2 AM  in the morning for many people.  And allegedly, as you can see here,  Oleg Pliss has locked their phone.  And he's done all of this remotely  and he's now demanding money.  He's demanding a ransom.  A lot of sort of everyday mum and dads in Australia  got hit by this, certainly hundreds.  I don't know quite how they're going to figure out  how to use MoneyPak or Ucash or PaySafe card  when their phone is locked.  And it may be the only thing they have.  But somehow, Oleg or whoever it is who was impersonating Oleg  was expecting them to know that.  So let me explain how he actually did this.  So I've got to thumb in my blog from last week,  breaking this down, showing you how an attack like this works.  So the first thing is the attacker logs into their iCloud.  Now, how the hell does an attacker log into an iCloud?  That is a question that is not yet answered.  For some reason, a bunch of Australians  and some people from overseas as well,  but very predominantly Australians.  And Australia has less than 1% of the global internet audience.  So I don't know why we featured so much.  But somehow, the attacker has got enough information  to log into the victim's accounts.  So for example, it may be that we had an Aussie service  compromised last week.  And it may be that the attacker got a whole bunch  of localized usernames and passwords  and then just started going through them,  holding them all for ransom.  Now, he may have automated the whole thing much more than this.  But this is how you would manually go and hijack someone's  account.  So on the right-hand side, we have the attacker.  So he's pulled out his iPhone or his iDevice  or whatever it is he's got.  And he's logged onto the victim's iCloud account.  That allows you to see where their device is.  So here, I've got my attacker hat on,  and I'm looking at Troy's iPhone.  And I want to hijack that device.  So what I do is I start a lost mode process.  So if you've got iCloud and iOS devices  and you've used Find My Phone, you may have seen this before.  The theory is that if you legitimately lose your phone,  you can see where it is on the map.  And then you can turn on lost mode.  Now, when you turn on lost mode, you can set a pin on the phone.  Now, you can only do this if the phone doesn't already  have a pin.  So all of these people that got owned by this attack last week  didn't have a pin on their phone,  which means the attacker can enter their own pin  into the lost phone mode.  Now, when they do that, they can also put in a phone number.  And the theory is that if you legitimately lose your phone  and someone picks it up, they see a message, which  is normally a lot friendlier than the one you see here  on the left side of the screen.  And they see a phone number that they can click on and use  your phone to call your wife or your husband  or whoever it may be at home on their other phone.  That's the way it's meant to work.  This guy was using it as a code, which he inevitably  wanted to accompany the payment so that he could verify who  had actually paid him.  And then in theory, unlock the phone.  I don't like the chances of you ever getting your phone unlocked  by the way, if you send money to someone called Oleg  Pliss, who has just held your phone to ransom.  So anyway, he'd put a number on.  And then he would put a message like this.  Now, after adding the message, he could also  hit the great big play sound button, which  means that whether the phone is on mute  or whether the volume's turned all the way down,  doesn't matter.  The phone would go absolutely nuts.  And all these people being woken up at 2 AM in the morning  with their phone irretrievably locked.  You cannot unlock it short of a vulnerability in iOS,  of which there have been a whole heap at different times.  But it's probably not the sort of thing  that mum and dad are going to be able to sort of circumvent  and get their phone back online.  So incidentally, the only thing that people could do  is restore from backup.  So they could restore, say, from a local backup of iTunes.  They could just blitz the device and restore from iCloud  if the guy doesn't actually destroy their entire iCloud  account.  You can't remotely unlock.  So even if you've still got access to your iCloud account,  you can't unlock this phone by sort of reversing the process  and turning off lost mode.  Once the pin is set, the pin stays there.  So actually, I mean, the guy's kind of ingenious.  It's a reasonably good attack in terms of the ease  and the effectiveness.  Now clearly, there were a few things that came out of this.  So one of them being security basics.  This was hard stuff.  So there are multiple things that consumers  had to have not done in order to fall victim to this attack.  If they had done any one of these next three things  I'm going to read off, it wouldn't have been a problem.  So one of them was they almost certainly  reused passwords.  Apple released a statement about this.  And as Apple is prone to do it, it was very curt and very direct  and said, don't use passwords.  Please go away.  It was something to that effect.  It was basically saying, look, we don't know.  It's your fault.  I suspect they actually know a lot more than that.  I mean, they see this happen inevitably on the back end.  But they've put it down to password reuse.  So number one, password reuse.  At number two, they didn't have pins on their devices.  Even just a four-digit pin, and it would have been OK.  So I don't know.  Maybe it was that they were giving it a little site.  iPads, and it's the kid's iPad.  But I've got little kids, and I tell you, well,  they can figure out a four-digit pin pretty easy.  So that shouldn't be a barrier.  And the third thing was no two-factor authentication.  If there was two-factor, this must be the fourth time  we've said this now.  If there was two-factor, assuming this is the way  the guy got in and there wasn't some unknown vulnerability  in iCloud, this could not have happened.  Now, iCloud is enormously convenient, and hackers love it.  They loved it with Matt Honen because they could wipe his devices.  They love it with these sort of people as well.  This is why someone probably sitting in the Eastern Block  summer in Europe is able to wake up  Aussies at 2 AM and lock their phones.  It is enormously convenient.  Of course, the reality of it is, if the attacker has access  to iCloud, they could have also taken the backups that  go to iCloud, because backing up to iCloud is so convenient.  It's also convenient for the attacker.  He could have taken those backups, restored them  to his device, accessed things like the keychains that  get synced across your Apple devices, because that's  also very convenient.  And basically, just taking over people's lives, or as Matt  Honen said, basically destroyed their digital world.  So an enormous amount of potential for hackers.  Now, the ransom one is a bit interesting too.  Clearly, that did possibly give the attacker opportunities  to do other things, but ransoms are this sort of other class  of software we're seeing.  Often seen called ransomware.  Things like crypto lockers in the news a lot at the moment,  where attackers will get more wear onto PCs,  generally do a pretty good job of encrypting all their data,  and then say, look, if you want to decrypt it,  you've got to send me $200.  So ransoms are becoming a thing.  But from Apple's side as well, you do have to wonder,  just how many devices should someone  be able to lock with a message from Oleg Plyst  demanding a ransom before Apple go, maybe this shouldn't happen?  Now, I know that they're massive,  and they have all sorts of resets and things go on,  but this is a sort of fraud pattern  that they probably should be detecting.  And the question for you guys is in your apps,  where there are critical functions,  things like being able to take over people's devices,  maybe just knowing your username and password  isn't really enough to let people do that.  So wrapping up, there are a few things here  that were really common patterns across the whole thing.  And one of them is, is that all of these risks  are really well known.  They're really well documented.  Heaps of free material out there,  heaps of stuff like my PluralSight courses,  I've got free ebook on Troyhunt.com, numerous blog posts,  all of this stuff is known by many security professionals,  known by many developers as well.  So a lot of this is not new,  yet we keep building vulnerable apps.  A clearly interlinked accounts is another biggie.  So we keep having problems where we create these  interdependencies between accounts.  And I think almost as a consumer,  the thing we've got to think about  is do we really want to allow this account  to be reset by that one?  Or should you be able to authenticate over there  and do something over there?  Convenient, yes.  Secure, yeah, can have issues.  We've seen some very bad humans throughout this process.  Humans are notoriously bad at security.  And I mentioned social engineering  is one of the biggest risks that we have.  Computers are very good at doing what they're told to do.  Sometimes they're not told to do the right thing,  which is another issue altogether.  But certainly they are more predictable in this way  than humans.  So don't forget the social engineering aspect.  And finally, it does come back to us as the devs.  So what sort of training are we getting  to understand these risks?  For those of us managing teams  or delivering on behalf of organizations,  what sort of processes do we have  around penetration testing?  Even automated scans.  So he put tools out there.  You can just point at a website,  it'll come back and say here's 50 things  that are wrong with it.  So there are very easy ways to do it,  but we as developers have got to take  some responsibility for it.  So with that, thank you very much.  I did refer a number of times to Friday  where I am going to do demos  and show things to get broken.  And because I'm in Norway  and a lot of people said I should do this in Norway,  we're also going to look at Pony Swedish websites,  which I believe is quite popular.  Thank you very much.  Thank you very much.  Thank you very much.  Thank you very much.  Thank you very much.  Thank you very much.  Thank you very much.  Thank you very much.  Any question time?  Couple of minutes, any questions?  Over here.  Can you pass the response after the class?  You don't need that.  I don't have any.  Do you have any vulnerability?  All right, so the question is about password managers.  And the gentleman mentioned key pass.  Key pass is one, last pass is another.  I use one password.  Do they have any vulnerabilities?  Probably, do I know of any no?  I think password managers are about the best  mouse trap we have for managing passwords.  Because if we want to be strong,  so it has to be long and random  and all these sort of things,  and we want to be unique,  we've only got so much memory mass to be able to do that.  So we certainly can't do that across the breadth of accounts,  particularly people here probably have,  because we create so many accounts online.  So I personally feel that the best balance  is to get a good password manager,  last pass, key pass, one password,  and use that as much as you possibly can.  Any other questions?  Nope.  Okay, well, do remember,  oh, up there, sorry, you're behind the light.  Ah, good question.  So what is the hashing algorithm  in the SQL membership provider?  So it depends on the version of ASP.NET.  So the one that we're going to break on Friday  is the ASP.NET implementation  that you would get with the Visual Studio 2010 project,  which gave you one round of SHA-1 with Assault,  which is totally useless,  and we will hack that at a rate of 10 million passwords  a second on Friday.  And that's slow, because it's on this.  We can do $4 billion at home on a good machine.  Newer versions have different implementations.  I think the latest one is doing a thousand rounds  of PDKDF2 with SHA-512.  So even that, by many people, is viewed to be insecure.  So the short answer is it's getting better,  but go back a few years,  and it was very bad by today's standards.  Anybody else?  Okay, look if everyone could fill out the evals on the way as well.  We'll do a...  That's the green card on the end.  Don't worry about those.  Thank you very much, everyone.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.
Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_0_47.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_48_95.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_96_143.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_144_191.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_192_239.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_240_287.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_288_335.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_336_395.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_396_443.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_444_491.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_492_539.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_540_599.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_600_659.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_660_707.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_708_755.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_756_803.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_804_851.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_852_899.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_900_1067.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_1068_2135.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_2136_4967.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_4968_5267.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_5268_5531.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_5532_5579.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_5580_5759.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_5760_6179.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_6180_6431.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_6432_6503.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_6504_6551.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_6552_7523.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_7524_8831.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_8832_11243.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_11244_14747.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_14748_18683.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_18684_18983.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_18984_21935.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_21936_23723.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_23724_24359.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_24360_28367.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_28368_30755.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_30756_31811.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_31812_32903.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_32904_36203.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_36204_36875.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_36876_37211.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_37212_37775.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_37776_41963.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_41964_43055.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_43056_44327.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_44328_47567.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_47568_50759.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_50760_52187.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_52188_56183.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_56184_58427.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_58428_59771.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_59772_60503.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_60504_65219.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_65220_68735.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_68736_69131.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_69132_69647.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_69648_71831.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_71832_73067.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_73068_74663.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_74664_75155.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_75156_75611.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_75612_76559.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_76560_76691.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_76692_78191.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_78192_82643.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_82644_85091.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_85092_85139.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_85140_85187.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_85188_85235.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_85236_85283.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_85284_88931.png Troy_Hunt_-_Builders_versus_breakers_____10_online_attacks_we_could_have_easily_prevented_88932_92964.png