Trojan HorsesA Trojan is a program that performs unknown and unwanted functions. It could take one or more of the following forms:
- An unauthorized program contained within a legitimate program
- A legitimate program that has been altered by the placement of unauthorized code within it
- Any program that appears to perform a desirable and necessary function but does something unintended
Trojans can be transmitted to the computer in several ways -- through email attachments, freeware, physical installation, ICQ/IRC chat, phony programs or infected Web sites. When the user signs on and goes online, the Trojan is activated and the attacker gains access to the system.
Unlike a worm, a Trojan doesn't typically self-replicate. The exact type of attack depends on the type of Trojan.
Trojans can be:
- Remote access Trojans
- Keystroke loggers or password-sending Trojans
- Software detection killers
- Purely destructive or denial-of-service Trojans
The list of Trojan horses in the wild is expanding quickly, but a few seem to have remained relevant over longer periods of time, and many of these serve as platforms for the development of more lethal variations.
Back Orifice 2000, known as BO2K, is the granddaddy of Trojan horses, and has spawned a considerable number of imitators. Once installed on a victim PC or server machine, BO2K gives the attacker complete control of the system.
BO2K has stealth capabilities, will not show up on the task list and runs completely in hidden mode. Back Orifice and its variants have been credited with the highest number of infestations of Windows systems.
Another Trojan that has been around for a considerable time is SubSeven, although it is becoming less and less of a problem. SubSeven is a backdoor program that enables others to gain full access to Windows systems through the network.
Other common Trojans and spyware currently in the wild include: Rovbin, Canary, Remacc.RCPro, NetCat, Jgidol, IRC.mimic and NetBus.
Buffer OverflowsA buffer overflow (or overrun) occurs when a program allocates a specific block length of memory for something, then attempts to store more data than the block was intended to hold. This overflowing data can overwrite memory areas
A buffer overflow can allow an intruder to load a remote shell or execute a command, allowing the attacker to gain unauthorized access or escalate user privileges. In order to generate the overflow, the attacker must create a specific data feed to induce the desired error, as random data will rarely produce the desired command.
For a buffer overflow attack to work, the target system needs to have both a lack of boundary testing, and a machine that has the ability to execute code that resides in the data or stack segment. Once the stack is smashed, the attacker can deploy his payload and take control of the attacked system.
Three common ways to test for a buffer overflow vulnerability are as follows:
- Look for strings declared as local variables in functions or methods, and verify the presence of boundary checks in the source code.
- Check for improper use of input/output or string functions.
- Feed the application large amounts of data and check for abnormal behavior.
Products like Immunix's Stackguard and ProPolice employ stack-smashing protection to detect buffer overflows on stack-allocated variables. Also, vulnerability scanners like Proventia can help protect against buffer overflow.
Buffer overflow vulnerabilities can be detected by manual auditing of the code as well as by boundary testing. Other countermeasures include updating C and C++ software compilers and C libraries to more secure versions, and disabling stack execution in the program.
SQL Injection AttackSQL injection is an example of a class of injection exploits that occurs when one scripting language is embedded inside another scripting language.
The injection targets the data residing in a database through the firewall in order to alter the SQL statements and retrieve data from the database or execute commands. It accomplishes this by attempting to modify the parameters of a Web-based application.
For example, an injection attack will allow an attacker to execute SQL code on a server -- such as "SHUTDOWN WITH NOWAIT" -- which causes the server to immediately shut down and stop services.
A SQL injection attacker may use Server Side Scripting to gain access, exploit incorrectly filtered string literal escape characters embedded in SQL statements, exploit incorrect type handling in the code, or use other vulnerabilities of the database server.
For example, creating a username with "1=1", "a' or 't'='t", or any text within single quotes could force the execution of SQL commands on a vulnerable system.
SQL injection vulnerability prevention involves enforcing better coding practices and database administration procedures. Here are some specific steps to take:
- Disable verbose error messages that give information to the attacker.
- Protect the system account 'sa'. It's very common for the 'sa' password to be < blank >.
- Enforce the concept of least privilege at the database connection.
- Secure the application by auditing the source code to:
- Restrict input length of input
- Escape single quotes
- Whitelist good input
- Blacklist bad input
Cross Site Scripting (XSS)Web application attacks are often successful, and one reason for this is because the attack may not be noticed immediately. One such attack exploits the XSS vulnerability -- an XSS vulnerability is created by the failure of a Web-based application to validate user-supplied input before returning it to the client system.
For example, a user may be logged on to an active Web application session, and receive a malicious XSS link either through email or via a driveby download. If an attacker knows of an existing XSS hole that affects a specific application, he can insert the link into Web content and make it load automatically without user intervention.
If the application accepts only expected input, then the XSS vulnerability can be significantly reduced. Many Web application vulnerabilities can be minimized by adhering to proper design specifications and coding practices, and implementing security early in the application's development life cycle.
Another piece of advice: don't rely on client-side data for critical processes during the application development process, and use an encrypted session -- such as SSL -- without hidden fields.
About the author
Russell Dean Vines is a bestselling author, Chief Security Advisor for Gotham Technology Group, LLC, and former President of the RDV Group. His most recent book is The CISSP and CAP Prep Guide, published by John S. Wiley and Sons. He is available to answer your security threat questions via Ask the Expert.
This was first published in July 2007