
Microsoft leaks TLS private key for cloud ERP product - mgliwka
https://medium.com/matthias-gliwka/microsoft-leaks-tls-private-key-for-cloud-erp-product-10b56f7d648
======
jrochkind1
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.

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

~~~
mgliwka
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...](https://www.computerworld.com.au/article/205327/microsoft_staffers_debate_worst_jobs_science_nomination/)

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

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

I will fix this right away!

Update: fixed.

~~~
jwilk
Please consider using a sane date format.

[https://xkcd.com/1179/](https://xkcd.com/1179/)

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

Maybe you meant "unambiguous"?

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

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

[https://en.m.wikipedia.org/wiki/Date_format_by_country](https://en.m.wikipedia.org/wiki/Date_format_by_country)

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

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

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

------
hannob
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...](https://www.golem.de/news/microsoft-
dynamics-365-wildcard-certificate-with-a-private-key-for-
everyone-1712-131544.html)

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

~~~
rjzzleep
> 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](https://en.wikipedia.org/wiki/Narus_\(company\)#NarusInsight)

~~~
sp332
PRISM
[https://en.wikipedia.org/wiki/PRISM_(surveillance_program)](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...](https://arstechnica.com/tech-policy/2013/10/new-docs-show-nsa-taps-
google-yahoo-data-center-links/) After that information came out, Google
started encrypting their internal networks.

------
mycall
> “[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.

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

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

Interesting, Interesting.

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

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

~~~
paulirwin
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?

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

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

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

