1
00:00:00,000 --> 00:00:02,610
[Seminar] [Defending Behind the Device: Mobile Application Security]

2
00:00:02,610 --> 00:00:04,380
[Chris Wysopal] [Harvard University]

3
00:00:04,380 --> 00:00:07,830
[This is CS50.] [CS50.TV]

4
00:00:07,830 --> 00:00:10,360
>> Good afternoon. My name is Chris Wysopal.

5
00:00:10,360 --> 00:00:13,360
I'm the CTO and co-founder of Veracode.

6
00:00:13,360 --> 00:00:15,880
Veracode is an application security company.

7
00:00:15,880 --> 00:00:18,230
We test all kinds of different applications,

8
00:00:18,230 --> 00:00:25,060
and what I'm going to talk about today is mobile application security.

9
00:00:25,060 --> 00:00:28,630
My background is I've been doing security research 

10
00:00:28,630 --> 00:00:31,970
for a very long time, probably about as long as anybody.

11
00:00:31,970 --> 00:00:35,000
I started in the mid 90s,

12
00:00:35,000 --> 00:00:37,370
and it was a time that was pretty interesting because 

13
00:00:37,370 --> 00:00:39,220
we had a paradigm change in the mid 90s.

14
00:00:39,220 --> 00:00:43,520
All of a sudden everyone's computer was hooked up to the internet,

15
00:00:43,520 --> 00:00:46,550
and then we had the beginnings of web applications,

16
00:00:46,550 --> 00:00:49,330
and that's what I focused on a lot then.

17
00:00:49,330 --> 00:00:51,160
It's interesting. 

18
00:00:51,160 --> 00:00:53,930
Now we have another paradigm change happening with computing,

19
00:00:53,930 --> 00:00:58,710
which is the shift to mobile applications.

20
00:00:58,710 --> 00:01:03,680
>> I feel it's kind of a similar time then it was in the late 90s

21
00:01:03,680 --> 00:01:07,650
when we were investigating web applications and finding defects like

22
00:01:07,650 --> 00:01:11,800
session management errors and SQL injection

23
00:01:11,800 --> 00:01:14,940
which really didn't exist before, and all of a sudden they were everywhere

24
00:01:14,940 --> 00:01:19,360
in web applications, and now a lot of the time I spend

25
00:01:19,360 --> 00:01:27,950
is looking at mobile applications and looking at what's going on out there in the wild.

26
00:01:27,950 --> 00:01:32,060
Mobile applications are really going to be the dominant computing platform,

27
00:01:32,060 --> 00:01:35,060
so we really need to spend a lot of time if you're in the security industry

28
00:01:35,060 --> 00:01:39,280
focusing on web applications.

29
00:01:39,280 --> 00:01:43,420
There were 29 billion mobile apps downloaded in 2011.

30
00:01:43,420 --> 00:01:47,920
It's predicted to be 76 billion apps by 2014.

31
00:01:47,920 --> 00:01:54,040
There's 686 million devices that are going to be purchased this year,

32
00:01:54,040 --> 00:01:57,060
so this is where people are going to be doing

33
00:01:57,060 --> 00:01:59,600
 the majority of their client computing going forward.

34
00:01:59,600 --> 00:02:04,220
>> I was talking to a vice president at Fidelity Investments

35
00:02:04,220 --> 00:02:08,780
a couple months ago, and he said they just saw more traffic

36
00:02:08,780 --> 00:02:12,610
doing financial transactions from their customer base

37
00:02:12,610 --> 00:02:16,230
on their mobile application than on their website,

38
00:02:16,230 --> 00:02:20,610
so a common use for the Web in the past has been

39
00:02:20,610 --> 00:02:23,800
checking your stock quotes, managing your portfolio,

40
00:02:23,800 --> 00:02:28,060
and we're actually seeing that in 2012 switch over

41
00:02:28,060 --> 00:02:30,960
to be more dominant on the mobile platform.

42
00:02:30,960 --> 00:02:34,530
Certainly if there's going to be any criminal activity,

43
00:02:34,530 --> 00:02:38,900
any malicious activity, it's going to start to be focused on the mobile platform

44
00:02:38,900 --> 00:02:44,210
over time as people switch over to that.

45
00:02:44,210 --> 00:02:48,320
If you look at the mobile platform,

46
00:02:48,320 --> 00:02:54,380
to look at the risks of the platform it's useful to break it down into the different layers,

47
00:02:54,380 --> 00:02:59,010
just like you would do it on a desktop computer,

48
00:02:59,010 --> 00:03:02,860
and you think about the different layers, software, operating system,

49
00:03:02,860 --> 00:03:07,730
network layer, hardware layer, and of course, there's vulnerabilities on all those layers.

50
00:03:07,730 --> 00:03:10,510
>> The same thing happens on mobile.

51
00:03:10,510 --> 00:03:14,880
But mobile, it seems that some of those layers are worse off.

52
00:03:14,880 --> 00:03:19,840
For one, the network layer is more problematic on mobile

53
00:03:19,840 --> 00:03:25,650
because a lot of people have in their office or at home

54
00:03:25,650 --> 00:03:30,780
wired connections or they have secure Wi-Fi connections,

55
00:03:30,780 --> 00:03:36,530
and with a lot of mobile devices you're obviously outside of the home

56
00:03:36,530 --> 00:03:40,520
or outside of the office a lot, and if you're using Wi-Fi there

57
00:03:40,520 --> 00:03:42,820
you might be using an insecure Wi-Fi connection, 

58
00:03:42,820 --> 00:03:45,570
something that's a public Wi-Fi connection,

59
00:03:45,570 --> 00:03:48,840
so when we think about mobile apps we have to take into account

60
00:03:48,840 --> 00:03:53,770
that the network environment is riskier for those applications

61
00:03:53,770 --> 00:03:57,640
when Wi-Fi is being used.

62
00:03:57,640 --> 00:04:02,410
And when I get into more of the mobile application risks 

63
00:04:02,410 --> 00:04:04,910
you'll see why that's more important.

64
00:04:04,910 --> 00:04:09,710
There are risks at the hardware level on mobile devices.

65
00:04:09,710 --> 00:04:11,670
This is an area of ongoing research.

66
00:04:11,670 --> 00:04:15,910
People call these broadband attacks or baseband attacks

67
00:04:15,910 --> 00:04:21,870
where you're attacking the firmware that's listening on the radio.

68
00:04:21,870 --> 00:04:25,430
>> These are really scary attacks because 

69
00:04:25,430 --> 00:04:27,280
the user doesn't have to do anything.

70
00:04:27,280 --> 00:04:30,760
You can hit lots of devices within RF range

71
00:04:30,760 --> 00:04:36,690
at once, and it seems like whenever this research bubbles up

72
00:04:36,690 --> 00:04:40,750
it quickly gets classified where

73
00:04:40,750 --> 00:04:46,600
people swoop in around and say, "Here, tell us about that, and please stop talking about it."

74
00:04:46,600 --> 00:04:49,460
There's some research going on in the broadband area,

75
00:04:49,460 --> 00:04:51,980
but it seems to be very hush hush.

76
00:04:51,980 --> 00:04:56,910
I think it's more of a nation state type of research that's going on.

77
00:04:56,910 --> 00:05:02,140
An area of active research, though, is the operating system layer,

78
00:05:02,140 --> 00:05:08,910
and again, this is different than in the desktop computing world

79
00:05:08,910 --> 00:05:14,840
because in the mobile space you have these teams of people called jailbreakers,

80
00:05:14,840 --> 00:05:18,670
and jailbreakers are different than regular vulnerability researchers.

81
00:05:18,670 --> 00:05:21,970
They're trying to find vulnerabilities in the operating system,

82
00:05:21,970 --> 00:05:27,000
but the reason they're trying to find the vulnerabilities is not to

83
00:05:27,000 --> 00:05:31,810
break into someone else's machine and compromise it.

84
00:05:31,810 --> 00:05:34,280
It's to break into their own computer.

85
00:05:34,280 --> 00:05:38,820
>> They want to break into their own mobile, modify their own mobile's operating system

86
00:05:38,820 --> 00:05:41,050
so that they can run the applications of their choice 

87
00:05:41,050 --> 00:05:44,510
and change things with full administrative permissions,

88
00:05:44,510 --> 00:05:49,050
and they don't want to tell the vendor about this.

89
00:05:49,050 --> 00:05:52,960
They're not like a security researcher which is a white hat security researcher

90
00:05:52,960 --> 00:05:56,600
which is going to do responsible disclosure and tell the vendor about it.

91
00:05:56,600 --> 00:06:01,270
They want to do this research, and they want to actually publish it

92
00:06:01,270 --> 00:06:06,400
in an exploit or a rootkit or a jailbreak code,

93
00:06:06,400 --> 00:06:10,010
and they want to do it strategically, like right after 

94
00:06:10,010 --> 00:06:13,570
the vendor ships the new operating system.

95
00:06:13,570 --> 00:06:16,350
You have this adversarial relationship 

96
00:06:16,350 --> 00:06:19,000
with OS-level vulnerabilities on the mobile, 

97
00:06:19,000 --> 00:06:23,150
which I think is quite interesting, and one place we see it

98
00:06:23,150 --> 00:06:29,210
is it makes it so that there's good published exploit code out there

99
00:06:29,210 --> 00:06:31,750
for kernel-level vulnerabilities, 

100
00:06:31,750 --> 00:06:35,040
and we've seen those actually be used by malware writers.

101
00:06:35,040 --> 00:06:38,450
It's a little bit different than the PC world.

102
00:06:38,450 --> 00:06:42,530
And then the final layer is the top layer, the application layer.

