SQL Injection Attacks on Steroids:

Transcription

1 SQL Injection Attacks on Steroids: An Overview of SA Exploiter By Scott White SecureState LLC 54 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 injection 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 (Litchfield, 2005). From its history, it is obvious that the concept behind manipulating SQL queries via injection techniques is far from a new attack. Although 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 penetration 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 perform 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

2 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. There have been many tools created to specifically aid SQL injection exploitation. 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 experiences as a professional penetration tester, Microsoft s SQL server is more common than any other database server. Besides being popular, special attacks against it can allow for full remote compromises, whereas other implementations will only allow for information disclosure. There have been many tools created to specifically 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 therefore 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-andclick remote shell producing tool. I think this causes many tools to become miserable 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 injection 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 desired 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 syntactically 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. 55

3 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 kiddies 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 builtin Windows command line tool saves the day. Welcome Windows debug. Windows debug can take a hexadecimal representation of a binary file and compile or assemble it (we ll use those terms loosely) into its original state ( Debug (command), 2008). It is possible to use the Windows echo command to echo a binary file s hex representation 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 programs 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 limitation 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 trivial to write custom portable executables that are under 64KiB and bypass most antivirus 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 requirements that crackers (i.e., malicious hackers) would not follow. The requirements of my tool were to be the following:

4 1. The file size limitation of 64KiB must be surpassed. 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. 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? 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. Figure 4. h2b.exe 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 compromised 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. 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! 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 Figure 5. h2b.exe recreating netcat from hex. Once the 64KiB limitation was bypassed, the use of Metasploit shellcode and custom portable executables 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 portable executables 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 pen-testing team and had a real value to the penetration testing community at large. In the end, all requirements were met, even under stringent development rules to keep things non-malicious and ethical. SA Exploiter is available for download to penetration testers and ethical individuals at com/pages/sa-exploiter.aspx. A video showing its ease of use in compromising a back-end 57

5 SQL server via a vulnerable web application and Metasploit shellcode can be viewed at Figure 9. Paste Metasploit shellcode. 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: 58 Figure 10. Choose Format Metasploit Shellcode button. Figure 7. Generate Metasploit shellcode. Figure 8. Copy Metasploit shellcode. Figure 11. Choose Generate button. Pre-formatted SQL injection string send on its way and wait for the magic!

6 References Arvin, R. (n.d.). Security Tools. Retrieved September 17, 2008 from com/tools.html Dbgtool. (n.d.). Welcome to the crypt of tools long forgotten... Retrieved September 24, 2008 from dex.html Debug(command). (2008, August 3). Retrieved September 24, 2008 from org/wiki/debug_(dos_command) Figure 12. Choose custom portable executable. Litchfield, D. (2005). SQL Injection and Data Mining through Inference. Retrieved September 17, 2008 from Metasploit Framework User Guide. (n.d.). User Guide for Metasploit 3.1 [manual]. Retrieved September 21, 2008 from guide.pdf Sedory, D. B. (2007). A Guide to DEBUG. Retrieved September 24, 2008 from com/thestarman/asm/debug/debug.htm Top (n.d.). Retrieved June 2, 2009, from OWASP: Top_10_ xp_cmdshell (Transact-SQL). (n.d.). Retrieved September 24, 2008 from com/en-us/library/ms aspx Figure 13. netcat as hex. Figure 14. Choose Generate button. Pre-formatted SQL injection string send on its way and wait for the magic! About the Author Scott White is a Senior Penetration Tester for SecureState 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 penetration 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 programming experience) has given him a thorough web application security understanding from both the developer and attacker viewpoints. He has spoken at Defcon and has also been called on by organizations such as the FBI and Secret Service as a subject matter expert.