Late
last
week
[2023-02-16],
popular
web
hosting
company
GoDaddy
filed
its
compulsory
annual
10-K
report
with
the
US
Securities
and
Exchange
Commission
(SEC).
Under
the
sub-heading
Operational
Risks,
GoDaddy
revealed
that:
In
December
2022,
an
unauthorized
third
party
gained
access
to
and
installed
malware
on
our
cPanel
hosting
servers.
The
malware
intermittently
redirected
random
customer
websites
to
malicious
sites.
We
continue
to
investigate
the
root
cause
of
the
incident.
URL
redirection,
also
known
as
URL
forwarding,
is
an
unexceptionable
feature
of
HTTP
(the
hypertext
transfer
protocol),
and
is
commonly
used
for
a
wide
variety
of
reasons.
For
example,
you
might
decide
to
change
your
company’s
main
domain
name,
but
want
to
keep
all
your
old
links
alive;
your
company
might
get
acquired
and
need
to
shift
its
web
content
to
the
new
owner’s
servers;
or
you
might
simply
want
to
take
your
current
website
offline
for
maintenance,
and
redirect
visitors
to
a
temporary
site
in
the
meantime.
Another
important
use
of
URL
redirection
is
to
tell
visitors
who
arrive
at
your
website
via
plain
old
unencrypted
HTTP
that
they
should
visit
using
HTTPS
(secure
HTTP)
instead.
Then,
once
they
have
reconnected
over
an
encrypted
connection,
you
can
include
a
special
header
to
tell
their
browser
to
start
with
HTTPS
in
future,
even
if
they
click
on
an
old
http://...
link,
or
mistakenly
type
in
http://...
by
hand.
In
fact,
redirects
are
so
common
that
if
you
hang
around
web
developers
at
all,
you’ll
hear
them
referring
to
them
by
their
numeric
HTTP
codes,
in
much
the
same
way
that
the
rest
of
us
talk
about
“getting
a
404”
when
we
try
to
visit
a
page
that
no
longer
exists,
simply
because
404
is
HTTP’s
Not
Found
error
code.
There
are
actually
several
different
redirect
codes,
but
the
one
you’ll
probably
hear
most
frequently
referred
to
by
number
is
a
301
redirect,
also
known
as
Moved
Permanently
That’s
when
you
know
that
the
old
URL
has
been
retired
and
is
unlikely
ever
to
reappear
as
a
directly
reachable
link.
Others
include
303
and
307
redirects,
commonly
known
as
See
Other
and
Temporary
Redirect
used
when
you
expect
that
the
old
URL
will
ultimately
come
back
into
active
service.
Here
are
two
typical
examples
of
301-style
redirects,
as
used
at
Sophos.
The
first
tells
visitors
using
HTTP
to
reconnect
right
away
using
HTTPS
instead,
and
the
second
exists
so
that
we
can
accept
URLs
that
start
with
just
sophos.com
by
redirecting
them
to
our
more
conventional
web
server
name
www.sophos.com
In
each
case,
the
header
entry
labelled
Location:
tells
the
web
client
where
to
go
next,
which
browsers
generally
do
automatically:
$ curl -D - --http1.1 http://sophos.com HTTP/1.1 301 Moved Permanently Content-Length: 0 Location: https://sophos.com/ <--reconnect here (same place, but using TLS) . . . $ curl -D - --http1.1 https://sophos.com HTTP/1.1 301 Moved Permanently Content-Length: 0 Location: https://www.sophos.com/ <--redirect to our web server for actual content Strict-Transport-Security: . . . <--next time, please use HTTPS to start with . . .
The
command
line
option
-D -
above
tells
the
curl
program
to
print
out
the
HTTP
headers
in
the
replies,
which
are
what
matters
here.
Both
these
replies
are
simple
redirects,
meaning
that
they
don’t
have
any
content
of
their
own
to
send
back,
which
they
denote
with
the
header
entry
Content-Length:
0
Note
that
browsers
generally
have
built-in
limits
on
how
many
redirects
they
will
follow
from
any
starting
URL,
as
a
simple
precaution
against
getting
caught
up
in
an
never-ending
redirect
cycle.
Redirect
control
considered
harmful
As
you
can
imagine,
having
insider
access
to
a
company’s
web
redirection
settings
effectively
means
that
you
can
hack
their
web
servers
without
modifying
the
contents
of
those
servers
directly.
Instead,
you
can
sneakily
redirect
those
server
requests
to
content
you’ve
set
up
elsewhere,
leaving
the
server
data
itself
unchanged.
Anyone
checking
their
access
and
upload
logs
for
evidence
of
unauthorised
logins
or
unexpected
changes
to
the
HTML,
CS
,
PHP
and
JavaScript
files
that
make
up
the
official
content
of
their
site…
…will
see
nothing
untoward,
because
their
own
data
won’t
actually
have
been
touched.
Worse
still,
if
attackers
trigger
malicious
redirects
only
every
now
and
then,
the
subterfuge
can
be
hard
to
spot.
That
seems
to
have
been
what
happened
to
GoDaddy,
given
that
the
company
wrote
in
a
statement
on
its
own
site
that:
In
early
December
2022,
we
started
receiving
a
small
number
of
customer
complaints
about
their
websites
being
intermittently
redirected.
Upon
receiving
these
complaints,
we
investigated
and
found
that
the
intermittent
redirects
were
happening
on
seemingly
random
websites
hosted
on
our
cPanel
shared
hosting
servers
and
were
not
easily
reproducible
by
GoDaddy,
even
on
the
same
website.
Tracking
down
transient
takeovers
This
is
the
same
sort
of
problem
that
cybsersecurity
researchers
encounter
when
dealing
with
poisoned
internet
ads
served
up
by
third-party
ad
servers –
what’s
known
ih
the
jargon
as
malvertising.
Obviously,
malicious
content
that
appears
only
intermittently
doesn’t
show
up
every
time
you
visit
an
affected
site,
so
that
even
just
refreshing
a
page
that
you
aren’t
sure
about
is
likely
to
destroy
the
evidence.
You
might
even
perfectly
reasonably
accept
that
what
you
just
saw
wasn’t
an
attempted
attack,
but
merely
a
transient
error.
This
uncertainty
and
unreproducibility
typically
delays
the
first
report
of
the
problem,
which
plays
into
the
hands
of
the
crooks.
Likewise,
researchers
who
follow
up
on
reports
of
“intermittent
malevolence”
can’t
be
sure
they’re
going
to
be
able
to
grab
a
copy
of
the
bad
stuff
either,
even
if
they
know
where
to
look.
Indeed,
when
criminals
use
server-side
malware
to
alter
the
behaviour
of
web
services
dynamically
(making
changes
at
run-time,
to
use
the
jargon
term),
they
can
use
a
wide
range
of
external
factors
to
confuse
researchers
even
further.
For
example,
they
can
change
their
redirects,
or
even
suppress
them
entirely,
based
on
the
time
of
day,
the
country
you’re
visiting
from,
whether
your’re
on
a
laptop
or
a
phone,
which
browser
you’re
using…
…and
whether
they
think
you’re
a
cybersecurity
researcher
or
not.
What
to
do?
Unfortunately,
GoDaddy
took
nearly
three
months
to
tell
the
world
about
this
breach,
and
even
now
there’s
not
a
lot
to
go
on.
Whether
you’re
a
web
user
who’s
visited
a
GoDaddy-hosted
site
since
December
2022
(which
probably
includes
most
of
us,
whether
we
realise
it
or
not),
or
a
website
operator
who
uses
GoDaddy
as
a
hosting
company…
…we
aren’t
aware
of
any
indicators
of
compromise
(IoCs),
or
“signs
of
attack”,
that
you
might
have
noticed
at
the
time
or
that
we
can
advise
you
to
search
for
now.
Worse
still,
even
though
GoDaddy
describes
the
breach
on
its
website
under
the
headline
Statement
on
recent
website
redirect
issues,
it
states
in
its
10-K
filing
that
this
may
be
a
much
longer-running
onslaught
than
the
word
“recent”
seems
to
imply:
Based
on
our
investigation,
we
believe
[that
this
and
other
incidents
dating
back
to
at
least
March
2000]
are
part
of
a
multi-year
campaign
by
a
sophisticated
threat
actor
group
that,
among
other
things,
installed
malware
on
our
systems
and
obtained
pieces
of
code
related
to
some
services
within
GoDaddy.
As
mentioned
above,
GoDaddy
has
assured
the
SEC
that
“we
continue
to
investigate
the
root
cause
of
the
incident”.
Let’s
hope
that
it
doesn’t
take
another
three
months
for
the
company
to
tell
us
what
it
uncovers
in
the
course
of
this
investigation,
which
appears
to
stretch
back
three
years
or
more…
About Author
