This presentation contains multiple pointers to academic research pertaining to Android and its security model. I presented these works to a weekly Security and Privacy reading group. The academic proceeding can be found here: www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf

1. Why
Eve
and
Mallory
Love
Android
An
Analysis
of
Android
SSL
(In)Security

2. WARNING
• The
views
presented
in
this
presentaAon
are
my
own
and
do
not
express
the
views
of
the
Johns
Hopkins
University.
• The
content
presented
in
this
presentaAon
was
extracted
from
mulAple
academic
conference
proceedings.
• Most
pictorial
references
were
shamelessly
collected
from
the
internet
and
presented
without
reference.
If
you
find
your
image
and
wish
to
request
that
I
provide
a
reference,
please
email
me
at
the
address
provided
on
my
website:
michaelrushanan.org.

3. Building
Our
Story
• There
once
was
a
mobile
device
called
Android…
• 2012
market
share
forecasts
of
48%
and
400,000+
apps
(or
so
says
our
authors)…
• Everyone
believed
Android
to
be
safe
because
it
uAlized
Java
for
its
applicaAon
development
language,
runs
inside
an
isolated
(sandboxed)
virtual
machine,
follows
a
unix-­‐based
permissions
model,
exposes
a
wonderful
API
for
secure
methods
and
cryptography.

