How I hacked my way to Norway
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50872 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 2014137 / 170
2
3
5
6
8
11
12
16
21
22
23
27
31
35
37
42
43
45
47
48
49
50
52
54
56
57
58
61
65
66
67
71
74
77
80
81
83
84
85
87
88
89
90
91
94
95
96
97
98
100
102
107
108
112
114
115
116
118
120
121
122
123
126
127
128
130
133
135
137
138
139
140
141
142
143
144
145
147
148
149
150
153
155
156
157
158
159
160
161
162
163
166
169
170
00:00
BitAreaPoint (geometry)Googol1 (number)Real numberContext awarenessBlogDrop (liquid)WebsitePower (physics)InformationComputer clusterGoodness of fitComputer animation
01:22
GoogolTwitterMemory cardPlastikkarteMemory cardDigital photographyTwitterWeb 2.0Computer-aided designBit rateComputer animation
02:31
Memory cardMaxima and minimaSign (mathematics)Digital image correlationChi-squared distributionInformation securityMountain passElement (mathematics)Personal identification numberNumberAddress spaceEmailLatin squareWhiteboardInformationTwin primeDebuggerMenu (computing)Active contour modelRule of inferenceGamma functionCache (computing)Capability Maturity ModelComa BerenicesMemory cardDigital photographyPlastikkarteArmInternetworkingPoint (geometry)Element (mathematics)QuicksortPersonal identification numberSoftware testingMessage passingForcing (mathematics)RandomizationInformationIdentity managementString (computer science)Computer configurationMobile appDependent and independent variablesMetropolitan area networkSocial classPhysical lawBitAdditionTriangleMilitary baseCycle (graph theory)DigitizingNumberTesselationCASE <Informatik>Content (media)Endliche ModelltheorieDifferent (Kate Ryan album)Sheaf (mathematics)FamilyProcess (computing)Row (database)Sound effectDatabaseWebsiteMotion captureHypermediaMultiplication signBit rateInformation securityAddress spaceWeb pageField (computer science)Right angleTablet computerVirtual machineMobile WebData miningProxy serverMemory managementGreatest elementFacebookGame theoryMatching (graph theory)EmailOffice suiteStandard deviationRandom number generationIP addressTouchscreenCryptographyAverageData dictionaryProfil (magazine)Set (mathematics)Computer animation
11:17
PasswordEntire functionFreewareFormal languageView (database)Domain nameClient (computing)DebuggerGraphical user interfaceFunctional (mathematics)ResultantSoftware developerPhysical systemSystem administratorOrder (biology)NumberMedical imagingClient (computing)Dependent and independent variablesBitPosition operatorOpen setPublic key certificateProxy serverLine (geometry)Game controllerService (economics)Mobile appDifferent (Kate Ryan album)Validity (statistics)Moment (mathematics)Information2 (number)Web servicePasswordFreewareConnected spaceDemo (music)Vulnerability (computing)Reflektor <Informatik>Parameter (computer programming)TrailMultilaterationQuicksortMultiplication signIncidence algebraRight angleIP addressWeb browserWordVirtual machineTelecommunicationMathematicsWebsiteAuthorizationBlog1 (number)Web pageLengthCASE <Informatik>Information securitySoftware frameworkCommunications protocolComputer configurationComputer virusApproximationDressing (medical)Thomas BayesPower (physics)Memory card40 (number)DigitizingSoftware testingMobile WebSource codeGoodness of fitSign (mathematics)Computer animationMeeting/Interview
19:46
Host Identity ProtocolDebuggerView (database)Virtual realityLink (knot theory)Local ringDefault (computer science)Latent heatAddress spaceConfiguration spaceEmulatorIntelComputer networkInternetworkingDemo (music)Connected spaceNeuroinformatikWebsiteOpen setIP addressComputer fileTracing (software)BackupMetreWave packetComputer animation
20:54
AreaBuffer overflowOffice suiteMetropolitan area networkGoodness of fitRight angleTouchscreenComputer animation
21:44
Buffer overflowAreaAmsterdam Ordnance DatumView (database)DebuggerGamma functionCodierung <Programmierung>Data typeGroup actionTouchscreenMobile WebRaster graphicsInternet service providerPasswordMobile appPoint (geometry)AuthorizationCartesian coordinate systemElement (mathematics)Multiplication signMedical imagingQuicksortConnected spaceRepetitionInformation securityMetropolitan area networkSound effectAuthentication1 (number)BitMappingCASE <Informatik>Computer animation
24:35
PasswordEncryptionCorporate NetworkDatabaseAuthorizationFile formatMemory cardInformationHash functionMaxima and minimaDenial-of-service attackUniqueness quantificationRule of inferenceData dictionaryCache (computing)Least squaresKernel (computing)System on a chipLibrary (computing)Tape driveComputer fileGraphics processing unitEstimationAsynchronous Transfer ModeoutputWorkloadHash functionSource codeData dictionaryBitTouchscreenPasswordCryptographyRoundness (object)RandomizationPlanningMultiplication signInternet service providerData management40 (number)DatabaseWave packetPattern languageGodVirtual machineSign (mathematics)Different (Kate Ryan album)MathematicsPoint (geometry)Element (mathematics)AlgorithmSoftwareData storage deviceGraphics processing unitGroup actionEncryptionMaizeLaptopComputer graphics (computer science)Table (information)WebsiteQuicksortSemantics (computer science)Process (computing)CountingDeterminismMatching (graph theory)Hand fanDevice driverBridging (networking)Mechanism designTrailScaling (geometry)Right angleLogin2 (number)DeterminantMereologyFormal languageAddress spaceVideoconferencingCASE <Informatik>Range (statistics)Cartesian coordinate systemAttribute grammarWeb 2.0CAN busProjective planeHessian matrixStatement (computer science)1 (number)Thomas BayesGoodness of fitFigurate numberDisk read-and-write headApplication service providerVisualization (computer graphics)Open setComputer fileHacker (term)10 (number)Row (database)Medical imagingEmailPublic-key cryptographyWordMoment (mathematics)System callComputer animation
33:16
Information securityLoginExecution unitVideo game consoleSoftware developerHTTP cookieScripting languageHypermediaGoogolServer (computing)Codierung <Programmierung>Heat transferComputer configurationFrame problemStylus (computing)WebsiteFile Transfer ProtocolProduct (business)Memory cardDirectory serviceLocal ringInjektivitätInformation security1 (number)Hand fanMultiplication signAutomatic differentiationWebsiteSource codeInjektivitätFrame problemAngleRow (database)CuboidSubject indexingComputer configurationEmailNumberDependent and independent variables3 (number)Point (geometry)Digital rights managementRight angleMappingLevel (video gaming)BitSingle-precision floating-point formatComa BerenicesMatching (graph theory)Core dumpDot productCondition numberKey (cryptography)GoogolForcing (mathematics)String (computer science)Web browserConnected spaceStatement (computer science)Scripting languageCASE <Informatik>Network topologyReading (process)Order (biology)Form (programming)System callGame controllerResource allocationProduct (business)Figurate numberDatabasePublic key certificateSeries (mathematics)AuthorizationDigital photographyQuantum stateTouchscreenPasswordWeb pageValidity (statistics)Configuration spaceSoftware testingGreatest elementArithmetic meanRaster graphicsAddress spaceMobile appCross-site scriptingInternetworkingApplication service providerWeb 2.0Complete metric spaceGraphical user interfacePoisson-KlammerVolumenvisualisierungComputer fileFile formatFile Transfer ProtocolBackupMaxima and minimaMereologyUniform resource locatorExtension (kinesiology)Goodness of fitNP-hardRevision controlComputer animation
41:47
Query languageString (computer science)InjektivitätProduct (business)Parameter (computer programming)Intrusion detection systemSide channel attackMusical ensembleTime domainInclusion mapMotion blurSummierbarkeitView (database)Software testingTrailHacker (term)FreewareRevision controlRoyal NavyElectric currentChi-squared distributionExecution unitWebsiteWebsiteUniform resource locatorExploit (computer security)Binary fileNumberGame theoryRoundness (object)Application service providerQuicksortInjektivitätRight anglePattern languageRow (database)Web browserEmailAxiom of choicePasswordGoodness of fitForm (programming)Parameter (computer programming)Source codeCASE <Informatik>Table (information)Query languageException handlingMoment (mathematics)String (computer science)Equivalence relationUser profileSelectivity (electronic)Physical systemBell and HowellDatabaseOrder (biology)Open setStatement (computer science)InformationIntegerWeb applicationInternet service providerView (database)Single-precision floating-point formatLink (knot theory)BitMusical ensembleDemo (music)Hacker (term)Web 2.0GoogolDeterminantSequelComa BerenicesInteractive televisionProcess (computing)Data dictionaryDot productElectronic mailing listTask (computing)Web pageMetropolitan area networkTraffic reportingResultantClassical physicsComputer animation
49:33
MaizeAreaSingle sign-onChemical equationRight angleMetropolitan area networkHookingReal-time operating systemWebsiteWeb pageElement (mathematics)Form (programming)Cellular automatonRoundness (object)Computer animation
50:25
LoginField (computer science)PasswordVideo game consoleSocial classComputer networkSource codeSurjective functionoutput10 (number)Interior (topology)Server (computing)EncryptionFreewareWireless LANSoftwarePoint (geometry)TelecommunicationForm (programming)Element (mathematics)Demo (music)Non-standard analysisContent (media)Interface (computing)PiInsertion lossConnected spaceArithmetic progressionRight angleQuicksortWebsiteWater vaporAnalytic continuationComputer animation
52:26
Total S.A.Revision controlFirmwareMKS system of unitsExecution unitExplosionConfiguration spaceAssociative propertySoftwareDemo (music)TouchscreenBitKeyboard shortcutGraphical user interfaceHacker (term)LoginFreewareNon-standard analysisComputer fileData miningFigurate numberPhysical systemComputer animation
53:37
Hacker (term)Configuration spaceDigital photographyMenu (computing)TouchscreenLaptopRankingPoint cloudWeb pageView (database)Graphical user interfaceZoom lensHash functionMotion captureWebsiteScripting languagePlastikkarteTwitterPasswordBackupCache (computing)Computer-generated imageryOpen setFile viewerExplosionAndroid (robot)ACIDComputer fileNon-standard analysisVirtual machineQuicksortDemo (music)FreewarePhysical systemDependent and independent variablesSoftwareMedical imagingConnected spaceGraphics tabletFrame problemGame theorySoftware testingInternetworkingMultiplication signComputer animation
55:11
Insertion lossInterior (topology)InternetworkingForm (programming)Point (geometry)Uniform resource locatorGoodness of fitComputer fileDifferent (Kate Ryan album)SoftwareWebsiteWeb 2.0Address spaceOpen setBitInformation securityWeb pageParticle systemCASE <Informatik>Group actionPasswordThomas BayesWaveCellular automatonConnected spaceDressing (medical)BuildingSource codeComputer animation
56:48
EmailPasswordLoginGroup actionConnected spaceCASE <Informatik>EmailWeb pageAddress spaceMereologyPoint (geometry)Form (programming)Uniform resource locatorFacebookPasswordRight angleSlide ruleFocus (optics)Computer animation
57:47
Decision theoryParallel portElement (mathematics)Uniform resource locatorFacebookConnected spaceScripting languageAlgorithmSlide ruleApplication service providerRoundness (object)Configuration spaceIterationComputer configurationBitWeb browserInternet service providerUsabilityInformation securityPasswordWorkloadMultiplication signRevision controlWeb pageCoefficient of determinationWebsiteSystem callMereologyPerspective (visual)LengthProgrammable read-only memoryBootingMeeting/Interview
01:01:13
Computer animation
Transcript: English(auto-generated)
00:02
All right. Welcome everyone. This is a good turnout. Look at this. Who was here for my talk a couple of days ago? Everyone. A lot of people. So a couple of days ago we looked at a whole bunch of online attacks that had happened in the past. So real world attacks, things that had actually happened and there were lots of power points.
00:21
And the power points are kind of good because you get to see a little bit of info and some real world stuff. But we didn't get to break anything and I left feeling really empty. So today we're going to break a bunch of stuff in a talk that I have called How I Hacked Myself to Norway. So for those who don't know me, I'm Troy Hunt. I'm at troyhunt.com and at troyhunt.
00:41
And a lot of what I'm going to talk about today is online on my blog or in my Pluralsight courses or places like that. So if you want more info, go and get it from there. So where I thought we'd start is to give you a bit of a context of why I'm doing How I Hacked Myself to Norway. And the thing is Australia is a very, very long way away from Norway.
01:00
Now sometimes I say this and people go, well, Australia isn't that far away, is it? That's not Australia. They're the guys with the mountains and the lederhosen. So that's not us. We're the guys with Mick Dundee and the drop bears. So they're the ones that you want to watch out for.
01:20
Now, if you don't know a lot about Australia, you can go and Google it. And what you'll find is that it is a very, very long way away. And it's about 15,000, 16,000 kilometres away. And what you'll find is that it's a very expensive trip to get from Australia all the way over to here. So before I left, I decided I'm going to need some spending money.
01:42
So I went out and I grabbed some credit cards. And I thought this would be a good way to start. Now, you don't want to guess where do I get these credit cards from? Shut up. Okay, so those who didn't hear the gentleman at the front, the noisy Irish man, I got them from here.
02:01
Yay. People put their credit cards on Twitter. Why do they do this? You know, taking photos of your breakfast is one thing. This is a whole other thing altogether. You know, it's a social thing. They get excited and they want to share everything they're doing. So, of course, they've got to take a photo of it and they've got to put it up on Twitter.
02:21
I particularly like this one. Oh, my God, I'm so happy he hears my credit card. Now, here's the funny thing, because if you jump over onto Twitter, you'll find that there is an account that is called Need a Debit Card. And Need a Debit Card very conveniently retweets photos that people take about their debit cards.
02:46
I really like this one because he took a photo of the back of his arm. So that was enormously convenient and I'm ever grateful.
03:03
Now, the thing that strikes me with this is that when we look at people posting credit cards on the Internet, we forget how easy they are making things to break. So everybody's worried. Well, we were worried about the Chinese, now we're worried about the Americans. We probably should be a little bit worried about everyone. But what I find interesting is when we're worried about the NSA, we're worried about the fact that they've influenced cryptographic standards
03:25
and broken random number generators and have done all this fancy, fancy stuff. And then we've got these guys just going, here's my credit card. Take it. So the point of this is that we're getting into this era where breaking security is often really easy because it's just so in front of us.
03:40
It is not a hard problem. Now, to that effect, I was looking at my Facebook the other day and a friend of mine posted this. And he was very excited because as you can see from the bottom, he was doing a fist pump because he got a first class upgrade. I was doing a fist pump because he gave me his boarding pass.
04:00
But it begs the question, what can we do with the boarding pass? This is real, too. I didn't make this one up. I better get his name off the screen. Oh, crap. Okay, so on the boarding pass, we have things like a name and we have a frequent flyer number. This is enormously convenient because we can go and do things with this. It's Qantas frequent flyer number.
04:20
Now, if we take a look at the Qantas mobile app, one of the things the Qantas mobile app lets us do is log in with a membership number, a last name and a pin. Just one point on pins. What I secure my luggage with is not a suitable pin to secure my millions of frequent flyer points and my travel history and my family names and everything else.
04:41
But somehow, pins have become a thing. Now, moving on, what we can do is we can go through and say that we've forgotten our pin. Now, if we have a membership number and a last name, who knows where we get that from, we can then go through and do a reset process. The problem with the reset process is that if we do this, they're going to send him an email with the details of the reset.
05:07
Now, I don't want to send him an email because it kind of blows the point. But if we go over to the website, then we can start to do something a little bit more interesting. We have two options. Send a temporary pin or don't send a temporary pin.
05:21
Now, the other thing is this Qantas website has got a little triangle on the padlock. Everyone know what the triangle means? A little yellow triangle? It means don't trust it. So it's been loaded over HTTPS. It's an HTTPS address. But then it's put something else on the page that is not HTTPS. We can't trust that piece of content. And a little bit later on, we're going to see exactly what it means not to be able to trust a piece of content on the web.
05:45
So for now, it needs a membership number and a last name. Now, that much I can get. So what I'm going to do is we're going to fill this out. We're going to get the data off the boarding pass. Fill in the details. Obfuscated details. Give it a last name. Now, I don't want to send it to his email address because clearly that's not going to work in my favour.
06:04
So we'll do this. So next up, we're going to need three different pieces of information. And in the first section, I can have either his mother's maiden name, which I've got no idea about, or I can have one of the last few flights that he's taken. Which begs the question, where am I going to get one of the last few flights?
06:21
There it is. That he's taken. Served up on social media. So thank you very much. We'll just take all that information. carrier, flight number, fist pump, first class, flight date. Very, very good. Okay. So we've got all that information.
06:43
Now, we need two other pieces of information. That's what this additional information bit down the bottom is. And one of these pieces of information is extremely easy to find out in the era of social media. So if I want to find out his birth date, I could just look at his profile and see everyone saying happy birthday. Not only happy birthday on a date, but happy 30th or 40th or whatever it was at the time.
07:04
So we get a year as well. So, birth date. Dead easy. We have many, many, many, many ways of getting birth dates off people in this day and age. Now, the other two. Office skated. Office skated.
07:22
Mailing address. So he's moved around a bit. I don't know the mailing address. And if you don't get the string just perfect, then it doesn't match up to what's in the database and the whole thing falls in a heap. Now, the data joining is a little bit interesting, though. So here's what I'm going to do. With the data joining, we're going to put in some sort of random date. Jan, keep going, keep going, keep going.
07:40
1990. Now, it's probably not going to be right, but it doesn't matter that it's not right. So let's try that. It doesn't work. Now, before I did this, I opened up Fiddler. So who here uses Fiddler? Those of you that don't, should. This is very, very good. So Fiddler is an HTTP proxy tool, and it can capture all of the requests that you make from your machine,
08:03
and as we'll see in a little bit of time, also the devices that are around you. So what I did is I captured that request in Fiddler. So at the top left there, you see it was request number 22. It was going to Qantas.com.au. What I've done is I've taken that request and I've dragged it into Fiddler's Composer.
08:21
So Fiddler has a tool that lets you take a request, put it in the Composer, and then see everything that was in that request and reissue it. So we see we've got request headers, which is that great big bit in the middle, and because it was a post request, it's got a body, which is everything down the bottom right. So what we're going to do is take a look at what's in that body,
08:41
and in the body we have the month of joining, which is what we just filled out before, number one, Jan, and we've got the year of joining being 1990. If we increment it and change it to two and reissue the request, we get another response. The response has an identical body size, so it's probably going to be the same message that's come back,
09:00
and that message was the one that said, sorry, some of your information is incorrect. So keep trying, three, four, five, six, seven, eight. Same response, same response, same response, same response, and then finally we get a response that's bigger. This one's just over 7K. So what ended up happening was that response was the one that said, okay, you've now got the information correct.
09:20
You have picked the right month of joining and year of joining, as well as the other data, which we knew was right because he gave it to us on his boarding pass. So all of that's gone off to the server, and the first interesting thing here is that Qantas, and many companies do this, but I want to just pick on Qantas, but Qantas has got brute force protection on the login, so they don't want people to try logging in too much with a particular membership number
09:42
and sort of random pins because otherwise, you know, it's membership. It's a 40-digit pin, so you've got 10,000 possible options. You're going to knock it off on average in about 5,000 guesses, probably less because there's common pins and you go through a dictionary. But what they don't do and what many don't do is there's no brute force protection on the process to reset the pin. So it doesn't matter that I can't log on, that I don't have the right pin
10:02
because I can just go and reset it anyway. So that then allowed me to go onto the website because now I know the month and the year of joining, fill that in, back into here, now I've successfully verified my identity and it's going to let me change the pin, which is great,
10:20
so I can put in my own pin. Confirm the pin, and we'll update, and we're done. Forgotten pin confirmation, we have his account. So that was how easy it was. So what can you do when you get his account? Well, once you're into a frequent flyer account, obviously you get all travel history, you can go and buy tangible things to send to yourself,
10:41
you can buy other people tickets, you can buy me a ticket. It can only be spouses and significant others, so I do have to be his gay lover, but I can get a ticket. And because this is being recorded, just for the record, I didn't do it just like this, I used my own account to test weather issues. So mate, I didn't steal your points, don't worry. Relax.
11:01
Alright, so that's a pretty sort of obvious, basic kind of set of risks. What I thought we might take a look at next is around mobile devices, and all of us have got a heap of mobile devices. Most of us in the room have probably got two or three IP addresses. A lot of them are probably talking over the internet, but I'm going to come back to that because it's going to be a bit interesting later on.
11:21
Now, how many apps do you think most devices have on them these days? Most phones, tablets? Any guesses? I heard a 50 here. So the sort of commonly accepted wisdom is somewhere around 40 to 50 different apps on most mobile devices. Now, how many of those do you think have serious security vulnerabilities in them?
11:43
Every time I ask, someone always says, all of them. So based on what I look at, and I go through and look at a bunch of apps, I would say probably about half the ones I see have serious vulnerabilities in the way they communicate over the web. And what I thought I might do is talk about some of the cases I've seen
12:01
and then show you how we can identify it in another live demo. So one of the ones I saw quite recently was reviewing an app. And normally when I review a mobile app, the first thing I'll do is I'll proxy the data from the device through Fiddler. And we'll do this in a second, so you'll be able to go away and do it yourself to your own apps later on.
12:20
Now, when I proxied the data through this, I could see the web service that it was hitting, and I could also discover other web services. So often, depending on the technology stack, web services are very nicely documented. You find one, then there's another page that lists all the other web services. Now, one of those other web services was called Get Users. And true to its word, it did exactly what it said it would.
12:43
It got users. It got every user, and every username, and every password, and returned it all over a nice API in JSON. So it was a nice, fast request. And when I found this, and I spoke to the developers and said, look, I'm thinking a little bit of a problem.
13:01
This is what I found. And I said, look, all I did was I just proxied the data through Fiddler, and I found this. And they said, oh, it doesn't matter. Our users don't use Fiddler. This is a true story. I kid you not. So I think the lesson there is that we do become very complacent. So we build systems with an intended function
13:22
and an intended way of being used, and we expect everybody to play nice and do it that way. And the reality of it is there are people out there who don't want to play nice, and unlike me, actually have an evil intent as well. That's one. Another one recently, this was around a bank. And in fact, I was preparing a demonstration for TechEd,
13:41
and I wanted to show an app that did security very well when it came to validating SSL certificates. And I'd looked at this bank before, just a random, I wonder what this app does. Open it up, bang, there we go, everything's okay. So what should normally happen is if you proxy data through something like Fiddler, Fiddler can create a self-signed certificate for HTTPS requests.
14:03
So it can actually return a certificate that won't be valid on the client. It's self-signed. It's not issued via a certificate authority. But it does mean that there can be an HTTPS communication. Now, normally, the device, if it gets a self-signed certificate that's not valid, will throw its hands up and say, no, this doesn't check out.
14:21
It's like every now and then you go to a website in the browser and Chrome goes all red and it says this certificate is invalid. It's not the right certificate or it's expired or something like that. So mobile apps normally do that. And basically, every modern protocol or every modern framework that allows you to make HTTP requests does this implicitly.
14:41
You have to consciously go and turn off certificate validation. This bank had done that. It was one of our largest banks in Australia. So they had actually turned off the certificate validation. Now, I imagine it was very convenient because for the developers, they didn't have to worry about getting certificates on the machine. We'll just turn it off and we'll ignore it and then we can just do whatever we want.
15:01
Of course, the right way to do it is to actually create a self-signed certificate and trust it on the device. So effectively compromise your own device in order to be able to test your mobile app. These guys didn't do that. So one more before I move on. There was an incident with Westfield Shopping Centre in Bondi in Sydney.
15:22
And I wrote about this a few years ago. So there's a big sort of detailed blog post on this. And these guys had a mobile app where if you enter the shopping centre and then you spend all day shopping and mucking around and losing track of time and then you went to try and find your car again and you couldn't find your car because it was a big shopping centre, you pull out the app, you put in your number plate
15:40
and it comes back with these four grainy pictures. They're sort of obfuscated. You can't quite see the number plate but you can see if it's a big SUV or a little red sports car, whatever it may be. And you click on the one you want and it says okay, here it is and you can go and find it. So they'd gone to some length to make sure there was no personally identifiable information such as a number plate.
16:00
So that was good. The bit that was not so good is that the response behind that, so the JSON response that had the position of the car park and I guess the ID of the image also had the number plate. So it was actually sending that number plate back. So once you proxied the traffic, you could get that request, run it again manually and get four results.
16:22
Now the way they made you only get four results is they passed four in the request. So we're going here. You could change four to 40. You could change 40 to 4,000. You could get every single vehicle in the car park just by parameter tampering. Now that's not the way the app's meant to work but it's just an HTTP request. You can find it very, very easily.
16:42
The other thing you can do is you can run it every 60 seconds. So you can start to profile traffic coming and going. You can start stalking people. When does this person arrive? You could probably do a very nice app in today's cloud world that you got notifications as soon as this car went into the shopping center and did terrible things. But the other thing these guys did is for the sake of convenience,
17:02
they also had the control centers for the shopping center on the same IP address that the service was on. So once you took out the path of the API, it exposed the paths to do things like change the number of available spots in different car parks, change the wording on the signs,
17:21
which I did not do. Much. So I spoke to those developers as well and firstly they did feel rather bad about it because it made a lot of press in Australia and it didn't look very good for Westfield. And they said, look, the reason why they did it is because it meant they could write the one API and they could use it everywhere
17:40
for their admin system as well as for mum and dad who's just lost the car. Reuse. But a very bad example of reuse. So let's have a look at what this looks like. And here's the example I thought we'd use. So on my way here, getting back to the theme of the talk, I'm in Heathrow and I'm trying to get Wi-Fi access.
18:01
And like most airports, Wi-Fi access is terrible. And you get on this thing and it gives you 45 minutes and then it's trapped the whole 45 minutes anyway. It's terrible speed. Then it says you've got to sign in and you've got to get more Wi-Fi access by handing over all your information. And then I found a spot that had good Wi-Fi. A spot they wouldn't let me into.
18:20
So I'm standing at the front here and thinking, all right, well, what can we do in order to maybe see how we can get some British Airways Wi-Fi? And what I found was that I had the British Airways app on my phone and I still had crappy public connectivity. Now, the British Airways app has a feature where if you are a silver or gold executive club member,
18:43
you can get Wi-Fi passwords. Now, I'm not a silver or gold executive club member but let that not deter us. So here's the demo we're going to run. So what I did to my iPhone is I set it up to proxy traffic through my PC, through Fiddler.
19:01
So anyone that has an iOS device can easily do this. And we're going to do this with my phone now. Other devices have different ways of setting up proxies but the bottom line is is that you can say I want all the traffic from here to go through there and we're going to watch it as it goes. So my phone is currently set up something like this. It's a different IP address. It's the IP address of my PC at the moment.
19:23
And what we're going to do is we're going to go over to Fiddler. Now, you can get Fiddler from getfiddler.com. It's free. It's awesome. It's been tracking some requests here that I'm going to get rid of. Now, all you do to enable this in Fiddler is we go up to Tools, Fiddler Options, Connections. Now, Fiddler is listening on port 8888.
19:43
So that's what we had over here, just there. And we are allowing remote computers to connect. Now, once we do that, I can unlock my phone and if I open up, say, Safari and I refresh and I find I've got no internet connection
20:01
because it's died again. I'll just get my internet connection back or my phone is no longer connecting because maybe my IP address has changed. And this is the joy of the live demo. I saw a lot of demos far earlier this week.
20:26
Okay, so let's check this. And if I can't get the IP address right, then I will go to my backup save trace. So what I'm doing, so that I can probably get it right as well. So here's my IP address, 10.15.5.164.
20:42
It should be right. But if it doesn't work, I will open up my save fiddler trace and it won't matter. Give it one more go. Trion.com, go. That wasn't me.
21:03
Somebody hacked me. Mr. AV Man? Well, that's good. You fix that. I'll fix my Wi-Fi. Listen, just because you're...
21:26
All right. While that is being fixed, we will... Did I stand on it? Did I hack myself? Actually, well, the screen's gone.
21:48
Okay. So while the screen was there and you couldn't see what I was doing, I just fixed everything and made it work. And it looks like...
22:02
So while he's doing that, you can actually do this with any of your apps. I mean, at the end of the day, when you open your apps, they're requesting data that the provider is happily sending down to you and sending into your phone. You can sit just here and see what's going backwards and forwards. So some of the sort of things that I often see go backwards and forwards. A couple of funny ones, particularly things like really,
22:22
really inefficient requests. Hey, well done. I wasn't... I was finishing my story. Okay. I'll come back to the inefficient requests. So while he was away and I made everything work, when I opened that British Airways app, I had several requests. We can see here British Airways. Now, one of these British Airways requests
22:40
went here. Lounge. We can go and look at the data in Lounge. And if we look at the data in Lounge, they have very kindly sent us all the Wi-Fi passwords.
23:02
Now, let's be clear. They sent them to me. All I did is... In all seriousness here, all you do is download the app, install it, and they send you the data. Now, to bring this back to a point about application security, they are making the assumption that the authorisation is going to happen on the device. So they're just going to give you everything
23:22
and you're only going to be able to unlock the feature on the device when you provide your particular membership details and it authenticates you. But they've already sent you the data. They're just not expecting that you can go and get it in a way that they didn't intend. Now, to finish my story, one of the things you often find is particularly really, really grossly inefficient requests,
23:43
which is particularly bad on mobile devices because, of course, you're on 3G and they're bad connections and you've got batteries to worry about and things like that. So I'll often see things like you'll go to, say, a magazine app. In fact, I saw one for Foxtel in Australia, so a pay-to-v. And in the Foxtel app, you'd have all the channels and you'd have tiny, tiny, tiny little bitmaps
24:01
of each channel. Now, they look tiny, but they're actually about this big. They're huge. Each one of them was like a megabyte and they were downloading a megabyte of image each time you opened up the app. And that's one megabyte just for each channel and then you've got a whole bunch of channels. And I tweeted something about it and the guy who was involved in it responded.
24:20
And he actually had a very good reason for it. That was just how he was given the images. Interesting. Go to Nick's performance talk. Learn how to compress images. It's easy. All right. Let's try and get us back on track. So eBay.
24:41
eBay a couple of weeks ago got hacked. And eBay said they had 145 million active accounts hacked. They didn't tell us how many inactive accounts were hacked. And as funny as that sounds, when Adobe got hacked last year and around October, they kept saying they had some tens of millions of accounts hacked.
25:00
20, 30 million. I have 152 million Adobe accounts. And I have them because they're all published publicly. So often when there is a breach like this, the scope of it is underestimated for obvious reasons. So for eBay, I suspect that... And all we've got to do is just think about the size of it and the scale of it. Every opportunity, there are a lot more than 145 million.
25:22
Anyway, what I was interested in is the way Adobe, or rather eBay, was storing their credentials. And when I was reading around a little bit, I found some info. So Ask eBay, the official verified Ask eBay account. We store encrypted passwords that have been hashed and soldered. What's wrong with this sentence?
25:41
You'll find out in a moment. Main thing being that encryption and hashing are very different processes. They're both cryptographic processes. But encryption is a two-way thing with private keys and you encrypt and you decrypt, and there are other semantics that make it fundamentally different to hashing and salting, which we're going to have a look at in a moment. So that was a little bit confusing, so I read a little bit further.
26:01
And I found the official eBay statement from when the breach occurred. And the official eBay statement said that they were encrypted passwords. Okay, good. So they're encrypted. They're not hashed. Then I read some more, and the eBay spokesperson said that they were using a sophisticated proprietary hashing and salting technology.
26:21
Now, when we talk about the attributes of cryptography, proprietary isn't normally the one we're looking for. I've seen proprietary encryption before, and it was called Base64. Now, the point is we have got to get away from this we-encrypted data when what we really did was hash data.
26:42
These are two fundamentally different things, and for God's sake, stop saying that they're encrypted when they hash because people hammer you every single time because you shouldn't be encrypting passwords. What we should be doing is hashing them. Not quite like that,
27:00
but it's trying to find a better hash image that isn't a hashtag. Now, the idea of a cryptographic hash is that it is a one-way deterministic algorithm. So what it means is you have a piece of text like a password. Say it's password, but it's got a zero instead of an O so other people can't figure it out, and you create a hash, it creates a cipher,
27:20
it creates an output. Now, you might use an algorithm like, say, MD5, for God's sake. Every time you hash the word password with a zero, with MD5, it doesn't matter where you are, what PC it is, where it is in the world, what language it is, you always get the same cipher. That's the deterministic part of the hashing algorithm. So what we used to do is we would hash the password
27:40
and we'd store the hash in the database next to the username and the email address and all that other stuff. When someone comes and logs in, we take the password they give us, we hash it with the same algorithm, and because it's deterministic, if it's correct, it will match the one in the database and then we can say, okay, you can log in. Now, the problem that we had with that is that when you do that,
28:01
you can precompute all these hashes. You can get all these common passwords and create what we used to call rainbow tables and then you take the rainbow table and you compare it to the hashes from a breach database and when it matches, the rainbow table also has the plain text. Messes it right up. So we started adding salt and the idea of the salt is that once we have salt on a password,
28:21
we have randomness. So what you might do is you create, say, 32 random bytes, you get the password, you put the salt with the password, then you hash those and you store it in the database. So you store the salt and you store the cipher. When someone comes to log in, you use the username to pull the salt back, add it to the password they've just given you and hash it.
28:42
So it kind of looks ultimately a little bit like this. Hashing of the salting and the password and that creates the cipher. Now in your database, you then have something that looks like this. So you get a whole bunch of salts, a whole bunch of hashes. One of these for each person. So this is what we'd refer to as a salted hash. Now, is this a suitable mechanism of password storage?
29:05
Shaking heads. Other people not wanting to say. So, I'm going to give you an example. What we see here is salted hashes from the ASP.NET membership provider, the one that came with the Visual Studio 2010 project. So if you've ever written ASP.NET web applications,
29:22
you have probably done something like this before and thought it was safe. And I'm going to show you why it's not. So here's what we're going to do. I have a little tool here called Hashcat. And what Hashcat is, is it is a GPU cracking password hacker. And what that means is we can run this command.
29:42
And this command is saying let's run CUDA, Hashcat. So CUDA is a GPU made by NVIDIA, which is what this machine runs on. It's just a little laptop. You could also do it with ACL, which is what you'd get, say, an AMD graphics card from. But it's going to do cracking in the GPU. It's going to run this against pattern 141, which is the ASP.NET membership provider.
30:02
So we're effectively saying it's one round of salted SHA-1. It's going to take salted hashes.txt, which is basically what I showed you on that last slide. Salts, hashes. And it's going to use my hash killer dictionary. Now this is a password dictionary with about 22 million plain text passwords in there.
30:22
All it is, is each row by row by row it's a password. Not like an Oxford dictionary, just passwords people have used. And we're going to run this. Now what is happening is it is going through and rehashing with the salt and comparing it to the stored passwords. So it goes to the password dictionary, gets a password,
30:40
takes one of the salts from the previous screen, adds it, hashes it, compares it to the cipher. What we can see going through here, if we break this little screen down a little bit, is we had our salts, which are over there. These are our hashes and these are the plain text passwords that it is cracking out of them. So we are cracking these passwords from the membership provider. And it is just flying through and it's finished.
31:01
Oh wow, look at this. So, the main thing here is that we just did 11,911 kilo hashes per second. So we did about 12 million hashes per second in this tiny little old crusty laptop. When I run this on a modern graphics card,
31:22
like something like an AMD Radeon 7970, MD5 we can do about 5 billion hashes a second. SHA-1, you can do about 2 billion hashes per second. The point is that you can recompute the hashing process so quickly you don't even need rainbow tables anymore. Talking to people that really, really, really know this stuff inside and out,
31:42
let's say rainbow tables are too hard, they are too big. We don't need them. So even when the passwords are not salted, when we don't have this randomness, GPUs have gotten so fast, if we can do billions of hashes a second, why don't we just hash a dictionary and see what matches up. So if you have the ASP.NET membership provider from 2010 or earlier,
32:01
you have some work to do next week. Yeah, good question. So the question was, the passwords there are all quite short. They are pretty simple passwords.
32:21
And how much faster would it be for larger passwords? So the reason why I have chosen these, first of all these are all very common passwords, things like Qity. It's a crap password, we all know that. But it is extremely common. Because this is working through a password dictionary, and I'd open it, but it's like a 220 meg file and this machine doesn't go too well. But because all it needs is a password dictionary
32:42
that already has passwords in it, it doesn't really matter whether they are shorter or longer. It's not like going through every possible character range from 6 to 12 alphanumeric, you know, lower case. So it doesn't really matter what the range of characters is. If it is in the password dictionary, it gets cracked just as fast as monkey or something like that.
33:02
Now the question is, is it going to be in the password dictionary? So if you have created a long random password with, say, a password manager, it's almost certainly not going to be in there. If you have tried to create something memorable, there is a good chance it will be. Okay, let's go on. Oh, you guys.
33:22
So before I came over, I was asking some people, what about Norwegian security? What about something a little bit topical? So why don't we see how you guys are going with security? So before I do this, what do you reckon? Is Norway good, security ones? Nobody wants to say yes.
33:40
I think I heard one yes. I'm going to take it as a yes. So I started looking around for Norwegian sites. Now the problem I was having is that every time I found a Norwegian site, I couldn't see anything behind the ad. You guys have the hugest freaking ads. And yes, I did actually measure it 63%.
34:05
These are the most enormous ads I've ever seen. So it made things hard. What I decided to do is go through the Alexa top 100 sites for Norway and start going through and looking for security risks. And in all honesty, you guys will love this,
34:20
the security was actually pretty good. So I thought instead of breaking Norwegian sites, I'd show you some good practices from Norwegian sites, and then we can look at how things should be done, and then we'll find another country that's got crap security. Don't know where. All right, so a good example, and these are just things that are immediately obvious security-wise. So obviously HTTPS, it's got an extended validation certificate.
34:42
That's the big green bit up the top. I can't pronounce what it says, but it is extended validation, which means that there's been a lot of due diligence that they've had to go through in order to demonstrate their identity and prove who they are to the certificate authority. The only thing I don't like about this is that padlock, that doesn't make it secure. A lot of people put bitmaps of padlocks
35:02
right next to the logon, secure logon, because I've got a bitmap of a padlock. It doesn't work that way. You kind of need to see it up there in the address bar. So that was that one. So I looked at another one, and what you're seeing here is a very common, very basic test to see how the site responds
35:20
to a possible cross-site scripting attack. So I've just put in a script tag, and I've tried to do alert XSS. If the site is vulnerable to cross-site scripting, you get an alert box that appears on the page. If you don't, then it actually gets rendered. So we can see that it gets rendered to the screen. I can't pronounce what it says, but you can see it in text just down here. So what that means is things like the angle brackets
35:41
have been encoded as ampersand less than and ampersand greater than, and they're actually there in the HTML source. They haven't actually been rendered as a script tag. Another one here, basic SQL injection test. So can we change that URL from 479 to try and close off a statement and then add a condition
36:01
and see if it behaves differently? What this has done is return 404, so it's basically taken everything in that string and said it's not a valid ID, it doesn't match a record in the database. So that was good. So it was getting very hard on me to find a good site. Now, this one. Lots of response headers here, but there are three things that stood out to me
36:21
in the response headers. Content security policy, talking about the things that the site can and can't do and the other sites that it can and can't do them to. Strict transport security, which is that fourth one from the bottom. We often call that HSTS. It means that once an HSTS header is set, if you go to a secure site and it responds like that,
36:40
you can't then make an HTTP request. The browser has to honor that, which Chrome does, and Internet Explorer doesn't. But it's a good header. And we've got a cross-frame options header as well, and x-frame options, or XFO header, of same origin. Means you can't put this in a frame on any other website. You can put it in a frame on this website,
37:00
and that defends against click-jacking attacks. So that is actually rather good. So where else do we go for bad security? So I asked around, and everyone said, you know what you should do? Does this look like they take security seriously?
37:22
Not ABBA, Sweden. So... That's not protection. Everyone said... Everyone said you should do Sweden. And Sweden made it really, really easy. Now, to kick me off, Niall sent me this.
37:40
Now, this is from IKEA in Norway, but it's IKEA, it's Swedish, so we're gonna have a go at them anyway. And they sent this form when you want a new kitchen, and they made it really, really easy for you to fill out these three things which I'm told are a username and an email address and a password. And the irony of it is, we're also worried about things like HTTPS and SSL
38:00
and making sure we get our transport layer right. And these guys go, just write it down and hand it to the minimum wage guy at the desk. He'll fill it out for you. Now, how many of these have the password of the person's Gmail account? Because I've reused it across everything. And they've got the Gmail account in the e-post. Is that email, e-post? Okay.
38:20
Right, so, very bad. So, thank you, Niall, for that, and for reconfirming the fact that clearly Sweden has issues. So, because Sweden has issues, I thought we should do this. I take it this pleases people. Are they that bad?
38:40
I mean, it's not like the New Zealanders are anything, are they? Ooh. There's a New Zealander in the audience. All right, so here's what we're gonna do. First one we're gonna do is Swedish websites via FTP. Now, in order to do this, we're gonna need a web browser, two Google searches, and an Allen key.
39:08
Now, do not use the left-handed Allen keys. Do get a proper right-handed Allen key. Okay. Now, let's be serious and hack some Swedish websites.
39:21
So, here's what we're gonna do. Swedish website. Now, what we're gonna do is just a really simple Google search, and it's probably going to order completeness for me. So, we're going to do a search for, in URL, FTP. So, did you know that Google indexes things over FTP? It's true, they do. It's not just HTTP. We're going to look for web.configs in the URL.
39:43
Everyone know what a web.config is? It's the configuration file with all your secrets for your ASP.NET app. And just to be sure that we only get configs, we're gonna make sure the file type is config, and we're gonna do a search. And we've just found 7,390 websites that have exposed FTP. Exposed web.configs over FTP.
40:02
But that's no good, because we only want Swedish sites. So, let's filter that. So, let's go down to in URL. So, we make sure that we only get the Swedish ones. So, there is Swedish websites. Now, if it wasn't a recording, I could click on this. But, if you were to click on that, don't click on that, and if you did, it wasn't my fault. If you click on that, you will get web.configs
40:22
that probably have connection strings, usernames, passwords, database names. You'll probably get API keys. You could probably take web.config off the path, go back to the root, and find the folder called secret or private or things like that which you aren't meant to see, but because you've got anonymous FTP access, you can get it.
40:41
Probably find database backups. Probably find source control is often something that gets published, believe it or not. You can do just about anything. The other thing is, it's obviously anonymous FTP. Is it anonymous read-only or anonymous write? Possible defacement. I don't know. I don't click these things.
41:03
Way number one of Swedish websites. Way number two of Swedish websites. SQL injection. What are you going to need for this? One Google browser. One Google search. One havage. One allen key.
41:20
Everything in Sweden is an allen key. Now, who here has an understanding of SQL injection? Uh, quarter. Okay, roughly. So, let's do a bit of SQL injection 101. So, this is how SQL injection works. Now, let's imagine we have a URL that looks like this. Very common looking URL. Very semantic.
41:41
I would like product number three. We have two parts here. We have a resource, which is clearly the URL and the path. And then on the right hand side, we have the query string. That inevitably translates down to a SQL statement that looks something like this. And we have two parts again. So, we have the query and we have the parameter.
42:03
Pretty basic how to build a web app 101. Now, the thing about this is that everything on the left hand side is trusted. It's trusted in so far as we built it, we own it, we run it, we support it. It's in our system. Everything on the right hand side is untrusted.
42:21
And when I say untrusted, I mean it is coming from an externality. From an external source. It's going to be a query string in this case. It could be form data, so post data. Okay, so we saw that earlier with Qantas. Untrusted form data. Could be request headers. The user agent is untrusted data. You can change the user agent and reissue the request.
42:43
So, what we're going to do is look for Swedish websites that we can SQL inject. So, let's go back to the browser. We'll do another Google search. And let's just drop down to SE like that. Now, there's a very common pattern that often indicates that you have a SQL injection risk.
43:04
If you have classic ASP, you probably have a SQL injection risk. If you saw my talk on Wednesday, we looked at Bell. And I said Bell was running classic ASP. Almost certainly they have a SQL injection risk. So, Bell obviously did because all their data got put on the paste bin.
43:20
And they had a big problem. But let's have a look at this guy. Bad taste records. It's all in English, but apparently it is Swedish. So, I reckon it's fair game. Alright, so we look at the URL. Now, we can add one character to this URL. And determine if there is a SQL injection risk. So, any guesses? If we had one character. Single quote.
43:41
Single quote might do it. I'm going to go with one that I know works. I'm just going to put one character. It's not hacking if it's only one character. Okay. So, what are we seeing here? We are seeing one character. We are seeing one character which has caused an internal exception.
44:01
The internal exception has bubbled up as a Microsoft OLED provider exception. Somewhere under here we have MySQL which has tried to run a query that hasn't worked. And inevitably what's happened is it was expecting to get an integer as the value of ID. And then it would pull that and pull the record from the database. Now, we've changed that integer into a string.
44:22
So, effectively it's probably written a query that goes something like select star from bands where ID equals 3X2. So, MySQL has gone and done an equivalency of actually thinking that it needs to find another column. Called 3X2. And it's told us that there is no column. So, it's telling us that it's bubbling up internal exceptions.
44:42
Now, who has never mounted a SQL injection attack? What, everyone has? Come on. Who has never mounted a SQL injection? This gentleman here. Do you want to come up here? We don't do enough interactive stuff in these shows. What's your name? Jeff. Jeff. G'day, Jeff. Troy. Come over here, mate. All right. So, everyone, please note for the record, Jeff is now hacking.
45:07
No, don't go away. You are. But, just to be safe, we're not going to hack this website. Okay. We're going to hack another website. So, I've created another website over here called Supercar Showdown. Now, I created this for a Pluralsight course called Hack Yourself First. It's got about 50 vulnerabilities in it.
45:21
If you want to hack, go to hackyourselffirst.troyhunt.com and go nuts. After Jeff. Not before Jeff. Because otherwise, the demo is not going to be real good. All right. So, what we're going to do. So, you really are driving, Jeff. Do you want to just scroll down a little bit on the page? All right. So, we've got three different manufacturers here.
45:40
Just click on the view link for one of those. So, pick one you like. Good choice. Now, we look at the URL. So, that is a suspicious looking URL. So, let's copy it. On the clipboard. Okay. Good. Now, we're going to open HAVAGE. So, see the little caret down on the taskbar?
46:02
Okay. Open that guy up. All right. Now, let's just maximize that. Because we're going to get a bit of data. If this all works. All right. Now, let's paste that into the target. Now, you can go and get HAVAGE for free from itsecteam.com. You've done this before. You know where to go.
46:20
Analyze. So, basically, what's going to happen here is HAVAGE is going away making HTTP requests to this website. And it's making them in such a way that it's trying to cause exceptions in the database so that when the exception is exposed, like we saw before with our Swedish mates, it's going to disclose information. And it's already told us that the database name
46:41
is HackYourselfFirst underscore DB. This is an Azure website with SQL Azure behind it. There's nothing wrong with Azure. It's just a crappy web app. Now, we know what the database is. But that's not good enough. Let's get the tables. So, go to the tables button. Okay. And let's click on get tables.
47:02
Very good. Okay. So, this is going away, making more and more and more HTTP requests. Okay. Now, what looks good, Jeff? What do we want, mate? We'll tell you what. Let's go down to user profile. Good choice.
47:21
All right. Now, let's get the columns. Okay. So, we're going to get the columns. It's always nice we can do this with a GUI, isn't it? All right. Now, what should we get? What data do we want, mate? Password. Yeah, password would be good. We're going to need something else, though, if we want to hack this. Let's get an email.
47:40
Good idea, Jeff. All right. Let's get the data. Round of applause for Jeff. Well done, mate. Look at that. Thanks, mate.
48:03
And that's how SQL injection is done. So, the other day, I was saying SQL injection is such a risk. And it's number one in the OWASP top ten. It's number one in just about every sort of risk assessment thing you see. The reason it's such a risk is that it is so easy to exploit. So, we did one Google search, first result. Clearly, we didn't go and hack that Swedish website exactly.
48:22
But I imagine if somebody was to hypothetically do this, they would get the same sort of data because it was so easy. And this is why you're seeing kids with mums who are pissed off taking them to court because they've just SQL injected some website. That's how it happens. Okay. Let's do one more.
48:41
All right. So, let's have a go at Swedish websites with insufficient SSL. Now, this is a really fun one. So, what are we going to need? We need one Google browser, one Wi-Fi pineapple. Okay. Okay. Now, here's what we're going to do. We're going to pick a site and we're going to pick a Swedish site
49:04
called expoessin.se. Let's have a look at the Swedish website. Now, I did go through and have a look at sort of the same Alexa top 50
49:21
or 100 or whatever it was Swedish websites in order to find one that would meet my needs. And this one, which is going to appear any moment now, is the one that I chose to use. It's number five in the Alexa top 100. Oh, man. Holy shit. Okay. Norway's off the hook.
49:43
Haven't seen that before. All right. Okay. So, this is a legitimate website. We're loading it. Real time. Does that say something funny that I don't understand? Okay. Now, we can log it in. Now, is this a secure login?
50:03
Why not? Ah, but, but, but. Let's inspect the form. Inspect element. Oh. Oh, oh, oh, oh, oh. Let's close Fiddler and reload this page.
50:22
Damn it. Let's try this again. Rewind. Let's log it in. Inspect this element. I hate it when demos fail. All righty. So, if we have a look at the form URL, it posts to HTTPS.
50:41
So, it's secure, right? Because when it posts to HTTPS, it's going to encrypt the credentials when they get sent to the server. All right? Yes, it is. No, really, it is. If we post this form, it will encrypt the credentials when they go to the server. Now, here's the interesting thing, though. When we load this page, it's not loaded securely,
51:01
which means that if you can get in the middle of the communication and you can manipulate the contents of the page, you can change what's going to happen here. And it begs the question, how do you get in the middle of the communication? And that's why I've got this little guy just here. So, I'm going to take this. This is the Wi-Fi pineapple.
51:21
This was in the instructions next to the LN key. So, this little guy is a wireless access point. And, in fact, it does a couple of things. So, it's a wireless access point that you can stand up just like any other wireless access point. And I have stood this wireless access point up and given it an SSID of free NSA Wi-Fi. Now, I'm guessing that there are a lot of people
51:41
who have seen free Wi-Fi and not seen NSA and gone, okay, let's jump onto it. The other thing it can do, though, is it has a little feature where it can look for what we call probe requests from your devices. Now, what a probe request is, is when you connect to a known network and you say, remember this, so that when I come home later on,
52:01
I automatically connect to the network, what's happening is your phone walks around continually blasting out probing for that network. Now, what it means is is that the pineapple can see that and it can turn around, it can change its SSID to the one that you're looking for. And then your phone says, well, let's get it on and we'll connect and we're all good
52:22
if there's no encryption on that network. So, what I can do now is I can go to the Wi-Fi pineapple interface and this is a nice, hacking tools are getting so good because they've got GUIs and it's all friendly and no green screens. And if we still have a connection, we can go into Karma, which is hopefully going to load the data
52:40
from our Wi-Fi pineapple, which it is not. While I'm doing this, anyone in this vicinity, have a look at your network and see if you are seeing networks that you know, which would be the really, really interesting thing, or free NSA Wi-Fi.
53:02
Oh, there we go, it's back. Now, one of the problems is when I do this at geek conferences and there are so many freaking Wi-Fi devices, the whole thing, it's loading, honestly. The whole thing just gets a little bit overwhelmed. So, let's see if we can go into the Karma log. Otherwise, you know what, it's working,
53:20
but there is so much data in here. Let's try and remove the duplicates. Let's try and apply the filter. It is massive. So, what I'm going to do is I'm going to try and grab one of my shortcuts. I've got all my secret demo bits
53:42
and I'm going to try and grab the log path. So, basically, it's just building up a file on the system with all the log data. And I don't think it's actually going to load, but what we normally see is all the network names that are being probed for. So, I can actually give you an example from my room earlier on because I ran a little demo of this
54:01
just to make sure everything would work and I took pineapple images. And this is the sort of thing that we normally see. So, this was in my room and what we're seeing here is my iPad and my iPhone and we can actually see that my iPad, I deliberately connected through to free NSA Wi-Fi because I wanted to test it. Often I see a lot of other people connect to free NSA Wi-Fi
54:20
because they want free Wi-Fi. My iPhone connected to an SSID called Radisson Guest. This is not Radisson Guest, but because my iPhone was saying, where is Radisson Guest, which is an open network, the pineapple responded. Now, I don't know who Amy is. Maybe I should have removed her name. But Amy's iPad connected to GitHub Secret.
54:41
So, she was probably near me. So, sorry, Amy, if you're in the room. And GitHub calling it Secret doesn't make it so. So, it actually broadcast that name back out. Now, if anyone is actually connected to the device and they're just simply overwhelming things, what's happening is you connect it to the device and then it routes the traffic through the ethernet cable into this machine and then out over the normal Wi-Fi.
55:02
So, effectively, this machine and the pineapple can man in the middle of the connection. Now, if I try this again, I'm just going to open Fiddler because I can replicate the behaviour when I have Fiddler open. If I try this again and we reload this page this time, C is the little bit that I was hiding just before.
55:22
And we're going to get, if we go back to the form, and we go into here and we inspect the element. And we go to here. Okay, so, we're seeing a different URL here. Okay, we're posting to a different URL. Now, the way the pineapple does it
55:40
is that you load this form and effectively your device is now through this malicious network. And this form makes a request for a JavaScript file from an HTTP address. And because it's an HTTP address and it's not a secure connection, we can do things to it. We can do things like, instead of actually returning the JavaScript file from that source,
56:00
I can serve one up from the pineapple. So, the pineapple, with its little built-in web server, has served up its own JavaScript file and that JavaScript file has rewritten the DOM. And that's why we're seeing that this now posts to a different URL. So, if I go in here... What's a good Swedish name? Sven?
56:21
I like here. Book, book. And I fill in other details and I submit it. And the internet works, hopefully. Of course, we know where it's going to go. And the point is, is that we can actually redirect where that form posts to
56:42
because the form was loaded in securely. And now that is actually going to post to the same website. It should look like that. Yay! All right, so what normally happens is this page loads, the email address is there, the password's there because we've changed the form action. So, we've actually sent it off to another URL.
57:02
Now, the point of all this is that it comes back to any part of the connection which is not secure can be compromised. It can't just be read. It can be manipulated. So, what that means for login forms is you've got to load the login form over HTTPS. If ever you see a login form and you don't see a padlock, and I showed one a couple of days ago for GoDaddy,
57:21
login form, no padlock, the connection can be compromised. And we've seen this happen in cases before. We've seen things like the Tunisian government compromising people's connections when Facebook was loaded over HTTP for the login page. So, ultimately, that's what anyone with a compromised device should be seeing. There are too many of you who have overcompromised my pineapple.
57:42
But you should hopefully still see those SSIDs there. And that was the slide which should have gone first. Home is where your Wi-Fi connects automatically. That is the risk of open Wi-Fi and that is the risk of not having HTTPS in your connection. And with that, I'm done. Thank you.
58:10
So, I think we've got a few minutes for questions. If anyone has any questions? Any questions at all? There's one over there, mate.
58:22
So, the problem with the salting and the hashing is it's just one round of SHA-1. And, effectively, the problem is that it's too fast. So, in the newer versions of the membership provider, you've got 1,000 rounds. So, it is now 1,000 times slower to do the same thing. And a lot of people say that's not fast enough or rather that's not slow enough as well.
58:40
It should be 5,000 or 10,000. So, really, the lesson there is don't use the old membership provider. Use the current one and preferably use something even stronger again. Other questions? Over there. Sorry? What is something stronger again? What is something stronger again? So, first of all, from an algorithm perspective,
59:01
there are things like bcrypt or script. The other option is to increase the iteration. So, instead of 1,000 rounds of SHA-256, I think it is, to increase it, which, unfortunately, you can't do in a configurable way in ASP.NET. But you can go and look at things like Brock Allen's membership provider reboot, which give you more configurability.
59:21
There are a few others out there as well that allow you to effectively increase the workload of hashing a password, because that's what you want to do. You don't want it to be too fast. Otherwise, stuff like that happens. Anyone else? Over there?
59:48
It could. I guess the issue there, so the question was, can the browser be a little bit smarter and actually tell you where it's going to send the credentials to? The problem is, I guess, from a consumer perspective, how are they going to deal with that, particularly when you just see...
01:00:00
URL somewhere, you know, do you want mum and dad saying it's going to go off to blah blah blah blah secure dot so on and so forth. It's probably a little bit tricky usability wise. The other thing is in the Facebook example I gave before, when they compromised the login page, they still posted to Facebook but they made an asynchronous parallel request
01:00:20
sending their credentials off to another URL. So the post path was still correct but it was still stealing passwords. Noel? Yeah but it doesn't, so Noel's saying doesn't it tell you if you're going to post credentials
01:00:41
to an insecure path. But it's still posting to a secure path. Yeah well so there's the other issue, if you give people security prompts saying do you want to do this or not, they always say yes. It's hard to give people security prompts and have them make informed decisions.
01:01:03
Anyone else? Alright well thank you very much everyone.