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.
There has been a lot of press, effort and money focused on Web Application Security over the past year–and rightly so. The attack footprint for many publicly-facing web applications has been growing as new web and browser-based vulnerabilities are being discovered at a scary pace. The PCI DSS push has helped primarily with the escalation of the press given, but we really haven’t crossed the bridge of minimizing the impact yet, and many security experts don’t yet see the light at the end of the tunnel.
What I want to discuss in this article is the trend observed over the past year, taken from data collected from hundreds of Pen Tests performed by myself and my peers. The results are indeed interesting.
Although web services take the cake, it’s not the web application vulnerabilities we hear about so much (such as XSS, SQL Injection and CSRF) that tops the list. In fact, the Top 8 of the Top 10 (although may contribute in some cases to things like XSS) are configuration and deployment errors.
The List (Organized by Number of Occurrences):
1. Weak, Insecure and Deprecated SSL Ciphers
2. TRACE Debugging Method Enabled on Web Server
3. Private IP Address of Web Server Leaked Through Headers (IIS)
4. Form Credentials and Confidential Information Transmitted over Clear Text (no SSL)
5. Default, Vendor Supplied Directories and Files (Mainly Apache/Tomcat Installations)
6. Poorly Configured Apache Servers, Including Directory Indexing and User Home Directories
7. Default ASP.NET Errors on IIS Installations
8. Unpatched IIS Installations Vulnerable to Remote Exploit
9. Presence of phpinfo() pages on Apache/PHP Installations
10. Cross-Site Scripting (XSS) Vulnerabilities
So at least one of the media-worthy vulnerabilities hits the list (XSS), but what is surprising to me is that common configuration errors and poor judgment calls by far takes the cake. In fact, when looking at the following graph, it is apparent just how bad this situation is.
This data is taken from raw pen testing data, is not specific to web servers and web applications only, and does not in any way correlate to things such as the OWASP Top 10 and the CWE Top 25 Programming Errors lists.
Food for thought: has the focus on web application security completely blinded us to the standard level of due care that should be exhibited in activities such as server deployment and patch management?
As a PHP coder myself, I know that it can be difficult for new programmers to build secure code. Aside from the Apache server config and the PHP config directives, writing secure code in PHP often is an afterthought — and it’s really easy to write insecure code with PHP.
Where many of the difficulties lay are in the use of Database connectivity, flashy AJAX and powerful Javascript to make a highly functional, good looking site. When coding these applications, many developers will pull pieces of code from other sites and integrate them into their own, often times not aware of input validation flaws, overflows and use of insecure PHP functions.
Where PHP often fails as a language is that it’s just that–a language. In and of itself, there are no input validation classes, no XSS or SQL Injection class to use, and no re-usable security mechanisms that can be used out of the gate.
In searching for frameworks that can be utilized by programmers to assist them in writing more secure PHP code, I ran across CakePHP. CakePHP is a PHP Framework that allows for the rapid coding of new applications using a Model, View, Controller (MVC) architecture. Aside from enabling the rapid development of new data-driven applications, CakePHP has some really good input validation classes that are extremely simple to use.
One of the main drawbacks with coding your own input validation with PHP is that many programmers aren’t familiar enough with regular expression syntax matching to make effective input validation routines–CakePHP simplifies this with pre-built functions for CC validation, SSNs, email addresses, password complexity and more.
Aside from its input validation classes, CakePHP allows developers to easily generate AJAX-enabled views, RSS feeds, XML and more without heavy modification of code or 3rd party downloaded scripts. Having been running through CakePHP for the past few weeks, I’m really impressed. I was really dumbfounded when I realized that CakePHP has been around for a really long time, has a corporate-sponsored team of developers and a very large base of programmers using it.
Any organization that utilizes PHP for writing public-facing web applications should look into (and require) a PHP development framework like CakePHP to ensure consistency and provide a baseline for common security features.
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.
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
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
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.
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
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?
One of the things that I constantly run into is that of security engineers trying to thwart web application attacks with network security equipment (such as IDS/IPS, AV signatures, etc).
A recent example regarded a SQL Injection attack on a web server. This particular entity has a very healthy multi-vendor network security perimeter, and felt that the gear in place was sufficient to both catch and stop a SQL Injection attack.
The really uncomfortable part about the whole thing was listening to the guy describe how he claimed to eventually stop it–by getting his IPS vendor to provide a “SQL Injection” signature. I was amazed….trying to deal with a Layer 7 issue using Layer 3 tools!!
This approach of course will not work (at least not for a determined hacker), what with the various encoding options, numerous ways to perform a SQL Injection attack, IPS signature evasion and the like.
The real issue at hand is how to address web application security attacks. Certainly, using a Web Application Firewall (WAF) in addition to the retro-firewall, but thats sort of like putting up an invisible dog fence to stop all dogs from crossing the line–its the wrong approach, and only deals with a portion of the issue (YOUR dog in this poorly-constructed example).
What was needed in this case was to address the issue of why a SQL Injection vulnerability was there in the first place–bad coding. User or URL-supplied input variables must be sanitized before injected into the SQL query, stored procedures used wherever possible, and -of course- DB permissions must be carefully handed out.
I rarely use the OSI model any more, but it has it’s value. Whether its real or made-up, the point is to address the security issue at the proper level. We need to start moving away from the idea that network security alone will protect our applications.
For a differing view, read RSnake’s post from way back in 2006 here. Although I agree with the viewpoint, the idea is to deal with the problem at the appropriate level. Most web attacks do occur at multiple theoretical OSI models, and -as such- require multiple defense strategies.
Some Free Web App Security Testing Tools & Resources
