Command Execution SQL Injection and Friends

Command execution generally includes operating system commands and SQL injection. However, in general, this is a potential issue for all systems that your site interacts with, such as XMLRPC, REST, and SOAP. The basic problem is that data from the user (the content of your blog post) is mixed with control information (the query to insert that content into the database) and the combined string is executed against the database. This book focuses on SQL injection more than other types of command injection because it is the most common command-injection issue found in Drupal. However, the same concepts apply to interactions with any system.

SQL stands for Structured Query Language and is the name of the particular language used to interact with databases. SQL is meant to be the same for all databases, but in practice it varies widely from one database to another.

There are several common models for safely handling user data:

Rejecting known bad input: Using blacklists to filter input is the process of refusing to accept data that contains items that are in a list of inappropriate characters. This is not particularly useful because it relies on the programmer to write code to handle an exhaustive list of bad inputs. That is a difficult task in the first place and impossible to do once you consider that new technologies with new vulnerabilities are constantly being invented.

Accepting known good input: Using a whitelist to determine safe input is safer than rejecting known bad because a list of safe input should stay safe into the future.

Both rejecting known bad and accepting known good are extremely limited in their usefulness to store anything more than simple text without any special characters. Drupal deals with rich data sets from clients such as HTML, which makes these two strategies unsuitable. These methods are not used in Drupal and therefore are not discussed in the rest of the chapter. Some other options include:

Sanitizing data before it is stored works well in a simple system but fails when the input is later used in a variety of contexts; rules to sanitize the data for use in one context may not protect another context. For example, sanitizing text to prevent XSS when you display in the context of a browser will not protect a site from SQL injection when the data is used in the context of a database query. The extremely flexible nature of Drupal requires that you use data in different contexts, so this architecture does not work for Drupal.

Safe data handling provides protection by using a means of interaction that separates the user data from the control statements. An example of this is using a parameterized query that contains no dynamic SQL. Parameterized queries were designed at a basic level to provide protection for mixing user data and command data. Safe data handling is useful where it is supported, but not all systems support it.

Boundary validation is the process of accepting all user input and then filtering it upon output depending on the nature of the boundary. Drupal relies primarily on the boundary validation pattern (see Figure 1-5).

The boundary

Figure 1-5 Boundary validation.

The boundary

Figure 1-5 Boundary validation.

In this diagram you can see the flow of a typical page-request cycle for creating a new blog entry on a site. The data flows are labeled 1 through 4 and described as follows:

1. The user has posted the form to the web server, which hands the data to Drupal. Drupal first makes semantic checks on the form data to ensure that the user hasn't tampered with the drop-downs, check boxes, and radio buttons in the form to, for example, create a blog post with a taxonomy term that is not allowed.

2. Drupal executes queries against the database to insert the user's blog entry for storage. At this phase Drupal is sending data beyond its boundary, so it must filter it to make sure that any characters inside the user data that may alter the impact of the SQL statements are ''escaped.'' The escaping is done in a context-sensitive manner. Since this is a database, the filtering is appropriate to SQL.

HIJ When interacting with other systems, certain characters have special meanings. In SQL, the single quote is used to separate string data from the rest of the statement. If a user has the last name O'Henry, then the single quote in the name could be misinterpreted. To handle these situations, SQL provides the slash escape character to allow the insertion of the single quote character into the database.

3. This is where Drupal retrieves data from the database. In general there are no concerns here, except that the system must remember which fields in the database are generated by the system (for example, sequential ID columns) and which are user-provided values that must be filtered.

4. The retrieved data is shown to the user. Because the data from step 3 includes some data from users, the data is filtered prior to being sent to the user's browser. Much like step 2, this filtering should be done in a context-sensitive manner that will work specifically for HTML data being sent via HTTP and rendered in the context of a browser.

These strategies for validating user data are used for different reasons in different areas. For example, Drupal rejects known bad data such as special characters in usernames because they are inappropriate for usernames. However, even after rejecting inappropriate characters, the query to insert that username into the database and the functions—which prepare the username for display to a browser—still perform boundary validation to filter the username in a way that is useful in that context.

SQL Injection

The Vulnerable module provides several examples of SQL injection. A simple example is available at the URL vulnerable/show-me-the-data/' UNION SELECT uid, pass, init FROM users where 1=1 OR 1 ='

Using the SQL UNION keyword, you can append data from a totally separate query into this page. In this example, you get the user ID, the MD5 (Message-Digest algorithm 5) hashed version of the password, and the email that was used when the account was created (stored in the init field). You can see the result of this modification in Figure 1-6, where in addition to the normal results you also see sensitive data like the hashed version of the password and email address. With the hashed password and email addresses of a user, an attacker can prey on the fact that most users use a limited number of passwords and try to use that password and email combination on commonly used websites.

HIJ Instead of just storing your password, Drupal stores a unique string that is derived from your password using a function. This is a one-way function, which means that you can take a password, send it through the function, and get the calculated hash value, but you cannot take a hash, reverse it through the function, and get the password. That said, the MD5 function used by many systems, including Drupal, is becoming increasingly unsafe given modern computer-processing capabilities. Therefore, you should still protect the MD5 hash of the password as if it were the password itself. In Drupal 7, the MD5 hash has been replaced with a more secure hash.

File Edit View History Bookmarks Tools Help

- 6 ©

^ http://crackingdrupal.com/vuln

erable/show-me

the-data/' UNION SELECT uid, pass, init FROM users where 1=1 > | » |

T

y

Cracking Drupal

_ Home

greg

Here is some data about our users

Code review

Information about users with 1 UNION SELECT uid, pass, init FROM users

where 1=1 OR 1 =' in their name

My account

.UID: 0 Name: Mail:

' Create content

UID

1 Name

greg Mall: [email protected]

1 Administer

UID

3 Name

sa_zfGQ9aHqPV Mail: [email protected],com

° Log out

UID

4 Name

tester Mail: [email protected]

UID

: 14 Name: asdf Mail: [email protected]

UID

: 15 Name: t2 Mail: [email protected]

UID

: 16 Name: t3 Mail: [email protected]

UID

: 17 Name: t4 Mall: [email protected]

UID

0 Name

5ebe2294ecd0e0f08eab7690d2a6ee69 Mail:

UID

1 Name

5ebe2294ecd0e0f08eab7690d2a6ee69 Mail: [email protected]

UID

3 Name

93d5bc097342016f96c2d7a41e3093d5 Mail:

UID

4 Name

912ec803b2ce49e4a541068d495ab570 Mail: [email protected],com

UID

: 1 4 Name: fia?04hdñflf.^r.ñS4ñafriFir.77r7T 7a097a Mail: asrif©asdfasdf

1 Done J

Figure 1-6 SQL injection is being used to show any data an attacker might want.

Figure 1-6 SQL injection is being used to show any data an attacker might want.

In this example, the union query could be used to get information about what other databases are on this server, the tables they contain, and the data in those tables. If you have an e-commerce site, donations database, or any private information such as email addresses or secret plans for world domination, an attacker would be able to use a hole like this to see that information.

Arbitrary File Upload

Another related problem is arbitrary file upload, which often leads to code execution. Drupal has many features and modules that allow users to upload a file. Within core alone, there are the Upload module, user avatars, the logo, and the favicon upload tool. Among contributed modules, there are dozens of ways to upload files: image, imagefield, filefield, embedded media field, video, and audio. Vulnerabilities in the code or configuration of any of these features could allow an attacker to upload an arbitrary file that contains PHP code, JavaScript, or another kind of code that can compromise the security of your site.

0 0

Post a comment