A vulnerability that I have interacted with in the wild and have had to intentionally avoid myself is the venerable SQL injection. In a sentence, SQL injections are vulnerabilities where input is improperly combined with commands in a way where the input can be interpreted as SQL statements (Vacca, 2009). The obvious exploit for passing arbitrary commands to a database is to read additional data, which is available to attackers targeting a SQL injection. Additionally, if the running account has write access, it can also be used to corrupt the integrity of the database, even going so far as to erase data, as was captured in the classic XKCD comic about Little Bobby Tables (Munroe, 2007).
The danger from exposing a SQL injection goes far beyond letting users read extra data or destroy some, though. Halfond, Viegas, and Orso enumerate a whole set of possible attacker intentions that can be realized through SQL injections: database finger-printing, learning the database schema, extracting data, changing or inserting data, causing denial of service, avoiding detection, skipping traditional authentication, elevating privileges, and command execution (2006). Some of these can be really easy, such as finger-printing the database in use: when first stumbling on the injection an error may be dumped to output containing the database version, query ran, software name, operating system, and more. (Halfond et al., 2006)
In a Black Hat Briefing, Guimarães describes some of the really nasty and unexpected things that attackers can accomplish through SQL queries. MySQL can use the LOAD_FILE function to read an arbitrary file on disk, allowing the extraction of sensitive data that isn’t even in the targeted database (Guimarães, 2009). MS SQL Server and PostgresSQL also have commands that can be used to extract arbitrary files. MySQL allows for the INTO DUMPFILE clause to write to arbitrary files, as can the PostgresSQL lo_export() function (Guimarães, 2009).
Even though arbitrary read/write to the remote system is nearly enough to fully own the target, SQL injections can provide even more access. MS SQL Server allows the importing of user defined functions from DLLs with CREATE ASSEMBLY (Patel, 2010). Being able to load an executable into the remote database process, combined with the previously mentioned ability to write the desired executable to the system, is total access to the level of the database account. It literally allows you to run anything you can write. Finally taking the cake, MS SQL Server even provides an xp_cmdshell() stored procedure to provide raw shell command execution (Guimarães, 2009). Game over.
Guimarães, B. D. A. (2009). Advanced SQL injection to operating system full control. Black Hat Europe, white paper.
Halfond, W. G., Viegas, J., & Orso, A. (2006, March). A classification of SQL-injection attacks and countermeasures. In Proceedings of the IEEE International Symposium on Secure Software Engineering (Vol. 1, pp. 13-15). IEEE.
Munroe, R. (2007, October 10). Exploits of a Mom. XKCD. Retrieved from https://xkcd.com/327/
Patel, V. (2010, September 27). Creating User-Defined Functions in Microsoft SQL Server
. Database Journal. Retrieved from http://www.databasejournal.com/features/mssql/article.php/3904491/Creating-User-Defined-Functions-in-Microsoft-SQL-Server.htm
Vacca, J. R. (2009). Computer and Information Security Handbook. Burlington, MA: Morgan Kaufman
No comments:
Post a Comment