SQL  Injec*on  

Vulnerability  and  Security    -­‐  Sandip  Chaudhari  

[    ]  

Welcome  

•  Our  first  meet  •  It’s  got  be  special!  •  Who  likes  geEng  injected?  •  Guests?  Welcome  •  Join,  voice-­‐in  •  AEtude!  

Dualism  

•  We  got  2  hours  today  •  We  got  to  have  2  introduc*ons  –  Me  &  You  •  We  got  to  look  into  Vulnerability  and  Security  •  Binary  -­‐  It’s  all  about  0  and  1  •  Today’s  date  is  25!  •  We  are  doomed!  We  didn’t  do  this  event  at        2  PM!    

•  Just  kidding…  

2  Introduc*ons  –  Too  much  about  me  

•  13+  years  experience  in  SoZware  and  Informa*on  Security  Industry  •  6+  years  worked  as  a  Professional  SoZware  Security  Analyst  and  Secure  Code  

Auditor  •  100+  in-­‐house  vulnerabili*es  discovered  and  reported  •  Presented  Security  Research  Paper  at  various  security  conferences  around  the  

globe  including  New  York,  USA,  Luxembourg,  Luxembourg,  Tokyo,  Japan,  Bangalore,  India  

•  Undertook  mul*ple  responsibili*es  in  various  roles  like  –  Security  Analyst,  Applica*on  Developer,  Project  Manager,  SoZware  Applica*on  Architect,  Informa*on  Security  Researcher,  CTO  

•  Proud  to  have  worked  along  with,  and  be  part  of  group  that  included  –  Dino  Dai  Zovi,  Shane  Macaulay,  Adam  Green,  Jonathan  Leonard  and  Jeremy  Jethro  

•  Huh!  Who  cares…  

Castle  with  many  doors!  

•  Which  door  was  leZ  open?  

•  But  text  input  is  a  valid  entry  at  mul*ple  doors!  

•  It’s  all  about  entry  though…  

•  So  what  causes  SQL  injec*on?  

 

Entry,  entry,  entry!  

•  SQL  is  used  to  save  /  read  /  delete  /  update  data  into  the  database  

•  SQL  is  THE  language  that  is  most  commonly  used  by  applica*ons,  to  talk  to  the  database  

•  But  SQL  exists  only  in  the  developer’s  /  implementer’s  world    

•  End-­‐user  should  never  have  to  bother  about  SQL  to  store/access  her/his  name  or  to  login  

•  Hmm,  maybe  true.  But  what  if  …  ?  

But  what  if  …  ?  

•  End  user  directly  provides  SQL  at  the  client  (view)  end?  

•  That  SQL  code  might  travel  all  the  way  via  client-­‐end,  network,  webserver,  applica*on  layers,  to  the  database  

•  What  happens  when  it  reaches  the  database?  •  Does  database  know  or  really  care,  who  or  which  end  point  provided  SQL?  

What  is  really  going  on?  

SQL  Injec*on  •  Wikipedia  –  SQL  injec*on  is  a  code  injec*on  technique  that  exploits  a  security  vulnerability  in  an  applica*on’s  soZware  

•  Database  is  doing  it’s  job.  It’s  developer’s  responsibility!  Aaaaaargh….!!!  

•  Hacker  injects  her/his  secret,  malicious  code,  via  a  valid  input  field.  That  input  travels  as  a  valid  entry,  through  a  provided  open  door,  all  the  way  to  the  database  –  Brilliant    

•  It’s  aZer  reaching  the  database,  poison  of  the  malicious  code  starts  ac*ng!  

SQL  Injec*on  2012  Stats  

•  Wikipedia  –  In  opera*onal  environments,  applica*ons  experience  an  average  of  71  SQL  injec*on  alempts  an  hour  

•  Barclays:  97%  of  data  breaches  s*ll  due  to  SQL  Injec*on  

•  Firehost  (July  2012):  SQL  Injec*on  alacks  up  by  69%.  From  277,770  in  Q1  2012  to  469,983  in  Q2  2012  

SQL  Injec*on  Feb  2013  Stats  hlp://hackmageddon.com/2013/02/22/1-­‐15-­‐february-­‐2013-­‐cyber-­‐alacks-­‐sta*s*cs/  

