1
00:00:01,910 --> 00: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.

2
00:00:13,150 --> 00: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.

3
00:00:24,390 --> 00:00:28,110
I do beginning classes and simple things.

4
00:00:28,110 --> 00:00:32,230
The really complicated stuff is usually beyond my classes.

5
00:00:32,850 --> 00:00:38,690
So mobile apps are a natural place to start because security is terrible.

6
00:00:38,690 --> 00: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.

7
00:00:47,170 --> 00: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.

8
00:00:56,210 --> 00:01:02,590
So Android I did over the last several years, and iOS I've only done for about the last six months.

9
00:01:02,610 --> 00:01:09,190
And I discovered that it is true what I had heard, that iOS apps are just as bad as Android apps.

10
00:01:09,190 --> 00: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.

11
00:01:24,030 --> 00: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.

12
00:01:40,570 --> 00:01:45,950
So OWASP has a nice mobile top 10 showing the vulnerabilities here.

13
00:01:45,990 --> 00: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.

14
00:01:54,910 --> 00: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.

15
00:02:05,390 --> 00:02:08,090
Those are all extremely common.

16
00:02:08,650 --> 00:02:13,670
So first, I'll just start with the headline, the worst apps I found.

17
00:02:14,710 --> 00: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.

18
00:02:24,730 --> 00: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.

19
00:02:34,350 --> 00:02:39,210
And their app has the worst API I've ever encountered that's still in use.

20
00:02:39,210 --> 00: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.

21
00:02:48,990 --> 00:02:55,090
Beyond that, if you try to log in with an incorrect password, the logic is shown in the top here.

22
00:02:55,190 --> 00:03:01,250
It doesn't send your username and password to the server to authenticate you.

23
00:03:01,250 --> 00: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.

24
00:03:12,010 --> 00:03:14,130
And it puts both of them in a log.

25
00:03:14,130 --> 00: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.

26
00:03:23,790 --> 00:03:28,450
The A's and 2's are a wrong password I typed in, and it sends me the right password.

27
00:03:28,450 --> 00: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.

28
00:03:36,670 --> 00: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.

29
00:03:43,470 --> 00:03:46,610
That is amazing to me.

30
00:03:46,610 --> 00: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.

31
00:03:55,830 --> 00:03:58,250
And this one here was almost as bad.

32
00:03:58,250 --> 00:04:01,690
The only thing better about it is they actually fixed it when I told them.

33
00:04:01,690 --> 00:04:06,630
The University of Houston had an alumni app, and so I installed it and played with it.

34
00:04:06,690 --> 00: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.

35
00:04:12,830 --> 00: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.

36
00:04:27,770 --> 00: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.

37
00:04:47,030 --> 00:04:50,230
So you get, again, get exposure to the entire database.

38
00:04:50,230 --> 00: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.

39
00:04:55,770 --> 00: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.

40
00:05:05,610 --> 00:05:08,590
But it is surprisingly bad.

41
00:05:08,590 --> 00: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.

42
00:05:18,610 --> 00:05:21,870
So over the last several years, I've done a lot of Android apps.

43
00:05:21,930 --> 00: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.

44
00:05:29,670 --> 00: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,

45
00:05:44,130 --> 00:05:45,850
but they just don't bother.

46
00:05:46,610 --> 00:05:50,970
And some of them make other errors, like using insecure encryption and such.

47
00:05:51,050 --> 00:05:56,230
But the fundamental reason why this is so easy to do on Android is the language it's in.

48
00:05:56,230 --> 00:05:58,090
So here's TD Ameritrade.

49
00:05:58,090 --> 00:06:03,550
If you log in here, it will put the password in the log.

50
00:06:03,590 --> 00: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.

51
00:06:09,050 --> 00: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.

52
00:06:15,170 --> 00:06:20,370
In fact, a best practice is to turn off all logging in the distribution version of your app.

53
00:06:20,370 --> 00:06:24,730
Logging should only be there for your test versions in production.

54
00:06:25,270 --> 00:06:29,610
So Mayo Clinic Medical Transport has the other issue of hard-coded credentials.

