DIVD-2022-00013 - The curious case of the odd update.microsoft.com certificates

Summary

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: 1073570f79136511ba45b44c923a55c69b97e91d3aaa2e06e5e657129ca809ff
• Only 6 servers actually return data:
  • 1 returns forbidden
  • 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.

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.

Conclusion

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.

Timeline

More information

• Tweet from Mikko
• Article by Eric Romang