1. Dude,
where’s
my
droid?!

2. About
Sebas6án
Guerrero
/
Mobile
Security
Analyst
at
viaForensics
• h6ps://blog.seguesec.com
• s.guerrero0@gmail.com
/
@0xroot
• I’m
sexy
and
I
know
it
• No
devices
were
harmed
or
infected
for
this
talk.
2/41

3. Agenda
• Introduc6on
–
Android
smartphone
sandbox
• Mo6va6on
behind
this
work
• Android
rootkits
I
• Demo
I
&
Demo
II
&
Demo
III
• Android
rootkits
II
• Demo
IV
• What
did
we
test?
• Conclusions
3/41

4. Introduc6on
–
Android
plaJorm
sandbox
4/41

5. Android
Sandbox
and
other
security
protecJons
• Isolates
your
app
data
and
code
execu6on
from
other
apps
• Robust
implementa6ons
of
common
security
func6onality
• Cryptography,
permissions,
IPC
• Other
security
technologies
to
mi6gate
risks
associated
with
memory
management
errors
• ASLR,
NX,
ProPolice,
safe_iop,
OpenBSD
dlmalloc,
calloc…
• Encrypted
filesystem
that
can
be
enabled
to
protect
data
on
lost
devices
• Fine
grained
permissions
to
restrict
access
to
system
and
user
data
• Applica6on-­‐defined
permissions
to
control
applica6on
data
on
a
per-­‐app
basis.
5/41

6. The
purpose
of
Sandbox
Security?
6/41

7. Android
‘smart’
sandbox
7/41

8. Reality
of
sandbox
security
• Security
threat
caused
by
malware
inside
of
Sandbox
• MulJple
malware
apps,
backdoor,
trojans,
etc
• Overcharged
fee,
personal
informaJon
leak,
eavesdropping
• Spam
SMS,
DDoS
botnet
a6acks
• Code
injecJon
into
legiJmate
apps
• TapJacking
Vulnerability
• Security
threat
caused
by
vulnerabili6es
out
side
of
Sandbox
• Android
3rd
party
applicaJons
and
webkit
remote
a6ack
• Local
rooJng
exploit
code,
using
kernel
vulnerabiliJes
• LKM
kernel
rootkit
a6acks
• Hard
to
apply
a
security
update
on
a
smart
pla]orm
8/41

9. MoJvaJons
behind
this
work
• 80%
of
all
users
carry
their
devices
with
them
at
all
6mes
• As
of
Q4
2012,
500
million
devices
ac6vated
globally
• Over
1.3
million
added
every
single
day
• A
smartphone
today,
has
the
same
processing
power
as
a
PC
from
some
years
ago,
furthermore:
• 3G
/
GPS
connecJvity
• Users
have
highly
sensi6ve
informa6on
in
their
smartphones
• Personal
/
Business
email
• Account
credenJals
(Social
networks,
Bank,
other
stuff…)
• Contacts,
pictures,
etc
• WiFi?
FREE?
There
we
go
• Users
never
quesJon
their
smartphone
integrity
9/41

10. Android
rootkits
–
Part
I
10/41

11. Developing
an
Android
Kernel
Rootkit
• Loadable
Kernel
Modules
(LKMs)
allow
to
extend
dynamically
the
kernel
func6onality
• LKMs
are
executed
in
Kernel
space
•
Add
or
remove
new
pieces
of
code
without
a
recompilaJon
or
reboot
• System
Calls
are
used
for
system
opera6ons
• Files,
process,
network
• Array
of
pointers
listed
in
sys_call_table
indexed
by
their
syscall
number
• With
a
LKM
/
Rootkit
we
can
modify
a
bunch
of
func6onali6es
• Hide
files,
processes,
connecJons
• Leak
user’s
informaJon
• Install
backdoors
through
which
the
device
can
be
accessed
• Hide
those
logs
lef
behind
as
a
record
of
system
intrusion
11/41

12. Developing
an
Android
Kernel
Rootkit
• Live
free
or
die
‘hooking’
• The
need
to
redirect
the
flow
execuJon
of
a
system
call
• Is
necessary
to
create
our
own
system
call
modified
• Registering
the
address
of
our
hook
as
the
locaJon
for
a
specific
funcJon
• When
the
original
is
called
our
hook
is
executed
in
place
12/41