55
00:06:29,610 --> 00:06:34,910
There's a password needed to see this app, and the producer makes half a dozen apps built the same way.

56
00:06:34,930 --> 00:06:37,150
And you can just see the source code.

57
00:06:37,150 --> 00:06:44,250
You can download the code from the phone and grep for the word password and just find the top secret password.

58
00:06:44,370 --> 00:06:46,830
And I notified him, and he told me to just get lost.

59
00:06:46,830 --> 00:06:48,270
My notifications are spam.

60
00:06:48,270 --> 00:06:49,710
I'm just irritating him.

61
00:06:49,710 --> 00:06:54,690
So I appreciate it when people give me a response like that, because that's volunteering to be homework.

62
00:06:54,690 --> 00:07:01,590
So anyway, another very common flaw in both Android and iOS is that they break TLS.

63
00:07:01,670 --> 00:07:09,470
They perform an HTTPS handshake, and then they don't verify the certificate with a trusted third-party provider.

64
00:07:09,470 --> 00:07:13,750
So you can give them a fake certificate, and they'll fall for it.

65
00:07:13,750 --> 00:07:19,650
This, in fact, has led to some punishments from the Federal Trade Commission to Fandango and Credit Karma.

66
00:07:19,710 --> 00: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.

67
00:07:32,930 --> 00:07:37,810
So then I gave some talks before about password storage on the phone.

68
00:07:38,830 --> 00:07:45,830
An enormous number of apps remember who you are by storing your password locally on the phone, which is very strange.

69
00:07:45,830 --> 00:07:52,730
So Target Australia had an Android app that does the right thing, what websites would do.

70
00:07:52,730 --> 00:07:55,310
It puts a random cookie on your machine.

71
00:07:55,850 --> 00: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.

72
00:08:04,650 --> 00:08:10,930
It puts a thing called encrypted password on your phone, and that is a very strange thing to do.

73
00:08:11,250 --> 00: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.

74
00:08:16,630 --> 00:08:19,810
If you're going to do it, there's an Android keychain to put it in.

75
00:08:19,810 --> 00:08:22,470
There's public key encryption you could use.

76
00:08:22,630 --> 00: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.

77
00:08:32,450 --> 00:08:34,870
So you can easily detect the flaws here.

78
00:08:35,810 --> 00:08:43,090
Anyway, so it's easy to see that they're using... here you can tell they're using electronic codebook encryption.

79
00:08:43,090 --> 00: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.

80
00:08:51,490 --> 00: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.

81
00:09:00,270 --> 00:09:09,630
So anyway, they construct the password by using things like the username, and the name of the app, and so on.

82
00:09:09,630 --> 00:09:12,790
And you can just read their source code and see how they build the password.

83
00:09:12,790 --> 00: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.

84
00:09:20,670 --> 00:09:28,850
So I can easily write a reversing code that will extract the key from that so-called encrypted password.

85
00:09:28,990 --> 00:09:32,850
Anyway, so I notified Staples and made videos of them and all that.

86
00:09:33,170 --> 00:09:34,750
But that's the game.

87
00:09:34,750 --> 00:09:38,250
Their fix was to just detect a rooted device, which is something.

88
00:09:38,250 --> 00:09:40,010
It's a step in the right direction.

89
00:09:40,230 --> 00:09:46,350
Anyway, a lot of apps store local plain text, Ace Hardware, and McDonald's, and so on.

90
00:09:46,390 --> 00:09:49,590
They just store the password with no encryption at all on the phone.

91
00:09:49,890 --> 00:09:54,410
A bunch of them use plain text login with unencrypted traffic over the internet.

92
00:09:54,690 --> 00:09:56,610
And you can catch them here.

93
00:09:56,610 --> 00:09:59,230
And then a lot of them break SSL, as I mentioned.

94
00:09:59,230 --> 00:09:59,970
Here's one.

95
00:09:59,970 --> 00:10:03,490
I first found this, I was excited, thinking I'd found a flaw in Amazon.

