Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile - Onofri
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile - Onofri

on

  • 154 views

Slides from Simone Onofri talk @Codemotion Roma 2014

Slides from Simone Onofri talk @Codemotion Roma 2014

Statistics

Views

Total Views
154
Views on SlideShare
153
Embed Views
1

Actions

Likes
1
Downloads
4
Comments
0

1 Embed 1

http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile - Onofri Presentation Transcript

  • 1. ROME 11-12 april 2014ROME 11-12 april 2014 Hackers vs Developers: vulnerabilità e soluzioni nello sviluppo di applicazioni Mobile simone.onofri@techub.it Simone Onofri
  • 2. Introduzione
  • 3. h,p://onofri.org/u/hvd14
  • 4. Agenda • Introduzione   • Cosa  succede  nel  mondo  della  sicurezza  del   mobile   • Quali  sono  gli  a5acchi  e  le  minacce?   • Cosa  ne  pensa  OWASP?   • Come  rendere  sicure  le  nostre  applicazioni   mobile   • Q&A  e  Conclusioni
  • 5. Agenda • Introduzione   • Cosa  succede  nel  mondo  della  sicurezza  del   mobile   • Quali  sono  gli  a5acchi  e  le  minacce?   • Cosa  ne  pensa  OWASP?   • Come  rendere  sicure  le  nostre  applicazioni   mobile   • Q&A  e  Conclusioni
  • 6. Perché  siamo  qui
  • 7. Cosa  succede  nel  mondo?
  • 8. Computer  Security  Timeline 1970 Nei  primi  anni  nasce  il   primo   Virus,  infe5a  gli  Apple  e     si  diffonde  tramite  Floppy.   Negli  ulAmi  anni  nascono    i   Worm,  alcuni  dei  quali   cifrano  il  disco.  A,acchi  alle   PA. 1980 1990 Blue  Box  Phreaking     da  Capitan  Crunch.   A5acchi  alle  compagnie   telefoniche. Il  mezzo  di  propagazione   è  spesso  l’e-­‐mail  e  i   bersagli  sono  i  sistemi   operaAvi  MicrosoI   (a5accando  es.  Outlook   express).  Il  bersaglio  sono   le  persone.
  • 9. Computer  Security  Timeline 2000 Si  denunciano  Advanced   Persistent  Threat.  I   disposiAvi  mobile   diventano  un  bersaglio   Apico.  Sono  molto  frequenA   a5acchi  a  sfondo  poliQco.   Diventa  evidente  come   quesA  strumenA  siano  usaQ   come  armi. 2010 I  Virus  a5accano  anche   i  servizi  di  rete  (es.  Slammer,    Sasser  e  Blaster).     Iniziano  gli  a5acchi     alle  Applicazioni  Web  e  su   SCADA.  L’obieQvo  è  anche   creare  disservizi.     E’  a  tuQ  gli  effeQ   un  Business.  
  • 10. Aumenta  la  sofisAcazione  degli  a,acchi  che   mirano  a  creare  un  disservizio  e  di  quelli  che   hanno  come  bersaglio  le  applicazioni  web.  
  • 11. A5acchi  frequenA  sono  ai  disposiAvi  Mobile,   bersaglio  di  malware  per  rubare  conQ  o   transazioni  bancarie,  daQ  di  accesso  (social,   e-­‐mail).  Furto  di  idenQtà  e  di  daA  più  in   generale.
  • 12. Sopra5u5o  sul  sistema  operaAvo  Android.  Ne  è  moAvo   la  forte  diffusione  e  il  fa5o  che  non  sono  spesso   distribuiQ  tempesQvamente  gli  aggiornamenQ  di   sicurezza  da  parte  dei  provider  che  “brandizzano”  il   disposiAvo  
  • 13. Aumenta  la  sofisAcazione  degli  a,acchi  che   mirano  a  creare  un  disservizio  e  di  quelli  che   hanno  come  bersaglio  le  applicazioni.  
  • 14. gli  a5accanA  tendono  a  sfru5are  vulnerabilità   che  sono  presenA  a  causa  di  praQche  di   sicurezza  basilari  inadeguate
  • 15. app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app Circa  la  metà  delle  applicazioni  web  hanno  vulnerabilità   importanA  secondo  l’X-­‐Force 50%
  • 16. app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app   app  app  app  app Quasi  tu5e  le  applicazioni  sono  vulnerabili  secondo  il  report   CENZIC 99%
  • 17. Le  principali  problemaQche  delle  applicazioni   mobile
  • 18. La  TOP  10  Risk  Mobile  (2013  vs  2014  RC1) M1:Insecure  Data  Storage M2:Weak  Server  Side  Controls M3:Insufficient  Transport  Layer   ProtecQon M4:  Client  Side  InjecQon M5:  Poor  AuthorizaQon  and   AuthenQcaQon M6:  Improper  Session  Handling M7:  Security  Decisions  Via  Untrusted   Inputs M8:  Side  Channel  Data  Leakage M9:  Broken  Cryptography M10:  SensiQve  InformaQon  Disclosure M1:  Weak  Server  Side  Controls M2:  Insecure  Data  Storage M3:Insufficient  Transport  Layer   ProtecQon M4:  Unintended  Data  Leakage M5:  Poor  AuthorizaQon  and   AuthenQcaQon M6:  Broken  Cryptography M7:  Client  Side  InjecQon M8:  Security  Decisions  via  Untrusted   Inputs M9:  Improper  Session  Handling M10:  Lack  of  Binary  ProtecQon
  • 19. Il  nostro  disposiQvo  mobile Hardware Sistema  OperaQvo RunQme Applicazioni Aziendali Personali Bult-­‐in Malicious Librerie Dipendenze VM Kernel Driver File  System Radio GPS Sensori Estensioni hardware Le,ori/ Sensori 802.11 / NFC / Bluetooth Peer Rete del Carrier SMS   Voce   DaQ WiFi /VPN (o via Carrier) Web M2:  Insecure   Data  Storage M1:  Weak  Server  Side  Controls M3:  Insufficient   Transport  Layer   ProtecQon M8:  Security  Decisions  via   Untrusted  Inputs M5:  Poor  AuthorisaQon   and  AuthenQcaQon M6:  Broken  Cryptography M7:  Client  Side  InjecQon M4:  Unintended   Data  Leakage M9:  Improper  Session  Handling M10:  Lack  of  Binary  ProtecQon
  • 20. Come  rendere  sicure  le  nostre  applicazioni  mobile
  • 21. M1.  Weak  Server  Side  Controls Sono  quelle  problemaAche  che  dipendono  dai  servizi  che  uQlizza   l’applicazione  mobile,  come  il  servizio  web  uAlizzato  (Web  Service,   REST,  SOAP).  Se  la  nostra  applicazione  uAlizza  servizi  esterni  anche   quesA  devono  essere  sicuri  e  non  dobbiamo  solamente   concentrarci  sulle  problemaAche  dell’applicazione  in  se.  Gli   a,accanQ  non  fanno  troppe  disQnzioni  tra  vulnerabilità  web,   Mobile  o  di  sistema  ma  sfru,eranno  quella  più  semplice.
  • 22. Riflessioni  e  SuggerimenQ • UAlizziamo  servizi  Web?  Facciamo  riferimento  alla  OWASP   TOP  10  Web  (almeno  per  iniziare).   • UAlizziamo  servizi  Cloud?  Facciamo  riferimento  alla  TOP  10   Cloud.
  • 23. 2003/2004   (a,acks) 2007   (vulnerabiliQes) 2010   (risks) 2013   (risks) Unvalidated  Input Cross  Site  ScripQng  (XSS) InjecQon InjecQon Broken  Access  Control InjecQon  Flaws Cross-­‐Site  ScripQng  (XSS) Broken  AuthenQcaQon   and  Session  Management Broken  AuthenQcaQon   and  Session  Management Malicious  File  ExecuQon Broken  AuthenQcaQon   and  Session  Management Cross-­‐Site  ScripQng  (XSS) Cross  Site  ScripQng  (XSS)   Flaws Insecure  Direct  Object   Reference Insecure  Direct  Object   References Insecure  Direct  Object   References Buffer  Overflows Cross  Site  Request   Forgery  (CSRF)* Cross-­‐Site  Request   Forgery  (CSRF) Security  MisconfiguraQon InjecQon  Flaws InformaQon  Leakage  and   Improper  Error  Handling Security  MisconfiguraQon SensiQve  Data  Exposure Improper  Error  Handling Broken  AuthenQcaQon   and  Session  Management Insecure  Cryptographic   Storage Missing  FuncQon  Level   Access  Control Insecure  Storage Insecure  Cryptographic   Storage Failure  to  Restrict  URL   Access Cross-­‐Site  Request   Forgery  (CSRF) Denial  of  Service Insecure  CommunicaQons Insufficient  Transport   Layer  ProtecQon Using  Known  Vulnerable   Components Insecure  ConfiguraQon   Management Failure  to  Restrict  URL   Access Unvalidated  Redirects   and  Forwards Unvalidated  Redirects   and  Forwards
  • 24. M2.  Insecure  Data  Storage Sono  quelle  problemaAche  di  protezione  dei  daQ  memorizzaQ.  Si   concreAzzano  quando  viene  compromesso  il  disposiAvo  tramite   applicazioni  malevoli  oppure  in  caso  di  furto.  Se  ci  sono  delle   informazioni  riservate  (es.  password,  CVV2,  daA  privaA)  devono   essere  proteQ.
  • 25. Riflessioni  e  SuggerimenQ • Se  il  disposiAvo  viene  rubato,  oppure  è  presente  un  trojan  o  altra  applicazione   malevola  la  nostra  applicazione  deve  proteggere  i  daA  che  gesAsce.   • Fare  a5enzione  a  quando  si  memorizzano  informazioni  su: • Database  SQLite   • File  di  Log   • Plist   • XML • File  Manifest   • Storage  di  altro  Apo  su  file   • Cookie   • Schede  SD
  • 26. M3.  Insufficient  Transport  Layer  ProtecQon Sono   quelle   problemaAche   relaAve   alla   sicurezza   della   comunicazione,  perme5ono  di  interce5are  il  traffico  tra  l’utente  e  il   server   o   tra   server   differenA.   Come   per   le   altre   vulnerabilità   il   problema  potrebbe  consistere  o  nella  mancanza  del  controllo  stesso   (come  l’uAlizzo  di  HTTP)  o  nelle  problemaAche  di  configurazione  di   SSL/TLS  sia  lato  server  ma  in  parAcolare  lato  disposiAvo  mobile.
  • 27. Riflessioni  e  SuggerimenQ • Tipicamente  un  disposiAvo  mobile  viene  uAlizzato  tramite  la  rete  del  Carrier   (di  cui  ci  fidiamo?)  oppure  tramite  reA  Wireless  casalinghe  oppure  gratuite   (anche  in  Italia  cominciano  a  diffondersi)   • Dobbiamo  proteggere  l’applicazione:   • Tramite  il  server  (configurandolo  corre5amente  e  tenendolo  aggiornato)   • Tramite  l’applicazione  (validare  e  acce5are  solamente  cerAficaA  trusted)
  • 28. Breaking  News!
  • 29. M4.  Unintended  Data  Leakage Prima  chiamata  Side-­‐Channel  Data  Leakage  è  una  so,o-­‐categoria  della   più  completa  Insecure  Data  Storage,  riguarda  dove  vengono  salvaA  i   daA.  Sono  quelle  problemaAche  che  rendono  accessibili  informazioni   che   invece   dovrebbero   essere   prote5e.   Solitamente   generata   da   un   uAlizzo  non  corre5o  del  Sistema  OperaAvo,  di  Framework,  Compilatori   senza  che  gli  sviluppatori  ne  siano  a  conoscenza.
  • 30. Riflessioni  e  SuggerimenQ • E’  possibile  che  librerie,  framework  o  il  sistema  operaAvo  salvino  in  qualche   locazione  non  prote5a  informazioni  sensibili.  Bisogna  fare  a5enzione  a:   • Caching  delle  richieste/risposte  HTTP  e  dei  Cookie   • Caching  della  tasAera   • Sistemi  che  mantengono  i  Log  o  che  inviano  staAsAche   • Storage  di  HTML5
  • 31. A5.  Poor  AuthorizaQon  and  AuthenQcaQon Sono  quelle  problemaAche  che  riguardano  AutenQcazione  e   Autorizzazione,  elemenA  cruciali  in  parAcolare  per  le  applicazioni   mobile.  Secondo  la  stru5ura  dell’applicazione  quesA  due  controlli   potrebbero  essere  gesAA  dire5amente  sul  disposiAvo  oppure,  se   l’applicazione  si  collega  a  dei  servizi  web,  devono  essere  gesAA   dire5amente  lato  server.  Inoltre  è  importante  la  scelta  dei  vari   criteri  da  uAlizzaA  per  idenAficare  (e  quindi  poi  autenAcare   l’utente).
  • 32. Riflessioni  e  SuggerimenQ • GesAre  sempre  l’autenAcazione  e  l’autorizzazione  lato  server,  e  fornire  i  daA   solo  previa  verifica.   • Se  bisogna  memorizzare  delle  informazioni  sul  disposiAvo  e  prevedere  più   utenA  allora  cifrare  le  informazioni  così  da  non  renderle  accessibili.   • A5enzione  alle  funzionalità  di  “Ricordami”  e  al  salvataggio  dei  Token  di   autenAcazione.   • Non  uAlizzare  informazioni  che  possono  essere  alterate  per  l’autenAcazione   (es.  device  id,  caller  id).
  • 33. M6.  Broken  Cryptography Questa  problemaAca  relaAva  alla  protezione  delle  informazioni   memorizzate,  consiste  nell’uAlizzo  di  algoritmi  cri5ografici  non   sicuri  o  uAlizzaA  in  maniera  errata.  Gli  algoritmi  uAlizzaA  devono   essere  infaQ  consideraA  sicuri  dalla  comunità  ed  essere  uAlizzaA   corre5amente.
  • 34. Riflessioni  e  SuggerimenQ • Quando  si  uAlizzano  elemenA  cri5ografici  dobbiamo:   • Usare  solamente  algoritmi  consideraQ  sicuri  (es.  evitare  MD5,  SHA1)   • UAlizzarli  in  maniera  propria  (es.  Password  con  gli  hash  e  non  con  cifratura   simmetrica)   • GesAre  corre5amente  le  chiavi  cri5ografiche  e  i  cerAficaA.
  • 35. M7.  Client  Side  InjecQon Questa  problemaAca  apparAene  alla  validazione  dei  daQ,  in   quanto  l’applicazione  interagisce  con  l’esterno  a5raverso  dei  daA.   Può  ricevere  daA  dall’utente  come  da  altre  enAtà  come  sensori,   hardware,  database  interni  o  dire5amente  dal  nostro  web  server.   QuesA  daA  possono  essere  manipolaA  più  o  meno  facilmente  e   pertanto  devono  essere  verificaA  per  evitare  comportamenA   anomali  dell’applicazione.
  • 36. Riflessioni  e  SuggerimenQ • Quando  riceviamo  daA  dall’utente  o  da  fonA  esterne  all’applicazione,  anche   quelli  memorizzaA  all’interno  di  un  database  locale  dobbiamo  sempre   considerare  che  possiamo  ricevere  daA  alteraA  e  fare  a5enzione  ai  daA  che   sono  uAlizzaA  da:   • Database,  per  le  SQL  InjecAon   • File  System,  per  le  File  Inclusion   • InterpreA  più  in  generale  (XML,  Xpath,  Xquery…)  e  anche  funzioni   matemaAche.   • UAlizziamo  HTML5?  h5p://onofri.org/u/html5sec
  • 37. M8.  Security  Decisions  via  Untrusted  Inputs L’applicazione  potrebbe  interagire  con  i  processi  esterni,  esempio   tramite  l’Inter-­‐Process  CommunicaAon  (IPC)  di  iOS.  Oppure  su   Android  altre  applicazioni  potrebbero  avere  i  permessi  per   accedere  ad  alcune  componenA.  Tali  interazioni  devono  essere   sempre  verificate.
  • 38. Riflessioni  e  SuggerimenQ • L’applicazione  può  acce5are  daA  ed  essere  uAlizzata  anche  da  altre   applicazioni:  l’accesso  a  tale  componenA  devono  essere  gesAte  corre5amente.   • Ad  esempio  su  iOS:   • NON  uAlizzare  handleOpenURL  ma  openURL,  uAlizzando  una  whitelist  per   le  applicazioni.  NON  uAlizzare  la  Pasteboard  per  le  comunicazioni  IPC.   • Su  Android  configurare  corre5amente  AndroidManifest.xml:  per  le   componenA  private  uAlizzare  android:exported=false,  per  le  altre  uAlizzare   true  ma  specificare  l’android:permission.
  • 39. M9.  Improper  Session  Handling HTTP  è  un  protocollo  state-­‐less  e  per  mantenere  la  sessione  aQva  tra  Client  e   Server  viene  stabilita  una  sessione  a5raverso  l’uAlizzo  di  Cookie  o  di  Token   univoci.  La  sessione  deve  essere  prote5a  sia  lato  server,  come  indicato  in  M1,     sia  lato  Client  con  dovuA  accorgimenA  sia  per  quel  che  riguarda  la  protezione   del  Cookie  e/o  del  Token  che  per  quel  che  riguarda  la  gesAone  delle   informazioni  contenute  all’interno  della  sessione  che  devono  essere  distru5e   quando  la  sessione  termina.  Lo  stesso  Ameout  della  sessione  (assoluto  e   relaAvo)  deve  essere  ben  definito  e  coerente  con  il  contesto.  
  • 40. Riflessioni  e  SuggerimenQ • La  gesAone  della  sessione  è  un  elemento  Apicamente  criQco,  in  parAcolare  se   la  nostra  applicazione  manQene  aqva  la  sessione  verso  il  web  server.  La   sessione  deve  essere  gesAta  corre5amente  lato  server  (come  specificato  per   M1),  ma  anche  lato  client  distruggendo  corre5amente  i  daA  alla  fine  della   sessione.   • Deve  essere  specificato  un  Qmeout  assoluto  (tempo  di  vita  massimo)  e   relaAvo  (dall’ulAmo  uAlizzo)  in  coerenza  con  il  contesto  applicaAvo.   • I  Cookie  o  più  in  generale  i  Token  di  sessione  devono  essere  gesQQ   corre,amente  (es.  cambiaA  ad  ogni  login  e  devono  essere  abbastanza   complessi  e  casuali  da  resistere  ad  a5acchi  di  cri5oanalisi  o  brute-­‐force).
  • 41. M10.  Lack  of  Binary  ProtecQon L’applicazione  stessa  deve  essere  prote5a  come  anche  il  suo   codice  sorgente.  Il  disposiAvo  mobile  deve  essere  considerando  un   “ambiente  osAle”  per  la  nostra  applicazione  e  dobbiamo   proteggerla  da  eventuali  a5acchi  come  il  reverse  engineering,  la   modifica  di  eventuali  componenA  (es.  file  web  presenA  in  locale)  o   dei  binari  stessi.  Le  tecniche  per  la  protezione  sono  diverse  e   cambiano  da  ambiente  ad  ambiente.
  • 42. Riflessioni  e  SuggerimenQ • Dobbiamo  considerare  osAle  l’ambiente  mobile  e  difendere  la  nostra   applicazione,  il  suo  codice  sorgente  e  i  vari  elemenA  residenA  sul  disposiAvo   uAlizzaA  dall’applicazione,  ad  esempio  verificando  l’integrità  delle  componenA   uAlizzate  o  se  viene  inserito  del  codice  al  runAme:   • Su  iOS  verificando  se  il  disposiAvo  è  stato  so5oposto  a  Jailbreak  o  se  è   possible  eseguire  il  dump  dell’eseguibile  (es.  Clutch)   • Su  Android  verificando  se  il  disposiAvo  è  stato  rootato  e  offuscando  il   codice.
  • 43. Conclusioni
  • 44. Mobile App
  • 45. Security  User  GrOup   ! h,ps://groups.google.com/forum/#! forum/sugo
  • 46. GRAZIE! ;-­‐)http://onofri.org/ http://twitter.com/simoneonofri http://it.linkedin.com/simoneonofri http://slideshare.net/simoneonofri
  • 47. DOMANDE ?http://onofri.org/ http://twitter.com/simoneonofri http://it.linkedin.com/simoneonofri http://slideshare.net/simoneonofri