Bugger Off: Patch Early, Patch Often, Patch Everywhere

Patches or updates to most operating systems appear on a regular basis, preventing malicious hackers from exploiting newly discovered vulnerabilities after they are applied. Administrators can usually choose to have critical patches pushed to their systems and applied automatically, making the update process fast and efficient.

Keeping tabs on security vulnerabilities is one way to prevent apps and utilities from becoming your server's (or network's) Achilles heel.

Discuss this article in the ServerWatch discussion forum

Unfortunately, the same is not true of many applications. If you install a program — whether commercial or open source — you may not be aware of when a critical security vulnerability is discovered at some point in the future, and that your server and possibly your network could be compromised at any time because of it.

The problem is compounded by the fact that the culprit may well be a vulnerability in the most innocuous utility on your server. Thus, even if you take care to keep your core applications patched and up to date, checking every last utility could easily slip your mind.

Two of the most common sources of problems are buffer overflows and cross-site scripting, and the discovery of new vulnerabilities seems to be endless. You need only take a look at any of the security and hacking oriented Web sites such as: SANS Internet Storm Center, Security Focus and Milw0rm to see new ones discovered every day. What's scary is that you could easily find out that a guest book application or issue tracking system you're running is vulnerable. Until you download and install an updated version, hackers could be having a field day, unbeknownst to you.

Buffer overflows are annoying because they are unnecessary. If coders paid more attention to the code they were writing and put the necessary safeguards in place, they would never happen in the first place. All it takes is someone armed with a fuzzer (i.e., a simple program that methodically pounds an application with user input of increasing length) to find a buffer overflow error in an application, and the game is up. Using a debugger makes it easy to see when the buffer overflow leads to processer registers to be overwritten. If the instruction pointer register, EIP, is overwritten, then some careful manipulation of the data that actually causes the buffer overflow can ensure the EIP is overwritten with a "JMP ESP" instruction. ESP is the stack point register, and the JMP ESP instruction resumes code execution at the address to which the ESP points. That point is exactly where the buffer overflow directs the malicious payload to be written.

The real problem is that standard prewritten payloads — such as getting the compromised machine to send a command prompt to the attacking machine, or adding a hacker-defined username and password to the machine, or even injecting a VNC server onto the machine so a hacker can take full visual control of it — are commonplace. Sites like Milw0rm have libraries of them, for example. Once a vulnerability is publicized, anyone can choose one of these stock payloads and run it on a machine with that vulnerability to compromise it completely.

Worse, the Metasploit framework reduces this to a simple point and click exercise: Choose a vulnerability, select a payload and click to exploit.

Cross-side scripting vulnerabilities are also astonishingly common in many Web applications, with new ones being discovered every day. These occur when user-supplied data, such as a user name or password, is treated as code that the application runs if the application does not correctly sanitize the user-submitted data. The possibilities are seemingly endless, but here's an example to illustrate the problem.

Assume you have an SQL-based Web application that asks for a user name and password, checks that the given password is the correct one for the supplied user name, and lets the user in if the pair match up. What could happen if a hacker enters ' or 1=1-- as a user name? If the data is not sanitized, the database may see the data after the ' as a SQL query, and evaluate 1=1 as True. The - would stop the SQL query, so instead of checking that the user name exists and the password matches the user name, the application would simply evaluate 1+1=2 as true, finish the query and let the hacker enter.

Sadly, the only practical solution to these problems is to monitor security Web sites for newfound vulnerabilities to see if any of the versions of the applications you are using on your servers are affected and to check vendors' or authors' Web sites to ensure you are running the latest patches or updates to all applications.

What happens if you don't was explained by a network administrator in a course run by security trainer Mati Aharoni. "The network admin told me that he didn't believe in patches, that he only updated his servers with service packs," Aharoni says. "I asked him to give me the output of netstat on his machine, and what he saw was literally hundreds of connections to Trojans and bots from his server. He realized then the silliness of his approach, and the consequences of not applying patches."

The message, then, is simple. Continue to make sure your operating system is up to date, but don't forget the smaller software packages. All it takes is one little app with one little buffer overflow to well and truly PWN your server.

This article was originally published on Jul 11, 2007
Page 1 of 1

Thanks for your registration, follow us on our social networks to keep up-to-date