54
SQL Injection Attacks
on Steroids:
An Overview of SA Exploiter
By Scott White
SecureState LLC
Athletes sometimes turn to steroids to become best in their sport. What if computer hackers could do the same thing? SA Exploiter, an advanced SQL injection tool, supercharges traditional SQL injec-tion techniques to bypass previously well-known limitations in just 29 lines of code.
The term “SQL injection” dates back to 1998, while its first public use was in October, 2000 (Li-tchfield, 2005). From its history, it is obvious that the concept behind manipulating SQL queries via injection techniques is far from a new attack. Al-though the attack is well documented and has been around for quite some time, it is still extremely common, even taking the number two spot on
the OWASP Top Ten list published in 2007 (listed under “A2—Injection Flaws”) (Top 10, n.d). It is prevalent today, with new methods for misusing or abusing technologies to operate in an attacker’s favor constantly being developed.
As a former developer and now full-time penetra-tion tester, I am very familiar with techniques for attack, as well as trends in corporate America. I estimate that more than 80% of the time I per-form an external penetration test for a client, it is through a web application. From SQL injection alone, I estimate that 25% to 50% of the time I obtain a full remote compromise of the backend SQL server. When I find SQL injection where the
55 queries are executing under a limited security
context (as they should be), I estimate that 80% or more of the time the information gained from the attack is used to formulate other, more sophisticated attacks.
With such an astounding success rate, I have worked on perfecting my SQL injection skills. Whether it is blind, error-based or time-based, all techniques have proved fruitful. There are many different implementations of SQL. In my experi-ences as a professional penetration tester, Micro-soft’s SQL server is more common than any other database server. Besides being popular, special at-tacks against it can allow for full remote compro-mises, whereas other implementations will only allow for information disclosure.
There have been many tools created to specifi-cally aid SQL injection exploitation. Many of them are free, and some of them are attached to larger commercial products costing more than $25,000. Most people tend to lean towards the free tools since many are open source, and
there-fore free, but, as the saying goes, you get what you pay for. I’ve used many of the available tools, and most of them don’t work very well or they simply try too hard. By “try too hard,” I mean they try to automate everything into a point-and-click remote shell producing tool. I think this causes many tools to become miser-able failures, since they overlook the fundamental aspects of what is required to carry out a successful SQL injection attack. In order to get any SQL injec-tion attack to work, first and foremost, the logic must be correct or the query
will not execute. If we don’t achieve this very small task, our attack will fail every time. Second, we must have our syntax correct in order for the query to execute. There are special cases where we purposely would supply bad syntax to achieve de-sired results, but the attacker must first have been able to determine the correct syntax to carry out such an attack. For the aforementioned reasons, I am not a fan of point-and-click automated attacks with regard to SQL injection.
After many penetration tests in which I manually and quite carefully typed out SQL injection strings, I decided to write a tool to automate injection
string generation specifically targeting Microsoft SQL servers running under elevated privileges. This tool’s sole purpose was to create a syntacti-cally correct injection string to be used manually during penetration testing efforts. The injection string could be used in a query string, cookie, form parameter, etc. Part of the design of this tool is that the identification of SQL injection and the application of the string to the vulnerability’s environment are deliberately left up to the pen tester. This allows the user to have complete control over what the tool is doing. This tool went through about a year of development on the side as a small pet project and was released on August 10, 2008 at Defcon 16 under the name SA Exploiter.
With Microsoft’s implementation of SQL server, there exists an extended stored procedure named xp_cmdshell that spawns a Windows command shell and passes a string as an input argument for execution. The result is then returned as rows of text—xp_cmdshell—which is disabled by default for Microsoft SQL Server 2005 and later. This does not pose an issue since there are known ways through SQL injection to re-enable it.
Figure 1. xp_cmdshell command execution.
Basically, if SQL injection is present and queries are being run under excessive privileges (meaning that the current security context has access to xp_ cmdshell), operation system command execution is possible. Commands executed via xp_cmdshell are executed under the MSSQLSERVER service itself. When SQL Server is installed, by default it runs as Local System. This translates to NT AU-THORITY\SYSTEM via the whoami command. This account’s privilege level is higher than that of the local administrator.
There have been many tools created to
specifically aid SQL injection exploitation.
56
Figure 2. SQL Server service running as “Local System.”
From this, it is very clear that we have indirectly achieved a full system compromise. Script kid-dies and other casual hackers may have not even made it this far, but we are still far from finished. Naturally, our goal is to further penetrate into the system or network. With most SQL injection, we can enumerate databases, tables, columns and data values via error messages. However, it would be really helpful to have a direct command shell to the SQL server that we’ve compromised, rather than injecting some complicated string into a cookie value that is on Step 5 of a 5-step checkout process for an online shopping cart.
In order to achieve a reverse command shell or to be able to use other desired functionality, we need to be able to transfer files to the SQL server. This sounds easy, but proves to be very difficult in many situations. A logical option would be to use the Windows command line ftp client. This may work, provided that the compromised SQL server does not have its egress communications filtered or, even worse, the server may not even have internet access.
Figure 3. Compromised SQL Server may not have internet access.
Let’s assume our compromised SQL server does not have internet access, but we have a custom virus, worm or some other self-propagating executable that we want to deliver to the server. At this point, binary file transfer seems impossible. The script kiddies are long gone, 90% of the casual hackers have given up and I still want my way with the SQL server. Fortunately, a built-in Wbuilt-indows command lbuilt-ine tool saves the day. Welcome Windows debug. Windows debug can take a hexadeci-mal representation of a binary file and “compile” or “assemble” it (we’ll use those terms loosely) into its original state (“Debug (com-mand),” 2008). It is possible to use the Windows echo command to echo a binary file’s hex repre-sentation into a text file on the SQL server’s hard disk, and then use debug to recreate it as a binary. From there, executing it is trivial. There are pro-grams freely available on the internet to create hex representations of binary files in “debug format” so that it will work correctly. An example of this would be dbgtool (“Dbgtool,” 2008).
Using this technique to achieve file transfer is well known for those well versed in SQL injection and advanced penetration testing; however, it has one major flaw. Since debug runs at a 16-bit process level, it is limited to files of 65,280 bytes or less (Sedory, 2007). This has been a well known limi-tation with debug and using it as a means for file transfer. Although this limitation is not that big of a deal to advanced hackers, it poses a problem if it is going to be used extensively. Granted, if you are a good hacker, you will author your own tools and make them as small as possible without the need for “script kiddie” tools that are often bloated with known antivirus signatures. It is quite triv-ial to write custom portable executables that are under 64KiB and bypass most an-tivirus software. Since no one can be good at everything (writing x86 assembly code, being a web application security expert, SQL server guru, etc.), I chose to pursue the challenge of breaking the 64KiB size barrier of Windows debug.
On setting out to complete this feat, SA Exploiter began to draw the curiosity of co-workers who develop custom tools as well. Being an ethical hacker, I had re-quirements that crackers (i.e., malicious hackers) would not follow. The requirements of my tool were to be the following:
57 1. The file size limitation of 64KiB must be sur-
passed.
2. The file transfer must not rely on egress connections of the compromised SQL server:
• All reverse shells, if supported, must not
have prior egress connections.
• The first egress connection must be the
reverse shell.
3. Data in the SQL server database(s) must not be modified:
• Do not create, modify, or drop databases,
tables, or data.
• I must respect production data of my clients
and not disturb its integrity. 4. The tool must be easy to use.
5. The tool must allow for custom portable executables to be used.
6. The tool must allow for copy/paste of Metasploit shellcode to be used.
7. The tool must clean up after itself as much as possible.
Obviously, I was rather tough on myself as far as requirements for features and limitations. An early attempt involved translation entirely in the com-promised SQL server’s memory. This proved to be quite difficult, as there were many limitations with SQL Server, most notably the maximum length of a string literal being 8,000 characters.
After almost a year of frustration and dead ends, my solution came in the form of a 29-line custom command line executable sizing in at only 5KB! My program simply reads a text file of hex as input, converts it at a byte level to binary and writes it back out to recreate the original file. First, I would use Windows debug to transfer my 5kb program, h2b.exe (short for hex to bin) to the SQL server.
Next, I use SQL injection to echo as much hex as I’d like into a text file. The echo command creates carriage returns and newlines at the end of each
line. Remember our 8,000 character string literal limitation in SQL server, so we must echo multiple times. During h2b.exe’s execution, it also must removing all carriage returns and newlines (\r\n) left by echo before writing its contents back to disk in binary. For such a well known limitation, who would have known that the solution was so trivial?
Figure 4. h2b.exe
Figure 5. h2b.exe recreating netcat from hex.
Once the 64KiB limitation was bypassed, the use of Metasploit shellcode and custom por-table execupor-tables must be supported. This was quite trivial since all that needed to be done was to read in a binary file and spit out its ASCII hex representation. This is just opposite of the h2b. exe tool. Additionally, a simple exe “wrapper” or “stub” was used to carry Metasploit shellcode. The Metasploit Project allows for custom porta-ble executaporta-bles to be created through the use of the msfpayload option (“Metasploit Framework User Guide,” n.d.). Other trivial methods exist to obtain hex from a binary file such as using Reed Arvin’s DumpHex tool (n.d.) or ANSI C’s printf (“%X”, s); statement.
After many lines of code that were written and rewritten, SA Exploiter became something that was going to be used more than internally by my testing team and had a real value to the pen-etration testing community at large. In the end, all
requirements were met, even un-der stringent development rules to keep things non-malicious and ethical.
SA Exploiter is available for download to penetration testers and ethical individuals at http://www.securestate. com/Pages/SA-Exploiter.aspx. A video show-ing its ease of use in compromisshow-ing a back-end
After almost a year of frustration and
dead ends, my solution came in the form
of a 29-line custom command line
58
SQL server via a vulnerable web application and Metasploit shellcode can be viewed at http:// www.securestate.com/files/SA_Exploiter/def-con_16_video.html.
Figure 6. SA Exploiter.
A sample walkthrough of an attack after finding SQL injection with elevated privileges may go something like what is depicted in Figures 7-14:
Figure 7. Generate Metasploit shellcode.
Figure 8. Copy Metasploit shellcode.
Figure 9. Paste Metasploit shellcode.
Figure 10. Choose “Format Metasploit Shellcode” button.
Figure 11. Choose “Generate” button. Pre-formatted SQL injection string—send on its way and wait for the magic!
59 References
Arvin, R. (n.d.). Security Tools. Retrieved ber 17, 2008 from http://reedarvin.thearvins. com/tools.html
Dbgtool. (n.d.). Welcome to the crypt of tools long forgotten... Retrieved September 24, 2008 from http://www.toolcrypt.org/tools/dbgtool/in dex.html
Debug(command). (2008, August 3). Retrieved tember 24, 2008 from http://en.wikipedia. org/wiki/DEBUG_(DOS_Command) Litchfield, D. (2005). SQL Injection and Data Mining through Inference. Retrieved September 17, 2008 from http://www.blackhat.com/presenta- tions/bh-europe-05/bh-eu-05-litchfield.pdf Metasploit Framework User Guide. (n.d.). User Guide for Metasploit 3.1 [manual]. Retrieved September 21, 2008 from http:// www.metasploit.com/documents/users_ guide.pdf
Sedory, D. B. (2007). A Guide to DEBUG. Retrieved September 24, 2008 from http://mirror.href. com/thestarman/asm/debug/debug.htm
Top 10 2007. (n.d.). Retrieved June 2, 2009, from OWASP: http://www.owasp.org/index.php/ Top_10_2007
xp_cmdshell (Transact-SQL). (n.d.). Retrieved tember 24, 2008 from http://msdn.microsoft. com/en-us/library/ms175046.aspx
About the Author
Scott White is a Senior Penetration Tester for Se-cureState LLC, a pure play information security assessment company based in Cleveland, Ohio. He is the web application security expert on the Profiling team. His day-to-day duties include but are not limited to black box assessments; grey box web application security assessments; source code reviews; internal, external and physical penetra-tion tests; and developer training. Scott holds a Bachelor of Science in Computer Science degree from Ohio Northern University and a Master of Science in Network Security from the University of Advancing Technology. Scott’s experience (over 5 years working with security, over 10 years pro-gramming experience) has given him a thorough web application security understanding from both the developer and attacker viewpoints. He has spo-ken at Defcon and has also been called on by or-ganizations such as the FBI and Secret Service as a subject matter expert.
Figure 12. Choose custom portable executable.
Figure 14. Choose “Generate” button. Pre-formatted SQL injection string—send on its way and wait for the magic! Figure 13. netcat as hex.