103
00:06:42,530 --> 00:06:45,250
That's what I'm going to talk about today.

104
00:06:45,250 --> 00:06:48,970
>> The other layers exist, and the other layers play into it,

105
00:06:48,970 --> 00:06:53,310
but I'm mostly going to talk about what's going on at the application layer

106
00:06:53,310 --> 00:06:55,560
where code is running in the sandbox.

107
00:06:55,560 --> 00:06:58,670
It doesn't have administrative privileges.

108
00:06:58,670 --> 00:07:02,170
It has to use the APIs of the device,

109
00:07:02,170 --> 00:07:06,970
but still, a lot of malicious activity and a lot of risk can happen at that layer

110
00:07:06,970 --> 00:07:09,220
because that's the layer where all the information is.

111
00:07:09,220 --> 00:07:12,330
Apps can access all the information on the device

112
00:07:12,330 --> 00:07:15,390
if they have the right permissions,

113
00:07:15,390 --> 00:07:17,540
and they can access the different sensors on the device,

114
00:07:17,540 --> 00:07:23,950
GPS sensor, microphone, camera, what have you.

115
00:07:23,950 --> 00:07:27,380
Even though we're only talking about at the application layer

116
00:07:27,380 --> 00:07:33,700
we have a lot of risk there.

117
00:07:33,700 --> 00:07:38,450
The other thing that's different about the mobile environment

118
00:07:38,450 --> 00:07:45,060
is all the operating system players, be it BlackBerry or Android 

119
00:07:45,060 --> 00:07:53,410
or iOS or Windows mobile, they all have a fine grained permission model,

120
00:07:53,410 --> 00:07:56,990
and this is one of the ways that they built into the operating system

121
00:07:56,990 --> 00:08:01,230
the idea that it's not as risky as you think.

122
00:08:01,230 --> 00:08:04,550
Even though you have all your contacts on there, all your personal information,

123
00:08:04,550 --> 00:08:09,080
you have your photos, you have your location on there,

124
00:08:09,080 --> 00:08:14,820
you're storing your bank pin for auto login on there, it's safe because 

125
00:08:14,820 --> 00:08:19,430
apps have to have certain permissions to get at certain parts

126
00:08:19,430 --> 00:08:25,080
of the information on the device, and the user has to be presented with

127
00:08:25,080 --> 00:08:29,230
these permissions and say okay.

128
00:08:29,230 --> 00:08:32,590
>> The problem with it is the user always says okay.

129
00:08:32,590 --> 00:08:35,240
As a security person, I know you can prompt the user,

130
00:08:35,240 --> 00:08:40,100
say something really bad is going to happen, do you want it to happen?

131
00:08:40,100 --> 00:08:44,680
And if they're in a rush or there's something really enticing on the other side of that,

132
00:08:44,680 --> 00:08:47,760
like a game is going to be installed that they've been waiting for,

133
00:08:47,760 --> 00:08:50,860
they're going to click okay.

134
00:08:50,860 --> 00:08:56,630
That's why I say on my slide here just let me fling birds at pigs already,

135
00:08:56,630 --> 00:09:03,150
and you can see on the slide here there's examples of a BlackBerry permission box.

136
00:09:03,150 --> 00:09:05,990
It says "Please set the BlackBerry Travel application permissions

137
00:09:05,990 --> 00:09:09,720
after clicking button below," and basically the user is just going to say 

138
00:09:09,720 --> 00:09:12,240
set the permissions and save.

139
00:09:12,240 --> 00:09:18,010
Here's an Android prompt where it shows things,

140
00:09:18,010 --> 00:09:20,260
and it actually puts something that almost looks like a warning.

141
00:09:20,260 --> 00:09:25,090
It's got a sort of yield sign there saying network communication, phone call,

142
00:09:25,090 --> 00:09:28,120
but the user is going to click install, right?

143
00:09:28,120 --> 00:09:32,940
And then the Apple one is completely innocuous.

144
00:09:32,940 --> 00:09:34,300
It doesn't give any kind of warning.

145
00:09:34,300 --> 00:09:37,380
It's just Apple would like to use your current location.

146
00:09:37,380 --> 00:09:39,670
Of course you're going to click okay.

147
00:09:39,670 --> 00:09:42,260
>> There is this fine-grained permission model,

148
00:09:42,260 --> 00:09:45,890
and apps have to have a manifest file where they declare

149
00:09:45,890 --> 00:09:49,410
the permissions they need, and that will get displayed to the user,

150
00:09:49,410 --> 00:09:53,480
and the user will have to say I grant these permissions.

151
00:09:53,480 --> 00:09:55,080
But let's be honest.

152
00:09:55,080 --> 00:09:58,400
Users are just going to always say okay.

153
00:09:58,400 --> 00:10:04,460
Let's take a quick look at the permissions that these apps are asking for

154
00:10:04,460 --> 00:10:06,850
and some of the permissions that are there.

155
00:10:06,850 --> 00:10:09,950
This company  Praetorian did a survey last year

156
00:10:09,950 --> 00:10:14,170
of 53,000 applications analyzed in the Android market and 3rd party markets,

157
00:10:14,170 --> 00:10:16,770
so this is all Android.

158
00:10:16,770 --> 00:10:19,670
And the average app requested 3 permissions.

159
00:10:19,670 --> 00:10:23,370
Some apps requested 117 permissions,

160
00:10:23,370 --> 00:10:27,480
so obviously these are very fine grained and way too complex for a user to understand

161
00:10:27,480 --> 00:10:31,600
if they're presented with this app that needs these 117 permissions.

162
00:10:31,600 --> 00:10:37,270
It's like the end user license agreement that's 45 pages long.

163
00:10:37,270 --> 00:10:40,240
Maybe soon they'll have an option where it's like 

164
00:10:40,240 --> 00:10:43,100
print the permissions and send me an email.

165
00:10:43,100 --> 00:10:45,480
>> But if you look at some of the top interesting permissions

166
00:10:45,480 --> 00:10:50,840
24% of the apps that they downloaded out of the 53,000

167
00:10:50,840 --> 00:10:57,230
requested GPS information from the device.

168
00:10:57,230 --> 00:10:59,810
8% read the contacts.

169
00:10:59,810 --> 00:11:03,770
4% sent SMS, and 3% received SMS.

170
00:11:03,770 --> 00:11:07,730
2% recorded audio.

171
00:11:07,730 --> 00:11:11,210
1% processed outgoing calls.

172
00:11:11,210 --> 00:11:13,140
I don't know. 

173
00:11:13,140 --> 00:11:17,520
I don't think 4% of the apps in the app store really need to send SMS text messages,

174
00:11:17,520 --> 00:11:21,410
so I think that's a hint that something untoward is going on.

175
00:11:21,410 --> 00:11:24,350
8% of the apps need to read your contacts list.

176
00:11:24,350 --> 00:11:26,510
It's probably not necessary.

177
00:11:26,510 --> 00:11:30,990
One of the other interesting things about permissions is

178
00:11:30,990 --> 00:11:36,740
if you link in shared libraries into your application

179
00:11:36,740 --> 00:11:39,780
those inherit the permissions of the application,

180
00:11:39,780 --> 00:11:46,570
so if your app needs the contact list or needs the GPS location to function 

181
00:11:46,570 --> 00:11:49,940
and you link in an advertising library, for instance,

182
00:11:49,940 --> 00:11:53,170
that ad library will also be able to access the contacts

183
00:11:53,170 --> 00:11:57,630
and also be able to access the GPS location,

184
00:11:57,630 --> 00:12:01,990
and the developer of the app knows nothing about the code that's running in the ad library.

185
00:12:01,990 --> 00:12:05,370
They're just linking that in because they want to monetize their app.

186
00:12:05,370 --> 00:12:09,820
>> This is where—and I'll talk about some examples of this with 

187
00:12:09,820 --> 00:12:13,930
an application called Pandora where an application developer

188
00:12:13,930 --> 00:12:18,910
might unwittingly be leaking information

189
00:12:18,910 --> 00:12:24,580
from their users because of libraries they've linked in.

190
00:12:24,580 --> 00:12:30,110
Surveying the landscape out there, looking at all the different apps

191
00:12:30,110 --> 00:12:34,310
that have been reported in the news as malicious or doing something users didn't want

192
00:12:34,310 --> 00:12:39,360
and then inspecting a lot of apps—we do a lot of static binary analysis on mobile apps,

193
00:12:39,360 --> 00:12:42,010
so we've inspected them and looked at the code itself—

194
00:12:42,010 --> 00:12:49,640
we came up with what we call our top 10 list of risky behaviors in applications.

195
00:12:49,640 --> 00:12:54,180
And it's broken down into 2 sections, malicious code,

196
00:12:54,180 --> 00:12:57,600
so these are bad things that the apps might be doing that

197
00:12:57,600 --> 00:13:06,520
are likely to be something that a malicious individual

198
00:13:06,520 --> 00:13:10,060
has specifically put in the application, but it's a little bit fuzzy.

199
00:13:10,060 --> 00:13:13,300
It could be something that a developer thinks is fine,

200
00:13:13,300 --> 00:13:16,350
but it ends up being thought of as malicious by the user.

201
00:13:16,350 --> 00:13:19,830
>> And then the second section is what we call coding vulnerabilities,

202
00:13:19,830 --> 00:13:24,600
and these are things where the developer basically is making mistakes

203
00:13:24,600 --> 00:13:27,200
or just doesn't understand how to write the app securely,

204
00:13:27,200 --> 00:13:30,260
 and that's putting the app user at risk.

205
00:13:30,260 --> 00:13:34,060
I'm going to go through these in detail and give some examples.

