TechDay: Hackers vs. Developers - Le SQL Injection - Simone Onofri

Hackers  vs  Developers  Le  SQL  Injec4onSimone  Onofri  -­‐  Techub  S.p.A.

v0.1

Introduzione

h;p://onofri.org/u/hvdsqli

Agenda

• Introduzione  • Breve  Storia  della  SQL  Injec4on  • Come  a;accare  • Come  difendersi  • Q&A  e  Conclusioni

Breve  storia  della  SQL  Injec4on

Web  e  SQL  Injec4on

Tecnicamente  le  prime  SQL  InjecBon  hanno  cominciato  ad  essere  presenB  sul  web  da  

quando  i  vari  interpreB  hanno  permesso  alle  pagine  web  di  mostrare  daB  collegandosi  ai  

database  e  quindi  mostrarne  i  daB.  Pensiamo  a  PHP  (1995)  e  ad  ASP  (1996).

La  prima  famosa  SQL  Injec4on

Risale  al  1998  da  un  arBcolo  firmato  da  Rain  Forest  Puppy  su  Phrack  “NT  Web  Technology  

VulnerabiliBes”  che  conBene  diverse  vulnerabilità  che  dipendono  dalle  tecnologie  

Web.   SELECT * FROM table WHERE x=1 SELECT * FROM table WHERE y=5

La  risposta  alla  prima  famosa  SQL  Injec4on

“Secondo  loro  (il  vendor)  quello  di  cui  sBamo  per  parlare  non  è  un  problema”  

—  Rain  Forest  Puppy  -­‐  Phrack  Issue  #54

La  famosa  raccomandazione

“Non  date  per  scontato  che  l’input  dell’utente  sia  ok  quando  (lo  inserite)  in  query  SQL”  

—  Rain  Forest  Puppy  -­‐  Phrack  Issue  #54

2003/2004  (a;acks)

2007  (vulnerabili4es)

2010  (risks)

2013  (risks)

Unvalidated  Input Cross  Site  Scrip4ng  (XSS) Injec4on Injec4on

Broken  Access  Control Injec4on  Flaws Cross-­‐Site  Scrip4ng  (XSS) Broken  Authen4ca4on  and  Session  Management

Broken  Authen4ca4on  and  Session  Management

Malicious  File  Execu4on Broken  Authen4ca4on  and  Session  Management Cross-­‐Site  Scrip4ng  (XSS)

