Microsoft leaks TLS private key for cloud ERP product | Hacker News Reader

Microsoft leaks TLS private key for cloud ERP product

medium.com

210 pointsmgliwka44 comments

Inability to get a response upon reporting the vulnerability without heroic measures is more disturbing to me than the vulnerability. Vulnerabilities _will_ happen (even if this one is particularly... basic), but if the company isn't paying attention to responsible private disclosures, that's even more disastrous.

MS's eventual changing of their key practices suggests that they do agree this was a vulnerability, so discussions of how bad this vulnerability is seem irrelevant to me. The disturbing thing is not about how bad the vulnerability is, but about inability, as far as we can tell, to get MS to even analyze and evaluate the vulnerabilty without heroic measures including journalists threatening exposure.

Exactly. It's very easy to fix a poor security configuration. It's very difficult to fix a poor security culture.

There is an article from 2007 [1], quote: "Working in the Microsoft Security Response Centre (MSRC) has been voted number six out of the ten worst jobs in science in 2007 [...]"

But I believe (I hope?) a lot has changed since then.

[1] https://www.computerworld.com.au/article/205327/microsoft_st...

For those, like me, who were mightily confused by the timeline posted at the end — he switches to euro style dates in September and October but used US style dates in August and December.

Thank you for noticing, somebody is reading until the end ;-)

I will fix this right away!

Update: fixed.

Future readers thank you. :)

Please consider using a sane date format.

https://xkcd.com/1179/

What's not "sane" about the format most of the world uses? dd/mm/yy

Maybe you meant "unambiguous"?

"Ambiguous" and "insane" are best friends.

In this case it's only ambiguous because a populated country uses an insane version and plasters those insanely-formatted dates all over the world wide web.

The middle-endian format makes perfect sense as it is the same order of elements used in spoken English: “April 22nd 2017” = “4/22/2017”.

I’ve never heard anyone say “22nd of April 2017” in normal conversation. Maybe on a wedding invite.

Based on our conversation I'm guessing you're American.

FYI: In Australia we say "22nd of April 2017".

Yes, but I also understand you folks like to flush your toilets in the wrong direction and drive on the wrong side of the road.

Date word order seems trivial by comparison.

We’re two countries separated by a common language.

FWIW, the article currently uses the middle-endian mm/dd/yy.

Most of the world does not use that format. It is ambiguous because a large swath of the Earth population uses mm/dd/yy. Including the USA, but also many others.

This is why ISO-8601 was published 30 years ago.

Did you have a source for that? Wikipedia disagrees with you.

https://en.m.wikipedia.org/wiki/Date_format_by_country

Ok then s/most/much

Over 2.8 billion people, a bit less than half of the worlds population commonly use a date format other than dd/mm/yy. My point stands; use ISO-8601 to avoid ambiguity.

We run a SaaS application that spits out ISO-8601 date formats in reports. Hundreds of thousands of “normal humans” seem to under that format just fine.

The only thing you took issue with was me saying most of the world uses dd/mm/yy. In fact, I suggested that it is ambiguous for the reason you described. I'm not sure what you're trying to convince me of.

I inferred from the tone that you were suggesting the whole world adopt “your” chosen date format.

Text-based messaging is not great for expressing or deciphering non-literal meaning.

The Golem.de text that is mentioned in the article is now also available in an English translation: https://www.golem.de/news/microsoft-dynamics-365-wildcard-ce...

If we have an global scale attacker which can sniff the internet traffic to specific hosts, or an attacker capable of BGP hijacking, this attacker would be able to attack all companies who use Microsoft Dynamics (industrial espionage?). He would just need to sniff the credentials and log in.

After the Snowden leaks we all know that this is possible.

> After the Snowden leaks we all know that this is possible.

This bothers me. A lot of people might remember Narus and Narusinsight[1]

> Narus is noted for having created NarusInsight, a supercomputer system, whose installation in AT&T's San Francisco Internet backbone gave rise to a 2006 class action lawsuit by the Electronic Frontier Foundation against AT&T, Hepting v. AT&T.

But sure, I'm certain there are people that actually worked for these companies and can tell you how their stuff doesn't really work as advertised. Anyway, what exactly new did Snowden bring to the table in this particular context?

