3. 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…
4. 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…
5. 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?
6. 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
…
?
7. 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?
9. 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!
10. 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
18. 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
19. 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
21. 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
22. 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’
/*
‘
23. 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
24. 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
25. • 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
26. • 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
27. • 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
28. • 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
29. • 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
30. • 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
31. 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
33. Security
• Ability
to
wear
Black
Hat
• Think
like
one!
• Go
one
step
beyond…
• It’s
more
fun
• The
Right
ATTITUDE
34. 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…!
35. 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
36. 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
37. Last
Week
-‐
Red-‐X
–
3xpir3
Cyber
Army
Targets:
SQL
Injec*on
Vulnerabili*es
in
CMS
Apps
like
Wordpress,
Joomla,
OsDate
38. 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/
39. 2
Introduc*ons
–
Lot
more
about
You
• Rebels?
• Tinkering?
• Go
beyond
programming
• Alack
alacker’s
alack
• AEtude!
Malers.
But
beware
of
the
Dark
Side
40. 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
41. 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!
42. 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!