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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
45 comments
[ 4.6 ms ] story [ 98.9 ms ] threadAfter 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
A "heroic" character that people could identify with to frame the rest of the story.
Scale and scope. And more attention to some things that were already known by those paying attention, true.
This is called Forward Secrecy.
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.
Wildcard certs in a shared VPS-like environment is a red flag.
Interesting, Interesting.
The shared private key was used to encrypt and authenticate the web traffic for all customers.
I agree on the reverse proxy part, but am not familiar enough with the product and Microsofts history to comment on that.
I will fix this right away!
Update: fixed.
https://xkcd.com/1179/
Maybe you meant "unambiguous"?
I’ve never heard anyone say “22nd of April 2017” in normal conversation. Maybe on a wedding invite.
FYI: In Australia we say "22nd of April 2017".
Date word order seems trivial by comparison.
We’re two countries separated by a common language.
This is why ISO-8601 was published 30 years ago.
https://en.m.wikipedia.org/wiki/Date_format_by_country
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.
Text-based messaging is not great for expressing or deciphering non-literal meaning.
That's a pretty naive look at penetration testing. Look, we have controls, so that CAN'T happen. Right.
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.
But I believe (I hope?) a lot has changed since then.
[1] https://www.computerworld.com.au/article/205327/microsoft_st...
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.