Web Security Essentials by Example
Hunt, Troy
There's a huge amount of information to absorb when it comes to web security but as broad as the discipline is, there are common patterns to look for. In this talk on the "essentials" of web security, we'll look beyond the headlines of commonly discussed risks and delve into details and demonstrations. It's a very practical look at online security in a way that everyone can absorb and take back to their everyday work with them. Many of the demos use real world websites and data breaches as examples – this is a very "real world" talk about the importance of web security.
 I'm not responsible for anything you do with the information I've provided in this video for you. So if you're going to do that with this information which I've given you, I'm not responsible for anything you do with the information I've provided in this video. So yeah now that I've got that out of the way let's get started. So what we've got to do is we've got a loadup command prompt. I like my color green. Then what we want to do is we want to type ping and then I've got a bunch of random IPs here. So ping and then just paste it out or you can type out hyphen t hyphen out and then the amount of packets. So this is the command it pings them and this is the IP it will ping. This is how long you want it to do it for. So I've put a limited timer. This is how many packets you want to send right here. So let's just hit that and as you can see it's already began the process of DDoSing the IP. Now there's one thing I'd just like to say like when you do this sometimes it will come up with like a timeout message. This means that the IP could be wrong or in fact your connection is not strong enough to send packets or could just be a general error because it could do all of this and then just say timeout and then carry on. So it could just be like the pings that I actually sent. So once you're done you hit control C and sent 43 packets. They received 43 packets. They lost nothing on their computer so it's a 0% loss. So basically they must have a strong connection. You've got to do this for a while with this method. So go outside and play while you DDoS and then mustn't. I don't know. But yeah. How do you like that? That's awesome isn't it? Did you know you could do that? I like the bit where he says just go outside and play while you DDoSing them. It gives you a bit of a sense of how sophisticated our adversaries are. So yeah often this is kids right? And we spoke a little bit about kids in the last talk. And recently we saw this as well. So we had the Paris attacks and Anonymous says we're going to declare war on ISIS. We're going to take down ISIS. And this was posted on Facebook. And I saw the most epic comment ever left about Anonymous coming after ISIS. All right. So here's how this session is going to work. I'm going to just show lots of different things that are not in any one deck or any one process. I'm going to sort of pick things that have been showing recently that I think are interesting. And we're going to do a lot of hands on stuff as well. So it's meant to be sort of very practical. And basically I'm just going to keep going until I run out of time. And then we have to have a break. So I want to show you a few different things around security. I want to try and make it pretty practical as well. And one thing I thought we might start with is we talk a lot about HTTPS and how do we do HTTPS right? And this is the thing with HTTPS. It's not like do you have it or do you not have it? There are lots of different levels of getting it right. Lots of different levels of screwing it up. And I want to give you an example. Here's one that really, really bugs me. And it's from an Aussie site. I'm going to start by insulting the Aussies. So when I go to Qantas, we get this nice scene. But when I go to Qantas over HTTPS, watch what happens up in the address bar. You got to watch it carefully. Let's try reloading that. Watch it this time. You see what happened? I'll show you again. Just watch carefully right here. It goes green and it's like there's hope. It's secure. And then you think they take it away. It disappears again straight away. So anyone know what this happens? Yes. Oh, no, not you. Anyone else? Anyone who's not an owl? So what's happening here is explained when you click on here, it goes you've loaded this page securely, but there are other resources which are not secure. Now this is really basic, right? Like you should put secure things on a secure page. But what they're doing is they're loading the page over HTTPS. So you can trust the page. No one has been able to view the page in transit. No one has been able to modify the page in transit. But then something else is happening which is making it insecure. There's another insecure resource being put on the page. Now there's something else kind of cool you can do as of the last day, which is that if you have the latest and greatest version of Chrome, you can now go in and you can go to the security tab. And in the security tab, we get a nice little report. So this security tab, go and get this, brand new. It's been in the beta for a while. Let's just hit the public airways. And we can go in here and we can see what the problem is. And we can see that there was a non-secure origin, which was quantis.com.au. And we can see that everything else here was secure. And it's kind of interesting because then when we go down and we actually have a look at the console, we can see the problem that was explained here in the console. Mixed content. The page here was loaded securely, but it requested this image insecurely. Why do you do that? You requested this image insecurely as well. So basically they've loaded this sprite in insecure fashion. This sprite has taken away their green padlock and their green HTTPS. And browsers keep evolving in the way they do this. So what Chrome used to do is you used to get like a little orange triangle up until a few months ago. And now they're going, you just don't get a padlock at all. You get nothing, which is cool. Google also wants to move Chrome to the point where rather than saying that a page, let's take my blog for a second, rather than say this page loads, I don't have HTTPS. There are other reasons for that we might get into later. And I just got a white page. They want to get to the point where there's a like a red cross. So some visual indicator which says you can't trust this. You can't trust it because it hasn't been loaded securely. And this is good, right? So you keep sort of raising the bar, forcing people to go towards HTTPS. A really good resource for this sort of stuff is SSL Labs. Who's used SSL Labs before? I don't need to show you then because that's most people. But use this in case you haven't. So this will go to a website and it will come back and it will tell you everything that is either good or bad about it. So if I take something like my Have I Been Poned address, plug it into here and run it. It'll come back and eventually it will say it's got an A grade and a Zura has done things right. And I'm just running on a Zura and it's basically a Zura's implementation of HTTPS. So this sort of stuff is good. We're kind of continually raising the bar. Now I want to show you something interesting. This is something that really drives me nuts. Let's go to somewhere English. Oh, it hasn't warned me. I wonder if it hasn't warned me because I'm here. Anyone know what I'm looking for? Let's try HSBC. Wow, no cookie warnings. Why no cookie warnings? Who's got a site that does a cookie warning? Do you guys do that here? Yeah? Do you like it? So you know what I mean. Everyone sees these cookie warnings and I look at this from Australia and I go, what are these European people so worried about? What's the problem with the cookies? And I wrote something a little while ago which was like just really bad UX patterns. So things like you go to a website and you just get a full screen banner and you have to wait for the banner to load. If ever you go to anything on Forbes, I don't know if anyone here look at Forbes, they do this. If we go somewhere like that, why are you doing this to me? I don't want to see the quote of the day. I don't want to wait and I don't want whatever the hell this is down here. I don't even know what that is. Why are you giving me ads? And then you get to continue. So I write about all these really nasty practices. But the cookie one was interesting because I said the cookies are a bad UX experience. Particularly mobile, you go there and it's like half your screen is a cookie warning and no one seems to like it. But here's the interesting thing with that because people say we have to do it because it's EU legislation and you could be tracked. If you have cookies, you could be tracked. And I sort of say, well, you can be tracked anyway because you can go somewhere like this. And you go, am I unique.org? You go to am I unique.org and you ask it to fingerprint your browser. And what it does is it goes away and it looks at various attributes of your browser and your user agent settings and it's going to come back and tell you how unique you are. So here we go down the bottom line. The interesting to see if you guys run this as well, see if you get the same results. 132,000 people have tested this and there is no one else like me. I'm an individual. I'm unique. Isn't it nice? So I don't have to send cookies back to a tracker who then track me as I move around. All you have to be able to do to track someone is get them to make an HTTP request. So if you're like double click or Google Analytics or any of these sort of things, so long as you can get the person to make a request, then you can track them. And have a look at how it does it. This many people using Chrome, wow, I'm only 0.2% of people using Chrome 48. I told you it was new. I literally updated it this morning. And okay, that is going to change and that might change your thumbprint, but you could always be smart enough to say if all the other attributes are the same and Chrome has revved one version, then you're probably the same person. It's not an exact science. Cookies aren't an exact science. People use different browsers. Well, they delete the cookies or whatever it may be. So I thought this was interesting and have a look at your results as well because you'll almost certainly find that you are one of like 130,000 plus people. So the cookie law thing is kind of pointless. And now you guys can use this as ammunition to say we shouldn't be doing it because we can track it all anyway. So that's an interesting one. Let's have a look at something really different and we might look at mobile apps. So obviously these days, these things are really popular. We've got a heap of different apps on here. And the curious thing about the apps is that many of them will talk to API backends and many of the API backends are doing really screwy things. Really screwy security things, really screwy performance things. And here's what I thought I might show you. I'm just going to pick something from one of my recent talks. And we might pick, I think, what did I do? No, I did this. I did this in NDC a while ago. Alright, so here's how this works. What you do is you get your mobile phone. And if you've got an i-thing, this is how the i-things work. You get your i-thing and you jump into, that was the very end of it. What happened there? Ah, I know why. Alright, you go into your network settings. So you go into whatever Wi-Fi network it is at the moment. You go into your HTTP proxy settings. You set your server as the IP address of your PC or your Mac or whatever device it is that you want to proxy through. And you run it over that port. And what you can then do if you're using something like Fidler is you can catch every request that the device sends through. So when I go into Fidler, normally what I'm seeing here is every request from my host. When I proxy the device, I can see every request from the device that goes through the PC. It's really cool. So you see all the same sort of traffic that you normally see if you're used to using Fidler or Charles on a Mac except you see the stuff that your mobile apps are doing. Now, what I wanted to show you is these guys here, British Airways. British Airways have an app. And what happens in the British Airways app is that if you are a member of the Silver or Gold Executive Club, you can get Wi-Fi passwords. But you've got to be a member. There's no other way to get the Wi-Fi passwords unless you know how to proxy your device. And then what you can do is you can go and load this previous archive that I created. This is what happens when British Airways loads their app. Makes three requests. One of those requests is to this path. If we copy that URL that it loads and we jump over into a browser somewhere, that one will do, there's your Wi-Fi passwords. Right? So what happens is it loads the Wi-Fi passwords before you authenticate. And then they're all just sitting there on the device and their security is that they basically just make the Wi-Fi passwords visible. That's how it works. That's the entire mechanism of authentication, which is kind of scurry. So all of that's already there on the device. Now, that one's bad. I'll show you another one that's even worse. What tends to happen is developers make this assumption that because they have built the APIs and they've built the apps, that that's the way they'll always talk together. You know, they own the ecosystem, but what they miss is that anyone who sits in the middle can actually see the traffic. They can see everything that goes backwards and forwards. And I want to give you an example because I checked a... Oh, that's talking to me. I checked a mobile app recently. And the mobile app I checked is one called Evo Magazine. It's a car magazine. It looks like this. This is the mobile app. And you go to the app store and you download it, and it's a 25-megabyte app. And then after you download it, you can sort of browse through all the editions, which you can see here, all the editions of the magazine. And then if you want to buy one, you click on it and you enter some payment details and then you get access to it. 25 megabytes to download. How much data do you reckon it downloads when you first open it? Who wants to take a guess? I'll take any guess. Any guess that's not Nile. It is actually about two gigs. It's pretty close. So this is the trace just here. And if we select it all and we go to our statistics, what we can see is it actually downloads about 1.8 gigabytes with the zip files. Why does it do this? Because when you go and you actually have a look at the body size, and we go down to the biggest ones, it downloads all of these 75 megabytes or so editions of the magazine. And if we go and pick one that's a little bit smaller, what you'll see is that we can still just jump over to the browser and download it. It's thinking, ooh, you could download it yesterday. That is curious. Let's try another one. Maybe that edition's been removed. But the point here, regardless of whether it actually loads or not, and it does load this one, is that all the editions are already on the device. So, okay, A, from a performance perspective, maybe not so good, because you've just chewed up a couple of gigabytes of my bandwidth. But B, you don't need to authenticate. There's a public URL. Any of you can go there right now and get that edition of the magazine. If you're a little bit good with HTML and JavaScript and CSS, you can recreate the magazine on your own website. You can download it from Evo. So this is what they do. And my assumption is that they're doing it because it's a really nice sort of performance behavior. It's like you buy the magazine, and magically it's just there. You know, you've just downloaded a 75-megabyte magazine like that because it's already on the device, right? You never actually have to authenticate to the service to download it. So do this with your devices. You go home, I know it sounds kind of geeky, but it's kind of cool. You go home and you proxy it and you just see all the stuff it does and you see this kind of stuff. Someone recently said, take a look at the FoxTel app. So FoxTel gives us cable television in Australia. And they have an electronic programming guide, and you have all the little icons of the channels, you know, a little Discovery icon, a little Disney icon, and they're tiny. But when they're downloaded to the iPad, they're massive. They're 3,000 pixels square. And I showed this in a talk once, and a guy came up to me afterwards and he said, I know why that happens. I worked on that app. He said, this is the way the designers gave them to us. Not a security thing, but an interesting little sort of performance issue there. So that one is problematic. I'll do something else. Let's have a bit of a look at passwords. And I've got a little video here to show you for passwords. And then we might do a quick bit of password cracking as well. So recently, there's a really good example here from Jimmy Kimmel. And what he did is he went out onto the streets and he asked people about how they store their passwords, or rather how they create their passwords. Check this out. We're talking about cybersecurity today and how safe people's passwords are. What is one of your online passwords currently? It is my dog's name, and the year I graduated from high school. What kind of dog do you have? I have a chivalry of Papillon. And what's its name? Jamison. Jamison. And where did you go to school? I went to school back in Greensburg, Pennsylvania. What school? Hempfield area senior high school. Oh, when did you graduate? In 2009. Oh, great. Getting passwords is easy. You don't actually have to crack them. It's like you just ask, what was your password? But this is actually interesting too, because it's a good sort of social engineering example where the reporter is, she's not coming on too heavy, right? Like she doesn't just say, give me your password. She says, how do you create your password? That's the dog's name in the year I graduated. And then she starts this dialogue, right? So it starts having this conversation. What kind of dog do you have? And anyone who has a dog wants to talk about their dog, right? They're going to cough up the information. And she kind of leads the person down this road to the point where she gets the answer out of them. So it's really interesting to remember that even when we do our best with the security, physical, digital security of our systems, the security of our humans is still really crap, right? Like they still succumb to these things. But let's actually take a look at some password cracking just very quickly to put it into context for anyone who hasn't seen how this works. What I'm going to do is take an example here, which is what I did in my workshop the other day. So I showed you Stratfor before, and Stratfor had all of these passwords. And all of these passwords were stored as MD5. So you know how we did a search and we found that it was Stratfor and we found 12,000 people or something used them. Now, what we're going to do is actually jump into Hashcat. Who's used Hashcat before? There are a few people. Excellent. So this won't be new for some of you, but for the vast majority of you, you weren't seen this before. So I'm going to look at CUDA Hashcat. So CUDA is going to run in my Nvidia graphics card. And in here I have Stratfor hashes. And these are all the hashes from that Stratfor data breach. There's about 860,000 or something in there. And what I'm going to do now is I'm going to take one of these commands, which is going to target Stratfor hashes. In fact, I think I'm going to do this one. And what we're going to do with this command is it's going to take those Stratfor hashes. And it's going to recalculate hashes that are passwords anywhere between 6 and 10 characters, lowercase, uppercase, decimal. And it's just going to sort of create these hashes on the fly in the GPU. And we're going to see how many of them actually get cracked. And the interesting thing here is just how fast it goes. And normally I sort of say to people, how fast do you think we can crack hashes in a GPU? So for someone who has not worked in HashCat before and knows the answer, what do we reckon? How fast might we create hashes in a GPU? Who wants to guess? MD5. Someone who doesn't know the answer because otherwise it kind of messes it up. Two million a second. Any other guesses? How many? Billions. Holy shit, you've got a fast computer. Billions. Okay. So we end up. Now this is just a little machine here. So this is not going to be as fast as a dedicated GPU in a big machine. But what we're doing now is just feeding in hashes. And it's going to start to warm itself up. And oh, you know what I've got to do, actually? Let's do this. I've got to delete the ones I did earlier on because otherwise it goes through and it does the same ones again. So we're going to delete the POT file down here. Get rid of that guy. All right, let's try that again. Back to there. Run. So here's the thing with hash cracking. And now here we go with cracking hashes. It doesn't look like really fast. I mean, it looks really fast, but it's much, much faster than what it looks like. So this is actually doing. Let's just pause and get a status here. When I press pause, it's going so fast, there's so much buffered to go to the console. It actually takes a while. What it's doing is it's actually calculating MD5 hashes on the fly and then comparing them to the ones in the database. And then if it actually finds a match of that hash, then it knows what the plain text value is. And in this case, we're ripping through and we've done this. How many we've calculated so far. We've recovered 6,900 of those hashes already, which is kind of nice. It normally runs in this machine. It does in the order of, I think I saw about 18 million per second on my little laptop the other day. But to the question about how fast could we do it on other hardware, when we look at hash cat, and this is where it sort of gets really interesting. Let's move to there and we go and we look at a standard machine. So what they do is they say, here are some examples. So a machine running an AMD HD 7970, which is a fast GPU or was a fast GPU. It's about five or six years old now. You would buy it, I guess in US dollar terms for about $300 at the time. A GPU of that class can crack MD five hashes that fast, eight and a half billion a second. So not million. It can calculate that many hashes per second, which is just massive. And that's like the old hardware, right? Like we've now had Moore's law and things have progressed and things have got faster. But that's how fast it was going. Now, the curious thing about this as well is that that is just if you have one. So there's a company called Strixia Group. Let's run by a friend of mine who create devices that look like this. And what they do is they put eight of those GPUs in one rack. So now we're like what 64 billion hashes a second. And then they have lots of racks. And the whole thing gets parallelized to the point where they can crack all of this sort of stuff enormously quickly. So the main lesson out of this is that you got to go and have a look at something like the OWASP password cheat sheet. Where they talk about using a password hashing algorithm where you can have a work factor. So something like Bcrypt where you can say, I would like my GPU or CPU, depending on where it's being calculated, to work this hard or that hard or that hard or however hard it needs to work such that you can't calculate billions a second, but that your application doesn't run terribly when you get 10 people trying to log on at once. So you need one of these adaptive algorithms that actually makes it slower. And that's what Patrion who I showed you before did. So Patrion had Bcrypt and they had a work factor 12, which would have made it really, really hard to crack just about anything other than terrible passwords. So good news there on the hash cracking front. Let's try something else. We might try talking about DDoS for a second, because DDoS comes up a lot, distributed denial of service attacks. Last week, anonymous, anonymous DDoS Nissan. Did anyone see this? Why would anonymous DDoS Nissan? I'll give you a hint. It has to do with whales. That seems fair, right? Like Japan kills whales, therefore anonymous will attack a car company. DDoS is basically just a kid throwing their toys. You know, they have a tantrum, it gets over, people move on, it does no long lasting damage. But that's effectively what it is. Now the interesting thing with DDoS is that you can go to this link, map.ipviking.com. You fire that up and you put it in full screen because it looks really awesome in full screen. Usually. There we go. So this starts to fire up, we should see a map appear in a moment as well. And it's showing us real time DDoS attacks. And it's kind of cool, like it's kind of mesmerizing. You get to see things like the origin, the types, the targets. Can you see that there's usually a bit of a pattern? For some reason the traffic generally tends to move from the east to the west. I don't know why that is. We see the same country sort of featuring a lot. So we see a lot of these DDoS attacks and it's interesting to look at things like the attack types as well. So some of them are running over Telnet, other ones are running over UDP. Sometimes they run over NTP, the network time protocol. So these attacks exploiting different protocols in order to try and send as many malformed packets as possible. Yeah. That's a good question. How does it distinguish DDoS traffic? Does anyone know? Can you tell me if you figure it out? I honestly don't know. I don't know how these guys actually do their measurements. I just know it's mesmerizing. They do have a bunch of other info on there. But it's kind of cool to sort of see how often this data is flowing around. And every now and then you just see, particularly out of China, you would just see like a massive whack of traffic go west over to the US. So DDoS is a real problem. And it is something that keeps occurring a lot and we particularly see it continually occur with kids. Yep. Question? How do they know if an attack is originally distributed? If it's distributed, well a lot of it originates from the one country still. So let's have a look at what else we got here. Oh, that's my wife. That's what happens when you leave your Facebook notifications on. I'm not sure exactly how they do their measurements. There are a couple of other services that do same things. I mean, you could obviously do it at the switch level at large ISPs within different countries. I guess they've got to identify also that the traffic is malicious. You know, some of these are done over HTTP or UDP, where we have a lot of traffic flowing backwards and forwards anyway. Talk a little bit more about DDoS. And grab a couple of things here. So one of the things that we have often seen in the past with DDoS is stuff like this. All right. Everyone seen this before? So we'll just see all of these tweets. Fire up your lasers. Point your lasers at whatever the hell they want to point them at today. We saw stuff like this happen against PayPal. So PayPal stopped taking payments for WikiLeaks around about 2011. And all the kids got on the Twitter and said, okay, what you got to do is you got to point Loic over there. Anyone seen Loic before? A few people? Free software. You plug in a URL and then you say target. And it just throws random packets at it. Now think again about the type of kids that I spoke about in the last talk. Like they've got no idea of the ramifications of what it is they're doing. All they know is that somebody on the internet said, point your lasers at this address. And if you get enough kids around the world doing this at the same time, they get to take stuff down. We saw this sort of attack happen against Steam over Christmas. Not necessarily with Loic. I think they were using a different tool. But Steam got DDoS over the Christmas period because kids seem to like taking down gaming services over Christmas. They're just nasty. A year before they were taking down PlayStation Network. And the interesting thing is that when they were attacking Steam, Steam then put on a bunch of other services to try and cope with the extra load. They put on a bunch of other caching engines. And when they put on those caching engines, they also screwed up their session association with the client. So what was happening was that you would go to Steam on the website and you go, that's just interesting. That's someone else's private details. Because they cached the identities, they tried to remove the load from the back end. They implemented more caching, but they effectively lost the affinity between the client and the session. So I suspect part of that was just sort of responding under duress as well, which made life very hard for them. All right, so often DDoS is very simple. It is just basically this. Another one that we keep coming back to, and we spoke about this just before, was SQL injection. And I showed you SQL map and someone asked, you know, look, is it basically just put the URL in? These tools are really, really simple and they're really readily available. And I'll give you an example here. So we will go to this site here. Now I use this for a lot of my demos. And I use it in a lot of my workshops. And it has a bunch of different SQL injection risks on it. It's basically a website where you can log on and you can vote for cars that you like. And then there's a leaderboard. It's deliberately vulnerable. There's lots and lots of vulnerabilities on this site. Anyone's welcome to go and play around with them. You can go and exploit SQL injection on here and not go to jail, which is really good. What you can do is say something like, okay, I want to view the Lamborghinis and I'm going to take this URL. Now let's make this a bit more interactive. So who has actually done SQL injection it takes before? Okay, some of you, some of you, you haven't. You want to come do one? Yeah, let's try. Because then if it's you and not me, I'm okay. You'll go to jail. All right, so here's what we're going to do. I'm just going to open up a tool called Havage. Now some of you may have seen this before, but I want to make the point of how easy it is. What's your name first? Pauvel. Pauvel, I'm trying. How am I? Pauvel, okay, Pauvel. So here's what you're going to do. You're going to be the hacker. And what you've got to do is you've got to paste the URL on the clipboard into that target field. Yeah, you paste it over the other one. Very good. Hacking is hard. Look at that. All right. Now you click the analyze button. So what it's doing is it's just making HTTP requests, right? This is not going direct to the database or anything like that. It's just making requests and trying to cause internal exceptions that disclose the structure of the database. And what it's actually done now on the bottom line is it says the DB name is hack yourself first underscore DB. So it's already found the name of the internal database. Now what you do is you go up and you click on the tables button because what you want to try and get is a list of the tables. And then you click on get tables. There we go. And it goes away. Here we go. Now remember while we're doing this, and I'm not saying that Pavel is like a 15 year old kid, right? But this is what 15 year old kids do. They can copy and paste URLs. Now which table should we get, Pavel? Well, I reckon that's kind of public. Let's get user profile. So you just click the check box next to user profile. That's about the hardest thing of SQL injection, like knowing which box to check. All right, let's get the columns. So it goes away and it's going to think because we want to wait until it finds all the columns. And again, all it's doing here, now let's wait till it finds them all before we do anything more. It's just making HTTP requests and it's causing exceptions in the database which bubble up to the user interface. Now if you were a hacker, what data would you get out of user profile? Oh, you're good at this. Yeah, very good. All right, let's get the data. There we go. That's SQL injection. Well done, Pavel. Good one. All right, so this is kind of the point, right? Like it is really, really easy to mount a SQL injection attack. And what we're seeing these kids doing is they're using these tools. And to be honest, like Havage is a bit of a, we'd say a Mickey Mouse tool, right? Like it's very, very basic. It's a nice little gooey interface. The hardcore guys are going to use something like SQL injection. Sorry, they're going to use something like SQL map. SQL map is much more effective. But the interesting thing as well is how people are finding sites to hack. And I'll show you because it's actually really, really easy. What they're doing most of the time is they're jumping into something like a Google search and they're saying let's do a search for in URL. And then they'll say, okay, in URL what I want is question mark ID equals. And then they might narrow it down a bit and they'll say, well, you know, what I really don't like is I don't like, I don't like Swedish sites. We still don't like Sweden here, right? Yeah, very good. Okay, I don't like Swedish sites. And then they would get a list of sites in Sweden which they don't like, which should have an ID equals somewhere in the query string. But actually how we might do this, we'll sort of narrow it down a little bit and we'll say.asp, get like classic asp. All right, because if it's classic asp, we know their chances of having good SQL injection defenses are going to be much lower. And then inevitably what you get is a list of URLs and you get IDs in the end, which are integers, and almost certainly if you pick a bunch of those and you put a non-integer character after the integer, you'll see an internal exception. Because what they're doing is they're just passing this untrusted data into the database and saying just run this, it's just part of a script. So for something like one of these, it's going to be select star from widgets where widget ID equals whatever the user gives us. If it's a one or two or three, it's fine. If it's a three X, the database is going to say it is not a valid integer type. There's a cast exception and that's that. So that's how SQL injection works. You may have also noticed that I have SQL injection on my t-shirt to Bobby Tables. So SQL injection is just a ridiculously easy attack vector. While we're here doing Google searches as well, there's other stuff that you can find via Google because there's just so much stuff that is openly searchable. So I like this one. There's one you can do which is in URL, FTP. So Google will index things over FTP. And then you can go down and say, well, let's get web.config files. Who knows what a web.config is? In an ASP.NET application, the web.config is where you have the connection strings, the machine key, which is effectively your private encryption key, your API keys in your settings, a whole bunch of really, really good juicy stuff. So you go and you run that and then you find all of these sites that have got exposed web.config. Now, what this means is that there is open FTP to these websites. Google can read from them because they allow anonymous access. So not only can you go and get FTP or you can go and get web.config, you can probably go and get anything from any of these sites. Not only can you get stuff, but if they've left anonymous FTP enabled in read access, they've probably also left it in write access. So you can write to these. And when you scroll down through these, you sort of get a sense of the diversity of just how much stuff is there..gov. Washington State Department of Transport. I know that's what it is because this has been here for years. They still haven't fixed it. It's still open. There was a time when I emailed a bunch of sites and I said, hey, you might be interested to know that your FTP is open and anyone can access your stuff. And no one replied. So fair enough. So that is curious. But of course, once you can start running these Google Docs, and this is what I meant earlier on. I said Google Doc, like a carefully crafted Google search. And just in case you really, really want to run other Google Docs, you go to exploit DB Google hacking database, which is there. And you can get a list of Google Docs to run. You can get different types of Google Docs. So maybe you would like to do a search for files containing juicy info. I wonder what's on. I've actually never looked in there. Let's see what's in there. This may not be public forum suitable stuff. Who knows? Okay. So what do we got in here? We've got things like stats generated by we've got Apache server status. So we're probably going to get some logs and things. PDFs with tax returns in them. What's in that one? Then you can run the Google Doc. And then we don't click on any of the links. But you get the idea, right? A lot of it is just index it's public. Looks like some of these are served over FTP as well. Inevitably, some of these are going to have some pretty sensitive personal info in them. We can learn other things by modifying our Google Docs just slightly. So again, this one which search for web.config. Web.config have connection strings in them. Connection strings connect to databases with accounts. Sometimes they connect with very privileged accounts. Anyone know what the SA account is? Right. So the admin. This is the God writes account. If you can connect to a database with SA, you can not only access everything in the database, you can access everything in every other database. You can execute any other commands on the host SQL version. So you can restart it. You can probably execute XP command shell which allows you to execute commands on the host operating system. And if you can't, you can enable XP command shell by hitting another command. If we find results here, then they're extra bad. Here's what I really like about these results. Password. Now, your passwords should have a combination of letters and numbers. Like that. Not like that. Don't do that. And don't use SA. Why do you think people do this? It's very easy. I'll tell you, this makes setting permissions really easy. Because it can just do everything. You don't have to worry about going to every table and setting data reader or data writer or any of that sort of stuff. It's like magic just happens. Makes life very, very simple. So that one's kind of curious. Let me show you something else. And I'm going to open my password manager for a second. Who uses a password manager? Who uses one password? Who uses last pass? Any others? Keep pass? Okay. Use a password manager. Whatever it is. I like one password for various reasons. But frankly, if you're using a password manager, you are so far ahead of everyone else anyway. All right. So what I'm going to do here is I want to just have a quick browse through one of these underground sites. And I'm going to start up my tour browser. Because one of the things I think people find very curious is the fact that we do have a lot of information for sale on the web. And what I want to do is I want to jump into Alpha Bay. Normally I don't do this in like really public talks. But this one is not so public. It's just us being recorded. All right. So everyone remember the Silk Road? Silk Road was a really large underground drug site run by a guy that went under the chute and named Dread Pirate Roberts. Dread Pirate Roberts was actually a guy called Ross Ulbricht. Ross Ulbricht eventually got caught. And one of the reasons he got caught is because he made a Stack Overflow post. I'll show you what it was. I was in this talk here. And this is kind of funny, right? Because he got this guy running this underground drug market. And basically he was asking questions on Stack Overflow related to running his underground drug market. This is the question he asked. This is one of the things that brought him undone. He originally created the profile using an email address that identified him personally. It's one of the ways he got caught. Anyway, Silk Road got taken offline. Of course we've seen other things pop up in its place. Stuff like Alpha Bay. I want to show you what Alpha Bay looks like. 7mp. I'm going to do that. I then have a really, really random username and password. I don't know why I chose Google Google. I think I just fat fingered it. So we do that. Because we're going to have a look at what these guys are actually selling. No idea how this will turn out. And they really like captures, don't they? This is the second one. 9b. Now for those of you who haven't used Tor, it's very easy to get the Tor web browser. You just download it. Google Tor web browser. It does have very legitimate purposes as well. It's a good way of having anonymity. And then inevitably when you have the Tor browser, you can go to these onion websites. So this is running on a server somewhere which we are accessing by going through multiple different Tor relay points. So our traffic is sort of getting bounced around the world such that they don't know who I am and I don't know who they are. Now there have been exploits against Tor. So we saw quite a bit of news a few months ago where Carnegie Mellon University apparently had demonstrated that if you have enough Tor exit nodes that you run, you can start to de-anonymise traffic because you can start to see where the traffic goes. But I wanted to show how easy it is to get in here and find things of this class. Drugs and chemicals, weapons, going to stuff like fraud. Have a look at what we get in fraud. Dumps. Would you like to buy some dumps? US dumps. What do you want in here? You want to buy a Skype man Spotify account? Would you like to buy Spotify accounts? As seen on Krebs and security, he is using Brian Krebs in order to promote his stolen Spotify accounts. Two bucks. I assume that they are probably about two bucks each. The curious thing about this, this is sort of what I was touching on in my previous talk. This is a marketplace that does not look dissimilar to many of the other marketplaces you see online, legitimate marketplaces. We have a seller, you will see that we have things like the vendor level, we have a trust level in here as well. Everything is nice to categorise, good description of it here. They have a whole lot of guidance in here about how to go and use Bitcoin to buy these things in a manner that makes it difficult to trace you. This is how easy it is, it is just a marketplace, you browse around and you buy these things. You can be buying drugs and weapons the same way. Mind you, you have to get them delivered, which is a lot harder than actually getting Spotify accounts delivered. So that is that one, I find that a really sort of curious thing about just how easily accessible this is. It also helps explain why data bridges are valuable, because you can go and sell them. People want to break into systems, your systems, because they can turn around and put them on the market. It is that easy. Okay, something a little bit different as we start to wrap up, one of the interesting things that I have found lately is IoT. So we have all seen a lot of IoT connected things, right? And we are starting to see vulnerabilities in IoT connected things. And actually, you know what, let's start with VTech. We will go back to VTech again. I talked about VTech and they inevitably had vulnerabilities in the APIs behind their IoT things, their tablets. And this was actually some of the data they had taken out. I never got given the photos, which I am quite happy about. But these are the photos of kids and sometimes with their parents that got leaked. Now curiously, so this was VTech, all this data got leaked out in October, November timeframe, because they had things like no transport layer security and they had enumeration risks and SQL injection risks. But the good news is that VTech is now moving on and they are building home security systems. Holy shit. This is at CES. The reporter I worked with on the VTech data breach took a photo of this and sent it to me. He thought I might find it amusing. I certainly did think some things when I saw this. Probably don't buy these ones. I got to feel a little bit sorry actually for these guys because they would have had this stuff being built well in advance of the VTech data breach. And inevitably they are totally different teams, totally different places, totally different approaches to security. But I feel sorry for the people working on these products because they must have seen how bad that VTech data breach was and just gone, oh crap. Now we got to try and sell home security products. Anyway, brings me to things like this. Now some of the interesting IOT stuff that we are seeing pop up lately, some of it is just kind of ridiculous. I don't think this is ridiculous, but I am going to give you some ridiculous examples in a moment too. So this is LFX and this is made by an Aussie company and they are connected light bulbs. And they are really, really cool and I like the idea of having an app where I can sort of change the colour of the bulbs and the brightness and everything. I don't want to have to get off the couch to do stuff. This is our lazy lifestyle today. But anyway, LFX had a vulnerability in the light bulbs. And I know it is a vulnerability in the light bulbs. But the interesting thing about it though is a lot of people say with the IOT emergence if you like, is they say, look in a case like this, alright, if there is a vulnerability in the light bulbs, the attackers may be able to control the light bulbs, do I really care? Like how much of a threat do I think it is if the attackers can put my house into disco mode? Make lights flash. But the vulnerability that they had leaked the network credentials. Right, so now the IOT thing is the attack vector into the network. And I am much more worried about someone having access to my network than what I am about them being able to change the colour of my light bulbs. So LFX came out and they said, yes we had a vulnerability, please patch your light bulbs. How the hell did you patch your light bulbs? I assume you do it with the companion app or something like that. But I guess the curious thing is, are we ready to sort of accept that you have to be able to patch your light bulbs? They also said, don't worry, we are not aware of anyone having been compromised by their light bulbs. Which to me sounds really odd because think about the attack, right? The attack is they get access to the network. If you find that someone is in your network, are you ready to blame the light bulbs? Probably not. Now as weird as this is, and again I would actually like these, they are kind of cool. I have seen two other devices in recent times suffer a similar attack. One is the eye kettle. There is an eye kettle. And the idea is that you can be laying in bed and you can turn your kettle on. Now think about this for a moment because this is pointless, right? What do you do once the kettle boils which takes about two minutes? It doesn't bring the water to you or bring the, you still got to get your ass out of bed and go to the kettle. But the vulnerability with the kettle was they found that you could de-auth the kettle from the wireless network. You could trick the kettle into connecting to your own network and then you could tell net into the kettle with the default pin. Tell net into the kettle. So now you are tell netted into the kettle using the default pin and then you can get the Wi-Fi credentials out for the network. Same problem. So that was the second one I saw and then just the other day when we had CES on, there was a doorbell that had the same problem. A fucking doorbell that connected to the web and the doorbell was disclosing the credentials of the network. And all of this stuff is crazy. But none of it is as crazy as this. Have you seen this? Anyone got one of this? You wouldn't say yes if you did would you? So this is a licksil satis and this is real. It's a Japanese toilet. If you've been to Japan you'll know how crazy they are about their toilets. They're all like rocket ships. And this is the companion app. And these are real screenshots. I didn't fabricate these. You can find them on the internet. And you look at them and you try to figure out what's happening. Like take this middle one. It's in Japanese. I don't know if anyone here speaks Japanese and can tell me. But what do you reckon is happening in the middle screen? Looks like a calendar. Like event driven data. Some kind. I don't know what. And I love the one in the front too. It looks like it's a music player. I did not fabricate this. The toilet is playing. I can't get no satisfaction. And I saw this a couple of years ago and I used it in a talk. And I said we are now approaching the era where we have to be aware of vulnerabilities in our toilet. And eventually they had one. Here's the advisory. This is terrifying. Can you imagine this? I showed this at a talk once and someone said yes this is known as a back door attack. On that note, I think this is a really terrifying thing is a good place to end. Let me see if anyone has any questions about what I've just covered. Or are we all just in shock about the fact that this could happen? Any questions, folks? All right, well hey, if you think of anything, put it into the Slido app and we'll be able to cover it later on. I think we get, what about another 15 minute break, Jacob? And then someone else can do some talking. Thanks, guys. Thank you.
 I'm not responsible for anything you do with the information I've provided in this video  for you.  So if you're going to do that with this information which I've given you, I'm not responsible for  anything you do with the information I've provided in this video.  So yeah now that I've got that out of the way let's get started.  So what we've got to do is we've got a loadup command prompt.  I like my color green.  Then what we want to do is we want to type ping and then I've got a bunch of random IPs  here.  So ping and then just paste it out or you can type out hyphen t hyphen out and then the  amount of packets.  So this is the command it pings them and this is the IP it will ping.  This is how long you want it to do it for.  So I've put a limited timer.  This is how many packets you want to send right here.  So let's just hit that and as you can see it's already began the process of DDoSing the IP.  Now there's one thing I'd just like to say like when you do this sometimes it will come  up with like a timeout message.  This means that the IP could be wrong or in fact your connection is not strong enough  to send packets or could just be a general error because it could do all of this and  then just say timeout and then carry on.  So it could just be like the pings that I actually sent.  So once you're done you hit control C and sent 43 packets.  They received 43 packets.  They lost nothing on their computer so it's a 0% loss.  So basically they must have a strong connection.  You've got to do this for a while with this method.  So go outside and play while you DDoS and then mustn't.  I don't know.  But yeah.  How do you like that?  That's awesome isn't it?  Did you know you could do that?  I like the bit where he says just go outside and play while you DDoSing them.  It gives you a bit of a sense of how sophisticated our adversaries are.  So yeah often this is kids right?  And we spoke a little bit about kids in the last talk.  And recently we saw this as well.  So we had the Paris attacks and Anonymous says we're going to declare war on ISIS.  We're going to take down ISIS.  And this was posted on Facebook.  And I saw the most epic comment ever left about Anonymous coming after ISIS.  All right.  So here's how this session is going to work.  I'm going to just show lots of different things that are not in any one deck or any one process.  I'm going to sort of pick things that have been showing recently that I think are interesting.  And we're going to do a lot of hands on stuff as well.  So it's meant to be sort of very practical.  And basically I'm just going to keep going until I run out of time.  And then we have to have a break.  So I want to show you a few different things around security.  I want to try and make it pretty practical as well.  And one thing I thought we might start with is we talk a lot about HTTPS and how do we do HTTPS right?  And this is the thing with HTTPS.  It's not like do you have it or do you not have it?  There are lots of different levels of getting it right.  Lots of different levels of screwing it up.  And I want to give you an example.  Here's one that really, really bugs me.  And it's from an Aussie site.  I'm going to start by insulting the Aussies.  So when I go to Qantas, we get this nice scene.  But when I go to Qantas over HTTPS, watch what happens up in the address bar.  You got to watch it carefully.  Let's try reloading that. Watch it this time.  You see what happened?  I'll show you again.  Just watch carefully right here.  It goes green and it's like there's hope.  It's secure.  And then you think they take it away.  It disappears again straight away.  So anyone know what this happens?  Yes.  Oh, no, not you.  Anyone else?  Anyone who's not an owl?  So what's happening here is explained when you click on here,  it goes you've loaded this page securely,  but there are other resources which are not secure.  Now this is really basic, right?  Like you should put secure things on a secure page.  But what they're doing is they're loading the page over HTTPS.  So you can trust the page.  No one has been able to view the page in transit.  No one has been able to modify the page in transit.  But then something else is happening which is making it insecure.  There's another insecure resource being put on the page.  Now there's something else kind of cool you can do as of the last day,  which is that if you have the latest and greatest version of Chrome,  you can now go in and you can go to the security tab.  And in the security tab, we get a nice little report.  So this security tab, go and get this, brand new.  It's been in the beta for a while.  Let's just hit the public airways.  And we can go in here and we can see what the problem is.  And we can see that there was a non-secure origin,  which was quantis.com.au.  And we can see that everything else here was secure.  And it's kind of interesting because then when we go down  and we actually have a look at the console,  we can see the problem that was explained here in the console.  Mixed content.  The page here was loaded securely,  but it requested this image insecurely.  Why do you do that?  You requested this image insecurely as well.  So basically they've loaded this sprite in insecure fashion.  This sprite has taken away their green padlock  and their green HTTPS.  And browsers keep evolving in the way they do this.  So what Chrome used to do is you used to get  like a little orange triangle up until a few months ago.  And now they're going, you just don't get a padlock at all.  You get nothing, which is cool.  Google also wants to move Chrome to the point where rather than  saying that a page, let's take my blog for a second,  rather than say this page loads, I don't have HTTPS.  There are other reasons for that we might get into later.  And I just got a white page.  They want to get to the point where there's a like a red cross.  So some visual indicator which says you can't trust this.  You can't trust it because it hasn't been loaded securely.  And this is good, right?  So you keep sort of raising the bar, forcing people to go towards HTTPS.  A really good resource for this sort of stuff is SSL Labs.  Who's used SSL Labs before?  I don't need to show you then because that's most people.  But use this in case you haven't.  So this will go to a website and it will come back  and it will tell you everything that is either good or bad about it.  So if I take something like my Have I Been Poned address,  plug it into here and run it.  It'll come back and eventually it will say it's got an A grade  and a Zura has done things right.  And I'm just running on a Zura and it's basically a Zura's implementation of HTTPS.  So this sort of stuff is good.  We're kind of continually raising the bar.  Now I want to show you something interesting.  This is something that really drives me nuts.  Let's go to somewhere English.  Oh, it hasn't warned me.  I wonder if it hasn't warned me because I'm here.  Anyone know what I'm looking for?  Let's try HSBC.  Wow, no cookie warnings.  Why no cookie warnings?  Who's got a site that does a cookie warning?  Do you guys do that here?  Yeah? Do you like it?  So you know what I mean.  Everyone sees these cookie warnings and I look at this from Australia  and I go, what are these European people so worried about?  What's the problem with the cookies?  And I wrote something a little while ago  which was like just really bad UX patterns.  So things like you go to a website and you just get a full screen banner  and you have to wait for the banner to load.  If ever you go to anything on Forbes,  I don't know if anyone here look at Forbes, they do this.  If we go somewhere like that, why are you doing this to me?  I don't want to see the quote of the day.  I don't want to wait and I don't want whatever the hell this is down here.  I don't even know what that is.  Why are you giving me ads?  And then you get to continue.  So I write about all these really nasty practices.  But the cookie one was interesting because I said the cookies are a bad UX experience.  Particularly mobile, you go there and it's like half your screen is a cookie warning  and no one seems to like it.  But here's the interesting thing with that because people say  we have to do it because it's EU legislation and you could be tracked.  If you have cookies, you could be tracked.  And I sort of say, well, you can be tracked anyway  because you can go somewhere like this.  And you go, am I unique.org?  You go to am I unique.org and you ask it to fingerprint your browser.  And what it does is it goes away and it looks at various attributes of your browser  and your user agent settings and it's going to come back and tell you how unique you are.  So here we go down the bottom line.  The interesting to see if you guys run this as well, see if you get the same results.  132,000 people have tested this and there is no one else like me.  I'm an individual. I'm unique. Isn't it nice?  So I don't have to send cookies back to a tracker who then track me as I move around.  All you have to be able to do to track someone is get them to make an HTTP request.  So if you're like double click or Google Analytics or any of these sort of things,  so long as you can get the person to make a request, then you can track them.  And have a look at how it does it. This many people using Chrome,  wow, I'm only 0.2% of people using Chrome 48. I told you it was new.  I literally updated it this morning.  And okay, that is going to change and that might change your thumbprint,  but you could always be smart enough to say if all the other attributes are the same  and Chrome has revved one version, then you're probably the same person.  It's not an exact science. Cookies aren't an exact science.  People use different browsers.  Well, they delete the cookies or whatever it may be.  So I thought this was interesting and have a look at your results as well  because you'll almost certainly find that you are one of like 130,000 plus people.  So the cookie law thing is kind of pointless.  And now you guys can use this as ammunition to say we shouldn't be doing it  because we can track it all anyway.  So that's an interesting one.  Let's have a look at something really different and we might look at mobile apps.  So obviously these days, these things are really popular.  We've got a heap of different apps on here.  And the curious thing about the apps is that many of them will talk to API backends  and many of the API backends are doing really screwy things.  Really screwy security things, really screwy performance things.  And here's what I thought I might show you.  I'm just going to pick something from one of my recent talks.  And we might pick, I think, what did I do?  No, I did this. I did this in NDC a while ago.  Alright, so here's how this works.  What you do is you get your mobile phone.  And if you've got an i-thing, this is how the i-things work.  You get your i-thing and you jump into, that was the very end of it.  What happened there?  Ah, I know why.  Alright, you go into your network settings.  So you go into whatever Wi-Fi network it is at the moment.  You go into your HTTP proxy settings.  You set your server as the IP address of your PC or your Mac  or whatever device it is that you want to proxy through.  And you run it over that port.  And what you can then do if you're using something like Fidler  is you can catch every request that the device sends through.  So when I go into Fidler, normally what I'm seeing here  is every request from my host.  When I proxy the device, I can see every request from the device  that goes through the PC.  It's really cool.  So you see all the same sort of traffic that you normally see  if you're used to using Fidler or Charles on a Mac  except you see the stuff that your mobile apps are doing.  Now, what I wanted to show you is these guys here,  British Airways.  British Airways have an app.  And what happens in the British Airways app  is that if you are a member of the Silver or Gold Executive Club,  you can get Wi-Fi passwords.  But you've got to be a member.  There's no other way to get the Wi-Fi passwords  unless you know how to proxy your device.  And then what you can do is you can go  and load this previous archive that I created.  This is what happens when British Airways loads their app.  Makes three requests.  One of those requests is to this path.  If we copy that URL that it loads  and we jump over into a browser somewhere,  that one will do,  there's your Wi-Fi passwords.  Right? So what happens is it loads the Wi-Fi passwords  before you authenticate.  And then they're all just sitting there on the device  and their security is that they basically  just make the Wi-Fi passwords visible.  That's how it works.  That's the entire mechanism of authentication,  which is kind of scurry.  So all of that's already there on the device.  Now, that one's bad.  I'll show you another one that's even worse.  What tends to happen is developers make this assumption  that because they have built the APIs  and they've built the apps,  that that's the way they'll always talk together.  You know, they own the ecosystem,  but what they miss is that anyone who sits in the middle  can actually see the traffic.  They can see everything that goes backwards and forwards.  And I want to give you an example because I checked a...  Oh, that's talking to me.  I checked a mobile app recently.  And the mobile app I checked is one called Evo Magazine.  It's a car magazine. It looks like this.  This is the mobile app.  And you go to the app store and you download it,  and it's a 25-megabyte app.  And then after you download it,  you can sort of browse through all the editions,  which you can see here, all the editions of the magazine.  And then if you want to buy one, you click on it  and you enter some payment details and then you get access to it.  25 megabytes to download.  How much data do you reckon it downloads  when you first open it?  Who wants to take a guess?  I'll take any guess.  Any guess that's not Nile.  It is actually about two gigs.  It's pretty close.  So this is the trace just here.  And if we select it all and we go to our statistics,  what we can see is it actually downloads  about 1.8 gigabytes with the zip files.  Why does it do this?  Because when you go and you actually have a look at the body size,  and we go down to the biggest ones,  it downloads all of these 75 megabytes or so editions of the magazine.  And if we go and pick one that's a little bit smaller,  what you'll see is that we can still just jump over to the browser  and download it.  It's thinking, ooh, you could download it yesterday.  That is curious.  Let's try another one.  Maybe that edition's been removed.  But the point here, regardless of whether it actually loads or not,  and it does load this one,  is that all the editions are already on the device.  So, okay, A, from a performance perspective,  maybe not so good,  because you've just chewed up a couple of gigabytes of my bandwidth.  But B, you don't need to authenticate.  There's a public URL.  Any of you can go there right now and get that edition of the magazine.  If you're a little bit good with HTML and JavaScript and CSS,  you can recreate the magazine on your own website.  You can download it from Evo.  So this is what they do.  And my assumption is that they're doing it  because it's a really nice sort of performance behavior.  It's like you buy the magazine, and magically it's just there.  You know, you've just downloaded a 75-megabyte magazine like that  because it's already on the device, right?  You never actually have to authenticate to the service to download it.  So do this with your devices.  You go home, I know it sounds kind of geeky,  but it's kind of cool.  You go home and you proxy it and you just see all the stuff it does  and you see this kind of stuff.  Someone recently said,  take a look at the FoxTel app.  So FoxTel gives us cable television in Australia.  And they have an electronic programming guide,  and you have all the little icons of the channels, you know,  a little Discovery icon, a little Disney icon, and they're tiny.  But when they're downloaded to the iPad, they're massive.  They're 3,000 pixels square.  And I showed this in a talk once, and a guy came up to me afterwards  and he said, I know why that happens.  I worked on that app.  He said, this is the way the designers gave them to us.  Not a security thing, but an interesting little sort of performance issue there.  So that one is problematic.  I'll do something else. Let's have a bit of a look at passwords.  And I've got a little video here to show you for passwords.  And then we might do a quick bit of password cracking as well.  So recently, there's a really good example here from Jimmy Kimmel.  And what he did is he went out onto the streets and he asked people  about how they store their passwords, or rather how they create their passwords.  Check this out.  We're talking about cybersecurity today and how safe people's passwords are.  What is one of your online passwords currently?  It is my dog's name, and the year I graduated from high school.  What kind of dog do you have?  I have a chivalry of Papillon.  And what's its name?  Jamison.  Jamison.  And where did you go to school?  I went to school back in Greensburg, Pennsylvania.  What school?  Hempfield area senior high school.  Oh, when did you graduate?  In 2009.  Oh, great.  Getting passwords is easy. You don't actually have to crack them.  It's like you just ask, what was your password?  But this is actually interesting too, because it's a good sort of social engineering example  where the reporter is, she's not coming on too heavy, right?  Like she doesn't just say, give me your password.  She says, how do you create your password?  That's the dog's name in the year I graduated.  And then she starts this dialogue, right?  So it starts having this conversation.  What kind of dog do you have?  And anyone who has a dog wants to talk about their dog, right?  They're going to cough up the information.  And she kind of leads the person down this road to the point where she gets the answer out of them.  So it's really interesting to remember that even when we do our best with the security,  physical, digital security of our systems, the security of our humans is still really crap, right?  Like they still succumb to these things.  But let's actually take a look at some password cracking just very quickly to put it into context  for anyone who hasn't seen how this works.  What I'm going to do is take an example here, which is what I did in my workshop the other day.  So I showed you Stratfor before, and Stratfor had all of these passwords.  And all of these passwords were stored as MD5.  So you know how we did a search and we found that it was Stratfor and we found 12,000 people or something used them.  Now, what we're going to do is actually jump into Hashcat.  Who's used Hashcat before?  There are a few people. Excellent.  So this won't be new for some of you, but for the vast majority of you, you weren't seen this before.  So I'm going to look at CUDA Hashcat. So CUDA is going to run in my Nvidia graphics card.  And in here I have Stratfor hashes.  And these are all the hashes from that Stratfor data breach.  There's about 860,000 or something in there.  And what I'm going to do now is I'm going to take one of these commands, which is going to target Stratfor hashes.  In fact, I think I'm going to do this one.  And what we're going to do with this command is it's going to take those Stratfor hashes.  And it's going to recalculate hashes that are passwords anywhere between 6 and 10 characters, lowercase, uppercase, decimal.  And it's just going to sort of create these hashes on the fly in the GPU.  And we're going to see how many of them actually get cracked.  And the interesting thing here is just how fast it goes.  And normally I sort of say to people, how fast do you think we can crack hashes in a GPU?  So for someone who has not worked in HashCat before and knows the answer, what do we reckon?  How fast might we create hashes in a GPU?  Who wants to guess?  MD5.  Someone who doesn't know the answer because otherwise it kind of messes it up.  Two million a second.  Any other guesses?  How many?  Billions.  Holy shit, you've got a fast computer.  Billions.  Okay.  So we end up.  Now this is just a little machine here.  So this is not going to be as fast as a dedicated GPU in a big machine.  But what we're doing now is just feeding in hashes.  And it's going to start to warm itself up.  And oh, you know what I've got to do, actually?  Let's do this.  I've got to delete the ones I did earlier on because otherwise it goes through and it does the same ones again.  So we're going to delete the POT file down here.  Get rid of that guy.  All right, let's try that again.  Back to there. Run.  So here's the thing with hash cracking.  And now here we go with cracking hashes.  It doesn't look like really fast.  I mean, it looks really fast, but it's much, much faster than what it looks like.  So this is actually doing.  Let's just pause and get a status here.  When I press pause, it's going so fast, there's so much buffered to go to the console.  It actually takes a while.  What it's doing is it's actually calculating MD5 hashes on the fly and then comparing them to the ones in the database.  And then if it actually finds a match of that hash, then it knows what the plain text value is.  And in this case, we're ripping through and we've done this.  How many we've calculated so far.  We've recovered 6,900 of those hashes already, which is kind of nice.  It normally runs in this machine.  It does in the order of, I think I saw about 18 million per second on my little laptop the other day.  But to the question about how fast could we do it on other hardware, when we look at hash cat, and this is where it sort of gets really interesting.  Let's move to there and we go and we look at a standard machine.  So what they do is they say, here are some examples.  So a machine running an AMD HD 7970, which is a fast GPU or was a fast GPU.  It's about five or six years old now.  You would buy it, I guess in US dollar terms for about $300 at the time.  A GPU of that class can crack MD five hashes that fast, eight and a half billion a second.  So not million.  It can calculate that many hashes per second, which is just massive.  And that's like the old hardware, right?  Like we've now had Moore's law and things have progressed and things have got faster.  But that's how fast it was going.  Now, the curious thing about this as well is that that is just if you have one.  So there's a company called Strixia Group.  Let's run by a friend of mine who create devices that look like this.  And what they do is they put eight of those GPUs in one rack.  So now we're like what 64 billion hashes a second.  And then they have lots of racks.  And the whole thing gets parallelized to the point where they can crack all of this sort of stuff enormously quickly.  So the main lesson out of this is that you got to go and have a look at something like the OWASP password cheat sheet.  Where they talk about using a password hashing algorithm where you can have a work factor.  So something like Bcrypt where you can say, I would like my GPU or CPU, depending on where it's being calculated,  to work this hard or that hard or that hard or however hard it needs to work such that you can't calculate billions a second,  but that your application doesn't run terribly when you get 10 people trying to log on at once.  So you need one of these adaptive algorithms that actually makes it slower.  And that's what Patrion who I showed you before did.  So Patrion had Bcrypt and they had a work factor 12,  which would have made it really, really hard to crack just about anything other than terrible passwords.  So good news there on the hash cracking front.  Let's try something else.  We might try talking about DDoS for a second,  because DDoS comes up a lot, distributed denial of service attacks.  Last week, anonymous, anonymous DDoS Nissan.  Did anyone see this?  Why would anonymous DDoS Nissan?  I'll give you a hint. It has to do with whales.  That seems fair, right?  Like Japan kills whales, therefore anonymous will attack a car company.  DDoS is basically just a kid throwing their toys.  You know, they have a tantrum, it gets over, people move on, it does no long lasting damage.  But that's effectively what it is.  Now the interesting thing with DDoS is that you can go to this link, map.ipviking.com.  You fire that up and you put it in full screen because it looks really awesome in full screen.  Usually. There we go.  So this starts to fire up, we should see a map appear in a moment as well.  And it's showing us real time DDoS attacks.  And it's kind of cool, like it's kind of mesmerizing.  You get to see things like the origin, the types, the targets.  Can you see that there's usually a bit of a pattern?  For some reason the traffic generally tends to move from the east to the west.  I don't know why that is.  We see the same country sort of featuring a lot.  So we see a lot of these DDoS attacks and it's interesting to look at things like the attack types as well.  So some of them are running over Telnet, other ones are running over UDP.  Sometimes they run over NTP, the network time protocol.  So these attacks exploiting different protocols in order to try and send as many malformed packets as possible.  Yeah.  That's a good question. How does it distinguish DDoS traffic?  Does anyone know?  Can you tell me if you figure it out?  I honestly don't know. I don't know how these guys actually do their measurements.  I just know it's mesmerizing.  They do have a bunch of other info on there.  But it's kind of cool to sort of see how often this data is flowing around.  And every now and then you just see, particularly out of China,  you would just see like a massive whack of traffic go west over to the US.  So DDoS is a real problem.  And it is something that keeps occurring a lot and we particularly see it continually occur with kids.  Yep. Question?  How do they know if an attack is originally distributed?  If it's distributed, well a lot of it originates from the one country still.  So let's have a look at what else we got here.  Oh, that's my wife.  That's what happens when you leave your Facebook notifications on.  I'm not sure exactly how they do their measurements.  There are a couple of other services that do same things.  I mean, you could obviously do it at the switch level at large ISPs within different countries.  I guess they've got to identify also that the traffic is malicious.  You know, some of these are done over HTTP or UDP,  where we have a lot of traffic flowing backwards and forwards anyway.  Talk a little bit more about DDoS.  And grab a couple of things here. So one of the things that we have often seen in the past with DDoS is stuff like this.  All right. Everyone seen this before?  So we'll just see all of these tweets.  Fire up your lasers. Point your lasers at whatever the hell they want to point them at today.  We saw stuff like this happen against PayPal.  So PayPal stopped taking payments for WikiLeaks around about 2011.  And all the kids got on the Twitter and said,  okay, what you got to do is you got to point Loic over there.  Anyone seen Loic before?  A few people?  Free software. You plug in a URL and then you say target.  And it just throws random packets at it.  Now think again about the type of kids that I spoke about in the last talk.  Like they've got no idea of the ramifications of what it is they're doing.  All they know is that somebody on the internet said, point your lasers at this address.  And if you get enough kids around the world doing this at the same time, they get to take stuff down.  We saw this sort of attack happen against Steam over Christmas.  Not necessarily with Loic. I think they were using a different tool.  But Steam got DDoS over the Christmas period because kids seem to like taking down gaming services over Christmas.  They're just nasty.  A year before they were taking down PlayStation Network.  And the interesting thing is that when they were attacking Steam,  Steam then put on a bunch of other services to try and cope with the extra load.  They put on a bunch of other caching engines.  And when they put on those caching engines, they also screwed up their session association with the client.  So what was happening was that you would go to Steam on the website and you go,  that's just interesting. That's someone else's private details.  Because they cached the identities, they tried to remove the load from the back end.  They implemented more caching, but they effectively lost the affinity between the client and the session.  So I suspect part of that was just sort of responding under duress as well,  which made life very hard for them.  All right, so often DDoS is very simple. It is just basically this.  Another one that we keep coming back to, and we spoke about this just before, was SQL injection.  And I showed you SQL map and someone asked, you know, look, is it basically just put the URL in?  These tools are really, really simple and they're really readily available.  And I'll give you an example here.  So we will go to this site here.  Now I use this for a lot of my demos.  And I use it in a lot of my workshops.  And it has a bunch of different SQL injection risks on it.  It's basically a website where you can log on and you can vote for cars that you like.  And then there's a leaderboard.  It's deliberately vulnerable. There's lots and lots of vulnerabilities on this site.  Anyone's welcome to go and play around with them.  You can go and exploit SQL injection on here and not go to jail, which is really good.  What you can do is say something like, okay, I want to view the Lamborghinis and I'm going to take this URL.  Now let's make this a bit more interactive.  So who has actually done SQL injection it takes before?  Okay, some of you, some of you, you haven't.  You want to come do one?  Yeah, let's try.  Because then if it's you and not me, I'm okay.  You'll go to jail.  All right, so here's what we're going to do.  I'm just going to open up a tool called Havage.  Now some of you may have seen this before, but I want to make the point of how easy it is.  What's your name first?  Pauvel.  Pauvel, I'm trying.  How am I?  Pauvel, okay, Pauvel.  So here's what you're going to do.  You're going to be the hacker.  And what you've got to do is you've got to paste the URL on the clipboard into that target field.  Yeah, you paste it over the other one.  Very good.  Hacking is hard.  Look at that.  All right.  Now you click the analyze button.  So what it's doing is it's just making HTTP requests, right?  This is not going direct to the database or anything like that.  It's just making requests and trying to cause internal exceptions that disclose the structure of the database.  And what it's actually done now on the bottom line is it says the DB name is hack yourself first underscore DB.  So it's already found the name of the internal database.  Now what you do is you go up and you click on the tables button because what you want to try and get is a list of the tables.  And then you click on get tables.  There we go.  And it goes away.  Here we go.  Now remember while we're doing this, and I'm not saying that Pavel is like a 15 year old kid, right?  But this is what 15 year old kids do.  They can copy and paste URLs.  Now which table should we get, Pavel?  Well, I reckon that's kind of public.  Let's get user profile.  So you just click the check box next to user profile.  That's about the hardest thing of SQL injection, like knowing which box to check.  All right, let's get the columns.  So it goes away and it's going to think because we want to wait until it finds all the columns.  And again, all it's doing here, now let's wait till it finds them all before we do anything more.  It's just making HTTP requests and it's causing exceptions in the database which bubble up to the user interface.  Now if you were a hacker, what data would you get out of user profile?  Oh, you're good at this.  Yeah, very good.  All right, let's get the data.  There we go.  That's SQL injection.  Well done, Pavel. Good one.  All right, so this is kind of the point, right?  Like it is really, really easy to mount a SQL injection attack.  And what we're seeing these kids doing is they're using these tools.  And to be honest, like Havage is a bit of a, we'd say a Mickey Mouse tool, right?  Like it's very, very basic.  It's a nice little gooey interface.  The hardcore guys are going to use something like SQL injection.  Sorry, they're going to use something like SQL map.  SQL map is much more effective.  But the interesting thing as well is how people are finding sites to hack.  And I'll show you because it's actually really, really easy.  What they're doing most of the time is they're jumping into something like a Google search  and they're saying let's do a search for in URL.  And then they'll say, okay, in URL what I want is question mark ID equals.  And then they might narrow it down a bit and they'll say, well, you know,  what I really don't like is I don't like, I don't like Swedish sites.  We still don't like Sweden here, right?  Yeah, very good.  Okay, I don't like Swedish sites.  And then they would get a list of sites in Sweden which they don't like,  which should have an ID equals somewhere in the query string.  But actually how we might do this, we'll sort of narrow it down a little bit  and we'll say.asp, get like classic asp.  All right, because if it's classic asp,  we know their chances of having good SQL injection defenses are going to be much lower.  And then inevitably what you get is a list of URLs and you get IDs in the end,  which are integers, and almost certainly if you pick a bunch of those  and you put a non-integer character after the integer, you'll see an internal exception.  Because what they're doing is they're just passing this untrusted data into the database  and saying just run this, it's just part of a script.  So for something like one of these, it's going to be select star from widgets  where widget ID equals whatever the user gives us.  If it's a one or two or three, it's fine.  If it's a three X, the database is going to say it is not a valid integer type.  There's a cast exception and that's that.  So that's how SQL injection works.  You may have also noticed that I have SQL injection on my t-shirt to Bobby Tables.  So SQL injection is just a ridiculously easy attack vector.  While we're here doing Google searches as well,  there's other stuff that you can find via Google because there's just so much stuff that is openly searchable.  So I like this one.  There's one you can do which is in URL, FTP.  So Google will index things over FTP.  And then you can go down and say, well, let's get web.config files.  Who knows what a web.config is?  In an ASP.NET application, the web.config is where you have the connection strings,  the machine key, which is effectively your private encryption key,  your API keys in your settings, a whole bunch of really, really good juicy stuff.  So you go and you run that and then you find all of these sites that have got exposed web.config.  Now, what this means is that there is open FTP to these websites.  Google can read from them because they allow anonymous access.  So not only can you go and get FTP or you can go and get web.config,  you can probably go and get anything from any of these sites.  Not only can you get stuff, but if they've left anonymous FTP enabled in read access,  they've probably also left it in write access.  So you can write to these.  And when you scroll down through these, you sort of get a sense of the diversity  of just how much stuff is there. .gov.  Washington State Department of Transport.  I know that's what it is because this has been here for years.  They still haven't fixed it. It's still open.  There was a time when I emailed a bunch of sites and I said, hey,  you might be interested to know that your FTP is open and anyone can access your stuff.  And no one replied.  So fair enough.  So that is curious.  But of course, once you can start running these Google Docs,  and this is what I meant earlier on.  I said Google Doc, like a carefully crafted Google search.  And just in case you really, really want to run other Google Docs,  you go to exploit DB Google hacking database, which is there.  And you can get a list of Google Docs to run.  You can get different types of Google Docs.  So maybe you would like to do a search for files containing juicy info.  I wonder what's on. I've actually never looked in there.  Let's see what's in there.  This may not be public forum suitable stuff. Who knows?  Okay. So what do we got in here?  We've got things like stats generated by we've got Apache server status.  So we're probably going to get some logs and things.  PDFs with tax returns in them.  What's in that one?  Then you can run the Google Doc.  And then we don't click on any of the links.  But you get the idea, right?  A lot of it is just index it's public.  Looks like some of these are served over FTP as well.  Inevitably, some of these are going to have some pretty sensitive personal info in them.  We can learn other things by modifying our Google Docs just slightly.  So again, this one which search for web.config.  Web.config have connection strings in them.  Connection strings connect to databases with accounts.  Sometimes they connect with very privileged accounts.  Anyone know what the SA account is?  Right. So the admin. This is the God writes account.  If you can connect to a database with SA, you can not only access everything in the database,  you can access everything in every other database.  You can execute any other commands on the host SQL version.  So you can restart it.  You can probably execute XP command shell which allows you to execute commands on the host operating system.  And if you can't, you can enable XP command shell by hitting another command.  If we find results here, then they're extra bad.  Here's what I really like about these results.  Password.  Now, your passwords should have a combination of letters and numbers.  Like that.  Not like that. Don't do that.  And don't use SA.  Why do you think people do this?  It's very easy.  I'll tell you, this makes setting permissions really easy.  Because it can just do everything.  You don't have to worry about going to every table and setting data reader or data writer or any of that sort of stuff.  It's like magic just happens.  Makes life very, very simple.  So that one's kind of curious.  Let me show you something else.  And I'm going to open my password manager for a second.  Who uses a password manager?  Who uses one password?  Who uses last pass?  Any others?  Keep pass?  Okay.  Use a password manager.  Whatever it is.  I like one password for various reasons.  But frankly, if you're using a password manager, you are so far ahead of everyone else anyway.  All right.  So what I'm going to do here is I want to just have a quick browse through one of these underground sites.  And I'm going to start up my tour browser.  Because one of the things I think people find very curious is the fact that we do have a lot of information for sale on the web.  And what I want to do is I want to jump into Alpha Bay.  Normally I don't do this in like really public talks.  But this one is not so public.  It's just us being recorded.  All right.  So everyone remember the Silk Road?  Silk Road was a really large underground drug site run by a guy that went under the chute and named Dread Pirate Roberts.  Dread Pirate Roberts was actually a guy called Ross Ulbricht.  Ross Ulbricht eventually got caught.  And one of the reasons he got caught is because he made a Stack Overflow post.  I'll show you what it was.  I was in this talk here.  And this is kind of funny, right?  Because he got this guy running this underground drug market.  And basically he was asking questions on Stack Overflow related to running his underground drug market.  This is the question he asked. This is one of the things that brought him undone.  He originally created the profile using an email address that identified him personally.  It's one of the ways he got caught.  Anyway, Silk Road got taken offline.  Of course we've seen other things pop up in its place.  Stuff like Alpha Bay.  I want to show you what Alpha Bay looks like.  7mp.  I'm going to do that.  I then have a really, really random username and password.  I don't know why I chose Google Google.  I think I just fat fingered it.  So we do that.  Because we're going to have a look at what these guys are actually selling.  No idea how this will turn out.  And they really like captures, don't they?  This is the second one. 9b.  Now for those of you who haven't used Tor, it's very easy to get the Tor web browser.  You just download it. Google Tor web browser.  It does have very legitimate purposes as well.  It's a good way of having anonymity.  And then inevitably when you have the Tor browser, you can go to these onion websites.  So this is running on a server somewhere which we are accessing by going through multiple different Tor relay points.  So our traffic is sort of getting bounced around the world such that they don't know who I am and I don't know who they are.  Now there have been exploits against Tor.  So we saw quite a bit of news a few months ago where Carnegie Mellon University apparently had demonstrated that if you have enough Tor exit nodes that you run,  you can start to de-anonymise traffic because you can start to see where the traffic goes.  But I wanted to show how easy it is to get in here and find things of this class.  Drugs and chemicals, weapons, going to stuff like fraud.  Have a look at what we get in fraud.  Dumps. Would you like to buy some dumps?  US dumps. What do you want in here?  You want to buy a Skype man Spotify account? Would you like to buy Spotify accounts?  As seen on Krebs and security, he is using Brian Krebs in order to promote his stolen Spotify accounts.  Two bucks. I assume that they are probably about two bucks each.  The curious thing about this, this is sort of what I was touching on in my previous talk.  This is a marketplace that does not look dissimilar to many of the other marketplaces you see online, legitimate marketplaces.  We have a seller, you will see that we have things like the vendor level, we have a trust level in here as well.  Everything is nice to categorise, good description of it here.  They have a whole lot of guidance in here about how to go and use Bitcoin to buy these things in a manner that makes it difficult to trace you.  This is how easy it is, it is just a marketplace, you browse around and you buy these things.  You can be buying drugs and weapons the same way.  Mind you, you have to get them delivered, which is a lot harder than actually getting Spotify accounts delivered.  So that is that one, I find that a really sort of curious thing about just how easily accessible this is.  It also helps explain why data bridges are valuable, because you can go and sell them.  People want to break into systems, your systems, because they can turn around and put them on the market.  It is that easy.  Okay, something a little bit different as we start to wrap up, one of the interesting things that I have found lately is IoT.  So we have all seen a lot of IoT connected things, right?  And we are starting to see vulnerabilities in IoT connected things.  And actually, you know what, let's start with VTech. We will go back to VTech again.  I talked about VTech and they inevitably had vulnerabilities in the APIs behind their IoT things, their tablets.  And this was actually some of the data they had taken out.  I never got given the photos, which I am quite happy about.  But these are the photos of kids and sometimes with their parents that got leaked.  Now curiously, so this was VTech, all this data got leaked out in October, November timeframe,  because they had things like no transport layer security and they had enumeration risks and SQL injection risks.  But the good news is that VTech is now moving on and they are building home security systems.  Holy shit. This is at CES.  The reporter I worked with on the VTech data breach took a photo of this and sent it to me.  He thought I might find it amusing.  I certainly did think some things when I saw this.  Probably don't buy these ones.  I got to feel a little bit sorry actually for these guys because they would have had this stuff being built well in advance of the VTech data breach.  And inevitably they are totally different teams, totally different places, totally different approaches to security.  But I feel sorry for the people working on these products because they must have seen how bad that VTech data breach was and just gone,  oh crap.  Now we got to try and sell home security products.  Anyway, brings me to things like this.  Now some of the interesting IOT stuff that we are seeing pop up lately, some of it is just kind of ridiculous.  I don't think this is ridiculous, but I am going to give you some ridiculous examples in a moment too.  So this is LFX and this is made by an Aussie company and they are connected light bulbs.  And they are really, really cool and I like the idea of having an app where I can sort of change the colour of the bulbs and the brightness and everything.  I don't want to have to get off the couch to do stuff.  This is our lazy lifestyle today.  But anyway, LFX had a vulnerability in the light bulbs.  And I know it is a vulnerability in the light bulbs.  But the interesting thing about it though is a lot of people say with the IOT emergence if you like, is they say, look in a case like this,  alright, if there is a vulnerability in the light bulbs, the attackers may be able to control the light bulbs, do I really care?  Like how much of a threat do I think it is if the attackers can put my house into disco mode?  Make lights flash.  But the vulnerability that they had leaked the network credentials.  Right, so now the IOT thing is the attack vector into the network.  And I am much more worried about someone having access to my network than what I am about them being able to change the colour of my light bulbs.  So LFX came out and they said, yes we had a vulnerability, please patch your light bulbs.  How the hell did you patch your light bulbs?  I assume you do it with the companion app or something like that.  But I guess the curious thing is, are we ready to sort of accept that you have to be able to patch your light bulbs?  They also said, don't worry, we are not aware of anyone having been compromised by their light bulbs.  Which to me sounds really odd because think about the attack, right?  The attack is they get access to the network.  If you find that someone is in your network, are you ready to blame the light bulbs?  Probably not.  Now as weird as this is, and again I would actually like these, they are kind of cool.  I have seen two other devices in recent times suffer a similar attack.  One is the eye kettle.  There is an eye kettle.  And the idea is that you can be laying in bed and you can turn your kettle on.  Now think about this for a moment because this is pointless, right?  What do you do once the kettle boils which takes about two minutes?  It doesn't bring the water to you or bring the, you still got to get your ass out of bed and go to the kettle.  But the vulnerability with the kettle was they found that you could de-auth the kettle from the wireless network.  You could trick the kettle into connecting to your own network and then you could tell net into the kettle with the default pin.  Tell net into the kettle.  So now you are tell netted into the kettle using the default pin and then you can get the Wi-Fi credentials out for the network.  Same problem.  So that was the second one I saw and then just the other day when we had CES on, there was a doorbell that had the same problem.  A fucking doorbell that connected to the web and the doorbell was disclosing the credentials of the network.  And all of this stuff is crazy.  But none of it is as crazy as this.  Have you seen this? Anyone got one of this?  You wouldn't say yes if you did would you?  So this is a licksil satis and this is real.  It's a Japanese toilet.  If you've been to Japan you'll know how crazy they are about their toilets.  They're all like rocket ships.  And this is the companion app.  And these are real screenshots.  I didn't fabricate these.  You can find them on the internet.  And you look at them and you try to figure out what's happening.  Like take this middle one.  It's in Japanese.  I don't know if anyone here speaks Japanese and can tell me.  But what do you reckon is happening in the middle screen?  Looks like a calendar.  Like event driven data.  Some kind.  I don't know what.  And I love the one in the front too.  It looks like it's a music player.  I did not fabricate this.  The toilet is playing.  I can't get no satisfaction.  And I saw this a couple of years ago and I used it in a talk.  And I said we are now approaching the era where we have to be aware of vulnerabilities in our toilet.  And eventually they had one.  Here's the advisory.  This is terrifying.  Can you imagine this?  I showed this at a talk once and someone said yes this is known as a back door attack.  On that note, I think this is a really terrifying thing is a good place to end.  Let me see if anyone has any questions about what I've just covered.  Or are we all just in shock about the fact that this could happen?  Any questions, folks?  All right, well hey, if you think of anything, put it into the Slido app and we'll be able to cover it later on.  I think we get, what about another 15 minute break, Jacob?  And then someone else can do some talking.  Thanks, guys.  Thank you.
Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_0_851.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_852_1883.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_1884_2135.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_2136_3383.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_3384_3635.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_3636_5567.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_5568_6515.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_6516_6803.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_6804_7619.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_7620_8555.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_8556_10451.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_10452_11111.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_11112_12515.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_12516_13559.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_13560_13691.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_13692_13823.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_13824_14639.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_14640_18095.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_18096_18587.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_18588_18671.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_18672_19211.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_19212_20135.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_20136_21083.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_21084_23807.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_23808_24407.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_24408_28355.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_28356_28907.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_28908_28955.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_28956_29051.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_29052_30083.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_30084_34763.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_34764_35363.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_35364_35627.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_35628_37019.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_37020_43439.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_43440_47327.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_47328_59639.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_59640_59987.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_59988_60059.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_60060_64403.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_64404_64727.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_64728_65123.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_65124_68375.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_68376_68495.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_68496_76775.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_76776_79475.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_79476_79535.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_79536_79595.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_79596_79643.png Web_Security_Essentials_by_Example_-_Troy_Hunt_-_Security_Day_2016_79644_79716.png
I'm not responsible for anything you do with the information I've provided in this video for you. So if you're going to do that with this information which I've given you, I'm not responsible for anything you do with the information I've provided in this video. So yeah now that I've got that out of the way let's get started. So what we've got to do is we've got a loadup command prompt. I like my color green. Then what we want to do is we want to type ping and then I've got a bunch of random IPs here. So ping and then just paste it out or you can type out hyphen t hyphen out and then the amount of packets. So this is the command it pings them and this is the IP it will ping. This is how long you want it to do it for. So I've put a limited timer. This is how many packets you want to send right here. So let's just hit that and as you can see it's already began the process of DDoSing the IP. Now there's one thing I'd just like to say like when you do this sometimes it will come up with like a timeout message. This means that the IP could be wrong or in fact your connection is not strong enough to send packets or could just be a general error because it could do all of this and then just say timeout and then carry on. So it could just be like the pings that I actually sent. So once you're done you hit control C and sent 43 packets. They received 43 packets. They lost nothing on their computer so it's a 0% loss. So basically they must have a strong connection. You've got to do this for a while with this method. So go outside and play while you DDoS and then mustn't. I don't know. But yeah. How do you like that? That's awesome isn't it? Did you know you could do that? I like the bit where he says just go outside and play while you DDoSing them. It gives you a bit of a sense of how sophisticated our adversaries are. So yeah often this is kids right? And we spoke a little bit about kids in the last talk. And recently we saw this as well. So we had the Paris attacks and Anonymous says we're going to declare war on ISIS. We're going to take down ISIS. And this was posted on Facebook. And I saw the most epic comment ever left about Anonymous coming after ISIS. All right. So here's how this session is going to work. I'm going to just show lots of different things that are not in any one deck or any one process. I'm going to sort of pick things that have been showing recently that I think are interesting. And we're going to do a lot of hands on stuff as well. So it's meant to be sort of very practical. And basically I'm just going to keep going until I run out of time. And then we have to have a break. So I want to show you a few different things around security. I want to try and make it pretty practical as well. And one thing I thought we might start with is we talk a lot about HTTPS and how do we do HTTPS right? And this is the thing with HTTPS. It's not like do you have it or do you not have it? There are lots of different levels of getting it right. Lots of different levels of screwing it up. And I want to give you an example. Here's one that really, really bugs me. And it's from an Aussie site. I'm going to start by insulting the Aussies. So when I go to Qantas, we get this nice scene. But when I go to Qantas over HTTPS, watch what happens up in the address bar. You got to watch it carefully. Let's try reloading that. Watch it this time. You see what happened? I'll show you again. Just watch carefully right here. It goes green and it's like there's hope. It's secure. And then you think they take it away. It disappears again straight away. So anyone know what this happens? Yes. Oh, no, not you. Anyone else? Anyone who's not an owl? So what's happening here is explained when you click on here, it goes you've loaded this page securely, but there are other resources which are not secure. Now this is really basic, right? Like you should put secure things on a secure page. But what they're doing is they're loading the page over HTTPS. So you can trust the page. No one has been able to view the page in transit. No one has been able to modify the page in transit. But then something else is happening which is making it insecure. There's another insecure resource being put on the page. Now there's something else kind of cool you can do as of the last day, which is that if you have the latest and greatest version of Chrome, you can now go in and you can go to the security tab. And in the security tab, we get a nice little report. So this security tab, go and get this, brand new. It's been in the beta for a while. Let's just hit the public airways. And we can go in here and we can see what the problem is. And we can see that there was a non-secure origin, which was quantis.com.au. And we can see that everything else here was secure. And it's kind of interesting because then when we go down and we actually have a look at the console, we can see the problem that was explained here in the console. Mixed content. The page here was loaded securely, but it requested this image insecurely. Why do you do that? You requested this image insecurely as well. So basically they've loaded this sprite in insecure fashion. This sprite has taken away their green padlock and their green HTTPS. And browsers keep evolving in the way they do this. So what Chrome used to do is you used to get like a little orange triangle up until a few months ago. And now they're going, you just don't get a padlock at all. You get nothing, which is cool. Google also wants to move Chrome to the point where rather than saying that a page, let's take my blog for a second, rather than say this page loads, I don't have HTTPS. There are other reasons for that we might get into later. And I just got a white page. They want to get to the point where there's a like a red cross. So some visual indicator which says you can't trust this. You can't trust it because it hasn't been loaded securely. And this is good, right? So you keep sort of raising the bar, forcing people to go towards HTTPS. A really good resource for this sort of stuff is SSL Labs. Who's used SSL Labs before? I don't need to show you then because that's most people. But use this in case you haven't. So this will go to a website and it will come back and it will tell you everything that is either good or bad about it. So if I take something like my Have I Been Poned address, plug it into here and run it. It'll come back and eventually it will say it's got an A grade and a Zura has done things right. And I'm just running on a Zura and it's basically a Zura's implementation of HTTPS. So this sort of stuff is good. We're kind of continually raising the bar. Now I want to show you something interesting. This is something that really drives me nuts. Let's go to somewhere English. Oh, it hasn't warned me. I wonder if it hasn't warned me because I'm here. Anyone know what I'm looking for? Let's try HSBC. Wow, no cookie warnings. Why no cookie warnings? Who's got a site that does a cookie warning? Do you guys do that here? Yeah? Do you like it? So you know what I mean. Everyone sees these cookie warnings and I look at this from Australia and I go, what are these European people so worried about? What's the problem with the cookies? And I wrote something a little while ago which was like just really bad UX patterns. So things like you go to a website and you just get a full screen banner and you have to wait for the banner to load. If ever you go to anything on Forbes, I don't know if anyone here look at Forbes, they do this. If we go somewhere like that, why are you doing this to me? I don't want to see the quote of the day. I don't want to wait and I don't want whatever the hell this is down here. I don't even know what that is. Why are you giving me ads? And then you get to continue. So I write about all these really nasty practices. But the cookie one was interesting because I said the cookies are a bad UX experience. Particularly mobile, you go there and it's like half your screen is a cookie warning and no one seems to like it. But here's the interesting thing with that because people say we have to do it because it's EU legislation and you could be tracked. If you have cookies, you could be tracked. And I sort of say, well, you can be tracked anyway because you can go somewhere like this. And you go, am I unique.org? You go to am I unique.org and you ask it to fingerprint your browser. And what it does is it goes away and it looks at various attributes of your browser and your user agent settings and it's going to come back and tell you how unique you are. So here we go down the bottom line. The interesting to see if you guys run this as well, see if you get the same results. 132,000 people have tested this and there is no one else like me. I'm an individual. I'm unique. Isn't it nice? So I don't have to send cookies back to a tracker who then track me as I move around. All you have to be able to do to track someone is get them to make an HTTP request. So if you're like double click or Google Analytics or any of these sort of things, so long as you can get the person to make a request, then you can track them. And have a look at how it does it. This many people using Chrome, wow, I'm only 0.2% of people using Chrome 48. I told you it was new. I literally updated it this morning. And okay, that is going to change and that might change your thumbprint, but you could always be smart enough to say if all the other attributes are the same and Chrome has revved one version, then you're probably the same person. It's not an exact science. Cookies aren't an exact science. People use different browsers. Well, they delete the cookies or whatever it may be. So I thought this was interesting and have a look at your results as well because you'll almost certainly find that you are one of like 130,000 plus people. So the cookie law thing is kind of pointless. And now you guys can use this as ammunition to say we shouldn't be doing it because we can track it all anyway. So that's an interesting one. Let's have a look at something really different and we might look at mobile apps. So obviously these days, these things are really popular. We've got a heap of different apps on here. And the curious thing about the apps is that many of them will talk to API backends and many of the API backends are doing really screwy things. Really screwy security things, really screwy performance things. And here's what I thought I might show you. I'm just going to pick something from one of my recent talks. And we might pick, I think, what did I do? No, I did this. I did this in NDC a while ago. Alright, so here's how this works. What you do is you get your mobile phone. And if you've got an i-thing, this is how the i-things work. You get your i-thing and you jump into, that was the very end of it. What happened there? Ah, I know why. Alright, you go into your network settings. So you go into whatever Wi-Fi network it is at the moment. You go into your HTTP proxy settings. You set your server as the IP address of your PC or your Mac or whatever device it is that you want to proxy through. And you run it over that port. And what you can then do if you're using something like Fidler is you can catch every request that the device sends through. So when I go into Fidler, normally what I'm seeing here is every request from my host. When I proxy the device, I can see every request from the device that goes through the PC. It's really cool. So you see all the same sort of traffic that you normally see if you're used to using Fidler or Charles on a Mac except you see the stuff that your mobile apps are doing. Now, what I wanted to show you is these guys here, British Airways. British Airways have an app. And what happens in the British Airways app is that if you are a member of the Silver or Gold Executive Club, you can get Wi-Fi passwords. But you've got to be a member. There's no other way to get the Wi-Fi passwords unless you know how to proxy your device. And then what you can do is you can go and load this previous archive that I created. This is what happens when British Airways loads their app. Makes three requests. One of those requests is to this path. If we copy that URL that it loads and we jump over into a browser somewhere, that one will do, there's your Wi-Fi passwords. Right? So what happens is it loads the Wi-Fi passwords before you authenticate. And then they're all just sitting there on the device and their security is that they basically just make the Wi-Fi passwords visible. That's how it works. That's the entire mechanism of authentication, which is kind of scurry. So all of that's already there on the device. Now, that one's bad. I'll show you another one that's even worse. What tends to happen is developers make this assumption that because they have built the APIs and they've built the apps, that that's the way they'll always talk together. You know, they own the ecosystem, but what they miss is that anyone who sits in the middle can actually see the traffic. They can see everything that goes backwards and forwards. And I want to give you an example because I checked a... Oh, that's talking to me. I checked a mobile app recently. And the mobile app I checked is one called Evo Magazine. It's a car magazine. It looks like this. This is the mobile app. And you go to the app store and you download it, and it's a 25-megabyte app. And then after you download it, you can sort of browse through all the editions, which you can see here, all the editions of the magazine. And then if you want to buy one, you click on it and you enter some payment details and then you get access to it. 25 megabytes to download. How much data do you reckon it downloads when you first open it? Who wants to take a guess? I'll take any guess. Any guess that's not Nile. It is actually about two gigs. It's pretty close. So this is the trace just here. And if we select it all and we go to our statistics, what we can see is it actually downloads about 1.8 gigabytes with the zip files. Why does it do this? Because when you go and you actually have a look at the body size, and we go down to the biggest ones, it downloads all of these 75 megabytes or so editions of the magazine. And if we go and pick one that's a little bit smaller, what you'll see is that we can still just jump over to the browser and download it. It's thinking, ooh, you could download it yesterday. That is curious. Let's try another one. Maybe that edition's been removed. But the point here, regardless of whether it actually loads or not, and it does load this one, is that all the editions are already on the device. So, okay, A, from a performance perspective, maybe not so good, because you've just chewed up a couple of gigabytes of my bandwidth. But B, you don't need to authenticate. There's a public URL. Any of you can go there right now and get that edition of the magazine. If you're a little bit good with HTML and JavaScript and CSS, you can recreate the magazine on your own website. You can download it from Evo. So this is what they do. And my assumption is that they're doing it because it's a really nice sort of performance behavior. It's like you buy the magazine, and magically it's just there. You know, you've just downloaded a 75-megabyte magazine like that because it's already on the device, right? You never actually have to authenticate to the service to download it. So do this with your devices. You go home, I know it sounds kind of geeky, but it's kind of cool. You go home and you proxy it and you just see all the stuff it does and you see this kind of stuff. Someone recently said, take a look at the FoxTel app. So FoxTel gives us cable television in Australia. And they have an electronic programming guide, and you have all the little icons of the channels, you know, a little Discovery icon, a little Disney icon, and they're tiny. But when they're downloaded to the iPad, they're massive. They're 3,000 pixels square. And I showed this in a talk once, and a guy came up to me afterwards and he said, I know why that happens. I worked on that app. He said, this is the way the designers gave them to us. Not a security thing, but an interesting little sort of performance issue there. So that one is problematic. I'll do something else. Let's have a bit of a look at passwords. And I've got a little video here to show you for passwords. And then we might do a quick bit of password cracking as well. So recently, there's a really good example here from Jimmy Kimmel. And what he did is he went out onto the streets and he asked people about how they store their passwords, or rather how they create their passwords. Check this out. We're talking about cybersecurity today and how safe people's passwords are. What is one of your online passwords currently? It is my dog's name, and the year I graduated from high school. What kind of dog do you have? I have a chivalry of Papillon. And what's its name? Jamison. Jamison. And where did you go to school? I went to school back in Greensburg, Pennsylvania. What school? Hempfield area senior high school. Oh, when did you graduate? In 2009. Oh, great. Getting passwords is easy. You don't actually have to crack them. It's like you just ask, what was your password? But this is actually interesting too, because it's a good sort of social engineering example where the reporter is, she's not coming on too heavy, right? Like she doesn't just say, give me your password. She says, how do you create your password? That's the dog's name in the year I graduated. And then she starts this dialogue, right? So it starts having this conversation. What kind of dog do you have? And anyone who has a dog wants to talk about their dog, right? They're going to cough up the information. And she kind of leads the person down this road to the point where she gets the answer out of them. So it's really interesting to remember that even when we do our best with the security, physical, digital security of our systems, the security of our humans is still really crap, right? Like they still succumb to these things. But let's actually take a look at some password cracking just very quickly to put it into context for anyone who hasn't seen how this works. What I'm going to do is take an example here, which is what I did in my workshop the other day. So I showed you Stratfor before, and Stratfor had all of these passwords. And all of these passwords were stored as MD5. So you know how we did a search and we found that it was Stratfor and we found 12,000 people or something used them. Now, what we're going to do is actually jump into Hashcat. Who's used Hashcat before? There are a few people. Excellent. So this won't be new for some of you, but for the vast majority of you, you weren't seen this before. So I'm going to look at CUDA Hashcat. So CUDA is going to run in my Nvidia graphics card. And in here I have Stratfor hashes. And these are all the hashes from that Stratfor data breach. There's about 860,000 or something in there. And what I'm going to do now is I'm going to take one of these commands, which is going to target Stratfor hashes. In fact, I think I'm going to do this one. And what we're going to do with this command is it's going to take those Stratfor hashes. And it's going to recalculate hashes that are passwords anywhere between 6 and 10 characters, lowercase, uppercase, decimal. And it's just going to sort of create these hashes on the fly in the GPU. And we're going to see how many of them actually get cracked. And the interesting thing here is just how fast it goes. And normally I sort of say to people, how fast do you think we can crack hashes in a GPU? So for someone who has not worked in HashCat before and knows the answer, what do we reckon? How fast might we create hashes in a GPU? Who wants to guess? MD5. Someone who doesn't know the answer because otherwise it kind of messes it up. Two million a second. Any other guesses? How many? Billions. Holy shit, you've got a fast computer. Billions. Okay. So we end up. Now this is just a little machine here. So this is not going to be as fast as a dedicated GPU in a big machine. But what we're doing now is just feeding in hashes. And it's going to start to warm itself up. And oh, you know what I've got to do, actually? Let's do this. I've got to delete the ones I did earlier on because otherwise it goes through and it does the same ones again. So we're going to delete the POT file down here. Get rid of that guy. All right, let's try that again. Back to there. Run. So here's the thing with hash cracking. And now here we go with cracking hashes. It doesn't look like really fast. I mean, it looks really fast, but it's much, much faster than what it looks like. So this is actually doing. Let's just pause and get a status here. When I press pause, it's going so fast, there's so much buffered to go to the console. It actually takes a while. What it's doing is it's actually calculating MD5 hashes on the fly and then comparing them to the ones in the database. And then if it actually finds a match of that hash, then it knows what the plain text value is. And in this case, we're ripping through and we've done this. How many we've calculated so far. We've recovered 6,900 of those hashes already, which is kind of nice. It normally runs in this machine. It does in the order of, I think I saw about 18 million per second on my little laptop the other day. But to the question about how fast could we do it on other hardware, when we look at hash cat, and this is where it sort of gets really interesting. Let's move to there and we go and we look at a standard machine. So what they do is they say, here are some examples. So a machine running an AMD HD 7970, which is a fast GPU or was a fast GPU. It's about five or six years old now. You would buy it, I guess in US dollar terms for about $300 at the time. A GPU of that class can crack MD five hashes that fast, eight and a half billion a second. So not million. It can calculate that many hashes per second, which is just massive. And that's like the old hardware, right? Like we've now had Moore's law and things have progressed and things have got faster. But that's how fast it was going. Now, the curious thing about this as well is that that is just if you have one. So there's a company called Strixia Group. Let's run by a friend of mine who create devices that look like this. And what they do is they put eight of those GPUs in one rack. So now we're like what 64 billion hashes a second. And then they have lots of racks. And the whole thing gets parallelized to the point where they can crack all of this sort of stuff enormously quickly. So the main lesson out of this is that you got to go and have a look at something like the OWASP password cheat sheet. Where they talk about using a password hashing algorithm where you can have a work factor. So something like Bcrypt where you can say, I would like my GPU or CPU, depending on where it's being calculated, to work this hard or that hard or that hard or however hard it needs to work such that you can't calculate billions a second, but that your application doesn't run terribly when you get 10 people trying to log on at once. So you need one of these adaptive algorithms that actually makes it slower. And that's what Patrion who I showed you before did. So Patrion had Bcrypt and they had a work factor 12, which would have made it really, really hard to crack just about anything other than terrible passwords. So good news there on the hash cracking front. Let's try something else. We might try talking about DDoS for a second, because DDoS comes up a lot, distributed denial of service attacks. Last week, anonymous, anonymous DDoS Nissan. Did anyone see this? Why would anonymous DDoS Nissan? I'll give you a hint. It has to do with whales. That seems fair, right? Like Japan kills whales, therefore anonymous will attack a car company. DDoS is basically just a kid throwing their toys. You know, they have a tantrum, it gets over, people move on, it does no long lasting damage. But that's effectively what it is. Now the interesting thing with DDoS is that you can go to this link, map.ipviking.com. You fire that up and you put it in full screen because it looks really awesome in full screen. Usually. There we go. So this starts to fire up, we should see a map appear in a moment as well. And it's showing us real time DDoS attacks. And it's kind of cool, like it's kind of mesmerizing. You get to see things like the origin, the types, the targets. Can you see that there's usually a bit of a pattern? For some reason the traffic generally tends to move from the east to the west. I don't know why that is. We see the same country sort of featuring a lot. So we see a lot of these DDoS attacks and it's interesting to look at things like the attack types as well. So some of them are running over Telnet, other ones are running over UDP. Sometimes they run over NTP, the network time protocol. So these attacks exploiting different protocols in order to try and send as many malformed packets as possible. Yeah. That's a good question. How does it distinguish DDoS traffic? Does anyone know? Can you tell me if you figure it out? I honestly don't know. I don't know how these guys actually do their measurements. I just know it's mesmerizing. They do have a bunch of other info on there. But it's kind of cool to sort of see how often this data is flowing around. And every now and then you just see, particularly out of China, you would just see like a massive whack of traffic go west over to the US. So DDoS is a real problem. And it is something that keeps occurring a lot and we particularly see it continually occur with kids. Yep. Question? How do they know if an attack is originally distributed? If it's distributed, well a lot of it originates from the one country still. So let's have a look at what else we got here. Oh, that's my wife. That's what happens when you leave your Facebook notifications on. I'm not sure exactly how they do their measurements. There are a couple of other services that do same things. I mean, you could obviously do it at the switch level at large ISPs within different countries. I guess they've got to identify also that the traffic is malicious. You know, some of these are done over HTTP or UDP, where we have a lot of traffic flowing backwards and forwards anyway. Talk a little bit more about DDoS. And grab a couple of things here. So one of the things that we have often seen in the past with DDoS is stuff like this. All right. Everyone seen this before? So we'll just see all of these tweets. Fire up your lasers. Point your lasers at whatever the hell they want to point them at today. We saw stuff like this happen against PayPal. So PayPal stopped taking payments for WikiLeaks around about 2011. And all the kids got on the Twitter and said, okay, what you got to do is you got to point Loic over there. Anyone seen Loic before? A few people? Free software. You plug in a URL and then you say target. And it just throws random packets at it. Now think again about the type of kids that I spoke about in the last talk. Like they've got no idea of the ramifications of what it is they're doing. All they know is that somebody on the internet said, point your lasers at this address. And if you get enough kids around the world doing this at the same time, they get to take stuff down. We saw this sort of attack happen against Steam over Christmas. Not necessarily with Loic. I think they were using a different tool. But Steam got DDoS over the Christmas period because kids seem to like taking down gaming services over Christmas. They're just nasty. A year before they were taking down PlayStation Network. And the interesting thing is that when they were attacking Steam, Steam then put on a bunch of other services to try and cope with the extra load. They put on a bunch of other caching engines. And when they put on those caching engines, they also screwed up their session association with the client. So what was happening was that you would go to Steam on the website and you go, that's just interesting. That's someone else's private details. Because they cached the identities, they tried to remove the load from the back end. They implemented more caching, but they effectively lost the affinity between the client and the session. So I suspect part of that was just sort of responding under duress as well, which made life very hard for them. All right, so often DDoS is very simple. It is just basically this. Another one that we keep coming back to, and we spoke about this just before, was SQL injection. And I showed you SQL map and someone asked, you know, look, is it basically just put the URL in? These tools are really, really simple and they're really readily available. And I'll give you an example here. So we will go to this site here. Now I use this for a lot of my demos. And I use it in a lot of my workshops. And it has a bunch of different SQL injection risks on it. It's basically a website where you can log on and you can vote for cars that you like. And then there's a leaderboard. It's deliberately vulnerable. There's lots and lots of vulnerabilities on this site. Anyone's welcome to go and play around with them. You can go and exploit SQL injection on here and not go to jail, which is really good. What you can do is say something like, okay, I want to view the Lamborghinis and I'm going to take this URL. Now let's make this a bit more interactive. So who has actually done SQL injection it takes before? Okay, some of you, some of you, you haven't. You want to come do one? Yeah, let's try. Because then if it's you and not me, I'm okay. You'll go to jail. All right, so here's what we're going to do. I'm just going to open up a tool called Havage. Now some of you may have seen this before, but I want to make the point of how easy it is. What's your name first? Pauvel. Pauvel, I'm trying. How am I? Pauvel, okay, Pauvel. So here's what you're going to do. You're going to be the hacker. And what you've got to do is you've got to paste the URL on the clipboard into that target field. Yeah, you paste it over the other one. Very good. Hacking is hard. Look at that. All right. Now you click the analyze button. So what it's doing is it's just making HTTP requests, right? This is not going direct to the database or anything like that. It's just making requests and trying to cause internal exceptions that disclose the structure of the database. And what it's actually done now on the bottom line is it says the DB name is hack yourself first underscore DB. So it's already found the name of the internal database. Now what you do is you go up and you click on the tables button because what you want to try and get is a list of the tables. And then you click on get tables. There we go. And it goes away. Here we go. Now remember while we're doing this, and I'm not saying that Pavel is like a 15 year old kid, right? But this is what 15 year old kids do. They can copy and paste URLs. Now which table should we get, Pavel? Well, I reckon that's kind of public. Let's get user profile. So you just click the check box next to user profile. That's about the hardest thing of SQL injection, like knowing which box to check. All right, let's get the columns. So it goes away and it's going to think because we want to wait until it finds all the columns. And again, all it's doing here, now let's wait till it finds them all before we do anything more. It's just making HTTP requests and it's causing exceptions in the database which bubble up to the user interface. Now if you were a hacker, what data would you get out of user profile? Oh, you're good at this. Yeah, very good. All right, let's get the data. There we go. That's SQL injection. Well done, Pavel. Good one. All right, so this is kind of the point, right? Like it is really, really easy to mount a SQL injection attack. And what we're seeing these kids doing is they're using these tools. And to be honest, like Havage is a bit of a, we'd say a Mickey Mouse tool, right? Like it's very, very basic. It's a nice little gooey interface. The hardcore guys are going to use something like SQL injection. Sorry, they're going to use something like SQL map. SQL map is much more effective. But the interesting thing as well is how people are finding sites to hack. And I'll show you because it's actually really, really easy. What they're doing most of the time is they're jumping into something like a Google search and they're saying let's do a search for in URL. And then they'll say, okay, in URL what I want is question mark ID equals. And then they might narrow it down a bit and they'll say, well, you know, what I really don't like is I don't like, I don't like Swedish sites. We still don't like Sweden here, right? Yeah, very good. Okay, I don't like Swedish sites. And then they would get a list of sites in Sweden which they don't like, which should have an ID equals somewhere in the query string. But actually how we might do this, we'll sort of narrow it down a little bit and we'll say.asp, get like classic asp. All right, because if it's classic asp, we know their chances of having good SQL injection defenses are going to be much lower. And then inevitably what you get is a list of URLs and you get IDs in the end, which are integers, and almost certainly if you pick a bunch of those and you put a non-integer character after the integer, you'll see an internal exception. Because what they're doing is they're just passing this untrusted data into the database and saying just run this, it's just part of a script. So for something like one of these, it's going to be select star from widgets where widget ID equals whatever the user gives us. If it's a one or two or three, it's fine. If it's a three X, the database is going to say it is not a valid integer type. There's a cast exception and that's that. So that's how SQL injection works. You may have also noticed that I have SQL injection on my t-shirt to Bobby Tables. So SQL injection is just a ridiculously easy attack vector. While we're here doing Google searches as well, there's other stuff that you can find via Google because there's just so much stuff that is openly searchable. So I like this one. There's one you can do which is in URL, FTP. So Google will index things over FTP. And then you can go down and say, well, let's get web.config files. Who knows what a web.config is? In an ASP.NET application, the web.config is where you have the connection strings, the machine key, which is effectively your private encryption key, your API keys in your settings, a whole bunch of really, really good juicy stuff. So you go and you run that and then you find all of these sites that have got exposed web.config. Now, what this means is that there is open FTP to these websites. Google can read from them because they allow anonymous access. So not only can you go and get FTP or you can go and get web.config, you can probably go and get anything from any of these sites. Not only can you get stuff, but if they've left anonymous FTP enabled in read access, they've probably also left it in write access. So you can write to these. And when you scroll down through these, you sort of get a sense of the diversity of just how much stuff is there..gov. Washington State Department of Transport. I know that's what it is because this has been here for years. They still haven't fixed it. It's still open. There was a time when I emailed a bunch of sites and I said, hey, you might be interested to know that your FTP is open and anyone can access your stuff. And no one replied. So fair enough. So that is curious. But of course, once you can start running these Google Docs, and this is what I meant earlier on. I said Google Doc, like a carefully crafted Google search. And just in case you really, really want to run other Google Docs, you go to exploit DB Google hacking database, which is there. And you can get a list of Google Docs to run. You can get different types of Google Docs. So maybe you would like to do a search for files containing juicy info. I wonder what's on. I've actually never looked in there. Let's see what's in there. This may not be public forum suitable stuff. Who knows? Okay. So what do we got in here? We've got things like stats generated by we've got Apache server status. So we're probably going to get some logs and things. PDFs with tax returns in them. What's in that one? Then you can run the Google Doc. And then we don't click on any of the links. But you get the idea, right? A lot of it is just index it's public. Looks like some of these are served over FTP as well. Inevitably, some of these are going to have some pretty sensitive personal info in them. We can learn other things by modifying our Google Docs just slightly. So again, this one which search for web.config. Web.config have connection strings in them. Connection strings connect to databases with accounts. Sometimes they connect with very privileged accounts. Anyone know what the SA account is? Right. So the admin. This is the God writes account. If you can connect to a database with SA, you can not only access everything in the database, you can access everything in every other database. You can execute any other commands on the host SQL version. So you can restart it. You can probably execute XP command shell which allows you to execute commands on the host operating system. And if you can't, you can enable XP command shell by hitting another command. If we find results here, then they're extra bad. Here's what I really like about these results. Password. Now, your passwords should have a combination of letters and numbers. Like that. Not like that. Don't do that. And don't use SA. Why do you think people do this? It's very easy. I'll tell you, this makes setting permissions really easy. Because it can just do everything. You don't have to worry about going to every table and setting data reader or data writer or any of that sort of stuff. It's like magic just happens. Makes life very, very simple. So that one's kind of curious. Let me show you something else. And I'm going to open my password manager for a second. Who uses a password manager? Who uses one password? Who uses last pass? Any others? Keep pass? Okay. Use a password manager. Whatever it is. I like one password for various reasons. But frankly, if you're using a password manager, you are so far ahead of everyone else anyway. All right. So what I'm going to do here is I want to just have a quick browse through one of these underground sites. And I'm going to start up my tour browser. Because one of the things I think people find very curious is the fact that we do have a lot of information for sale on the web. And what I want to do is I want to jump into Alpha Bay. Normally I don't do this in like really public talks. But this one is not so public. It's just us being recorded. All right. So everyone remember the Silk Road? Silk Road was a really large underground drug site run by a guy that went under the chute and named Dread Pirate Roberts. Dread Pirate Roberts was actually a guy called Ross Ulbricht. Ross Ulbricht eventually got caught. And one of the reasons he got caught is because he made a Stack Overflow post. I'll show you what it was. I was in this talk here. And this is kind of funny, right? Because he got this guy running this underground drug market. And basically he was asking questions on Stack Overflow related to running his underground drug market. This is the question he asked. This is one of the things that brought him undone. He originally created the profile using an email address that identified him personally. It's one of the ways he got caught. Anyway, Silk Road got taken offline. Of course we've seen other things pop up in its place. Stuff like Alpha Bay. I want to show you what Alpha Bay looks like. 7mp. I'm going to do that. I then have a really, really random username and password. I don't know why I chose Google Google. I think I just fat fingered it. So we do that. Because we're going to have a look at what these guys are actually selling. No idea how this will turn out. And they really like captures, don't they? This is the second one. 9b. Now for those of you who haven't used Tor, it's very easy to get the Tor web browser. You just download it. Google Tor web browser. It does have very legitimate purposes as well. It's a good way of having anonymity. And then inevitably when you have the Tor browser, you can go to these onion websites. So this is running on a server somewhere which we are accessing by going through multiple different Tor relay points. So our traffic is sort of getting bounced around the world such that they don't know who I am and I don't know who they are. Now there have been exploits against Tor. So we saw quite a bit of news a few months ago where Carnegie Mellon University apparently had demonstrated that if you have enough Tor exit nodes that you run, you can start to de-anonymise traffic because you can start to see where the traffic goes. But I wanted to show how easy it is to get in here and find things of this class. Drugs and chemicals, weapons, going to stuff like fraud. Have a look at what we get in fraud. Dumps. Would you like to buy some dumps? US dumps. What do you want in here? You want to buy a Skype man Spotify account? Would you like to buy Spotify accounts? As seen on Krebs and security, he is using Brian Krebs in order to promote his stolen Spotify accounts. Two bucks. I assume that they are probably about two bucks each. The curious thing about this, this is sort of what I was touching on in my previous talk. This is a marketplace that does not look dissimilar to many of the other marketplaces you see online, legitimate marketplaces. We have a seller, you will see that we have things like the vendor level, we have a trust level in here as well. Everything is nice to categorise, good description of it here. They have a whole lot of guidance in here about how to go and use Bitcoin to buy these things in a manner that makes it difficult to trace you. This is how easy it is, it is just a marketplace, you browse around and you buy these things. You can be buying drugs and weapons the same way. Mind you, you have to get them delivered, which is a lot harder than actually getting Spotify accounts delivered. So that is that one, I find that a really sort of curious thing about just how easily accessible this is. It also helps explain why data bridges are valuable, because you can go and sell them. People want to break into systems, your systems, because they can turn around and put them on the market. It is that easy. Okay, something a little bit different as we start to wrap up, one of the interesting things that I have found lately is IoT. So we have all seen a lot of IoT connected things, right? And we are starting to see vulnerabilities in IoT connected things. And actually, you know what, let's start with VTech. We will go back to VTech again. I talked about VTech and they inevitably had vulnerabilities in the APIs behind their IoT things, their tablets. And this was actually some of the data they had taken out. I never got given the photos, which I am quite happy about. But these are the photos of kids and sometimes with their parents that got leaked. Now curiously, so this was VTech, all this data got leaked out in October, November timeframe, because they had things like no transport layer security and they had enumeration risks and SQL injection risks. But the good news is that VTech is now moving on and they are building home security systems. Holy shit. This is at CES. The reporter I worked with on the VTech data breach took a photo of this and sent it to me. He thought I might find it amusing. I certainly did think some things when I saw this. Probably don't buy these ones. I got to feel a little bit sorry actually for these guys because they would have had this stuff being built well in advance of the VTech data breach. And inevitably they are totally different teams, totally different places, totally different approaches to security. But I feel sorry for the people working on these products because they must have seen how bad that VTech data breach was and just gone, oh crap. Now we got to try and sell home security products. Anyway, brings me to things like this. Now some of the interesting IOT stuff that we are seeing pop up lately, some of it is just kind of ridiculous. I don't think this is ridiculous, but I am going to give you some ridiculous examples in a moment too. So this is LFX and this is made by an Aussie company and they are connected light bulbs. And they are really, really cool and I like the idea of having an app where I can sort of change the colour of the bulbs and the brightness and everything. I don't want to have to get off the couch to do stuff. This is our lazy lifestyle today. But anyway, LFX had a vulnerability in the light bulbs. And I know it is a vulnerability in the light bulbs. But the interesting thing about it though is a lot of people say with the IOT emergence if you like, is they say, look in a case like this, alright, if there is a vulnerability in the light bulbs, the attackers may be able to control the light bulbs, do I really care? Like how much of a threat do I think it is if the attackers can put my house into disco mode? Make lights flash. But the vulnerability that they had leaked the network credentials. Right, so now the IOT thing is the attack vector into the network. And I am much more worried about someone having access to my network than what I am about them being able to change the colour of my light bulbs. So LFX came out and they said, yes we had a vulnerability, please patch your light bulbs. How the hell did you patch your light bulbs? I assume you do it with the companion app or something like that. But I guess the curious thing is, are we ready to sort of accept that you have to be able to patch your light bulbs? They also said, don't worry, we are not aware of anyone having been compromised by their light bulbs. Which to me sounds really odd because think about the attack, right? The attack is they get access to the network. If you find that someone is in your network, are you ready to blame the light bulbs? Probably not. Now as weird as this is, and again I would actually like these, they are kind of cool. I have seen two other devices in recent times suffer a similar attack. One is the eye kettle. There is an eye kettle. And the idea is that you can be laying in bed and you can turn your kettle on. Now think about this for a moment because this is pointless, right? What do you do once the kettle boils which takes about two minutes? It doesn't bring the water to you or bring the, you still got to get your ass out of bed and go to the kettle. But the vulnerability with the kettle was they found that you could de-auth the kettle from the wireless network. You could trick the kettle into connecting to your own network and then you could tell net into the kettle with the default pin. Tell net into the kettle. So now you are tell netted into the kettle using the default pin and then you can get the Wi-Fi credentials out for the network. Same problem. So that was the second one I saw and then just the other day when we had CES on, there was a doorbell that had the same problem. A fucking doorbell that connected to the web and the doorbell was disclosing the credentials of the network. And all of this stuff is crazy. But none of it is as crazy as this. Have you seen this? Anyone got one of this? You wouldn't say yes if you did would you? So this is a licksil satis and this is real. It's a Japanese toilet. If you've been to Japan you'll know how crazy they are about their toilets. They're all like rocket ships. And this is the companion app. And these are real screenshots. I didn't fabricate these. You can find them on the internet. And you look at them and you try to figure out what's happening. Like take this middle one. It's in Japanese. I don't know if anyone here speaks Japanese and can tell me. But what do you reckon is happening in the middle screen? Looks like a calendar. Like event driven data. Some kind. I don't know what. And I love the one in the front too. It looks like it's a music player. I did not fabricate this. The toilet is playing. I can't get no satisfaction. And I saw this a couple of years ago and I used it in a talk. And I said we are now approaching the era where we have to be aware of vulnerabilities in our toilet. And eventually they had one. Here's the advisory. This is terrifying. Can you imagine this? I showed this at a talk once and someone said yes this is known as a back door attack. On that note, I think this is a really terrifying thing is a good place to end. Let me see if anyone has any questions about what I've just covered. Or are we all just in shock about the fact that this could happen? Any questions, folks? All right, well hey, if you think of anything, put it into the Slido app and we'll be able to cover it later on. I think we get, what about another 15 minute break, Jacob? And then someone else can do some talking. Thanks, guys. Thank you.
very practical. And basically I'm just going to but there are other resources which are not their security is that they basically just make attacks and it's interesting to look at things coming back to, and we spoke about this just a lot of my demos. And I use it in a lot of my welcome to go and play around with them. You can they're just passing this untrusted data into the information for sale on the web. And what I want very legitimate purposes as well. It's a good way on in my previous talk. This is a marketplace a licksil satis and this is real. It's a Japanese