Dude where's my droid

40
Dude, where’s my droid?!

Transcript of Dude where's my droid

Page 1: Dude where's my droid

Dude,  where’s  my  droid?!  

 

 

Page 2: Dude where's my droid

2/41  

About    

Sebas6án  Guerrero  /  Mobile  Security  Analyst  at  viaForensics    

•  h6ps://blog.seguesec.com  

•  [email protected]    /  @0xroot  

•  I’m  sexy  and  I  know  it  

•  No  devices  were  harmed  or  infected  for  this  talk.  

Page 3: Dude where's my droid

3/41  

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  

Page 4: Dude where's my droid

Introduc6on  –  Android  plaJorm  sandbox  

 

 

4/41  

Page 5: Dude where's my droid

5/41  

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.  

Page 6: Dude where's my droid

6/41  

The  purpose  of  Sandbox  

Security?  

Page 7: Dude where's my droid

7/41  

Android  ‘smart’  sandbox  

Page 8: Dude where's my droid

8/41  

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  

Page 9: Dude where's my droid

9/41  

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  

Page 10: Dude where's my droid

Android  rootkits  –  Part  I  

 

  10/41  

Page 11: Dude where's my droid

11/41  

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  

 

Page 12: Dude where's my droid

12/41  

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    

Page 13: Dude where's my droid

13/41  

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  

 

Page 14: Dude where's my droid

14/41  

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  

 

Page 15: Dude where's my droid

15/41  

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  

 

 

Page 16: Dude where's my droid

16/41  

Searching  sys_call_table  3/6  

Solu6on  #3  Gevng  sys_call_table  address  from  vector_swi  handler  

 

 

Page 17: Dude where's my droid

17/41  

Searching  sys_call_table  4/6  

 

 An  excep6on/interrupt  occurs  

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  

Calling  the  real  func6on  Calling  the  hooking  func6on    

Page 18: Dude where's my droid

18/41  

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??  

Page 19: Dude where's my droid

19/41  

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]  

 

 

Page 20: Dude where's my droid

20/41  

Keep  calm  and  use  r2  from  git  

 

 

Page 21: Dude where's my droid

22/41  

There  we  go  

8============D  

Page 22: Dude where's my droid

23/41  

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  

 

 

Page 23: Dude where's my droid

24/41  

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  

 

 

Page 24: Dude where's my droid

25/41  

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  

Page 25: Dude where's my droid

26/41  

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  •  …  

 

 

Page 26: Dude where's my droid

27/41  

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  

 

 

Page 27: Dude where's my droid

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

 

 

28/41  

 

 

Page 28: Dude where's my droid

DEMO  II  –  Debugging  an  user-­‐land  applica6on  

 

 

 

29/41  

 

 

Page 29: Dude where's my droid

DEMO  III–  Debugging  a  piece  of  malware  

 

 

30/41  

 

 

Page 30: Dude where's my droid

Android  rootkits  -­‐  Part  II  

 

  31/41  

 

 

Page 31: Dude where's my droid

32/41  

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  

 

 

Page 32: Dude where's my droid

•  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  

How  can  we  deploy  this  a6ack  1/4  

Page 33: Dude where's my droid

34/41  

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  

 

 

Page 34: Dude where's my droid

35/41  

How  can  we  deploy  this  a6ack  3/4  

•  How  can  we  hide  a  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  

We  got  access  to  the  vector  class_data_item  where:    -­‐  direct_methods  :  The  defined  direct  method    -­‐  virtual_methods:  The  defined  virtual  method  

Page 35: Dude where's my droid

36/41  

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  

 

 

 

Page 36: Dude where's my droid

DEMO  IV–  Hiding  last  method  of  last  class  

 

 

37/41  

 

 

Page 37: Dude where's my droid

38/41  

 

 

But…  We  have  an6virus  and  we’re  protected,  isn’t  it?  

 

 

Page 38: Dude where's my droid

39/41  

 

 

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    

 

 

Page 39: Dude where's my droid

40/41  

 

 

Conclusions  

S6ll  having  a

 phone?!  

Page 40: Dude where's my droid

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  

 

 

QUESTIONS?