Introduction
Recently a penetration scan was done on a client's Microsoft Endpoint Configuration Manager's (MECM) environment. The MECM security settings stipulated EHTTP rather than PKI security. EHTTP (Enhanced HTTP) secures client communication by using self-signed certificates. Sometimes the overhead of using PKI certificates is not practical - for instance if automatic enrolment and renewal cannot be established. EHTTP does secure communications when this situation exits. Without a client PKI certificate, network access account or Windows authentication clients can securely download application content from distribution points.
And this was all good until the penetration scan revealed that the MECM Distribution Point was not in compliance with RFC 6797 - a vulnerability we needed to address. This vulnerability states that the HSTS (HTTP Strict Transport Security) is missing from the HTTP server - that is, the MECM Distribution point. HSTS is a security protocol that commands a browser to only communicate via HTTPS. When HSTS is not activated the following attacks can occur:
1) Downgrade attacks: This is a cryptographic attack that can downgrade an encrypted connection to a lower-quality connect such as a cleartext connection.
2) Man in the Middle Attacks: This is a cyberattack in which direct communication between two entities is secretly compromised and a third entity is filtering and capturing the communication data.
3) Cookie hijacking: This is when the attacker steals HTTP cookies by listening on the communication between the two systems, thus gaining access to web browser data.
And so the begging question was this: could we enable HSTS on a MECM distribution point configured to use EHTTP? I found no definitive documentation answering this question. The documentation I did find suggested HSTS could only be enabled on a site using PKI certificate authentication. Further investigation was required.
Application download without HSTS and EHTTP.
Without enabling HSTS I cleared the Configuration Manager client cache and started a test install of a PSApp deployment toolkit package. I then examined the datatransfer.log file on the client to determine the mode of transport the download used in the transaction.
The site communication was configured as per the following screen grabs.
As can be seen in the datatransfer.log file below the deployment download is initiated using http with redirection to port 80.
Application download with HSTS and EHTTP.
I then enabled HSTS on IIS on the MECM Distribution Point.
This was done by opening the IIS admin console and navigating to the Default Web Site. It was then matter of clicking on HSTS in the actions column and enabling the feature, ensuring all options were selected.
I then opened a command prompt as administrator and ran the following command: iisreset.exe
On the test server I then cleared the MECM client caching by running control smscfgrc, clicking on the Cache tab and then clicking on Clear Cache
I then reinstalled the application within software center. As can be seen from the DataTransfer.log file - the download takes place using HTTPS on port 443.
Conclusion
The tests here demonstrate that oftentimes what is it expected in a given configuration is not always what is observed. Enabling HSTS in this scenario should not have been possible when MECM is configured for EHTTP communications. Astonishingly, forcing HSTSC on the IIS installation on the Distribution Points forces the MECM client to download application content using HTTPS on port 443 using self-signed certificates, almost as if the site is configured to use PKI certificates.
A further dividend for us here is that the Penetration scan no longer detects the RFC 6797 vulnerability.
I hope you enjoyed this blog and I wish you much success in your own testing of HSTS with MECM using EHTTP.