4. Developers
Are
Idiots
• Or
completely
malicious
geniuses!
• Case
in
point:
– ApplicaAon
Developers
seemingly
don’t
understand
the
less-­‐is-­‐
more
paradox
for
se`ng
permissions.
– Manufacturers
allow
devices
to
stagnate
by
not
supporAng
latest
OS
releases.
– The
android
runAme
supports
a
range
of
APIs
by
exposing
runAme
arguments
for
validaAng
the
current
API.
– *SIGH*
People
sAll
implement
their
own,
already
provided,
methods.
For
example,
extending
the
SSLSocketFactory
class.

5. My
Advice
to
the
UI
Class
String
BRICK
Required
to
be
able
to
disable
the
device
(very
dangerous!).
String
CAMERA
Required
to
be
able
to
access
the
camera
device.
String
READ_SMS
Allows
an
applicaAon
to
read
SMS
messages.

6. Why
Should
Fruit
Ninja…
• Have
access
to
your
phone
state?
• Be
able
to
read
SMS?
• Access
your
camera?

7. Android
Security
• Trend
Micro
reported
17
malicious
apps
discovered
in
the
Google
Play
Store.
• Six
of
these
apps
contained
a
reused
snippet
of
code
–
Plankton.
Ten
the
year
prior.
• Plankton…
– Enables
the
app
to
connect
to
a
set
of
command
and
control
servers.
– Collects
user’s
browsing
history,
bookmarks,
and
device
informaAon
(that
really
doesn’t
sound
that
bad).

8. Malicious
App
Stats

9. WARNING:
It’s
About
to
Get
Real
• Prior
to
jumping
straight
into
current
Android
research,
I’d
like
to
point
out
something.

10. ExtrapolaAng
the
Experimental
Method
for
evaluaAng
Android
Apps
• You
take
a
handful
of
apps,
usually
the
free
ones.
• Introduce
some
new
component.
• Perform
some
analysis.
• Uncover
some
horrible
truth.
• Consider
implicaAons
and
make
suggesAons.

11. A
Study
of
Android
ApplicaAon
Security
• William
Enck
et
al.

12. Android
App
Security
• “1,100
Popular
Free
Apps
examined.”
• “ded
decompiler
used
to
recover
Android
applicaAon
source
code
directly
from
installaAon
image.”
• “Horizontal
study
of
smartphone
applicaAons
based
on
staAc
analysis
of
21
million
lines
of
recovered
code.”
• “Uncovered
pervasive
use/misuses
of
personal/phone
idenAfiers,
and
deep
penetraAon
of
adverAsing
and
analyAcs.”
• “Conclude
by
considering
the
implicaAons
of
these
preliminary
findings
and
offer
direcAons
for
future
analysis.”

13. Android
App
Security
• ded
is
a
Dalvik
decompiler
that
is
used
to
recover
an
applicaAons
Java
source
from
the
installed
image.
– Madness:
DVM-­‐to-­‐JVM
bytecode
retargeAng.
– TranslaAng
class
and
method
structures.
Inferring
types.
• DVM:
– .class
files
converted
to
.dex.
– MulAple
classes
are
included
into
a
single
.dex
file.
– Dupilcate
objects
and
constants
used
in
mulAple
class
fields
are
included
ONCE
in
the
.dex.
– Java
bytecode
is
converted
into
an
alternaAve
instrucAon
set
used
by
DVM.
– DVM
executables
installed
onto
a
mobile
device
are
subject
to
further
opAmizaAons
(reording
byte
order,
inline
linking
of
simple
data
structures
and
funcAon
libraries).

14. Trivia
• What
is
IMEI?
• IMSI?
• ICC-­‐ID

15. This
is
a
really
big
paper…
• So
we’ll
menAon
the
stuff
that
is
interesAng:
– Authors
purport
a
wide
misuse
of
privacy
sensiAve
informaAon:
• IMEI
• IMSI
• ICC-­‐ID
– Usage
of
ad
and
analyAc
network
libraries
were
integrated
with
51%
of
applicaAons
studied
(eh,
they
were
free
apps).
– Many
developers
fail
to
securely
use
Android
APIs.
They’re
idiots,
remember?

16. Points
that
Repeat
• Leaking
informaAon
to
logs:
Log
API
(logcat).
• Unprotected
Broadcast
Receivers
–
we’ll
talk
more
about
this
later.
IPC
mishaps
101.
• Intent
InjecAon
Apacks.
• Denial
of
Service
with
Null
Checks
on
IPC
input
(applicaAon
crashes).
• DelegaAng
control
(we’ll
talk
about
this
in
a
second).
• Tapjoy…
• SDCard
usage
(external
vs
internal
storage).
• NaAve
code
usage
(JNI…
NDK).

17. SCanDroid:
Automated
Security
CerAficaAon
of
Android
ApplicaAons
• Adam
Fuchs
et
al.
*This
applica8on
to
prove
a
research
goal
name
usage
deal
is
also
repeated.

18. Android
App
Security
• Unless
I
missed
it,
no
collecAon
of
apps
were
pulled
from
the
Market.
• “Enforcing
permissions
is
not
sufficient
to
prevent
security
violaAons,
since
permissions
may
be
misused,
intenAonally
or
unintenAonally,
to
introduce
insecure
data
flows.
SCanDroid,
a
tool
for
reasoning
automaAcally
about
the
security
of
Android
ApplicaAons.”
• ScanDroid
staAcally
analyzes
data
flows
through
Android
applicaAons…
it
can
decide
whether
it
is
safe
for
an
applicaAon
to
run
with
certain
permissions,
based
on
the
permissions
enforced
by
other
applicaAons.
• A
soluAon
to
the
failing
permissions
model.
• With
data
flow
analysis,
the
precision
of
reasoning
by
the
user
is
no
longer
limited.

19. SCanDroid
• ScanDroid
(Program
Analysis):
– Parses
manifest
file,
and
– Analyzes
data
flow.
– Uri
and
Intent-­‐based
addr.

20. Android
Basics
λ Intents
are
the
preferred
mechanisms
for
asynchronous
IPC
in
Android.
- sendBroadcast()
- sendOrderedBroadcast()
λ You
can
apply
access
permissions
to
broadcasted
intents
so
only
certain
applicaAons
can
register
to
see
the
intents.
If
you're
doing
this,
you
might
just
consider
invoking
the
receiver
directly.
- android:exported
λ Allow
use
of
IPC
by
other
apps.
- android:protecAonLevel
λ Characterizes
the
potenAal
risk
implied
in
the
permission
and
indicates
the
procedure
the
system
should
follow
when
determining
whether
or
not
to
grant
permission
to
requester.
- “normal”
=
default
low
risk,
requests
isolated
applicaAon
features.
- “dangerous”
=
high-­‐risk,
requests
private
user
data
or
control.
- “signature”
=
granted
only
if
the
requesAng
applicaAon
is
signed
with
the
same
cerAficate
as
the
applicaAon
that
declared
the
permission.
- “signatureOrSystem”
=
system
grants
only
to
applicaAons
that
are
in
the
Android
system
image
or
as
above.
- android:permission
λ ApplicaAons
will
need
to
declare
a
corresponding
<uses-­‐permission>
element
in
their
manifest
to
start,
stop,
or
bind
service.

21. TaintDroid:
An
InformaAon-­‐Flow
Tracking
System
for
RealAme
Privacy
Monitoring
on
Smartphones
• William
Enck
et
al.

22. Trivia
• Where
else
have
we
seen
tainAng
used?

23. TaintDroid
• “30
popular
third-­‐party
Android
ApplicaAons.
• “TaintDroid,
an
efficient,
system-­‐wide
dynamic
taint
tracking
and
analysis
system
capable
of
simultaneously
tracking
mulAple
sources
of
sensiAve
data.”
• Monitor
behavior
with
TaintDroid.
• “68
instances
of
potenAal
misuse
of
users’
private
informaAon
across
20
applicaAons.”
• “Monitoring
sensiAve
data
with
TaintDroid
provides
informed
use
of
third-­‐party
applicaAons
for
phone
users
and
valuable
input
for
smartphone
security
service
firms
seek
to
idenAfy
misbehavior.”

24. TaintDroid
• An
extension
to
the
mobile
playorm,
not
an
applicaAon
itself.
• Taints
data
sources
with
a
label,
and
as
the
data
propagates
through
program
variables,
files,
and
interprocess
messages
this
allows
TaintDroid
to
monitor
(variable,
message,
method,
and
file
level).

25. TaintDroid

26. Permission
Re-­‐DelegaAon
Apacks
&
Defenses
• Adrienne
Porter
Felt
et
al.

27. ExtrapolaAng
the
Experimental
Method
for
evaluaAng
Android
Apps
• 872
survey
applicaAons.
• Demonstrate
Permission
re-­‐delegaAon.
• Perform
some
analysis.
• “More
than
a
third
request
permissions
for
sensiAve
resources
and
also
exposes
public
interfaces
–
at
risk
for
exposing
permission
re-­‐
delegaAon.”
• “IPC
InspecAon,
a
new
OS
mechanism
for
defending
against
permission
re-­‐delegaAon.
Reduces
an
applicaAon’s
permissions
a{er
receiving
communicaAon
from
a
less
privileged
applicaAon.”

28. Permission
Re-­‐DelegaAon
• Permission
re-­‐delegaAon
is
an
apack
when
lower
priv.
app
can
gain
advanced
priv.
by
communicaAng
with
more
trusted
app

29. Permission
Bloat

30. Eve
and
Mallory
<3
Android
• Finally,
we’ll
move
on
to
discussing
the
paper
at
hand.
• Sascha
et
al.
• Many
Android
apps
have
a
legiAmate
need
to
communicate
over
the
Internet.

31. Eve
and
Mallory
<3
Android
• Paper
wants
to:
– Discover
potenAal
security
threats
posed
by
benign
Android
apps
that
use
SSL/TLS
protocols
to
protect
data.
– Query
users
if
they
really
understand
those
pop
up
messages
concerning
SSL/TLS
warnings
(caveat:
when
they
actually
happen).

32. Trivia
• Whats
the
*Droid
name
used
in
this
paper?

33. MalloDroid
• Analyzed
13,500
popular
free
apps.
• Revealed
1,074
(8%)
of
apps
potenAally
vulnerable
to
MITM.
• Selected
100
apps
of
interest
(no
rhyme
nor
reason).
• 41
of
these
apps
gather
sensiAve
data
(e.g.,
banking
credenAals).
• Many
of
these
apps
communicate
over
the
internet
for
legiAmate
reasons
–
thus
requiring
the
INTERNET
permission.

34. MalloDroid
• These
INTERNET
capable
apps
uAlize
the
SSL/TLS
for
secure
communicaAon.
• MalloDroid
is
an
extension
to
AndroGuard
– Reverse
Engineering,
Malware
and
goodware
analysis
of
Android
apps.
– Wripen
in
python
to
play
with
DEX
(disassemble,
decompilaAon),
APK,
Binary
xml,
Resources.
• Performs
staAc
code
analysis:
– Analyze
the
networking
API
calls
and
extract
valid
HTTP(S)
URLS
from
the
decompiled
apps;
– Check
the
validity
of
the
SSL
cerAficates
of
all
extracted
HTTPS
hosts;
– IdenAfy
apps
that
contain
API
calls
that
differ
from
Android’s
default
SSL
usage:
• Non-­‐default
trust
managers;
• SSL
socket
factories
or
hostname
verifiers
with
permissive
verificaAon
strategies.

35. MalloDroid
• Out
of
the
100
selected
apps,
the
following
idenAfiers
were
scanned
for:
– AccepAng
all
SSL
cerAficates.
– Allowing
all
hostnames
regardless
of
the
cerAficates
Common
Name.
– NeglecAng
precauAons
against
SSL
stripping.
– TrusAng
all
available
CerAficate
AuthoriAes.
– Not
using
SSL
pinning
(eh,
don’t
really
have
to
do
this).
– Misinforming
users
about
SSL
usage.

36. Android
&
SSL
• Several
packages
for
accessing
the
network:
java.net,
javax,net,
android.net
and
org.apache.hpp.
• Developers
must
ensure
that
they
use
SSL
correctly:
– TrusAng
All
CerAficates.
TrustManager
interface
can
allow
trust
of
all
cerAficates
regardless
of
who
signed
them.
– Allowing
all
Hostnames.
Forgo
checks
of
whether
the
cert
was
issued
for
this
address
or
not.
– TrusAng
Many
CAs.
134
Root
CAs
by
default.
– Mixed-­‐Mode/NO
SSL.
SSLStripping…
mostly
a
webview
problem.

37. Android
&
SSL
Byproduct

38. MITM
• Argument
here
is
that
mobile
has
an
increased
chance
of
vulnerability
when
considering
a
malicious
MITM
(proxy
SSL).
• Authors
make
the
argument
that
just
because
an
app
doesn’t
use
SSL
appropriately,
doesn’t
mean
that
there
is
sensiAve
informaAon
there.
• ExperimentaAon:
– Targeted
Finance,
Business,
CommunicaAon,
Social
Tools.
– 266
apps
in
quesAon,
cherry
picked
100
again.
– Used
Samsung
Galaxy
Nexus,
Android
4.0
– Network
Access
via
MITM
SSL
Proxy
w/
self-­‐signed
cerAficate
or
one
that
was
signed
by
a
trusted
CA.

39. What
Happened
• Banking/Paypal
credenAals
were
leaked.
• Bitcoin-­‐miner
API
keys
were
leaked.
• Email/Contact
data…
• Why?
– Allowing
all
Hostnames.
– Allowing
any
CA-­‐signed
cerAficate

40. Case
of
SSLPinning

41. Case
for
Appropriate
Feedback

42. Survey
• The
end
result
was
approximately
half
of
the
surveyed
populaAon
didn’t
really
understand
what
a
secure
connecAon
(via
SSL/TLS)
was,
and
what
a
feedback
message
about
SSL/TLS
meant.

43. Nailed
It
• 13,500
popular
free
apps
examined.
• Introduce
some
new
component.
• 1,074
of
the
apps
contained
SSL/TLS
code.
100
cherry
picked
apps
resulted
in
41
vulnerable
apps
gathering
a
large
variety
of
sensiAve
data.
• Banking
and
personal
data
is
sensiAve,
and
suscepAble
to
the
apacks.
• Using
MalloDroid
with
Androguard.