206
00:13:34,060 --> 00:13:39,620
For reference, I wanted to put up the OWASP mobile top 10 list.

207
00:13:39,620 --> 00:13:43,590
These are the 10 issues that a group at OWASP, 

208
00:13:43,590 --> 00:13:48,900
the Open Web Application Security Project, they have a working group

209
00:13:48,900 --> 00:13:50,620
working on a mobile top 10 list.

210
00:13:50,620 --> 00:13:54,600
They have a very famous web top 10 list, which are the top 10

211
00:13:54,600 --> 00:13:57,180
riskiest things you can have in a web application.

212
00:13:57,180 --> 00:13:59,090
They're doing the same thing for mobile,

213
00:13:59,090 --> 00:14:01,750
and their list is a little different than ours.

214
00:14:01,750 --> 00:14:03,670
6 out of the 10 are the same.

215
00:14:03,670 --> 00:14:06,020
They have 4 that are different.

216
00:14:06,020 --> 00:14:10,550
I think they have a little bit of a different take on 

217
00:14:10,550 --> 00:14:14,490
risk in mobile apps where a lot of their issues

218
00:14:14,490 --> 00:14:20,490
are really how the application is communicating to a back-end server

219
00:14:20,490 --> 00:14:23,100
or what's going on on the back-end server,

220
00:14:23,100 --> 00:14:29,220
not so much apps that have risky behavior that are just straightforward client apps.

221
00:14:29,220 --> 00:14:36,640
>> The ones in red here are the differences between the 2 lists.

222
00:14:36,640 --> 00:14:40,740
And some of my research team has actually contributed to this project,

223
00:14:40,740 --> 00:14:44,570
so we'll see what happens over time, but I think the takeaway here is

224
00:14:44,570 --> 00:14:47,550
we don't really know what the top 10 list is in mobile apps because 

225
00:14:47,550 --> 00:14:50,510
they've really only been around for 2 or 3 years now,

226
00:14:50,510 --> 00:14:57,750
and there hasn't been enough time to really research the operating systems

227
00:14:57,750 --> 00:15:00,450
and what they're capable of, and there hasn't been enough time

228
00:15:00,450 --> 00:15:06,870
for the malicious community, if you will, to have spent enough time

229
00:15:06,870 --> 00:15:12,910
trying to attack users through mobile apps, so I expect these lists to change a little bit.

230
00:15:12,910 --> 00:15:18,720
But for now, these are the top 10 things to worry about.

231
00:15:18,720 --> 00:15:24,150
You might wonder on the mobile side where does the malicious mobile code—

232
00:15:24,150 --> 00:15:28,880
how does it get on to the device?

233
00:15:28,880 --> 00:15:35,210
North Carolina State has a project called the Mobile Malware Genome Project

234
00:15:35,210 --> 00:15:39,520
where they are collecting as much mobile malware as they can and analyzing it,

235
00:15:39,520 --> 00:15:45,270
and they've broken down the injection vectors that the mobile malware uses,

236
00:15:45,270 --> 00:15:51,490
and 86% use a technique called repackaging,

237
00:15:51,490 --> 00:15:54,160
and this is only on the Android platform

238
00:15:54,160 --> 00:15:56,720
can you really do this repackaging.

239
00:15:56,720 --> 00:16:03,100
>> The reason is Android code is built with

240
00:16:03,100 --> 00:16:08,130
a Java byte code called Dalvik which is easily decompilable.

241
00:16:08,130 --> 00:16:12,460
What the bad guy can do is 

242
00:16:12,460 --> 00:16:16,590
take an Android application, decompile it,

243
00:16:16,590 --> 00:16:20,120
insert their malicious code, recompile it,

244
00:16:20,120 --> 00:16:28,070
and then put it up in the app store purporting to be a new version of that application,

245
00:16:28,070 --> 00:16:30,330
or just maybe changing the name of the application.

246
00:16:30,330 --> 00:16:35,140
If it was some sort of game, change the name slightly,

247
00:16:35,140 --> 00:16:42,860
and so this repackaging is how 86% of mobile malware gets distributed.

248
00:16:42,860 --> 00:16:45,810
There's another technique called update which is

249
00:16:45,810 --> 00:16:50,030
very similar to repackaging, but you actually don't put the malicious code in.

250
00:16:50,030 --> 00:16:52,870
What you do is you put in a small update mechanism.

251
00:16:52,870 --> 00:16:56,660
You decompile, you put in an update mechanism, and you recompile it,

252
00:16:56,660 --> 00:17:02,360
and then when the app is running it pulls down the malware onto the device.

253
00:17:02,360 --> 00:17:06,300
>> By far the majority are those 2 techniques.

254
00:17:06,300 --> 00:17:12,710
There isn't really much download drive-bys or drive-by downloads on mobiles,

255
00:17:12,710 --> 00:17:15,890
which could be like a phishing attack.

256
00:17:15,890 --> 00:17:18,200
Hey, check out this really cool website, 

257
00:17:18,200 --> 00:17:21,020
or you need to go to this website and fill out this form

258
00:17:21,020 --> 00:17:24,420
to keep continuing doing something.

259
00:17:24,420 --> 00:17:26,230
Those are phishing attacks.

260
00:17:26,230 --> 00:17:28,160
The same thing can happen on the mobile platform where they

261
00:17:28,160 --> 00:17:33,830
point to a mobile app to download, say "Hi, this is Bank of America."

262
00:17:33,830 --> 00:17:36,070
"We see you're using this application."

263
00:17:36,070 --> 00:17:38,540
"You should download this other application."

264
00:17:38,540 --> 00:17:41,170
Theoretically, that could work.

265
00:17:41,170 --> 00:17:48,610
Maybe it just isn't being used enough to determine whether it's successful or not,

266
00:17:48,610 --> 00:17:51,680
but they found that less than 1% of the time that technique is used.

267
00:17:51,680 --> 00:17:56,130
The majority of the time it's really a repackaged code.

268
00:17:56,130 --> 00:17:58,710
>> There's another category called standalone

269
00:17:58,710 --> 00:18:01,420
where someone just builds a brand-new application.

270
00:18:01,420 --> 00:18:04,020
They build an application that purports to be something.

271
00:18:04,020 --> 00:18:07,360
It's not a repackaging of something else, and that has the malicious code.

272
00:18:07,360 --> 00:18:11,230
That's used 14% of the time.

273
00:18:11,230 --> 00:18:17,880
Now I want to talk about what is the malicious code doing?

274
00:18:17,880 --> 00:18:23,070
One of the first malware out there

275
00:18:23,070 --> 00:18:25,490
you could consider a spyware.

276
00:18:25,490 --> 00:18:27,620
It basically spies on the user.

277
00:18:27,620 --> 00:18:30,470
It collects emails, SMS messages.

278
00:18:30,470 --> 00:18:32,340
It turns on the microphone.

279
00:18:32,340 --> 00:18:37,330
It harvests the contact book, and it sends it off to someone else.

280
00:18:37,330 --> 00:18:40,870
This type of spyware exists on the PC,

281
00:18:40,870 --> 00:18:46,200
so it makes perfect sense for people to try to do this on mobile devices.

282
00:18:46,200 --> 00:18:53,230
>> One of the first examples of this was a program called Secret SMS Replicator.

283
00:18:53,230 --> 00:18:56,250
It was in the Android Marketplace a couple of years ago,

284
00:18:56,250 --> 00:18:59,960
and the idea was if you had access to someone's Android phone 

285
00:18:59,960 --> 00:19:03,450
that you wanted to spy on, so maybe it's your spouse

286
00:19:03,450 --> 00:19:07,600
or your significant other and you want to spy on their text messaging,

287
00:19:07,600 --> 00:19:11,200
you could download this app and install it and configure it

288
00:19:11,200 --> 00:19:16,540
to send an SMS text message to you with a copy

289
00:19:16,540 --> 00:19:21,710
of every SMS text message they got.

290
00:19:21,710 --> 00:19:27,220
This obviously is in violations of the app store terms of service,

291
00:19:27,220 --> 00:19:32,040
and this was removed from the Android Marketplace within 18 hours of it being there,

292
00:19:32,040 --> 00:19:36,760
so a very small number of people were at risk because of this.

293
00:19:36,760 --> 00:19:42,510
Now, I think if the program was called something maybe a little less provocative

294
00:19:42,510 --> 00:19:48,690
like Secret SMS Replicator it probably would have worked a lot better.

295
00:19:48,690 --> 00:19:52,870
But it was kind of obvious.

296
00:19:52,870 --> 00:19:58,680
>> One of the things we can do to determine if apps have this behavior that we don't want

297
00:19:58,680 --> 00:20:01,410
is to inspect the code.

298
00:20:01,410 --> 00:20:06,250
This is actually really easy to do on Android because we can decompile the apps.

299
00:20:06,250 --> 00:20:11,050
On iOS you can use a disassembler like IDA Pro

300
00:20:11,050 --> 00:20:17,190
to look at what APIs the app is calling and what it's doing.

301
00:20:17,190 --> 00:20:20,680
We wrote our own binary static analyzer for our code

302
00:20:20,680 --> 00:20:24,940
and we do this, and so what you could do is you could say 

303
00:20:24,940 --> 00:20:30,490
does the device do anything that is basically spying on me or tracking me?

304
00:20:30,490 --> 00:20:33,360
And I have some examples here on the iPhone.

305
00:20:33,360 --> 00:20:41,440
This first example is how to access the UUID on the phone.

306
00:20:41,440 --> 00:20:47,060
This is actually something that Apple has just banned for new applications,

