If during the Probe phase a username/password prompt for a particular service is discovered, an attacker can use a script (or one of several password grinding tools available) to start guessing passwords. The script can either brute-force the passwords of various lengths by trying all possible combinations or use a dictionary of potential passwords. Usernames are fairly easy to discover since email addresses are very often the same as usernames. Alternatively, many operating systems and services have default usernames that can be guessed. If the authentication mechanism behind the discovered username/password prompt does not lock accounts after a certain number of bad password guesses (Windows does not lock the built-in Administrator account by default), an attacker can take as long as is necessary to discover passwords. Even diligent administrators who enable intruder lockout protections in their environment can be defeated by a web-based interface that does not use the same protection when authenticating users. Even with these measures in place, you are just making it take longer to guess the passwords. A patient attacker will throttle the speed of the guessing so as to not trigger lockout.
Buffer overflows represent at least 50% of newly discovered vulnerabilities. Simply put (very simply... it can get complex), when an application is running, it allocates memory for the different information it needs to keep track of& mdash;names, addresses, phone numbers, costs, item names, and so on. Very often, applications ask the system or the user of the application for information to insert into these memory locations. If the application blindly accepts whatever the user (or system) provides, problems can result.
Let's say that an application asks for your name. It allocates 20 characters in memory for this information. If the user provides more than this number of characters and the application does not check for that possibility, memory past the previously allocated 20 characters can be overwritten with the user's information. If the user is very crafty and provides a character length that forces the application to overwrite portions of memory that the system uses to run other programs, it may be possible to trick the system into running whatever you want it to run. This could be a variety of things: instructions to install remote control software, return the contents of a directory, dump the username and password database, and so on. Anything you can put in a small chunk of code can be run using this technique.
Most buffer overflows result in a service or system crashing. The real art in crafting a successful buffer overflow is determining how many characters to insert before the malicious code to get the code to run. This length is commonly referred to as the offset.
Application behavior boundary flaws
This is a difficult category to define. When a developer designs an application, he does not always anticipate the ways the application may be tricked into doing other things that are not intended. A great example of this are the techniques that tricked Windows IIS web servers into running a command shell from the system directories using Unicode characters to represent a "dot-dot-slash." In most operating systems, a "../" moves a command shell up a layer in the filesystem. By crafting a URL with these Unicode characters and sending it to a vulnerable web server, it was possible to trick the web server into jumping out of its web root directory and into the system directory. From the there the attacker could execute any of the system applications& mdash;including cmd.exe, the command shell. Once a command shell running under the context of the web server is available, anything is possible.
This is just one example and there are many like it that affect a wide range of applications and operating systems. Please don't think I'm picking on Microsoft. Snort is well equipped to catch most of the known variations of this class of attack.
System configuration errors
When a system is not configured according to industry-accepted best practices, security vulnerabilities can be exposed. If an account has a very poor password, it may be guessed, for example. If a firewall is misconfigured to allow dangerous ports through into the internal network, it may increase the chances of a successful attack against your environment. A fair number of Snort signatures catch some of this "low-hanging fruit."
User input validation problems
One consequence of not checking what information a user supplies to an application was discussed in Section 188.8.131.52, above. Other, equally dire, consequences can result from not validating a user's input. A rule of thumb when attempting to write secure code is, "Never trust anything a user or other process tells you."
One common technique for exploiting careless user input validation is called SQL Injection. Most (really useful) web pages are built from the data contained in a database. If a web page asks the user for input (including things like login credentials), it is possible to replace what the web page is looking for with SQL code that gets passed to the database server on the backend. If this is properly crafted, it can make the database dump data that the user would normally not have access to& mdash;sometimes sensitive business data. It is also possible to insert data into the database, thereby poisoning the database and making it impossible to trust. The inserted data could also be used to create a user and password with high privileges if the database is used for authentication.
There are several Snort signatures that watch for this variety of attack, as well.
Once an attacker goes through the trouble of finding a vulnerable system, locates or builds the attack, and then successfully attacks the machine, it would be a nuisance to have to repeat the process every time he wants to access the system. It may be that between visits, the system gets attention from an administrator and is no longer vulnerable. Launching an attack multiple times against a system increases the chances of being noticed.
As a result, one of the first things an attacker does once a machine has been "owned" is make it easier to get back onto the system. The attacker may create an administrator-level user with a password that only he knows. He may simply acquire the username and password database from the system and crack the passwords using a password cracking utility (like John the Ripper or L0phtcrack) to decrypt the passwords on their system. Once the passwords are cracked, the attacker can login as whomever he wants.
The attacker may install some remote-control software, too. This makes it easier to work remotely on the system. The most common of these tools is a utility called netcat. Netcat is a very flexible remote command-shell utility that is easy to install remotely and can be configured to run on any network port, making it possible to access through a firewall.
Most serious attackers attempt to hide evidence of their activity at this point by altering or deleting system and firewall logs. They may use utilities that hide the directories that hold their attack tools from the eyes of administrators.
If the attacker was an automated tool or a network worm, it may copy itself to system files, and ensure that it will survive past a reboot. It may go so far as take steps to hide itself, too.
Once the attacker has an established presence on a system, the next move is to see what else is available. The attack phases begin anew with the compromised system as the source of the activity. The attacker will try to map the internal network (or the network that contains the compromised system). The newly enumerated machines will then be attacked, if they are interesting to the attacker. If the attack was a worm, this phase is sometimes the most damaging. The worm attempts to infect (probe and penetrate) other systems on the local network (or systems on the public Internet).
There is a concept called implied trust, in which a username and password that works on one system (or group of systems) works on another system. For example, if the system that was compromised is a Linux system, the username and password that works on this system may also work on the organization's Windows systems, as well. While the concept of "single sign-on" is an administrative aid, it can be a detriment in the event of a successful attack.
The only good news is that, if an attack gets to this point, it may be possible to detect this second round of attacks with your Snort systems.
This is the ultimate goal of a targeted attack, in which the attacker goes after your environment with a goal in mind. The goal may be to steal or destroy data, bring your systems down, or attack another organization from one of your systems, making you look guilty. The attacker looks for what I call the "soft, chewy center" of your network. This is most often a database that hosts your organization's proprietary data, financial information, inventory, or even email.
If a worm was the source of all your trouble, the result in this phase may be clogged network connections and crashing systems.
Kerry J. Cox is a knowledgeable and enthusiastic chief administrator/network engineer at Bonneville International/KSL Radio and Television where he manages 40 Red Hat Linux servers, as well as Solaris and FreeBSD, performing installation, patching, hardening, and maintenance.
View catalog information for Managing Security with Snort & IDS Tools
Return to the Security DevCenter.