96
00:10:03,490 --> 00:10:08,910
But this is just a flaw in a third-party app that tracks Amazon prices.

97
00:10:08,930 --> 00: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.

98
00:10:15,550 --> 00:10:18,530
And so let me skip over a few more of these.

99
00:10:18,530 --> 00:10:21,490
These are things I've talked about before.

100
00:10:21,690 --> 00:10:27,590
Many, many big companies do these common app mistakes.

101
00:10:27,590 --> 00: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.

102
00:10:41,230 --> 00:10:47,330
So I was gradually moving forward in the world of security and trying to move into more advanced things.

103
00:10:47,330 --> 00:10:49,790
And then I saw this talk by Joe McCrae.

104
00:10:49,790 --> 00:10:51,550
Joe McCrae is wonderful.

105
00:10:51,550 --> 00:10:53,450
He's doing the same thing I'm doing.

106
00:10:53,450 --> 00:10:57,650
He's trying to show that a relatively normal person can figure out how to do this.

107
00:10:57,650 --> 00:11:01,370
And he made this talk called Exploit Development for Mere Mortals.

108
00:11:01,370 --> 00: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.

109
00:11:11,050 --> 00:11:13,730
And Joe convinced me that it's not that hard.

110
00:11:14,450 --> 00: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.

111
00:11:21,490 --> 00: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,

112
00:11:35,890 --> 00:11:36,810
and it really worked.

113
00:11:36,810 --> 00:11:39,490
So then I was able to start teaching exploit development.

114
00:11:39,490 --> 00: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.

115
00:11:48,390 --> 00: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.

116
00:12:01,230 --> 00:12:05,270
And in particular, this guy, Axiom X, came to the class.

117
00:12:05,270 --> 00: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,

118
00:12:21,430 --> 00: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.

119
00:12:35,310 --> 00: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.

120
00:12:45,810 --> 00:12:48,810
So I immediately got a couple jailbroken phones.

121
00:12:48,810 --> 00: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.

122
00:12:59,310 --> 00:13:03,970
I audited a few hundred iPhone apps, and I found all the same problems with iPhone apps.

123
00:13:03,970 --> 00:13:09,050
Here's the Blue Cross app, storing passwords locally on the phone without any encryption.

124
00:13:09,670 --> 00: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.

125
00:13:18,610 --> 00:13:25,870
Here's West Point, transmitting passwords without no encryption at all, plain text over the internet, a West Point athletic app.

126
00:13:25,870 --> 00:13:28,650
Here's an Air Force app doing the same thing.

127
00:13:29,410 --> 00:13:35,410
Then there's Zillow, which stores a local copy of the passwords in a cache insecurely.

128
00:13:36,330 --> 00: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.

129
00:13:49,310 --> 00: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.

130
00:14:05,310 --> 00:14:07,630
But I went and looked, and this is the article.

131
00:14:07,630 --> 00:14:12,510
There is this thing called app transport security, but you don't have to use it.

132
00:14:12,510 --> 00:14:19,070
You only get app transport security if you turn it on or if you are targeting recent versions of iOS.

133
00:14:19,070 --> 00:14:22,970
So older apps or apps that turn it off don't have it.

134
00:14:22,970 --> 00:14:29,330
So you can continue to have iPhone apps that send unencrypted sensitive data over the internet, which surprised me.

135
00:14:29,330 --> 00: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.

136
00:14:36,670 --> 00:14:38,670
So then I tried other apps.

137
00:14:38,670 --> 00: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.

138
00:14:44,790 --> 00:14:49,650
They all used broken encryption, breaking TLS, and one of them uses no encryption at all.

139
00:14:49,650 --> 00:14:55,870
It appears that this company has swallowed up some other app companies, and they've inherited some products that are insecure.

140
00:14:55,870 --> 00:14:57,610
And I told them about this.

141
00:14:57,610 --> 00:15:01,210
All these vulnerabilities, by the way, I've disclosed many months ago.

142
00:15:01,370 --> 00:15:04,330
So I think they've been fixed if they're ever going to be fixed.