307
00:20:47,060 --> 00:20:52,540
but old applications that you might have running on your phone can still do this,

308
00:20:52,540 --> 00:20:56,500
and so that unique identifier can be used to track you 

309
00:20:56,500 --> 00:21:00,440
across many different applications.

310
00:21:00,440 --> 00:21:07,180
>> On the Android, I have an example here of getting the device's location.

311
00:21:07,180 --> 00:21:10,310
You can see that if that API call is there that app is tracking,

312
00:21:10,310 --> 00:21:15,000
and you can see whether it's getting fine location or coarse location.

313
00:21:15,000 --> 00:21:18,860
And then on the bottom here, I have an example of how on the BlackBerry

314
00:21:18,860 --> 00:21:25,130
an application might access the email messages in your inbox.

315
00:21:25,130 --> 00:21:27,660
These are the kind of things you can inspect to see 

316
00:21:27,660 --> 00:21:32,360
if the app is doing those things.

317
00:21:32,360 --> 00:21:38,320
The second big category of malicious behavior, and this is probably the biggest category now,

318
00:21:38,320 --> 00:21:43,950
is unauthorized dialing, unauthorized premium SMS text messages

319
00:21:43,950 --> 00:21:46,080
or unauthorized payments.

320
00:21:46,080 --> 00:21:48,930
Another thing that's unique about the phone

321
00:21:48,930 --> 00:21:52,700
is the device is hooked to a billing account,

322
00:21:52,700 --> 00:21:55,960
and when activities happen on the phone

323
00:21:55,960 --> 00:21:58,510
it can create charges.

324
00:21:58,510 --> 00:22:00,700
You can purchase things over the phone,

325
00:22:00,700 --> 00:22:04,390
and when you send a premium SMS text message you're actually giving money

326
00:22:04,390 --> 00:22:11,590
to the account holder of the phone number on the other side.

327
00:22:11,590 --> 00:22:17,420
These were set up to get stock quotes or get your daily horoscope or other things,

328
00:22:17,420 --> 00:22:21,680
but they can be set up to order a product by sending an SMS text.

329
00:22:21,680 --> 00:22:26,970
People give money to the Red Cross by sending a text message.

330
00:22:26,970 --> 00:22:30,650
You can give $10 that way.

331
00:22:30,650 --> 00:22:34,190
>> The attackers, what they've done is they set up

332
00:22:34,190 --> 00:22:38,750
accounts in foreign countries, and they embed in the malware

333
00:22:38,750 --> 00:22:42,840
that the phone will send a premium SMS text message,

334
00:22:42,840 --> 00:22:47,700
say, a few times a day, and at the end of the month you realize you've spent

335
00:22:47,700 --> 00:22:52,090
tens or maybe even hundreds of dollars, and they walk away with the money.

336
00:22:52,090 --> 00:22:57,280
This got so bad that this was the very first thing that the Android 

337
00:22:57,280 --> 00:23:00,760
Marketplace or the Google place—it was the Android Marketplace at the time,

338
00:23:00,760 --> 00:23:04,430
and it's now Google Play—the first thing that Google started checking for.

339
00:23:04,430 --> 00:23:08,700
When Google started distributing Android apps in their app store

340
00:23:08,700 --> 00:23:11,350
they said they were not going to check for anything.

341
00:23:11,350 --> 00:23:15,630
We'll pull apps once we've been notified they've broken our terms of service,

342
00:23:15,630 --> 00:23:17,520
but we're not going to check for anything.

343
00:23:17,520 --> 00:23:24,350
Well, about a year ago it got so bad with this premium SMS text message malware

344
00:23:24,350 --> 00:23:28,030
that this is the very first thing they started checking for.

345
00:23:28,030 --> 00:23:31,770
If an app can send SMS text messages

346
00:23:31,770 --> 00:23:34,750
they further manually scrutinize that application.

347
00:23:34,750 --> 00:23:38,770
They look for the APIs that call this,

348
00:23:38,770 --> 00:23:40,580
and now since then Google has expanded, 

349
00:23:40,580 --> 00:23:46,900
but this was the first thing that they started looking for.

350
00:23:46,900 --> 00:23:50,690
>> Some other apps that did some SMS text messages,

351
00:23:50,690 --> 00:23:56,980
this Android Qicsomos, I guess it is called.

352
00:23:56,980 --> 00:24:02,670
There was this current event on the mobile where this CarrierIQ came out

353
00:24:02,670 --> 00:24:07,720
as spyware put on the device by the carriers,

354
00:24:07,720 --> 00:24:10,820
so people wanted to know if their phone was vulnerable to this,

355
00:24:10,820 --> 00:24:13,890
and this was a free app that tested that.

356
00:24:13,890 --> 00:24:17,520
Well, of course, what this app did was it sent premium SMS text messages,

357
00:24:17,520 --> 00:24:20,090
so by testing to see if you're infected with spyware

358
00:24:20,090 --> 00:24:24,930
you loaded malware onto your device.

359
00:24:24,930 --> 00:24:27,310
We saw the same thing happen at the last Super Bowl. 

360
00:24:27,310 --> 00:24:33,180
There was a bogus version of the Madden football game

361
00:24:33,180 --> 00:24:38,320
that sent premium SMS text messages.

362
00:24:38,320 --> 00:24:45,750
It actually tried to create a bot network too on the device.

363
00:24:45,750 --> 00:24:48,090
Here I have some examples.

364
00:24:48,090 --> 00:24:52,640
Interestingly enough, Apple was pretty smart,

365
00:24:52,640 --> 00:24:58,470
and they don't allow applications to send SMS text messages at all.

366
00:24:58,470 --> 00:25:00,350
No app can do it. 

367
00:25:00,350 --> 00:25:03,530
That's a great way of getting rid of a whole class of vulnerability,

368
00:25:03,530 --> 00:25:09,040
but on Android you can do it, and of course, on BlackBerry you can do it too.

369
00:25:09,040 --> 00:25:13,060
It's interesting that on the BlackBerry all you need is internet permissions

370
00:25:13,060 --> 00:25:18,370
to send an SMS text message.

371
00:25:18,370 --> 00:25:21,580
>> The other thing really that we look for

372
00:25:21,580 --> 00:25:24,780
when we're looking to see if something is malicious is just any kind of 

373
00:25:24,780 --> 00:25:28,100
unauthorized network activity, like look at the network activity 

374
00:25:28,100 --> 00:25:31,570
the app is supposed to have to have its functionality,

375
00:25:31,570 --> 00:25:35,380
and look at this other network activity.

376
00:25:35,380 --> 00:25:43,380
Perhaps an app, to work, has to get data over HTTP,

377
00:25:43,380 --> 00:25:47,500
but if it's doing things over email or SMS or Bluetooth or something like that

378
00:25:47,500 --> 00:25:52,890
now that app could potentially be malicious, so this is another thing you can inspect for.

379
00:25:52,890 --> 00:26:00,430
And on this slide here I have some examples of that.

380
00:26:00,430 --> 00:26:05,950
Another interesting thing we saw with malware happened back in 2009,

381
00:26:05,950 --> 00:26:07,600
and it happened in a big way.

382
00:26:07,600 --> 00:26:11,390
I don't know if it's happened so much since then, but it was an app

383
00:26:11,390 --> 00:26:15,140
that impersonated another application.

384
00:26:15,140 --> 00:26:21,700
There was a set of apps, and it was dubbed the 09Droid attack,

385
00:26:21,700 --> 00:26:29,770
and someone decided that there were a lot of small, regional, midsize banks

386
00:26:29,770 --> 00:26:32,260
that didn't have online banking applications,

387
00:26:32,260 --> 00:26:36,870
so what they did was they built about 50 online banking applications

388
00:26:36,870 --> 00:26:39,410
that all they did was take the user name and password

389
00:26:39,410 --> 00:26:42,190
and redirect you to the website.

390
00:26:42,190 --> 00:26:47,470
And so they put these all up in the Google Marketplace,

391
00:26:47,470 --> 00:26:51,530
in the Android Marketplace, and when someone searched to see if their bank

392
00:26:51,530 --> 00:26:56,000
had an application they would find the bogus application,

393
00:26:56,000 --> 00:27:01,230
which collected their credentials and then redirected them to their website.

394
00:27:01,230 --> 00:27:06,640
The way that this actually became—the apps were up there for a few weeks,

395
00:27:06,640 --> 00:27:09,050
and there were thousands and thousands of downloads.

396
00:27:09,050 --> 00:27:12,910
>> The way this came to light was someone was having a problem 

397
00:27:12,910 --> 00:27:15,740
with one of the applications, and they called their bank,

398
00:27:15,740 --> 00:27:18,390
and they called their bank's customer support line and said,

399
00:27:18,390 --> 00:27:21,180
"I'm having a problem with your mobile banking application."

400
00:27:21,180 --> 00:27:23,460
"Can you help me out?"

401
00:27:23,460 --> 00:27:26,540
And they said, "We don't have a mobile banking application."

402
00:27:26,540 --> 00:27:28,120
That started the investigation.

403
00:27:28,120 --> 00:27:31,200
That bank called Google, and then Google looked and said,

404
00:27:31,200 --> 00:27:37,220
"Wow, the same author has written 50 bank applications," and took them all down.

405
00:27:37,220 --> 00:27:43,410
But certainly this could happen again.

406
00:27:43,410 --> 00:27:51,790
There's the list of all the different banks here

407
00:27:51,790 --> 00:27:55,870
that were part of this scam.

408
00:27:55,870 --> 00:28:02,050
The other thing an app can do is present the UI of another application.

409
00:28:02,050 --> 00:28:06,430
While it's running it could pop up the Facebook UI.

