
CVE-2020-0688: Remote Code Execution on Microsoft Exchange Server - d4n
https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys
======
asveikau
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.

~~~
mzs
[https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/021_s...](https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/021_smtpd_envelope.patch.sig)

[https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/019_s...](https://ftp.openbsd.org/pub/OpenBSD/patches/6.6/common/019_smtpd_exec.patch.sig)

------
toraobo
> 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???

~~~
watermelon0
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.

~~~
to11mtm
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.

~~~
e12e
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.

------
zxcmx
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.

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

~~~
stevekemp
I'm currently going through a process like this with a lawyer in a foreign
country; they wanted me to provide banking details, proof of identity and
address.

Most of the details I could supply by email but they were so worried that the
emails could/would be modified that a lot of this had to be done via snail-
mail, and phone-calls where I read out my banking details.

On the one hand very understandable, but on the other very frustrating.

------
plasma
It wasn't clear whether this fixes existing installs with existing keys, or if
its only fixed for new installations.

