ITsecurity
twitter facebook rss

A RAT is not a RAT when a remote access tool is a remote access trojan

Posted by on April 28, 2014.

Remote Access Trojans (RATs) are a blight on the internet – they allow attackers to take complete control of the victim’s computer to do and steal what they wish. Remote Access Tools (RATs), however, are increasingly valuable to provide remote support to an increasingly distributed workforce. Which is which is not always clear.

At the end of last month, Trustwave‘s David Kirkpatrick looked at the NetSupport remote management application (clearly designed to be one of the latter). He was testing the security of a client and noticed hundreds of computers running NetSupport; and decided to see if any were susceptible to a particular remote buffer overflow vulnerability.

Not wanting to potentially cause disruption to hundreds of clients running the exploit against all of them I needed to find the version of the software running and also see if any of the hosts could be taken over using no authentication, for the quick win.
An Intro to NetSupport Manager Scripts

He wrote a script to remotely find if the NetSupport installations required specific authentication, and to see if he could connect if they did not. He found that he could connect, and therefore use, any installation that did not require user authentication. The implications would be quite severe if

  1. he didn’t need to do this from within the NetSupport Manager
  2. the connection did not pop up a warning window on the accessed PC

Since then he has worked on a more covert method to take over NetSupport clients – and today he will announce his success on a new Trustwave SpiderLabs blog post.

Since then [the March post], 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.

But by coming via Nmap from outside of the network, the new script doesn’t trip the users’ ‘connect’ warning.

This meant I could run this script across the network and the clients would be unaware I was testing their configuration… But more worryingly, an attacker could remotely connect to the host without the need for a password, bypassing Windows local or domain passwords.

spacer

The information returned by Kilpatrick's Nmap script

The information returned by Kirkpatrick’s Nmap script

spacer

Put bluntly, using this new Nmap script, Kirkpatrick found that he could “easily bypass any Domain or Windows credentials and use NetSupport to remotely connect to the hosts and compromise them.”

What we end up with is the archetypal description of a dual-use weapon. In the hands of a white hat pentester, this script will allow the auditor to rapidly, and with no disturbance to the network, discover which NetSupport installations have not been properly secured by their users. But in the hands of a black hat hacker, it can be used to covertly completely and remotely take over the user’s PC. The moral is simple: never accept the out-of-the-box default security settings for any product – if there is an option for password authentication, take it; and always change any default password to one of your own.


Share This:
Facebooktwittergoogle_plusredditpinterestlinkedinmail

Leave a Reply

Your email address will not be published. Required fields are marked *

Submitted in: News |