Another
day,
another
access-token-based
database
breach.
This
time,
the
victim
(and
in
some
ways,
of
course,
also
the
culprit)
is
Microsoft’s
GitHub
business.
GitHub
claims
that
it
spotted
the
breach
quickly,
the
day
after
it
happened,
but
by
then
the
damage
had
been
done:
On
December
6,
2022,
repositories
from
our
,
atom
,
desktop
and
other
deprecated
GitHub-owned
organizations
were
cloned
by
a
compromised
Personal
Access
Token
(PAT)
associated
with
a
machine
account.
Once
detected
on
December
7,
2022,
our
team
immediately
revoked
the
compromised
credentials
and
began
investigating
potential
impact
to
customers
and
internal
systems.
Simply
put:
someone
used
a
pre-generated
access
code
acquired
from
who-knows-where
to
leech
the
contents
of
various
source
code
repositories
that
belonged
to
GitHub
itself.
We’re
guessing
that
GitHub
keeps
its
own
code
on
GitHub
(it
would
be
something
of
a
vote
of
no
confidence
in
itself
if
it
didn’t!),
but
it
wasn’t
the
underlying
GitHub
network
or
storage
infrastructure
that
was
breached,
just
some
of
GitHub’s
own
projects
that
were
stored
there.
Beachheads
and
lateral
movement
Think
of
this
breach
like
a
crook
getting
hold
of
your
Outlook
email
archive
password
and
downloading
your
last
month’s
worth
of
messages.
By
the
time
you
noticed,
your
own
email
would
already
be
gone,
but
neither
Outlook
itself
nor
other
users’
accounts
would
have
been
directly
affected.
Note,
however,
our
careful
use
of
the
word
“directly”
in
the
previous
sentence,
because
the
compromise
of
one
account
on
a
system
may
lead
to
knock-on
effects
against
other
users,
or
even
against
the
system
as
a
whole.
For
example,
your
corporate
email
account
almost
certainly
contains
correspondence
to
and
from
your
colleagues,
your
IT
department
and
other
companies.
In
those
emails
you
may
have
revealed
confidential
information
about
account
names,
system
details,
business
plans,
logon
credentials,
and
more.
Using
attack
intelligence
from
one
part
of
a
system
to
wriggle
into
other
parts
of
the
same
or
other
systems
is
known
in
the
jargon
as
lateral
movement,
where
cybercriminals
first
establish
what
you
might
call
a
“beachhead
of
compromise”,
and
then
try
to
extend
their
access
from
there.
What’s
in
your
repositories,
anyway?
In
the
case
of
stolen
source
code
databases,
whether
they’re
stored
on
GitHub
or
elsewhere,
there’s
always
the
risk
that
a
private
repository
might
include
access
credentials
to
other
systems,
or
let
cybercriminals
get
at
code
signing
certificates
that
are
used
when
actually
building
the
software
for
public
release.
In
fact,
this
sort
of
data
leakage
can
even
be
a
problem
for
public
repositories,
including
open-source
source
code
projects
that
aren’t
secret,
and
are
supposed
to
be
downloadable
by
anybody.
Open
source
data
leakage
can
happen
when
developers
inadvertently
bundle
up
private
files
from
their
development
network
into
the
public
code
package
that
they
ultimately
upload
for
everyone
to
access.
This
sort
of
mistake
can
lead
to
the
very
public
(and
very
publicly
searchable)
leak
of
private
configuration
files,
private
server
access
keys,
personal
access
tokens
and
passwords,
and
even
entire
directory
trees
that
were
simply
in
the
wrong
place
at
the
wrong
time.
For
better
or
for
worse,
it’s
taken
GitHub
nearly
two
months
to
figure
out
just
how
much
stuff
their
attackers
got
hold
of
in
this
case,
but
the
answers
are
now
out,
and
it
looks
as
though:
-
The
crooks
got
hold
of
code
signing
certificates
for
the
GitHub
Desktop
and
Atom
products.
This
means,
in
theory,
that
they
could
publish
rogue
software
with
an
official
Github
seal
of
approval
on
it.
Note
that
you
wouldn’t
already
need
to
be
an
existing
user
of
either
of
those
specific
products
to
be
fooled
–
the
criminals
could
give
GitHub’s
imprimatur
to
almost
any
software
they
wanted. -
The
stolen
signing
certificates
were
encrypted,
and
the
crooks
apparently
didn’t
get
the
passwords.
This
means,
in
practice,
that
even
though
the
crooks
have
the
certificates,
they
won’t
be
able
to
use
them
unless
and
until
they
crack
those
passwords.
The
mitigating
factors
That
sounds
like
pretty
good
news
out
of
what
was
a
bad
start,
and
what
makes
the
news
better
yet
is:
-
Only
three
of
the
certificates
had
not
yet
expired
on
the
day
they
were
stolen.
You
can’t
use
an
expired
certificate
to
sign
new
code,
even
if
you
have
the
password
to
decrypt
the
certificate. -
One
stolen
certificate
expired
in
the
interim,
on
2023-01-04.
That
certificate
was
for
signing
Windows
programs. -
A
second
stolen
certificate
expires
tomorrow,
2023-02-01.
That’s
also
a
signing
certificate
for
Windows
software. -
The
last
certificate
only
expires
in
2027.
This
one
is
for
signing
Apple
apps,
so
GitHub
says
it
is
“working
with
Apple
to
monitor
for
any
[…]
new
apps
signed.”
Note
that
the
crooks
would
still
need
to
crack
the
certificate
password
first. -
All
affected
certificates
will
be
revoked
on
2023-02-02.
Revoked
certificates
are
added
to
a
special
checklist
that
operating
systems
(along
with
apps
such
as
browsers)
can
use
to
block
content
vouched
for
by
certificates
that
should
no
longer
be
trusted. -
According
to
GitHub,
no
unauthorised
changes
were
made
to
any
of
the
repositories
that
were
leeched.
It
looks
as
though
this
was
a
“read
only”
compromise,
where
the
attackers
were
able
to
look,
but
not
to
touch.
What
to
do?
The
good
news
is
that
if
you
aren’t
a
GitHub
Desktop
or
Atom
user,
there’s
nothing
that
you
immediately
need
to
do.
If
you
have
GitHub
Desktop,
you
need
to
upgrade
before
tomorrow,
to
ensure
that
you
have
replaced
any
instances
of
the
app
that
were
signed
with
a
certificate
that
is
about
to
be
flagged
bad.
If
you
are
still
using
Atom
(which
was
discontinued
in
June
2022,
and
ended
its
life
as
an
official
GitHub
software
project
on
2022-12-15),
you
will
somewhat
curiously
need
to
downgrade
to
a
slightly
older
version
that
wasn’t
signed
with
a
now-stolen
certificate.
Given
that
Atom
has
already
reached
the
end
of
its
official
life,
and
won’t
be
getting
any
more
security
updates,
you
should
probably
replace
it
anyway.
(The
ultra-popular
Visual
Studio
Code,
which
also
belongs
to
Microsoft,
seems
to
be
the
primary
reason
that
Atom
was
discontinued
in
the
first
place.)
If
you’re
a
developer
or
a
software
manager
yourself…
…why
not
use
this
as
an
incentive
to
go
and
check:
-
Who’s
got
access
to
which
parts
of
our
development
network?
Especially
for
legacy
or
end-of-life
projects,
are
there
any
legacy
users
who
still
have
left-over
access
they
don’t
need
any
more? -
How
carefully
is
access
to
our
code
repository
locked
down?
Do
any
users
have
passwords
or
access
tokens
that
could
easily
be
stolen
or
misused
if
their
own
computers
were
compromised? -
Has
anyone
uploaded
files
that
shouldn’t
be
there?
Windows
can
mislead
even
experienced
users
by
suppressing
the
extensions
at
the
end
of
filenames,
so
you
aren’t
always
sure
which
file
is
which.
Linux
and
Unix
systems,
including
macOS,
automatically
hide
from
view
(but
not
from
use!)
any
files
and
directories
that
start
with
a
dot
(period)
character.
About Author