410
00:28:06,430 --> 00:28:09,540
It says you have to put in your user name and password to continue

411
00:28:09,540 --> 00:28:15,090
or put up any user name and password UI for a website

412
00:28:15,090 --> 00:28:18,420
that maybe the user uses just to try to trick the user

413
00:28:18,420 --> 00:28:21,340
into putting their credentials in.

414
00:28:21,340 --> 00:28:25,590
This is really a straight parallel of the email phishing attacks

415
00:28:25,590 --> 00:28:28,210
where someone sends you an email message

416
00:28:28,210 --> 00:28:33,050
and gives you basically a fake UI for a website

417
00:28:33,050 --> 00:28:37,320
that you have access to.

418
00:28:37,320 --> 00:28:41,590
>> The other thing we look for in malicious code is system modification.

419
00:28:41,590 --> 00:28:48,160
You can look for all the API calls that require root privilege

420
00:28:48,160 --> 00:28:50,870
to execute correctly.

421
00:28:50,870 --> 00:28:56,160
Changing the device's web proxy would be something that an application 

422
00:28:56,160 --> 00:28:59,530
shouldn't be able to do.

423
00:28:59,530 --> 00:29:03,030
But if the application has code in there to do that

424
00:29:03,030 --> 00:29:05,960
you know that it's probably a malicious application 

425
00:29:05,960 --> 00:29:09,620
or very highly likely to be a malicious application,

426
00:29:09,620 --> 00:29:13,910
and so what would happen is that app would have some way of escalating privilege.

427
00:29:13,910 --> 00:29:17,200
It would have some privilege escalation exploit

428
00:29:17,200 --> 00:29:20,730
in the application, and then once it escalated privileges

429
00:29:20,730 --> 00:29:23,800
it would do these system modifications.

430
00:29:23,800 --> 00:29:28,010
You can find malware that has privilege escalation

431
00:29:28,010 --> 00:29:32,550
in it even without knowing how the privilege escalation

432
00:29:32,550 --> 00:29:37,960
exploit is going to happen, and that's a nice, easy way

433
00:29:37,960 --> 00:29:41,220
to look for malware.

434
00:29:41,220 --> 00:29:46,030
DroidDream was probably the most famous piece of Android malware.

435
00:29:46,030 --> 00:29:50,530
I think it affected about 250,000 users over a few days

436
00:29:50,530 --> 00:29:52,810
before it was found.

437
00:29:52,810 --> 00:29:56,890
They repackaged 50 bogus applications,

438
00:29:56,890 --> 00:30:00,370
put them in the Android app store, 

439
00:30:00,370 --> 00:30:10,940
and essentially it used Android jailbreak code to escalate privileges

440
00:30:10,940 --> 00:30:16,380
and then install a command and control and turn all the victims

441
00:30:16,380 --> 00:30:20,690
into a bot net, but you could have detected this

442
00:30:20,690 --> 00:30:24,170
if you were scanning the application and just looking for

443
00:30:24,170 --> 00:30:32,230
API calls that required root permission to execute correctly.

444
00:30:32,230 --> 00:30:40,150
>> And there's an example here I have which is changing the proxy,

445
00:30:40,150 --> 00:30:46,380
and this actually is only available on the Android.

446
00:30:46,380 --> 00:30:49,070
You can see I'm giving you a lot of examples on Android 

447
00:30:49,070 --> 00:30:53,990
because this is where the most active malware ecosystem is

448
00:30:53,990 --> 00:30:58,690
because it's really easy for an attacker to get malicious code

449
00:30:58,690 --> 00:31:01,470
into the Android Marketplace.

450
00:31:01,470 --> 00:31:06,480
It's not so easy to do that in the Apple App Store

451
00:31:06,480 --> 00:31:10,250
because Apple requires developers to identify themselves

452
00:31:10,250 --> 00:31:12,790
and sign the code.

453
00:31:12,790 --> 00:31:20,340
They actually check who you are, and Apple is actually scrutinizing the applications.

454
00:31:20,340 --> 00:31:27,450
We don't see a lot of true malware where the device is getting compromised.

455
00:31:27,450 --> 00:31:32,250
I will talk about some examples where it's really privacy that's getting compromised,

456
00:31:32,250 --> 00:31:38,460
and that's what's really happening on the Apple device.

457
00:31:38,460 --> 00:31:44,090
Another thing to look for malicious code, risky code in devices

458
00:31:44,090 --> 00:31:50,300
is logic or time bombs, and time bombs are probably 

459
00:31:50,300 --> 00:31:53,370
much easier to look for than logic bombs.

460
00:31:53,370 --> 00:31:57,030
But with time bombs, what you can do is you can look for

461
00:31:57,030 --> 00:32:04,760
places in the code where the time is tested or an absolute time is looked for

462
00:32:04,760 --> 00:32:08,190
before certain functionality in the app happens.

463
00:32:08,190 --> 00:32:14,200
And this could be done to hide that activity from the user,

464
00:32:14,200 --> 00:32:17,510
so it's happening late at night.

465
00:32:17,510 --> 00:32:24,350
DroidDream did all its activity between 11 PM and 8 AM local time

466
00:32:24,350 --> 00:32:30,650
to try to do it while the user might not be using their device.

467
00:32:30,650 --> 00:32:38,680
>> Another reason to do this is if people are using behavioral analysis of an application,

468
00:32:38,680 --> 00:32:43,430
running the app in a sandbox to see what the behavior of the application is,

469
00:32:43,430 --> 00:32:51,090
they can use time-based logic to do the activity

470
00:32:51,090 --> 00:32:54,640
when the app isn't in the sandbox.

471
00:32:54,640 --> 00:33:01,520
For example, an app store like Apple

472
00:33:01,520 --> 00:33:07,940
runs the application, but they probably don't run every application for, say, 30 days

473
00:33:07,940 --> 00:33:10,550
before approving it, so you can put 

474
00:33:10,550 --> 00:33:14,120
logic in your application that said, okay, only do the bad thing

475
00:33:14,120 --> 00:33:20,490
after 30 days has gone by or after 30 days after the publish date of the application,

476
00:33:20,490 --> 00:33:27,020
and that can help the malicious code hide from people inspecting for it.

477
00:33:27,020 --> 00:33:30,050
If anti-virus companies are running things in sandboxes

478
00:33:30,050 --> 00:33:36,370
or the app stores themselves are this can help

479
00:33:36,370 --> 00:33:39,260
hide that from that inspection.

480
00:33:39,260 --> 00:33:43,020
Now, the flip side of that is it's easy to find with static analysis,

481
00:33:43,020 --> 00:33:46,170
so actually inspecting the code you can look for all the places 

482
00:33:46,170 --> 00:33:54,010
where the application tests the time and inspect that way.

483
00:33:54,010 --> 00:33:58,850
And here I have some examples on these 3 different platforms

484
00:33:58,850 --> 00:34:05,640
how time can be checked for by the app maker

485
00:34:05,640 --> 00:34:10,520
so you know what to look for if you're inspecting the app statically.

486
00:34:10,520 --> 00:34:14,570
>> I just went through a whole bunch of different malicious activities

487
00:34:14,570 --> 00:34:18,969
that we've seen in the wild, but which ones are the most prevalent?

488
00:34:18,969 --> 00:34:23,940
That same study from North Carolina State Mobile Genome Project

489
00:34:23,940 --> 00:34:28,560
published some data, and there were basically 4 areas

490
00:34:28,560 --> 00:34:32,850
that they saw where there was a lot of activity.

491
00:34:32,850 --> 00:34:35,370
37% of the apps did privilege escalation,

492
00:34:35,370 --> 00:34:38,429
so they had some type of jailbreak code in there 

493
00:34:38,429 --> 00:34:42,070
where they tried to escalate privileges so that they could 

494
00:34:42,070 --> 00:34:48,360
do API commands running as the operating system.

495
00:34:48,360 --> 00:34:52,520
45% of the apps out there did premium SMS,

496
00:34:52,520 --> 00:34:57,260
so that's a huge percentage that is trying to directly monetize.

497
00:34:57,260 --> 00:35:02,640
93% did remote control, so they tried to set up a bot net, a mobile bot net.

498
00:35:02,640 --> 00:35:08,990
And 45% harvested identifying information

499
00:35:08,990 --> 00:35:16,230
like phone numbers, UUIDs, GPS location, user accounts,

500
00:35:16,230 --> 00:35:22,870
and this adds up to more than 100 because most malware tries to do a few of these things.

501
00:35:22,870 --> 00:35:27,070
>> I'm going to switch to the second half and talk about the code vulnerabilities.

502
00:35:27,070 --> 00:35:29,480
This is the second half of the risky activity.

503
00:35:29,480 --> 00:35:33,450
This is where essentially the developer is making errors.

504
00:35:33,450 --> 00:35:37,210
A legitimate developer writing a legitimate app

505
00:35:37,210 --> 00:35:41,830
is making errors or is ignorant of the risks of the mobile platform.

506
00:35:41,830 --> 00:35:44,780
They just don't know how to make a secure mobile app,

507
00:35:44,780 --> 00:35:47,700
or sometimes the developer doesn't care about putting the user at risk.

508
00:35:47,700 --> 00:35:50,850
Sometimes part of their business model might be 

509
00:35:50,850 --> 00:35:54,610
harvesting the user's personal information.

510
00:35:54,610 --> 00:35:58,090
That's sort of the other category, and that's why some of this malicious 

511
00:35:58,090 --> 00:36:03,200
versus legitimate starts to bleed over because there's difference of opinions

512
00:36:03,200 --> 00:36:10,440
between what the user wants and what the user considers risky

