MOVEit zero-day exploit used by data breach gangs: The how, the why, and what to do…
Last
week,
Progress
Software
Corporation,
which
sells
software
and
services
for
user
interface
development,
devops,
file
management
and
more,
alerted
customers
of
its
MOVEit
Transfer
and
related
MOVEit
Cloud
products
about
a
critical
vulnerability
dubbed
CVE-2023-34362.
As
the
name
suggests,
MOVEit
Transfer
is
a
system
that
makes
it
easy
to
store
and
share
files
throughout
a
team,
a
department,
a
company,
or
even
a
supply
chain.
In
its
own
words,
“MOVEit
provides
secure
collaboration
and
automated
file
transfers
of
sensitive
data
and
advanced
workflow
automation
capabilities
without
the
need
for
scripting.”
Unfortunately,
MOVEit’s
web-based
front
end,
which
makes
it
easy
to
share
and
manage
files
using
just
a
web
browser
(a
process
generally
considered
less
prone
to
misdirected
or
“lost”
files
than
sharing
them
via
email),
turned
out
to
have
a
SQL
injection
vulnerability.
SQL
injections
explained
Web-based
SQL
injection
bugs
arise
when
an
HTTP
request
that’s
submitted
to
a
web
server
is
converted
insecurely
into
a
query
command
that’s
then
issued
by
the
server
itself
to
do
a
database
lookup
in
order
to
work
out
what
HTTP
reply
to
construct.
For
example,
a
database
search
that’s
triggered
from
a
web
page
might
end
up
as
a
URL
requested
by
your
browser
that
looks
like
this:
https://search.example.com/?type=file&name=duck
The
query
text
duck
could
then
be
extracted
from
the
name
parameter
in
the
URL,
converted
into
database
query
syntax,
and
and
stitched
into
a
command
to
submit
to
the
database
server.
If
the
backend
data
is
stored
in
a
SQL
database,
the
web
server
might
convert
that
URL
into
a
SQL
command
like
the
one
shown
below.
The
%
characters
added
to
the
text
duck
mean
that
the
search
term
can
appear
anywhere
in
the
retrieved
filename,
and
the
single
quote
characters
at
each
end
are
are
added
as
markers
to
denote
a
SQL
text
string:
SELECT filename FROM filesdb WHERE name LIKE '%duck%'
The
data
that
comes
back
from
the
query
could
then
be
formatted
nicely,
converted
to
HTML,
and
sent
back
as
an
HTTP
reply
to
your
browser,
perhaps
giving
you
a
clickable
list
of
matching
files
for
you
to
download.
Of
course,
the
web
server
needs
to
be
really
careful
with
the
filenames
that
are
submitted
as
a
search
term,
in
case
a
malicious
user
were
to
create
and
request
a
URL
like
this:
https://search.example.com/?type=file&name=duck';DROP table filesdb;--
If
that
search
term
were
blindly
converted
into
a
query
string,
you
might
be
able
to
trick
the
web
server
into
sending
the
SQL
server
a
command
like
this:
SELECT filename FROM filesdb WHERE name LIKE '%duck';DROP TABLE filesdb;--%'
Because
a
semicolon
(;)
acts
as
a
statement
separator
in
SQL,
this
single-line
command
is
actually
the
same
as
sending
three
consecutive
commands:
SELECT filename FROM filesdb WHERE name LIKE '%duck' -- matches names ending duck DROP TABLE filesdb -- deletes whole database --%' -- comment, does nothing
Sneakily,
because
everying
after
--
is
discarded
by
SQL
as
a
programmer’s
comment,
these
three
lines
are
the
same
as:
SELECT filename FROM filesdb WHERE name LIKE '%duck' DROP TABLE filesdb
You’ll
get
back
a
list
of
all
filenames
in
the
database
that
end
with
the
string
duck
(the
special
SQL
character
%
at
the
start
of
a
search
term
means
“match
anything
up
to
this
point”)…
…but
you’ll
be
the
last
person
to
get
anything
useful
out
of
the
filesdb
database,
because
your
rogue
search
term
will
follow
up
the
search
with
the
SQL
command
to
delete
the
whole
database.
Little
Bobby
Tables
If
you’ve
ever
heard
syadmins
or
coders
making
jokes
about
Little
Bobby
Tables,
that’s
because
this
sort
of
SQL
injection
was
immortalised
in
an
XKCD
cartoon
back
in
2007:
As
the
cartoon
concludes
in
the
last
frame,
you
really
need
to
sanitise
your
database
inputs,
meaning
that
you
need
to
take
great
care
not
to
allow
the
person
submitting
the
search
term
to
control
how
the
search
command
gets
interpreted
by
the
backend
servers
involved.
You
can
see
why
this
sort
of
trick
is
known
as
an
injection
attack:
in
the
examples
above,
the
malicious
search
terms
cause
an
additional
SQL
command
to
be
injected
into
the
handling
of
the
request.
In
fact,
both
these
examples
involve
two
injected
fommands,
following
the
sneakily-inserted
“close
quote”
character
to
finsh
off
the
search
string
early.
The
first
extra
command
is
the
destructive
DROP
TABLE
instruction.
The
second
is
a
“comment
command”
that
causes
the
rest
of
the
line
to
be
ignored,
thus
cunningly
eating
up
the
trailing
%'
characters
generated
by
the
server’s
command
generator,
which
would
otherwise
have
caused
a
syntax
error
and
prevented
the
injected
DROP
TABLE
command
from
working.
Good
news
and
bad
news
The
good
news
in
this
case
is
that
Progress
patched
all
its
supported
MOVEit
versions,
along
with
its
cloud-based
service,
once
it
became
aware
of
the
vulnerability.
So,
if
you
use
the
cloud
version,
you’re
now
automatically
up-to-date,
and
if
you
are
running
MOVEit
on
your
own
network,
we
hope
you’ve
patched
by
now.
The
bad
news
is
that
this
vulnerability
was
a
zero-day,
meaning
that
Progress
found
out
about
it
because
the
Bad
Guys
had
already
been
exploiting
it,
rather
than
before
they
figured
out
how
to
do
so.
In
other
words,
by
the
time
you
patched
your
own
servers
(or
Progress
patched
its
cloud
service),
crooks
might
already
have
injected
rogue
commands
into
your
MOVEit
SQL
backend
databases,
with
a
range
of
possible
outcomes:
-
Deletion
of
existing
data.
As
shown
above,
the
classic
example
of
a
SQL
injection
attack
is
large-scale
data
destruction. -
Exfiltration
of
existing
data.
Instead
of
dropping
SQL
tables,
attackers
could
inject
queries
of
their
own,
thus
learning
not
only
the
structure
of
your
internal
databases,
but
also
extracting
and
stealing
their
juiciest
parts. -
Modification
of
existing
data.
More
subtle
attackers
might
decide
to
corrupt
or
disrupt
your
data
instead
of
(or
as
well
as)
stealing
it. -
Implantation
of
new
files,
including
malware.
Attackers
could
inject
SQL
commands
that
in
turn
launch
external
system
commands,
thus
achieving
arbitrary
remote
code
execution
inside
your
network.
One
group
of
attackers,
alleged
by
Microsoft
to
be
(or
to
be
connected
with)
the
infamous
Clop
ransomware
gang,
have
apparently
been
using
this
vulnerability
to
implant
what
are
known
as
webshells
on
affected
servers.
If
you’re
not
familiar
with
webshells,
read
our
plain-English
explainer
that
we
published
at
the
time
of
the
troublesome
HAFNIUM
attacks
back
in
March
2021:
Webshell
danger
Simply
put,
webshells
provide
a
way
for
attackers
who
can
add
new
files
to
your
web
server
to
come
back
later,
break
in
at
their
leisure,
and
parlay
that
write-only
access
into
complete
remote
control.
Webshells
work
because
many
web
servers
treat
certain
files
(usually
determined
by
the
directory
they’re
in,
or
by
the
extension
that
they
have)
as
executable
scripts
used
to
generate
the
page
to
send
back,
rather
than
as
the
actual
content
to
use
in
the
reply.
For
example,
Microsoft’s
IIS
(internet
information
server)
is
usually
configured
so
that
if
a
web
browser
requests
a
file
called,
say,
hello.html
then
the
raw,
unomdified
content
of
that
file
will
be
read
in
and
sent
back
to
the
browser.
So,
if
there
is
any
malware
in
that
hello.html
file,
then
it
will
affect
the
person
browsing
to
the
server,
not
the
server
itself.
But
if
the
file
is
called,
say,
hello.aspx
(where
ASP
is
short
for
the
self-descriptive
phrase
Active
Server
Pages),
then
that
file
is
treated
as
a
script
program
for
the
server
to
execute.
Running
that
file
as
a
program,
instead
of
simply
reading
it
in
as
data,
will
generate
the
output
to
be
sent
in
reply.
In
other
words,
if
there
is
any
malware
in
that
hello.aspx
file,
then
it
will
directly
affect
the
server
itself,
not
the
person
browsing
to
it.
In
short,
dropping
a
webshell
file
as
the
side-effect
of
a
command
injection
attack
means
that
the
attackers
can
come
back
later,
and
by
visiting
the
URL
corresponding
to
that
webshell’s
filename…
…they
can
run
their
malware
right
inside
your
network,
using
nothing
more
suspicious
than
an
unassuming
HTTP
request
made
by
an
everyday
a
web
browser.
Indeed,
some
webshells
consist
of
just
one
line
of
malicious
script,
for
example,
a
single
command
that
says
“get
text
from
a
specific
HTTP
header
in
the
request
and
run
it
as
a
system
command”.
This
gives
general-purpose
command-and-control
access
to
any
attacker
who
knows
the
right
URL
to
visit,
and
the
right
HTTP
header
to
use
for
delivering
the
rogue
command.
What
to
do?
-
If
you’re
a
MOVEit
user,
make
sure
all
instances
of
the
software
on
your
network
are
patched. -
If
you
can’t
patch
right
now,
turn
off
the
web-based
(HTTP
and
HTTP)
interfaces
to
your
MOVEit
servers
until
you
can.
Apparently
this
vulnerability
is
exposed
only
via
MOVEit’s
web
interface,
not
via
other
access
paths
such
as
SFTP. -
Search
your
logs
for
newly-added
web
server
files,
newly
created
user
accounts,
and
unexpectedly
large
data
downloads.
Progress
has
a
list
of
places
to
search,
along
with
filenames
and
to
search
for. -
If
you’re
a
programmer,
sanitise
thine
inputs. -
If
you’re
a
SQL
programmer,
used
parameterised
queries,
rather
than
generating
query
commands
containing
characters
controlled
by
the
person
sending
the
request.
In
many,
if
not
most,
webshell-based
attacks
investigated
so
far,
Progress
suggests
that
you’ll
probably
find
a
rogue
webshell
file
named
human2.aspx
perhaps
along
with
newly-created
malicious
files
with
a
.cmdline
extension.
(Sophos
products
will
detect
and
block
known
webshell
files
as
Troj/WebShel-GO,
whether
they
are
called
human2.aspx
or
not.)
Remember,
however,
that
if
other
attackers
knew
about
this
zero-day
before
the
patch
came
out,
they
may
have
injected
different,
and
perhaps
more
subtle,
commands
that
can’t
now
be
detected
by
scanning
for
malware
that
was
left
behind,
or
searching
for
known
filenames
that
might
show
up
in
logs.
Don’t
forget
to
review
your
access
logs
in
general,
and
if
you
don’t
have
time
to
do
it
yourself,
don’t
be
afraid
to
ask
for
help!
Learn
more
about
Sophos
Managed
Detection
and
Response:
24/7
threat
hunting,
detection,
and
response ▶
Short
of
time
or
expertise
to
take
care
of
cybersecurity
threat
response?
Worried
that
cybersecurity
will
end
up
distracting
you
from
all
the
other
things
you
need
to
do?
About Author
