This chapter is from the book
This chapter is from the book
This chapter is from the book
Initial Compromise
To execute the first step of the attack—initial compromise—the 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.
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.