DDOS  Egypt  Govt  -­‐  OpEgypt  

OpKashmir  

Hack*vism  -­‐  OpBankUnderAlack  

SQL  Injec*on  Feb  2013  Stats  hlp://hackmageddon.com/2013/02/22/1-­‐15-­‐february-­‐2013-­‐cyber-­‐alacks-­‐sta*s*cs/  

SQL  Injec*on  Feb  2013  Stats  hlp://hackmageddon.com/2013/02/22/1-­‐15-­‐february-­‐2013-­‐cyber-­‐alacks-­‐sta*s*cs/  

SQL  Injec*on  Feb  2013  Stats  hlp://hackmageddon.com/2013/02/22/1-­‐15-­‐february-­‐2013-­‐cyber-­‐alacks-­‐sta*s*cs/  

SQL  Injec*on  Feb  2013  Stats  hlp://hackmageddon.com/2013/02/22/1-­‐15-­‐february-­‐2013-­‐cyber-­‐alacks-­‐sta*s*cs/  

WHAT?  That  data  was  never  supposed  to  be  shared!  

It’s  all  about  parsing,  interpre*ng,  processing  

SQL  Parser  –  Simplis*c  View  

•  Imagine  that  SQL  Parser  simply  extracts  and  separates  -­‐  DB  opera*on  instruc*ons  and  data  elements  

•  Example  –  username=‘alice’  has  alice  as  data  element,  separated  by  quote  (‘)  

•  Thus  parser  uses  some  delimiters’  help  to  separate  data  from  instruc*ons  

Again,  SQL  Injec*on  •  SQL  Injec*on  =  <instruc*ons  [+  data]>  reaching  database,  injected  at  a  point  where  applica*on  only  expects  data  

•  Always,  there  is  an  input  (entry)  to  start  it  all!  •  Then  there  is  some  processing  on  that  input  •  Processing  almost  always  entails  certain  expecta*ons  of  what  the  input  maybe  

•  When  an  input  expecta2on  overlaps  trust,  a  vulnerability  is  born  

•  Hackers  manipulate  trust  &  exploit  vulnerability  

SQL  Injec*on  Alack  Vector  Classifica*on  

 Source:  Wikipedia  

Why  bother  about  SQL  Injec*on?  •  Credit  card  informa*on  •  Usernames,  Passwords  •  Sensi*ve  Informa*on  –  

medical  records  •  Spoof  iden*ty  •  Tampering  with  data  •  Repudia*on  issues  •  Reveal  DB  structure  •  Operate  as  Admin  •  Delete  en*re  DB  •  Execute  system  commands  •  Elevate  privileges  and  

compromise  the  whole  system  

SQL  Injec*on  -­‐  Basics  

•  $sql  =  “SELECT  *  FROM  Users  where  firstName  =  ‘”  .  $firstName  .”’”;  

•  User  provides:  ‘  or  ‘1’=‘1  •  SQL  String:  “SELECT  *  FROM  Users  where  firstName  =  ‘’  or  ‘1’=‘1’”  

