start	end	text
1910	8910	All right, so this is the worst mobile apps, and it's just a review of the last several years of
8910	15190	my work auditing the security of mobile apps in a very simple way. So I'm a teacher at City College
15190	22330	San Francisco, and I founded this company called InfoSec Decoded, and I do a lot of these classes,
22330	29650	and I'm not very advanced. I do beginning classes and simple things. The really complicated stuff
29650	37670	is usually beyond my classes. So mobile apps are a natural place to start because security
37670	42810	is terrible. Mobile apps... finding vulnerabilities in mobile apps is like taking a time machine back
42810	49190	to the early 90s when people didn't know anything about security. And so I did a lot of Android
49190	56210	auditing because it's very easy on Android, and it was very difficult on iOS until check rain.
56210	62590	So Android I did over the last several years, and iOS I've only done for about the last six months.
62610	69190	And I discovered that it is true what I had heard, that iOS apps are just as bad as Android apps.
69190	74790	Now the operating system is a little more secure, and the coding language is harder to reverse
74790	82510	engineer because it really is executable code compiled from C instead of partially compiled
82510	89170	from Java. But the end result is it's painfully obvious that the standards of most app developers
89170	96150	are extremely low, and that the management does not review the security of apps they purchase
96150	103550	from third-party developers, not even for the simplest flaws. So OWASP has a nice mobile top 10
103550	109290	showing the vulnerabilities here. And when I did Android apps, I typically found the ones
109290	115490	marked 8 and 9 here, where you can easily see the source code and find vulnerabilities. That is not
115490	121670	so easy to do on iOS, but the other ones are extremely common, like insecure data storage
121670	128090	and insecure communication and insufficient cryptography. Those are all extremely common.
128650	133670	So first, I'll just start with the headline, the worst apps I found.
134710	139870	The worst app in the world is probably this one, because not only is it incredibly
139870	145930	mind-bogglingly insecure, it's still in common use for an important purpose. This company, Equity
145930	152310	Pandit, is apparently a widely respected company in India and even has passed some kind of certification
152310	159210	for at least functionality. And their app has the worst API I've ever encountered that's still in use.
159210	164970	If you go to their API, not only does it log you in with plain text transmission over the internet
165510	170930	and then store your password in plain text locally. Beyond that, if you try to log in
170930	178430	with an incorrect password, the logic is shown in the top here. It doesn't send your username
178430	183630	and password to the server to authenticate you. It sends your email address to the server and
183630	190130	then it sends the correct password down to the phone, and then it compares the password you typed
190130	196250	to the password on the phone. And it puts both of them in a log. So at the top in that command line
196250	203790	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.
203790	209110	The A's and 2's are a wrong password I typed in, and it sends me the right password. So I gave my
209110	214390	students homework to just steal my password from my account on their server, and anybody can get
214390	219210	anybody's password at any time. And I told them years ago, and I've been giving it for homework
219210	226610	and using it in classes all over the world, and they just don't care. That is amazing to me.
226610	231110	That a company, especially a financial company, can just hand out all the passwords of everybody
231110	238250	all the time, and nobody cares, but it's still going on. And this one here was almost as bad.
238250	242770	The only thing better about it is they actually fixed it when I told them. The University of Houston
242770	248590	had an alumni app, and so I installed it and played with it. And the first thing it does before you log
248590	254630	in is it lets you search for yourself on the list of alumni. And when you do that, you'll see here
254630	260750	in the top line, it sends a request with the first letter or two of a username up to the server, which
260750	269050	is 326 bytes in the length column, and then the reply is 351 kilobytes. Every time anybody
269050	275890	searches for a user in the app, before you log in, it downloads the entire database of every user,
275890	284790	credit card numbers, account numbers, passwords, email addresses, down onto the phone, and it does
284790	290730	all that with broken encryption. So you get, again, get exposure to the entire database. But when I
290730	294670	told them, they actually took down the app and made a revised version that no longer has these
294670	300150	flaws. But when I showed this to students, some of my students said this, in fact, is something they
300150	304610	tell people to do, put everything on the phone so it will have fast response, even if the network
304610	313310	is slow. But it is surprisingly bad. So not every app is that bad, but a large portion of apps,
313310	318950	like 10 or 15 percent, make extremely elementary flaws so simple that I can catch them. So over
318950	323870	the last several years, I've done a lot of Android apps. I started by doing the top 10 banks,
323870	328210	insurance companies, and stockbrokers, and essentially all of them are vulnerable to
328210	333530	code modification. So you can see the source code, you can modify the code, you can make a modified
333530	338350	app and run it, and they don't detect that it's modified, and they don't detect that it's an
340050	344130	unauthorized app when it connects to the server, both of which would be pretty easy to do,
344130	350190	but they just don't bother. And some of them make other errors, like using insecure encryption and
350190	356230	such. But the fundamental reason why this is so easy to do on Android is the language it's in.
356230	364230	So here's TD Ameritrade. If you log in here, it will put the password in the log. This is in the
364230	369050	syslog on the app, and in older versions of Android, this was visible to every app on the device.
369050	372870	That's not true of later versions of Android, but still, it's not an appropriate place
372870	378050	to put secrets like a password. In fact, a best practice is to turn off all logging
378050	383810	in the distribution version of your app. Logging should only be there for your test versions in
383810	389610	production. So Mayo Clinic Medical Transport has the other issue of hard-coded credentials.
389610	394270	There's a password needed to see this app, and the producer makes half a dozen apps built the
394270	400350	same way. And you can just see the source code. You can download the code from the phone and grep
400350	405730	for the word password and just find the top secret password. And I notified him, and he told
405730	411170	me to just get lost. My notifications are spam. I'm just irritating him. So I appreciate it when
411170	415590	people give me a response like that, because that's volunteering to be homework. So anyway,
416130	424370	another very common flaw in both Android and iOS is that they break TLS. They perform an HTTPS
424370	429470	handshake, and then they don't verify the certificate with a trusted third-party provider.
429470	434970	So you can give them a fake certificate, and they'll fall for it. This, in fact, has led to
434970	440570	some punishments from the Federal Trade Commission to Fandango and Credit Karma. If you had some
440570	446290	standard boilerplate statement in your terms of service that we take reasonable security measures,
446290	452550	this behavior, breaking TLS, was considered insufficient to comply with that promise.
452930	457810	So then I gave some talks before about password storage on the phone.
458830	464370	An enormous number of apps remember who you are by storing your password locally on the phone,
464370	471610	which is very strange. So Target Australia had an Android app that does the right thing,
471610	477310	what websites would do. It puts a random cookie on your machine. But for some reason, a large
477310	482510	number of web apps just store your password locally, which is a miserable thing to do,
482510	488230	and that's what Staples does. It puts a thing called encrypted password on your phone,
488230	493610	and that is a very strange thing to do. And in fact, you know, if you look at best practices,
493610	498190	they say don't store a password on the phone at all. If you're going to do it, there's an Android
498190	503630	keychain to put it in. There's public key encryption you could use. But what they almost
503630	509850	all do, if they don't store it in plain text, is they store it with private key encryption,
509850	514870	and then they try to hide the key on the phone. So you can easily detect the flaws here.
515810	520890	Anyway, so it's easy to see that they're using... here you can tell they're using
520890	526730	electronic codebook encryption. So if you give it a password that's 32 A's in a row,
526730	532390	you get encrypted data with a repeating block shown in the lower middle here. And that shows
532390	538190	that an identical block of input turns into an identical block of output, which is another very
538190	546230	fundamental encryption error. So anyway, they construct the password by using things like the
546230	551810	username, and the name of the app, and so on. And you can just read their source code and see how
551810	556990	they build the password. Here they take the brand, device, model, serial number, and the name of the
556990	565150	package, and combine that to construct the key. So I can easily write a reversing code that will
565150	571230	extract the key from that so-called encrypted password. Anyway, so I notified Staples and made
571230	577170	videos of them and all that. But that's the game. Their fix was to just detect a rooted device,
577170	582850	which is something. It's a step in the right direction. Anyway, a lot of apps store local
582850	588230	plain text, Ace Hardware, and McDonald's, and so on. They just store the password with no encryption
588230	593610	at all on the phone. A bunch of them use plain text login with unencrypted traffic over the
593610	599450	internet. And you can catch them here. And then a lot of them break SSL, as I mentioned. Here's
599450	604970	one. I first found this, I was excited, thinking I'd found a flaw in Amazon. But this is just a
604970	611350	flaw in a third-party app that tracks Amazon prices. So that's a review of work I've done
611350	617630	years ago, showing the kind of problems you have with Android apps. And so let me skip over a few
617630	624830	more of these. These are things I've talked about before. Many, many big companies do these common
626010	631530	app mistakes. And I never really knew how bad it was on iOS, because since there wasn't a good
631530	638710	jailbreak available for iOS, I couldn't really look inside the file system in a modern version
638710	645230	of iOS and see what was happening. So I was gradually moving forward in the world of security
645230	650510	and trying to move into more advanced things. And then I saw this talk by Joe McCrae. Joe McCrae
650510	656470	is wonderful. He's doing the same thing I'm doing. He's trying to show that a relatively normal person
656470	661370	can figure out how to do this. And he made this talk called Exploit Development for Mere Mortals.
661370	665790	And I looked at that talk, and it was wonderful, because I thought exploit development was just
665790	670150	mind-boggling and complicated, and I could never figure it out, and my students could never figure
670150	676410	it out. And Joe convinced me that it's not that hard. He explains it in simple terms and shows
676410	681490	you how to use the basic tools like OliDebug, and I said, well, maybe I could do it after all.
681490	686290	And then Georgia Weidman wrote this book, and the book has a lot of introductory stuff,
686290	690250	but it has an appendix where you would develop a simple buffer overflow exploit,
690250	695890	and that was the first document that wrote I could do this in terms I could really follow,
695890	699490	and it really worked. So then I was able to start teaching exploit development.
699490	703330	So I wrote this class where we go through the shellcoder's handbook and we develop
703330	707950	buffer overflow exploits and other things like format string exploits.
708390	714070	And that was very exciting to me, and it attracted a bunch of new, more advanced students,
714070	719010	people who had never been interested in taking college courses in ordinary ethical hacking,
719010	725510	were drawn to this class. And in particular, this guy, Axiom X, came to the class. He had
725510	730950	been a developer, and he'd never done hacking or attack before, but he heard about this class
730950	736110	and came and took it, and so immediately he raced through everything I knew and everything in my
736110	742790	book, and he rushed into iOS hacking, because he was a real expert on iOS, and he immediately found
742790	748330	the checkring vulnerability, which makes almost up to, I think, two versions back now, made all
748330	753390	these modern versions of iOS vulnerable, and it was a flaw in a hardware module that can't be
753390	758350	updated without a replacement of the hardware. So suddenly, because of him and the team that
758350	763950	joined him to make the checkring exploits, we could now get into the system of modern iPhones,
763950	770290	and that was fun. So I immediately got a couple jailbroken phones. He loaned me a couple,
770290	777670	and I, over the January and December, six months ago or seven months ago, I spent all my time
777670	782990	auditing iPhone apps. I audited a few hundred iPhone apps, and I found all the same problems
782990	787830	with iPhone apps. Here's the Blue Cross app, storing passwords locally on the phone without
787830	794930	any encryption. Here's Blue Shield failing to validate TLS certificates, so it will just believe
795250	800350	a fake certificate from a fake certificate provider. Here's West Point, transmitting
800350	805870	passwords without no encryption at all, plain text over the internet, a West Point athletic app.
805870	812450	Here's an Air Force app doing the same thing. Then there's Zillow, which stores a local copy
812450	821690	of the passwords in a cache insecurely. Here's StockOptions, a stock app that breaks TLS
821690	828370	encryption and stores things locally and sends plain text transmissions over the internet.
829310	834090	And I was surprised by this one when I found these apps that send plain text data over the
834090	838190	internet, because I thought that was not possible anymore, because I saw a news article saying
838190	844510	years ago Apple has updated their application policy so you can't use insecure network
844510	849190	transmissions. But I went and looked, and this is the article. There is this thing called app
849190	855790	transport security, but you don't have to use it. You only get app transport security if you turn it
855790	862830	on or if you are targeting recent versions of iOS. So older apps or apps that turn it off don't have
862830	867870	it. So you can continue to have iPhone apps that send unencrypted sensitive data over the internet,
867870	874230	which surprised me. I had believed that Apple was more secure than that, but it's not so,
874230	880230	and it certainly is not so in practice. So then I tried other apps. I tried My City College app,
880230	885170	and I found that the entire product line, about half of their products, were all insecure. They
885170	890310	all used broken encryption, breaking TLS, and one of them uses no encryption at all. It appears that
890310	894730	this company has swallowed up some other app companies, and they've inherited some products
894730	899070	that are insecure. And I told them about this. All these vulnerabilities, by the way, I've
899070	904330	disclosed many months ago. So I think they've been fixed if they're ever going to be fixed.
905730	910050	And to be fair, I should say I've done a lot of vulnerability disclosure like this. This is white
910050	915170	hatting, which is generally considered a waste of your time and an amateur move where you try to
915170	921250	tell people about their problems when they have not come to you to ask for an audit. And it used
921250	926830	to be that only 2% of them would ever fix it. And now it's up to maybe 10% of them fix it. And
926830	931130	some of them even say thank you and promise to send me stuff and then never send me the stuff.
931250	936570	But nobody tried to get me fired or start a lawsuit or anything this time. So I think
936570	945010	the US government bug bounties have begun to raise awareness so that more companies don't just freak
945010	950150	out and decide that you're a criminal when you report a vulnerability. And it's getting moving
950150	955590	from 2% up to maybe 10% of them that actually care. Very few of them are actually ready to do
955590	961450	anything about a vulnerability or fix it. But I think they're more it's becoming more common that
961450	966170	they will at least admit that it is possible that they have a security flaw. And that in principle,
966170	971390	they should do something about it instead of just shooting the messenger. So it's gradually improving.
972110	978450	And I tried these chains of financial apps. I did a lot of bank apps. And I found this whole
978450	984610	line of apps from Jack Henry that puts your password in the log, which is unsafe. And there's
984690	991070	a whole series of banks using it. And then I found another financial app company. And again, they had
991070	994870	the same thing, but a different structure. They also put your password in the log every time you
994870	1001670	logged in. So I notified their customers and the main provider that they needed to fix that. I
1001670	1005990	don't know if they care. But I was surprised they have whole vulnerable product lines. And you would
1005990	1011330	think at least that a developer that's making a whole product line would have some security
1011330	1016970	auditing. But obviously, they don't. And their customers don't. So you can just sell broken junk
1016970	1024950	forever. And nobody will catch you for a long time. So I've got a hacking mobile devices class
1024950	1030610	where we've been doing this. And now we're moving into iOS in addition to Android. And I made a
1030610	1035390	cryptography class trying to improve people's awareness of cryptography. So hopefully, they
1035390	1040910	won't make so many fundamental cryptography mistakes. And you know, the basic bottom line
1040910	1044810	here is nothing that exciting. You should be auditing your apps. You should have managers
1045310	1049530	that ask the simple questions. And they don't have to be very technical. They need to say,
1049530	1055250	did you collect data from the user? Where did you put it? Did you encrypt it? Where did you put the
1055250	1061010	key? How did you transmit it? And you should have nice, simple, clear answers to those questions.
1061010	1068890	And if you don't, then you shouldn't accept that app. So that's what I've got to tell you.