Initial Compromise

Initial Compromise

To execute the first step of the attackinitial compromisethe attacker has to evaluate what is exposed. The objective of initial compromise is to obtain a foothold on the network that can be expanded later. The only thing exposed on this network is a Web site, and an open port on which nothing is listening. That leaves us with the Web page as the only ingress. Figure 2-3 shows the Web server home page.

Figure 2-3. Victimsrus.com home page.

From this screen, you learn two things. First, we are not graphic designers, OK? If you want cool graphics, pick up another book. If you want network attacks, and more importantly, protection, keep going. Second, this is obviously an ordering site of some kind. Let's use a legitimate account to find out more.

We now get a page (Figure 2-4) that welcomes us to the Pubs bookstore and lists books for sale. We also note that the page displays our username. This could come in handy if they are not careful because we can use it to validate certain other techniques. For example, very often Web sites like this use a pretty poor algorithm for checking whether you had the right username or password. We are also curious whether they are properly validating the input from the username and password fields. To find out for sure, we are going to utilize a technique called "SQL injection." SQL injection makes use of poor coding techniques. In an SQL injection attack, an attacker passes input to the application, which it in turn passes on as unvalidated data to the database management system (DBMS). The DBMS, however, interprets this data as legitimate instructions. The net result is that the attacker can rewrite the query run by the DBMS and therefore alter the instructions the DBMS will execute. For more information on how SQL injection works, see Chapter 16.

Figure 2-4. The main order page.

To verify the existence of an SQL injection vulnerability, we pass "foo' OR 1=1;--" in the Username field. This gets us the result shown in Figure 2-5.

Figure 2-5. An example of SQL injection (and cross-site scripting) at work.

In Figure 2-5, we see that not only do we get logged on, but the application also displayed the fake username we sent it on the home page. This latter artifact is actually a separate type of vulnerability known as a cross-site scripting (XSS) vulnerability, where the user input is echoed directly to the screen without sanitizing it first. We will not use it in the following attack, but it is interesting to note that it is there.

NOTE: For more information on XSS, refer to Writing Secure Code , 2nd Edition; Howard and LeBlanc, Microsoft Press, 2003.

However, more curiously, how come we were logged on? Is there a user called "foo' OR 1=1;--" . No, there is no such user. The app is just very poorly written. In Chapter 16, we look at the actual code. For now, all we need to know is that it makes the assumption that if any results came back from the database when it asked for a user with a particular password, the username and password combination was obviously valid, and therefore it should log on this user. We effectively rewrote the database query, through an SQL injection attack, to include the statement OR 1=1 . Because 1 is always equal to 1, this evaluates to true, which means the entire query evaluates to true, for all records in the database. This will return every user account in the database, which means the application thought we were logged on.

We can use this SQL injection vulnerability to send arbitrary commands to the back-end database server. We are going to use that in an elevation-of-privilege attack to get the database server to run commands for us.

NOTE: An SQL injection vulnerability is not a vulnerability in the DBMS. It is a vulnerability in the application accessing the DBMS. The DBMS is doing exactly what it should be doing, which is to evaluate and execute the statements sent to it and return the result to the caller. Moreover, this is not an issue specific to Microsoft SQL Server. Because the vulnerability is in the front-end application, SQL injection attacks can be perpetrated with any database. The attacker just needs to modify the exploit to match the syntax required and functionality presented by the particular DBMS in use at the target.