How to hack an unpatched Exchange server with rogue PowerShell code – Naked Security

Just below two months in the past, some worrying bug information broke: a pair of zero-day vulnerabilities have been introduced in Microsoft Exchange.

As we suggested on the time, these vulnerabilities, formally designated CVE-2022-41040 and CVE-2022-41082:

[were] two zero-days that [could] be chained collectively, with the primary bug used remotely to open sufficient of a gap to set off the second bug, which doubtlessly permits distant code execution (RCE) on the Exchange server itself.

The first vulnerability was harking back to the troublesome and widely-abused ProxyShell safety gap from again in August 2021, as a result of it relied on harmful behaviour in Exchange’s Autodiscover characteristic, described by Microsoft as a protocol that’s “used by Outlook and EAS [Exchange ActiveSync] clients to find and connect to mailboxes in Exchange”.

Fortunately, the Autodiscover misfeature that could possibly be exploited within the ProxyShell assault by any distant person, whether or not logged-in or not, was patched greater than a yr in the past.

Unfortunately, the ProxyShell patches didn’t do sufficient to shut off the exploit to authenticated customers, resulting in the brand new CVE-2022-40140 zero-day, which was quickly laconically, if misleadingly, dubbed ProxyNotShell.

Not as harmful, however harmful nonetheless

Clearly, ProxyNotShell was nowhere close to as harmful as the unique ProxyShell, on condition that it required what’s often known as authenticated entry, so it wasn’t open to abuse by simply anyone from wherever.

But it rapidly transpired that on many Exchange servers, understanding any person’s logon title and password could be sufficient to move as authenticated and mount this assault, even when that person would themselves want to make use of two-factor authentication (2FA) to logon correctly to entry their e-mail.

As Sophos skilled Chester Wisniewski put it on the time:

It’s a “mid-authentication vulnerability”, if you wish to name it that. That is a blended blessing. It does imply that an automatic Python script can’t simply scan the entire web and doubtlessly exploit each Exchange server on the earth in a matter of minutes or hours, as we noticed occur with ProxyLogon and ProxyShell in 2021. […]

You want a password, however discovering one e-mail tackle and password mixture legitimate at any given Exchange server might be not too tough, sadly. And you may not have gotten exploited to this point, as a result of to efficiently log into Outlook Web Access [OWA] requires their FIDO token, or their authenticator, or no matter second issue you is likely to be utilizing.

But this assault doesn’t require that second issue. […] Just buying a username and password mixture is a fairly low barrier.

As you in all probability bear in mind, many people assumed (or at the very least hoped) that Microsoft would rush to get a repair out for the ProxyNotShell holes, given that there have been nonetheless two weeks till October’s Patch Tuesday.

But we have been dissatisfied to search out {that a} dependable repair was apparently extra complicated than anticipated, and October got here and went with ProxyNotShell addressed solely by workarounds, not by correct patches.

Even November’s Patch Tuesday didn’t immediately present the wanted fixes, although the patches nevertheless got here out on the identical day as a part of an Exchange-specific safety replace that could possibly be fetched and put in individually:

Proof-of-concept revealed

Now that the mud has settled and everybody has had time to patch their Exchange servers (those they haven’t forgotten about, at the very least), researchers at Zero Day Initiative (ZDI), to which these vulnerabilities have been initially responsibly disclosed for submission to Microsoft, have defined how the bugs may be exploited.

The dangerous information, relying in your opinion of overt exploit disclosures, is that the ZDI staff has now successfully supplied a proof-of-concept (PoC) explaning assault Exchange servers.

The excellent news, after all, is that:

• We can now research and perceive the bugs ourselves. This not solely helps us all to make sure that the general precautions we’ve got taken (not merely restricted to patching) are possible to offer the safety we count on, but additionally informs us of progamming practices that we are going to need to keep away from in future, so we don’t get trapped into opening up bugs of this kind in our personal server-side code.
• We now don’t have any excuses left for not making use of the patches. If we’ve dragged our toes about updating, ZDI’s rationalization of why the assault works makes it clear that the remedy is unquestionably preferable to the illness.

How it really works

ZDI’s rationalization of this vulnerability makes for an enchanting story of how complicated it may be to chain collectively all of the components it is advisable to flip a vulnerability right into a viable exploit.

It’s additionally price studying that will help you perceive why digging into an current exploit may also help to disclose different ways in which a vulnerability could possibly be misused, doubtlessly prompting extra patches, urging configuration modifications, and selling new programming practices that may not have been apparent simply from fixing the unique gap.

The rationalization is, of necessity, sophisticated and fairly technical, and leads you forwards by means of a prolonged collection of steps to realize distant code execution (RCE) on the finish.

In the hope of serving to you observe the high-level particulars extra simply when you resolve to learn the ZDI report, right here’s a hopefully-not-too-simplified abstract with the steps listed in reverse…

…so you’ll know prematurely why the story takes the instructions it does:

• STEP 4. Remotely trick Exchange into instantiating a .NET object of your selection, with an initialisation parameter of your selection.

In trendy coding, an instantiated object is the jargon phrase for an allotted chunk of reminiscence, routinely initialised with the info and sources it’ll want whereas it’s in use, and tied to a selected set of features that may function on it. (Instantiate is only a fancy phrase for create.)

