Security 101: Attack Vectors, Part 1

In the first part of this series, we discussed the entry points that an intruder could use to attack our “building,” our metaphor for network security. In the next few posts, we shall focus on the next level: attack vectors.

If vulnerabilities are the entry points, then attack vectors are the ways attackers can launch their assaults or try to infiltrate the building.

In the broadest sense, the purpose of the attack vectors is to implant a piece of code that makes use of a vulnerability. This code is called the payload, and attack vectors vary in how a payload is implanted.

Although there’s no official classification for attack vectors, we often catalog them according to how much interaction with the victim is needed to make them work. For example, if the attack vector is a malicious file, then the victim needs to download and open it for the attack to work. On the other hand, a SQL-injection attack needs little or no interaction with its victims.

These criteria help to determine how massive an attack can be. An attack that requires little interaction will probably be less massive than one that requires a high level of interaction. In the first case, the attacker can target only a certain number of “buildings” at the same time, that number is usually small, and all the work is done by the attacker. In contrast, an attack that depends on a high level of interaction can target many buildings in parallel because the attacker leaves the malicious code somewhere–disguised as file or a website–and its victims retrieve it on their own. So even though the attack requires a lot of work beforehand, at the moment of infection the work of the attack is done by the victims, not the attacker.

Most known attack vectors can be classified in one of three categories of interaction: low, medium, or high. Today we’ll focus on low-interaction vectors, leaving the rest for next time.

Low Interaction

These are vectors that require attackers to do much of the work ahead of time. Most of the effort is simply reconnaissance, figuring out the where and how of the attack. Victims need to do little for these attacks to be successful. Many of the vectors in this category require Internet applications. Here are three common vectors of this type:

  • SQL Injection: As the name implies, this vector works only on websites or applications that have direct contact with a database. Typically an attacker finds a legitimate website with some design flaws such that after a user inputs data, the information is not cleaned. (By cleaned we mean that all input is checked for special characters; if found they’re deleted with everything that follows them.) The lack of cleaning allows an attacker to send to the database SQL commands that will be executed–because the website doesn’t check whether the input is valid. As a result, the attacker can execute any SQL code without having the necessary permissions.

  • Buffer Overflows (BO): When any application requires user data, it is usually stored in a memory buffer until it is needed. As with SQL injection, sometimes the application does not check that the input fits in the buffer. Enter too much data and it overflows the buffer. When this happens the data that falls outside the buffer is translated into memory direction numbers, and whatever is on that memory direction is executed. An overflow could allow an attacker to at least crash the application, but if it is done correctly an overflow can execute any command the attacker wants, as long as the attacker knows in which memory direction the command is stored.

  • Cross-Site Scripting (XSS): This is a special kind of injection, similar to SQL injection. XSS works only on websites that allow the execution of scripting code (such as JavaScript). In this case, when a website asks for user input, the attacker enters scripting code between the <script> and </script> tags. The site reads the input, recognizes it as scripting code, and executes it without restrictions. This can be a one-time attack or a persistent attack if the input is stored in some part of the website (such as a Facebook wall message, or a user’s profile page). This attack is mostly silent because the tags make the scripting code invisible to any visitors.

These basic vectors have a lot of variations, depending of the platform, application under attack, and other criteria. Basically all low-interaction vectors work in a similar manner.

Until next time!