Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Dude where's my droid

2,010 views

Published on

  • Be the first to comment

  • Be the first to like this

Dude where's my droid

  1. 1. Dude,  where’s  my  droid?!      
  2. 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. 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. 4. Introduc6on  –  Android  plaJorm   sandbox     4/41  
  5. 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. 6. The  purpose  of  Sandbox   Security?   6/41  
  7. 7. Android  ‘smart’  sandbox   7/41  
  8. 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. 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. 10. Android  rootkits  –  Part  I       10/41  
  11. 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. 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. 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. 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. 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. 16. Searching  sys_call_table  3/6   Solu6on  #3   Gevng  sys_call_table  address  from  vector_swi  handler       16/41  
  17. 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. 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  its  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. 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. 20. Keep  calm  and  use  r2  from  git       20/41  
  21. 21. There  we  go   8============D   22/41  
  22. 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. 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. 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. 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. 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. 27. DEMO  I  –  A  reverse  TCP  shell  over     3G/WiFi       28/41  
  28. 28. DEMO  II  –  Debugging  an  user-­‐land     applica6on         29/41  
  29. 29. DEMO  III–  Debugging  a  piece  of     malware       30/41  
  30. 30. Android  rootkits  -­‐  Part  II           31/41  
  31. 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. 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. 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. 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. 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. 36. DEMO  IV–  Hiding  last  method     of  last  class       37/41  
  37. 37. But…  We  have  an6virus  and   we’re  protected,  isn’t  it?           38/41  
  38. 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. 39. Conclusions   hone?!   ving  a  p   S6 ll  ha   40/41  
  40. 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  

×