Objects could also be managed and managed by the working system itself, to assist keep away from the form of reminiscence mismanagement errors widespread in a language reminiscent of C, the place you sometimes have to allocate reminiscence your self, refill the related knowledge fields by hand, and bear in mind to launch the reminiscence and sources you’re utilizing, reminiscent of community sockets or disk information, while you’re achieved.

Objects typically have a programmatic perform related to them known as a constructor, which is routinely executed when a brand new object is created so as to allocate the correct quantity of reminiscence and the right set of system sources.

Usually, it is advisable to move a number of parameters as arguments to the constructor, to indicate the way you need the thing to be configured when it begins out.

Simply put, when you instantiate, say, a TextString object (we’re making these names up, however you get the concept) utilizing a parameter that’s itself a textual content string reminiscent of instance.com:8888…

…you’ll in all probability find yourself with a reminiscence buffer allotted to carry your textual content, initialised so it holds the identical worth you handed in, particularly the uncooked textual content instance.com:8888.

In that context, the textual content string handed in as knowledge to the thing constructor doesn’t instantly pose any apparent cybersecurity menace while you set off the constructor remotely, apart from a attainable denial of service (DoS) by repeatedly asking for greater and larger strings to attempt to exhaust reminiscence.

But when you have been to instantiate, say, a ConnectedTCPClient object utilizing the exact same textual content string parameter of instance.com:8888, you may find yourself with a reminiscence buffer prepared to carry non permanent knowledge, together with a community socket allotted by the working system that’s able to alternate knowledge woith the server instance.com over TCP port 8888.

You can see the distant code execution danger there, even when you by no means get to ship any knowledge to the open socket, given that you just’ve tricked the server into calling dwelling to a location that you just management.

You may even discover an object known as, say, RunCmdAndReadOutput, the place the textual content string you ship as a parameter is, fairly actually, a command you need to run routinely as quickly the thing is created, so you may accumulate its output later.

Even when you by no means get to get better the output of the command, simply instantiating such an object would nonetheless allow you to select a command to run, thus supplying you with generic distant code execution and presenting a danger restricted solely by the entry rights of the server course of itself.

Of course, the assault is barely this simple when you get to the final stage, which you’re not supposed to have the ability to do, as a result of Exchange has a strict allowlist that stops you from selecting any previous object to instantiate.

In principle, solely protected or low-risk objects may be created remotely through PowerShell, in order that instantiating our imaginary TextString above, or a EasyIntegerValue, is likely to be thought-about acceptable, whereas a ConnectedTCPClient or a RunCmdAndReadOutput would positively not be.

But the ZDI researchers discover that earlier than triggered the final step, they may do that:

• STEP 3. Remotely trick Exchange into pondering {that a} low-risk object that’s handed the protection take a look at is, in reality, another object of your selection.

Even so, you may count on Exchange to stop the distant creation even of low-risk objects, to minimise the menace even additional.

But the researchers discovered that they may:

• STEP 2. Remotely trick Exchange into utilizing its PowerShell Remoting characteristic to create an object based mostly on initialisation parameters managed externally.

And that was attainable due to the ProxyShell-like gap that was solely semi-patched:

• STEP 1. Remotely trick Exchange into accepting and processing an internet request with code in by packing a sound username:password area into the request as properly.

Even if the person named within the request wasn’t truly logged in, and would want to undergo some form of 2FA course of to entry their very own mailbox, an attacker who knew their username:password mixture would have sufficient authentication data to trick Exchange into accepting an internet connection that could possibly be used to kick off the assault chain described in steps 2 to 4 above.

Loosely talking, any legitimate username:password mixture would do, on condition that the “authentication” was wanted merely to stop Exchange from rejecting the HTTP request up entrance.

What to do?

Note that this assault solely works:

• If you might have on-premises Exchange servers. Microsoft claims to have locked down its personal cloud providers rapidly, so Exchange Online is just not affected. Make certain you know the place your Exchange servers are. Even when you now use Exchange Online, you should still have on-premises servers operating, maybe left over by mistake out of your migration course of.
• If your servers are unpatched. Make certain you might have utilized the Exchange Software Update of 2022-11-08 to shut off the vulnerabilities that the exploit requires.
• If your servers nonetheless settle for Basic Authentication, often known as legacy authentication. Make certain you might have blocked all facets of legacy authentication so your servers received’t settle for the username:password headers talked about above, and received’t settle for dangerous Autodiscover protocol requests within the first place. This stops attackers tricking a server into accepting their booby-trapped object instantiation tips, even when that server isn’t patched.

You can preserve observe of our official prevention, remediation and response recommendation, and Sophos clients can preserve observe of the menace detection names utilized by our merchandise, through the Sophos X-Ops Twitter feed (@SophosXOps).

New data has been printed concerning CVE-2022-41040 and CVE-2022-41082: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) November 21, 2022

LEARN MORE ABOUT EXCHANGE AUTHENTICATION AND OAUTH2

With Paul Ducklin and Chester Wisniewski
Intro and outro music by Edith Mudge.