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. 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. I do beginning classes and simple things. The really complicated stuff
is usually beyond my classes. So mobile apps are a natural place to start because security
is terrible. 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. 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.
So Android I did over the last several years, and iOS I've only done for about the last six months.
And I discovered that it is true what I had heard, that iOS apps are just as bad as Android apps.
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. 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. So OWASP has a nice mobile top 10
showing the vulnerabilities here. 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. 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. Those are all extremely common.
So first, I'll just start with the headline, the worst apps I found.
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. This company, Equity
Pandit, is apparently a widely respected company in India and even has passed some kind of certification
for at least functionality. And their app has the worst API I've ever encountered that's still in use.
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. Beyond that, if you try to log in
with an incorrect password, the logic is shown in the top here. It doesn't send your username
and password to the server to authenticate you. 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. And it puts both of them in a log. 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.
The A's and 2's are a wrong password I typed in, and it sends me the right password. 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. 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. That is amazing to me.
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. And this one here was almost as bad.
The only thing better about it is they actually fixed it when I told them. The University of Houston
had an alumni app, and so I installed it and played with it. And the first thing it does before you log
in is it lets you search for yourself on the list of alumni. 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. 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. So you get, again, get exposure to the entire database. But when I
told them, they actually took down the app and made a revised version that no longer has these
flaws. 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. But it is surprisingly bad. 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. So over
the last several years, I've done a lot of Android apps. I started by doing the top 10 banks,
insurance companies, and stockbrokers, and essentially all of them are vulnerable to
code modification. 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,
but they just don't bother. And some of them make other errors, like using insecure encryption and
such. But the fundamental reason why this is so easy to do on Android is the language it's in.
So here's TD Ameritrade. If you log in here, it will put the password in the log. This is in the
syslog on the app, and in older versions of Android, this was visible to every app on the device.
That's not true of later versions of Android, but still, it's not an appropriate place
to put secrets like a password. In fact, a best practice is to turn off all logging
in the distribution version of your app. Logging should only be there for your test versions in
production. So Mayo Clinic Medical Transport has the other issue of hard-coded credentials.
There's a password needed to see this app, and the producer makes half a dozen apps built the
same way. And you can just see the source code. You can download the code from the phone and grep
for the word password and just find the top secret password. And I notified him, and he told
me to just get lost. My notifications are spam. I'm just irritating him. So I appreciate it when
people give me a response like that, because that's volunteering to be homework. So anyway,
another very common flaw in both Android and iOS is that they break TLS. They perform an HTTPS
handshake, and then they don't verify the certificate with a trusted third-party provider.
So you can give them a fake certificate, and they'll fall for it. This, in fact, has led to
some punishments from the Federal Trade Commission to Fandango and Credit Karma. 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.
So then I gave some talks before about password storage on the phone.
An enormous number of apps remember who you are by storing your password locally on the phone,
which is very strange. So Target Australia had an Android app that does the right thing,
what websites would do. It puts a random cookie on your machine. 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. It puts a thing called encrypted password on your phone,
and that is a very strange thing to do. And in fact, you know, if you look at best practices,
they say don't store a password on the phone at all. If you're going to do it, there's an Android
keychain to put it in. There's public key encryption you could use. 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. So you can easily detect the flaws here.
Anyway, so it's easy to see that they're using... here you can tell they're using
electronic codebook encryption. 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. And that shows
that an identical block of input turns into an identical block of output, which is another very
fundamental encryption error. So anyway, they construct the password by using things like the
username, and the name of the app, and so on. And you can just read their source code and see how
they build the password. Here they take the brand, device, model, serial number, and the name of the
package, and combine that to construct the key. So I can easily write a reversing code that will
extract the key from that so-called encrypted password. Anyway, so I notified Staples and made
videos of them and all that. But that's the game. Their fix was to just detect a rooted device,
which is something. It's a step in the right direction. Anyway, a lot of apps store local
plain text, Ace Hardware, and McDonald's, and so on. They just store the password with no encryption
at all on the phone. A bunch of them use plain text login with unencrypted traffic over the
internet. And you can catch them here. And then a lot of them break SSL, as I mentioned. Here's
one. I first found this, I was excited, thinking I'd found a flaw in Amazon. But this is just a
flaw in a third-party app that tracks Amazon prices. So that's a review of work I've done
years ago, showing the kind of problems you have with Android apps. And so let me skip over a few
more of these. These are things I've talked about before. Many, many big companies do these common
app mistakes. 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. So I was gradually moving forward in the world of security
and trying to move into more advanced things. And then I saw this talk by Joe McCrae. Joe McCrae
is wonderful. He's doing the same thing I'm doing. He's trying to show that a relatively normal person
can figure out how to do this. And he made this talk called Exploit Development for Mere Mortals.
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. And Joe convinced me that it's not that hard. 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.
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,
and it really worked. So then I was able to start teaching exploit development.
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.
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. And in particular, this guy, Axiom X, came to the class. 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, 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. 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. So I immediately got a couple jailbroken phones. 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. I audited a few hundred iPhone apps, and I found all the same problems
with iPhone apps. Here's the Blue Cross app, storing passwords locally on the phone without
any encryption. Here's Blue Shield failing to validate TLS certificates, so it will just believe
a fake certificate from a fake certificate provider. Here's West Point, transmitting
passwords without no encryption at all, plain text over the internet, a West Point athletic app.
Here's an Air Force app doing the same thing. Then there's Zillow, which stores a local copy
of the passwords in a cache insecurely. Here's StockOptions, a stock app that breaks TLS
encryption and stores things locally and sends plain text transmissions over the internet.
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. But I went and looked, and this is the article. There is this thing called app
transport security, but you don't have to use it. You only get app transport security if you turn it
on or if you are targeting recent versions of iOS. So older apps or apps that turn it off don't have
it. So you can continue to have iPhone apps that send unencrypted sensitive data over the internet,
which surprised me. I had believed that Apple was more secure than that, but it's not so,
and it certainly is not so in practice. So then I tried other apps. I tried My City College app,
and I found that the entire product line, about half of their products, were all insecure. They
all used broken encryption, breaking TLS, and one of them uses no encryption at all. It appears that
this company has swallowed up some other app companies, and they've inherited some products
that are insecure. And I told them about this. All these vulnerabilities, by the way, I've
disclosed many months ago. So I think they've been fixed if they're ever going to be fixed.
And to be fair, I should say I've done a lot of vulnerability disclosure like this. 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. And it used
to be that only 2% of them would ever fix it. And now it's up to maybe 10% of them fix it. And
some of them even say thank you and promise to send me stuff and then never send me the stuff.
But nobody tried to get me fired or start a lawsuit or anything this time. 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. And it's getting moving
from 2% up to maybe 10% of them that actually care. Very few of them are actually ready to do
anything about a vulnerability or fix it. 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. And that in principle,
they should do something about it instead of just shooting the messenger. So it's gradually improving.
And I tried these chains of financial apps. I did a lot of bank apps. And I found this whole
line of apps from Jack Henry that puts your password in the log, which is unsafe. And there's
a whole series of banks using it. And then I found another financial app company. And again, they had
the same thing, but a different structure. They also put your password in the log every time you
logged in. So I notified their customers and the main provider that they needed to fix that. I
don't know if they care. But I was surprised they have whole vulnerable product lines. And you would
think at least that a developer that's making a whole product line would have some security
auditing. But obviously, they don't. And their customers don't. So you can just sell broken junk
forever. And nobody will catch you for a long time. So I've got a hacking mobile devices class
where we've been doing this. And now we're moving into iOS in addition to Android. And I made a
cryptography class trying to improve people's awareness of cryptography. So hopefully, they
won't make so many fundamental cryptography mistakes. And you know, the basic bottom line
here is nothing that exciting. You should be auditing your apps. You should have managers
that ask the simple questions. And they don't have to be very technical. They need to say,
did you collect data from the user? Where did you put it? Did you encrypt it? Where did you put the
key? How did you transmit it? And you should have nice, simple, clear answers to those questions.
And if you don't, then you shouldn't accept that app. So that's what I've got to tell you.