In response to the *not so* recent Mass SQL Injection Attacks from earlier this year, which targeted mainly pre-ASP.NET 2.0 code, Microsoft has released an advisory revealing 2 new Microsoft products (URLScan 3.0 and Microsoft Source Code Analyzer for SQL Injection) and a partnership with HP for their new free ASP-only SQL Injection scanner named Scrawler

I had a chance to review Scrawler and the SQL Injection Source Code Scanner and was largely unimpressed. Scrawler has some limitations and only analyzes ASP.NET code, and has limited page crawling capabilities. It also handles no FORM variables, no Cookies, no header modification and will not work on sites requiring authentication–so it’s by and large useless in *most circumstances*.

The Microsoft Source Code Analyzer for SQL Injection is also somewhat limited in that it only reviews ASP source code, but this is a massive improvement to the previously-available tools provided by Microsoft to help ASP developers identify potential problem areas in their code, where URL and user-supplied input is concerned. Any ASP developer should grab this and run it on their own source code.

As far as URLScan 3.0 goes, I have always been a fan of this *crucial* IIS add-on. Although it is based on a “blacklist” logic model, it can be useful for forbidding at least very common URL strings that may be used in a SQL Injection, or XSS attack. Not to mention that one of the most common security issues I still run across with IIS installations are poorly configured Web Server Extension such as FrontPage and WebDAV, which this tool will quash by default.

The beta version of this tool can be found here.

So although these tools are far from perfect and don’t even come close to meeting the needs of professional web application security testers, this is certainly a good set of tools (at least the latter 2) for ASP.NET developers who would like the get the leg up on their auditors.

A recent post came through the WASC mailing list today from Carlos Bueno regarding this topic. The basic gist is in the impact of utilizing the browser-supplied Host headers as a means for link consistency in programming your web code.

For example, assume the page ‘urltest.php’ contained the following

$host = $_SERVER['HTTP_HOST'];
$filename = $_SERVER["REQUEST_URI"];
echo 'http://'.$host.$filename;


Although a simple example, imagine using this variable as the root of any “a href” links you may want to make (by the way, it seems to be the default for PHP5 installations I’ve tested)

The problem lies in the ability for an attacker to arbitrarily change the Host: header information when talking to your web server. For example:

nc www.target.com 80
GET /urltest.php HTTP/1.1
User-Agent: Mozilla
Host: evilhacker.com#

which results in the following HTML output from the server

HTTP/1.1 200 OK
Date: Thu, 12 Jun 2008 19:42:23 GMT
Server: Apache
X-Powered-By: PHP/5.1.6
Content-Length: 41
Connection: close
Content-Type: text/html; charset=UTF-8
http://evilhacker.com#/urltest.php

…returning the invalid Host header in our echo statement which was provided by the attacker.

The theoretical problem here lies in the ability in certain isolated situations to poison the server’s cache or poison an upstream proxy cache, which could mean an attacker could redirect links or other content embedded in the attacked site, while other users browse the vulnerable page….

I actually verified this in a couple of instances today on some real servers and it works, but while going through my Squid Proxy (in an attempt to capitalize on the cache-poisoning issue), Squid properly returned the valid host headers, even when I cleared the cache, so this is probably a very low-risk attack from a proxy cache-poisoning perspective, but I bet the method has other uses (we already do similar things when attempting HTTP Response-Splitting)

In shared hosting environments, it is possible to use this attack to force your browser to grab resources from another virtual host on the same server. I tested this on a shared server with 2 known virtual hosts, and found that by inserting an initial “Host:” variable referencing another host in my shared server, all subsequent calls would reference resources on the other domain (for example includes and images) where full paths where not used in the source code.

For example:

include 'file.php'

Would attempt to load the file ‘file.php’ from the forged host header running on the same machine…

I tested this on an Apache2/PHP5 installation running on Linux with 2 virtual host defs….works every time…I can swap include files for my own to run my own content…

If you have a web server on a shared (i.e. virtual) environment, you are at risk

Shameless and sweet, I have designed a maternity line based on this:

To order one of these for your favorite pregger, check out my Cafe Press Site

Thanks for your support!

It never ceases to amaze me to find legacy Citrix implementations out there, but it happens (often).

A common mis-conception in years past was that Citrix was a secure remote access solution. Although more current versions of the architecture may indeed be more secure, it is certainly no replacement for a true secure remote access solution, such as IPSec or SSL VPNs.

At any rate, while auditing a client recently, I ran across a legacy implementation of Citrix (again), and thought it worth posting about should anyone stumble upon this site.

One of the best articles ever written on hacking Citrix was written by sh0dan back at the turn of the century, last modified here back in 2003.

It is a great reference for legacy versions of Citrix, and I will be having an in-depth conversation with my client about this in the days to come.

A more recent reference to hacking Citrix is from GNUCITIZEN and can be found here

