NetSupport vulnerabilty allows information leakage

NetSupport is an application that allows corporations to remotely manage and connect to PCs and servers from a central location, to provide desktop support.

I wrote a script using the NetSupport scripting language to find versions of NetSupport running on clients with default installations whereby, no authentication was necessary to remotely connect to them. Essentially you could use NetSupport to bypass any Domain or local credentials to remotely connect to the PC and compromise it.

The problem with this script was that you needed access to NetSupport Manager software to run it. Since then, I’ve written a basic Nmap script that can be used to do a similar function to check whether authentication is required and if not also returns useful NetSupport configuration settings from the hosts. This negates the requirement to use the NetSupport software to find hosts configured with this weakness.

With no information on the NetSupport packet format, in my test network, I fired up Wireshark and captured all the relevant data sent from the NetSupport Manager when I performed an Inventory query from the Action menu on the manager to another host, as shown below:

Wireshark allows you to follow the TCP stream of the NetSupport service on TCP port 5405 and view the response. It also has a handy feature to show this data as raw Hex by clicking on C Arrays, which essentially gives you the raw Hex code required to send to a socket. I captured this raw data, then replayed the request by sending it to TCP port 5405 on the client using an Nmap script to see what output I would get.

From all the hosts I used to test, each returned a response which contained the word “License” in the packet response after a successful connection. I decided to use that as my true/false test in my Nmap script to see if the client required authentication or not. If “License” was returned then the information was freely retrieved without authentication. If it wasn’t, that meant that authentication was required to get the results of the query.

I did get the information I was after, and the “Connect” popup that happened on the remote PC when running the previous NetSupport Manager script, did not appear when using the Nmap script. The following shows a typical response from my Nmap script from a PC running NetSupport client with a default installation:

This meant I could run this script across the network and the clients would be unaware I was testing their configuration. While writing the script I was also determining how much of the raw response to include in the Nmap output, whether to just put a basic message e.g. “No authentication required”, or return just the version information and a message, or send the ASCII output.

From the testing I performed on other NetSupport versions, the responses seemed to change slightly. For example, in version 12.0, the response included this information in the _version=1200 parameter response. However for earlier versions there was no _version parameter returned.

I decided to just return a chunk of the raw data back, and clean it up a bit removing \x00 and other hex data. What I ended up with is a custom Nmap script which:

• Sends a NetSupport Inventory query in raw packets
• Checks if the response includes the word “License”
• If it has successfully connected to the client without the need for authentication
• The response also should include using information such as hostname, user, version info, password of the “Configurator Password”, etc.

The screenshot below shows that the encrypted Configurator Password of the client is also returned:

Installing the default NetSupport client settings on a PC where no client password is set can allow the return of information which can assist an attacker. Even worse, an attacker could remotely connect to the host without the need for a password, bypassing Windows local or domain passwords.

NetSupport were informed of this information leakage vulnerability and have reported to have fixed the issue in later revisions. The simple remediation is to ensure that a Client Password is configured in ALL clients using the software to mitigate the risk. This can be done by clicking on the NetSupport Client Security settings, and configuring a password as shown below:

In the network I was testing there were many PCs not configured with a NetSupport password. This allowed me to easily bypass any Domain or Windows credentials and use NetSupport to remotely connect to the hosts and compromise them.

The lesson here is that greater care should be taken when installing software that can bypass all your domain security so easily. Of course, the software providers could help by securing their default installation configurations as well. Anyway, here’s my Nmap script you may find useful to help you find weakly configured NetSupport hosts.

Author: David Kirkpatrick, Trustwave Principal Consultant.