DIVD-2022-00013 - The curious case of the odd update.microsoft.com certificates
|Case lead||Jan Los|
|Recommendation||If you get a notification about this, we recommend to investigate why this certificate is being served and take appropriate action.|
|Last modified||23 Nov 2022 21:04|
In August 2022, during his investigation into exposed LDAP servers, DIVD researcher Jan Los notices that secure LDAP servers (too) often use a certificate with the subject
www.update.microsoft.com. Using Shodan and the query
ssl:"www.update.microsoft.com it is dermined that at that point in time:
- 357 listening on the LDAP port use a certificate with this name
- 8180 listening on the HTTPS port use a certificate with this name
A second investigation on 27 Feb 2022 reveils that:
- 8588 ip addresses use a certificate with this name
- 8231 have the same SHA256 fingerprint:
- Only 6 servers actually return data:
- 1 returns
- 1 redirects to hxxps://fe2.update.microsoft.com/
- 1 redirects to hxxps://www.update.microsoft.com/
- 3 redirect to hxxps://support.microsoft.com/en-us/help/12373/windows-update-faq
- These 6 servers seem to be legit.
- 1 returns
Of the servers that have the
1073570f79136511ba45b44c923a55c69b97e91d3aaa2e06e5e657129ca809ff fingerprint we kown the following:
- The server that completes the handshare, has the private key for the certificate
- The certificates are issued and signed by the
Microsoft Update CA
- Modern windows versions have a certificate for this subCA and it’s Root, but the rootCA’s certificate expired in May 2021
- Apart for this expiration the certificate chain appears to be valid.
The certificate for www.update.microsoft.com, signed by the
Microsoft Update CA has been the issue of security troubles in the past, given this tweet from Mikko and on 18 June 2012 Microsoft had to regenerate the entire certificate chain, accoording to this article by Eric Romang.
On the 21st of October, after a call for help into the Dutch o-irt-o community, we receive a possible explanation for this data.
We have seen this before and this is not as exciting as it seems. Back then this appeared to be NorthGhost/TouchVPN, which is corroborated by most hosts having port 1194/tcp open. It seems to be that these hosts use this certificate to avoid being blocked by content filtering. In our investigation, the hosts did not actually have the certificate themselves, but seemed to be forwarding/SRC-NATing the handhake to a valid Microsoft server.
We have checked this with our data and our data seems to match with this explanation.
Our suspicioun that these certificates belonged to a criminal infrastructure was disproven. The found servers seem to be part of the TouchVPN service. These servers employ a trick to avoid being blocked by content filtering solutions.
TouchVPNs trick might be a bit doubious, but because the TLS handshake they offer results in an invalid chain because the chain has expired, the security risk is limited.
This trick may result in TouchVPn being able to bypass certain content filtering devices, if those devices do not block invalid certificate chains.
What we are doing
No futher action required.
What you can do
For now, there is not much you can do.
|05 Feb 2022||Certificates discovered for first time|
|24 Aug 2022||Case is referred to the ethics committee to see if it fits into the CoC|
|19 Sep 2022||Ethics committee, rules that case is within CoC|
|28 Sep 2022||Ethics committee is asked to reassess the case|
|05 Oct 2022||Ethics comittee explains earlier verdict, case is a go|
|21 Oct 2022||Got a hint from the community|
|23 Oct 2022||Case file published|
|23 Oct 2022||Case closed|