Sql Injection - Vulnerability and Security

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





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=‘[email protected] 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-‐[email protected] –  .:: 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!

Technology

Sql Injection - Vulnerability and Security