Live data from Hacker News

CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

thezdi.com

11–20 of 21 posts

Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

#11
post #6
post #2

> Due to the use of static keys, an authenticated attacker can trick the server into deserializing maliciously crafted ViewState data. Many years ago I was shocked that ASP.net will deserialize arbitrary (potentially unsafe) objects from the client and relies on signatures to ensure that parameters sent by the client were in fact round-tripped via HTTP POST from the same server. How is __VIEWSTATE not a horrible idea…

AFAICT there's nothing inherently insecure about server-encrypted data on the client. You have to secure that encryption, but fundamentally it Should Be Fine(TM). Now, deserializing arbitrary objects which might contain code?... that's crazy town, but it was a different time.

This is an area where 'fine' rapidly becomes problematic.

Remember that the dataset is often going to be small, and frequently will contain known or easily guessed strings. Uncompressed, often at predicable locations.

There are whole classes of cryptographic vulnerabilities which might result from either not compressing (compression should in theory would normalize entropy over the stream) or using a compression algorithm that results in a predictable dictionary, length, or other value in the same location (if junk padding isn't used properly).

Also, sending the state from client to server might open replay attacks and all sorts of other horrid situations.

Security depends on doing everything correctly all the time; this context IMO just feels open to too many plausible and unknown (potentially introduced in the future) vulnerabilities.

Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

#12
post #11
post #6

Earlier quoted context omitted.

AFAICT there's nothing inherently insecure about server-encrypted data on the client. You have to secure that encryption, but fundamentally it Should Be Fine(TM). Now, deserializing arbitrary objects which might contain code?... that's crazy town, but it was a different time.

This is an area where 'fine' rapidly becomes problematic. Remember that the dataset is often going to be small, and frequently will contain known or easily guessed strings. Uncompressed, often at predicable locations. There are whole classes of cryptographic vulnerabilities which might result from either not compressing (compression should in theory would normalize entropy over the stream) or using a compression algo…

> Remember that the dataset is often going to be small, and frequently will contain known or easily guessed strings.

This is why modern crypto is designed to be resistant to prefix attacks, rainbow attacks, why CBC is considered a good idea, etc. soo....

Yeah, you're being paranoid about the wrong things, I think.

EDIT: FWIW, I was being a bit cheeky with the Fine(TM) thing, but if you get the "process" bits about encrypting the thing you send to the browser (and will be returned to you) right, you should really be in a position about as good as if the encryption itself had been compromised.

Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

#13
post #3

The audience of people caring about Exchange will not overlap with this, but in other mail server news, it didn't get much attention here that opensmtpd had another remote root hole announced yesterday, following the one from January. So in some sense I'm glad it's not just them, Microsoft gets to have a turn too.

https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/021_s...

https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/019_s...

Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

#14
post #4
post #2

> Due to the use of static keys, an authenticated attacker can trick the server into deserializing maliciously crafted ViewState data. Many years ago I was shocked that ASP.net will deserialize arbitrary (potentially unsafe) objects from the client and relies on signatures to ensure that parameters sent by the client were in fact round-tripped via HTTP POST from the same server. How is __VIEWSTATE not a horrible idea…

Seaside[1] and (IIRC) arc[2] both do this too. My understanding was that __ViewState was intended to be encrypted in production by setting something in machine.config[3]. [1]: https://en.wikipedia.org/wiki/Seaside_(software) [2]: http://arclanguage.org/ [3]: https://docs.microsoft.com/en-us/previous-versions/dotnet/ar...

Hell no. Seaside captures the state server side, stores it under an id and sends that id to the client. The client sends the id of the state snapshot back to the server.

Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

#15
post #2

> Due to the use of static keys, an authenticated attacker can trick the server into deserializing maliciously crafted ViewState data. Many years ago I was shocked that ASP.net will deserialize arbitrary (potentially unsafe) objects from the client and relies on signatures to ensure that parameters sent by the client were in fact round-tripped via HTTP POST from the same server. How is __VIEWSTATE not a horrible idea…

I assume the idea behind __VIEWSTATE is that you don't have to save anything on the server side, which makes the whole architecture easier (no need for storage layer, sharing the secret between machines allows for load balancing), and you can support as many clients as possible, since you don't have to worry about the storage size. __VIEWSTATE should be as secure as JSON Web Tokens, unless you manage to leak the secr…

There have been vulnerabilities in java and rails caused by deserializing arbitrary classes with given constructor parameters.

An attacker just has to find one that (e.g.) accepts a url and a filepath in its constructor and saves the file to that location, and you've (usually) got code execution (by eg overwriting something that gets run frequently).

Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

#16
I think this is an amazing bug for "practical" attackers. Not quite an MS08-067 ... but also sort of better?

For lots of SMBs their OWA (plus maybe a VPN server and a web site hosted elsewhere) is their only online presence.

With this, you phish or stuff one set of user creds and now you have all their mail spools (plus all third party accounts linked to those emails) and are in a great place to pivot to domain admin.

Probably small accounting firms will be worst hit but also countless other small manufacturing and services firms.

Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

#17
post #8
post #2

> Due to the use of static keys, an authenticated attacker can trick the server into deserializing maliciously crafted ViewState data. Many years ago I was shocked that ASP.net will deserialize arbitrary (potentially unsafe) objects from the client and relies on signatures to ensure that parameters sent by the client were in fact round-tripped via HTTP POST from the same server. How is __VIEWSTATE not a horrible idea…

I remember that JSF(java faces) used the same __VIEWSTATE approach to preserve the state, attaching the state to every request. It may also be a great source of security vulnerabilities. Luckily neither .net WebForms, nor JSF are popular nowadays.

>Luckily neither .net WebForms, nor JSF are popular nowadays.

Oh boy do I have news for you!

Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

#19
post #16

I think this is an amazing bug for "practical" attackers. Not quite an MS08-067 ... but also sort of better? For lots of SMBs their OWA (plus maybe a VPN server and a web site hosted elsewhere) is their only online presence. With this, you phish or stuff one set of user creds and now you have all their mail spools (plus all third party accounts linked to those emails) and are in a great place to pivot to domain admin…

The small accounting firm we use never sends sensitive information (e.g. tax forms, spreadsheets) in email.

Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server

#20
post #3

The audience of people caring about Exchange will not overlap with this, but in other mail server news, it didn't get much attention here that opensmtpd had another remote root hole announced yesterday, following the one from January. So in some sense I'm glad it's not just them, Microsoft gets to have a turn too.

Do you know any commercial products using it?
Post reply on HN