513
00:36:10,440 --> 00:36:13,050
and what the application developer considers risky.

514
00:36:13,050 --> 00:36:18,380
Of course, it's not the application developer's data in most cases.

515
00:36:18,380 --> 00:36:22,030
>> And then finally, another way this happens is a developer might link in

516
00:36:22,030 --> 00:36:28,600
a shared library that has vulnerabilities or this risky behavior in it

517
00:36:28,600 --> 00:36:32,480
unbeknownst to them.

518
00:36:32,480 --> 00:36:37,060
The first category is sensitive data leakage,

519
00:36:37,060 --> 00:36:40,030
and this is when the app collects information

520
00:36:40,030 --> 00:36:44,980
like location, address book information, owner information

521
00:36:44,980 --> 00:36:48,000
and sends that off the device.

522
00:36:48,000 --> 00:36:53,050
And once it's off the device, we don't know what's happening with that information.

523
00:36:53,050 --> 00:36:57,170
It could be stored insecurely by the application developer.

524
00:36:57,170 --> 00:37:02,070
We've seen application developers get compromised,

525
00:37:02,070 --> 00:37:05,820
and the data that they're storing gets taken.

526
00:37:05,820 --> 00:37:10,970
This happened a few months ago to a developer down in Florida

527
00:37:10,970 --> 00:37:21,660
where a huge number of—it was iPad UUIDs and device names

528
00:37:21,660 --> 00:37:25,270
were leaked because someone, I think it was anonymous,

529
00:37:25,270 --> 00:37:29,460
claimed to do this, broke into this developer's servers

530
00:37:29,460 --> 00:37:34,920
and stole millions of iPad UUIDs

531
00:37:34,920 --> 00:37:37,390
and computer names.

532
00:37:37,390 --> 00:37:40,260
Not the most risky information,

533
00:37:40,260 --> 00:37:46,820
but what if that was the storage of user names and passwords

534
00:37:46,820 --> 00:37:48,170
and home addresses?

535
00:37:48,170 --> 00:37:51,100
There's lots of apps that store that kind of information.

536
00:37:51,100 --> 00:37:53,230
The risk is there.

537
00:37:53,230 --> 00:37:56,620
>> The other thing that can happen is if the developer doesn't take care

538
00:37:56,620 --> 00:38:01,370
to secure the data channel, and that's another big vulnerability I'm going to talk about,

539
00:38:01,370 --> 00:38:05,160
that data is being sent in the clear.

540
00:38:05,160 --> 00:38:09,040
If the user is on a public Wi-Fi network

541
00:38:09,040 --> 00:38:12,330
or someone is sniffing the internet somewhere

542
00:38:12,330 --> 00:38:19,260
along the path that data is being exposed.

543
00:38:19,260 --> 00:38:23,790
One very famous case of this information leakage happened with Pandora,

544
00:38:23,790 --> 00:38:27,250
and this is something we researched at Veracode.

545
00:38:27,250 --> 00:38:33,200
We heard that there was a—I think it was a Federal Trade Commission 

546
00:38:33,200 --> 00:38:35,310
investigation going on with Pandora.

547
00:38:35,310 --> 00:38:39,830
We said, "What's going on there? Let's start digging into the Pandora application." 

548
00:38:39,830 --> 00:38:46,690
And what we determined was the Pandora application collected

549
00:38:46,690 --> 00:38:51,270
your gender and your age, 

550
00:38:51,270 --> 00:38:56,660
and it also accessed your GPS location, and the Pandora application 

551
00:38:56,660 --> 00:39:00,200
did this for what they said were legitimate reasons.

552
00:39:00,200 --> 00:39:05,360
The music that they were playing—Pandora is a music streaming app—

553
00:39:05,360 --> 00:39:07,530
the music they were playing was only licensed in the United States,

554
00:39:07,530 --> 00:39:13,020
so they had to check to comply with their license agreements that they had

555
00:39:13,020 --> 00:39:17,240
for the music that the user was in the United States.

556
00:39:17,240 --> 00:39:25,070
They also wanted to comply with the parental advisory

557
00:39:25,070 --> 00:39:33,790
around adult language in music, 

558
00:39:33,790 --> 00:39:37,500
and so it's a voluntary program, but they wanted to comply with that

559
00:39:37,500 --> 00:39:43,010
and not play explicit lyrics to children 13 and under.

560
00:39:43,010 --> 00:39:46,280
>> They had legitimate reasons for collecting this data.

561
00:39:46,280 --> 00:39:49,160
Their app had the permissions to do it.

562
00:39:49,160 --> 00:39:52,000
Users thought this was legitimate. But what happened?

563
00:39:52,000 --> 00:39:55,810
They linked in 3 or 4 different ad libraries.

564
00:39:55,810 --> 00:39:59,140
Now all of a sudden all these ad libraries

565
00:39:59,140 --> 00:40:02,970
are getting access to this same information.

566
00:40:02,970 --> 00:40:05,830
The ad libraries, if you look at the code in the ad libraries

567
00:40:05,830 --> 00:40:08,430
what they do is every ad library says

568
00:40:08,430 --> 00:40:11,340
"Does my app have permission to get GPS location?"

569
00:40:11,340 --> 00:40:14,890
"Oh, it does? Okay, tell me the GPS location."

570
00:40:14,890 --> 00:40:16,620
Every single ad library does that,

571
00:40:16,620 --> 00:40:19,740
and if the app doesn't have GPS permission

572
00:40:19,740 --> 00:40:23,460
it won't be able to get it, but if it does, it will get it.

573
00:40:23,460 --> 00:40:26,240
This is where the business model of the ad libraries

574
00:40:26,240 --> 00:40:31,160
is opposed to the privacy of the user.

575
00:40:31,160 --> 00:40:34,980
And there's been studies out there that will say if you know the age

576
00:40:34,980 --> 00:40:38,430
of a person and you know their location

577
00:40:38,430 --> 00:40:42,530
where they sleep at night, because you have their GPS coordinates

578
00:40:42,530 --> 00:40:46,030
while they perhaps are sleeping, you know exactly who that person is

579
00:40:46,030 --> 00:40:50,230
because you can determine which member of that household is that person.

580
00:40:50,230 --> 00:40:54,780
Really this is identifying to advertisers

581
00:40:54,780 --> 00:40:59,530
exactly who you are, and it looks like it was legitimate.

582
00:40:59,530 --> 00:41:02,800
I just want my streaming music, and this is the only way to get it.

583
00:41:02,800 --> 00:41:05,370
>> Well, we exposed this.

584
00:41:05,370 --> 00:41:08,030
We wrote this up in several blog posts,

585
00:41:08,030 --> 00:41:13,280
and it turned out that someone from Rolling Stone magazine

586
00:41:13,280 --> 00:41:18,810
read one of our blog posts and wrote their own blog in Rolling Stone about it,

587
00:41:18,810 --> 00:41:22,120
and the very next day Pandora thought it was a good idea

588
00:41:22,120 --> 00:41:27,600
to remove the ad libraries from their application.

589
00:41:27,600 --> 00:41:31,270
As far as I know they're the only—they should be commended.

590
00:41:31,270 --> 00:41:35,770
I think they're the only freemium type of app that has done this.

591
00:41:35,770 --> 00:41:38,660
All the other freemium apps have this same behavior,

592
00:41:38,660 --> 00:41:41,780
so you've got to think about what kind of data you're giving 

593
00:41:41,780 --> 00:41:48,330
these freemium applications because it's all going to advertisers.

594
00:41:48,330 --> 00:41:53,390
Praetorian also did a study about shared libraries and said, 

595
00:41:53,390 --> 00:41:57,100
"Let's look at what shared libraries are the top shared libraries," and this was the data.

596
00:41:57,100 --> 00:41:59,420
>> They analyzed 53,000 apps,

597
00:41:59,420 --> 00:42:01,900
and the number 1 shared library was Admob.

598
00:42:01,900 --> 00:42:06,060
It was actually in 38% of the applications out there,

599
00:42:06,060 --> 00:42:08,800
so 38% of the applications you're using 

600
00:42:08,800 --> 00:42:11,250
are likely harvesting your personal information

601
00:42:11,250 --> 00:42:16,650
and sending it to the ad networks.

602
00:42:16,650 --> 00:42:19,350
Apache and Android were 8% and 6%,

603
00:42:19,350 --> 00:42:22,960
and then these other ones down at the bottom, Google Ads, Flurry,

604
00:42:22,960 --> 00:42:26,600
Mob City and Millennial Media,

605
00:42:26,600 --> 00:42:30,500
these are all ad companies, and then, interestingly enough,

606
00:42:30,500 --> 00:42:33,500
4% linked in the Facebook library

607
00:42:33,500 --> 00:42:38,870
probably to do authentication through Facebook

608
00:42:38,870 --> 00:42:40,810
so the app could authenticate the Facebook.

609
00:42:40,810 --> 00:42:44,660
But that also means the corporation Facebook controls code

610
00:42:44,660 --> 00:42:49,010
that's running in 4% of the Android mobile apps out there,

611
00:42:49,010 --> 00:42:53,490
and they have access to all the data that that app has permission to get at.

612
00:42:53,490 --> 00:42:57,170
Facebook essentially tries to sell advertising space.

613
00:42:57,170 --> 00:43:00,120
That's their business model.

614
00:43:00,120 --> 00:43:02,920
>> If you look at this whole ecosystem with these permissions

615
00:43:02,920 --> 00:43:07,740
and shared libraries you start to see that 

616
00:43:07,740 --> 00:43:13,850
you have a lot of risk in a supposedly legitimate application.

