Feb 07, 2012

NetSupport Manager: Learning From a Year-Old Vulnerability

by Frank Gifford

There are new vulnerabilities popping up all the time, and some go unfixed for days or even months. But NetSupport Manager has been out for a full year now, and sad to say, the vulnerability that was reported still exists within the product. Today we review this vulnerability, not to pick on NetSupport Manager, but to illustrate an important lesson for all of us about auditing your network and testing for vulnerabilities.

First, for those who do not know, let’s look at what NetSupport Manager does. Here is a quote from the website:

"The latest evolution in Remote PC support and desktop management . . . Designed to operate over your network, via mobile communications or the Internet, securely and without the need for firewall configuration."

Usefulness of the product aside, a stack-smashing attack was reported while using this product a year ago. This attack would allow anyone to seize control of the machine. Smashing is typically accomplished by overwriting a buffer that sits on the stack, which then overwrites the return address of the function and exception handlers. Crafting the bytes carefully, a hacker can then have the program run arbitrary code.

The key point, at least for this post, is that despite a very nasty exploit against this software that has been public knowledge for over one year, you can buy it today. You might even have it deployed already.

Auditing and Testing Vulnerabilities in Your Own Network

Here are a couple of questions to keep you up at night:

How many third-party software programs, such as NetSupport Manager, does your company use?
How would you know that such a vulnerability exists in your company if the vendor doesn't provide an update?

Here is the two-pronged answer:

A quick Google search for "NetSupport Manager vulnerability" provides, as the fourth link, a warning about this particular attack. (Note the release date of 2011-01-10.) It is important to continue searching for information about vulnerabilities within the software and devices that you use in your network.

Use a box, such as the BreakingPoint Storm or FireStorm, to generate traffic. Our box will generate this exact attack and test your device as well as the IDS/IPS that is supposed to protect you. This is critical, particularly after reading about the latest published vulnerabilities.

Do a periodic audit of your software.
Test your network using the attack.

But there is more to it than simply auditing and testing. Let’s discuss a scenario. In an earlier blog post, I mentioned a job candidate waiting in the lobby who may have access to your VoIP system via the telephone. While that post described a particular VoIP implementation, there is another plausible avenue of attack:

Companies typically perform interviews in a conference room that will have at least one data port available. Good companies have several people interview a candidate to ensure that there is a good team fit and, for a high-tech company, that all the technical issues are covered. Between these interview sessions, a candidate can be left alone in the room - behind your firewall. Have you ever interviewed someone and decided there was no way you'd ever trust him in your company? How long would it take him to send a malicious packet or exploit a known long-term vuln such as the one presented by NetSupport Manager?

How You Can Prevent Vulnerability Exploitation

Perhaps my scenario above is a bit dramatic, but it is certainly realistic. And it can be prevented, because many vulnerabilities are publicly known for a long time - a year in the case of NetSupport Manager. So what can you do?

For the programmer:

Remember: Stack buffer overflows still get discovered. When there is a push to get your code out the door on time, it's easy to miss this. A common pitfall is prototyping code and not going back to make sure it is correct.
Never trust user input, and don't trust the caller to your function to have validated the size of the buffer.
Unicode or http encoding is longer, so a string of "://" may have a "length" of 3 bytes, but your application may have converted that somewhere else to "%3a%2f%2f," which is 9 bytes.

For the business owner:

You cannot wait for a vendor - you must periodically audit all your software for vulnerabilities. The Google search above took only seconds.
Split the audit work up, and offer something very nice to the employee with the best find. It'll be worth every penny.
It's basic knowledge but overlooked: All visitors to your company need to be escorted at all times.

Oh, and don’t forget: Test.