[conspire] [OT] Microsoft security: CVE-2020-1472 (10/10 patch it NOW if not already done so) Netlogon / Zerologon

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [conspire] [OT] Microsoft security: CVE-2020-1472  
> (10/10 patch it NOW if not     already done so) Netlogon / Zerologon
> Date: Fri, 25 Sep 2020 23:36:17 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> If I'm reading correctly, allows unauthenticated remote compromise
>> of Administrator on Active Directory (AD) Domain Controllers (DCs).
>> Microsoft released patch/update 2020-08-11, but not everyone is
>> caught up yet.
>
> Ugh!  Yes, definitely a five-alarm fire example.  (Those words,
> 'unauthenticated remote compromise of Administrator on Active Directory
> (AD) Domain Controllers', are words you want to never hear.)

Yup ... or what do they call it after five-alarm fire ...
"general alarm" I think it is ... but not finding
authoritative reference on that right off (but lots of usage of it).
But maybe we save "general alarm" for when it's being actively
exploited at worm-like rate well in excess of
mitigation/control/eradication ... and at already up to large scale.
Sort'a like the Morris worm ... but at today's Internet scale.

I haven't read up on CVE-2020-1472 in a whole lot of details, and I'll
be the first to (gladly, even proudly) admit I'm not exactly a
Microsoft expert nor close - and especially not for Microsoft
Operating Systems (OSs), and even more so especially at scale.

In any case, what I glean from my reading/skimming about
CVE-2020-1472 ... it's not exactly a zero to Administrator on
AD DCs in a single step
http://linuxmafia.com/pipermail/conspire/2020-September/011156.html
... but it can get one there quite quickly enough ... and that likely
also can be / is being turned into automated exploits at scale ... I
think something like:
remote unauthenticated to
arbitrary code execution on AD DC at elevated privilege
which can get one quite quickly to full Administrator rights
on AD DC ... and from there, fully control of the Microsoft Domain
(as in AD, not to be confused with Domain as in DNS ...
in Microsoft speak, I believe it's more of an
administrative/security/authentication/control Domain,
again, I'm not a Microsoft expert nor do I play one on TV)

> I see it involves privilege escalation after talking to MS-NRPC, which
> is Microsoft's copy of Unix's remote procedure call (RPC) portmapper
> service -- which is infamously a menace and one of the reasons why NFS
> (which relies on the RPC portmapper) is not considered safe to expose to
> public networks.  Without digging deeper into the CVE-2020-1472 matter
Yes, I believe I read part of Microsoft's longer term fix involves
switching to secure RPC ... but that that won't be happening until
sometime in 2021 (probably mostly so in the meantime they don't both
secure - and further break (backwards compatibility) stuff in the
meantime - they may also need the time to develop/test/vet
it well works as intended and doesn't introduce too many new
problems).

And yes, hopefully/generally not exposed to public networks.  However,
to well bear in mind ...
o a whole lot of corporate/enterprise networks are often
   "hard crunchy outside, soft chewy middle" - think Tootsie Pop.
   Anyway, often pretty well firewalled from access coming from
   The (unwashed) Internet, but, once inside the corporate/enterprise
   network, ... what, 10s maybe 100(s) of thousands or more authorized
   employees, contractors, clients, select customers, "trusted"
   3rd parties, etc. have "inside" access, and things are often
   relatively soft from the inside, hence the "soft chewy middle" part.
   Also, with hundreds of millions or more, if not billions, working from
   home / remotely (shelter-in-place/lockdown, etc.) and VPNs, and
   workers (and teachers/students) also often using their own devices(!)
   to access over VPN or the like, there may also be significantly to
   perhaps unprecedented additional pathways to attack (notably via many
   more remote points and/or less tightly controlled devices/systems).
   Add to that how many quickly shifted to and massively scaled up
   "remote", well, at least some will make mistakes, and have things not
   as secured as they ought be ... how many and to what extent, who
   knows, but there's probably at least some elevated risk factor in that
   too.
o it only takes one bad actor/device/system, to start going after a
   whole lot 'o systems ... and if that happens, e.g. inside a large
   corporate network (5,000 phish emails received, 10 workers click
   the link, 3 of their computers can't defend against it and are
   instantly infected and now (stealthily - or not) attacking the
   corporate network ... stuff happens).
o far too many are often significantly behind on security updates.  This
   is what often makes for points of entry for ransomware attacks to
   start - get a foothold via an older not-yet-fixed vulnerability,
   stealthily work to leverage access and control of the target entity's
   digital assets - learn its basic infrastructure and backups, etc.,
   when sufficient control is gained, perhaps also considering timing for
   largest impact and highest probability of ransom being paid,  launch
   ransomware attack widely across enterprise - wait for your million(s)
   in payment, use payments to build more attack/exploit infrastructure
   and lather, rinse, repeat.

> discussed in this case, my instinct would always be that portmappers
> must _not_ be exposed to attack from hostile hosts or networks, and I'm
> utterly unsurprised that a flaw in Microsoft's has bit them with a
> priority 10-severity CVE.

Yep, wish I could say I was surprised, but not surprised.  And
it's not like Unix/BSD/Linux/... (and OSs) built upon/atop such are
immune from such booboos.  They sometimes happen - at relatively core
level, or some highly commonly used network utility/service - or
something that can be exploited locally (though that's not as large a
threat).  But not as commonly.  And there's a bit of truth to the
scale/numbers of the OS deployments, so that does also make Microsoft a
bigger target, and more homogeneous also makes exploits closer to
"universal" once found - e.g. I believe CVE-2020-1472 is actually
vulnerability that goes back to at least some 2008 versions of Microsoft
OSs - including even some no longer under support ... oh, and what I
seemed to glean too - not under Microsoft Support - no patch for you.
So, ... running an itty bitty unique boutique OS doesn't make one
immune ... but may take longer until vulnerability is found, and
exploit crafted for it.  As for Linux, there's generally plenty of
deployment and much commonality in code bases - so often there's
common vulnerability across many Linux-based OSs - but too,
often there's enough diversity it doesn't hit all - or even
necessarily most - of 'em at the same time.  E.g. the (overhyped)
"boothole" vulnerability - SUSE had managed to take a somewhat
different approach there, and thus wasn't vulnerable.  One generally
doesn't find that kind of diversity with Microsoft - as they're not
exactly handing out the source code to all and saying approximately
"do with it pretty much as you please, we're cool with it if you want
to do it better and/or differently".