►
Description
In this talk Adam explores his methodology for finding vulnerabilities in software.
Recorded on 2015-07-10
A
Take
it
away
all
right:
okay,
whoo
get
excited
it's
almost
lunchtime,
so,
as
stated,
I
am
Adam
Baldwin.
That's
where
you'd
find
me
on
the
Internet
I'm
from
a
wonderful
place
called
and
yet,
where
I
run
the
lift
security
team
and
started
and
coordinate
the
node
security
project
and
I'm
here
today
to
talk
about
the
art
of
identifying
vulnerabilities
and
so
back
when
I
stepped
out
of
the
security
community
in
2009
and
I
stepped
into
the
world
of
devs
I.
A
Did
my
first
conference
talk
at
Django
Con
in
2009
and
to
you
know,
I
I,
you
know
was
an
outsider
coming
into
the
developer
community
and
I
wanted
to
take.
You
know
the
knowledge
I
had
from
the
security
community
and
go
to
the
source
of
where
you
know
bugs
bugs
were
formed
right
developers
and
I
I
got
the
question.
I
immediately
got
the
question:
how
do
you
do
what
you
do?
A
I
thought
that
I
thought
that
I'd
be
able
to
explain
things
better,
and
it's
taken
me
since
then,
until
now,
until
actually
put
any
others
talk
to
figure
out
what
those
sort
of
what
those,
what
those
things
might
be
and
actually
distill
it
down
into
sort
of
a
you
know
what
could
be
a
repeatable
process
and
that's
that's.
What
I'm
gonna
share
today
is
the
is
my
thoughts
and
perspective
on
this,
and
it's
gonna
probably
jump
around
a
bit
to
me.
A
It
feels
kind
of
like
the
matrix
when
I
look
at
an
application
and
I'm
just
things
just
feel
a
certain
way
and
I
look
into
those
nooks
and
crannies,
so
I'm
gonna
do
my
best
to
put
that
in
you
know
a
linear,
linear
format,
for
you
we're
gonna
start
with
not
changing
slides.
So
what
is
what
is
a
vulnerability?
What
is
vulnerability,
what
are
we
looking
for?
Is
it
a
bug?
Is
it
simply
a
bug
and
I?
Think
that's
true.
Is
it?
Is
it
a
weakness?
That's
my
favorite
security
fail
picture
of
all
time.
A
A
You
can
shim
them
with
a
little
piece
of
aluminum
from
a
soda
can,
but
you
know
we're
looking
for
things
that
can
break
the
promise
of
confidentiality,
integrity
and
availability,
things
that
create
weakness
but,
most
importantly,
we're
looking
for
things
we're
looking
for
bugs
that
we
can
fix.
You
know,
that's
that
that's
the
saving
grace
here
is
it
just
bugs
we
can
fix
them,
there's
nothing
to
really
worry
about.
A
So
here
we
go
to
find
vulnerabilities.
You
need
systems,
knowledge,
you
need
security.
Knowledge
I
need
my
favorite
favorite
part
of
all
curiosity,
so
systems
vulnerabilities
grow
in
the
cracks
between
nuances
and
assumptions
to
find
vulnerabilities.
You
must
understand
the
nuances
of
the
systems
that
you
create
and
consume
in
JavaScript.
You
know
what
the
heck
is.
The
event
loop
anyway.
That's
a
great
you
know
the
that's
a
complex,
complex
thing
that
we
have
to
deal
with.
This
is
a
great
talk
by
a
team
member
of
mine.
A
Phillip
Roberts,
if
you
want
to
you,
know,
know,
know
more
about
the
nuances
of
that
I'm.
Not
gonna.
I'm
gonna
stay
a
bit
I
level
in
some
of
this.
That's
something
that,
if
blocked
right,
we
have,
we
have
a
vulnerability
against
or
we
have
an
attack
against
availability
right.
So
my
other
some
other
great
resource
I
know
you.
Can
you
know
if
you
can't
read
them?
We,
the
slides,
will
be
available
some
other
places
to
find
and
understand
the
pitfalls
of
JavaScript
nuances.
A
Things
like
the
equality
table
right,
it's
it's
it's
it's
super
confusing
and
also
in
the
other
one
you
don't.
No
js'
is
a
great
great
book
series.
You
have
an
interesting
advantage
as
developers
when
it
comes
to
systems
as
compared
to
an
outside
security.
Individual
is
that
you,
you
have
your
closer
to
that
that
code,
you
have
a
deeper
understanding
of
that
code
and
how
those
things
are
put
together.
We,
on
the
other
hand,
from
the
outside,
when
we
have
to
audit
code,
we
have
to
figure
that
out
very
quickly
and
anyway,
I'm
battling
okay.
A
So
hopefully
you
saw
Helens
talk
yesterday
about
prototypical
inheritance.
Another
really
interesting
new
one
nuance
thing
about
JavaScript
right
and
the
surface
area
is
growing
as
we
get
es6,
it's
growing
more
complex,
here's,
my
favorite
nuance
of
JavaScript.
It
seems
so
simple
right.
The
the
double
equals
right.
It's
it's!
It's
just
something
that
we
take
for
granted.
We
use
it
probably
every
day
double
equals
or
triple
equals.
Does
anybody
here
know
actually
how
that
really
works
and
could
tell
me
it's
on
this
slide?
A
You
can't
read
it
basically
I
constrict
to
62
like
there's
this
there's
tons
and
tons
of
like
conditions
that
it
goes
through
as
it
compares
a
string
to
go
from.
You
know
to
compare
equality,
and
we
can
abuse
that
as
attackers
to
guess
strings
that
we
can't
see
because
of
timing
differences.
How
long?
How
far
down
into
this
this
chain
of
events?
Can
we
get?
You
know
bite
by
bite
and
we
can
guess
that,
and
so
you
should
use.
A
You
know
constant
time
comparison
functions
in
like
crypto
chills
or
like
the
bcrypt
utility,
there's
something
that's
my
favorite
new
ones,
it's
so
it's
so
simple.
It's
so
often
ignored
and
again
system
stuff,
gulnur
abilities
are
prevalent
between
one
system
and
another,
so
as
you're
gonna
find
vulnerabilities
where
data
changes
hands
between
one
function
and
another
or
a
client's
to
a
database.
But
it's
not
just
about
the
code
that
we
write
and
the
data
flowing
between
that
code.
It's
also
about
other
systems
that
we
use
and
consume.
A
Who
here
uses
NPM
on
a
very
daily
basis?
Right,
probably
the
majority
of
the
people
in
the
room,
my
I
do
myself:
I
love,
I,
love,
n
p.m.
it's
a
system
that
provides
input
into
the
applications
that
we
write
right.
We
add
dependencies
store
project
from
other
people,
we're
taking
untrusted,
maybe
trusted
client
input
and
putting
it
into
our
projects.
You
know
whose
code
are
you
really
running
in
production?
That's
an
interesting
question.
I!
A
A
This
is
a
just,
a
simple
graph
showing
that
the
red
dots
I
haven't
blurred
out,
because
I
don't
want
to
say
basically
who
it
is
never
adopt,
shows
a
maintainer
and
shows
their
packages
than
it
shows
the
packages
that
depend
on
those
packages
and
so
on
and
so
forth
and
the
more
popular
you
get
the
more
impact
and
who
here
has
changed
their
NPM
password
in
the
last
90
days.
Don't
lie
right.
It
goes
into
a
config
file.
A
A
A
You
know
you
to
basically
man
in
the
middle,
and
you
know
person
impersonate,
you
know
assert
and
that's
three
hundred
lines,
three
hundred
thousand
lines
of
code.
It's
it's
complex.
If
any
of
you,
you
know,
you
know
we
trivialize
and
say
you
know,
just
make
a
request
to
the
server.
There's
an
amazing
amount
of
complexity
that
happens
down
the
entire.
A
You
know
the
the
stack
from
application
down
to
the
network
and
back
again,
and
the
thing
there
is
I
can
be
I
can
be
contrarian
say,
and
the
example
that
I'm
gonna
show
you
at
the
end
goes
against
that
and
will
show
a
module.
That
is,
that
is
really
very
simple.
Yet
has
a
vulnerability
in
it
as
well.
So
don't
let
that
be
deceiving.
Complexity
is
where
they
thrive,
but
something
as
simple
as
you
know,
as
a
fuel
line,
module
can
have
a
little
as
well
and
I.
A
Just
love
this
tweet,
so
sometimes
I
marvel
that
every
computer
is
on
fire
all
the
time.
So
security.
Let's
we've
talked
about
systems.
We
talked
about
the
fact
that
we
need
to
understand
the
nuances
of
the
things
that
we
create
and
consume.
So,
let's
put
on
our
security
hats,
this
is
I'm,
not
a
black
hat
hacker
or
a
white
hat
I'm,
a
pink
hat
hacker
I
know
so
where
to
start
right.
So
if
we're
talking
about
security,
where
do
we
want
to
start
and
what
what
I
thought
would
be
of
interest
is?
A
A
You
know
john
says
I
locate
the
intuitive
trust
in
the
relationships
between
developers,
software
and
users
and
manipulate
them,
the
trust
that
happens
without
conscious
decision
like
a
person
sitting
in
a
chair
assuming
someone
hasn't
removed
one
of
the
legs
since
they
last
sat
in
it.
How
many
of
you
checked
how
many
legs
were
on
your
chair
before
you
sat
in
it?
We
make
these
assumptions
as
we
use
the
systems
we
we
create
and
consume,
and
sometimes
those
legs
can
be
pulled
and
pulled
out
from
under
us
and
John
says.
A
Then
he
determines
how
he
can
redirect
those
trusts
towards
himself
without
making
either
party
without
making
either
party
aware
Matt
on
my
team,
says.
Thinking
like
an
attacker
to
him
means
that
we
try
to
push
the
boundaries
of
useful
things
to
see
how
we
can
get
them
to
do
something
that
it
wasn't
designed
for.
A
A
simple
example
would
be
a
screwdriver,
it's
very
useful
for
its
intended
purpose,
but
it
can
also
have
nefarious
purposes
as
well
to
me
again,
I,
look
at
when
I,
when
I'm,
given
a
piece
of
code
or
an
application
to
audit
I,
think
about
what
promise
again
going
back
to
the
promise.
What
promise
does
it
make?
A
The
reason
why
I
mentioned
this
is
because
this
is
really
useful
for
module
auditing
versus
an
application
where
you
have
an
entire
stack
and
and
if
you
have
a
module,
the
thing
is
is
that
it
can
be
used
in
many
different
ways
and
many
different
purposes.
In
many
ways
you
didn't
intend
you
have
you.
The
vulnerability
exists
in
a
module
when
it
makes
a
promise
and
it
doesn't
doesn't
satisfy
that
promise.
A
A
That's
a
that's
a
good
example
there
and
also
I.
Look
at
it
when
I
ever
look
at
an
application
or
from
from
a
service
perspective.
How
does
it
make
money?
Those
are
the
important
things
to
protect
is
gang
confidentiality,
integrity,
availability
of
you
know
protecting
that
core.
Think
of
how
it
makes
money,
an
ability
often
gets.
Our
availability
often
gets
forgotten
availability.
However,
it
is
a
security
concern
and
it's
the
most
felt
by
your
users.
If
something
is
down,
it's
gonna
be
felt
by
your
users.
A
If
something
is,
you
know,
there's
something
we
sniffed
on
the
wire:
it's
not
as
it's
not
as
impacting
it
may
be
just
as
severe,
but
it's
not
going
to
be
as
felt
so
now.
We've
talked
about
systems
system,
stuff
security,
stuff,
but
you
know
how
do
we?
How
do
we
gain
knowledge
about
sort
of
you
know,
attacking
these
nuances,
an
assumption,
the
standard
one?
If
you
haven't
heard
of
the
aw,
stop
ten,
that's
a
great
place
to
start.
A
A
Also
this
one
I,
really
love.
If
you
want
to
know
how
to
get
better
at
hunting
security,
bugs
read
security,
bug
reports
and
the
thing
is:
is
we
don't
have
a
lot
of
a
lot
of
vulnerabilities
in
the
ecosystem?
We've
got.
You
know
some
out
at
the
node
Security
Project
advisories.
You
don't
have
a
lot
of
detail
there,
but
that's
where
you're
going
to
get
that's
where
you're,
like
learning
from
basically
others
learning
from
other
platforms.
This
thing
doesn't
click
learning
from
other.
A
This
is
a
great
resource
from
other
languages
that
have
basically,
you
want
to
learn
from
their
mistakes
if
we
don't
like
we're
resting
on
the
shoulder
of
giants
and
they've
solved
these
problems
and
we're
just
another
language
in
that
we
should
rise
up
to
be
better
than
just
make
the
same
mistakes
as
as
other
platforms
before
us
have
done.
There's
no
need
to
reinvent
the
wheel,
the
majority
of
the
time
now
finally,
I
get
to
my
favorite.
A
My
favorite
section
of
all
is
curiosity,
because
you
can
have
all
of
the
knowledge
about
systems
and
all
of
the
knowledge
about
how
to
abuse
those
systems.
But
if
you
don't
actually
get
off
of
your
rear
end
and
actually
look
you
don't
find
anything
right
if
we
don't
actually
take
the
time
take
part
of
our
day,
part
of
our
are
our
sprint
to
look
for
these
things
in
our
code
and
our
systems.
A
We're
not
going
to
find
that
find
anything,
and
my
favorite
way
to
to
put
it
in
motion
to
is
is
to
act
ridiculous,
calculated
reckless
abandon.
That's
my
daughter,
she's
wonderful,
but
it's
it's
stimulus-response!
Do
things
your
application
that
you
that
you
normally
wouldn't
don't
basically
shed
all
prior
knowledge
act
like
a
child.
They
don't
they
want
to
get
into
something
they're
gonna
get
into
it.
They're
gonna,
they're,
gonna,
bypass
whatever
child,
lock
you
put
on
there
or
they're
gonna
manipulate
you
socially
to
give
them
whatever
you
want,
and
this
again
you
could.
A
You
could
just
throw
in
pro
to
underscore
underscore
proto
everywhere,
you
know
nice
and
who
wants
the
JavaScript?
How
many
you
know
how
many
have
tried
to
just
throw
it
into
every
input
field
that
they've
found
in
their
JavaScript
application?
Things
break
lots
of
things
break,
and
then
you
know
this
is
my
son
on
a
rocking
horse
on
a
skateboard.
A
Just
because
how
can
it
be
used
in
other
ways?
How
can
you
know
how
is
a
user
going
to
use
your
application
that,
like
what
assumptions
are
you
making
and
not
going
to
be
used?
I'm
also
going
to
excuse
to
use
that
video,
so
the
other
another
tip
is
avoid
or
ask
questions
and
avoid
statements.
What
I
hear
often
is
a
user
would
never
that's
a
big
red
flag.
A
So
it's
really
easy
to
be
blinded
by
the
assumptions
you
made,
while
writing
it,
and
so
again
bouncing
that
off
of
that
peer,
having
a
peer
review
is
good,
but
try
to
shed
that
that
knowledge
and
doing
doing
so
by
just
acting
ridiculous,
throwing
strange
inputs,
you
know
they
call
it
fuzzing.
It
has
a
term
throw
a
random.
A
A
Okay,
and
this
is
the
process
that
I
go
through.
This
is
like
the
TLDR
or,
like
too
long
was
boring.
Didn't
listen,
basically,
I!
Look
at
the
code.
I
understand
the
you
know
the
the
threat
model.
What
is
it
used
for?
What
does
it
do?
What
is
how
is
it
what's
it
intended
to
do
identify
the
inputs?
You
know
the
things
that
are,
you
know,
take
taking
it
data
into
the
application,
identify
the
sinks.
A
The
sinks
are
basically
that
that
that
those
functions
that
are,
if
something
from
a
user
or
if
certain
behaviors
ends
up
in
that
function
like
eval
or
a
regular
expression
or
a
file
system
right
or
you
know
if
a
sink
is
one
of
those.
If
it
ends
up
there.
It's
add
you've
traced,
those
things
you've
test
and
validate,
and
you
repeat,
and
yes,
it
is
actually
really
boring
and
it
doesn't
look
like
anything
like
hacking
in
the
movies.
It's
just
typing.
A
A
Ms,
of
course,
the
network's
not
gonna
work,
we're
gonna,
look
at
a
module,
it
does
millisecond
time
time,
conversion
who
would
expect
a
vulnerability
in
a
module
like
this
right,
but
anyway
like
few
people.
Okay,
because
you
know
they're
gonna
find
out
okay,
so
I
I
didn't
and
we
we
audit
modules
and
like
we
just
have
to
do
it.
I
have
to
go
through
and
look
at
this.
A
This
is
this
is
part
of
my
job,
and
so
it's
like
started
looking
at
this
module
like
okay,
it
does
time
conversion
it
takes
in
some
some
strings
and
some
arbitrary
values,
and
you
know
it
just
dumps
out
milliseconds.
Okay,
so
that's
great.
We
know
what
it
we
know
what
it
does
now,
let's
go!
Look
you
know
if
you,
if
you
go
look
at
like
you,
know
the
actual
module
and
you
just
you
go
through
it.
A
It
has
one
module
exports
that
again
takes
in
a
value
and
some
options
and
then
does
some
some
things
right.
So
if
it's
a
string,
you
know
or
eternity
it
passes
it
to
parse,
so
we're
gonna
go,
follow
it
down
into
parse
and
parse
then
compares
it
against
a
regular
expression.
So
that's
that's
my
first
like
work
like
Erik
like
it.
A
It
goes
into
a
regular
fresh
in
a
rail
expression.
If
you
again
once
you
gain
that
that
security
knowledge
and
that
systems
knowledge,
you
know
that
regular
expressions
are
actually
a
nice
sink,
and
so,
if
we
didn't
know
that
we
might
say
okay,
a
regular
expression,
we're
regulars
Russian,
do
they
have
any
known
attacks.
Well,
you
put
regular
expression
attacks
into
this
wonderful
computer.
You
machine
thing
we
get.
You
know
we
find
that
we
can
gain
knowledge
on
the
fact
that
there
is
a
thing
called
rayless
russian
denali
service.
A
So,
given
the
right
input,
the
right,
regular
expression
and
the
right
input,
we
actually
we
actually
can
end
up
with
a
denial
of
service
condition.
We
can
block
that
wonderful
event,
loop,
that
we
want
to
that.
We
have
want
to
keep
you
know,
spinning
our
callbacks,
so
we
go
back
and
we
said:
could
we
have?
We
have
a
regular
expression.
How
do
we
know
if
it's
vulnerable?
We
could
read
that
paper.
There's
a
really
cool
module
from,
of
course,
sub
stack.
A
There's
you
could
run
it
through
this.
This
module
called
safe,
reg,
X
that'll.
Tell
you
if
that
regular
expression
is,
is
vulnerable
to
regular
first
denial
service.
It's
really
cool
we're
not
going
to
do
that,
but
another
way
is
to
just
kind
of
look
at
what
that
regular
expression
looks
like
in
this
debug
XCOM,
and
this
is
not
gonna-
show
up
well,
but
it's
plug
it
in
there
and
it
shows
you
visually
what
it's
doing
and
it
wants
a
decimal
dot
decimal,
and
then
you
know
something
on
the
end.
A
We
can
still
put
in
those
other
characters
at
the
end,
so
we
can
put,
we
just
keep
putting
decimals
and
the
input
can
be
as
long
as
we
want,
and
then
we
can
put
like
minute
and
then
it
matches
and
we
just
put
some
other
random
character
in
it,
and
it
fails
what
that's
fine.
It's
not
really
blocking
anything.
However,
if
we
take
exit
this.
A
This
is
a
little
test
thing
that
basically
just
generates
a
really
long
string.
You
know
whatever
I
wanted
and
then
adds
like
the
minute.
A
at
the
end
right
so
I'm
gonna,
say
whatever
I
pass
it
in
for
a
length,
generate
a
big,
long
string
and
then
throw
this
on
the
end
of
it
and
pass
it
to
MS,
see
if
it
parses
it.
A
So
if
you
happen
to
be
taking
this
on
to
a
server
that
starts
increasing
as
we
just
that
time
that
it's
blocking
keeps
increasing
and
different
regular
sessions
you
run
into
will
in
fact
have
different
amplification
amounts,
and
so
that's
that's
basically
how
I
followed
it
through
and
there's
little
utilities
that
can
help
you
with
in
those
different
different
those
different
loss,
categories
of
like
cross-site,
scripting
or
cross-site,
request,
forgery
or
denial
service.
Or
what
have
you
there's?
A
There's
tools
that
have
been
created
to
help
test
these
things:
they're,
not
always
developer
friendly,
but
they
do
exist.
If
you
go
looking
looking
for
them,
and
so
it
just
you,
you
know
it
amplifies
quite
a
bit.
You
know
guillermo
block,
basically
blocked
the
attack
of
saying
like
okay.
It
can
be.
You
know
it
can
be
a
thousand
characters
long
or
something,
and
it's
like
it's
it's
nullified.
So
it's
really
easy
to
to
to
mitigate
in
in
a
lot
of
a
lot
of
issues
or
a
lot
of
situations.
A
So
like
this
again,
we
went
through
understood
the
code.
You
know
it
doesn't
use
any
built-ins,
it
doesn't
use
like
we
understood
it.
We
followed
the
data
from
sources
sync
after
we
identified
the
inputs
there,
she's
gonna
hate
me
someday
I
identified
the
sinks
where
it
went,
and
you
know
we've
we.
This
is
something
I
didn't
show,
but
it's
something
that
we
use,
often
to
is
es
graph,
is
a
great
utility
to
do
call
flows
to
see
how
data
flows
between
a
inside
of
an
application
just
an
example.
A
A
Once
you
once
you
go
from
manual
auditing
and
you
understand
how
to
find
these
things
from
a
manual
respective,
you
can
take
it
into
an
automated,
automated,
like
area,
and
so
we've
got
a
set
of
whenever
we
identify
one
of
those
sinks
that
could
be
bad
or
a
pattern.
That
could
be
bad.
We
make
es
lint
rules
for
internally,
and
so
we
run
so
I've
got
this
tool
called
EP
lint,
evil
packet
loop,
that
runs
a
peel
and
index,
and
it
just
runs-
and
it
tells
me
hey-
there's
a
regular
expression.
A
That
was
that,
so
it
found
the
rail
expression
by
parsing
the
ast
it
gave
me
the
regular
expression.
I
ran
it
through
safe
reg
X
and
it
flagged
it.
It's
there's
some
false
positives,
but
it
shows
up
so
I
can
take
this
now
and
run
it
over
every
module
in
the
NPM
ecosystem
and
now
start
flagging
those
and
find
those
vulnerabilities.
It's
really
easy
for
you
to
as
well.
Those
are
up
on
my
github
complex,
evil
packet.
A
There's
some
es
lint
rules
up
there
for
this
particular
one,
and
also
you
can
do
yeah
a
lot
of
time.
So
we,
if
you
want
to
know
other
automated
stuff
that
I've
been
working
on,
come
talk
to
me
afterwards,
like
I'm,
really
excited
about
using
docker
to
find
like
malicious
modules
that
have
like
install
scripts
stuff
like
that
really
interesting
stuff
ways
of
finding
vulnerabilities.
Automated
final
messages
be
okay
with
boring,
monotonous
and
unfruitful
testing.
Just
like
a
cat
trying
to
get
into
any
size
box
be
persistent,
you
will
find
vulnerability.
A
My
last
note
there
is
don't
try
to
do
it
all
at
once,
pick
one
of
those
categories
and
learn
a
little
bit
more
about
it.
Share
it
amongst
your
team
amongst
the
community.
You
know
write
some
write,
some
good
blog
post
about
these
things.
We
need
more
about
it
in
the
know,
community.
That's
it!
Thank
you.