Your SlideShare is downloading. ×
  • Like
  • Save
Sebastián Guerrero - Ke ase Android? [Rooted CON 2013]
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

  • 989 views
Published

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

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

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
989
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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