El objetivo de la charla es la de acercar al usuario al desarrollo de LKM's que amplien la funcionalidad del Kernel, abriendo la posibilidad de tomar el control del dispositivo. La presentación, se dividirá en dos ramas, por un lado, se mostrará como troyanizar y explotar un teléfono a través de un rootkit, explicando diferentes métodos de obtención de la syscall_table, con el objetivo final de desplegar nuestros módulos infectados. Por otro lado, se explicará y desguazará la estructura de los ficheros de clases DEX, mostrando cómo ocultar malware dentro de ellos para infectar un terminal desde el desconocimiento del usuario utilizando como soporte vulnerabilidades que afectan a todos los terminales en sus diferentes versiones de Android. Conectando entre sí ambas partes

1. Dude,
where
is
my
droid?!

2. About
Sebas4án
Guerrero
/
Mobile
Security
Analyst
at
viaForensics
• h5ps://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

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

4. Introduc4on
–
Android
plaGorm
sandbox
4

5. Android
Sandbox
and
other
security
protecLons
• Isolates
your
app
data
and
code
execu4on
from
other
apps
• Robust
implementa4ons
of
common
security
func4onality
• Cryptography,
permissions,
IPC
• Other
security
technologies
to
mi4gate
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
• Applica4on-­‐defined
permissions
to
control
applica4on
data
on
a
per-­‐app
basis.
5

6. The
purpose
of
Sandbox
Security?
6

7. Android
‘smart’
sandbox
7

8. Reality
of
sandbox
security
• Security
threat
caused
by
malware
inside
of
Sandbox
• MulLple
malware
apps,
backdoor,
trojans,
etc
• Overcharged
fee,
personal
informaLon
leak,
eavesdropping
• Spam
SMS,
DDoS
botnet
a5acks
• Code
injecLon
into
legiLmate
apps
• TapJacking
Vulnerability
• Security
threat
caused
by
vulnerabili4es
out
side
of
Sandbox
• Android
3rd
party
applicaLons
and
webkit
remote
a5ack
• Local
rooLng
exploit
code,
using
kernel
vulnerabiliLes
• LKM
kernel
rootkit
a5acks
• Hard
to
apply
a
security
update
on
a
smart
plaaorm
8

9. MoLvaLons
behind
this
work
• 80%
of
all
users
carry
their
devices
with
them
at
all
4mes
• As
of
Q4
2012,
500
million
devices
ac4vated
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
connecLvity
• Users
have
highly
sensi4ve
informa4on
in
their
smartphones
• Personal
/
Business
email
• Account
credenLals
(Social
networks,
Bank,
other
stuff…)
• Contacts,
pictures,
etc
• WiFi?
FREE?
There
we
go
• Users
never
quesLon
their
smartphone
integrity
9

10. Android
rootkits
–
Part
I
10

11. Developing
an
Android
Kernel
Rootkit
• Loadable
Kernel
Modules
(LKMs)
allow
to
extend
dynamically
the
kernel
func4onality
• LKMs
are
executed
in
Kernel
space
•
Add
or
remove
new
pieces
of
code
without
a
recompilaLon
or
reboot
• System
Calls
are
used
for
system
opera4ons
• 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
func4onali4es
• Hide
files,
processes,
connecLons
• Leak
user’s
informaLon
• Install
backdoors
through
which
the
device
can
be
accessed
• Hide
those
logs
lel
behind
as
a
record
of
system
intrusion
11

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

13. IniLal
difficulLes
• 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
informaLon
• Deploying
the
vector
a5ack
13

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
• Solu4on
#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

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

16. Searching
sys_call_table
3/6
Solu4on
#3
Gewng
sys_call_table
address
from
vector_swi
handler
16

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

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

19. Searching
sys_call_table
6/6
• Aeer
an
ENDPROC
instruc4on
there
is
always
hope
• __sys_trace
declaraLve
–
0xc0026z4
t
(Kernel
based)
• Now
we
are
able
to
delimit
the
EVT
• We’re
looking
for
an
‘adr’
instrucLon,
which
is
really:
‘add’
and
‘ldr’
• Keep
calm
and
use
R2
from
git
• opcode
e28f8080
–
add
r8,
pc,
0x80
• opcode
e599c000
ldr
ip,
[r9]
19

20. Keep
calm
and
use
r2
from
git
20

21. 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
• Solu4on
#1:
• Modify
UTS_RELEASE
constant
defined
in
/include/linux/utsrelease.h
• Problem
#1:
• Great
if
you’re
chinese
and
have
enough
Lme
to
recompile
every
Kernel
version
for
your
module
21

22. Compile
against
the
device
Kernel
version
2/3
• Solu4on
#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
22

23. Compile
against
the
device
Kernel
version
3/3
• Solu4on
#3:
• Use
a
script
to
overwrite
directly
the
vermagic
value
in
execuLon
Lme
• Available
on
my
GitHub
(0xroot)
• Problem
#3:
• Only
works
in
some
cases,
someLmes
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
23

24. System
call
debugging
• What
else
can
we
do?
• We
can
discover
phone
rouLnes
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
applicaLons
acLvity
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
• …
24

25. 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
applicaLons
from
a
device
• Browser,
Tweetdeck,
Instagram,
Malware…
25

26. DEMO
I
–
A
reverse
TCP
shell
over
3G/WiFi
26

27. DEMO
II
–
Debugging
an
user-­‐land
applica4on
27

28. DEMO
III–
Debugging
a
piece
of
malware
28

29. Android
rootkits
-­‐
Part
II
29

30. A
possible
a5ack
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
30

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

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

33. How
can
we
deploy
this
a5ack
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
secLon
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
33

34. How
can
we
deploy
this
a5ack
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:
[Add
link
to
my
github
code]
• Re-­‐package
APK
• Replace
the
current
DEX
by
the
new
one.
• Zip
all
and
sign
it
using
jarsigner
34

35. DEMO
IV–
Hiding
last
method
of
last
class
35

36. But…
We
have
an4virus
and
we’re
protected,
isn’t
it?
36

37. What
did
we
test?
• AV
solu4ons
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
protecLon
against
this
kind
of
a5ack
• Their
only
swiss
army
knife
is
to
detect
the
LKM
at
deployment
stage
37

38. Conclusions
hone?!
ving
a
p
S4 ll
ha
There’s
no
virus
for
iPhone!11
That
was
a
fanboy
:D
38

39. QUESTIONS?
Thanks!!
blog.seguesec.com
github.com/0xroot
@0xroot
Greets:
@pof,
@pancake,
@fsero,
L,
@reversemode,
@matalaz,
@DS,
@Lmstrazz,
@thomas_cannon,
@marcograss,
@insitusec,
Rootedcon,
iSexAud,
n
and
many
others!
:D
39