[00:01.910 --> 00:08.910] All right, so this is the worst mobile apps, and it's just a review of the last several years of [00:08.910 --> 00:15.190] my work auditing the security of mobile apps in a very simple way. So I'm a teacher at City College [00:15.190 --> 00:22.330] San Francisco, and I founded this company called InfoSec Decoded, and I do a lot of these classes, [00:22.330 --> 00:29.650] and I'm not very advanced. I do beginning classes and simple things. The really complicated stuff [00:29.650 --> 00:37.670] is usually beyond my classes. So mobile apps are a natural place to start because security [00:37.670 --> 00:42.810] is terrible. Mobile apps... finding vulnerabilities in mobile apps is like taking a time machine back [00:42.810 --> 00:49.190] to the early 90s when people didn't know anything about security. And so I did a lot of Android [00:49.190 --> 00:56.210] 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:14.790] Now the operating system is a little more secure, and the coding language is harder to reverse [01:14.790 --> 01:22.510] engineer because it really is executable code compiled from C instead of partially compiled [01:22.510 --> 01:29.170] from Java. But the end result is it's painfully obvious that the standards of most app developers [01:29.170 --> 01:36.150] are extremely low, and that the management does not review the security of apps they purchase [01:36.150 --> 01:43.550] from third-party developers, not even for the simplest flaws. So OWASP has a nice mobile top 10 [01:43.550 --> 01:49.290] showing the vulnerabilities here. And when I did Android apps, I typically found the ones [01:49.290 --> 01:55.490] marked 8 and 9 here, where you can easily see the source code and find vulnerabilities. That is not [01:55.490 --> 02:01.670] so easy to do on iOS, but the other ones are extremely common, like insecure data storage [02:01.670 --> 02:08.090] and insecure communication and insufficient cryptography. 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:19.870] The worst app in the world is probably this one, because not only is it incredibly [02:19.870 --> 02:25.930] mind-bogglingly insecure, it's still in common use for an important purpose. This company, Equity [02:25.930 --> 02:32.310] Pandit, is apparently a widely respected company in India and even has passed some kind of certification [02:32.310 --> 02:39.210] for at least functionality. And their app has the worst API I've ever encountered that's still in use. [02:39.210 --> 02:44.970] If you go to their API, not only does it log you in with plain text transmission over the internet [02:45.510 --> 02:50.930] and then store your password in plain text locally. Beyond that, if you try to log in [02:50.930 --> 02:58.430] with an incorrect password, the logic is shown in the top here. It doesn't send your username [02:58.430 --> 03:03.630] and password to the server to authenticate you. It sends your email address to the server and [03:03.630 --> 03:10.130] then it sends the correct password down to the phone, and then it compares the password you typed [03:10.130 --> 03:16.250] to the password on the phone. And it puts both of them in a log. So at the top in that command line [03:16.250 --> 03:23.790] 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:29.110] The A's and 2's are a wrong password I typed in, and it sends me the right password. So I gave my [03:29.110 --> 03:34.390] students homework to just steal my password from my account on their server, and anybody can get [03:34.390 --> 03:39.210] anybody's password at any time. And I told them years ago, and I've been giving it for homework [03:39.210 --> 03:46.610] and using it in classes all over the world, and they just don't care. That is amazing to me. [03:46.610 --> 03:51.110] That a company, especially a financial company, can just hand out all the passwords of everybody [03:51.110 --> 03:58.250] all the time, and nobody cares, but it's still going on. And this one here was almost as bad. [03:58.250 --> 04:02.770] The only thing better about it is they actually fixed it when I told them. The University of Houston [04:02.770 --> 04:08.590] had an alumni app, and so I installed it and played with it. And the first thing it does before you log [04:08.590 --> 04:14.630] in is it lets you search for yourself on the list of alumni. And when you do that, you'll see here [04:14.630 --> 04:20.750] in the top line, it sends a request with the first letter or two of a username up to the server, which [04:20.750 --> 04:29.050] is 326 bytes in the length column, and then the reply is 351 kilobytes. Every time anybody [04:29.050 --> 04:35.890] searches for a user in the app, before you log in, it downloads the entire database of every user, [04:35.890 --> 04:44.790] credit card numbers, account numbers, passwords, email addresses, down onto the phone, and it does [04:44.790 --> 04:50.730] all that with broken encryption. So you get, again, get exposure to the entire database. But when I [04:50.730 --> 04:54.670] told them, they actually took down the app and made a revised version that no longer has these [04:54.670 --> 05:00.150] flaws. But when I showed this to students, some of my students said this, in fact, is something they [05:00.150 --> 05:04.610] tell people to do, put everything on the phone so it will have fast response, even if the network [05:04.610 --> 05:13.310] is slow. But it is surprisingly bad. So not every app is that bad, but a large portion of apps, [05:13.310 --> 05:18.950] like 10 or 15 percent, make extremely elementary flaws so simple that I can catch them. So over [05:18.950 --> 05:23.870] the last several years, I've done a lot of Android apps. I started by doing the top 10 banks, [05:23.870 --> 05:28.210] insurance companies, and stockbrokers, and essentially all of them are vulnerable to [05:28.210 --> 05:33.530] code modification. So you can see the source code, you can modify the code, you can make a modified [05:33.530 --> 05:38.350] app and run it, and they don't detect that it's modified, and they don't detect that it's an [05:40.050 --> 05:44.130] unauthorized app when it connects to the server, both of which would be pretty easy to do, [05:44.130 --> 05:50.190] but they just don't bother. And some of them make other errors, like using insecure encryption and [05:50.190 --> 05:56.230] such. But the fundamental reason why this is so easy to do on Android is the language it's in. [05:56.230 --> 06:04.230] So here's TD Ameritrade. If you log in here, it will put the password in the log. This is in the [06:04.230 --> 06:09.050] syslog on the app, and in older versions of Android, this was visible to every app on the device. [06:09.050 --> 06:12.870] That's not true of later versions of Android, but still, it's not an appropriate place [06:12.870 --> 06:18.050] to put secrets like a password. In fact, a best practice is to turn off all logging [06:18.050 --> 06:23.810] in the distribution version of your app. Logging should only be there for your test versions in [06:23.810 --> 06:29.610] production. So Mayo Clinic Medical Transport has the other issue of hard-coded credentials. [06:29.610 --> 06:34.270] There's a password needed to see this app, and the producer makes half a dozen apps built the [06:34.270 --> 06:40.350] same way. And you can just see the source code. You can download the code from the phone and grep [06:40.350 --> 06:45.730] for the word password and just find the top secret password. And I notified him, and he told [06:45.730 --> 06:51.170] me to just get lost. My notifications are spam. I'm just irritating him. So I appreciate it when [06:51.170 --> 06:55.590] people give me a response like that, because that's volunteering to be homework. So anyway, [06:56.130 --> 07:04.370] another very common flaw in both Android and iOS is that they break TLS. They perform an HTTPS [07:04.370 --> 07:09.470] handshake, and then they don't verify the certificate with a trusted third-party provider. [07:09.470 --> 07:14.970] So you can give them a fake certificate, and they'll fall for it. This, in fact, has led to [07:14.970 --> 07:20.570] some punishments from the Federal Trade Commission to Fandango and Credit Karma. If you had some [07:20.570 --> 07:26.290] standard boilerplate statement in your terms of service that we take reasonable security measures, [07:26.290 --> 07:32.550] 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:44.370] An enormous number of apps remember who you are by storing your password locally on the phone, [07:44.370 --> 07:51.610] which is very strange. So Target Australia had an Android app that does the right thing, [07:51.610 --> 07:57.310] what websites would do. It puts a random cookie on your machine. But for some reason, a large [07:57.310 --> 08:02.510] number of web apps just store your password locally, which is a miserable thing to do, [08:02.510 --> 08:08.230] and that's what Staples does. It puts a thing called encrypted password on your phone, [08:08.230 --> 08:13.610] and that is a very strange thing to do. And in fact, you know, if you look at best practices, [08:13.610 --> 08:18.190] they say don't store a password on the phone at all. If you're going to do it, there's an Android [08:18.190 --> 08:23.630] keychain to put it in. There's public key encryption you could use. But what they almost [08:23.630 --> 08:29.850] all do, if they don't store it in plain text, is they store it with private key encryption, [08:29.850 --> 08:34.870] and then they try to hide the key on the phone. So you can easily detect the flaws here. [08:35.810 --> 08:40.890] Anyway, so it's easy to see that they're using... here you can tell they're using [08:40.890 --> 08:46.730] electronic codebook encryption. So if you give it a password that's 32 A's in a row, [08:46.730 --> 08:52.390] you get encrypted data with a repeating block shown in the lower middle here. And that shows [08:52.390 --> 08:58.190] that an identical block of input turns into an identical block of output, which is another very [08:58.190 --> 09:06.230] fundamental encryption error. So anyway, they construct the password by using things like the [09:06.230 --> 09:11.810] username, and the name of the app, and so on. And you can just read their source code and see how [09:11.810 --> 09:16.990] they build the password. Here they take the brand, device, model, serial number, and the name of the [09:16.990 --> 09:25.150] package, and combine that to construct the key. So I can easily write a reversing code that will [09:25.150 --> 09:31.230] extract the key from that so-called encrypted password. Anyway, so I notified Staples and made [09:31.230 --> 09:37.170] videos of them and all that. But that's the game. Their fix was to just detect a rooted device, [09:37.170 --> 09:42.850] which is something. It's a step in the right direction. Anyway, a lot of apps store local [09:42.850 --> 09:48.230] plain text, Ace Hardware, and McDonald's, and so on. They just store the password with no encryption [09:48.230 --> 09:53.610] at all on the phone. A bunch of them use plain text login with unencrypted traffic over the [09:53.610 --> 09:59.450] internet. And you can catch them here. And then a lot of them break SSL, as I mentioned. Here's [09:59.450 --> 10:04.970] one. I first found this, I was excited, thinking I'd found a flaw in Amazon. But this is just a [10:04.970 --> 10:11.350] flaw in a third-party app that tracks Amazon prices. So that's a review of work I've done [10:11.350 --> 10:17.630] years ago, showing the kind of problems you have with Android apps. And so let me skip over a few [10:17.630 --> 10:24.830] more of these. These are things I've talked about before. Many, many big companies do these common [10:26.010 --> 10:31.530] app mistakes. And I never really knew how bad it was on iOS, because since there wasn't a good [10:31.530 --> 10:38.710] jailbreak available for iOS, I couldn't really look inside the file system in a modern version [10:38.710 --> 10:45.230] of iOS and see what was happening. So I was gradually moving forward in the world of security [10:45.230 --> 10:50.510] and trying to move into more advanced things. And then I saw this talk by Joe McCrae. Joe McCrae [10:50.510 --> 10:56.470] is wonderful. He's doing the same thing I'm doing. He's trying to show that a relatively normal person [10:56.470 --> 11:01.370] can figure out how to do this. And he made this talk called Exploit Development for Mere Mortals. [11:01.370 --> 11:05.790] And I looked at that talk, and it was wonderful, because I thought exploit development was just [11:05.790 --> 11:10.150] mind-boggling and complicated, and I could never figure it out, and my students could never figure [11:10.150 --> 11:16.410] it out. And Joe convinced me that it's not that hard. He explains it in simple terms and shows [11:16.410 --> 11:21.490] you how to use the basic tools like OliDebug, and I said, well, maybe I could do it after all. [11:21.490 --> 11:26.290] And then Georgia Weidman wrote this book, and the book has a lot of introductory stuff, [11:26.290 --> 11:30.250] but it has an appendix where you would develop a simple buffer overflow exploit, [11:30.250 --> 11:35.890] and that was the first document that wrote I could do this in terms I could really follow, [11:35.890 --> 11:39.490] and it really worked. So then I was able to start teaching exploit development. [11:39.490 --> 11:43.330] So I wrote this class where we go through the shellcoder's handbook and we develop [11:43.330 --> 11:47.950] buffer overflow exploits and other things like format string exploits. [11:48.390 --> 11:54.070] And that was very exciting to me, and it attracted a bunch of new, more advanced students, [11:54.070 --> 11:59.010] people who had never been interested in taking college courses in ordinary ethical hacking, [11:59.010 --> 12:05.510] were drawn to this class. And in particular, this guy, Axiom X, came to the class. He had [12:05.510 --> 12:10.950] been a developer, and he'd never done hacking or attack before, but he heard about this class [12:10.950 --> 12:16.110] and came and took it, and so immediately he raced through everything I knew and everything in my [12:16.110 --> 12:22.790] book, and he rushed into iOS hacking, because he was a real expert on iOS, and he immediately found [12:22.790 --> 12:28.330] the checkring vulnerability, which makes almost up to, I think, two versions back now, made all [12:28.330 --> 12:33.390] these modern versions of iOS vulnerable, and it was a flaw in a hardware module that can't be [12:33.390 --> 12:38.350] updated without a replacement of the hardware. So suddenly, because of him and the team that [12:38.350 --> 12:43.950] joined him to make the checkring exploits, we could now get into the system of modern iPhones, [12:43.950 --> 12:50.290] and that was fun. So I immediately got a couple jailbroken phones. He loaned me a couple, [12:50.290 --> 12:57.670] and I, over the January and December, six months ago or seven months ago, I spent all my time [12:57.670 --> 13:02.990] auditing iPhone apps. I audited a few hundred iPhone apps, and I found all the same problems [13:02.990 --> 13:07.830] with iPhone apps. Here's the Blue Cross app, storing passwords locally on the phone without [13:07.830 --> 13:14.930] any encryption. Here's Blue Shield failing to validate TLS certificates, so it will just believe [13:15.250 --> 13:20.350] a fake certificate from a fake certificate provider. Here's West Point, transmitting [13:20.350 --> 13:25.870] passwords without no encryption at all, plain text over the internet, a West Point athletic app. [13:25.870 --> 13:32.450] Here's an Air Force app doing the same thing. Then there's Zillow, which stores a local copy [13:32.450 --> 13:41.690] of the passwords in a cache insecurely. Here's StockOptions, a stock app that breaks TLS [13:41.690 --> 13:48.370] encryption and stores things locally and sends plain text transmissions over the internet. [13:49.310 --> 13:54.090] And I was surprised by this one when I found these apps that send plain text data over the [13:54.090 --> 13:58.190] internet, because I thought that was not possible anymore, because I saw a news article saying [13:58.190 --> 14:04.510] years ago Apple has updated their application policy so you can't use insecure network [14:04.510 --> 14:09.190] transmissions. But I went and looked, and this is the article. There is this thing called app [14:09.190 --> 14:15.790] transport security, but you don't have to use it. You only get app transport security if you turn it [14:15.790 --> 14:22.830] on or if you are targeting recent versions of iOS. So older apps or apps that turn it off don't have [14:22.830 --> 14:27.870] it. So you can continue to have iPhone apps that send unencrypted sensitive data over the internet, [14:27.870 --> 14:34.230] which surprised me. I had believed that Apple was more secure than that, but it's not so, [14:34.230 --> 14:40.230] and it certainly is not so in practice. So then I tried other apps. I tried My City College app, [14:40.230 --> 14:45.170] and I found that the entire product line, about half of their products, were all insecure. They [14:45.170 --> 14:50.310] all used broken encryption, breaking TLS, and one of them uses no encryption at all. It appears that [14:50.310 --> 14:54.730] this company has swallowed up some other app companies, and they've inherited some products [14:54.730 --> 14:59.070] that are insecure. And I told them about this. All these vulnerabilities, by the way, I've [14:59.070 --> 15:04.330] disclosed many months ago. So I think they've been fixed if they're ever going to be fixed. [15:05.730 --> 15:10.050] And to be fair, I should say I've done a lot of vulnerability disclosure like this. This is white [15:10.050 --> 15:15.170] hatting, which is generally considered a waste of your time and an amateur move where you try to [15:15.170 --> 15:21.250] tell people about their problems when they have not come to you to ask for an audit. And it used [15:21.250 --> 15:26.830] to be that only 2% of them would ever fix it. And now it's up to maybe 10% of them fix it. And [15:26.830 --> 15:31.130] 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.570] But nobody tried to get me fired or start a lawsuit or anything this time. So I think [15:36.570 --> 15:45.010] the US government bug bounties have begun to raise awareness so that more companies don't just freak [15:45.010 --> 15:50.150] out and decide that you're a criminal when you report a vulnerability. And it's getting moving [15:50.150 --> 15:55.590] from 2% up to maybe 10% of them that actually care. Very few of them are actually ready to do [15:55.590 --> 16:01.450] anything about a vulnerability or fix it. But I think they're more it's becoming more common that [16:01.450 --> 16:06.170] they will at least admit that it is possible that they have a security flaw. And that in principle, [16:06.170 --> 16:11.390] they should do something about it instead of just shooting the messenger. So it's gradually improving. [16:12.110 --> 16:18.450] And I tried these chains of financial apps. I did a lot of bank apps. And I found this whole [16:18.450 --> 16:24.610] line of apps from Jack Henry that puts your password in the log, which is unsafe. And there's [16:24.690 --> 16:31.070] a whole series of banks using it. And then I found another financial app company. And again, they had [16:31.070 --> 16:34.870] the same thing, but a different structure. They also put your password in the log every time you [16:34.870 --> 16:41.670] logged in. So I notified their customers and the main provider that they needed to fix that. I [16:41.670 --> 16:45.990] don't know if they care. But I was surprised they have whole vulnerable product lines. And you would [16:45.990 --> 16:51.330] think at least that a developer that's making a whole product line would have some security [16:51.330 --> 16:56.970] auditing. But obviously, they don't. And their customers don't. So you can just sell broken junk [16:56.970 --> 17:04.950] forever. And nobody will catch you for a long time. So I've got a hacking mobile devices class [17:04.950 --> 17:10.610] where we've been doing this. And now we're moving into iOS in addition to Android. And I made a [17:10.610 --> 17:15.390] cryptography class trying to improve people's awareness of cryptography. So hopefully, they [17:15.390 --> 17:20.910] won't make so many fundamental cryptography mistakes. And you know, the basic bottom line [17:20.910 --> 17:24.810] here is nothing that exciting. You should be auditing your apps. You should have managers [17:25.310 --> 17:29.530] that ask the simple questions. And they don't have to be very technical. They need to say, [17:29.530 --> 17:35.250] did you collect data from the user? Where did you put it? Did you encrypt it? Where did you put the [17:35.250 --> 17:41.010] key? How did you transmit it? And you should have nice, simple, clear answers to those questions. [17:41.010 --> 17:48.890] And if you don't, then you shouldn't accept that app. So that's what I've got to tell you.