[Seminar] [Defending Behind the Device: Mobile Application Security]
[Chris Wysopal] [Harvard University]
[This is CS50.] [CS50.TV]
>> Good afternoon. My name is Chris Wysopal.
I'm the CTO and co-founder of Veracode.
Veracode is an application security company.
We test all kinds of different applications,
and what I'm going to talk about today is mobile application security.
My background is I've been doing security research
for a very long time, probably about as long as anybody.
I started in the mid 90s,
and it was a time that was pretty interesting because
we had a paradigm change in the mid 90s.
All of a sudden everyone's computer was hooked up to the internet,
and then we had the beginnings of web applications,
and that's what I focused on a lot then.
It's interesting.
Now we have another paradigm change happening with computing,
which is the shift to mobile applications.
>> I feel it's kind of a similar time then it was in the late 90s
when we were investigating web applications and finding defects like
session management errors and SQL injection
which really didn't exist before, and all of a sudden they were everywhere
in web applications, and now a lot of the time I spend
is looking at mobile applications and looking at what's going on out there in the wild.
Mobile applications are really going to be the dominant computing platform,
so we really need to spend a lot of time if you're in the security industry
focusing on web applications.
There were 29 billion mobile apps downloaded in 2011.
It's predicted to be 76 billion apps by 2014.
There's 686 million devices that are going to be purchased this year,
so this is where people are going to be doing
the majority of their client computing going forward.
>> I was talking to a vice president at Fidelity Investments
a couple months ago, and he said they just saw more traffic
doing financial transactions from their customer base
on their mobile application than on their website,
so a common use for the Web in the past has been
checking your stock quotes, managing your portfolio,
and we're actually seeing that in 2012 switch over
to be more dominant on the mobile platform.
Certainly if there's going to be any criminal activity,
any malicious activity, it's going to start to be focused on the mobile platform
over time as people switch over to that.
If you look at the mobile platform,
to look at the risks of the platform it's useful to break it down into the different layers,
just like you would do it on a desktop computer,
and you think about the different layers, software, operating system,
network layer, hardware layer, and of course, there's vulnerabilities on all those layers.
>> The same thing happens on mobile.
But mobile, it seems that some of those layers are worse off.
For one, the network layer is more problematic on mobile
because a lot of people have in their office or at home
wired connections or they have secure Wi-Fi connections,
and with a lot of mobile devices you're obviously outside of the home
or outside of the office a lot, and if you're using Wi-Fi there
you might be using an insecure Wi-Fi connection,
something that's a public Wi-Fi connection,
so when we think about mobile apps we have to take into account
that the network environment is riskier for those applications
when Wi-Fi is being used.
And when I get into more of the mobile application risks
you'll see why that's more important.
There are risks at the hardware level on mobile devices.
This is an area of ongoing research.
People call these broadband attacks or baseband attacks
where you're attacking the firmware that's listening on the radio.
>> These are really scary attacks because
the user doesn't have to do anything.
You can hit lots of devices within RF range
at once, and it seems like whenever this research bubbles up
it quickly gets classified where
people swoop in around and say, "Here, tell us about that, and please stop talking about it."
There's some research going on in the broadband area,
but it seems to be very hush hush.
I think it's more of a nation state type of research that's going on.
An area of active research, though, is the operating system layer,
and again, this is different than in the desktop computing world
because in the mobile space you have these teams of people called jailbreakers,
and jailbreakers are different than regular vulnerability researchers.
They're trying to find vulnerabilities in the operating system,
but the reason they're trying to find the vulnerabilities is not to
break into someone else's machine and compromise it.
It's to break into their own computer.
>> They want to break into their own mobile, modify their own mobile's operating system
so that they can run the applications of their choice
and change things with full administrative permissions,
and they don't want to tell the vendor about this.
They're not like a security researcher which is a white hat security researcher
which is going to do responsible disclosure and tell the vendor about it.
They want to do this research, and they want to actually publish it
in an exploit or a rootkit or a jailbreak code,
and they want to do it strategically, like right after
the vendor ships the new operating system.
You have this adversarial relationship
with OS-level vulnerabilities on the mobile,
which I think is quite interesting, and one place we see it
is it makes it so that there's good published exploit code out there
for kernel-level vulnerabilities,
and we've seen those actually be used by malware writers.
It's a little bit different than the PC world.
And then the final layer is the top layer, the application layer.
That's what I'm going to talk about today.
>> The other layers exist, and the other layers play into it,
but I'm mostly going to talk about what's going on at the application layer
where code is running in the sandbox.
It doesn't have administrative privileges.
It has to use the APIs of the device,
but still, a lot of malicious activity and a lot of risk can happen at that layer
because that's the layer where all the information is.
Apps can access all the information on the device
if they have the right permissions,
and they can access the different sensors on the device,
GPS sensor, microphone, camera, what have you.
Even though we're only talking about at the application layer
we have a lot of risk there.
The other thing that's different about the mobile environment
is all the operating system players, be it BlackBerry or Android
or iOS or Windows mobile, they all have a fine grained permission model,
and this is one of the ways that they built into the operating system
the idea that it's not as risky as you think.
Even though you have all your contacts on there, all your personal information,
you have your photos, you have your location on there,
you're storing your bank pin for auto login on there, it's safe because
apps have to have certain permissions to get at certain parts
of the information on the device, and the user has to be presented with
these permissions and say okay.
>> The problem with it is the user always says okay.
As a security person, I know you can prompt the user,
say something really bad is going to happen, do you want it to happen?
And if they're in a rush or there's something really enticing on the other side of that,
like a game is going to be installed that they've been waiting for,
they're going to click okay.
That's why I say on my slide here just let me fling birds at pigs already,
and you can see on the slide here there's examples of a BlackBerry permission box.
It says "Please set the BlackBerry Travel application permissions
after clicking button below," and basically the user is just going to say
set the permissions and save.
Here's an Android prompt where it shows things,
and it actually puts something that almost looks like a warning.
It's got a sort of yield sign there saying network communication, phone call,
but the user is going to click install, right?
And then the Apple one is completely innocuous.
It doesn't give any kind of warning.
It's just Apple would like to use your current location.
Of course you're going to click okay.
>> There is this fine-grained permission model,
and apps have to have a manifest file where they declare
the permissions they need, and that will get displayed to the user,
and the user will have to say I grant these permissions.
But let's be honest.
Users are just going to always say okay.
Let's take a quick look at the permissions that these apps are asking for
and some of the permissions that are there.
This company Praetorian did a survey last year
of 53,000 applications analyzed in the Android market and 3rd party markets,
so this is all Android.
And the average app requested 3 permissions.
Some apps requested 117 permissions,
so obviously these are very fine grained and way too complex for a user to understand
if they're presented with this app that needs these 117 permissions.
It's like the end user license agreement that's 45 pages long.
Maybe soon they'll have an option where it's like
print the permissions and send me an email.
>> But if you look at some of the top interesting permissions
24% of the apps that they downloaded out of the 53,000
requested GPS information from the device.
8% read the contacts.
4% sent SMS, and 3% received SMS.
2% recorded audio.
1% processed outgoing calls.
I don't know.
I don't think 4% of the apps in the app store really need to send SMS text messages,
so I think that's a hint that something untoward is going on.
8% of the apps need to read your contacts list.
It's probably not necessary.
One of the other interesting things about permissions is
if you link in shared libraries into your application
those inherit the permissions of the application,
so if your app needs the contact list or needs the GPS location to function
and you link in an advertising library, for instance,
that ad library will also be able to access the contacts
and also be able to access the GPS location,
and the developer of the app knows nothing about the code that's running in the ad library.
They're just linking that in because they want to monetize their app.
>> This is where—and I'll talk about some examples of this with
an application called Pandora where an application developer
might unwittingly be leaking information
from their users because of libraries they've linked in.
Surveying the landscape out there, looking at all the different apps
that have been reported in the news as malicious or doing something users didn't want
and then inspecting a lot of apps—we do a lot of static binary analysis on mobile apps,
so we've inspected them and looked at the code itself—
we came up with what we call our top 10 list of risky behaviors in applications.
And it's broken down into 2 sections, malicious code,
so these are bad things that the apps might be doing that
are likely to be something that a malicious individual
has specifically put in the application, but it's a little bit fuzzy.
It could be something that a developer thinks is fine,
but it ends up being thought of as malicious by the user.
>> And then the second section is what we call coding vulnerabilities,
and these are things where the developer basically is making mistakes
or just doesn't understand how to write the app securely,
and that's putting the app user at risk.
I'm going to go through these in detail and give some examples.
For reference, I wanted to put up the OWASP mobile top 10 list.
These are the 10 issues that a group at OWASP,
the Open Web Application Security Project, they have a working group
working on a mobile top 10 list.
They have a very famous web top 10 list, which are the top 10
riskiest things you can have in a web application.
They're doing the same thing for mobile,
and their list is a little different than ours.
6 out of the 10 are the same.
They have 4 that are different.
I think they have a little bit of a different take on
risk in mobile apps where a lot of their issues
are really how the application is communicating to a back-end server
or what's going on on the back-end server,
not so much apps that have risky behavior that are just straightforward client apps.
>> The ones in red here are the differences between the 2 lists.
And some of my research team has actually contributed to this project,
so we'll see what happens over time, but I think the takeaway here is
we don't really know what the top 10 list is in mobile apps because
they've really only been around for 2 or 3 years now,
and there hasn't been enough time to really research the operating systems
and what they're capable of, and there hasn't been enough time
for the malicious community, if you will, to have spent enough time
trying to attack users through mobile apps, so I expect these lists to change a little bit.
But for now, these are the top 10 things to worry about.
You might wonder on the mobile side where does the malicious mobile code—
how does it get on to the device?
North Carolina State has a project called the Mobile Malware Genome Project
where they are collecting as much mobile malware as they can and analyzing it,
and they've broken down the injection vectors that the mobile malware uses,
and 86% use a technique called repackaging,
and this is only on the Android platform
can you really do this repackaging.
>> The reason is Android code is built with
a Java byte code called Dalvik which is easily decompilable.
What the bad guy can do is
take an Android application, decompile it,
insert their malicious code, recompile it,
and then put it up in the app store purporting to be a new version of that application,
or just maybe changing the name of the application.
If it was some sort of game, change the name slightly,
and so this repackaging is how 86% of mobile malware gets distributed.
There's another technique called update which is
very similar to repackaging, but you actually don't put the malicious code in.
What you do is you put in a small update mechanism.
You decompile, you put in an update mechanism, and you recompile it,
and then when the app is running it pulls down the malware onto the device.
>> By far the majority are those 2 techniques.
There isn't really much download drive-bys or drive-by downloads on mobiles,
which could be like a phishing attack.
Hey, check out this really cool website,
or you need to go to this website and fill out this form
to keep continuing doing something.
Those are phishing attacks.
The same thing can happen on the mobile platform where they
point to a mobile app to download, say "Hi, this is Bank of America."
"We see you're using this application."
"You should download this other application."
Theoretically, that could work.
Maybe it just isn't being used enough to determine whether it's successful or not,
but they found that less than 1% of the time that technique is used.
The majority of the time it's really a repackaged code.
>> There's another category called standalone
where someone just builds a brand-new application.
They build an application that purports to be something.
It's not a repackaging of something else, and that has the malicious code.
That's used 14% of the time.
Now I want to talk about what is the malicious code doing?
One of the first malware out there
you could consider a spyware.
It basically spies on the user.
It collects emails, SMS messages.
It turns on the microphone.
It harvests the contact book, and it sends it off to someone else.
This type of spyware exists on the PC,
so it makes perfect sense for people to try to do this on mobile devices.
>> One of the first examples of this was a program called Secret SMS Replicator.
It was in the Android Marketplace a couple of years ago,
and the idea was if you had access to someone's Android phone
that you wanted to spy on, so maybe it's your spouse
or your significant other and you want to spy on their text messaging,
you could download this app and install it and configure it
to send an SMS text message to you with a copy
of every SMS text message they got.
This obviously is in violations of the app store terms of service,
and this was removed from the Android Marketplace within 18 hours of it being there,
so a very small number of people were at risk because of this.
Now, I think if the program was called something maybe a little less provocative
like Secret SMS Replicator it probably would have worked a lot better.
But it was kind of obvious.
>> One of the things we can do to determine if apps have this behavior that we don't want
is to inspect the code.
This is actually really easy to do on Android because we can decompile the apps.
On iOS you can use a disassembler like IDA Pro
to look at what APIs the app is calling and what it's doing.
We wrote our own binary static analyzer for our code
and we do this, and so what you could do is you could say
does the device do anything that is basically spying on me or tracking me?
And I have some examples here on the iPhone.
This first example is how to access the UUID on the phone.
This is actually something that Apple has just banned for new applications,
but old applications that you might have running on your phone can still do this,
and so that unique identifier can be used to track you
across many different applications.
>> On the Android, I have an example here of getting the device's location.
You can see that if that API call is there that app is tracking,
and you can see whether it's getting fine location or coarse location.
And then on the bottom here, I have an example of how on the BlackBerry
an application might access the email messages in your inbox.
These are the kind of things you can inspect to see
if the app is doing those things.
The second big category of malicious behavior, and this is probably the biggest category now,
is unauthorized dialing, unauthorized premium SMS text messages
or unauthorized payments.
Another thing that's unique about the phone
is the device is hooked to a billing account,
and when activities happen on the phone
it can create charges.
You can purchase things over the phone,
and when you send a premium SMS text message you're actually giving money
to the account holder of the phone number on the other side.
These were set up to get stock quotes or get your daily horoscope or other things,
but they can be set up to order a product by sending an SMS text.
People give money to the Red Cross by sending a text message.
You can give $10 that way.
>> The attackers, what they've done is they set up
accounts in foreign countries, and they embed in the malware
that the phone will send a premium SMS text message,
say, a few times a day, and at the end of the month you realize you've spent
tens or maybe even hundreds of dollars, and they walk away with the money.
This got so bad that this was the very first thing that the Android
Marketplace or the Google place—it was the Android Marketplace at the time,
and it's now Google Play—the first thing that Google started checking for.
When Google started distributing Android apps in their app store
they said they were not going to check for anything.
We'll pull apps once we've been notified they've broken our terms of service,
but we're not going to check for anything.
Well, about a year ago it got so bad with this premium SMS text message malware
that this is the very first thing they started checking for.
If an app can send SMS text messages
they further manually scrutinize that application.
They look for the APIs that call this,
and now since then Google has expanded,
but this was the first thing that they started looking for.
>> Some other apps that did some SMS text messages,
this Android Qicsomos, I guess it is called.
There was this current event on the mobile where this CarrierIQ came out
as spyware put on the device by the carriers,
so people wanted to know if their phone was vulnerable to this,
and this was a free app that tested that.
Well, of course, what this app did was it sent premium SMS text messages,
so by testing to see if you're infected with spyware
you loaded malware onto your device.
We saw the same thing happen at the last Super Bowl.
There was a bogus version of the Madden football game
that sent premium SMS text messages.
It actually tried to create a bot network too on the device.
Here I have some examples.
Interestingly enough, Apple was pretty smart,
and they don't allow applications to send SMS text messages at all.
No app can do it.
That's a great way of getting rid of a whole class of vulnerability,
but on Android you can do it, and of course, on BlackBerry you can do it too.
It's interesting that on the BlackBerry all you need is internet permissions
to send an SMS text message.
>> The other thing really that we look for
when we're looking to see if something is malicious is just any kind of
unauthorized network activity, like look at the network activity
the app is supposed to have to have its functionality,
and look at this other network activity.
Perhaps an app, to work, has to get data over HTTP,
but if it's doing things over email or SMS or Bluetooth or something like that
now that app could potentially be malicious, so this is another thing you can inspect for.
And on this slide here I have some examples of that.
Another interesting thing we saw with malware happened back in 2009,
and it happened in a big way.
I don't know if it's happened so much since then, but it was an app
that impersonated another application.
There was a set of apps, and it was dubbed the 09Droid attack,
and someone decided that there were a lot of small, regional, midsize banks
that didn't have online banking applications,
so what they did was they built about 50 online banking applications
that all they did was take the user name and password
and redirect you to the website.
And so they put these all up in the Google Marketplace,
in the Android Marketplace, and when someone searched to see if their bank
had an application they would find the bogus application,
which collected their credentials and then redirected them to their website.
The way that this actually became—the apps were up there for a few weeks,
and there were thousands and thousands of downloads.
>> The way this came to light was someone was having a problem
with one of the applications, and they called their bank,
and they called their bank's customer support line and said,
"I'm having a problem with your mobile banking application."
"Can you help me out?"
And they said, "We don't have a mobile banking application."
That started the investigation.
That bank called Google, and then Google looked and said,
"Wow, the same author has written 50 bank applications," and took them all down.
But certainly this could happen again.
There's the list of all the different banks here
that were part of this scam.
The other thing an app can do is present the UI of another application.
While it's running it could pop up the Facebook UI.
It says you have to put in your user name and password to continue
or put up any user name and password UI for a website
that maybe the user uses just to try to trick the user
into putting their credentials in.
This is really a straight parallel of the email phishing attacks
where someone sends you an email message
and gives you basically a fake UI for a website
that you have access to.
>> The other thing we look for in malicious code is system modification.
You can look for all the API calls that require root privilege
to execute correctly.
Changing the device's web proxy would be something that an application
shouldn't be able to do.
But if the application has code in there to do that
you know that it's probably a malicious application
or very highly likely to be a malicious application,
and so what would happen is that app would have some way of escalating privilege.
It would have some privilege escalation exploit
in the application, and then once it escalated privileges
it would do these system modifications.
You can find malware that has privilege escalation
in it even without knowing how the privilege escalation
exploit is going to happen, and that's a nice, easy way
to look for malware.
DroidDream was probably the most famous piece of Android malware.
I think it affected about 250,000 users over a few days
before it was found.
They repackaged 50 bogus applications,
put them in the Android app store,
and essentially it used Android jailbreak code to escalate privileges
and then install a command and control and turn all the victims
into a bot net, but you could have detected this
if you were scanning the application and just looking for
API calls that required root permission to execute correctly.
>> And there's an example here I have which is changing the proxy,
and this actually is only available on the Android.
You can see I'm giving you a lot of examples on Android
because this is where the most active malware ecosystem is
because it's really easy for an attacker to get malicious code
into the Android Marketplace.
It's not so easy to do that in the Apple App Store
because Apple requires developers to identify themselves
and sign the code.
They actually check who you are, and Apple is actually scrutinizing the applications.
We don't see a lot of true malware where the device is getting compromised.
I will talk about some examples where it's really privacy that's getting compromised,
and that's what's really happening on the Apple device.
Another thing to look for malicious code, risky code in devices
is logic or time bombs, and time bombs are probably
much easier to look for than logic bombs.
But with time bombs, what you can do is you can look for
places in the code where the time is tested or an absolute time is looked for
before certain functionality in the app happens.
And this could be done to hide that activity from the user,
so it's happening late at night.
DroidDream did all its activity between 11 PM and 8 AM local time
to try to do it while the user might not be using their device.
>> Another reason to do this is if people are using behavioral analysis of an application,
running the app in a sandbox to see what the behavior of the application is,
they can use time-based logic to do the activity
when the app isn't in the sandbox.
For example, an app store like Apple
runs the application, but they probably don't run every application for, say, 30 days
before approving it, so you can put
logic in your application that said, okay, only do the bad thing
after 30 days has gone by or after 30 days after the publish date of the application,
and that can help the malicious code hide from people inspecting for it.
If anti-virus companies are running things in sandboxes
or the app stores themselves are this can help
hide that from that inspection.
Now, the flip side of that is it's easy to find with static analysis,
so actually inspecting the code you can look for all the places
where the application tests the time and inspect that way.
And here I have some examples on these 3 different platforms
how time can be checked for by the app maker
so you know what to look for if you're inspecting the app statically.
>> I just went through a whole bunch of different malicious activities
that we've seen in the wild, but which ones are the most prevalent?
That same study from North Carolina State Mobile Genome Project
published some data, and there were basically 4 areas
that they saw where there was a lot of activity.
37% of the apps did privilege escalation,
so they had some type of jailbreak code in there
where they tried to escalate privileges so that they could
do API commands running as the operating system.
45% of the apps out there did premium SMS,
so that's a huge percentage that is trying to directly monetize.
93% did remote control, so they tried to set up a bot net, a mobile bot net.
And 45% harvested identifying information
like phone numbers, UUIDs, GPS location, user accounts,
and this adds up to more than 100 because most malware tries to do a few of these things.
>> I'm going to switch to the second half and talk about the code vulnerabilities.
This is the second half of the risky activity.
This is where essentially the developer is making errors.
A legitimate developer writing a legitimate app
is making errors or is ignorant of the risks of the mobile platform.
They just don't know how to make a secure mobile app,
or sometimes the developer doesn't care about putting the user at risk.
Sometimes part of their business model might be
harvesting the user's personal information.
That's sort of the other category, and that's why some of this malicious
versus legitimate starts to bleed over because there's difference of opinions
between what the user wants and what the user considers risky
and what the application developer considers risky.
Of course, it's not the application developer's data in most cases.
>> And then finally, another way this happens is a developer might link in
a shared library that has vulnerabilities or this risky behavior in it
unbeknownst to them.
The first category is sensitive data leakage,
and this is when the app collects information
like location, address book information, owner information
and sends that off the device.
And once it's off the device, we don't know what's happening with that information.
It could be stored insecurely by the application developer.
We've seen application developers get compromised,
and the data that they're storing gets taken.
This happened a few months ago to a developer down in Florida
where a huge number of—it was iPad UUIDs and device names
were leaked because someone, I think it was anonymous,
claimed to do this, broke into this developer's servers
and stole millions of iPad UUIDs
and computer names.
Not the most risky information,
but what if that was the storage of user names and passwords
and home addresses?
There's lots of apps that store that kind of information.
The risk is there.
>> The other thing that can happen is if the developer doesn't take care
to secure the data channel, and that's another big vulnerability I'm going to talk about,
that data is being sent in the clear.
If the user is on a public Wi-Fi network
or someone is sniffing the internet somewhere
along the path that data is being exposed.
One very famous case of this information leakage happened with Pandora,
and this is something we researched at Veracode.
We heard that there was a—I think it was a Federal Trade Commission
investigation going on with Pandora.
We said, "What's going on there? Let's start digging into the Pandora application."
And what we determined was the Pandora application collected
your gender and your age,
and it also accessed your GPS location, and the Pandora application
did this for what they said were legitimate reasons.
The music that they were playing—Pandora is a music streaming app—
the music they were playing was only licensed in the United States,
so they had to check to comply with their license agreements that they had
for the music that the user was in the United States.
They also wanted to comply with the parental advisory
around adult language in music,
and so it's a voluntary program, but they wanted to comply with that
and not play explicit lyrics to children 13 and under.
>> They had legitimate reasons for collecting this data.
Their app had the permissions to do it.
Users thought this was legitimate. But what happened?
They linked in 3 or 4 different ad libraries.
Now all of a sudden all these ad libraries
are getting access to this same information.
The ad libraries, if you look at the code in the ad libraries
what they do is every ad library says
"Does my app have permission to get GPS location?"
"Oh, it does? Okay, tell me the GPS location."
Every single ad library does that,
and if the app doesn't have GPS permission
it won't be able to get it, but if it does, it will get it.
This is where the business model of the ad libraries
is opposed to the privacy of the user.
And there's been studies out there that will say if you know the age
of a person and you know their location
where they sleep at night, because you have their GPS coordinates
while they perhaps are sleeping, you know exactly who that person is
because you can determine which member of that household is that person.
Really this is identifying to advertisers
exactly who you are, and it looks like it was legitimate.
I just want my streaming music, and this is the only way to get it.
>> Well, we exposed this.
We wrote this up in several blog posts,
and it turned out that someone from Rolling Stone magazine
read one of our blog posts and wrote their own blog in Rolling Stone about it,
and the very next day Pandora thought it was a good idea
to remove the ad libraries from their application.
As far as I know they're the only—they should be commended.
I think they're the only freemium type of app that has done this.
All the other freemium apps have this same behavior,
so you've got to think about what kind of data you're giving
these freemium applications because it's all going to advertisers.
Praetorian also did a study about shared libraries and said,
"Let's look at what shared libraries are the top shared libraries," and this was the data.
>> They analyzed 53,000 apps,
and the number 1 shared library was Admob.
It was actually in 38% of the applications out there,
so 38% of the applications you're using
are likely harvesting your personal information
and sending it to the ad networks.
Apache and Android were 8% and 6%,
and then these other ones down at the bottom, Google Ads, Flurry,
Mob City and Millennial Media,
these are all ad companies, and then, interestingly enough,
4% linked in the Facebook library
probably to do authentication through Facebook
so the app could authenticate the Facebook.
But that also means the corporation Facebook controls code
that's running in 4% of the Android mobile apps out there,
and they have access to all the data that that app has permission to get at.
Facebook essentially tries to sell advertising space.
That's their business model.
>> If you look at this whole ecosystem with these permissions
and shared libraries you start to see that
you have a lot of risk in a supposedly legitimate application.
The same similar thing that happened with Pandora
happened with an application called Path,
and Path thought they were being helpful, friendly developers.
They were just trying to give you a great user experience,
and it turned out that without prompting the user or telling the user anything—
and this happened on the iPhone and on Android,
the Pandora app was on iPhone and Android—
that the Path application was grabbing your entire address book
and uploading it to Path just when you installed and ran the application,
and they didn't tell you about this.
They thought it was really helpful for you
to be able to share with all the people in your address book
that you're using the Path application.
>> Well, obviously Path thought this was great for their company.
Not so great to the user.
You have to think that it's one thing if maybe a teenager
is using this application and their dozens of friends are in there,
but what if it's the CEO of a company that installs Path
and then all of a sudden their whole address book is up there?
You're going to get a lot of potentially valuable contact information
for a lot of people.
A reporter from the New York Times, you might be able to get the phone number
for ex presidents from their address book,
so obviously a lot of sensitive information gets transferred with something like this.
There was such a big flap about this that Path apologized.
They changed their app, and it even impacted Apple.
Apple said, "We're going to force app vendors to prompt users
if they're going to collect their entire address book."
>> It looks like what's happening here is
when there's one big privacy violation and it makes the press
we see a change out there.
But of course, there's other things out there.
The LinkedIn application harvests your calendar entries,
but Apple doesn't make the user be prompted about that.
Calendar entries can have sensitive information in them too.
Where are you going to draw the line?
This is really kind of an evolving place
where there's really no good standard out there
for the users to understand when their information is going to be at risk
and when they're going to know it's being taken.
We wrote an app at Veracode called Adios,
and essentially it allowed you to point the app at your iTunes directory
and look at all the applications that were harvesting your full address book.
And as you can see on this list here, Angry Birds,
AIM, AroundMe.
Why does Angry Birds need your address book?
I don't know, but it does somehow.
>> This is something that many, many applications do.
You can inspect the code for this.
There's well-defined APIs for iPhone, Android and BlackBerry
to get at the address book.
You can really easily inspect for this, and this is what we did in our Adios application.
The next category, Unsafe Sensitive Data Storage,
is something where developers take something like a pin or an account number
or a password and store it in the clear on the device.
Even worse, they might store it in an area on the phone
which is globally accessible, like the SD card.
You see this more often on Android because Android allows for an SD card.
IPhone devices don't.
But we even saw this happen in a CitiGroup application.
Their online banking application stored the account numbers insecurely,
just in the clear, so if you lost your device,
essentially you lost your bank account.
This is why I personally don't do banking on my iPhone.
I think it's too risky right now to do these kinds of activities.
>> Skype did the same thing.
Skype, of course, has an account balance, a user name and password
that access that balance.
They were storing all that information in the clear on the mobile device.
I have some examples here of creating files
that don't have the right permissions or writing to disc
and not having any encryption happen for that.
This next area, Unsafe Sensitive Data Transmission,
I've alluded to this a few times, and because of public Wi-Fi
this is something that apps absolutely need to do,
and this is probably what we see go wrong the most.
I would say—actually, I think I have the actual data,
but it's close to half the mobile applications
screw up doing SSL.
They just don't use the APIs correctly.
I mean, all you've got to do is follow the instructions and use the APIs,
but they do things like not check whether there is an invalid certificate at the other end,
not check if the other end is trying to do a protocol downgrade attack.
>> The developers, they want to get their checkbox, right?
Their requirement is to use this to sell. They've used this to sell.
The requirement isn't to use this to sell securely,
and so this is why all applications that use SSL to secure data
as it's being transmitted off the device really need to be inspected
to make sure that was implemented correctly.
And here I have some examples where you can see an application
might be using HTTP instead of HTTPS.
In some cases apps will fall back to HTTP
if the HTTPS isn't working.
I have another call here on Android where they've disabled the certificate check,
so a man-in-the-middle attack can happen.
An invalid certificate will be accepted.
These are all cases where attackers are going to be able to get on
the same Wi-Fi connection as the user and access all the data
that's being sent over the internet.
>> And finally, the last category I have here is hardcoded password and keys.
We actually see a lot of developers use the same coding style
that they did when they were building web server applications,
so they're building a Java server application, and they're hardcoding the key.
Well, when you're building a server application, yeah,
hardcoding the key is not a good idea.
It makes it difficult to change.
But it's not so bad on the server side because who has access to the server side?
Only the administrators.
But if you take the same code and you poured it over to a mobile application
now everyone who has that mobile application has access to that hardcoded key,
and we actually see this a lot of times, and I have some statistics
on how often we see this happen.
It actually was in example code that MasterCard published
on how to use their service.
The example code showed how you would just take the password
and put it in a hardcoded string right there,
and we know how developers love to copy and paste code snippets
when they're trying to do something, so you copy and paste the code snippet
that they gave as example code, and you have an insecure application.
>> And here we have some examples.
This first one is one we see a lot where they hardcode
the data right into a URL that gets sent.
Sometimes we see string password = the password.
That's pretty easy to detect, or string password on BlackBerry and Android.
It's actually pretty easy to check for because almost always
the developer names the variable that's holding the password
some variation of password.
I mentioned that we do static analysis at Veracode,
so we've analyzed several hundred Android and iOS applications.
We've built full models of them, and we're able to scan them
for different vulnerabilities, especially the vulnerabilities I was talking about,
and I have some data here.
68.5% of the Android apps we looked at
had broken cryptographic code,
which for us, we can't detect if you made your own crypto routine,
not that that's a good idea, but this is actually using the published APIs
that are on the platform but doing them in such a way
that the crypto would be vulnerable, 68.5.
And this is for people that are sending us their applications actually because
they think it's a good idea to do security testing.
These are already people that are probably thinking securely,
so it's probably even worse.
>> I didn't talk about control line feed injection.
It's something we check for, but it's not that risky an issue.
Information leakage, this is where sensitive data is being sent off the device.
We found that in 40% of the applications.
Time and state, those are race condition type issues, typically pretty hard to exploit,
so I didn't talk about that, but we looked at it.
23% had SQL injection issues.
A lot of people don't know that a lot of applications
use a small little SQL database on their back end to store data.
Well, if the data that you're grabbing over the network
has SQL injection attack strings in it
someone can compromise the device through that,
and so I think we find about 40% of web applications have this problem,
which is a huge epidemic problem.
We find it 23% of the time in mobile apps
and that's probably because many more web applications use SQL than mobile.
>> And then we still see some cross-site scripting, authorization issues,
and then credential management, that's where you have your hardcoded password.
In 5% of the applications we see that.
And then we have some data on iOS.
81% had error handling issues.
This is more of a code quality problem,
but 67% had cryptographic issues, so not quite as bad as Android.
Maybe the APIs are a little bit easier, the example codes a little better on iOS.
But still a very high percentage.
We had 54% with information leakage,
about 30% with buffer management errors.
That's places where there could potentially be a memory corruption issue.
It turns out that that's not as much of a problem for exploitation
on iOS because all the code has to be signed,
so it's hard for an attacker to execute arbitrary code on iOS.
Code quality, directory traversal, but then credentials management here at 14.6%,
so worse than on the Android.
We have people not handling passwords correctly.
And then the numeric errors and buffer overflow,
those are more going to be code quality issues on iOS.
>> That was it for my presentation. I don't know if we're out of time or not.
I don't know if there's any questions.
[Male] A quick question around fragmentation and the Android market.
Apple at least owns patching.
They do a good job of getting it out there whereas less so in the Android space.
You almost need to jailbreak your phone to stay current
with the current release of Android.
Yeah, that's a huge problem and so if you think about—
[Male] Why can't you repeat it?
>> Oh, right, so the question was what about fragmentation
of the operating system on the Android platform?
How does that affect the riskiness of those devices?
And it actually is a huge problem because what happens is
the older devices, when someone comes up with a jailbreak for that device,
essentially that's privilege escalation, and until that operating system is updated
any malware can then use that vulnerability to totally compromise the device,
and what we're seeing on the Android is in order to get a new operating system
Google has to put out the operating system, and then the hardware manufacturer
has to customize it, and then the carrier has to customize it and deliver it.
You have basically 3 moving parts here,
and it's turning out that the carriers don't care,
and the hardware manufacturers don't care, and Google is not prodding them enough
to do anything, so essentially over half of the devices out there
have operating systems that have these privilege escalation vulnerabilities in them,
and so if you get malware on your Android device it's much more of a problem.
>> Okay, thank you very much.
[Applause]
[CS50.TV]