143
00:15:05,730 --> 00:15:09,490
And to be fair, I should say I've done a lot of vulnerability disclosure like this.

144
00:15:09,490 --> 00: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.

145
00:15:20,030 --> 00:15:24,390
And it used to be that only 2% of them would ever fix it.

146
00:15:24,470 --> 00:15:26,790
And now it's up to maybe 10% of them fix it.

147
00:15:26,790 --> 00:15:31,130
And some of them even say thank you and promise to send me stuff and then never send me the stuff.

148
00:15:31,250 --> 00:15:36,150
But nobody tried to get me fired or start a lawsuit or anything this time.

149
00:15:36,150 --> 00: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.

150
00:15:48,710 --> 00:15:53,090
And it's getting moving from 2% up to maybe 10% of them that actually care.

151
00:15:53,250 --> 00:15:58,050
Very few of them are actually ready to do anything about a vulnerability or fix it.

152
00:15:58,050 --> 00: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.

153
00:16:05,170 --> 00:16:09,010
And that in principle, they should do something about it instead of just shooting the messenger.

154
00:16:09,010 --> 00:16:11,390
So it's gradually improving.

155
00:16:12,110 --> 00:16:14,950
And I tried these chains of financial apps.

156
00:16:14,950 --> 00:16:16,750
I did a lot of bank apps.

157
00:16:16,750 --> 00:16:24,450
And I found this whole line of apps from Jack Henry that puts your password in the log, which is unsafe.

158
00:16:24,450 --> 00:16:26,490
And there's a whole series of banks using it.

159
00:16:26,550 --> 00:16:30,230
And then I found another financial app company.

160
00:16:30,450 --> 00:16:32,850
And again, they had the same thing, but a different structure.

161
00:16:32,850 --> 00:16:35,510
They also put your password in the log every time you logged in.

162
00:16:35,510 --> 00:16:41,670
So I notified their customers and the main provider that they needed to fix that.

163
00:16:41,670 --> 00:16:42,630
I don't know if they care.

164
00:16:42,630 --> 00:16:45,570
But I was surprised they have whole vulnerable product lines.

165
00:16:45,570 --> 00:16:51,910
And you would think at least that a developer that's making a whole product line would have some security auditing.

166
00:16:51,910 --> 00:16:53,690
But obviously, they don't.

167
00:16:53,690 --> 00:16:55,190
And their customers don't.

168
00:16:55,190 --> 00:16:57,770
So you can just sell broken junk forever.

169
00:16:57,770 --> 00:17:00,790
And nobody will catch you for a long time.

170
00:17:01,350 --> 00:17:06,310
So I've got a hacking mobile devices class where we've been doing this.

171
00:17:06,310 --> 00:17:09,370
And now we're moving into iOS in addition to Android.

172
00:17:09,370 --> 00:17:14,350
And I made a cryptography class trying to improve people's awareness of cryptography.

173
00:17:14,350 --> 00:17:18,290
So hopefully, they won't make so many fundamental cryptography mistakes.

174
00:17:19,050 --> 00:17:22,410
And you know, the basic bottom line here is nothing that exciting.

175
00:17:22,410 --> 00:17:23,790
You should be auditing your apps.

176
00:17:23,790 --> 00:17:26,790
You should have managers that ask the simple questions.

177
00:17:26,790 --> 00:17:28,670
And they don't have to be very technical.

178
00:17:28,670 --> 00:17:31,630
They need to say, did you collect data from the user?

179
00:17:31,730 --> 00:17:33,150
Where did you put it?

180
00:17:33,150 --> 00:17:34,310
Did you encrypt it?

181
00:17:34,310 --> 00:17:36,030
Where did you put the key?

182
00:17:36,050 --> 00:17:37,530
How did you transmit it?

183
00:17:37,530 --> 00:17:41,010
And you should have nice, simple, clear answers to those questions.

184
00:17:41,010 --> 00:17:46,030
And if you don't, then you shouldn't accept that app.

185
00:17:47,010 --> 00:17:48,890
So that's what I've got to tell you.