Injection Attacks Executing, Preventing, and Auditing

Injection AttacksExecuting, Preventing, and Auditing Presentation by Michael Pinch Matthew Giordano January 26th, 2007

What is an Injection Attack? • Exploits weak application level security around the “system” type ID • Exploit allows the client, a.k.a. attacker, to “piggyback” code into a web page, and have the “system” ID execute it for them • Can both execute commands and insert / update / delete data

What is the Danger? • Typically “system” IDs have “all access” rights to the database • When exploited, the attacker can do anything the “system” ID can • Utilizes no special equipment or advanced knowledge

Industry • Joint study by the US department of Commerce and Visa • Ranked as one of the top 5 greatest data security vulnerabilities • “SQL injection is a technique used to exploit Web-based applications by using client-supplied data in SQL queries. SQL injection attacks are caused primarily by applications that lack input validation checks. Recently, commercial shopping cart products have been the focus of attack by hackers who seek account information. PCI DSS Requirement 6.5 requires that Web-facing applications be developed in accordance with secure coding guidelines to guard against such attacks. “

Different Types of Code Injection • SQL Injection (Most prevalent) • LDAP Injection • XML Injection • Others… * Flaw is not code specific, rather in the web application it is embedded in

Structure of Web Based Systems • Application logic– Typically built with a scripting language (php, jsp, asp), a lightweight tool that interfaces with the data source and controls the behavior of the program • Data Source – Typically a database, but could also be a flat file, XML file, or another application • The interface between the application and data source is typically done with an embedded language. Embedded systems integrate one type of code into another (such as a php script executing SQL commands)

How does it work? • Review on Client-Server Architecture • You (client) request a web page • Server responds with the page, as displayed on the client computer • Client enters data • Server takes data, runs server side script, queries database, returns results

What really happens when you search? • Server has a prewritten SQL query stored in a script • select item, picture, from ItemDB where description = ‘$client_input’; • You input “american psycho 1st” • Prewritten script is then executed by “system” as : • select item, picture, from ItemDB where description = “american psycho 1st”; • Please Note: You just used the “system” ID to execute a query that YOU wrote. In practice, most “system” ID’s have DBA level access, and are only restricted by the logic built into the application itself.

This is the Danger! A direct link between the client and the all powerful “system” ID!

Code Example • <?PHP • session_start(); • header("Cache-control: private"); // IE 6 Fix. • error_reporting(E_ALL); • ?> • <html> • <body bgcolor = white> • <?php • $email = $_SESSION['email']; // Variable holding user’s email address • $value = stripslashes($_POST['newdata']); // Variable holding data entered • $fieldname = $_POST['type']; // Variable holding fieldname to update • if ($_SESSION['access_rights'] == 1) • { • $db = mysql_connect("localhost", "system_id", “password"); // Connects to local DB • mysql_select_db("payroll",$db); // selects database to query • $query = "update data SET $fieldname='$value' WHERE email = '$email'"; // Prewritten Query • $result = mysql_query($query,$db); // executes query • echo "<META HTTP-EQUIV='Refresh' CONTENT='0; URL=return.php'>"; • } • ?>

How can we exploit this? • SQL Query Stored in Application: select item, picture, from ItemDB where description = ‘$client_input’ • To commit a SQL Injection Attack, enter into the web site form: x‘;drop table ‘ItemDB The query executed by the “System” ID will now be: select item, picture, from ItemDB where description = ‘x‘;drop table ‘ItemDB’ • The server just executed the stored query, and we just effectively destroyed the entire “ItemDB” database!

Even More Fun… • “Add A New User” • Canned Query: SELECT email, passwd, login_id, full_name FROM members WHERE email = ‘$user_input’; • SQL Attack: x'; INSERT INTO members ('email', 'passwd', 'login_id', 'full_name') VALUES (‘mike@pinch.com',‘mynewPW',‘pinch',‘Mike Pinch') • System then Executes: SELECT email, passwd, login_id, full_name FROM members WHERE email = ‘x'; INSERT INTO members ('email', 'passwd', 'login_id', 'full_name') VALUES (‘mike@pinch.com',‘mynewPW',‘pinch',‘Mike Pinch'); • I now have my very own account!