•  Few  Others  (source:  Wikipedia)  ‘  or  ‘1’=‘1’  –  ‘  ‘  or  ‘1’=‘1’  ({  ‘  ‘  or  ‘1’=‘1’  /*  ‘  

SQL  Injec*on  Type  –  Tautology  Ref:  hlps://sites.google.com/site/injec*onsmakemesql2/sqlia-­‐types/tautology  

•  Alack  Intent:  – By  pass  authen*ca*on,  Iden*fy  injectable  parameters,  extract  data  

•  General  inten*on  is  to  submit  a  query  that  will  always  return  true  ‘  or  1=1    :    is  a  tautology  

•  All  rows  are  targeted  •  To  be  successful,  hacker  must  be  aware  of  

the  query  structure  

SQL  Injec*on  Type  –  Illegal  /  Illogical  Queries  Ref:  hlps://sites.google.com/site/injec*onsmakemesql2/sqlia-­‐types/tautology  

•  Alack  Intent  –  Iden*fy  injectable  parameters,  Iden*fy  DB,  extract  data  

•  Gather  informa*on  about  backend  of  web  applica*on  

•  Error  messages  are  overly  descrip*ve.  DB  informa*on  is  thus  revealed  

•  Example  –  5a  is  provided  in  field  where  data  is  expected  

•  Alack  Intent:  – Bypass  authen*ca*on,  data  extrac*on  

•  Inclusion  of  a  union  statement  and  extrac*on  of  data  

•  Example  –  10  UNION  SELECT  password  FROM  users  WHERE  1=1  or  2=2  provided  where  id  is  expected  

•  Requires  knowledge  of  DB  schema  

SQL  Injec*on  Type  –  Union  Query    Ref:  hlps://sites.google.com/site/injec*onsmakemesql2/sqlia-­‐types/tautology  

•  Alack  Intent:  – Data  extrac*on,  data  modifica*on,  remote  command  execu*on,  DoS  

•  First  query  is  valid  and  runs  normally  but  when  delimiter  is  recognized,  DB  executes  second  and  further  queries  

•  Example  –  bingo’;  UPDATE  users  SET  email=‘hacker@hush.com  provided  where  name  is  expected  

SQL  Injec*on  Type  –  Piggy-­‐backed  Queries    Ref:  hlps://sites.google.com/site/injec*onsmakemesql2/sqlia-­‐types/tautology  

•  Alack  Intent  – Privilege  escala*on,  DoS,  Remote  Command  Execu*on  

•  DBs  may  come  with  in-­‐built  stored-­‐procedures,  that  alacker  can  use  

•  Procedures  maybe  in  other  languages  opening  newer  alack  avenues  

•  Example  –  1;  EXEC  master..xp_cmdshell  ‘dir  *.exe’  where  an  id  is  expected  

SQL  Injec*on  Type  –  Stored  Procedure    Ref:  hlps://sites.google.com/site/injec*onsmakemesql2/sqlia-­‐types/tautology  

•  Alack  Intent:  –  Iden*fy  vulnerable  parameters,  iden*fy  schema,  data  extrac*on  

•  Alack  against  beler  secured  databases,  hiding  descrip*ve  errors  

•  TRUE  /  FALSE  type  based  on  web  page  /  returned  data  behavior  

•  Example  –  1  AND  1=1  and  1  AND  1=2  

SQL  Injec*on  Type  –  Blind  Injec*on    Ref:  hlps://sites.google.com/site/injec*onsmakemesql2/sqlia-­‐types/tautology  

•  Alack  Intent:  –  Iden*fy  vulnerable  parameters,  iden*fy  schema,  data  extrac*on  

•  Gather  informa*on  based  on  *me  delays  in  the  response  

•  Example  –  Bingo’  wai_or  delay  ‘00:00:10’  –  delays  response  by  10  secs  if  vulnerable  

–  If  first  lecer  of  db  name  is  an  ‘a’  wait  10  secs  or  if  it  is  ‘b’  wait  20  secs…    

SQL  Injec*on  Type  –  Time  Based  Injec*on    Ref:  hlps://sites.google.com/site/injec*onsmakemesql2/sqlia-­‐types/tautology  

•  Alack  Intent:  – Evade  detec*on  

•  Injec*on  commands  are  encoded  in  various  formats  

•  Example  -­‐  %3c%74%69%74%6c%3e%2e%2f%20%72  is  URL  encoded,  decodes  to  <2tle>./  r  is  part  of  Red-­‐X  alack  signature  

•  Double  encoding  simply  involves  re-­‐encoding  the  %  symbol  to  %25  

SQL  Injec*on  Type  –  Alternate  Encodings    Ref:  hlps://sites.google.com/site/injec*onsmakemesql2/sqlia-­‐types/tautology  

SQL  Injec*on  Type  –  Second  Order  Injec*on    

•  Alack  Intent:  –  Data  manipula*on,  Remote  Command  Execu*on  

•  Frequency  based  Primary  Applica*on  –  Applica*on  that  re-­‐present  processed  data  of  Primary  Applica*on  

•  Frequency  based  Secondary  Applica*on  –  Secondary  applica*on  processes  submission  of  Primary  applica*on  

•  Secondary  Support  Applica*on  –  Secondary  applica*on  that  is  usually  internal  support  group  for  the  Primary  applica*on  

•  Cascaded  Submission  –  Submiled  data  is  stored  and  re-­‐used  further  in  queries  

Security  

May  the  Force  be  with  you!  

Security  

•  Ability  to  wear  Black  Hat  •  Think  like  one!  •  Go  one  step  beyond…  •  It’s  more  fun  •  The  Right  ATTITUDE  

Security  –  Prepared  Statements  

•  No  processing  of  input  •  Input  is  just  data  •  SQL  instruc*on  template  is  pre-­‐compiled  •  All  input  is  simply  treated  as  data  •  No  processing,  no  interpreta*on,  no  overlap  of  expecta*on  on  trust  

•  Hence,  no  vulnerability!  •  Best  Op*on  •  Moms,  name  your  kids  whatever…!  

Security  –  Stored  Procedures  

•  As  good  as  Prepared  Statements    if  implemented  safely  

•  Stored  Procedures  allow  dynamic  SQL  statements  

•  If  dynamic  SQL  statements  are  used  inside  stored  procedures,  security  is  lost  

•  Not  the  best  op*on  

Security  –  Escape  User  Input  

•  Some*mes  it  just  has  to  be  plain  SQL!  •  Escape  all  user  input  before  execu*on  of  the  dynamic  SQL  

•  Think  mul*ple  *mes  before  you  go  for  this  op*on  

•  If  you  do,  re-­‐review  mul*ple  *mes  to  ensure  no  vulnerability  

•  Should  be  the  Last  Op*on  

Last  Week  -­‐  Red-­‐X  –  3xpir3  Cyber  Army  

Targets:    SQL  Injec*on  

Vulnerabili*es  in  CMS  Apps  like  

Wordpress,  Joomla,  OsDate  

Red-­‐X  •  Some  signatures:  

–  red  X  –  3xp1r3  –  Cyber  Army  –  Bangladeshi  Hacker  –  The  Real  Outrageous  –  media.somewhereinblog.net/images/ondhokarer_rajputra_1353552651_1-­‐red-­‐x.jpg  –  Dear  ADMIN<br/>!  Secure  your  SITE  !  –  ..::|  Greetz  |::..  –  red-­‐x@hackermail.com  –  .::  x3o-­‐1337  |  Gabby  |  $p!r!t~$33k3r  |  FrEaKy  ::.  –  All  Members  of  3xp1r3  Cyber  Army  –  PL3E6316C123CFC160  –  %3c%74%69%74%6c%65%3e%2e%2f%20%72  –  hacked  by  Cimy  

•  Simple  scanner  script:  hlp://ec2-­‐54-­‐251-­‐11-­‐172.ap-­‐southeast-­‐1.compute.amazonaws.com/scans/  

2  Introduc*ons  –  Lot  more  about  You  

•  Rebels?  

•  Tinkering?  

•  Go  beyond  programming  

•  Alack  alacker’s  alack  

•  AEtude!  Malers.  But  beware  of  the  Dark  Side  

Courtesies  &  Disclaimer  

•  Many  of  the  images  used  in  this  presenta*on  are  NOT  the  genius  crea*ons  of  my  own  

•  I  Google’d  ‘em  and  all  the  credits  go  to  the  original  ar*sts  

•  If  there  are  any  images  of  my  own  that  I  have  added  in  this  presenta*on,  you  are  more  than  welcome  to  freely  use  them  

Ques*ons  ???  

•  What  you  want  to  ask,  many  already  have  that  same  ques*on  on  their  mind.  Be  bold  and  lead  

•  OK,  If  you  don’t  want  to  speak  and  keep  shut  and  keep  thinking  about  it  in  your  mind  and  take  those  ques*ons  home,  make  sure  you  email’em  to  me  and  sleep  well  at  night!  

I  have  some  for  y’all  •  Do  you  like  to  watch  –  Matrix,  Star  Wars,  Star  Trek,  Hitchhiker's  Guide  to  the  Galaxy,  ...  Sci-­‐Fi?  

•  Would  you  like  to  play  Capture  The  Flag  using  SQL  Injec*on?  

•  What  should  be  our  topic  for  the  next  meet?  •  I  hate  to  ask  but,  how  can  we  make  this  beler?  •  Again,  so  do  you  s*ll  like  geEng  injected?  •  I  know,  we  the  elite,  genius  group,  who  like  to  rot  before  idiot  box  are  ‘especially’  afraid  of  injec*ons!  

•  Are  you  convinced  by  now?  Of  course,  you  already  hate  injec*ons!