Sebastián Guerrero - Ke ase Android? [Rooted CON 2013]

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 ﬁlesystem that can be enabled to protect data on lost devices •  Fine grained permissions to restrict access to system and user data •  Applica4on-‐deﬁned 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 stuﬀ…) •  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 ﬁles, 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 diﬃculLes •  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 deﬁned 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 eﬃcient 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 speciﬁc 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 deﬁned 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 speciﬁc data, input or commands •  Prompt a reverse TCP shell when the phone receives a speciﬁc 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 predeﬁned 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 ﬁles (*.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 oﬀsets/sizes to all secLons •  Tables contain references to each other, and oﬀsets 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 ﬁle as argument and debugging ﬂags 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 ﬁles in system data app, the AV doesn’t care about that directories •  Actually, there is no an AV product that oﬀers 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

Sebastián Guerrero - Ke ase Android? [Rooted CON 2013]

Du liest eine Vorschau.

Hier ansehen

Sebastián Guerrero - Ke ase Android? [Rooted CON 2013]

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Ähnlich wie Sebastián Guerrero - Ke ase Android? [Rooted CON 2013] (20)

Weitere von RootedCON (20)

Aktuellste (20)