Cross  Site  Scrip4ng  (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  Misconfigura4on

Injec4on  Flaws Informa4on  Leakage  and  Improper  Error  Handling Security  Misconfigura4on Sensi4ve  Data  Exposure

Improper  Error  Handling Broken  Authen4ca4on  and  Session  Management

Insecure  Cryptographic  Storage

Missing  Func4on  Level  Access  Control

Insecure  Storage Insecure  Cryptographic  Storage

Failure  to  Restrict  URL  Access

Cross-­‐Site  Request  Forgery  (CSRF)

Denial  of  Service Insecure  Communica4ons Insufficient  Transport  Layer  Protec4on

Using  Known  Vulnerable  Components

Insecure  Configura4on  Management

Failure  to  Restrict  URL  Access

Unvalidated  Redirects  and  Forwards

Unvalidated  Redirects  and  Forwards

morale?

E’  stata  compromessa  (almeno  per  la  terza  volta  

negli  ulBmi  anni)  l’azienda  di  Telecomunicazioni  Pakistana,  

controllata  dallo  stato,  tramite  una  SQL  Injec4on  

Cosa  dicono  i  trend  sulla  sicurezza?

“gli  aZaccanB  tendono  a  sfruZare  vulnerabilità  che  sono  presenB  a  causa  di  pra4che  di  

sicurezza  basilari  inadeguate”  —  Rapporto  Melani

Database  e  interrogazioni

Cosa  sono  i  database  relazionali?

I  database  o  basi  di  daB  sono  degli  archivi  organizzaB  tramite  delle  relazioni.  I  daB  sono  contenuB  all’interno  di  alcune  tabelle  che  hanno  delle  intestazioni  (campi)  in  cui  i  daB  sono  organizzaB  in  delle  righe  (o  record).

Cos’è  SQL?

SQL  (Structured  Query  Language)  è  un  linguaggio  struZurato  per  eseguire  

interrogazioni  a  un  database  relazionale.  Possiamo  avere  una  serie  di  query  esempio  per  richiedere  dei  daB  (SELECT),  inserirli  (INSERT),  aggiornarli  (UPDATE)  e  cancellarli  (DELETE).  

Altri  4pi  di  query  servono  per  creare  o  cancellare  database,  utenB,  tabelle  o  sono  comandi  come  es.  per  spegnere  il  database.

Logica  booleana

Le  query  si  basano  sulla  logica  booleana,  ripassiamo  brevemente  l’OR  e  l’AND:

Perchè  devo  sapere  queste  cose?

Per  eseguire  delle  SQL  InjecBon  è  necessaria  una  conoscenza  approfondita  di  SQL,  dei  

database  e  più  nello  specifico  del  linguaggio  supportato  dal  database  uBlizzato  

dall’applicazione  che  sBamo  aZaccando.

Come  a;accare  con  le  SQL  Injec4on

Authen4ca4on  bypass

Authen4ca4on  Bypass  by  SQL  Injec4on

• E’  un  Bpico  aZacco  “vecchio  sBle”.  • Non  è  ovviamente  sempre  possibile,  dipende  da  come  è  scriZa  la  query  che  verifica  l’autenBcazione.  

• L’impaZo  è  estremamente  criBco,  è  infa`  possibile  personificare  gli  utenB.

Come  funziona?

• AnzituZo  è  fondamentale  capire  la  query  che  è  “dietro”  la  richiesta.  

• Tipicamente  la  pagina  di  login  è  qualche  cosa  come:  • SELECT  *  FROM  users  WHERE  use_name  =  ‘simone’  AND  use_password  =  “pwd”;  

• Che  cerca  una  corrispondenza  tra  il  nome  utente  e  la  password  inserita  tramite  GET/POST.  

• Se  inseriamo  quindi  come  username:  • simone’—  

• La  query  sarà:  • SELECT  *  FROM  users  WHERE  use_name  =  ‘simone’—  ‘AND  use_password  =  “pwd”  

• Quindi  viene  verificato  solo  se  l’utente  esiste  o  meno.

Come  funziona?

• Se  però  non  conosciamo  lo  username,  al  neZo  di  quelli  Bpici  come  “admin”,  “administrator”,  o  se  si  uBlizza  un  CMS  basta  andare  a  cercare  la  documentazione,  come  fare?  

• E’  possibile  usare  ‘  OR  1=1—  o  comunque  generare  una  condizione  logica  che  sia  sempre  vera.  

• Cosa  succede  quindi?  il  database  seleziona  tuZo  il  contenuto  della  tabella  users  trovando  sicuramente  almeno  una  corrispondenza.

Avvertenze

• A;enzione:  quando  fate  le  prove  con  OR  1=1,  se  ci  sono  molB  record  nella  tabella  è  possibile  che  il  server  impieghi  molto  tempo  a  rispondere,  oppure  potrebbe  andare  in  Bmeout,  è  consigliabile  uBlizzare  una  strategia  del  Bpo  AND  1=1  e  AND  1=0  quindi  condizioni  logiche  sempre  vere  o  sempre  false  che  però  fanno  tornare  meno  record.  

• Nota:  nell’esempio  precedente  abbiamo  visto  come  -­‐  probabilmente  -­‐  la  password  sia  in  chiaro  (MALE),  quando  si  cerca  il  bypass  infa`  è  più  probabile  trovare  una  SQL  InjecBon  nello  username.  

• Perché  tuZo  questo  probabile?  Ogni  applicazione  è  diversa.

Probing

Quando  si  verificano  le  SQL  Injec4on

Le  vulnerabilità  di  Bpo  InjecBon  si  verificano  quando  da4  non  valida4  vengono  inviaB  come  parte  di  una  richiesta  verso  un  interprete,  permeZendo  di  eseguire  richieste  o  comandi  

normalmente  non  previsB  dall’applicazione.    L’impaZo  di  queste  vulnerabilità  è  spesso  alto  e  permeZe  di  

compromeZere  il  sistema  o  i  daB.

Consigli  sulle  SQL  Injec4on

•Fai  il  reverse  engineering  della  query  •Capisci  il  linguaggio  dell’interprete  •Comprendi  la  logica  •Sii  creaBvo/a

Passo  dopo  passo  (come  ispirazione)

1.Verifica  il  Bpo  di  dato  che  l’applicazione  si  aspeZa  (es.  numero,  stringa,  data,  uuid  ecc..).  2.Cerca  di  capire  e  “rompere”  la  query  uBlizzando  caraZeri  Bpici  dei  delimitatori  (es.  ‘,  ’’,  “),  numeri  posiBvi  e  negaBvi,  aZenzione  ai  LIKE  e  alle  date.  3.IdenBfica  le  differenze  nelle  risposte  (es.  daB  caricaB,  errori,  pagine  bianche).

Esempio

•Applicazione  che  visualizza  le  noBzie:  •hZp://www.example.com/news.php?id=123  

•Solitamente  le  query  in  questo  caso  sono:  •SELECT  *  FROM  news  WHERE  new_id  =  $param  AND  new_published  =  1  

•Un  primo  test  può  essere:  •OR  1=1—,  ma  aZenzione  ai  DoS  •AND  1=1—  e  AND  1=0—  valutando  la  differenza  nelle  risposte  

•Dato  che  è  un  numero  supponiamo  non  siano  necessarie  delle  parentesi,  ma  dobbiamo  considerare  che  se  la  query  è  complessa  possiamo  lasciare  aperte  es.  delle  parentesi.

Fingerprin4ng/Reverse  

Engineering

Fingerprin4ng  e  Reverse  Engineering

Una  volta  idenBficata  la  presenza  potenziale  di  una  SQL  InjecBon  è  necessario  verificarla  e  quindi  sfruZarla.  E’  di  cruciale  importanza  capire  almeno:  •Il  4po  di  dato  che  sBamo  manipolando  •Il  4po  di  query  dove  siamo  dentro  •Dove  siamo  nella  query  •Il  Bpo  di  database

Capire  il  4po  di  dato

•Lo  possiamo  valutare  navigando  nell’applicazione  e  vedendo  quali  sono  i  daB  che  normalmente  l’applicazione  si  aspeZa,  Bpicamente:  

•Numeri  •Stringhe  •Date  •IdenBficaBvi

Capire  il  4po  di  query

Anche  in  questo  caso  il  contesto  applicaBvo  è  importante.  SBamo:  •Visualizzando  dei  daB?  >  SELECT  •Modificando/Aggiornando  dei  daB?  >  UPDATE  •Cancellando  dei  daB?  >  DELETE  A"enzione  a  query  mul0ple  eseguite  dalla  stessa  pagina

Capire  dove  siamo  nella  query

Consideriamo  sempre  che  possiamo  essere  in  più  punB  della  query,  quindi  la  nostra  manipolazione  può  avere  effe`  

differenB.  

SELECT  *  FROM  tabella  WHERE  campo  =  valore  ORDER  BY  campo

Capire  il  4po  di  database

Passo  non  poco  difficile  è  capire  il  Bpo  di  database  (es.  Microsow,  Oracle,  Postgre,  DB2…)  e  la  sua  versione  specifica,  in  quanto  alcune  funzionalità  sono  previste  solo  per  determinate  versioni.  Un  piccolo  cheatsheet:  • Concatenare  le  stringhe:  

• Oracle:    ‘||’FOO  • MsSQL:  ‘+’FOO  • MySQL:  ‘  ‘FOO  

• Calcoli  sui  numeri:  • Oracle:  BITAND(1,1)-­‐BITAND(1,1)  • MS-­‐SQL:  @@PACK_RECEIVED-­‐@@PACK_RECEIVED  • MySQL:  CONNECTION_ID()-­‐CONNECTION_ID()  

• Commen4  di  MySQL:  • Se  MySQL  trova  questo  commento    /*!32302  and  1=0*/  lo  eseguirà  solo  se  la  sua  versione  è  maggiore  o  uguale  alla  3.23.02

Exploi4ng

Come  sfru;are  le  vulnerabilità

Una  volta  oZenute  le  informazioni  sulla  query  e  sul  database  possiamo  procedere  con  lo  sfruZamento.  E’  possibile  uBlizzare  differenB  tecniche  secondo  il  contesto:  In  alcuni  casi  l’errore  SQL  è  visibile,  il  che  semplifica  molto  il  lavoro.  In  altri  casi  dobbiamo  capire  l’esito  delle  nostre  richieste  capendo  quando  l’applicazione:  •Esegue  il  nostro  codice,  inserendo  delle  condizioni  di  vero  o  falso  (seleziona  solo  alcuni  daB)  •La  query  non  è  correZa  (es.  WSOD)

Errori  4pici

•ORA-­‐01756:  quoted  string  not  properly  terminated  •You  have  an  error  in  your  SQL  syntax;  check  the  manual  that  corresponds  to  your  MariaDB  server  version  for  the  right  syntax  to  use  near  ‘'  •Error:  You  have  an  error  in  your  SQL  syntax;  check  the  manual  that  corresponds  to  your  MySQL  server  version  for  the  right  syntax  to  use  near  '''  at  line  •Unclosed  quotaBon  mark  awer  the  character  string  ''.

La  tecnica  UNION

•La  UNION  è  una  delle  tecniche  più  comuni  per  l’estrazione  di  daB.  •L’operatore  UNION  è  uBlizzato  per  combinare  i  risultaB  di  più  query:  la  prima  è  quella  inclusa  dall’applicazione,  la  seconda  è  quella  da  cui  vogliamo  estrarre  i  daB.  •Quando  facciamo  una  UNION  dobbiamo  considerare  che:  

•Le  due  query  devono  avere  lo  stesso  numero  di  colonne  (es.  ORA-­‐01789:  query  block  has  incorrect  number  of  result  columns)  •Le  colonne  nella  stessa  posizione  devono  essere  dello  stesso  Bpo  o  uno  compaBbile.  (es.  ORA-­‐01790:  expression  must  have  same  datatype  as  corresponding  expression).  NULL  è  spesso  nostro  amico  •Dobbiamo  conoscere  almeno  il  nome  di  una  tabella  (ecco  anche  perchè  facciamo  il  fingerprinBng).

Come  fare?

•Trova  il  nome  di  una  tabella  che  esiste  e  cui  hai  accesso  (es.  DUAL  in  Oracle  o  anche  nulla  in  MS-­‐SQL)  •Capisci  il  numero  di  colonne:  

•‘  UNION  SELECT  NULL—  •‘  UNION  SELECT  NULL,  NULL—  •‘  UNION  SELECT  NULL,  NULL,  NULL—  

•Trova  almeno  un  Bpo  di  dato  come  stringa  •‘  UNION  SELECT  ‘a’,  NULL,  NULL—  

•Estrai  le  informazioni  •UNION  SELECT  banner,  NULL,  NULL  from  v$version

Tool  automa4ci

Strumen4  automa4ci

•Esistono  numerosi  strumenB  automaBci  tramite  i  quali  è  possibile  idenBficare  e  sfruZare  le  SQL  InjecBon.  •E’  bene  comunque  imparare  a  sfruZarle  a  mano!  •Non  sempre  gli  strumenB  automaBci  sono  di  aiuto:  

•In  quel  caso  è  possibile  modificare  lo  strumento  se  è  open  source.  •Oppure  farsi  una  propria  serie  di  script  nel  proprio  linguaggio  preferito  per  sfruZare  la  vulnerabilità.  

Sqlmap

•Sqlmap  è  uno  dei  più  potenB  strumenB  per  le  SQL  InjecBon,  consideriamo  il  nostro  target  testasp.  •Scaricare:  hZp://sqlmap.org/  •Lanciare:  

•python  sqlmap.py  -­‐u  “hBp://testasp.vulnweb.com/showthread.asp?id=1"  •python  sqlmap.py  -­‐u  "hBp://testasp.vulnweb.com/showthread.asp?id=1"  -­‐-­‐users  •python  sqlmap.py  -­‐u  "hBp://testasp.vulnweb.com/showthread.asp?id=1"  -­‐-­‐passwords    •python  sqlmap.py  -­‐u  "hBp://testasp.vulnweb.com/showthread.asp?id=1"  -­‐-­‐dbs

Difendersi  dalle  SQL  Injec4on

A;acco

Vulnerabilità

<?php

// parameters

$author = $_GET['author'];

$sql_inline = "SELECT * FROM blogs_table WHERE blogger_name = '$author'";

$res = $dbh->query($sql_inline);

?>

Contromisura

<?php

// parameters

$author = $_GET['author'];

$sql_prep = "SELECT * FROM blogs_table WHERE blogger_name = ?";

$res = $dbh->prepare($sql_prep);

$res->bindParam(1, $author, PDO::PARAM_STR, 16);

$res->execute();

?>

Suggerimen4

E’  possibile  miBgare  questa  vulnerabilità  uBlizzando  API  parametriche  per  interfacciarsi  agli  interpreB  oppure  regole  di  validazione  a  whitelist  per  verificare  il  dato.  Inoltre,  prima  della  validazione,  bisogna  eseguire  una  normalizzazione  (canonicalizaBon)  e  codificare  correZamente  il  dato  (encoding),  quindi  applicare  le  regole  specifiche  dell’interprete  per  gesBre  i  cara;eri  speciali  (escaping),  come  ad  esempio:  

•CaraZeri  per  la  delimitazione  delle  stringhe  (es.  ‘  “  )  

•CaraZeri  o  sequenze  intepretate  (es.  %  -­‐-­‐  #  /*)  •Operatori  o  funzioni  (es.  AND  OR  NOT  SLEEP  ||  CHR  +)

FAQ

Frequently  Asked  Ques4ons

• I  database  NoSQL  sono  vulnerabili? Si  

• Esistono  altri  Bpi  di  InjecBon? Si  es.  LDAP,  ORM,  XML  InjecRon,  XXE,  SSI,  XPath,  XQuery,  SPARQL,  IMAP/SMTP,  Code,  Command  

• Se  uso  il  framework  X  sono  invulnerabile? No,  dipende  da  come  si  usa  

• Come  posso  prevenire? Query  parametriche*,  validazione  whitelist/blacklist*  

• Un  Web  ApplicaBon  Firewall  mi  protegge? Ni*  

• Su  una  Web  App  HTML5  posso  avere  SQL  InjecBon? Si,  se  si  usano  i  Web  Database  

• Come  si  fa  la  SQL  InjecBon  sul  database  X?  (dove  X  è  il  tuo  database)Leggi  il  manuale  e  trova  le  funzioni  del  database  (e  versione)  specifica

Q&A  e  Conclusioni

Mobile App

GRAZIE!

;-­‐)http://onofri.org/ http://twitter.com/simoneonofri http://it.linkedin.com/simoneonofri http://slideshare.net/simoneonofri

DOMANDE

?http://onofri.org/ http://twitter.com/simoneonofri http://it.linkedin.com/simoneonofri http://slideshare.net/simoneonofri