This is a list of the Top 5 FREE SQL Injection tools currently available. Although there is already a list of the Top 15 Free SQL Injection Scanners, not all of them deserve the honors of the best general-purpose tools.

Not all of the Top 5 tools here work on all target databases, nor are they all “scanners”, but they all deserve their place on this list for various reasons.

Listed in order from THE best down (IMHO):

1. Pangolin
2. Absinthe
3. SQL Ninja
4. Automagical SQL
5. SQLMap

Not all of these tools provide the same functionality, but I have found that with these tools, I need look no-where else. If you’re interested in others, check the referenced list in the link above, and enjoy

Otherwise, for a detailed breakdown of the tools’ features, functionalities and how-to documents click here (registered users only)

Donwalrus (a.k.a. Michael Menefee) is the President and Co-founder of WireHead Security, an Internet Security Consulting firm focused on education and training.

Michael’s career has spanned over 14 years in the Information Security arena. Spending most of his time tearing apart other people’s networks and helping them to better secure them, Michael is also a the President of the North Carolina OWASP Chapter and a contributor to WASC and a frequent blogger on CIOZone.com.

Aside from his “auditing” experience, Michael has also developed several managed security services in his career, including an automated penetration testing framework, anti-spam/virus email relay service and a hosted IDS/IPS platform.

Several weeks ago I stumbled on a client’s e-commerce site that had (what appeared to be) a non-vulnerable SQL Injection pathway on a search form. I used the standard calls to determine if it was vulnerable, determined (or so I thought) that it wasn’t and moved on to test for XSS.

While testing for XSS with the de-facto

alert('xss')
script that we all know and love, turns out the vulnerable field was in fact prone to SQL Injection (I just had to mod my testing methods a little bit).

Throughout the course of running the concept of utilizing XSS to perform SQL Injection past colleagues and other forums, it quickly became apparent that the biggest use would be in targeting sites with known persistent XSS vectors, to amass a distributed SQL Injection attack towards a vulnerable 3rd party system.

So, why is this important? Well, there are many SQL Injection automated tools (many listed in my Pen Testing Tools section) that can perform brutal SQL Injection attacks, but can be traceable by source IP address. You could run through a series of proxies, but that too is eventually traceable.

This means that a potentially insignificant XSS on your website/portal could be used as a launching point via Javascript to perform an unwitting SQL Injection attack against a third party…all the more reason to close even those tiny XSS flaws in your site

- Donwalrus

A good old-fashioned method of breaking into accounts on web apps is still brute-force. Although many commercial and in-house (custom) applications are subject to authentication bypass through various means, there is no substitute for a known list of usernames and the human propensity for poorly-chosen passwords. In an age of single-sign-on (especially in the corporate world) finding a list of potential usernames is surprisingly still very easy–thanks Google!

One of the methods I’ve been using for quite some time to pull a potential list of valid accounts is using some Advanced Google searching techniques to find email addresses for a target domain. Email addresses almost always relate to a username in some capacity, and Google, Yahoo and MSN (just to name a few common ones) make it so easy to find.

You can find my bash script here. My perl script is soon to follow…

For example, with Google, try this for your organization: Search for ‘*@mydomain.com’ where ‘mydomain.com’ is your domain, and Google readily produces a list of pages on the Internet with email addresses for ‘mydomain.com’ highlighted in bold….you know how easy that is to script to search through thousands of search results? Well, trust me, it’s easy.

So how can the average organization protect against this? There’s a couple of ways (some which don’t work in all situations) which we will now discuss:

1st — To protect your own website(s) from giving up your user IDs, protect them from Google caching. This can be accomplished using a robots.txt in your web server’s virtual root directory. I will post more on this subject later, with some specific guidelines, but be careful with this file–anything you configure here is world-readable by anyone, and you could block your site from ever coming up on search engines.

2nd — Make it clear to your internal users that their corporate email addresses are not for personal use. You can monitor this activity with custom Google Alerts to see when your users post their ‘mydomain.com’ email address on 3rd party sites (more on this later as well–it’s not as good as it used to be, but can be handy in certain situations)

3rd — Don’t default into using your AD or LDAP “username” to generate your employees’ email addresses–figure out some other delineation. Since it’s usually easier to have your email addresses be something simple like ‘firstinitiallastname’, make your user IDs different (or vice-versa if you’re a sadist).

At any rate, the bottom line of this discussion is that users choose poor passwords. Windows 2003 still doesn’t provide a good enforcement mechanism (so 80% of us have few options), eDirectory is even worse, and enforcing really strong usernames with most poorly-funded IT departments is always difficult….

In my opinion a simple way to thwart this is not to give up your usernames….any thoughts?

This will eventually be my own cheat-sheet, but for the meantime, check Here

This is will eventually be my SQL Injection Cheat Sheet

For the meantime, check Here …not the best resource in the world, but a placeholder for the meantime