Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Trustwave Unveils New Offerings to Maximize Value of Microsoft Security Investments. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

NetSupport Information Leakage Using Nmap Script

NetSupport allows corporations to remotely manage and connect to PC's and servers from a central location for the purposes of desktop support.

In my last post I discussed how I wrote a script using the NetSupport scripting language to find versions of NetSupport running on clients with default installations that didn't require authentication 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, but you needed access to NetSupport Manager software to run it.

Since then, I've written a basic Nmap script that performs a similar task by checking whether a NetSupport Manager implementation requires authentication. If authentication is not requireed, it 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:

10846_9c827ec9-3ac8-4fa3-8f62-f6f65cc65360

As you can see, it provides quite a lot of information on the client NetSupport configuration. 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.

Each host I used to test returned a response which contained the word "License" (see the word "License" in the above response) in the packet response after a successful connection. So, 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 most likely authentication was required to get the results of the query.

I was amused that I did end up getting the information I was after. Even better, the "Connect" popup that usually appears on the remote PC, when running the previous NetSupport Manager script, did not pop up (for want of a better word !) when using the Nmap script after a successful connection. The following shows a typical response from my Nmap script from a PC running NetSupport client with a default installation:

8334_234bcf83-6cc7-4b89-87c7-c83dd2e46bd9

This meant I could run this script across the network and the clients would be unaware of my testing of their configuration.

While writing the script I needed to decide how much of the raw response to include in the Nmap output. Should it just include a basic message e.g. "No authentication required"? Should it return only the version information and a message? Should it 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.

In the end I decided to just return a chunk of the raw data and clean it up a bit removing \x00 and other hex data. So, what I ended up with is a custom Nmap script that does the following:

  • Sends a NetSupport Inventory query in raw packets
  • Checks if the response includes the word "License"
    • If so, it has successfully connected to the client without the need for authentication
    • If not, then most probably it requires authentication
  • Displays the response including user 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:

9015_4615e3b8-9a9a-438d-8df9-f9b3c78aaa62

This flaw draws attention to software that is installed without the need for passwords to be configured. In this case installing the default NetSupport client settings on a PC, where no Client password is set, can allow information to be freely returned, which can assist an attacker. But more worryingly, an attacker could remotely connect to the host without the need for a password, bypassing Windows local or domain passwords.

We informed NetSupport of this information leakage vulnerability, and they have responded claiming 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:

10500_8c95eace-4f24-4697-b4ca-a08d67455344

Of course to properly secure the installation and configuration, it's best to follow NetSupports own guidelines.

In the customer network I was testing that was using NetSupport there were quite a few PCs not configured with a NetSupport password. This essentially was a quick win for me, allowing 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 such powerful software that can bypass all your domain security so easily. Of course, software providers can 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:

 

 

local nmap = require "nmap"local shortport = require "shortport"description = [[Determines if NetSupport authentication is open or not and then gets Inventory query from host.]]author = "David Kirkpatrick"categories = {"auth"}portrule = shortport.port_or_service(5405, "netsupport")action = function(host, port)        local socket = nmap.new_socket()	local result        local status = true	local response        local strPayload = string.char (0x14, 0x00, 0x5a, 0x00, 0x44, 0x41, 0x56, 0x45,0x2d, 0x50, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x35, 0x00, 0x51, 0x00, 0x81, 0x00, 0x44, 0x41, 0x56, 0x45, 0x2d, 0x50, 0x43, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x3f, 0x4e, 0x41, 0x44,0x3e, 0x41, 0x48, 0x41, 0x40, 0x4e, 0x40, 0x48,0x43, 0x4f, 0x48, 0x45, 0x00, 0x38, 0x00, 0x03,0x00, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfd,0xb5, 0xa5, 0xff, 0x00, 0x00, 0x64, 0x61, 0x76,0x65, 0x00, 0x57, 0x4f, 0x52, 0x4b, 0x47, 0x52,0x4f, 0x55, 0x50, 0x00, 0x3c, 0x3e, 0x00, 0x44,0x41, 0x56, 0x45, 0x2d, 0x50, 0x43, 0x00, 0x31,0x32, 0x2e, 0x30, 0x2e, 0x30, 0x2e, 0x31, 0x30,0x30, 0x30, 0x00, 0x31, 0x30, 0x00, 0x00)                socket:connect(host.ip, port.number, port.protocol)        socket:send (strPayload)        status, result = socket:receive_bytes(1200)	local noauth = string.match(result, "License")        local cleanup1 = string.gsub(result, "\x00",",")        if (noauth) then		response = "!! No Authentication required !!\nHost Response = " ..cleanup1                return response         else                return "Not vulnerable - probably requires authentication."	end        	socket:close()end

Latest SpiderLabs Blogs

Clockwork Blue: Automating Security Defenses with SOAR and AI

It’s impractical to operate security operations alone, using manual human processes. Finding opportunities to automate SecOps is an underlying foundation of Zero Trust and an essential architecture...

Read More

Professional Services Sector Under Attack - Trustwave SpiderLabs Report 2024

Recent research by Trustwave SpiderLabs, detailed in their newly published report "2024 Professional Services Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies,"...

Read More

Atlas Oil: The Consequences of a Ransomware Attack

Overview Atlas Oil, a major player in the oil and fuel distribution industry, fell victim to a ransomware attack orchestrated by the Black Basta group. This attack not only compromised sensitive...

Read More