617
00:43:13,850 --> 00:43:19,360
The same similar thing that happened with Pandora

618
00:43:19,360 --> 00:43:22,340
happened with an application called Path,

619
00:43:22,340 --> 00:43:27,660
and Path thought they were being helpful, friendly developers.

620
00:43:27,660 --> 00:43:32,160
They were just trying to give you a great user experience,

621
00:43:32,160 --> 00:43:37,810
and it turned out that without prompting the user or telling the user anything—

622
00:43:37,810 --> 00:43:40,400
and this happened on the iPhone and on Android, 

623
00:43:40,400 --> 00:43:44,420
the Pandora app was on iPhone and Android—

624
00:43:44,420 --> 00:43:48,890
that the Path application was grabbing your entire address book

625
00:43:48,890 --> 00:43:52,830
and uploading it to Path just when you installed and ran the application,

626
00:43:52,830 --> 00:43:55,840
and they didn't tell you about this.

627
00:43:55,840 --> 00:43:58,750
They thought it was really helpful for you 

628
00:43:58,750 --> 00:44:04,040
to be able to share with all the people in your address book

629
00:44:04,040 --> 00:44:06,920
that you're using the Path application.

630
00:44:06,920 --> 00:44:09,490
>> Well, obviously Path thought this was great for their company.

631
00:44:09,490 --> 00:44:13,510
Not so great to the user.

632
00:44:13,510 --> 00:44:19,020
You have to think that it's one thing if maybe a teenager

633
00:44:19,020 --> 00:44:23,700
is using this application and their dozens of friends are in there,

634
00:44:23,700 --> 00:44:29,360
but what if it's the CEO of a company that installs Path

635
00:44:29,360 --> 00:44:33,170
and then all of a sudden their whole address book is up there?

636
00:44:33,170 --> 00:44:38,310
You're going to get a lot of potentially valuable contact information

637
00:44:38,310 --> 00:44:40,920
for a lot of people.

638
00:44:40,920 --> 00:44:44,500
A reporter from the New York Times, you might be able to get the phone number

639
00:44:44,500 --> 00:44:47,380
for ex presidents from their address book,

640
00:44:47,380 --> 00:44:54,780
so obviously a lot of sensitive information gets transferred with something like this.

641
00:44:54,780 --> 00:44:58,090
There was such a big flap about this that Path apologized.

642
00:44:58,090 --> 00:45:01,610
They changed their app, and it even impacted Apple.

643
00:45:01,610 --> 00:45:06,950
Apple said, "We're going to force app vendors to prompt users

644
00:45:06,950 --> 00:45:12,650
if they're going to collect their entire address book."

645
00:45:12,650 --> 00:45:15,360
>> It looks like what's happening here is 

646
00:45:15,360 --> 00:45:19,430
when there's one big privacy violation and it makes the press

647
00:45:19,430 --> 00:45:21,680
we see a change out there.

648
00:45:21,680 --> 00:45:23,230
But of course, there's other things out there.

649
00:45:23,230 --> 00:45:27,440
The LinkedIn application harvests your calendar entries,

650
00:45:27,440 --> 00:45:34,530
but Apple doesn't make the user be prompted about that.

651
00:45:34,530 --> 00:45:38,030
Calendar entries can have sensitive information in them too.

652
00:45:38,030 --> 00:45:40,000
Where are you going to draw the line?

653
00:45:40,000 --> 00:45:43,960
This is really kind of an evolving place

654
00:45:43,960 --> 00:45:47,640
where there's really no good standard out there

655
00:45:47,640 --> 00:45:51,990
for the users to understand when their information is going to be at risk

656
00:45:51,990 --> 00:45:57,820
and when they're going to know it's being taken.

657
00:45:57,820 --> 00:46:03,040
We wrote an app at Veracode called Adios,

658
00:46:03,040 --> 00:46:08,350
and essentially it allowed you to point the app at your iTunes directory

659
00:46:08,350 --> 00:46:12,550
and look at all the applications that were harvesting your full address book.

660
00:46:12,550 --> 00:46:19,760
And as you can see on this list here, Angry Birds,

661
00:46:19,760 --> 00:46:21,590
AIM, AroundMe.

662
00:46:21,590 --> 00:46:24,050
Why does Angry Birds need your address book?

663
00:46:24,050 --> 00:46:29,160
I don't know, but it does somehow.

664
00:46:29,160 --> 00:46:32,310
>> This is something that many, many applications do.

665
00:46:32,310 --> 00:46:34,780
You can inspect the code for this.

666
00:46:34,780 --> 00:46:38,660
There's well-defined APIs for iPhone, Android and BlackBerry

667
00:46:38,660 --> 00:46:42,120
to get at the address book.

668
00:46:42,120 --> 00:46:48,520
You can really easily inspect for this, and this is what we did in our Adios application.

669
00:46:48,520 --> 00:46:52,320
The next category, Unsafe Sensitive Data Storage,

670
00:46:52,320 --> 00:46:55,670
is something where developers take something like a pin or an account number

671
00:46:55,670 --> 00:46:58,530
or a password and store it in the clear on the device.

672
00:46:58,530 --> 00:47:02,310
Even worse, they might store it in an area on the phone

673
00:47:02,310 --> 00:47:06,820
which is globally accessible, like the SD card.

674
00:47:06,820 --> 00:47:11,320
You see this more often on Android because Android allows for an SD card.

675
00:47:11,320 --> 00:47:13,200
IPhone devices don't.

676
00:47:13,200 --> 00:47:17,900
But we even saw this happen in a CitiGroup application.

677
00:47:17,900 --> 00:47:25,450
Their online banking application stored the account numbers insecurely,

678
00:47:25,450 --> 00:47:28,120
just in the clear, so if you lost your device,

679
00:47:28,120 --> 00:47:30,670
essentially you lost your bank account.

680
00:47:30,670 --> 00:47:36,000
This is why I personally don't do banking on my iPhone.

681
00:47:36,000 --> 00:47:43,710
I think it's too risky right now to do these kinds of activities.

682
00:47:43,710 --> 00:47:45,950
>> Skype did the same thing.

683
00:47:45,950 --> 00:47:49,870
Skype, of course, has an account balance, a user name and password

684
00:47:49,870 --> 00:47:51,030
that access that balance.

685
00:47:51,030 --> 00:48:00,080
They were storing all that information in the clear on the mobile device.

686
00:48:00,080 --> 00:48:05,760
I have some examples here of creating files

687
00:48:05,760 --> 00:48:10,310
that don't have the right permissions or writing to disc

688
00:48:10,310 --> 00:48:17,260
and not having any encryption happen for that.

689
00:48:17,260 --> 00:48:20,190
This next area, Unsafe Sensitive Data Transmission,

690
00:48:20,190 --> 00:48:24,450
I've alluded to this a few times, and because of public Wi-Fi

691
00:48:24,450 --> 00:48:27,770
this is something that apps absolutely need to do,

692
00:48:27,770 --> 00:48:31,250
and this is probably what we see go wrong the most.

693
00:48:31,250 --> 00:48:34,920
I would say—actually, I think I have the actual data,

694
00:48:34,920 --> 00:48:38,120
but it's close to half the mobile applications

695
00:48:38,120 --> 00:48:41,780
screw up doing SSL.

696
00:48:41,780 --> 00:48:43,910
They just don't use the APIs correctly.

697
00:48:43,910 --> 00:48:47,970
I mean, all you've got to do is follow the instructions and use the APIs,

698
00:48:47,970 --> 00:48:54,720
but they do things like not check whether there is an invalid certificate at the other end,

699
00:48:54,720 --> 00:49:02,120
not check if the other end is trying to do a protocol downgrade attack.

700
00:49:02,120 --> 00:49:07,200
>> The developers, they want to get their checkbox, right?

701
00:49:07,200 --> 00:49:11,910
Their requirement is to use this to sell. They've used this to sell.

702
00:49:11,910 --> 00:49:14,800
The requirement isn't to use this to sell securely,

703
00:49:14,800 --> 00:49:19,680
and so this is why all applications that use SSL to secure data

704
00:49:19,680 --> 00:49:23,470
as it's being transmitted off the device really need to be inspected

705
00:49:23,470 --> 00:49:28,950
to make sure that was implemented correctly.

706
00:49:28,950 --> 00:49:32,850
And here I have some examples where you can see an application 

707
00:49:32,850 --> 00:49:37,400
might be using HTTP instead of HTTPS.

708
00:49:37,400 --> 00:49:40,510
In some cases apps will fall back to HTTP

709
00:49:40,510 --> 00:49:44,250
if the HTTPS isn't working.

710
00:49:44,250 --> 00:49:49,070
I have another call here on Android where they've disabled the certificate check,

711
00:49:49,070 --> 00:49:51,700
so a man-in-the-middle attack can happen.

712
00:49:51,700 --> 00:49:56,370
An invalid certificate will be accepted.

713
00:49:56,370 --> 00:50:01,920
These are all cases where attackers are going to be able to get on

714
00:50:01,920 --> 00:50:07,150
the same Wi-Fi connection as the user and access all the data

715
00:50:07,150 --> 00:50:11,650
that's being sent over the internet.

716
00:50:11,650 --> 00:50:15,970
>> And finally, the last category I have here is hardcoded password and keys.

717
00:50:15,970 --> 00:50:21,470
We actually see a lot of developers use the same coding style

718
00:50:21,470 --> 00:50:25,900
that they did when they were building web server applications,

719
00:50:25,900 --> 00:50:29,700
so they're building a Java server application, and they're hardcoding the key.

720
00:50:29,700 --> 00:50:31,940
Well, when you're building a server application, yeah,

