We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Getting SSLizzard

00:00
subtitles
off
playback rate
1
subtitles
off
English (auto-generated)
playback rate
0.25
0.5
0.75
1
1.25
1.5
1.75
2
quality
576p
7
 Cite
 Share
 Related Material
 Download Purchase
No logo availableDEF CON
 Percoco, Nicholas J. Kehrer, Paul

Formal Metadata

Title
Getting SSLizzard
Title of Series
Number of Parts
122
Author
License
CC Attribution 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 purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
The world has seen a seismic shift from browser-based web applications to GUI-rich semi-thick client applications running on handheld mobile devices. In the browser world, the industry had placed a great deal of time and energy towards providing users visual cues to indicate the level security and trust that their data being transmitted to the remote server is protected and not falling into the hands of unintended recipients. In the mobile device world, these visual cues are mostly nonexistent, resulting in the inherent trust that the underlying APIs are ensuring a level of security before transmitting a users sensitive data. In our research, we tested the most popular apps on both the iOS and Android platforms. We ran each app through a data transmission assault course that contained various historic, contemporary, and obscure SSL attacks and documented the results. In this presentation, we will discuss and demonstrate flaws at both the application an OS layer that need to be addressed by both the mobile app developers and well the mobile device manufactures. A utility called "SSLizzard" will also be released for use by mobile application developers to test their mobile apps and their behavior against SSL-based attacks discussed in this talk. Nicholas J. Percoco: With more than 14 years of information security experience, Percoco is the lead security advisor to many of Trustwaveps premier clients and assists them in making strategic decisions around security compliance regimes. He leads the SpiderLabs team that has performed more than 1000 computer incident response and forensic investigations globally, run thousands of penetration and application security tests for clients, and conducted security research to improve Trustwave's products. Percoco and his research has been featured by many news organizations including: The Washington Post, eWeek, PC World, CNET, Wired, Hakin9, Network World, Dark Reading, Fox News, USA Today, Forbes, Computerworld, CSO Magazine, CNN, The Times of London, NPR and The Wall Street Journal. Paul Kehrer is a web developer and programmer at Trustwave with extensive experience with X.509 and PKI, including writing and maintaining a registration authority. Since 2007, Paul has lead the team responsible for the design and infrastructure of Trustwave's Certification Authority. Paul enjoys baking cakes in his spare time.
00:00
Source codeMobile WebData transmissionComponent-based software engineeringSoftware testingDisk read-and-write headInformationWaveInformation securityExplosionSoftware developerGame theoryAuthorizationMobile appInformation securityGame theoryBitData storage deviceDisk read-and-write headInformationSoftware developerResultantSoftware testingTraffic reportingMobile WebMultiplication signXMLComputer animation
01:22
Mobile WebAndroid (robot)Computer networkInternetworkingUniform resource locatorWeb browserPresentation of a groupInformation securityTime evolutionSoftware testingStress (mechanics)NetscapeNetwork socketPublic key certificateServer (computing)Client (computing)Communications protocolData transmissionSymmetric matrixKey (cryptography)AnalogyTelecommunicationIdentity managementAuthenticationData integrityCodeData managementSoftware frameworkLocal area networkSuite (music)Proxy serverChainError messageMessage passingStandard deviationPersonal digital assistantChainPublic key certificateCodeTelebankingSoftware testingKeyboard shortcutSoftware frameworkAbstract Syntax Notation OneQuicksortLocal area networkDifferent (Kate Ryan album)Data loggerMetropolitan area networkBitSymmetric-key algorithmServer (computing)Connectivity (graph theory)Social engineering (security)Web browserTransport Layer SecurityProxy serverConnected spaceEvoluteUniform resource locatorCartesian coordinate systemFacebookInternetworkingLatent heatPlastikkarteParsingData storage deviceType theoryFunctional (mathematics)Physical systemIntercept theoremMobile appTouchscreenStandard deviationData transmissionExtension (kinesiology)CoroutineInteractive televisionValidity (statistics)Online helpCommunications protocolHydraulic jumpWebsiteGreen's functionoutputMobile WebSoftwarePlanningClient (computing)Source codeFile formatInformationSpacetimeLoginMultiplication signInformation securityINTEGRALData structureComputing platformProfil (magazine)Software developerTelecommunicationError messageMultiplicationRootDiagramInterior (topology)Similarity (geometry)Identity managementPoint (geometry)Front and back endsSign (mathematics)WeightPrice indexNetscapeComputer fileMoment (mathematics)Presentation of a groupPublic-key cryptographyPerspective (visual)Utility softwareMessage passingLibrary (computing)Stress (mechanics)NavigationComputer animation
11:16
Web browserMobile WebStandard deviationMobile appInformation securityFunction (mathematics)Software developerDependent and independent variablesWireless LANPhysical systemClient (computing)FirmwareRadon transformAndroid (robot)iPod touchComponent-based software engineeringData transmissionData structureCodierung <Programmierung>Constraint (mathematics)Type theoryTime domainModule (mathematics)Source codeSoftware frameworkSoftware testingDirectory serviceLine (geometry)Public key certificateElectric currentSoftware developerPublic key certificateSoftware testingFacebookConstraint (mathematics)Router (computing)Server (computing)CASE <Informatik>Library (computing)1 (number)Touch typingSpherical capStandard deviationFunctional (mathematics)Client (computing)Domain nameDifferent (Kate Ryan album)Google+Sign (mathematics)Control flowSource codeModule (mathematics)Mobile appAuthorizationField (computer science)CryptographyForm (programming)ProgrammschleifeMultiplicationAbstract Syntax Notation OneArithmetic meanError messageSoftwareResultantType theoryScripting languageElectric generatorLevel (video gaming)Key (cryptography)Internet service providerString (computer science)Physical systemFirmwareGastropod shellFunction (mathematics)FlagMetropolitan area networkWeb browserExtension (kinesiology)Price indexSet (mathematics)Demo (music)Mobile WebInformation securityRevision controlInternetworkingHookingCoroutineQuicksortValidity (statistics)Digital photographyMereologyRegular graphDependent and independent variablesLine (geometry)Uniform resource locatorLatent heatEncryptionGraphical user interfaceBitCuboidoutputData structurePresentation of a groupRoutingInformationQueue (abstract data type)PlastikkarteCodecPoint (geometry)Software development kitNetwork topologyAreaIdentifiabilityCartesian coordinate systemAuthenticationIntercept theoremInstance (computer science)Right angleParsingContext awarenessWebsiteMultiplication signOpen sourceCellular automatonChainRepresentation (politics)Fuzzy logicComputer animation
21:09
Public key certificateDirectory serviceNormal (geometry)Revision controlWeb pageCentralizer and normalizerTime domainNumberElectronic signatureAlgorithmValidity (statistics)InformationHypercubeConformal mapCoroutineSingle-precision floating-point formatComa BerenicesMobile appLibrary (computing)Spherical capDemo (music)Text editorCartesian coordinate systemKey (cryptography)Domain nameSoftware developerElectric generatorExpected valuePublic key certificate
22:08
Software testingData structureDirectory serviceLine (geometry)Public key certificateElectric currentFunction (mathematics)Normal (geometry)Error messageMessage passingFacebookOpen setClosed setAndroid (robot)Mobile WebSign (mathematics)Web browserPasswordInternetworkingUniform resource locatorSlide ruleComputing platformSource codeExploit (computer security)Web pageVolumenvisualisierungComputer-generated imageryClient (computing)Internet ExplorerVulnerability (computing)Computing platformVirtual machineConstraint (mathematics)Time domainServer (computing)TouchscreenError messageSoftware testingResultantMobile appView (database)Server (computing)SoftwareLibrary (computing)Entire functionComputing platformPublic key certificateBitSlide ruleKey (cryptography)Validity (statistics)TouchscreenOpen setLevel (video gaming)ChainWeb pageFlagConnected spaceTwitterComputer fileWebsiteFacebookType theorySign (mathematics)Client (computing)BlogMathematical analysisMetropolitan area networkVulnerability (computing)MultilaterationDomain nameForm (programming)Web 2.0Structural loadUniform resource locatorAbstract Syntax Notation OneWeb browserWeb crawlerComplete metric space1 (number)outputAndroid (robot)Constraint (mathematics)Latent heatInternet ExplorerVirtual machineInternet forumPerspective (visual)Parameter (computer programming)CASE <Informatik>Spherical capQuicksortTime travelComputer animation
29:04
TouchscreenSoftware testingSoftware testingComa BerenicesDot productComputer animationLecture/Conference
29:33
Degree (graph theory)Error messageInformation securityBlackboard systemQuicksort
30:12
Software testingTouchscreenTwitterComplete metric spaceMobile WebConstraint (mathematics)Web browserOpen setClosed setRevision controlSoftware developerWaveMobile appData transmissionServer (computing)outputMetropolitan area networkFlow separationRevision controlQuicksortData transmissionSoftware developerSoftware testingComputing platformTelebankingBlogAsynchronous Transfer ModeSinc functionPoint (geometry)Mobile appCodeLibrary (computing)Mobile WebInformation securitySoftware bugWeb browserType theorySoftwareConstraint (mathematics)Cartesian coordinate systemValidity (statistics)Right angleWeb crawlerResultantTwitterClient (computing)Complete metric spaceSingle-precision floating-point formatFacebookBitPerspective (visual)Absolute valueAndroid (robot)Process (computing)Frame problemAliasingMultiplication signComputer animation
Transcript: English(auto-generated)
00:00
For those of you who don't know, you guys are sitting in the Getting Slizzard talk. So just brief agenda here, where we're gonna take you through during this talk, go through some introductions about who we are, go through a little bit of a primer on SSL, talk about some mobile SSL user experiences, research motivations, research implications,
00:23
talk a little bit about a test lab that we built, I'm gonna introduce a tool for you guys, so the Slizzard tool, show you some of the results of us testing some of the mobile apps and the mobile devices, and then there's gonna be an audience participation. So real quick, who we are, I'm Nicholas Percoco,
00:41
I'm the head of the Spider Labs team at Trustwave, I started my Infosec career in the 90s, I'm doing penetration testing, this is my sixth DEF CON talk, I actually had two others this weekend, one was Mailer Freak Show on Friday, and then the Droid talk yesterday. I'm also the primary author of Trustwave's Global Security Report. And I'm Paul Cara, I'm the lead SSL developer
01:02
and the CA architect for Trustwave, and since I don't have a whole lot of other bio information I can put up here, so we decided to say, also a mobile game developer in my spare time, and also sometimes at work, if you're going to hosting con in the next few days, we're releasing a game there, so if we figure we'd hype it now, it went in the app store this morning. I promise it's not malicious.
01:25
So before we start, we have some audience participation at the end of this presentation, and so you're gonna be able to help us find a mobile SSL flaw. So what you'll need, so if you have a mobile device, actually you could have any type of device, it has internet connectivity, 3G, 4G, if you're on the Defcon network,
01:41
you can help us out. You have to have the ability to enter a URL in your mobile browser, and then you have to let the trust that we're not gonna be doing anything malicious to you. And then willingness to stand up if you're tested successful, so just to gauge the audience, how many people here are willing to help out? Who? Okay, great, cool, that's gonna be fun.
02:03
So let's jump into the introductions here. So what does this talk about? So basically, when we were talking about, Paul and I were discussing planning for this talk and planning for the research, really we're discussing the evolution of the security experience in mobile platforms. Obviously, when you have a large, giant screen, 27-inch screen in front of you,
02:21
there's a lot of things you can do from a security standpoint, or even security warnings, messages, and other things that you could present to users. But when you cram it down into a small, little device, the space is limited, and also the developers of the platforms tend to try to abstract some of the busy information that you may see on your desktop platforms,
02:41
or you wanna see on your desktop platforms from your device itself. We're also gonna talk a little bit about some different types of SSL attacks, the lack of testing tools, testing's available for mobile applications, specifically for mobile app developers. We're also gonna talk about how various apps and devices perform under SSL stress,
03:00
and so we did take some popular apps, ran them through some tests, and we're gonna present how those actually reacted. And then we're gonna release a tool to help solve this problem. So very briefly, just whenever I give talks, I always wanna make sure to start with a primer, because about 11 years ago,
03:21
I sat in the audience at DEF CON and saw plenty of talks, and sometimes when I was staring at the presenter, I was thinking, I have no idea what this guy's talking about. So I wanna just bring everybody up to speed, and there could be some people in the audience who maybe aren't familiar with SSL. So basically, SSL stands for Secure Socket Layer. It uses certificates, digital files,
03:42
which are certificates defined by the X.509 specification. It was actually developed by Netscape back in 1994, and it was implemented in Netscape Navigator 1.0. My personal history, I remember when Netscape Navigator 1.0 was released, I was sitting in my dorm room, and the day it was released, I think it was probably a couple of hours
04:00
after it was released, I went to a Netscape store and actually bought a T-shirt with a credit card. It was my first experience with SSL and sending a secure transmission across the internet using that technology. It's a protocol typically used to secure client to server communication, data specifically. Most of you in this room interact with it every single day.
04:21
If you do anything online, logging into sites, if you're using mobile devices and you're logging into your online banking account, wherever you may be doing, most people have interaction with it. Some people may not be aware they're interacting with it. And then it uses, from a key standpoint, it uses asymmetric keys, basically public and private keys,
04:41
to establish a symmetric key to establish the secure transmission. So where is SSL used, specifically certs? We talked about to establish secure client to server communication. It also is used to establish identity as well. So when you visit a website,
05:01
that a popular financial institution, you often will see sometimes even something like an extended validation indications, like the green bar, that'll establish that you are in fact, or you hopefully are in fact, connecting to that website that you think you're going to. Also used in app signing, so the same technology used to sign applications,
05:22
specifically in the mobile world as well. And then log file integrity. Lots of times you could actually sign, there are tools out there that will sign your logs to ensure the integrity of those logs they haven't been tampered with after the fact. And then very similar in the mobile world, used for communication or public networks. It's actually pretty important
05:40
for security communication or public networks, because we're all roaming around, walking around at conferences, walking down the street, using our phones from untrusted networks, such as coffee shops and places like that. And when you submit data that you don't want anybody else to see, you want to submit, you want to send it over the public internet, or even public local networks in an encrypted format.
06:01
So it establishes app to server communication. It's also used in app code signing, like we already talked about. And then it's also used in mobile device profiles. So if you work for a corporate, you work for a company and they push down profiles to your iOS device, they'll actually sign those using SSL.
06:22
So a little bit of a sort of cartoon drawing about what man in the middle is, and this is where it's gonna dive a little deeper into our talk. Basically, we want to describe what is a man in the middle attack? And so you can see that diagram at the bottom, very, very cartoon-like, but the bad guy sitting in the middle there, of the diagram, the you or the end user is sitting over on the left-hand side of the screen,
06:42
and that's your mobile device. You're actually, he's injected into your network somewhere. So it may be on your local WAN, could be somewhere in the path between you and the place you want to visit, the legitimate place you want to go. And so basically you establish your connection with the attacker, and the attacker then establishes a legitimate connection
07:03
to the backend server. So then when that happens, the attacker is able to then intercept the data that you're sending, but also possibly modify that as well. So what tools actually exist to help with man in the middle attacks? There are quite a few. We've got a thicknet,
07:20
which is a man in the middle framework developed by Steve Asepik, who is a member of the Trustwave Spider Labs team. It's written in Perl and is a modular system that allows you to add extra functionality to it after you've set up your initial man in the middle. There's Ettercap, which is kind of the gold standard tool that everybody's familiar with, although it hasn't been developed in quite some time. It's still a very solid and very useful tool
07:42
for doing this sort of thing. You can also use more basic tools like ARP spoof that will just spoof ARP, exactly what it sounds like, to cause packets to be redirected to you, and then you can use other tools to parse and, excuse me, intercept and modify those packets,
08:01
specifically things such as SSL strip or SSL sniff. And then there's also things like man in the middle proxy which is just an SSL capable and intercepting HTTP proxy. So why is true SSL man in the middle difficult? Well, SSL certificates have what's called a chain of trust. The X.509 spec was based around the concept
08:22
that you have roots, or sometimes they're called trust anchors. Those roots are present in the certificate store of the device or application that you're attempting to use. So for example, you connect to Facebook.com using your web browser. Your web browser is now chaining,
08:40
it obtains the SSL certificate and any intermediate certificates in the initial handshake, and then it uses its own internal methods to try and find a chain of trust up to a root CA that it's already familiar with. So you can't just go and sign your own certificate because it's not in there. And if you add it to your own, it's not in anybody else's.
09:02
And the reason for that is, of course, that, well, we don't want you to be able to create www.facebook.com or api.facebook.com or any of those other certificates because why should you be the authoritative source for that? Now there are certain other ways of trying to develop more distributed networks of trust,
09:20
but for the moment, X.509 is based upon the concept that there are trust anchors. So now that we've established that you need a public CA for that, you now need to find some way to attack a public CA. Now as proven in the past by Moxie and others, you can attack public CAs. However, it's typically not particularly practical. You need to take,
09:41
you need to focus on one specific one. You may need to spend quite a bit of time, and you may not be successful in the first place. Social engineering usually plays a fairly large component in it rather than technical flaw. So then you may want to generate malformed certs. Well, the tooling around generating certificates is pretty streamlined these days. And because the ASN1 spec,
10:01
which is what X.509 utilizes is so complex, they actually lock it down pretty heavily in almost all the tooling. It's so easy to go wrong. So you actually have to go down and play down in the libSSL, OpenSSL layers, or use something like the Ruby OpenSSL bindings to be able to generate malformed ASN1 structures. So that's usually an obstacle
10:20
for people who aren't familiar with that type of code. And then SSL parsing zero days are difficult to come by. As Moxie's demonstration of null character attacks worked, he managed to find both a flaw in the way CAs were validating certificates and a parsing error in the, in actual multiple different parsing engines,
10:43
because that flaw actually affected Firefox and the IE S-channel validation routines. So we'll talk a little bit about mobile SSL experience from a user perspective. So obviously there's no standard UI. If you have an Android device, you have an iOS device or webOS, whatever you have,
11:02
there's no real standard for letting the end user know that they've established a secure connection. So you've established an SSL connection. Most applications show nothing at all. Fire up your online banking app, and you just have to assume that maybe it's being sent over SSL,
11:20
but it could be being sent over in the clear. There's no indication from an end user's experience of the difference. In most cases, like I said, there's no UI at all. There's no lock that you see in a browser experience. It's just basically non-existent. There are things like that in some of the mobile browsers themselves,
11:41
but just because you see a lock there, you have no ability to drill down deeper and actually check in to the, check out the certificates that are being presented to you. And then of course there's cryptic warnings. As a part of our research, we were doing some of the testing, we noticed a lot of cryptic warnings. Some warnings just didn't even make sense for what was going on in the testing.
12:02
And then users don't know the difference. So everybody in this room, being security aware, would know the difference, but most end users wouldn't, and they wouldn't know if they established a connection or if they didn't. They wouldn't even know to look. And then the pop-up could be lying. And so there's the photo you see there,
12:20
the screenshot you see there was from an app that I actually went and downloaded. It's an app to find sort of boutique hotels when you travel around that are cheaper, but maybe a little nicer than chains. And so when I was using that app, I noticed there was a lock in the corner and it says secured by and it has trust click on it. You put your finger on that lock
12:40
and a pop-up box comes up that says secure booking powered by travel click and protected by 256 bit SSL encryption. So that could be just complete bullshit. You have no idea if that pop-up is lying. So the browser community has now spent almost two decades tweaking their UI behavior
13:00
when it comes to SSL. I mean, originally you had locks, padlocks in the corners and you've had padlocks move up next to the URL bar. You've had yellow, you've had green, you've had just white. You've had green locks that actually don't represent EV security. The point is that there is always presentation even if that presentation has been changing.
13:20
So there's ways for you to both look at and validate what you're seeing. However, the mobile device market in essence destroyed that within less than five years. It went from at least something to see you need to trust that something good is happening. When you open up your mobile app to connect to Google Plus or Facebook or whatever your social network is,
13:43
you just assume that it's using SSL. You have no way to tell. So that's obviously something of a problem and you can't expect to see, excuse me. So if SSL fails silently on that front, well, the world probably doesn't end but maybe your personal world does.
14:03
So some of the research motivations as well, most apps completely ignore the UI aspect of security. So that's something we wanted to look into like Paul already mentioned. But from the end user standpoint or even from a developer standpoint, you're a mobile app developer. There is a zero functionality difference
14:21
between sending data in the clear and sending data encrypted. So there's no real no motivation other than the protection of the data that's being sent for them to implement it. And so as an end user, you just have to trust that when you're sending some things like credentials or bank account information or credit card information via an app that the developer cares enough about you to actually establish that SSL session
14:42
and encrypt your data. And we also thought there wasn't really any tools, an easy set of tools for people to run their apps through these types of tests. And then also, when you find OS level problems, they cascade to all apps where they can cascade to all apps. So if there's an OS level SSL parsing problem,
15:03
it could affect every single app on a device, not just the ones that are used, not just one single app. And to be fair, that is true of desktop as well. But on the mobile side, much more so than the desktop side, people tend to use consistent APIs that go down to the OS hooks. So for example, on the desktop,
15:21
you could have several different libraries that are actually handling your SSL validation routines. If you're using Firefox, it uses its own, NSS specifically. And if you're using Safari or Chrome or Internet Explorer or whatever, then you're using S Channel or the OS level libraries for OS X. However, on the mobile side,
15:41
you're emphatically, unless you've chosen to go a route that very few do, you're using the OS level libraries for handling that. So whenever you're doing security research, there's always the implications of your research. And obviously, something that we talk about today could be used by someone to do something,
16:00
used to do bad things tomorrow. And basically, due to attackers really focusing on the mobile app world and the mobile device world, obviously, the results of our research can be used for, like I said, to do bad things. Specifically, if there's problems with SSL, they can be used for credential stealing, data interception, even response manipulation
16:21
back to the client application. But the other thing to think about is these types of attacks will go unnoticed, specifically if there's a lack of user awareness. Users aren't aware, even when they see error messages, if they just click through them, that's a problem as well.
16:40
And then, of course, the lack of UI queues within the apps compound that. So like what we talked about earlier, if the SSL fails and it fails silently, the users are just basically blindly submitting their data through the networks and being intercepted by attackers. So how do you actually build a test lab then?
17:01
Well, there's a lot of ways, obviously, but one of the simplest and cheapest ways is just go ahead and get yourself a cheap SOHO switch and router like a WRT54GL or something that typically you'd like it to be able to run a third-party firmware like Tomato or DDWRT. You're gonna want an attacker system. In our case, we went ahead and used Linux because it's much easier to compile
17:21
a lighter cap there than anywhere else. And we went ahead and also added a patch to it that we'll be discussing in a little bit. And then you need some victim clients. In our case, we have a Nexus S that was running, at the time, the latest version of Gingerbread and an iPod Touch fourth generation, which was running iOS 433.
17:42
So what types of search do you need then once you've got that all set up? You're gonna want ones that are valid for the target domain, of course, so you can validate that it works in the primary use case. You're also gonna want as many malformed SSL certificate types as you can come up with. Self-sign, which is a common one that many people deal with. CRLF, which is a carriage return line feed.
18:02
That's actually something that in the past various libraries have had trouble with. You feed a carriage return line feed inside the domain or wrapping domains and sometimes it will parse before or after the CRLF. Sometimes it'll just break and return true. Now that hasn't always been, it shouldn't be true now, but that doesn't mean it isn't.
18:22
Then the null prefix, which of course was one of Moxie's big ones recently, which we discussed earlier. Invalid ASN1 structures, where you can write fuzzers where you can say, I want to have various broken loops and misnested forms inside my ASN1 structures. And then broken encodings in general
18:42
where you can push UTF-8 into BMP strings and things like that because ASN1 has type identifiers, so you can play around with that. And then things like the basic constraints and key usage and extended key usage extensions. Every certificate has things encoded in it that tell the browser or the OS
19:02
what it should allow that cert to do. For instance, when you are using a regular server certificate, it has an extended key usage called server auth. And when you're using it for client authentication, it has one called client auth. And server auth certs can't be used for client auth and vice versa. And in the basic constraints extension, there's typically a field that says CA colon false,
19:23
which means it's not a CA, don't let anybody sign things. So then you would need a method, of course, to generate the above easily. So what we went ahead and did was wrote a Ruby script called Slizzard. It's an open source toolkit to easily generate multiple types of invalid certs for any given domain.
19:42
The output can then be used with Ettercap to run these attacks against your apps or others to see if these things are vulnerable. We've successfully tested with Ettercap, and we have a patch on the DEFCON 19 DVD that you can apply against any standard Ettercap 073-NG tree, which will allow you
20:02
to add a new flag, again, documented in the patch. But you pass dash X that allows you to pass any certificate in. Normally, Ettercap generates standard, excuse me, standard self-signed certificates on the fly. And since we want to be able to provide different forms of broken certificates,
20:20
we need you use the flag to supply them. There's also a thicknet module being developed by Steve Osepik. I believe that will be delayed a little bit, but. Yeah, Steve's doing a talk, I think, the next hour called Blinky Lights. And so when that talk got accepted, it delayed his man in the middle, or his thicknet module a little bit. But he's gonna put that out shortly after our talk.
20:41
And this setup can be used against any OS application, browser, anything. I mean, as long as it's connected to the network that you've developed, you can man in the middle it. So to use it, all you have to do is run it. You can either specify it on the command line, or it'll have an interactive shell
21:01
for specifying as well. And I guess we can do the demo. Yeah. Yeah. And the real motivation here was to develop this toolkit so that app developers, specifically app developers that may be using their own libraries to, their own routines to validate SSL in their applications.
21:21
And this will be a surprisingly short demo, since it does exactly what you'd expect. Specify the main you want it to generate certificates for, and they are generated. So now we can say, let's take a look at one. Let's go ahead and look at the null character attack one.
21:40
So as you can see, it generated for domain.com with a null character. OpenSSL is actually capable of detecting and reparsing null characters such that you can see it. But in certain other tools, you may not see the null character, because it's a null character and unprintable. But that's the kind of thing we're going ahead and generating.
22:00
And then you have a single key that corresponds to all these certificates. And in the, and in the Ettercap, and so once you apply the patch, you actually can specify the certs to use for your test. As you can see there. So you'll go ahead and execute it, generate your certs, set up Ettercap using the dash x flag
22:20
to specify the cert type you want to test. And then you'll use your app as normal and see if you get error messages. If you don't get errors, then you should check Ettercap, which you can tell it, you can either have it outputting data to the screen, or you can have it writing to a pcap file for later analysis using something like Wireshark. That'll let you see if the data was intercepted as you expected. You'll have to execute Ettercap once per cert type
22:42
generated by Slizzard to comprehensively test it. We don't allow dynamic switching at the moment, although we have been looking into improving the patch. So now we're gonna talk a little bit about the mobile app test results. So like we've mentioned earlier about setting up the test lab,
23:01
we actually set up the test lab, we had the various devices, and then we proceeded to basically man in the middle each of those devices and some popular apps. And so, you know. Sure. So on Android, as you can see, in a lot of ways we didn't find a whole lot. We ran through several hundred tests actually
23:21
across the ASN1 fuzzers and various other ones. And you can see that the self sign, CRLF, null character, and ASN1s all fail closed. In the browser you get what you'd expect, which is the invalid certificate notification, in which in Android you can also actually click the view certificate and see a little bit of the details.
23:41
You can't see why the chain might not be working, but you can see the end entity certificate itself. Some of the more interesting things around it were that when you do these types of attacks, some of the underlying OS libraries are getting upset because the Facebook app will, for example, completely stop responding. Quitting it, reopening it doesn't seem to help. You actually have to reboot the entire phone sometimes.
24:02
However, and then there's the other thing we'll get, was confusing error messages. None of them said bad SSL certificate. They would say things like no network connection or server busy or basically fallback error messages that just assumed that there couldn't be a problem
24:20
with the SSL cert, it was something else. So that was always, that was a little bit of an interesting revelation for us. So we also tested iOS and based on the same exact fashion. And so I mean, it gets the big takeaway here. You can see the same keys. If you can't really see it from the back of the room,
24:41
on the key basically, FC, the green FC means it failed close, it did what it should. UR means user request. So basically something popped up and asked the user to do something and failed open. So obviously this was a little bit disappointing at this stage in the research that we didn't find anything, but there was also some confusing error messages as well that we noted.
25:00
And then one thing to note, Twitter, the Twitter client, actually had very nice accurate error messages. I think all those apps that we tested, was the only one that actually accurately displayed what the issue was, that was being presented to the end user. So now we're gonna crowd, you have a question?
25:24
Oh yeah, sorry. So that's interesting. Thanks for pointing that out. Yeah, so basically once you, when you went to the signup screen using the Facebook app we noticed that all data was being transmitted over HTTP. Yeah, it takes you to a custom web view,
25:42
which just loads the m.facebook.com page, which is not over SSL and everything including the signup form posts over HTTP for some reason. Yeah, the app does that whether or not you're man in the middle again. That was just a little side thing we found.
26:03
So now we're gonna do the audience participation. So what are we going to do? We're gonna test for a specific SSL flaw by audience members. So we need as many people as possible to test this, so hopefully we'll find some vulnerable devices out there. You're gonna be shown a URL on the next slide. If you see a certificate error,
26:20
when you visit that, don't do anything. We don't need to know that you got that error. But if you see a Spider Labs logo and we'll show you what that looks like, we'd like you to stand up. So what we're not going to do, we're not pushing anything malicious to your device. See, I guess you have to trust us with that. And we're not exploiting any known
26:41
or unknown browser flaws. So this is an SSL negotiation test. That's specifically what it is. And in fact, we don't actually even have any JavaScript on that page. It's pure CSS and HTML. So a little bit about what we're gonna test. So basically, if you take the Wayback machine, you jump in the time machine,
27:00
go back to 2002, Moxie actually published a serious Microsoft Internet Explorer vulnerability. It was basically related to SSL validation checking. Yeah, I mean, this flaw happens when a client fails to validate the signer as a valid CA. It allows a SSL negotiation to occur incomplete because from its perspective, it found a chain.
27:20
So chains are actually, again, unrelated to whether or not the cert is allowed to be a signing CA. That's all in the basic constraints parameter. So if something fails to check that it should or should not be capable of signing, and it's just assumed to be capable of signing, that you could sign a certificate underneath your own personal website for some other website
27:41
and then just pass that as an intermediate and it will validate. So that was what Moxie found at the time. Yeah, so we take this to the present day. If we have a device or we found a device during our research that this was successful, it's basically complete SSL failure. So basically, SSL man in the mill, completely possible, whether a device or an app is operating
28:00
on a public network. So today at DEFCON 19, we're gonna go through and actually see if this exists on any mobile platforms in the audience. So do you wanna explain what we did to set this up? So what we did is we requested a cert from a public CA for a meaningless domain, and specifically in this case, we used a cert that I personally have for my own blog.
28:21
Then we used that certificate in Slizzard to generate and sign a new certificate in private key just underneath it. So basically, we treated that end entity certificate as a sub CA. And then we installed the resulting certificate and key on test server and passed the meaningless domain cert as the intermediate. So the correct vertevior when visiting this test server
28:42
is a certificate error. It just shouldn't work. So let's do the test. So everybody in the room, if you can visit ssltest.spiderlabs.com, and then if you see this logo on your screen without having to click through anything, please stand up.
29:00
And you wanna do it as well with the audience? Sure, so I'll go ahead and just take a look at it myself here. Oh, sure, sorry about that, guys. Sorry, it is ssltest.spiderlabs.com.
29:20
So if you see the logo, please stand up. Okay, so you wanna do it as well to show what the audience looks like? Sure, everybody's got it here. Keep standing.
29:44
So this is what you should see if you are vulnerable to this attack. You should not see a security warning at all. Yeah, if you see a security warning, that means your phone is not vulnerable to this attack.
30:01
It's not working at all? You get the error on the blackboard. Yeah, that's good, but you should. Okay, let's go back into the. So we'll explain a little more here, so sort of the problem here. So thanks, everybody. I guess you can sit back down. Wait, actually, one question while you're standing up.
30:20
Does anybody not using an iOS device? Who did get man in the middle? We have someone back there. Okay, if you can see us after the talk. We'd love to talk to you. Yeah, so actually, yeah. So what is your device, sir?
30:42
That runs iOS. Thank you though. Oh, we have one here. Oh. Interesting. Yeah, if you could see us after the talk, that would be great. There's a Samsung Rogue, he said. Yeah. That is an Android device.
31:01
Yeah, so let's, well, if you could see us after our talk, we'd be interested to talk to you. So basically, anybody using anything less than iOS 4.3.5, so if people are aware, Apple just pushed out a patch about a week ago, nine days ago, that specifically addressed this issue.
31:21
Yeah, and it's just for those of you who might be on Verizon, it's 4.2.10 is the patch version that fixes it. And this patch was solely pushed out to fix only this bug. There were no other fixes out there because of the severity of the issue. Yeah, from the timeframe, Apple did a great job. It was 10 days after we reported this problem to Apple that they actually patched and pushed out the newest release.
31:42
So what we show here in the results here, so the basic constraints test, browser, Facebook, Mint, Foursquare, and Twitter all failed to open. And so what that means is that we were able to establish complete man-in-the-middle via SSL and intercept all the traffic that was being sent from the client device to the server.
32:01
And then a little side note here, we estimate the iOS user's exposure. So the people who stood up are still exposed and are still vulnerable to this attack. Basically, it was about 18 months, everything since at least 3.1.3. And since Apple tends to end of life after about two years, each iPhone, they're no longer eligible
32:22
for updates, security otherwise. 3.1.3 was the last version for the original iPhone. 4.1 something was the last version available for the iPhone 3G. So only 3GS and iPhone 4 are actually eligible to not be vulnerable. So I guess a note to the people who were standing in this room.
32:40
All of you, whether you're on the DEFCON network or any place else, could be man-in-the-middle via this method and we probably recommend at this point you put your phone in airplane mode.
33:02
The Apple patch fixes the underlying library so it fixes it for browser and apps and everything else. So after our iOS disclosure, Moxie was pretty tickled about the fact that one of his bugs had come back around. And so he released an updated version of SSL sniff that will fingerprint and do this to any device
33:23
that you've got on your network. Eric Monty, one of our Trustwave spider labs guys, has developed a workaround for iOS developers who want their app to work on earlier versions and not rely on iOS to the validation checking. We're gonna be posting a blog post about that right after the talks for people who wanna incorporate this code snippet. We'd love more eyeballs on it because quite frankly
33:41
we're not sure why it works, but it does seem to. The one big implication there, so say you are a financial institution and you have online banking customers who are using a banking app from an iOS device, if those customers are not patched, that means that all the customers in your ecosystem that are not using this latest version
34:01
are now vulnerable. So iOS developers may want to implement this, or that banking application developer may wanna implement this to fix it retroactively in older devices. Right, and then just recently Hubert or Hubert or whatever his name might be, he's owned solely by this alias, released a tool called iSniff,
34:21
which also does SSL man in the middle, using iOS less than 435. So you can check that out on GitHub as well. So just to conclude here, the basic takeaway is that we need more eyes on this type of technology, on this testing.
34:40
So that's why we put together this toolkit for developers to be able to test their apps, test their devices, and to find these problems and fix them. But I guess from a user perspective, we all have to insist that SSL is used for all data transmission, but then we also need to also insist that the mobile device manufacturers, the mobile platform developers, fix their UI.
35:02
So it's more recognizable to us and other end users at what's going on from a secure data transmission standpoint. Apps and devices that should always fail close when there's an SSL problem. So in that regard, our testing has revealed that in general they try to do that, that's a big improvement over the past years.
35:21
And it's an encouraging note, I guess, but it results in a larger dependence on a single failure point, which hopefully people will continue to consistently test to make sure it doesn't have problems that have occurred in the past. And I guess the one final piece, the gentleman that actually had that Samsung device,
35:42
if you can meet us here, and when we were doing this talk, we knew that the iOS devices would be vulnerable because we released that advisory with Apple, and we were hoping that we might find another device. Obviously in our test lab, we didn't have hundreds of flavors of devices to play with and the gentleman with the Samsung device, if you can meet us,
36:01
we wanna find a little more details about that device and you may see an advisory come out very soon on that platform as well. So that's our talk. Thanks everybody. Thank you. Thank you. Thank you.