►
Description
4 years ago I fell in love with node.js at 0.4 ever since then I’ve been focused on finding ways to 0wn and secure node applications. A lot of that effort was focused around the npm registry where the majority of the code developers produce is shared and consumed.
This talk will be a trip back in time to discuss the mad science research and experiments I’ve done to try and understand the state of node.js security and to try and make the node community and ecosystem a bit more secure.
Hopefully it will leave you with a healthy sense of paranoia and a curiosity for how you can make the code you create and consume more secure.
Recorded on 2015-11-14
A
Is
the
experiments
that
I've
run
over
the
years
to
try
to
understand
the
security
posture
of
the
community
of
the
ecosystem
of
the
software
that
we
build
software
that
you
build
and
how
to
make
that
better
and
we're
gonna
take
a
trip
back
in
time
to
when
the
node
security
project
first
started.
This
is
the
original
logo.
This
is
why
security
people
do
not
build
Legos
this
one's
better.
This
one
is
worse.
Okay,
it's
done
design
talk
so
once
upon
a
time
so
to
set
the
stage
node
0.4
was
just
released.
A
I
came
from
you
know
a
Python
background
before
then
it's
figuring
things
out
I
became
apparent
to
me
that
one
of
the
biggest
security
challenges
we
would
face
in
building
our
application
would
be
that
the
various
things
that
were
outside
of
her
control.
We
could
control
the
code
quality
of
what
we
were
building
of
what
the
teammates
building.
We
can
do
that
you
know
through
linting
and
through
peer
review
and
all
those
other
fun
things,
but
the
things
that
you
all
produce
and
share
on
NPM.
A
Is
you
still
have
to
get
that
that
code
from
NPM
onto
the
victims
machine
and
that's
where
that
seems
to
get
glossed
over?
Oh
I
can
post
this
malicious
thing
yeah,
but
people
are
just
gonna,
npm
and
stai
totally,
not
you
know,
install
totally,
not
a
virus.
Trust
me
that
I'm
a
dolphin
I'll
wait.
If
you
want
to
try
that
it's
it's,
you
still
have
to
get
that
code
to
them.
So
let's
take
a
little
step
back
and
understand
what
this
is.
A
What
I
was
doing
back
then
I
was
understanding
who
the
who
the
actors
were,
who
the
who
are
the
players
there
and
for
for
me
it
was.
You
have
the
devs
right.
You
have
your
team,
you
have
other
deaths
and
you
get
the
jerks
the
people
that
wanted
to
publish,
intensely
malicious
things
on
that
network
and
then
you've
got
the
distribution
point.
You've
got
NPM
and
so
there's
different
ways
that
we
can
go
about.
A
A
The
no
sequel
database,
land
and
I
realized
that
MPM
was
built
on
couch,
well
old
versions
of
couch
exposed
all
the
SHA
houses,
which
seems
silly
today,
but
expose
all
of
the
SHA
hashes
at
that
time
to
to
the
end
users,
it
was
just
available
and
to
me
that
was
you
know
that
was
just
a
feature
of
couch.
But
to
me
that
was
a
that
was
it
was
a
breach.
That's
what
I
consider
from
security
background
a
breach.
A
All
these
so
I
had
everyone
Shaw,
as
I,
ran
them
through
a
GPU
and
I
cracked
about
25
percent
of
them
in
an
overnight,
and
that
was
to
me.
I
could
now
compromise
those
modules.
This
is
one
of
those
hashes.
It
isn't
actually
exercise
left
up
to
you
to
crack
it
and
tell
me
who
that
is
you'll.
Be
surprised
that
not
everyone
treats
that
password
as
something
important.
Yet
it's
yet
it's
guarding
something
very
important.
A
So
what's
another,
the
other
actors
in
this
are
the
developers
you
that
you
are
publishing
modules
on
the
register
or
you
are
consuming
modules
on
the
registry.
I
want
to
get
that
to
you,
so
humans
make
mistakes
right,
humans,
type
things
poorly.
We
make
typos
when
we
install
things
so
another
another
sort
of
experiment
that
I
did
and
I'm
gonna
be
all
over
the
place.
I've
always
wanted
to
give
a
talk
where
I
can
just
talk
about
all
of
the
different
sort
of
research
things
that
I've
done
so
I
get
this
opportunity
to
do
that.
A
So
what
I
did
instead
was
I
took
the
top
hundred
modules
I
generated
typos
for
them,
and
what
I
found
was
that
punctuation
causes
error.
If
those
are
the
ones
that
rose
to
the
top
being
most
attempted
to
be
installed,
but
didn't
actually
exist
in
the
registry,
and
so
is
it
Sokka
da
da
da,
oh
or
socket
IO,
which
one
are
you
actually
supposed
to
stall,
and
you
type
that
right
every
single
time
is
it
CoffeeScript
or
coffee
script?
A
It's
actually
coffee
script,
I
published
CoffeeScript
just
to
see
what,
if
anyone
would
notice-
and
it
didn't
do
anything-
it
was
a
readme.
That
said,
if
you
find
this,
let
me
know
and
I'll
take
it
down
it
took
about
a
week
and
about
200
downloads
or
installs,
for
somebody
actually
finally
recognized
that
this
wasn't
supposed
to
be.
There
contact
me
in
the
registry
and
it
was
taken
down,
so
it's
I
mean
that's
a
pretty
good
community
response,
but
would
that
have
been
noticed?
A
Had
I
mimicked,
the
behavior
of
CoffeeScript
and
I,
just
put
in
whatever
I
wanted
to
there
I'm
doubtful
that
it
would
have
so
what's
next?
What's
stopping
me
from
publishing
modules,
as
you
write,
if
we
don't
find
a
flaw
in
the
registry,
this
is
a
big
one
and
passwords
passwords
are
currently.
What
stops
me
from
publishing,
as
you
and
being
you
on
NPM
and
what's
interesting,
is
how
who's
changed
their
MP
and
password
within
the
last
say
30
days
Rebecca.
Maybe
we
don't
it's
put
in
a
canoe.
It's
we
get
an
off
token.
A
It's
put
in
a
configuration
file.
We
don't
have
to
as
a
convenience,
write
it
it's
it's
gone,
it's
it's
out
of
our
hair,
and
so
we
don't.
We
don't
change
that
and
maybe
there's
users
that
have
set
up
accounts
that
don't
have
good
passwords
right
and
so
what
I
did
was
I
looked
for
some
accounts
with
poor
passwords
and
I'm,
not
gonna.
Tell
you
what
they
were,
but
we're
gonna
talk
about.
A
A
So
we
know
that's
all
I
further
I
consume.
Sorry.
Well,
we'll
move
around.
So
what
it
did
was
once
I
got
all
those
accounts
and
I
wanted
to
see
what
impact
did
those
accounts
have
because
they
weren't
just
all
test
accounts,
there's
a
lot
of
test
accounts.
These
are
these
little
one
offs,
where
that's
the
little
red
dots,
the
maintainer
and
little
green
dots,
the
packages
at
the
control-
and
you
start
visualizing
and
start
looking.
You
start
seeing
these
clusters.
This
person
has
a
lot
of
packages.
They
might
be
test
packages.
A
Other
ones
over
here,
a
few
other
test
packages
interdependent
there.
You
got
this
one
down
here
that
dependency
tree,
so
one
user
in
NPM,
with
a
poor
package
or
purpose
or
password.
They
that's
that
you
use
their
module
you're,
accepting
their
security
standards
right.
So
this
person
has
packages
that
extend
well
up
into
other
projects,
and
so
it's
important
to
rotate
those
credentials.
It's
important
to
take
that
on,
if
your
module
author
to
be
rotating,
that
in
taking
your
account
security
seriously
for
everyone
else,
that
is,
that
is
using
the
order.
A
Your
modules,
let's
see
if
this
works,
okay,
so
I
made
a
claim
when
I
started
the
node
security
project
that
we're
gonna
audit
all
of
the
things
this
is.
This
is
the
big
claim
that
I
made
when
I
started
the
node
Security
Project,
because
I
said:
okay,
we've
got
this
playground.
We
got
this
the
self-contained
thing
where
all
the
codes
being
published
and
shared
I
can
just
I
can
just
you
know,
skip
through
it
and
find
bugs
and
help
people
fix
it.
Well,
there's
12,000
things
in
the
registry
at
that
point
in
time.
A
Now
there
are
this
many
and
I
look
like
that,
and
the
reason
I
look
like
that
is
because
Security's
like
this.
This
is
this
is
security,
and
this
is
what
happens
when
you're
publishing
I
think
you
all
are
publishing
like
2500
modules
a
week
or
something
like
that.
We
can't
keep
up
it's
it's.
It
is
impossible
for
us
to
to
keep
up
security.
A
It's
a
journey.
It's
a
it's,
not
a
destination.
It's
like
the
Penrose
stairs.
You
will
be
this
little
person
forever
and
ever
and
ever
and
that's
what
we
are.
That's
the
node
security
project.
I
can't
meet
that
claim
of
auditing
all
the
things
for
all
the
things.
I
will
never
ever
meet
that
claim.
I'm,
sorry
that
I
ever
said
it
and
I
take
it
back
and
we
will
just
move
on.
This
is
my
moving
on
from
that.
A
However,
we
can
audit
for
things
and
we
can
keep
up
and
we
can
tell
you
about
them,
and
so
we
were.
We
were
going
to
be
doing
that
better
right
now,
you
all's,
you
see
the
negatives.
You
see
that
the
node
Security
Project
published
advisories
of
things
we
find
so.
But
how
are
we
doing
that?
How
are
we
looking
for
certain
things?
So
how
do
I
look
for
things
and
find
vulnerabilities
in
the
NPM
playground
that
it
is
that's
through
static
analysis,
right,
we're
not
doing
dynamic
analysis,
we're
not
running
all
of
this
code.
A
A
So,
first
of
all
we
put
on
our
thinking
hat
and
we
identify
a
pattern.
So
where
do
we
find
these
patterns?
We
we
steal.
These
patterns
I'm
a
pink
cat
hacker.
By
the
way
we
steal
these
patterns
from
other
languages.
We
say:
okay,
what
are
some
bugs
in
in
the
in
Python
we're
some
bugs
in
in
Ruby
land
we're
some
patterns
and
we
steal
those,
and
then
we
just
look
for
them
right
and
then
we
search
for
that
pattern
and
searching
for
that
pattern
is
hard.
That's
my
daughter
searching
and
you
you.
A
The
thing
is:
is
that
it's
hard
to
search
with
something
like
grep,
you
don't
have
context
you,
you
get
a
hit
and
it's
a
hot
spot,
but
it's
not
really
it's
not
really
good
enough,
and
then
you
have
the
challenge
of
no.
What's
interesting
is,
is
you
all
in
your
code
can
apply
these
things
really
really
really
simple
and
really
fast
to
your
code
bases
when
we're
talking
to
taking
you
to
the
in
scale,
it's
really
really
hard.
So
the
chance
some
of
the
challenge
you
have
to
deal
with
the
storage
requirements.
A
It's
like
500
gigabyte
on
disk
there's,
1.2
million,
plus
tar
balls
in
NPM
right,
like
that's,
that's
a
challenge
in
and
of
itself,
you
have
to
deal
with
people
checking
in
like
you
need
node
modules
in
there
and
test
directories
modules
like
your
mom,
which
is
a
it's
a
like
a
200k
tarball
that
blows
up
into
a
keg
file.
It's
going
to
blow
up
your
processes,
you
just
end
up
blacklisting
those.
You
know
argument
too
long.
Your
give
that
this
is
where
we
started.
We
started
with
really
janky
systems.
A
What
we
have
now
is
we've
got
a
clone
of
NPM
in
s3
and
whenever,
whenever
it's
all
tar
ball
hits
s3,
it
triggers
lambda
jobs
and
that
we
can
actually
do
that
automatic
analysis,
and
it
just
brings
it
up
to
it
to
a
human
level.
It
tells
us
here's
a
hot
spot.
Here's
where
a
human
should
go,
look
and
validate
it's
just
a
little
bit
better
than
grub.
So
once
you've
found
your
hot
spot
right,
you
need
to
validate,
and
you
need
to
make
sure
that
the
thing
that
you're
testing
can
you
actually
abuse
it.
A
This
is
my
son
on
a
rocking
horse
riding
down
this
thing
on
a
skateboard
he's
using
it
as
it's
not
intended.
We
need
to
validate
those
things
and
auditing
modules
is
really
unique,
because
what
do
we
claim
as
a
vulnerability?
You
can
use
a
module
as
it
wasn't
intended
right,
but
so
the
metric
that
I
use-
and
this
is
when
I'm
auditing
a
module
I
say
can't-
is
the
module
making
a
promise
that
I
can
break.
A
A
Otherwise,
it's
just
misuse
and
maybe
can
create
a
security
situation,
maybe
not,
and
then
the
most
important
thing
that
I
can
tell
you
about
searching
for
vulnerabilities
is
I
guess
the
best
way
to
tell
you
is:
have
you
ever
seen
a
cat
try
to
get
into
a
box?
How
about
a
box
like
this
big?
It
still
tries
to
get
into
that
box.
It
will
repeatedly
bang
its
face
against
the
entrance
of
that
box
until
it
gets
in
or
maybe
gets.
A
You
know,
sidetracked
and
walks
away,
but
curiosity
and
actually
trying
to
find
bugs
in
your
code
that
a
relative
security
is
the
way
you're
gonna.
Do
that
you
I,
don't
care
what
knowledge
you
have
what
background
whatever.
As
long
as
you
go
and
you
try
and
you
learn
about
them
and
you
go
look.
You
actually
do
that
that
act
of
looking
and
having
that
curiosity,
you
will
find
those
bugs
in
your
code.
So
here's
some
here's
some
fun
stuff
that
may
help
you.
A
Here's
some
PS
lint
rules
that
we're
gonna
release
today
that
deal
with
security
patterns.
So
we
kind
of
improved
our
game
from
grep.
We
said:
hey,
grep
kinda
stinks,
let's
get
a
little
more
context,
let's
use
the
ast
and
let's,
let's
use
the
tools
that
we
have,
and
so
there's
a
few
of
them
that
that
try
to
find
unsafe,
regular
expressions
and
then
different
sort
of
patterns
that
we've
found
very
common
in
encode
they're.
A
Not
that
great,
don't
add
them
to
your
project
and
expect
your
linting
to
pass,
because
they're
gonna
find
a
bunch
of
false
positives,
but
it
tells
you
as
a
human
where
you
might
look,
and
you
might
find
something
if
you
want
to
put
NPM
on
disk
and
actually
have
it.
I've
made
a
little
project.
I've
got
a
little
hard
drive
that
I
keep
an
PM
on
me
at
all
times.
Just
for
spelunking,
it's
fun.
You
can
use
it's
based
on
registry
static
by
Dave
glass,
just
for
local
testing.
A
The
other
thing
is
is
once
we
have
all
those
modules
and
we
have
all
that
data.
We
can
just
run
other
tools
again
that
right,
so
one
of
the
things
I
did
there's
a
tool
called
retired
j/s.
It's
very
similar
to
have
NSP
accept
it.
It's
got
a
catalog
of
more
like
front-end
framework
vulnerabilities.
This
version
of
jQuery
is
known
vulnerable
to
this
type
of
thing.
A
It's
you
should
be
using
in
your
code,
so
we
ran
it
against
NPM
back
when
there's
about
a
hundred
eighty
four
thousand
modules,
and
we
found
that
about
1.6
percent
of
things
had
known
flaws,
and
so
we're
gonna
start
to
expose
that
through
the
node
security
project,
but
that's
something
there.
You
should
be
looking
your
project,
not
real,
that
exciting.
It's
a
needle,
it's
needle
in
a
haystack
right.
The
majority
of
the
projects
don't
have
those
libraries
and
a
good
portion
of
these
things
also
are
probably
in
test
directories.
Example
directories.
A
This
was
of
Bower,
so
Bowers,
more
focused
on
front-end
frameworks
and
I.
Believe
Bower
is
since
kind
of
slowing
down
in
development,
probably
see
some
of
that
shift
over
to
NPM.
You
see
a
larger
percentage
because
they
they're
just
focused
on
that
type
of
that's
the
that's
the
audience
right
and
then
we
did
some
initials
and
some
interesting
things
would
just
Bower
and
static
analysis.
There's
a
tool
called
burp
proxy
that
has
a
built
in
static
analysis
engine.
A
It
can
do
taint,
checking
to
see
if
certain
sources,
user
input
from
say
a
query
parameter,
ends
up
in
a
sink
such
as
like
window,
dot,
location
or
you
know
into
the
Dom
and
things
like
that,
and
this
is
what
we
found
for
Bower.
We
found
a
just
a
pile
of
interesting
vulnerabilities
potentials.
I
published
that
data
there
we
didn't.
Actually
we
haven't
actually
looked
through
it
and
validated
any
of
it.
A
But
if
you,
if
you're
doing
projects
that
you've
have
exposed
on
Bower,
you
can
go
spelunking
through
that
data
and
maybe
you'll
find
something
of
interest
to
you.
If
you
do
find
something,
that's
a
validated
concern,
valen
or
confirmed
vulnerability.
Please
let
us
know
and
we'll
publish
an
advisory
in
your
name.
This
is
this
is
a
fun
one.
I
thought
who
else
is
out
there
in
the
ecosystem
doing
stuff
in
NPM?
Who
else
might
be
doing
this
stuff
that
I'm
doing
and
I
wanted
to
find
out?
A
If
there's
any
robots
pulling
stuff
down
testing
it
installing
packages,
maybe
a
CI,
maybe
something-
and
this
sort
failed,
horribly
they're,
not
really
anything
out
there
doing
anything
like
this
I
created
a
module
called
bot
bait
and
it
it
calls
home.
That's
all
it
does
it.
When
you
test
calls
home
when
you
start
it
calls
home
when
you
install
it
calls
home
when
you
run
index
you
require
it,
it
calls
home
it's
all
it
does.
It
sends
your
node
version
to
me.
One
person
installed
it.
A
That's
it
or
one
process,
one
bot,
this
lonely
soul
in
Portugal,
I,
don't
know
who
you
are,
but
thank
you
for
installing
it
and
it
was
downloaded
165
times
which
is
interesting.
So
people
are
cloning.
This
data
they're
just
not
necessarily
running
npm
test
or
npm
install'.
So
that's
kind
of
interesting.
So
that's
kind
of
the
history.
A
Those
are
the
things
that
we've
done
to
find
stuff
in
NPM.
That's
it
that's
pretty
much
all
the
different
experiments
I
mean
there's
there's
very
like
those
greps
take.
You
know
two
to
three
hours
to
complete,
so
you
know,
there's
a
lot
of
run.
A
pattern.
Come
back
run
a
pattern.
Go
over.
You
know
12,000
lines
of
output.
Things
like
that.
So
now
we're
trying
to
do
that.
We're
trying
to
do
that
faster,
we're
trying
to
do
that
more
accurate.
A
We
had
an
intern
this
summer,
build
a
static
analysis
engine
for
us
to
do
really
really
good
team
checking.
So
we
can
load
AST
and
we
can
do
control
flow
graphs
and
we
can
do
data
flow
into
neo4j
and
we
can
query
it
like.
Facebook
does
Facebook
friends
right
and
we
can.
We
can
just
find
vulnerabilities
that
way
and
that's
pretty
interesting.
I'm
gonna
talk
about
two
things
that
we're
doing
now
that
I
found
kind
of
interesting.
So
what
about
finding
malicious
modules?
A
What
about
modules
that
are
say
like
the
CoffeeScript
module,
but
they
actually
have
malicious
behavior
on
install
just
like
the
rim,
Rafal
module?
How
might
we
be
able
to
find
those
in
the
registry?
So
I
started
a
project
and
it's
available
here
at
November,
evil
packet,
dotnet
and
it
is
a
it-
is
a
search.
A
A
Yeah,
my
internet
doesn't
work
so
failed
live
demo.
It
lists
out
any
files
that
were
added,
changed
or
deleted
for
that
docker
container
Dockers
got
this
really
really
nice
feature
called
docker
diff
you're
on
a
container
you're
on
a
diff.
You
see
what
files
changed.
It's
really
interesting
and
I
plan
on
I
mean
you
can
see
kind
of
right
here.
A
This
is
just
what
it
shows,
but
if
you
see
four,
that's
for
RIM
Rafal,
it
just
deleted
a
bunch
files.
It
touched
Etsy,
it
touched
var.
Why
would
a
module
do
that?
I
can
see
that
it's
about
56
gigs
of
data
right
now
and
it's
open.
You
can
go
search
in
and
we'll
expose
it
at
some
point
to
the
node
security
project
and
then
the
last
one
I
want
to
talk
about.
Hopefully
this
live
demo
doesn't
fail.
A
Miserably
is
we're
doing
fuzzing
of
binary
modules,
so
fuzzing,
basically
taking
there's
a
tool
called
AFL,
fuzz,
American,
fuzzy
lop.
It's
really
useful
for
fuzzing
sea
based
applications.
Things
like
that
and
it's
it's
a
it
employs
like
a
genetic
kind
of
algorithm,
so
it
finds
it.
It
finds
ways
to
get
new
code
paths
and
instruments
the
code
and
it
sees
when
it
goes
farther
and
it
tries
to
snake
that
input
farther
and
then
try
different
types
of
input
to
crash
the
application.
This
was
message
pack
0.2,
dot,
6.
A
It's
since
been
fixed
used
to
crash
me.
He
just
gave
it
I'm
gonna
we're
gonna,
try
run
on
node
SAS
and
see
if
we
can
find
any
bugs.
I'm
gonna
give
it
about
30
seconds,
and
if
it
fails
horribly,
then
we
will
just
kind
of
move
on.
But
what
we've
done
is
we
built
a
little
sort
of
like
harness
a
docker
container
and
a
harness,
and
that
builds
node
and
my
coworker
John
lamendola
has
sort
of
like
pushed
this
really
hard
trying
to
get
instrumentation
of
these
binary
modules.
A
There's
not
very
many,
but
some
of
them
are
pretty
important.
You
know
bcrypt
and
Abby's
on
and
there's
a
lot
of
important
ones
out
there
that
we
want
to.
We
want
to
fuzz,
and
so
let's
just
build
its
docker.
You
know:
okay,
come
on
we'll
build
a
docker
image.
Quick,
that's
gonna
fail
miserably
because
you
can't
find
the
hashes.
A
A
A
A
A
A
So
what
what
it's
doing
now
is
basically
it's
it's.
It's
might
be
kind
of
hard
to
see.
The
basically
what's
doing
is
running
about
just
twelve
exact
per
second,
it's
calling
a
very
small
script.
It's
taking
user
input,
compiling
of
a
note
SAS,
and
that's
it.
That's
that's
all
a
little
app
little.
It's
all
a
little
program
does
and.
A
It
needs
input
actually
to
crash.
So
let's
try
that
again
it
it
stick.
It's
it's
generating
input,
it's
mutating
it
it's
doing,
arithmetic
bit,
flips
things
like
that
and
it's
sending
it
to
the
app
and
then
seeing
if
it
crashed
and
it
shouldn't
take
too
long.
This
path
number
right
here,
it's
finding
new,
interesting
ways:
I
covered
it
up
there
we
got
a
crash,
so
we've
got
we've
got
a
way.
If
you
have
an
application
that
takes
user
input
in
note
SAS,
we
can
crash
it.
That's
it!
A
That's
that's
what
we
can
do,
and
so
we
can
take
that
now.
We
can
look
at
that
test
case
when
you
provide
that
to
note
SAS
and
say:
here's
how
you
could
you
know,
here's
how
you
can
make
things
better
and
we
hopefully
are
gonna,
be
able
to
do
that
for
any
any
node
binary
add-ons
out
there.
It's
really
just
setting
up
that
that
build
environment.
A
So
with
that
said,
that's
that
demo
didn't
fail
too
horribly
and
that's
basically
it
I've.
You
know:
we've
gone
through
and
we've
we've
done
a
lot
with
with
different
different
experiments.
We've
just
taken
our
knowledge
in
security.
We've
taken
our
knowledge
in
the
end
of
the
node
ecosystem.
We
try
to
apply
them
together
and
make
things
better
for
you.
What
I
want
you
to
get
out
of
this
is
that
you
can
do
that
too.
In
your
codebase.
It
takes
curiosity.
It
takes
looking
to
other
sources
like
other
languages.
A
It
takes,
you
know,
doing
a
little
bit
of
research
and
you
and
a
little
bit
of
spelunking
and
you
might
find
something.
Node
NPM
is
a
great
player,
pretty
good
playground
for
that,
as
well
as
your
own
code
base.
If
you
see
something
say
something
I
mean
if
you
find
something
report,
a
security
issue
to
us
and
that's
what
I
got
thank
you.