[1]: https://en.wikipedia.org/wiki/Narus_(company)#NarusInsight

> Anyway, what exactly new did Snowden bring to the table in this particular context?

A "heroic" character that people could identify with to frame the rest of the story.

xkeyscore --> https://en.wikipedia.org/wiki/XKeyscore

> Anyway, what exactly new did Snowden bring to the table in this particular context?

Scale and scope. And more attention to some things that were already known by those paying attention, true.

PRISM https://en.wikipedia.org/wiki/PRISM_(surveillance_program) And also that GCHQ tapped Google's datacenter links. https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns... After that information came out, Google started encrypting their internal networks.

Also, if such an actor was storing encrypted traffic as well, they could now easily decrypt this traffic en mass.

Yikes.. So compromise a public wifi and MITM + store any traffic pointed at the affected domain(s), then simply sign up for their own ERP account, download the key and decrypt.

Only if PFS is not in use though.

Most public wifi hotspots I've seen are unencrypted, so there'd be no need to do a MitM - just be within range to decode the client and AP transmissions.

Even on an unsecured network would the transmissions not be encrypted via tls from your computer to the server?

https://nsa.gov1.info/utah-data-center/

If you use ephemeral keys, as you should, the contents of past encryption is still secure if the private key gets leaked. The encryption keys are newly generated each time, the certified private/public key pair is only used to validate these encryption keys belong to server that has the certified keys.

This is called Forward Secrecy.

With TLS, the symmetric encryption keys are always newly generated regardless of the cipher suite chosen; the difference with the ephemeral cipher suites is how the keys are communicated.

Without forward secrecy, the client chooses the premaster secret, encrypts it with the server's public key, and sends it in the ClientKeyExchange message. With forward secrecy, the client receives signed ServerDHParams in the ServerKeyExchange and responds with ClientDiffeHellmanPublic in the ClientKeyExchange.

> “[c]ontrols exist in production environments that render the described technique ineffective [..]"

That's a pretty naive look at penetration testing. Look, we have controls, so that CAN'T happen. Right.

Hanno points out two big problems here that are not so obvious.

Firstly there is supposed to be a Problem Reporting mechanism for the certificates themselves. If you can't get the application developer to pull their finger out but you have acquired a Private Key you shouldn't have, you should be able to file such a report and get satisfaction in hours not weeks. Sophisticated users can prove they have the key without revealing it, but that's polite rather than obligatory. This mechanism either wasn't apparent to the problem's discoverer or didn't work. Neither is OK.

Secondly, even without being able to get a copy of the shared private key, sharing is a risk. If we confuse a remote client into talking to our service rather than the one they expected, they'll never know the difference because the keys check out fine.

The latter is why wildcards, while convenient, are not always a wise choice for security.

Darn, I saw this, it's also a bit similar on the onmicrosoft.com domain for 365 clients.

Interesting, Interesting.

Does the cloud ERP product use only the private key for rdp authentication?

No, the RDP authentication works using a Username/Password-pair displayed in the Life Cycle Services control panel.

The shared private key was used to encrypt and authenticate the web traffic for all customers.

I see, I agree that is still pretty bad. Wonder how many other RDP+IIS products use wildcard certs and share this same vulnerability to leak keys?

It makes sense that their "quick" solution is to give each customer their own cert/key, but I'm surprised that they didn't go with a reverse proxy approach from the beginning, where the wildcard key would be kept securely at their reverse proxy layer that no customers would have access to. Having to maintain TLS certs in IIS on each of these VMs seems like it would cause them more work than it's worth. Having experience with the platform, do you have any insight into why they would do TLS at the VM rather than via a reverse proxy?

As far as I remember, there was already a Powershell script as part of their deployment mechanism in place to deploy the certificates in the first place. Just the certificate provided to this script was a wildcard one.

I agree on the reverse proxy part, but am not familiar enough with the product and Microsofts history to comment on that.

This is rather common security hole on different app and web hosting services that provide "We will spare you the pain of getting ssl cert by yourself, and get you one for free," but which instead give you their wildcars cert.

Wildcard certs in a shared VPS-like environment is a red flag.

If you are aware of such issues specifically feel free to contact me. I'll make sure they get handled properly.

Reply on news.ycombinator.com