13. IniJal
difficulJes
• There
are
few
constraints
to
beat
• Find
the
sys_call_table
address
• Compile
against
the
right
device
kernel
version
• Debug
system
calls
to
retrieve
useful
informaJon
• Deploying
the
vector
a6ack
13/41

14. Searching
sys_call_table
1/6
• The
sys_call_table
structure
is
no
longer
export
since
Linux
Kernel
2.5
or
greater
• extern
void
*system_call_table[];
-­‐
No
longer
supported
• Solu6on
#1:
• Can
be
found
in
the
System.map
• Problem
#1:
• This
address
is
STATIC
for
all
devices
using
the
same
Kernel
version
•
Is
necessary
the
Kernel
source
code
14/41

15. Searching
sys_call_table
2/6
• Solu6on
#2:
• Retrieve
the
informaJon
from
/proc/kallsyms
• Problem:
• A
patch
has
been
submi6ed,
introducing
a
new
sysctl
to
control
the
enablement
of
this
security
countermeasure
• InformaJon
disclosure
–
CVE-­‐2012-­‐0957
15/41

16. Searching
sys_call_table
3/6
Solu6on
#3
Gevng
sys_call_table
address
from
vector_swi
handler
16/41

17. Searching
sys_call_table
4/6
Content
declared
by
entry-­‐armv.S
Filled
at
boot
6me
by
early_trap_init()
(traps.c)
Sohware
Interrupt,
then
go
to
vector_swi
handler
Content
defined
by
entry-­‐common.S
An
excep6on/interrupt
occurs
Calling
the
hooking
func6on
Calling
the
real
func6on
17/41

18. Searching
sys_call_table
5/6
• At
this
point:
• We
have
detected
the
starJng
address
for
the
vector_swi
handler,
but
don’t
know
where
it
ends
• In
ARM
architecture,
there
is
not
a
RET
instrucJon,
so
it's
impossible
to
reference
directly,
the
content
returned
by
the
subrouJne
• So,
there’s
no
an
efficient
way
to
get
the
sys_call_table
address,
apparently.
POO’
QE??
18/41

19. Searching
sys_call_table
6/6
• Aher
an
ENDPROC
instruc6on
there
is
always
hope
• __sys_trace
declaraJve
–
0xc0026y4
t
(Kernel
based)
• Now
we
are
able
to
delimit
the
EVT
• We’re
looking
for
an
‘adr’
instrucJon,
which
is
really:
‘add’
and
‘ldr’
• *ptr
&
(unsigned
long)0xFFFFF000
==
0xe28f8000
• Keep
calm
and
use
R2
from
git
• opcode
e28f8080
–
add
r8,
pc,
0x80
• opcode
e599c000
ldr
ip,
[r9]
19/41

20. Keep
calm
and
use
r2
from
git
20/41

21. There
we
go
8============D
22/41

22. Compile
against
the
device
Kernel
version
1/3
• The
module
has
been
compiled
for
a
specific
kernel
version
• 2.6.29-­‐gf1ef1c8
/
3.0.31-­‐g3b9c5d2
• The
kernel
refuses
to
accept
our
LKM
because
version
magics
are
not
the
same
• Solu6on
#1:
• Modify
UTS_RELEASE
constant
defined
in
/include/linux/utsrelease.h
• Problem
#1:
• Great
if
you’re
chinese
and
have
enough
Jme
to
recompile
every
Kernel
version
for
your
module
23/41

23. Compile
against
the
device
Kernel
version
2/3
• Solu6on
#2
• Modify
of
_module_depends
constant
in
the
kernel
module
• Problem
#2:
• Same
as
previous
one,
you
need
to
modify
your
module
for
every
kernel
version
24/41

24. Compile
against
the
device
Kernel
version
3/3
• Solu6on
#3:
• Use
a
script
to
overwrite
directly
the
vermagic
value
in
execuJon
Jme
• Available
on
my
GitHub
(0xroot)
• Problem
#3:
• Only
works
in
some
cases,
someJmes
is
necessary
to
modify
other
values
• ARMv5
is
not
the
same
as
ARMv7
(We
need
to
have
a
precompiled
version
for
both
architectures)
Old
New
25/41

25. System
call
debugging
• What
else
can
we
do?
• We
can
discover
phone
rouJnes
by
parsing
dmesg
for
specific
data,
input
or
commands
• Prompt
a
reverse
TCP
shell
when
the
phone
receives
a
specific
SMS
from
a
known
number
• Captures
all
applicaJons
acJvity
being
conducted
on
the
phone
as
well
• Is
necessary
to
map
out
the
syscalls
we
were
interested
in
• sys_write
• sys_read
• sys_open
• sys_close
• sys_getuid
• …
26/41

