After trying to get a copy of http.sys to examine, I discovered that it appeared to be in use on my desktop. Looking in to it, I found three desktop services using the HTTP Service provided by http.sys. There may be more, less obvious, vulnerable services/systems than just web servers. This post also demonstrates a brute-force approach to finding dependent services, for when you can’t find the proper way of doing so quickly enough.
Just a quick blurb as it’s getting late (and I’m getting tired), but I tried to get a copy of http.sys this morning (mainly because I think I was confusing it with winhttp.dll, thinking that it provided client side HTTP services), and discovered that my desktop may be vulnerable.
When I tried to copy http.sys using PuTTY‘s pscp command, I was getting a file not found error, despite the file showing up in a dir command. Next test, can I copy it? Copying http.sys worked. Third test, can I rename it? No. ren http.sys http.sis failed with an Access denied error.
I’d seen this combination of symptoms before, and it was because the file in question was in use. If this was the case, it could mean that my desktop was vulnerable. How can I test this hunch and find out which services, if any, are using http.sys?
Searching the registry under HKLM\SYSTEM\CurrentControlSet\Services\ I found HTTP, which has ImagePath set to system32\drivers\HTTP.sys. Checking the Start and Type values, I saw that this was a kernel device driver (as suggested by the .sys file name extension) that was configured to load on demand.
It wasn’t overly obvious what the dependent services are, so I disabled the service, albeit in a convoluted fashion by rebooting in to Linux, renaming the http.sys file, and rebooting back in to Windows. I thought afterward that I could have just changed the Start parameter in the registry entry while I was looking at it (I was used to having to boot Linux and rename a file to disable the anti-virus software for a demonstration I was doing — Windows wouldn’t let me disable that service, even as an admin user).
So, after renaming the http.sys file to stop it from loading on boot, I rebooted in to Windows and checked the event logs for services that failed to start. I found that the following services had failed to start because they depended upon the HTTP Service:
- Print Spooler
- SSDP Discovery service
- Windows Remote Management (WS-Management)
Checking those services in the Services control panel applet (or the registry Services key shown above) to see what the ImagePath is for those services, I could then use netstat -ban to see if those services were listening on any network ports.
I connected to the Print Spooler network port and issued a HTTP request, but didn’t get any response (the connection just remained open without any response from the server), suggesting that that particular port wasn’t serving HTTP requests and hence may not have been served by http.sys.
I attempted a wmic /node:<hostname> startup thinking that that command would use the Windows Remote Management service. A network capture showed that that command was causing an RPC connection to find the port of the service, and then a subsequent non-HTTP connection to the service’s port, so still no joy.
The Windows Remote Management service includes the WS-Management Protocol which ‘is based on the following standard web service specifications: HTTPS, SOAP over HTTP (WS-I profile), SOAP 1.2, WS-Addressing, WS-Transfer, WS-Enumeration, and WS-Eventing.’ (https://msdn.microsoft.com/en-us/library/aa384291%28v=vs.85%29.aspx).
I believe that the WS-Management Protocol is an implementation of the DMTF (Desktop Management Task Force — a task force creating standards for management of systems), as opposed to DTMF (Dual Tone Multi-Frequency — used to play simple tunes on a touch-tone telephone), WBEM (Web Based Enterprise Management) protocols. Something tells me that this may use the services of http.sys.
I haven’t had time to look into this further, but it looks like there may be a few services using http.sys that don’t immediately spring to mind when you think of HTTP server functionality. I also notice that the SANS Internet Storm Center have issued an update.