What I really want to know is this: Where are the Database Admins (DBAs) these days?

I cant tell you how many times in the past 18 months that I’ve found real enterprises running vulnerable databases with default passwords, weak passwords and no real permissions management.

It’s bad enough that the stats right now are this (so I guess I can tell you):

• 9 out of 10 organizations have a Microsoft SQL Database with a blank “sa” password (or an sa password of “sa”, “sql” or “password”)
• 9 out of 10 organizations have a Postgres Database with a default password
• 9 out of 10 organizations have a Sybase Database with a default password
• Several default Microsoft SQL Server 2000 Installations–do you remember SQL Slammer/Saphire??? Yup…still out there
• Oracle Listener services not requiring authentication–this means anyone with network access can shutdown the DB server
• Common practice of NOT patching a DB server, or deploying anti-virus…for Microsoft SQL Servers, exploit an unpatched Windows vuln and “poof”–get a terminal services session and you’ve got full control of the database (or fall prey to Slammer 7 years after the fact)
• No defined DBA position–application developers or system admins are the DB admins…no wonder why I see this so often
• Storing passwords unencrypted–I’ve seen this in MAJOR software vendors’ DB implementations

This is just the short list, but with all of the other ways to get access to a database through the applications connected to it, why has the industry at large neglected the baseline security parameters of database administration? Is being a DBA just not sexy enough these days? Is there a shortage of qualified DBAs? Can most organizations even afford a good DBA?

Forget the whole database optimization/normalization value of employing a DBA, but the security implications of leaving DBA tasks in the hands of developers and engineers is massive.

Am I the only one seeing this, or can you relate?

We went over some of these tools at the latest North Carolina OWASP Meeting, so I thought I’d make this list available here. Enjoy!

Proxy Servers:
WebScarab: http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project#Download
Burp: http://www.portswigger.net/suite/download.html
Paros: http://www.parosproxy.org/download.shtml

Firefox Plugins:
Tamper Data: https://addons.mozilla.org/en-US/firefox/addon/966
NoScript: http://noscript.net/getit
ShowIP: https://addons.mozilla.org/en-US/firefox/addon/590
SwitchProxy: https://addons.mozilla.org/en-US/firefox/addon/125
SQL Inject Me: https://addons.mozilla.org/en-US/firefox/addon/7597
XSS Me: https://addons.mozilla.org/en-US/firefox/addon/7598
ViewStatePeeker: https://addons.mozilla.org/en-US/firefox/addon/7167

Many of these are included in a single plugin distribution here: https://addons.mozilla.org/en-US/firefox/collection/webappsec

Some SQL Injection Tools we Discussed:

SQLMap: http://sqlmap.sourceforge.net/
SQLNinja: http://sqlninja.sourceforge.net/
Pangolin: http://www.nosec.org/en/pangolin.html

Test Applications that wont land you in Prison:
WebGoat: http://sourceforge.net/project/showfiles.php?group_id=64424&package_id=61824&release_id=613045
Hacme Series: http://www.foundstone.com/us/resources-free-tools.asp (look under SASS Tools)

Some suggestions taken from RSnake over at ha.ckers.org:
* http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
* http://testasp.acunetix.com/Default.asp
* http://test.acunetix.com/
* http://hackme.ntobjectives.com/
* http://www.foundstone.com/us/resources/proddesc/hacmeshipping.htm
* http://www.foundstone.com/us/resources/proddesc/hacmecasino.htm
* http://www.foundstone.com/us/resources/proddesc/hacmebooks.htm
* http://www.foundstone.com/us/resources/proddesc/hacmetravel.htm
* http://zero.webappsecurity.com/
* http://www.hackertest.net/
* http://www.hackthissite.org/
* http://www.mavensecurity.com/WebMaven.php
* http://ha.ckers.org/challenge/
* http://ha.ckers.org/challenge2/
* http://demo.testfire.net/
* http://scanme.nmap.org/
* http://www.hellboundhackers.org/
* http://www.overthewire.org/wargames/
* http://roothack.org/
* http://heorot.net/
* http://www.irongeek.com/i.php?page=security/mutillidae-deliberately-vulnerable-php-owasp-top-10
* http://wocares.com/xsstester.php
* https://how2hack.net
* http://hax.tor.hu/

An interesting article published earlier this week on Information Week’s website here called “Web Applications: Achilles’ Heel Of Corporate Security” discusses the tremendous rise in web-application breaches and attacks this past year.

IBM’s 2008 X-Force Trend and Risk report which was released Monday states:

“Certain types of corporate applications, namely custom-built software like Web applications, remain a highly profitable and inexpensive target for criminal attackers. The sheer number of new vulnerabilities, the majority of which have no available patch, coupled with the hundreds of thousands of custom Web applications that are also vulnerable (but never subject to a vulnerability disclosure, much less a patch), continue to be the Achilles’ heel of corporate security.”

Since CIOZone.com is currently running a poll regarding what is considered the largest security threat, and since ‘Poorly coded web applications’ is rightly on the list, I thought this a good topic for this week’s article. By the way, you can view the poll results here.

So should you be worried about your web applications and should it be a top priority? The answers are “yes” and “maybe”. You should be worried about your organization’s web applications, but it may not be your biggest risk. In combing through the data breaches listed at www.privacyrights.org the overwhelming majority of breaches are due to human error, via either incompetence or malice. Simple things like throwing sensitive hard-copy paperwork in the garbage dates back to before the computing industry dominated the workforce.

What does this say about the state of affairs in many organizations in relation to their information security posture? It’s tough to say for sure, but there is certainly evidence that many organizations are simply not preparing their employees properly with regular Security Awareness Training. While working on a Social Engineering assessment for a client late last year, we found more damaging, earth-shattering information in the company’s dumpster than email phishing and other impersonation attacks. In fact, the 10 minutes it took us to go through their trash yielded 90% of the total data collected during the engagement…and this isn’t exactly an isolated incident.

So what’s my point? Basically that although Web Applications are certainly the current target of choice, this is not a new issue, and wont be solved by focusing on the specific issue. Rather, focusing on Information Security as a whole, from the top down, in any organization continues to be the best approach to minimize the impact to any organization. No problem in Information Security has ever been solved by a product, a process or a policy, rather the combination of all 3 and a commitment to security-minded thinking in daily operations and planning initiatives.

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)

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