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.

Mobile security chess board - attacks & defense

867 views

Published on

Mobile Security Review

Published in: Software
  • Be the first to comment

  • Be the first to like this

Mobile security chess board - attacks & defense

  1. 1. Mobile  Security  chess  board  -­‐   A4acks  &  Defense  
  2. 2. Who Am I? •  Hemil  Shah  –  hemil@blueinfy.net   •  Co-­‐CEO  &  Director,  Blueinfy  Solu>ons   •  Past  experience     –  eSphere  Security,  HBO,  KPMG,  IL&FS,  Net  Square   •  Interest   –  ApplicaIon  security  research   •  Published  research   –  ArIcles  /  Papers  –  Packstroem,  etc.   –  Web  Tools  –  wsScanner,  scanweb2.0,  AppMap,  AppCodeScan,  AppPrint  etc.   –  Mobile  Tools  –  FSDroid,  iAppliScan,  DumpDroid   hemil@blueinfy.com   h4p://www.blueinfy.com   Blog  –  h4p://blog.blueinfy.com/  
  3. 3. About • Global  experience  worked   clients  based  in  USA,  UAE,   Europe  and  Asia-­‐pac.   • Clients/Partners  include   Fortune  100  companies.   • Delivery  model  and  support   • Blackbox  and  Whitebox  –   Scanners  and  Code  Analyzers   • Scanning  tools  and  technology   (15  years)   • Strong  and  tested  with   Fortune  clients   • Integrated  in  SDLC   • Help  client  in  miIgaIng  or   lowering  down  the  Risk  by   improving  process   • In  house  R&D  team  for  last  7   years   • Papers  and  PresentaIons  at   conference  like  RSA,  Blackhat,   HITB,  OWASP  etc.   • Books  wri4en  and  used  as   security  guides   Know-­‐How   Methods  &   Approach   Global   Delivery  &   Team   Technology   Ø BBC   Ø Dark  Readings   Ø Bank  Technology   Ø SecurityWeek   Ø MIT  Technology  Review   ApplicaIon  Security    
  4. 4. Mobile  Apps  
  5. 5. Market  Share  
  6. 6. Mobile  Top  10  -­‐  OWASP   •  Weak  Server  Side  Controls   •  Insecure  Data  Storage   •  Insufficient  Transport  Layer  ProtecIon   •  Unintended  Data  Leakage   •  Poor  AuthorizaIon  and  AuthenIcaIon   •  Broken  Cryptography   •  Client  Side  InjecIon   •  Security  Decisions  Via  Untrusted  Inputs   •  Improper  Session  Handling   •  Lack  of  Binary  ProtecIons     Contributor : Nvisium Security, HP Fortify, Andreas Athanasoulias & Syntax IT, eSphere Security, Godfrey Nolan and RIIS (Research Into Internet Systems), Arxan Technologies Ref - https://www.owasp.org/index.php/Mobile_Top_Contributions
  7. 7. Enterprise  Mobile  Cases  
  8. 8. E-­‐commerce   •  Typical  applicaIon  making  server  side  calls   •  Security  issues  and  hacks   –  Credit  card  and  Private  data  storage  with  poor  crypto   –  SQLite  hacks   –  SQL  injecIon  over  JSON   –  Ajax  driven  XSS   –  Several  XSS  with  Blog  component   –  Several  informaIon  leaks  through  JSON  fuzzing   •  Server  side  scan  with  tools/products  failed    
  9. 9. Banking  ApplicaIon   •  Scanning  applicaIon  for  vulnerabiliIes   •  Typical  banking  running  with  middleware     •  VulnerabiliIes  –  Mobile  interface   –  Poor  encoding  to  store  SSN  and  PII  informa>on   locally   –  Very  sensi>ve  transac>on  informa>on  stored   locally   –  Default  OS  Behavior  leaking  informa>on   –  CredenIals  submi4ed  in  GET  request   –  Keys/session  stored  in  keychain  file  
  10. 10. Social  ApplicaIon   •  Social  ApplicaIon  on  mulIple  plagorms   –  ApplicaIon  leverages  browser  component  as  part   of  the  mobile   –  Common  code  base  for  all  plagorms   –  Vulnerable     • Bypass  Profile  validaIon  (Logical)  and  unique  device   installaIon     • Screenshot  revealing  sensi>ve  informa>on     • Default  OS  Behavior  leaking  informa>on   • PresentaIon  layer  (XSS  and  CSRF)   • Unencrypted  Communica>on  channel  
  11. 11. Postmortem   •  One  pa4ern  in  all  the  reviews  -­‐  SOME   INFORMATION  WAS  STORED  LOCALLY   •  More  than  99%  of  the  applicaIon  review  has   the  LOCAL  STORAGE  issue  as  we  saw  in  stats.   •  Server  side  and  logical  issues  are  sIll  hard  to   find  but  have  biggest  impact.    
  12. 12. Mobile  Threats  and  Risk  
  13. 13. A4acks  on  Mobile   •  No JailBreak Required •  Ease of attack - Airports/Public places
  14. 14. Why  should  I  worry?   •  We  have  MDM  in  place   •  We  do  not  allow  any  JailBreak  or  rooted   device  in  our  environment  with  MDM   •  We  have  strict  policy  enforced  and  all  our   devices  are  forced  to  have  password  lock   •  May  or  may  not  have  BYOD     •  OS  provides  encrypIon  
  15. 15. Mobile  A4acks   •  So  What  a4acks  are  we  talking  about?     •  Privacy  becomes  important  along  with  the   Security  in  mobile  space   •  It  is  MOBILE  so  chances  of  loosing  device  or   someone  gemng  physical  access  to  it  is  MUCH   MUCH  higher  than  the  other  devices  
  16. 16. ExploitaIon   •  Physical  Then   •  Temporary  physical  access   •  Malware   •  Malicious  ApplicaIons   •  Lack  of  standardize  security  review  process   •  JailBreak/Rooted  devices  
  17. 17. What  can  be  done???   •  InformaIon  found  in  local  storage  with   default  OS  behavior  –     •  Changing  OS  behavior  -­‐     •  Server  side  exploitaIon  –   •  XSS  in  Mobile  Hybrid  applicaIon  –    
  18. 18.        Technology  Trends  
  19. 19. Mobile  Infrastructure   www mail intranet router DMZ Internet VPN Dial-up Other Office s Exchange firewall Database RAS
  20. 20. Mobile  App  Environment   Web Server Static pages only (HTML,HTM, etc.)Web Client Scripted Web Engine Dynamic pages (ASP,DHTML, PHP, CGI, etc.) ASP.NET on .Net Framework, J2EE App Server, Web Services, etc. Application Servers And Integrated Framework Internet DMZ Trusted W E B S E R V I C E S Mobile SOAP/JSON etc. DB X Internal/Corporate
  21. 21. Mobile  Architecture   Presentation Layer Business Layer Data Access Layer Authentication Communication etc. Runtime, Platform, Operating System Components Server side Components Client side Components (Browser) • HTML 5 • DOM • XHR • WebSocket • Storage • WebSQL • Flash • Flex • AMF • Silverlight • WCF • XAML • NET • Storage • JS • Android • iPhone/Pad • Other Mobile
  22. 22. Game  is  complex  –  Chess  
  23. 23. Challenges  
  24. 24. Challenges   •  Different  code  base   •  Achieve  things  with  single  click   •  Vendor  review  process  -­‐  Not  transparent  –   Can  we  rely  on  it???   •  Decrease  transacIon  Ime   •  CompeIIon     •  Rapid  business  requirement  results  in  high   frequency  of  updates  
  25. 25. Frequency  of  updates   •  Very  High  compare  to  Web  ApplicaIons   •  Usually,  4-­‐5  updates  in  a  year  for  web   applicaIons  or  even  less  at  Imes   •  Usually,  10-­‐12  updates  in  mobile  applicaIons   or  even  more  in  some  cases   •  We  all  have  accepted  that  applicaIon  needs   to  be  reviewed  before  going  to  producIon  –   DID  WE???  
  26. 26. Frequency  of  Updates   Application Name   Number of Releases in iOS   Number of Releases in Android   Facebook   19   34   Twitter   22   25   Chase Bank   9   2   eBay   9   4   Amazon   10   3   Temple Run 2   12   10   FB Messenger   12   10   Whatsapp   4   154   skype   8   6  
  27. 27. Mobile  A4acks   •  So  What  a4acks  are  we  talking  about?     •  Privacy  becomes  important  along  with  the   Security  in  mobile  space   •  It  is  MOBILE  so  chances  of  loosing  device  or   someone  gemng  physical  access  to  it  is  MUCH   MUCH  higher  than  the  other  devices  
  28. 28. Mobile  Top  10  -­‐  OWASP   •  Weak  Server  Side  Controls   •  Insecure  Data  Storage   •  Insufficient  Transport  Layer  ProtecIon   •  Unintended  Data  Leakage   •  Poor  AuthorizaIon  and  AuthenIcaIon   •  Broken  Cryptography   •  Client  Side  InjecIon   •  Security  Decisions  Via  Untrusted  Inputs   •  Improper  Session  Handling   •  Lack  of  Binary  ProtecIons     Contributor : Nvisium Security, HP Fortify, Andreas Athanasoulias & Syntax IT, eSphere Security, Godfrey Nolan and RIIS (Research Into Internet Systems), Arxan Technologies Ref - https://www.owasp.org/index.php/Mobile_Top_Contributions
  29. 29. Top  5  vulnerability   •  From  the  stats  of  eSphere  data  -­‐     0 10 20 30 40 50 60 70 80 90 100 Local Storage Sensitive Information stored in Logs/ Default OS Behaviour Copy/Paste enabled in sensitive fields - Privacy issue Cross Site Scripting SQL Injection over JSON or other streams
  30. 30. Mobile  A4acks  
  31. 31. Weak  Server  Side  Controls  
  32. 32. Server  Side  Issues   •  Most  ApplicaIon  makes  server  side  calls  to   either  web  services  or  some  other   component.  Security  of  server  side   component  is  equally  important  as  client  side   •  Controls  to  be  tested  on  the  server  side  –   Security  Control  Categories  for  Server  Side   ApplicaIon–  AuthenIcaIon,  Access  Controls/ AuthorizaIon,  API  misuse,  Path  traversal,   SensiIve  informaIon  leakage,  
  33. 33. Server  Side  Issues   •  Error  handling,  Session  management,   Protocol  abuse,  Input  validaIons,  XSS,  CSRF,   Logic  bypass,  Insecure  crypto,  DoS,  Malicious   Code  InjecIon,  SQL  injecIon,  XPATH  and   LDAP  injecIons,  OS  command  injecIon,   Parameter  manipulaIons,  BruteForce,  Buffer   Overflow,  HTTP  response  splimng,  HTTP   replay,  XML  injecIon,  CanonicalizaIon,   Logging  and  audiIng.    
  34. 34. Insecure  Data  Storage  
  35. 35. Insecure  Storage   •  How  a4acker  can  gain  access   •  Wifi     •  Default  password  aner  jail  breaking  (alpine)   •  Adb  over  wifi   •  Physical  Then   •  Temporary  access  to  device    
  36. 36. What   •  What  informaIon   –  AuthenIcaIon  CredenIals   –  AuthorizaIon  tokens   –  Financial  Statements   –  Credit  card  numbers   –  Owner’s  InformaIon  –  Physical  Address,  Name,   Phone  number   –  Social  Engineering  Sites  profile/habbits   –  SQL  Queries  
  37. 37. Insufficient  Transport  Layer   ProtecIon  
  38. 38. Insecure  Network  Channel   •  Easy  to  perform  MiM  a4acks  as  Mobile   devices  uses  untrusted  network  i.e  open/ Public  WiFi,  HotSpot,  Carrier’s  Network   •  ApplicaIon  deals  with  sensiIve  data  i.e.     •  AuthenIcaIon  credenIals   •  AuthorizaIon  token   •  PII  InformaIon  (Privacy  ViolaIon)  (Owner  Name,   Phone  number,  UDID)  
  39. 39. Insecure  Network  Channel   •  Can  sniff  the  traffic  to  get  an  access  to   sensiIve  data   •  SSL  is  the  best  way  to  secure  communicaIon   channel   •  Common  Issues   •  Does  not  deprecate  HTTP  requests   •  Allowing  invalid  cerIficates   •  SensiIve  informaIon  in  GET  requests  
  40. 40. Session  token  
  41. 41. Unintended  Data  Leakage  
  42. 42. Unintended  Data  Leakage     •  Plagorm  issues  –  sandboxing  or  disable   controls   •  Cache   •  Logs,  Keystrokes,  screenshots  etc.   •  Temp  files   •  3rd  Party  libs  (AD  networks  and  analyIcs)    
  43. 43. Data  Leakage   •  Default  OS  behavior  aner  iOS  4.0  to  cache  all   the  URLS  (Request/Response)  in  the  local   storage  in  file  named  cache.db  file   •  Cache.db  file  is  not  encrypted   •  By  default,  applicaIon  takes  last  screenshot   and  saves  it  in  to  file  system  when  user   presses  home  bu4on  
  44. 44. Poor  AuthorizaIon  and   AuthenIcaIon  
  45. 45. AuthorizaIon  &  AuthenIcaIon   •  No  password  complexity  specially  on  mobile     •  Hidden/No  Logout  bu4on   •  Long  session  Ime  out   •  No  account  lock  out   •  AuthorizaIon  flags  or  based  on  the  local   storage  
  46. 46. Broken  Cryptography  
  47. 47. Cryptography   •  Broken  implementaIon   •  Hash/Encoding  used  in  place  of  encrypIon   •  Client  side  script  in  place  of  SSL  
  48. 48. Client  Side  InjecIon  
  49. 49. SQL  InjecIon  in  Local  database   •  Most  Mobile  plagorms  uses  SQLite  as   database  to  store  informaIon  on  the  device   •  Using  any  SQLite  Database  Browser,  it  is   possible  to  access  database  logs  which  has   queries  and  other  sensiIve  database   informaIon   •  In  case  applicaIon  is  not  filtering  input,  SQL   InjecIon  on  local  database  is  possible  
  50. 50. Security  Decisions  Via  Untrusted   Inputs  
  51. 51. Untrusted  Source   •  Any  input  from  client  side  which  can  be   modified     •  Mainly  authenIcaIon  and  authorizaIon   decisions  based  on  the  untrusted  input   •  Easiest  way  for  developer  to  solve  complex   issues/funcIonality     •  A4acker  can  get  this  informaIon  by  either   reverse  engineering  applicaIon  or  by   checking  local  storage  
  52. 52. KeyChain  Dumper   •  Easy  as  running  a  command   •  Upload  on  to  server  in  /var  directory   •  Give  execute  permission   •  Chmod  +x  /var/keychain_dumper   •  Get  all  the  keys   •  ./keychain_dumper  
  53. 53. Improper  Session  Handling  
  54. 54. Improper  Session   •  Session  is  key  for  any  applicaIon  for   authorizaIon       •  Session  is  stored  in  binary  format  but  can  be   easily  reversible   •  ApplicaIon  is  sending  sensiIve  informaIon   in  GET  request  (Be  it  on  HTTP  or  HTTPS)  
  55. 55. Lack  of  Binary  protecIon  
  56. 56. Lack  of  Binary  ProtecIon   •  Apple  signs  and  encrypts  all  the  binaries     •  SIll  strings  can  be  retrieved  from  the  binary     •  Storing  EncrypIon  and  DecrypIon  keys  in   the  client  side  is  sIll  a  problem      
  57. 57. AutomaIon  in  ApplicaIon   Reviews  
  58. 58. Manual  Review     •  Looking  for  informaIon  in  local  storage   manually  is  really  –     –  Time  Consuming   –  Tedious   –  Prone  to  be  false  negaIves  (how  accurately  you   can  check  files  more  than  once  in  an  hour  and  file   formats  are  different)    
  59. 59. Manual  Review  -­‐  iOS  
  60. 60. What  do  we  need   •  AutomaIon!!!   •  AutomaIon!!!   •  AutomaIon!!!   •  AutomaIon!!!   •  AutomaIon!!!   •  Unfortunately  no  complete  automaIon  is   available  today  BUT  some  of  the  tools  which   can  be  handy  are  -­‐      
  61. 61. Snoop-­‐it   •  The  only  tool  today  to  automate  iOS   applicaIon  reviews   •  Very  handy  and  gives  perfect  pointer  where   to  look  for   •  A  long  way  to  go  for  automaIon  like  web    
  62. 62. Snoop-­‐it  (Cont…)   •  Snoop-­‐it  helps  you  monitor  –     –  File  system  access   –  Keychain  access   –  HTTP(S)  connecIons     –  Access  to  sensiIve  API   –  Debug  outputs   –  Tracing  App  internals  
  63. 63. Snoop-­‐it  (Cont…)   •  Along  with  Monitoring,  snoop-­‐it  allows  to  -­‐     –  Fake  hardware  idenIfier   –  Fake  locaIon/GPS  data   –  Explore  and  force  display  of   available  ViewController   –  List  custom  URL  schemes   –  List  available  ObjecIve-­‐C  classes,  objects  and   methods   –  Bypass  basic  jailbreak  detecIon  mechanisms  
  64. 64. Snoop-­‐it  
  65. 65. iAppliScan   •  iAppliScan  allows  you  to  automate  iOS   applicaIon  review.     •  InteresIng  features  –     –   Look  for  sensiIve  informaIon  in  files/directories   –  Find  whether  parIcular  file  exist  or  not   –  Download  file  for  further  analysis   –  Run  external  command    
  66. 66. iAppliScan  
  67. 67. Review  without  JailBreak  
  68. 68. Reviewing  without  jailbreaking   •  Is  it  really  possible  to  review  applicaIon  with   out  jailbreaking  ?   •  “YES”   •  “YES”   •  “YES”   •  “YES”  
  69. 69. Reviewing  without  jailbreaking   •  Plenty  of  tools  available  (Specially  for   Forensic)  to  brows  the  applicaIon  directory   without  jailbreaking.     •  iFunBox  allows  to  view  files  on  the  device   without  jailbreak   •  Displays  applicaIon’s  permissions   •  Browse  the  installed  applicaIon  directory    
  70. 70. Reviewing  without  jailbreaking   •  Copy    the  enIre  applicaIon  directory  mulIple   Imes   •  Look  for  sensiIve  informaIon  in  the  files   •  Use  Proxy  on  non-­‐jailbreak  device  to  check  all   server  side  a4acks.  
  71. 71. Reviewing  with  iFunbox  
  72. 72. AutomaIon  in  Android  
  73. 73. Manual  Review  -­‐  Android  
  74. 74. FSDroid   •  Leverages  SDK  Class  –  No  hacks  in  here!!!   •  FSDroid  can  –   –  Monitor  file  system     –  Can  write  filter  to  monitor  parIcular  directory   –  Can  save  last  5  reports  for  future  use   –  Does  not  need  mobile  device  –  can  run  on   Emulator  smoothly   –  Easy  to  run  (As  easy  as  giving  directory  name  and   pressing  start  bu4on)    
  75. 75. File  System  Monitoring  Demo  
  76. 76. Looking  in  to  Code  
  77. 77. Static Code Analysis •  Introduce in Mac OS X v10.6, XCode 3.2, Clang analyzer merged into XCode. •  Memory leakage warning •  Run from Build->Analyze •  Innovative shows you complete flow of object start to end •  Configure as a automatic analysis during build process
  78. 78. StaIc  Code  Analysis     PotenIal  Memory  Leak  
  79. 79. StaIc  Code  Analysis     Dead  store  –  variable  never  used  
  80. 80. Code  Analysis  with  AppCodeScan   •  Semi  automated  tool   •  Ability  to  expand  with  custom  rules   •  Simple  tracing  uIlity  to  verify  and  track   vulnerabiliIes   •  Simple  HTML  reporIng  which  can  be   converted  to  PDF    
  81. 81. AppCodeScan   •  SophisIcated  tool  consist  of  two  components     •  Code  Scanning   •  Code  Tracer   •  Allows  you  to  trace  back  the  variable   •  AppCodeScan  is  not  complete  automated   staIc  code  analyzer.   •  It  only  relies  on  regex  and  lets  you  find   SOURCE  of  the  SINK  
  82. 82. Rules  in  AppCodeScan   •  WriIng  rules  is  very  straight  forward   •  In  an  XML  file  which  is  loaded  at  run  Ime   •  This  release  has  rules  for  iOS  and  Android  for   -­‐  Local  Storage,  Unsafe  APIs,  SQL  InjecIon,   Network  ConnecIon,  SSL  CerIficate  Handling,   Client  Side  ExploitaIon,  URL  Handlers,   Logging,  CredenIal  Management  and   Accessing  PII.      
  83. 83. Sample  Rules  -­‐  Android    
  84. 84. Android  DEMO  
  85. 85. Sample  Rules  -­‐  iOS    
  86. 86. iOS  DEMO  
  87. 87. Debuggable  flag  in  Android   •  One  of  the  key  a4ribute  in  android  manifest   file   •  Under  “applicaIon”  secIon   •  Describes  debugging  in  enabled   •  If  “Debuggable”a4ribute  is  set  o  true,  the   applicaIon  will  try  to  connect  to  a  local  unix   socket  “@jdwp-­‐control”   •  Using  JDWP,  It  is  possible  to  gain  full  access  to   the  Java  process  and  execute  arbitrary  code  in   the  context  of  the  debugable  applicaIon  
  88. 88. CheckDebuggable  Script   •  Checks  in  APK  whether  debuggable  is  enabled   •  Script  can  be  found  at  –  h4p:// www.espheresecurity.com/ resourcestools.html   •  Paper  can  be  found  at  -­‐  h4p:// www.espheresecurity.com/ CheckDebuggable.pdf    
  89. 89. Conclusion  

×