CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
1–10 of 21 posts
Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
#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???
Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
#3The 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.
Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
#4> 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)
[3]: https://docs.microsoft.com/en-us/previous-versions/dotnet/ar...
Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
#5> 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 secret (or as in this case, you use a shared one for all customers.)
I don't know why exactly did they choose to (de)serialize executable code, instead of using an XML or similar format, but similar choices were made (and later changed) with frameworks/libraries for other languages, so they are not the only one.
Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
#6> 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.
Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
#7> 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…
I could have some of the specifics wrong here, especially since it's been forever...
But the problem is there are some things that needed to be serialized for things like .NET remoting or firing stuff across appdomains. Things like Delegates.
Now, I -think- the intent, back in the day that ASP.NET was created, to use Code Access Security/Security Transparent Code (CAS/STC) to safely put a system like this together. But CAS/STC is pretty easy to do 'wrong' and a lot of people, rather than setting up the correct LinkDemands for individual items like Database, File IO, ETC on the specific endpoints, would just toss 'AllowPartiallyTrustedCallersAttribute' on the assembly and call it a day. This renders it CAS/STC almost worthless, to the point Microsoft half-killed this concept in Net 4.0 and in Core it's just about gone.
Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
#8> 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.
Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
#9> 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'm suprised this attack is even possible. Disabling of the viewstate MAC validation is disallowed, since a while [1]. However, MAC validation is apparently circumvented because the ViewStateUserKey is known.
[1]: https://devblogs.microsoft.com/aspnet/farewell-enableviewsta...
Re: CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server
#10Earlier quoted context omitted.
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…
I could have some of the specifics wrong here, especially since it's been forever... But the problem is there are some things that needed to be serialized for things like .NET remoting or firing stuff across appdomains. Things like Delegates. Now, I -think- the intent, back in the day that ASP.NET was created, to use Code Access Security/Security Transparent Code (CAS/STC) to safely put a system like this together. B…
Handling user input is tricky, and so is (de) serialization (I seem to recall most big frameworks from ruby, via php and python through Java - all doing some form of unsafe marshaling from both xml and json).
For encrypted and signed data on the client, you get to add "crypto is hard" on top.
You get things like clear signed data - that makes it easier to de-couple verifying signatures from marshaling contained data - perhaps without checking the signature...
You get encrypted data that isn't using a proper authenticated encryption construct - and again open the door for manipulated data.
Even with proper encryption, you get key revocation wrong (left out), and there's maybe no expiry on chiper texts either - so you happily accept data encrypted and signed by a compromised or expired key.
And there's key management, like in this case, re-using a key that should be sigle client/single session.
Oh,and re-play attacks due to missing serial numbers/nonce on transactions/messages...
But yeah, sure. Like another comment mentions - in theory encrypted data managed by the client is sound.. Unfortunately in practice theory isn't always right.