►
Description
If you’re a developer, this video is for you! We’re going to focus on the software decisions that led towards what has been characterized as the vulnerability of the decade. Watch to learn how to code with security in mind!
Presented by: Joseph Katsioloudes (@jkcso)
Connect with us:
Twitter: @GHSecurityLab
Web: securitylab.github.com
About GitHub Security Lab:
“Securing the world's software, together” - GitHub Security Lab’s mission is to inspire and enable the community to secure the open source software we all depend on.
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
A
A
Hey
and
welcome
to
security
bytes
a
series
of
short
videos
from
the
github
security
lab,
aiming
towards
educating
developers
about
common
vulnerabilities
in
software.
Today,
we
are
going
to
focus
on
the
log4j
vulnerability.
Lock4J,
which
means
logging
for
java
is
a
very
popular
logging
library,
it's
so
popular
that
it
exists
in
millions
of
systems
in
the
world,
either
directly
or
indirectly.
A
This
software
library
is
very
useful
for
when
things
go
wrong,
which
happens
all
the
time
in
the
world
of
software
log
for
shell,
which
is
the
name
given
to
the
lock4g
vulnerability,
due
to
the
fact
that
anyone
called
up
in
a
shell
made
the
headlines
everywhere.
This
is
due
to
the
huge
number
of
systems
exposed
to
remote
code
execution
which,
as
we've
learned
in
previous
episodes,
allows
attackers
to
literally
run
anything
they
want
on
a
victim's
machine,
including
malware
installation
and
data.
Stealing,
let's
now
understand
the
vulnerability
step
by
step.
A
Log4J
allows
expression,
logging
in
the
first
line
we
get
the
logger
client
and
in
the
second
line
we
log
the
error
message.
This
is
done
at
run
time
through
the
error,
object,
plugging
its
content
into
the
curly
braces
that
represent
the
steering
placeholder.
As
of
now,
what
we've
seen
is
consider
standard
logging.
A
Let's
now
look
at
the
software
decisions
that
led
towards
remote
code
execution.
This
is
caused
by
lookups.
Lookups
is
a
feature
that
makes
it
really
easy
to
inject
some
common
values
into
the
locked
messages.
For
example,
you
may
want
to
log
the
value
of
a
given
environment
variable
when
an
exception
occurs
in
that
case,
instead
of
retrieving
the
variable
programmatically
and
concatenating
this
variable
into
the
log
message
you
can
just
append
it.
There
are
many
types
of
lookups
one
of
them.
A
A
good
use
case
for
this
feature
will
be
a
centralized
login
configuration
from
a
config
server
that
needs
to
be
loaded
to
a
jvm
using
a
jndi
lookup
for
the
purpose
of
prefixing
logs.
In
a
specific
way,
this
is
a
productivity
feature
simply
put
if
a
user
controls
part
of
the
data
that
gets
locked
he
or
she
gets
to
choose,
not
only
what
is
locked,
but
also
the
ability
to
use
any
of
the
enabled
lookups
by
using
the
special
dollar
curly
braces
syntax.
A
Giving
such
an
opportunity
to
the
untrusted
user
has
proved
a
bad
software
decision,
even
if
there
was
a
legitimate
productivity
reason
behind
it.
But
do
the
benefits
of
this
use
case
outweigh
every
worst
case
scenario.
Let's
see
this
in
practice.
In
the
first
line
we
have
an
ldap
url
that
we
can
use
to
acquire
java
objects
from
any
ldap
server.
Now,
in
line
4,
we
acquire
prefix
for
the
logging
message
from
the
configuration
server
by
passing
a
jndi
url
as
an
argument.
A
This
will
normally
be
used
in
the
pattern
layout,
but
for
the
sake
of
the
demo,
we
will
be
using
it
here.
The
jndi
url
passed
above
is
not
malicious,
but
if
a
user
controls
the
message
returned
by
error.get
message,
there
is
nothing
stopping
him
or
here
from
adding
another
lookup.
In
that
case,
a
malicious
lookup
could
be
performed
and
malware
could
be
installed
in
a
victim's
machine.
A
Take
the
following
example
of
a
search
feature
where
an
untrusted
user
passes
the
following
malicious
query:
another
attack
is
one
that
will
send
secrets
retrieved
from
environment
variables
outside
to
a
malicious
resource.
Using
this
search
query,
obviously,
updating
to
a
non-vulnerable
version
is
their
way
forward,
but
let's
focus
on
the
big
picture
here
to
avoid
similar
flaws
in
the
future.
A
This
feature
was
added
in
2014
two
years
before
the
jndi
system
was
publicly
known
to
be
a
vector
leading
to
remote
code
execution,
which
means
that
the
log4j
maintainers
were
not
aware
about
the
risks
at
the
time.
However,
security
is
about
looking
at
the
right
place
with
the
right
security
mindset,
even
in
2014,
where
there
are
any
good
reasons.
Allowing
outbound
connections
to
any
arbitrary
server
in
the
internet.
Secured
in
depth
is
about
adding
as
many
layers
as
possible
to
the
security
cake
and
assume
that
some
of
them
will
fail.
A
This
vulnerability
highlights
that
developers
often
use
libraries
blindly
without
considering
all
the
features
they
are
signing
up
to.
Of
course,
in
practice,
it's
very
hard
to
review
all
possible
configurations
of
all
dependencies,
but
the
realistic
way
to
reduce
the
attack
surface
would
be
for
the
lock
4g
maintainers
to
make
those
powerful
lookups
opt-in
by
that
the
principle
of
least
privilege
will
be
applied
through
an
approach
that
is
denial
by
default.
Make
sure
to
leave
a
comment
below
to
let
us
know
about
your
thoughts
on
lock
4j
in
the
meantime.