WEBVTT 00:01.910 --> 00:13.030 All right, so this is the worst mobile apps, and it's just a review of the last several years of my work auditing the security of mobile apps in a very simple way. 00:13.150 --> 00:24.390 So I'm a teacher at City College San Francisco, and I founded this company called InfoSec Decoded, and I do a lot of these classes, and I'm not very advanced. 00:24.390 --> 00:28.110 I do beginning classes and simple things. 00:28.110 --> 00:32.230 The really complicated stuff is usually beyond my classes. 00:32.850 --> 00:38.690 So mobile apps are a natural place to start because security is terrible. 00:38.690 --> 00:47.010 Mobile apps... finding vulnerabilities in mobile apps is like taking a time machine back to the early 90s when people didn't know anything about security. 00:47.170 --> 00:56.210 And so I did a lot of Android auditing because it's very easy on Android, and it was very difficult on iOS until check rain. 00:56.210 --> 01:02.590 So Android I did over the last several years, and iOS I've only done for about the last six months. 01:02.610 --> 01:09.190 And I discovered that it is true what I had heard, that iOS apps are just as bad as Android apps. 01:09.190 --> 01:23.810 Now the operating system is a little more secure, and the coding language is harder to reverse engineer because it really is executable code compiled from C instead of partially compiled from Java. 01:24.030 --> 01:40.010 But the end result is it's painfully obvious that the standards of most app developers are extremely low, and that the management does not review the security of apps they purchase from third-party developers, not even for the simplest flaws. 01:40.570 --> 01:45.950 So OWASP has a nice mobile top 10 showing the vulnerabilities here. 01:45.990 --> 01:54.910 And when I did Android apps, I typically found the ones marked 8 and 9 here, where you can easily see the source code and find vulnerabilities. 01:54.910 --> 02:05.390 That is not so easy to do on iOS, but the other ones are extremely common, like insecure data storage and insecure communication and insufficient cryptography. 02:05.390 --> 02:08.090 Those are all extremely common. 02:08.650 --> 02:13.670 So first, I'll just start with the headline, the worst apps I found. 02:14.710 --> 02:24.730 The worst app in the world is probably this one, because not only is it incredibly mind-bogglingly insecure, it's still in common use for an important purpose. 02:24.730 --> 02:34.330 This company, Equity Pandit, is apparently a widely respected company in India and even has passed some kind of certification for at least functionality. 02:34.350 --> 02:39.210 And their app has the worst API I've ever encountered that's still in use. 02:39.210 --> 02:48.930 If you go to their API, not only does it log you in with plain text transmission over the internet and then store your password in plain text locally. 02:48.990 --> 02:55.090 Beyond that, if you try to log in with an incorrect password, the logic is shown in the top here. 02:55.190 --> 03:01.250 It doesn't send your username and password to the server to authenticate you. 03:01.250 --> 03:12.010 It sends your email address to the server and then it sends the correct password down to the phone, and then it compares the password you typed to the password on the phone. 03:12.010 --> 03:14.130 And it puts both of them in a log. 03:14.130 --> 03:23.790 So at the top in that command line window, you see two passwords, capital P-S-S-W-0-R-D, and then one that's just a lot of A's and 2's. 03:23.790 --> 03:28.450 The A's and 2's are a wrong password I typed in, and it sends me the right password. 03:28.450 --> 03:36.670 So I gave my students homework to just steal my password from my account on their server, and anybody can get anybody's password at any time. 03:36.670 --> 03:43.470 And I told them years ago, and I've been giving it for homework and using it in classes all over the world, and they just don't care. 03:43.470 --> 03:46.610 That is amazing to me. 03:46.610 --> 03:55.130 That a company, especially a financial company, can just hand out all the passwords of everybody all the time, and nobody cares, but it's still going on. 03:55.830 --> 03:58.250 And this one here was almost as bad. 03:58.250 --> 04:01.690 The only thing better about it is they actually fixed it when I told them. 04:01.690 --> 04:06.630 The University of Houston had an alumni app, and so I installed it and played with it. 04:06.690 --> 04:12.530 And the first thing it does before you log in is it lets you search for yourself on the list of alumni. 04:12.830 --> 04:27.650 And when you do that, you'll see here in the top line, it sends a request with the first letter or two of a username up to the server, which is 326 bytes in the length column, and then the reply is 351 kilobytes. 04:27.770 --> 04:46.810 Every time anybody searches for a user in the app, before you log in, it downloads the entire database of every user, credit card numbers, account numbers, passwords, email addresses, down onto the phone, and it does all that with broken encryption. 04:47.030 --> 04:50.230 So you get, again, get exposure to the entire database. 04:50.230 --> 04:55.470 But when I told them, they actually took down the app and made a revised version that no longer has these flaws. 04:55.770 --> 05:05.570 But when I showed this to students, some of my students said this, in fact, is something they tell people to do, put everything on the phone so it will have fast response, even if the network is slow. 05:05.610 --> 05:08.590 But it is surprisingly bad. 05:08.590 --> 05:18.610 So not every app is that bad, but a large portion of apps, like 10 or 15 percent, make extremely elementary flaws so simple that I can catch them. 05:18.610 --> 05:21.870 So over the last several years, I've done a lot of Android apps. 05:21.930 --> 05:29.470 I started by doing the top 10 banks, insurance companies, and stockbrokers, and essentially all of them are vulnerable to code modification. 05:29.670 --> 05:44.130 So you can see the source code, you can modify the code, you can make a modified app and run it, and they don't detect that it's modified, and they don't detect that it's an unauthorized app when it connects to the server, both of which would be pretty easy to do, 05:44.130 --> 05:45.850 but they just don't bother. 05:46.610 --> 05:50.970 And some of them make other errors, like using insecure encryption and such. 05:51.050 --> 05:56.230 But the fundamental reason why this is so easy to do on Android is the language it's in. 05:56.230 --> 05:58.090 So here's TD Ameritrade. 05:58.090 --> 06:03.550 If you log in here, it will put the password in the log. 06:03.590 --> 06:09.050 This is in the syslog on the app, and in older versions of Android, this was visible to every app on the device. 06:09.050 --> 06:15.170 That's not true of later versions of Android, but still, it's not an appropriate place to put secrets like a password. 06:15.170 --> 06:20.370 In fact, a best practice is to turn off all logging in the distribution version of your app. 06:20.370 --> 06:24.730 Logging should only be there for your test versions in production. 06:25.270 --> 06:29.610 So Mayo Clinic Medical Transport has the other issue of hard-coded credentials. 06:29.610 --> 06:34.910 There's a password needed to see this app, and the producer makes half a dozen apps built the same way. 06:34.930 --> 06:37.150 And you can just see the source code. 06:37.150 --> 06:44.250 You can download the code from the phone and grep for the word password and just find the top secret password. 06:44.370 --> 06:46.830 And I notified him, and he told me to just get lost. 06:46.830 --> 06:48.270 My notifications are spam. 06:48.270 --> 06:49.710 I'm just irritating him. 06:49.710 --> 06:54.690 So I appreciate it when people give me a response like that, because that's volunteering to be homework. 06:54.690 --> 07:01.590 So anyway, another very common flaw in both Android and iOS is that they break TLS. 07:01.670 --> 07:09.470 They perform an HTTPS handshake, and then they don't verify the certificate with a trusted third-party provider. 07:09.470 --> 07:13.750 So you can give them a fake certificate, and they'll fall for it. 07:13.750 --> 07:19.650 This, in fact, has led to some punishments from the Federal Trade Commission to Fandango and Credit Karma. 07:19.710 --> 07:32.550 If you had some standard boilerplate statement in your terms of service that we take reasonable security measures, this behavior, breaking TLS, was considered insufficient to comply with that promise. 07:32.930 --> 07:37.810 So then I gave some talks before about password storage on the phone. 07:38.830 --> 07:45.830 An enormous number of apps remember who you are by storing your password locally on the phone, which is very strange. 07:45.830 --> 07:52.730 So Target Australia had an Android app that does the right thing, what websites would do. 07:52.730 --> 07:55.310 It puts a random cookie on your machine. 07:55.850 --> 08:04.550 But for some reason, a large number of web apps just store your password locally, which is a miserable thing to do, and that's what Staples does. 08:04.650 --> 08:10.930 It puts a thing called encrypted password on your phone, and that is a very strange thing to do. 08:11.250 --> 08:16.630 And in fact, you know, if you look at best practices, they say don't store a password on the phone at all. 08:16.630 --> 08:19.810 If you're going to do it, there's an Android keychain to put it in. 08:19.810 --> 08:22.470 There's public key encryption you could use. 08:22.630 --> 08:32.450 But what they almost all do, if they don't store it in plain text, is they store it with private key encryption, and then they try to hide the key on the phone. 08:32.450 --> 08:34.870 So you can easily detect the flaws here. 08:35.810 --> 08:43.090 Anyway, so it's easy to see that they're using... here you can tell they're using electronic codebook encryption. 08:43.090 --> 08:51.490 So if you give it a password that's 32 A's in a row, you get encrypted data with a repeating block shown in the lower middle here. 08:51.490 --> 09:00.270 And that shows that an identical block of input turns into an identical block of output, which is another very fundamental encryption error. 09:00.270 --> 09:09.630 So anyway, they construct the password by using things like the username, and the name of the app, and so on. 09:09.630 --> 09:12.790 And you can just read their source code and see how they build the password. 09:12.790 --> 09:20.670 Here they take the brand, device, model, serial number, and the name of the package, and combine that to construct the key. 09:20.670 --> 09:28.850 So I can easily write a reversing code that will extract the key from that so-called encrypted password. 09:28.990 --> 09:32.850 Anyway, so I notified Staples and made videos of them and all that. 09:33.170 --> 09:34.750 But that's the game. 09:34.750 --> 09:38.250 Their fix was to just detect a rooted device, which is something. 09:38.250 --> 09:40.010 It's a step in the right direction. 09:40.230 --> 09:46.350 Anyway, a lot of apps store local plain text, Ace Hardware, and McDonald's, and so on. 09:46.390 --> 09:49.590 They just store the password with no encryption at all on the phone. 09:49.890 --> 09:54.410 A bunch of them use plain text login with unencrypted traffic over the internet. 09:54.690 --> 09:56.610 And you can catch them here. 09:56.610 --> 09:59.230 And then a lot of them break SSL, as I mentioned. 09:59.230 --> 09:59.970 Here's one. 09:59.970 --> 10:03.490 I first found this, I was excited, thinking I'd found a flaw in Amazon. 10:03.490 --> 10:08.910 But this is just a flaw in a third-party app that tracks Amazon prices. 10:08.930 --> 10:15.530 So that's a review of work I've done years ago, showing the kind of problems you have with Android apps. 10:15.550 --> 10:18.530 And so let me skip over a few more of these. 10:18.530 --> 10:21.490 These are things I've talked about before. 10:21.690 --> 10:27.590 Many, many big companies do these common app mistakes. 10:27.590 --> 10:41.190 And I never really knew how bad it was on iOS, because since there wasn't a good jailbreak available for iOS, I couldn't really look inside the file system in a modern version of iOS and see what was happening. 10:41.230 --> 10:47.330 So I was gradually moving forward in the world of security and trying to move into more advanced things. 10:47.330 --> 10:49.790 And then I saw this talk by Joe McCrae. 10:49.790 --> 10:51.550 Joe McCrae is wonderful. 10:51.550 --> 10:53.450 He's doing the same thing I'm doing. 10:53.450 --> 10:57.650 He's trying to show that a relatively normal person can figure out how to do this. 10:57.650 --> 11:01.370 And he made this talk called Exploit Development for Mere Mortals. 11:01.370 --> 11:10.870 And I looked at that talk, and it was wonderful, because I thought exploit development was just mind-boggling and complicated, and I could never figure it out, and my students could never figure it out. 11:11.050 --> 11:13.730 And Joe convinced me that it's not that hard. 11:14.450 --> 11:21.490 He explains it in simple terms and shows you how to use the basic tools like OliDebug, and I said, well, maybe I could do it after all. 11:21.490 --> 11:35.890 And then Georgia Weidman wrote this book, and the book has a lot of introductory stuff, but it has an appendix where you would develop a simple buffer overflow exploit, and that was the first document that wrote I could do this in terms I could really follow, 11:35.890 --> 11:36.810 and it really worked. 11:36.810 --> 11:39.490 So then I was able to start teaching exploit development. 11:39.490 --> 11:47.950 So I wrote this class where we go through the shellcoder's handbook and we develop buffer overflow exploits and other things like format string exploits. 11:48.390 --> 12:01.150 And that was very exciting to me, and it attracted a bunch of new, more advanced students, people who had never been interested in taking college courses in ordinary ethical hacking, were drawn to this class. 12:01.230 --> 12:05.270 And in particular, this guy, Axiom X, came to the class. 12:05.270 --> 12:21.430 He had been a developer, and he'd never done hacking or attack before, but he heard about this class and came and took it, and so immediately he raced through everything I knew and everything in my book, and he rushed into iOS hacking, because he was a real expert on iOS, 12:21.430 --> 12:35.310 and he immediately found the checkring vulnerability, which makes almost up to, I think, two versions back now, made all these modern versions of iOS vulnerable, and it was a flaw in a hardware module that can't be updated without a replacement of the hardware. 12:35.310 --> 12:45.810 So suddenly, because of him and the team that joined him to make the checkring exploits, we could now get into the system of modern iPhones, and that was fun. 12:45.810 --> 12:48.810 So I immediately got a couple jailbroken phones. 12:48.810 --> 12:59.310 He loaned me a couple, and I, over the January and December, six months ago or seven months ago, I spent all my time auditing iPhone apps. 12:59.310 --> 13:03.970 I audited a few hundred iPhone apps, and I found all the same problems with iPhone apps. 13:03.970 --> 13:09.050 Here's the Blue Cross app, storing passwords locally on the phone without any encryption. 13:09.670 --> 13:18.210 Here's Blue Shield failing to validate TLS certificates, so it will just believe a fake certificate from a fake certificate provider. 13:18.610 --> 13:25.870 Here's West Point, transmitting passwords without no encryption at all, plain text over the internet, a West Point athletic app. 13:25.870 --> 13:28.650 Here's an Air Force app doing the same thing. 13:29.410 --> 13:35.410 Then there's Zillow, which stores a local copy of the passwords in a cache insecurely. 13:36.330 --> 13:48.370 Here's StockOptions, a stock app that breaks TLS encryption and stores things locally and sends plain text transmissions over the internet. 13:49.310 --> 14:05.310 And I was surprised by this one when I found these apps that send plain text data over the internet, because I thought that was not possible anymore, because I saw a news article saying years ago Apple has updated their application policy so you can't use insecure network transmissions. 14:05.310 --> 14:07.630 But I went and looked, and this is the article. 14:07.630 --> 14:12.510 There is this thing called app transport security, but you don't have to use it. 14:12.510 --> 14:19.070 You only get app transport security if you turn it on or if you are targeting recent versions of iOS. 14:19.070 --> 14:22.970 So older apps or apps that turn it off don't have it. 14:22.970 --> 14:29.330 So you can continue to have iPhone apps that send unencrypted sensitive data over the internet, which surprised me. 14:29.330 --> 14:36.390 I had believed that Apple was more secure than that, but it's not so, and it certainly is not so in practice. 14:36.670 --> 14:38.670 So then I tried other apps. 14:38.670 --> 14:44.790 I tried My City College app, and I found that the entire product line, about half of their products, were all insecure. 14:44.790 --> 14:49.650 They all used broken encryption, breaking TLS, and one of them uses no encryption at all. 14:49.650 --> 14:55.870 It appears that this company has swallowed up some other app companies, and they've inherited some products that are insecure. 14:55.870 --> 14:57.610 And I told them about this. 14:57.610 --> 15:01.210 All these vulnerabilities, by the way, I've disclosed many months ago. 15:01.370 --> 15:04.330 So I think they've been fixed if they're ever going to be fixed. 15:05.730 --> 15:09.490 And to be fair, I should say I've done a lot of vulnerability disclosure like this. 15:09.490 --> 15:19.930 This is white hatting, which is generally considered a waste of your time and an amateur move where you try to tell people about their problems when they have not come to you to ask for an audit. 15:20.030 --> 15:24.390 And it used to be that only 2% of them would ever fix it. 15:24.470 --> 15:26.790 And now it's up to maybe 10% of them fix it. 15:26.790 --> 15:31.130 And some of them even say thank you and promise to send me stuff and then never send me the stuff. 15:31.250 --> 15:36.150 But nobody tried to get me fired or start a lawsuit or anything this time. 15:36.150 --> 15:48.350 So I think the US government bug bounties have begun to raise awareness so that more companies don't just freak out and decide that you're a criminal when you report a vulnerability. 15:48.710 --> 15:53.090 And it's getting moving from 2% up to maybe 10% of them that actually care. 15:53.250 --> 15:58.050 Very few of them are actually ready to do anything about a vulnerability or fix it. 15:58.050 --> 16:05.170 But I think they're more it's becoming more common that they will at least admit that it is possible that they have a security flaw. 16:05.170 --> 16:09.010 And that in principle, they should do something about it instead of just shooting the messenger. 16:09.010 --> 16:11.390 So it's gradually improving. 16:12.110 --> 16:14.950 And I tried these chains of financial apps. 16:14.950 --> 16:16.750 I did a lot of bank apps. 16:16.750 --> 16:24.450 And I found this whole line of apps from Jack Henry that puts your password in the log, which is unsafe. 16:24.450 --> 16:26.490 And there's a whole series of banks using it. 16:26.550 --> 16:30.230 And then I found another financial app company. 16:30.450 --> 16:32.850 And again, they had the same thing, but a different structure. 16:32.850 --> 16:35.510 They also put your password in the log every time you logged in. 16:35.510 --> 16:41.670 So I notified their customers and the main provider that they needed to fix that. 16:41.670 --> 16:42.630 I don't know if they care. 16:42.630 --> 16:45.570 But I was surprised they have whole vulnerable product lines. 16:45.570 --> 16:51.910 And you would think at least that a developer that's making a whole product line would have some security auditing. 16:51.910 --> 16:53.690 But obviously, they don't. 16:53.690 --> 16:55.190 And their customers don't. 16:55.190 --> 16:57.770 So you can just sell broken junk forever. 16:57.770 --> 17:00.790 And nobody will catch you for a long time. 17:01.350 --> 17:06.310 So I've got a hacking mobile devices class where we've been doing this. 17:06.310 --> 17:09.370 And now we're moving into iOS in addition to Android. 17:09.370 --> 17:14.350 And I made a cryptography class trying to improve people's awareness of cryptography. 17:14.350 --> 17:18.290 So hopefully, they won't make so many fundamental cryptography mistakes. 17:19.050 --> 17:22.410 And you know, the basic bottom line here is nothing that exciting. 17:22.410 --> 17:23.790 You should be auditing your apps. 17:23.790 --> 17:26.790 You should have managers that ask the simple questions. 17:26.790 --> 17:28.670 And they don't have to be very technical. 17:28.670 --> 17:31.630 They need to say, did you collect data from the user? 17:31.730 --> 17:33.150 Where did you put it? 17:33.150 --> 17:34.310 Did you encrypt it? 17:34.310 --> 17:36.030 Where did you put the key? 17:36.050 --> 17:37.530 How did you transmit it? 17:37.530 --> 17:41.010 And you should have nice, simple, clear answers to those questions. 17:41.010 --> 17:46.030 And if you don't, then you shouldn't accept that app. 17:47.010 --> 17:48.890 So that's what I've got to tell you.