Recently I had to do a vulnerability scan for a client using OpenVAS. If you haven’t already used OpenVAS then you should, it’s the defacto opensource vulnerability scanner and v9 is a breeze to use. One of the results in the latest vulnerability assessment revealed that there was a webservice running on port 8000 of a server but the process responsible was just plain old ‘System’. With a bit of headscratching, I had to find out what that service was and whether we could/should/would block it or disable it.
Port 8000 was flapping in the wind and suffered some nasty vulnerabilities
The client has an SLA that requires any vulnerability of a with a severity of 7 or above be dealt with within 24 hours of being discovered so we had to find a solution fairly urgently. Viewing port 8000 in a browser didn’t really help.
Port 8000 was determined to not help me out.
The first thing was to use good old netstat to show which process was holding port 8000 open. So running the command netstat -aob|find “8000” told me that the PID was 4.
PID is 4…hmmmm
But PID4 just equates to SYSTEM. Which is about as helpful as one of my kids when the PS4 is turned on. Any service that uses the HTTP API in Windows will effectively be handled by the SYSTEM process, so I couldn’t just look up the process and kill it.
Enter netsh, the under-used command line hero of Windows. You can use netsh to show the list of processes registered to run HTTP services through the SYSTEM process, but the output isn’t awesomely straightforward. The command netsh http show servicestate returns the following information, showing me that something is running on port 8000.
As clear as mud
The output doesn’t actually show the process responsible for the URL. However if we scroll down the (very long) output you will see other blocks of information showing the process numbers of all the processess registering URLs. Unfortunately they don’t include the port numbers so you have no choice but to look up each process number and try disabling that process and then testing the port.
At last, a process number
After testing every process number shown in the output, process 54320 hit gold. This related to the Intel SBMAÂ Provider Service.
Finally!
Disabling the Intel SBMA Provider Service in the services admin tool closed port 8000 up like my wallet on a day out.
Now, obviously you could also close that port with the firewall on the machine, but if possible I prefer to find the root cause and at least make an assessment of the cause first. I’ve also not been able to find out what the Intel SBMA Provider Service actually does, but disabling it has so far not caused any issues, nor has blocking that port. If you know what it does, let me know in the comments below.