26. Penetraitor
v.0.1
• What
am
I
going
to
show?
• DEMO
I
–
A
rootkit
that
sends
a
reverse
TCP
shell
over
3G/WiFi
triggered
by
a
SMS
from
a
predefined
phone
number
• View
SMS
messages
• View
contacts
•
Make
a
phone
call
to
a
premium
number
• Send
a
SMS
to
a
premium
number
• Shutdown
the
phone
• DEMO
II
–
Another
and
simple
LKM
to
debug
applicaJons
from
a
device
• Browser,
Tweetdeck,
Instagram,
Malware…
• DEMO
III
–
Debugging
a
malware
with
root
exploit
capabiliJes
27/41

27. DEMO
I
–
A
reverse
TCP
shell
over
3G/WiFi
28/41

28. DEMO
II
–
Debugging
an
user-­‐land
applica6on
29/41

29. DEMO
III–
Debugging
a
piece
of
malware
30/41

30. Android
rootkits
-­‐
Part
II
31/41

31. A
possible
a6ack
scenario
• Future
threats
for
Android
devices
• Kernel
based
botnet
(C&C
and
covert
channels)
• Touchpad
Keyloggers
• Kernel
rootkit
that
hides
the
malware
• We
can
get
the
PID
of
the
AV
app,
and
hide
files
(*.odex
/
*.dex
/
*.apk)
for
certain
PIDS
32/41

32. How
can
we
deploy
this
a6ack
1/4
• Structure
of
a
DEX
• A
header
with
several
arrays
(strings,
types,
…)
• The
header
contains
offsets/sizes
to
all
secJons
• Tables
contain
references
to
each
other,
and
offsets
to
the
data
secJon
• Data
is
located
in
the
data
secJon
33/41

33. How
can
we
deploy
this
a6ack
2/4
• Structure
of
DEX
header
• DEXparser
–
Get
source
from
my
Github
(0xroot)
• Takes
the
DEX
file
as
argument
and
debugging
flags
34/41

34. How
can
we
deploy
this
a6ack
3/4
• How
can
we
hide
a
method?
We
got
access
to
the
vector
class_data_item
where:
-­‐
direct_methods
:
The
defined
direct
method
-­‐
virtual_methods:
The
defined
virtual
method
We
need
to
obtain
access
to
the
class_defs
secJon
for
every
class
on
a
DEX
file
*header.class_def_off
+
(class_num
-­‐1)
*
sizeof(class_def_item)
Class_data_off
has
the
offset
from
the
start
of
the
file
to
the
class
data
for
this
item
*header.map_off
-­‐
*class_def_item.class_data_off
35/41

35. How
can
we
deploy
this
a6ack
4/4
• Modify
a
DEX
and
re-­‐package
• Re-­‐compute
the
modified
DEX
SHA1
disreguarding
the
first
32
bytes
• Re-­‐compute
checkshum
disreguarding
the
first
12
bytes
• DEXreHash
–
Link
on
my
GitHub
• Re-­‐package
APK
• Replace
the
current
DEX
by
the
new
one.
• Zip
all
and
sign
it
using
jarsigner
36/41

36. DEMO
IV–
Hiding
last
method
of
last
class
37/41

37. But…
We
have
an6virus
and
we’re
protected,
isn’t
it?
38/41

38. What
did
we
test?
• AV
solu6ons
are
implemented
to
work
only
on
user-­‐space
• They
don’t
care
of
kernel-­‐space
• Even
more,
you
can
hide
files
in
system
data
app,
the
AV
doesn’t
care
about
that
directories
• Actually,
there
is
no
an
AV
product
that
offers
protecJon
against
this
kind
of
a6ack
• Their
only
swiss
army
knife
is
to
detect
the
LKM
at
deployment
stage
39/41

39. Conclusions
hone?!
ving
a
p
S6 ll
ha
40/41

40. QUESTIONS?
Thanks!!
blog.seguesec.com
github.com/0xroot
@0xroot
Greets:
@pof,
@trufae,
@fsero,
L,
@DS,
@Jmstrazz,
@thomas_cannon,
iSexAud,
@marcograss,
@insitusec,
Rootedcon,
n
and
many
others!
:D
41/41