721
00:50:31,940 --> 00:50:34,240
hardcoding the key is not a good idea.

722
00:50:34,240 --> 00:50:36,290
It makes it difficult to change.

723
00:50:36,290 --> 00:50:40,700
But it's not so bad on the server side because who has access to the server side?

724
00:50:40,700 --> 00:50:43,140
Only the administrators.

725
00:50:43,140 --> 00:50:48,100
But if you take the same code and you poured it over to a mobile application 

726
00:50:48,100 --> 00:50:52,550
now everyone who has that mobile application has access to that hardcoded key,

727
00:50:52,550 --> 00:50:56,380
and we actually see this a lot of times, and I have some statistics 

728
00:50:56,380 --> 00:51:00,920
on how often we see this happen.

729
00:51:00,920 --> 00:51:04,940
It actually was in example code that MasterCard published 

730
00:51:04,940 --> 00:51:06,850
on how to use their service.

731
00:51:06,850 --> 00:51:11,860
The example code showed how you would just take the password

732
00:51:11,860 --> 00:51:14,850
and put it in a hardcoded string right there,

733
00:51:14,850 --> 00:51:19,380
and we know how developers love to copy and paste code snippets

734
00:51:19,380 --> 00:51:22,360
when they're trying to do something, so you copy and paste the code snippet

735
00:51:22,360 --> 00:51:28,450
that they gave as example code, and you have an insecure application.

736
00:51:28,450 --> 00:51:31,490
>> And here we have some examples.

737
00:51:31,490 --> 00:51:35,840
This first one is one we see a lot where they hardcode

738
00:51:35,840 --> 00:51:40,510
the data right into a URL that gets sent.

739
00:51:40,510 --> 00:51:45,120
Sometimes we see string password = the password.

740
00:51:45,120 --> 00:51:49,060
That's pretty easy to detect, or string password on BlackBerry and Android.

741
00:51:49,060 --> 00:51:53,680
It's actually pretty easy to check for because almost always

742
00:51:53,680 --> 00:51:57,030
the developer names the variable that's holding the password

743
00:51:57,030 --> 00:52:02,290
some variation of password.

744
00:52:02,290 --> 00:52:05,200
I mentioned that we do static analysis at Veracode,

745
00:52:05,200 --> 00:52:11,790
so we've analyzed several hundred Android and iOS applications.

746
00:52:11,790 --> 00:52:15,160
We've built full models of them, and we're able to scan them

747
00:52:15,160 --> 00:52:19,280
for different vulnerabilities, especially the vulnerabilities I was talking about,

748
00:52:19,280 --> 00:52:21,050
and I have some data here.

749
00:52:21,050 --> 00:52:24,320
68.5% of the Android apps we looked at

750
00:52:24,320 --> 00:52:28,590
had broken cryptographic code,

751
00:52:28,590 --> 00:52:33,240
which for us, we can't detect if you made your own crypto routine,

752
00:52:33,240 --> 00:52:38,980
not that that's a good idea, but this is actually using the published APIs

753
00:52:38,980 --> 00:52:42,530
that are on the platform but doing them in such a way 

754
00:52:42,530 --> 00:52:46,680
that the crypto would be vulnerable, 68.5.

755
00:52:46,680 --> 00:52:49,870
And this is for people that are sending us their applications actually because 

756
00:52:49,870 --> 00:52:53,730
they think it's a good idea to do security testing.

757
00:52:53,730 --> 00:52:56,960
These are already people that are probably thinking securely,

758
00:52:56,960 --> 00:52:59,540
so it's probably even worse.

759
00:52:59,540 --> 00:53:02,690
>> I didn't talk about control line feed injection.

760
00:53:02,690 --> 00:53:07,640
It's something we check for, but it's not that risky an issue.

761
00:53:07,640 --> 00:53:15,390
Information leakage, this is where sensitive data is being sent off the device.

762
00:53:15,390 --> 00:53:19,270
We found that in 40% of the applications.

763
00:53:19,270 --> 00:53:23,540
Time and state, those are race condition type issues, typically pretty hard to exploit,

764
00:53:23,540 --> 00:53:26,170
so I didn't talk about that, but we looked at it.

765
00:53:26,170 --> 00:53:28,750
23% had SQL injection issues.

766
00:53:28,750 --> 00:53:32,020
A lot of people don't know that a lot of applications

767
00:53:32,020 --> 00:53:35,880
use a small little SQL database on their back end to store data.

768
00:53:35,880 --> 00:53:40,430
Well, if the data that you're grabbing over the network

769
00:53:40,430 --> 00:53:43,800
has SQL injection attack strings in it

770
00:53:43,800 --> 00:53:45,970
someone can compromise the device through that,

771
00:53:45,970 --> 00:53:49,800
and so I think we find about 40% of web applications have this problem,

772
00:53:49,800 --> 00:53:52,840
which is a huge epidemic problem.

773
00:53:52,840 --> 00:53:55,740
We find it 23% of the time in mobile apps

774
00:53:55,740 --> 00:54:02,030
and that's probably because many more web applications use SQL than mobile.

775
00:54:02,030 --> 00:54:05,580
>> And then we still see some cross-site scripting, authorization issues, 

776
00:54:05,580 --> 00:54:09,400
and then credential management, that's where you have your hardcoded password.

777
00:54:09,400 --> 00:54:14,540
In 5% of the applications we see that.

778
00:54:14,540 --> 00:54:17,970
And then we have some data on iOS.

779
00:54:17,970 --> 00:54:20,180
81% had error handling issues.

780
00:54:20,180 --> 00:54:23,130
This is more of a code quality problem,

781
00:54:23,130 --> 00:54:28,010
but 67% had cryptographic issues, so not quite as bad as Android.

782
00:54:28,010 --> 00:54:32,440
Maybe the APIs are a little bit easier, the example codes a little better on iOS.

783
00:54:32,440 --> 00:54:35,420
But still a very high percentage.

784
00:54:35,420 --> 00:54:39,040
We had 54% with information leakage,

785
00:54:39,040 --> 00:54:42,080
about 30% with buffer management errors.

786
00:54:42,080 --> 00:54:45,930
That's places where there could potentially be a memory corruption issue.

787
00:54:45,930 --> 00:54:50,350
It turns out that that's not as much of a problem for exploitation

788
00:54:50,350 --> 00:54:56,450
on iOS because all the code has to be signed,

789
00:54:56,450 --> 00:55:02,210
so it's hard for an attacker to execute arbitrary code on iOS.

790
00:55:02,210 --> 00:55:07,880
Code quality, directory traversal, but then credentials management here at 14.6%,

791
00:55:07,880 --> 00:55:09,250
so worse than on the Android.

792
00:55:09,250 --> 00:55:13,240
We have people not handling passwords correctly.

793
00:55:13,240 --> 00:55:15,790
And then the numeric errors and buffer overflow,

794
00:55:15,790 --> 00:55:22,680
those are more going to be code quality issues on iOS.

795
00:55:22,680 --> 00:55:26,110
>> That was it for my presentation. I don't know if we're out of time or not.

796
00:55:26,110 --> 00:55:29,540
I don't know if there's any questions.

797
00:55:29,540 --> 00:55:33,220
[Male] A quick question around fragmentation and the Android market.

798
00:55:33,220 --> 00:55:36,240
Apple at least owns patching.

799
00:55:36,240 --> 00:55:40,780
They do a good job of getting it out there whereas less so in the Android space.

800
00:55:40,780 --> 00:55:44,280
You almost need to jailbreak your phone to stay current

801
00:55:44,280 --> 00:55:46,660
with the current release of Android.

802
00:55:46,660 --> 00:55:50,960
Yeah, that's a huge problem and so if you think about—

803
00:55:50,960 --> 00:55:52,280
[Male] Why can't you repeat it?

804
00:55:52,280 --> 00:55:55,610
>> Oh, right, so the question was what about fragmentation

805
00:55:55,610 --> 00:56:00,410
of the operating system on the Android platform?

806
00:56:00,410 --> 00:56:05,890
How does that affect the riskiness of those devices?

807
00:56:05,890 --> 00:56:09,700
And it actually is a huge problem because what happens is

808
00:56:09,700 --> 00:56:15,110
the older devices, when someone comes up with a jailbreak for that device,

809
00:56:15,110 --> 00:56:19,960
essentially that's privilege escalation, and until that operating system is updated

810
00:56:19,960 --> 00:56:25,350
any malware can then use that vulnerability to totally compromise the device,

811
00:56:25,350 --> 00:56:30,200
and what we're seeing on the Android is in order to get a new operating system

812
00:56:30,200 --> 00:56:34,690
Google has to put out the operating system, and then the hardware manufacturer

813
00:56:34,690 --> 00:56:39,390
has to customize it, and then the carrier has to customize it and deliver it.

814
00:56:39,390 --> 00:56:43,070
You have basically 3 moving parts here, 

815
00:56:43,070 --> 00:56:47,210
and it's turning out that the carriers don't care, 

816
00:56:47,210 --> 00:56:50,400
and the hardware manufacturers don't care, and Google is not prodding them enough

817
00:56:50,400 --> 00:56:54,430
to do anything, so essentially over half of the devices out there

818
00:56:54,430 --> 00:57:00,590
have operating systems that have these privilege escalation vulnerabilities in them,

819
00:57:00,590 --> 00:57:08,440
and so if you get malware on your Android device it's much more of a problem.

820
00:57:08,440 --> 00:57:10,350
>> Okay, thank you very much.

821
00:57:10,350 --> 00:57:12,310
[Applause]

822
00:57:12,310 --> 00:57:14,310
[CS50.TV]