Thanks
to
the
precise
four-week
length
of
February
this
year,
last
month’s
coincidence
of
Firefox
and
Microsoft
updates
has
happened
once
again.
Last
month,
Microsoft
dealt
with
three
zero-days,
by
which
we
mean
security
holes
that
cybercriminals
found
first,
and
figured
out
how
to
abuse
in
real-life
attacks
before
any
patches
were
available.
(The
name
zero-day,
or
just
0-day,
is
a
reminder
of
the
fact
that
even
the
most
progressive
and
proactive
patchers
amongst
us
enjoyed
precisely
zero
days
during
which
we
could
have
been
ahead
of
the
crooks.)
In
March
2023,
there
are
two
zero-day
fixes,
one
in
Outlook,
and
the
other
in
Windows
SmartScreen.
Intriguingly
for
a
bug
that
was
discovered
in
the
wild,
albeit
one
reported
rather
blandly
by
Microsoft
as
Exploitation
Detected,
the
Outlook
flaw
is
jointly
credited
to
CERT-UA
(the
Ukrainian
Computer
Emergency
Response
Team),
Microsoft
Incident
Response,
and
Microsoft
Threat
Intelligence.
You
can
make
of
that
what
you
will.
Outlook
EoP
This
bug,
dubbed
CVE-2023-23397:
Microsoft
Outlook
Elevation
of
Privilege
Vulnerability
(EoP),
is
described
as
follows:
An
attacker
who
successfully
exploited
this
vulnerability
could
access
a
user’s
Net-NTLMv2
hash
which
could
be
used
as
a
basis
of
an
NTLM
Relay
attack
against
another
service
to
authenticate
as
the
user.
[…]The
attacker
could
exploit
this
vulnerability
by
sending
a
specially
crafted
which
triggers
automatically
when
it
is
retrieved
and
processed
by
the
Outlook
client.
This
could
lead
to
exploitation
BEFORE
the
is
viewed
in
the
Preview
Pane.
[…]External
attackers
could
send
specially
crafted
emails
that
will
cause
a
connection
from
the
victim
to
an
external
UNC
location
of
attackers’
control.
This
will
leak
the
Net-NTLMv2
hash
of
the
victim
to
the
attacker
who
can
then
relay
this
to
another
service
and
authenticate
as
the
victim.
To
explain
(as
far
as
we
can
guess,
given
that
we
don’t
have
any
specifics
about
the
attack
to
go
on).
Net-NTLMv2
authentication,
which
we’ll
just
call
NTLM2
for
short,
works
very
roughly
like
this,:
-
The
location
you’re
connecting
to
sends
over
8
random
bytes
known
as
a
challenge. -
Your
computer
generates
its
own
8
random
bytes. -
You
calculate
an
HMAC-MD5
keyed
hash
of
the
two
challenge
strings
using
an
existing
securely-stored
hash
of
your
password
as
the
key. -
You
send
off
the
keyed
hash
and
your
8-byte
challenge. -
The
other
end
now
has
both
8-byte
challenges
and
your
one-time
reply,
so
it
can
recompute
the
keyed
hash,
and
verify
your
response.
Actually,
there’s
a
fair
bit
more
to
it
than
that,
because
there
are
actually
two
keyed
hashes,
one
mixing
in
the
two
8-byte
random-challenge
numbers
and
the
other
mixing
in
additional
data
including
your
username,
domain
name
and
the
current
time.
But
the
underlying
principle
is
the
same.
Neither
your
actual
password
or
the
stored
hash
of
your
password
(for
example
from
Active
Directory)
is
ever
transmitted,
so
it
can’t
leak
in
transit.
Also,
both
sides
get
to
inject
8
bytes
of
their
own
randomness
every
time,
which
prevents
either
party
from
sneakily
re-using
an
old
challenge
string
in
the
hope
of
ending
up
with
the
same
the
keyed
hash
as
in
a
previous
session.
(Wrapping
in
the
time
and
other
logon-specific
data
adds
extra
protection
against
so-called
replay
attacks,
but
we’ll
ignore
those
details
here.)
Sitting
in
the
middle
As
you
can
imagine,
given
that
the
attacker
can
trick
you
into
trying
to
“logon”
to
their
fake
server
(either
when
you
read
the
booby-trapped
email
or,
worse,
when
Outlook
starts
processing
it
on
your
behalf,
before
you
even
get
a
glimpse
of
how
bogus
it
might
look),
you
end
up
leaking
a
single,
valid
NTLM2
response.
That
response
is
intended
to
prove
to
the
other
end
not
only
that
you
really
do
know
the
password
of
the
account
you
claim
is
yours,
but
also
(because
of
the
challenge
data
mixed
in)
that
you’re
not
just
re-using
a
previous
answer.
So,
as
Microsoft
warns,
an
attacker
who
can
time
things
right
might
be
able
to
start
authenticating
to
a
genuine
server
as
you,
without
knowing
your
password
or
its
hash,
just
to
get
an
8-byte
starting
challenge
from
the
real
server…
…and
then
pass
that
challenge
back
to
you
at
the
moment
you
get
tricked
into
trying
to
login
to
their
fake
server.
If
you
then
compute
the
keyed
hash
and
send
it
back
as
your
“proof
I
know
my
own
password
right
now”,
the
crooks
might
be
able
to
relay
that
correctly-calculated
reply
back
to
the
genuine
server
they’re
trying
to
infiltrate,
and
thus
to
trick
that
server
into
accepting
them
as
if
they
were
you.
In
short,
you
definitely
want
to
patch
against
this
one,
because
even
if
the
attack
requires
lots
of
tries,
time
and
luck,
and
isn’t
terribly
likely
to
work,
we
already
know
that
it’s
a
case
of
“Exploitation
Detected”.
In
other
words,
the
attack
can
be
made
to
work,
and
has
succeeded
at
least
once
against
an
unsuspecting
victim
who
themelves
did
nothing
risky
or
wrong.
SmartScreen
security
bypass
The
second
zero-day
is
CVE-2023-24880,
and
this
one
pretty
much
describes
itself:
Windows
SmartScreen
Security
Feature
Bypass
Vulnerability.
Simply
put,
Windows
usually
tags
files
that
arrive
via
the
internet
with
a
flag
that
says,
“This
file
came
from
outside;
treat
it
with
kid
gloves
and
don’t
trust
it
too
much.”
This
where-it-came-from
flag
used
to
be
known
as
a
file’s
Internet
Zone
identifier,
and
it
reminds
Windows
how
much
(or
how
little)
trust
it
should
put
in
the
content
of
that
file
when
it
is
subsequently
used.
These
days,
the
Zone
ID
(for
what
it’s
worth,
an
ID
of
3
denotes
“from
the
internet”)
is
usually
referred
to
by
the
more
dramatic
and
memorable
name
Mark
Of
The
Web,
or
MotW
for
short.
Technically,
this
Zone
ID
is
stored
in
along
with
the
file
in
what’s
known
as
an
Alternate
Data
Stream,
or
ADS,
but
files
can
only
have
ADS
data
if
they’re
stored
on
NTFS-formatted
Wiindows
disks.
If
you
save
a
file
to
a
FAT
volume,
for
example,
or
copy
it
to
a
non-NTFS
drive,
the
Zone
ID
is
lost,
so
this
protective
label
is
somewhat
limited.
This
bug
means
that
some
files
that
come
in
from
outside
–
for
example,
downloads
or
email
attachments
–
don’t
get
tagged
with
the
right
MotW
identifier,
so
they
sneakily
sidestep
Microsoft’s
official
security
checks.
Microsoft’s
public
bulletin
doesn’t
say
exactly
what
types
of
file
(images?
Office
documents?
PDFs?
all
of
them?)
can
be
infiltrated
into
your
network
in
this
way,
but
does
warn
very
broadly
that
“security
features
such
as
Protected
View
in
Microsoft
Office”
can
be
bypassed
with
this
trick.
We’re
guessing
this
means
that
malicious
files
that
would
usually
be
rendered
harmless,
for
example
by
having
built-in
macro
code
suppressed,
might
be
able
to
spring
into
life
unexpectedly
when
viewed
or
opened.
Once
again,
the
update
will
bring
you
back
on
par
with
the
attackers,
so
Don’t
delay/Patch
it
today.
What
to
do?
-
Patch
as
soon
as
you
can,
as
we
just
said
above. -
Read
the
full
SophosLabs
analysis
of
these
bugs
and
more
than
70
other
patches,
in
case
you
still
aren’t
convinced.
About Author
