{"id":25461,"date":"2022-06-30T00:11:00","date_gmt":"2022-06-29T22:11:00","guid":{"rendered":"http:\/\/159.69.82.204\/win\/?p=25461"},"modified":"2022-06-30T10:46:22","modified_gmt":"2022-06-30T08:46:22","slug":"microsoft-exchange-server-remote-code-execution-schwachstelle-cve-2022-23277-trotz-patch-ausnutzbar","status":"publish","type":"post","link":"https:\/\/borncity.com\/win\/2022\/06\/30\/microsoft-exchange-server-remote-code-execution-schwachstelle-cve-2022-23277-trotz-patch-ausnutzbar\/","title":{"rendered":"Microsoft Exchange Server: Remote Code Execution vulnerability CVE-2022-23277 exploitable despite patch?"},"content":{"rendered":"

\"Exchange[German<\/a>]Are Microsoft Exchange servers on the current patch level still vulnerable via the remote code execution vulnerability CVE-2022-23277? Some fragments of information have just come to my attention that at least raise questions. In any case, the disclosure of the details that led to the vulnerability is interesting. I'll try to summarize the information as best as I can.<\/p>\n

<\/p>\n

Short review of CVE-2022-23277<\/h2>\n

\"\"CVE-2022-23277<\/a> is a remote code execution vulnerability rated as critical (score 8.8), which requires an attacker to be authenticated.\u00a0 However, only an authenticated role with low privileges (PR:L) is required on the Exchange Server. The attacker for this vulnerability could attack the server accounts for arbitrary or remote code execution. As an authenticated user, the attacker could attempt to trigger malicious code in the context of the server account via a network call. The vulnerability was found and reported by Markus Wulftange. Microsoft closed two vulnerabilities rated as critical, including the remote code execution vulnerability CVE-2022-23277 with a patch for Exchange Server 2013 – 2019 in March 2022.<\/p>\n

Disclosure of the issue<\/h2>\n

Markus Wulftangepublished his findings in the post Bypassing .NET Serialization Binders<\/a> as of June 28, 2022. He addresses in the post that serialization<\/a> binders are often used under .NET framework to validate the types specified in the serialized data. The goal is to prevent the deserialization of dangerous types that can have malicious side effects with runtime serializers such as the BinaryFormatter.<\/p>\n

In his blog post, Wulftange takes a look at cases where this check can fail and consequently allow validation to be bypassed. He also cites two real-world examples of insecure serialization binders in the DevExpress<\/em> framework (CVE-2022-28684) and Microsoft Exchange (CVE-2022-23277) that he goes over. Both vulnerabilities allow remote code execution.<\/p>\n

It is \"dry programmer stuff\" for .NET developers, I'm too many years out of this business to dig through the details. Markus Wulftange's conclusion: the insecure serializers BinaryFormatter<\/em>, SoapFormatter<\/em> and NetDataContractSerializer<\/em> should be discontinued and legacy code should be migrated to the preferred alternatives.<\/p>\n

Tinfanu-CUP and Exchange Hack<\/h2>\n

What immediately rang a bell for me was the tweet<\/a> shown below. The statement: the PoC exploit code for vulnerability CVE-2022-23277, which was used in Tianfu contest to hack Microsoft Exchange Server (don't know if the contest was 2021 or 2022), still works with a slightly tweaked approach. In the screenshot you can see that MSExchangePowerShell was used – here to call Paint.<\/p>\n

<\/a><\/p>\n

My first reading was, this is true, even for a fully patched Exchange Server that had the security updates installed in March 2022 to close the vulnerability. But the comment below say, that this can't be said. The Tinfanu PoC seems to work only on an unpatched Exchange. But my reading of the details of the vulnerability means, that Microsoft is using a lot of legacy code which uses the serialization binding. That bears the risk, that other code locations with serial bindings may not properly checked for malicious parameters – Microsoft just patched a specific code location.<\/p>\n

What to do?<\/h2>\n

I can't say at this point, if my interpretation is true, whether this will have an immediate negative impact on Exchange and Sharepoint installations. But the feeling remains that there are some security-related bugs lurking in the .NET code when it comes to testing serialization bindings. It's only a matter of time before the next patch is due because this is being exploited.<\/p>\n

So the question remains what administrators of Exchange servers can do, to mitigate possible attack vectors. Ad hoc, the usual advice comes to mind: Ensure that Exchange and OWA are not directly accessible via the Internet and, if necessary, that they are isolated via a reverse proxy.<\/p>\n

In the concrete case there is another point. To exploit CVE-2022-23277<\/a>, the attacker needs authenticated access to an Exchange account. Here you need to make sure that there are no orphaned accounts (employees who have left) and that the accounts cannot be hacked via weak passwords using brute force. If something is missing, you can add it in the comments.<\/p>\n

Similar articles:<\/strong>
\nSecurity updates for Exchange Server (March 8, 2022)<\/a>
\nTianfu Cup 2021: Exchange 2019 and iPhone hacked<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

[German]Are Microsoft Exchange servers on the current patch level still vulnerable via the remote code execution vulnerability CVE-2022-23277? Some fragments of information have just come to my attention that at least raise questions. In any case, the disclosure of the … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[580,1547],"tags":[869,69],"class_list":["post-25461","post","type-post","status-publish","format-standard","hentry","category-security","category-software","tag-exchange","tag-security"],"_links":{"self":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts\/25461","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/comments?post=25461"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts\/25461\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/media?parent=25461"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/categories?post=25461"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/tags?post=25461"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}