One More for Good Measure • “Forgot my Password” • Canned Query: SELECT email, passwd, login_id, full_name FROM members WHERE email = ‘$UserInput’; • SQL Attack: x'; UPDATE members SET email = ‘pinch@CLIENTX.com' WHERE email = ‘sysadmin@CLIENTX.com • System then Executes: SELECT email, passwd, login_id, full_name FROM members WHERE email = x'; UPDATE members SET email = ‘pinch@CLIENTX.com' WHERE email = ‘sysadmin@CLIENTX.com • Now just go to forgot my password, type pinch@CLIENTX.com, and the system will conveniently email me the system admin’s password!

Halftime Discussion • Does anyone have any questions about HOW this attack works, why it is possible, or anything else?

Is this as easy as it looks? • Requires knowledge of the DB schema • Work Around • Standard DB error messages return information about DB schema • Enter bad data -> get error messages! • Programmers use descriptive table names

Bad Good Error Message Masking

Error Masking • Blocks real error messages from being displayed to the client • Best Practice • All specific errors messages are suppressed, either through using a generic error message, or blocking them altogether.

How are Attacks Prevented? • Sanitize all input including: • Data collected in Forms through browsers • Data collected in URL’s • Data collected through cookies • White/Black List • Mask Error Messages • Continuous Monitoring • New Technique: SQL Firewalls

Prevalence of Attacks • Injection attacks are extremely powerful, almost always malicious, and nearly undetectable (until its too late) • Danger comes from simplicity – no special hardware or software is necessary. Just syntax knowledge and a browser! • In 2006, 14% of newly released commercial application and open source tools were vulnerable to SQL injection attacks. • A recent study of web sites not masking error messages returned a total of 10.3%

Weak controls related to preventing injection attacks may require nature, timing and extent of financial statement substantive audit procedures. Assistance may be needed from systems or data management professionals to help identify if there were instances in which the control weaknesses were exploited. Cobit Framework (See excerpt) DS 5.3, Identity Management Cobit Framework DS 5.3, Identity Management “All users (internal, external and temporary) and their activity on IT systems (business application, system operation, development and maintenance) should be uniquely identifiable. User access rights to systems and data should be in line with defined and documented business needs and job requirements. User access rights are requested by user management, approved by system owner and implemented by the security-responsible person. User identities and access rights are maintained in a central repository. Cost-effective technical and procedural measures are deployed and kept current to establish user identification, implement authentication and enforce access rights.” Integrating into the Audit

What Systems are Vulnerable? • Predominantly internally developed applications • Web based client-server architecture • Any system where access is available via the web

How do you determine if a system is vulnerable? • Inquire • Do you have database and server error messages masked? • Do you have a strategy to sanitize all user input to detect SQL injection attacks? • Walk me through how your system prevents SQL injection attempts, IE filtering input, limiting rights. • Observe • Ask client to generate an error message • Should either be generic or non-existent • Inspect • Request code sample showing filtering module logic • Should filter out suspicious characters such as “’,/;&%$” etc • View White/Black List • Attack and Penetration Testing

Demonstration

Questions / Comments • Open Discussion • References • http://www.sarbanes-oxley.com/section.php?level=1&pub_id=Sarbanes-Oxley • http://usa.visa.com/download/business/accepting_visa/ops_risk_management/Top_5_Vulnerabilities_Bulletin_August2006.pdf - 2006 Visa USA • "Applying an improved economic model to software buy-versus-build decisions", Higaki,Wesley. Hewlett-Packard Journal, August 1995. • "Cobit 4.0", IT Governance Institute, 2005 • Mitre Corporation, 2006

Injection Attacks Executing, Preventing, and Auditing