On June 30, 2008, section 6.6 goes from being a best practice to a mandatory requirement. This section has often been debated as it isn't as clear as it could be. Therefore, it has yet to be implemented by many corporations. Unfortunately, procrastination time is over as you now have 5 months to interpret and take section 6.6 seriously. Let's start by taking a look at it:

Ensure that web-facing applications are protected against known attacks by applying either of the following methods:

• Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
• Installing an application layer firewall in front of web facing applications

Now I'm not a big fan of this section for two reasons. First I don't feel that it goes far enough. I believe in defense in depth and these choices are not mutually exclusive. An application review and an application firewall are two separate and complementary controls. Both should be implemented. They should not be presented as a la carte replacements for one another.  However, sometimes you can't change the rules and you've still gotta play the game. So let's dig deeper.

My second concern with section 6.6 relates to the wording used in the first option. It leaves a lot of grey area. First off, what is ‘custom application code'? If I take a packaged web application and add a custom style sheet, do I need a code review? In my opinion, canned web applications present significant risk themselves and should be treated no differently.

Beyond this, what constitutes a ‘review' of custom application code? As I've argued in the past, white box testing (aka static code review) is not a replacement for black box testing, or vice versa. They are separate and distinct methodologies with their own strengths and weaknesses. As with other controls, they should be used to complement one another, not compete for solo status. Why would the PCI Standards Council advocate one approach over the other? Fortunately, Dennis Hurst cleared up the confusion when he posted a response from the PCI council on his blog which addressed this very question. When asked if section 6.6 specifically require static code analysis, the council responded as follows:

Using specialized 3rd-party tools that perform thorough analysis of applications to detect vulnerabilities and defects may well meet the intention and objectives of the source code review requirement in PCI Data Security Standard requirement 6.6, if the company using the 3rd-party tool also has the internal expertise to understand the findings and make appropriate changes.

The PCI Security Standards Council will look to clarify this section of the standard during the next revision, to include that testing of web-facing applications can be done via source code review or products that test the application thoroughly for defects and vulnerabilities (when internal staff have the skills to use the tool and fix defects). The PCI Security Standards Council will also consider including prescriptive requirements as to what both the application firewall and application analysis tool or process should test for.

Thank you and regards,

The PCI Security Standards Council Response Team

There you have it, black box testing is acceptable. Unfortunately, at present this causes even more confusion as we're now left with three choices for satisfying section 6.6 - static code analysis, vulnerability scanning or an application firewall. Hopefully, the council will clarify t in the next iteration of the PCI DSS but in the meantime, if you are not adhering to section 6.6, you need to ASAP. Given the choices that you have for compliance this means either hiring a third party to conduct static code analysis/scanning or procuring and implementing an application firewall. The good news is that you have choices. The bad news is that you have five months to get it done.

- michael

This month Microsoft patched 15 vulnerabilities that were packaged into 6 security bulletins, 13 of which were critical. The patch release was average by recent standards. The 15 vulnerabilities had the following overall severity rankings.

• 8 Critical
• 4 Important
• 3 Moderate

This month's bulletins included patches for 3 public vulnerabilities, none of which were already being actively exploited. The following publicly known issues received patches:

• MS07-033 (CVE-2007-1499) Navigation Cancel Page Spoofing Vulnerability
• MS07-034 (CVE-2006-2111) URL Redirect Cross Domain Information Disclosure Vulnerability
• MS07-034 (CVE-2007-1658) Windows Mail UNC Navigation Request Remote Code Execution Vulnerability

Below is a cheat sheet for all 15 vulnerabilities.

Enjoy!

- michael

 When auditing web applications, in order to efficiently test the application it is necessary to quickly determine the underlying technology that is being tested. Sure you could throw every single known attack at a web app but that would be extremely inefficient. There's no reason to send a known ColdFusion information leakage issue at an Java app., nor would you include stacked SQL queries when attacking a PHP/MySQL app. When auditing complex applications, efficiency is important in order to ensure that the audit can be completed during the timeframe provided and to ensure that it can be done regularly.

Assuming that a true black box test is being performed, knowledge of the underlying web application technologies will not be available. It is therefore necessary to monitor the behavior of the application in order to identify clues that will aid in identifying the technologies that have been used. Below is a list of typical clues to look for.

Server Response Header

The Server response header can be a goldmine of information as it "identif[ies] the server and any significant subproducts". RFC 2616 (Hypertext Transfer Protocol - HTTP/1.1) actually warns of the dangers of providing an overly verbose server header by stating that "revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes". Don't however be fooled as this header can easily be omitted, spoofed or altered by an intermediate device such as a proxy, even though RFC 2616 prohibits such behavior.

Response Header Format/Order

Different web servers provide response headers that adhere to protocol specifications but are still unique. Depending upon the structure of the request received, servers may respond with headers listed in a different order or perhaps with additional/omitted headers. Entire whitepapers have been written on this topic and this behavior has led to the creation of various web server fingerprinting technologies such as HTTPrint or HMAP.

Verbose Error Messages

When verbose error messages are not suppressed they can reveal not only the web/application servers being used but also complimentary technologies such as the database server that has been employed or the programming language used. For example, take a look at the following Google queries which identify revealing verbose error messages:

• ColdFusion
• Microsoft IIS 4.0
• Apache Tomcat

Known Pages/Directories/Functionality

By default, most servers/applications arrive out of the box with a number of sample apps, help files and common directory structures. Identifying such items on a site can once again reveal important details about the technologies used. Once again consider the following Google queries:

• Oracle - iSQL*Plus is a web based SQL query tool that is included by default in Oracle HTTP Server, which is part of Oracle Application Server and Oracle Database Server

Page Extensions

This one is a bit of a no brainer but even this can be misleading at times as extensions can be changed, not displayed or be generic extensions used by multiple technologies (e.g. .htl or .html). Below is a sample of common page extensions and their underlying technologies:

• ColdFusion
• .cfm - ColdFusion Markup File
• Microsoft
• .asa - ASP Configuration File
• .ascx - Active Server Custom Control
• .asmx - Active Server Method File
• .asp - Active Server Page
• .aspx - Active Server Page Extended
• .chm - Compiled HTML Help File
• Java
• .jhtml - Java within Hypertext Markup Language
• .jnlp - Java Web Start File
• .jsp - Java Server Page
• .jspx - XML Java Server Page
• PHP
• .php - Hypertext Preprocessor File
• .php3 - PHP 3 Script
• .php4 - PHP 4 Script
• .php5 - PHP 5 Script
• .phtm - PHP Web Page
• .phtml - PHP Web Page
• Ruby
• .rhtml - Ruby HTML Web Page

What is the ‘correct' way to identify underlying web application technologies? As with just about everything in security, there is no silver bullet. A combination of all of the aforementioned approaches is your best bet but in the end everything can be obfuscated either intentionally or otherwise. Nothing short of a chat with the developers and/or system administrators will reveal the true answer but with a little detective work you should be able to quickly identify the technologies with a reasonable level of confidence.

The break that we were given in April when only 8 vulnerabilities were delivered is now a long lost memory. While May was not a record month, it was big with 18 overall vulnerabilities in seven advisories. More importantly, the vulnerabilities were strongly skewed toward critical with 14 of 18 reports receiving the top severity ranking. As always, while it's refreshing to get such a large bundle out of the way, don't relax just yet. Instead, take a quick look at upcoming advisories for 3Com's Zero Day Initiative or eEye Research and you'll see that they still collectively have more than a dozen unpatched Microsoft vulnerabilities despite the fact that two TippingPoint issues were addressed this month.

The 18 total vulnerabilities had the following overall severity rankings.

• 14 Critical
• 4 Important

This month's bulletins included patches for three public vulnerabilities.

• MS07-024 (CVE-2007-0870) Word Document Stream Vulnerability
• MS07-027 (CVE-2007-0942) COM Object Instantiation Memory Corruption Vulnerability
• MS07-029 (CVE-2007-1748) DNS RPC Management Vulnerability

Most importantly, the zero-day Windows DNS RPC vulnerability was addressed. This was important as Microsoft had acknowledged targeted exploitation of this issue nearly a month ago.

Below is a cheat sheet for all 18 vulnerabilities.

Enjoy!

- michael

I spend much of my time on the road conducting presentations on application security for various audiences. Of all the groups that I speak to, developers are a favorite of mine. Developers get a bad rap when it comes to security. They are generally blamed for creating vulnerabilities, not thanked for preventing them. While it's true that a developer somewhere is responsible for creating just about any vulnerability, I don't blame them. Developers build what we ask them to build. Plain and simple. The problem lies in the fact that we've not historically asked for security. What we've asked for is functionality and a project that is released on schedule. Unfortunately, those two requirements generally work in opposition to security.

Slowly, we are coming to the realization that when it comes to application security, the only complete solution is to ensure that the application itself is secure. While defense in depth solutions such as firewalls, IDS/IPS technologies, etc. can increase the enterprise's overall security posture, in the end, they are band-aid solutions designed to protect vulnerable applications. With enough time and effort, these defenses can be bypassed and the vulnerable technology exploited.

With this realization we're now finally asking our developers to start worrying about security. That's a bit of a scary proposition for most developers who have been building applications for many years without a need to focus on secure coding because ‘the security team takes care of security'. We're now asking developers to learn a new discipline on top of the ever evolving world of software development. Why then do I enjoy speaking to developers? The answer is simple - despite the challenge, they want to learn. Developers do not for the most part despise security. On the contrary, they want to embrace it but no one has ever shown them the way. Take a look at any programming textbook or university course syllabus - where are the chapters or lectures on security? There not there, but they need to be. Developers, like anyone tasked with building something from nothing, take pride in their work. They want their code to be secure just as much as they want their project to have adequate functionality but they need the resources and training to make that happen. I enjoy speaking to developers because I so often see that ‘lightbulb moment'. For the first time they say ‘ah, so that's what XSS/SQL Injection/[Fill in vulnerability type here] is. I'd heard the term but had no idea what it was or how to fix it'. As a presenter, that's a very satisfying moment.

Educating developers to produce secure code is no small task and will not happen overnight. A first step requires providing developers and their employers with a metric to measure both current developer knowledge and assess progress over time. SANS has recently launched the Secure Programming Skills Assessment, a collection six examinations covering various programming languages (C, C++, Java, .Net, PHP and Perl). The goals of the project include enabling employers, consumers and the developers themselves to be able to assess the secure coding knowledge of those involved in a software project. While the exams are designed to benefit multiple parties, I expect that developers will receive the greatest benefit as the exams will allow them to identify their own deficiencies. SPI Dynamics was one of the many contributors to this initiative and having looked at some of the content, I can assure you that the questions can be quite challenging and I expect that the exams will be an eye opening experience for those that choose to take the exams. If you're interested, in learning more take the time to listen to a recent webcast that was conducted to launch the initiative. I had the pleasure of sitting on a panel with a group of industry leaders where we discussed the types of application vulnerabilities that we're seeing and what we believe needs to be done about them going forward.

The month of April started off with a bang, when Microsoft released MS07-017, a rare out of cycle patch but ended with a fizzle, with 8 additional vulnerabilities. While four critical vulnerabilities were addressed, that is down significantly from the 13 critical vulnerabilities that were patched in February 2007, the last full patch cycle (March was skipped). While it may at first appear encouraging to see the number of patches diminishing, don't be fooled. Take a quick look at upcoming advisories for 3Com's Zero Day Initiative or eEye Research and you'll see that they collectively have more than a dozen unpatched Microsoft vulnerabilities.

The February patch release was relatively small when compared to recent months. We ended up with 8 vulnerabilities in 5 bulletins having the following overall severity rankings.

• 4 Critical
• 3 Important
• 1 Moderate

This month's bulletins included patches for one public vulnerability, beyond MS07-017 which was patched last week. The following publicly known issue received a patch:

• MS07-021 (CVE-2006-6696) MsgBox (CSRSS) Remote Code Execution Vulnerability

Below is a cheat sheet for all 8 vulnerabilities.

Enjoy!

- michael

I was excited this afternoon when I thought that I'd stumbled upon a universal XSS vulnerability in verbose ColdFusion error messages. While testing a site, I had noted that a verbose debug error message (see below) echoed back many of the request headers, including the Referrer and User-Agent (aka Browser) headers.

Error Occurred While Processing Request

#Form.XXX#

Naturally, curiosity got the best of me and I attempted to inject JavaScript into the headers only to find that yes indeed, the injected JavaScript was echoed back without being sanitized, which makes for a nice XSS vulnerability on all ColdFusion sites which don't suppress such error messages. Alas, my hopes were dashed when I realized that I'd been beaten to the punch. Despite the setback, I was still curious to see how many sites would be affected by the vulnerability and was blown away when my friend Google suggested that the number may be in the six figure range.

Knowing that, my curiosity was peaked again, so I started poking around to see if I could find other third party or custom web apps which exposed XSS vulnerabilities by echoing back raw request headers. A bit of creative Googling suggested that many have made the same mistake:

• "Error Occurred While Processing Request" referrer
• intitle:"PHPWrap Error"
• intitle:"CGIWrap Error" " -"Local -Information -and -Documentation"
• "The requested URL" "was not found on this server"
• intitle:"File Not Found" intext:"HTTP_USER_AGENT"

The moral of this story is that we must think broadly when defining user input. Data does not need to come from a web form to be considered user supplied input. Headers, cookies, hidden form fields, etc. all come from the client and can therefore be manipulated by an attacker. When building web apps, we need to define user input as ANYTHING that is sent from the client to the server.

- michael

            "Web 2.0 is the business revolution in the computer industry caused by the move to the internet as platform, and an attempt to understand the rules for success on that new platform. Chief among those rules is this: Build applications that harness network effects to get better the more people use them."

If someone can decipher that please contact me because I have no idea what it means.

Wikipedia on the other hand has this to say about Web 2.0:

            "a perceived or proposed second generation of Web-based services-such as social networking sites, wikis, communication tools, and folksonomies-that emphasize online collaboration and sharing among users"

That's a bit better; at least I can picture the sites that they're referring to. The truth is that Web 2.0 doesn't have a definition; it is simply referring to the emergence of more user friendly, responsive web applications that take advantage of new technologies to create a better user experience. In a nutshell, web applications are beginning to feel like desktop applications, with the advantage of being interconnected globally.

There are a number of technologies being leveraged to create these next generation applications including AJAX, RSS, JSON, SOAP, Atom, etc. These technologies are in turn being used to create fancy web sites such as Google Maps, flickr, del.icio.us, Google Docs and Spreadsheets, etc.

What does this mean from a security perspective? First off, Web 2.0 has not created any new vulnerabilities, it has only changed the way that we build web applications. All of the aforementioned technologies are layered on top of HTTP and are subject to the same vulnerabilities that affect traditional web applications. What has changed is where we need to look for the vulnerabilities. Virtually all web application vulnerabilities exist when input is accepted and processed without being properly sanitized. Identifying input is now less straight forward. Input does not have to come from a web form, it does not need to be generated by a user action and it does not even need to come from a user. Take for example the case of Asynchronous JavaScript and XML (AJAX). AJAX instructs the browser to make requests and receive responses behind the scenes. It creates a more rich application as screen content can change without the need for a full page refresh. Each of those requests occurring in the background represents input. Take for example this AJAX request being sent to BlinkList, a link sharing site. The request triggers the following verbose SQL error message!

select usertag.name from usertag where usertag.userid =  order by usertag.name<br>You have an error in  your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax  to use near 'order by usertag.name' at line 1

How did I find it? No, I didn't attack BlinkList, I spotted it when I had the XMLHttpRequest monitor enabled in FireBug, a popular FireFox extension. This is a request that the BlinkList developers built into the application. They have actually built a SQL injection attack into their website which is triggered any time a user visits the BlinkList homepage.

How about a mashup which pulls various RSS feeds together to create a dynamic news site? Is that site accepting input even if it's a read-only page? Absolutely. The feeds from third party sites should be treated as untrusted inputs and be subject to the same scrutiny as a web form accepting user input. Bob Auger warned us about this in a whitepaper on injection attacks in RSS and Atom feeds last year.

The point is that when testing so called Web 2.0 applications we need to redefine what we consider to be untrusted input. You cannot appropriately audit a web application without first identifying all potential input vectors. Whether using commercial or freeware tools or manually auditing a page, ensure that your approach is capable of identifying and interpreting the input vectors contained in the application being audited. Whether that input comes from an AJAX XMLHttpRequest, a third party RSS feed of a SOAP based web service, it all represents a potential attack vector and must therefore be tested with the same level of scrutiny as would a user controlled web form.

Let the revolution begin.

- michael

The February patch release was significant leaving us with 20 vulnerabilities in 12 bulletins having the following overall severity rankings.

• 13 Critical
• 7 Important

This month's bulletins included patches for 7 public vulnerabilities, most of which were already being actively exploited. The following publicly known issues received patches:

• MS07-009 (CVE-2006-5559) Microsoft Windows MDAC ActiveX Vulnerability
• MS07-014 (CVE-2006-5994) Word Malformed String Vulnerability
• MS07-014 (CVE-2006-6456) Word Malformed Data Structures Vulnerability
• MS07-014 (CVE-2006-6561) Word Count Vulnerability
• MS07-014 (CVE-2007-0515) Word Malformed Function Vulnerability
• MS07-015 (CVE-2007-0671) Excel Malformed Record Vulnerability
• MS07-016 (CVE-2006-4697) COM Object Memory Instantiation Vulnerability

Below is a cheat sheet for all 20 vulnerabilities.

Enjoy!

- michael

I recently blogged about the phishing pages that I found during a Tour of the Google Blacklist. In that posting I noted how I was surprised to find that Yahoo! was actually hosting phishing sites designed to phish Yahoo! credentials. Not surprisingly, Yahoo! quickly removed the pages that I'd pointed out. When questioned about the issue by Network World news editor Paul McNamara, Yahoo! stated that they "proactively scan hosted sites for potential phishing activity and deactivate suspicious sites" and that they "are continually improving and modifying [their] efforts to remain at the forefront of the industry". Fair enough, perhaps Yahoo! had not been aware of the Google blacklist and my blog posting had encouraged them to add monitoring the list to their "use of enhanced technologies, industry collaboration, public policy efforts, and increasing consumer awareness", which they are apparently employing to combat phishing. I therefore revisited the Google blacklist today and was disappointed to see that it still includes active phising sites hosted by Yahoo! Geocities. The good news for Yahoo! - they're far from being the worst offender.

This time around, I decided to see which hosting providers are aiding phishers by maintaining their websites - for free. To do this, I spent a couple of hours sifting through various publicly available resources including search engines, phishing archives, the Google Blacklist and the Google Hashed/Encoded Blacklist. Sadly, I found that most free hosting providers are contributing to the problem of phishing. Given that I was able to find dozens of sites with minimal effort and no special resources, it is clear to me that the hosting providers are making no effort whatsoever to combat this problem. Why? Do they lack the resources? Is the challenge too difficult? I have a different theory. I believe that they benefit from the ad revenue that these web pages provide. They choose not to combat the problem because they are profiting from it.

What can be done to change this? Hosting providers must be held responsible for the content that is hosted on their servers. Companies such as HSBC, MySpace, Microsoft (Hotmail) and eBay were among the targets of the phishing sites that I investigated. It is their clients that are paying the price for this and it is therefore time that such companies took action. MySpace has repeatedly removed content when facing legal action for copyright infringement. I suspect that the free hosting providers would try a little harder if they likewise faced legal action for their negligence when combating phishing.

Below, from least to most prolific offenders are the free hosting sites which I uncovered this evening. All were active phishing sites at the time of this posting.

FreeWebPage.org

http://mypics4u6969.freewebpage.org/mypics2.html

50 Megs

http://sgi.com.50megs.com/SWcgi3-bin0-ISAPIdll-viewtheitem-4583745438.htm

Tripod (Lycos)

http://jokaowns.tripod.com/
http://daulamoe.tripod.com/

Geocities (Yahoo!)

http://www.geocities.com/maria_bitch69/album_photo.html
http://www.geocities.com/myphotos30021/
http://www.geocities.com/sweet_aqnes/Album_Photo.html
http://www.geocities.com/you_want_my_cookies/
http://www.geocities.com/sweet_angel_eyez_of_tears/
http://www.geocities.com/lxxl_kiss_me_fool_lxxl/
http://www.geocities.com/sydneypulse/
http://www.geocities.com/ravish334/yahoophoto.htm

...and by far the worst offender (I stopped at 50+, but there's plenty where that came from)...

Angelfire (Lycos)

http://www.angelfire.com/ab7/serviceupdate/index.htm
http://www.angelfire.com/goth/login0/index.htm
http://www.angelfire.com/punk5/xxhaterxx4/
http://www.angelfire.com/blog/myspacelogin.error
http://www.angelfire.com/band2/hahheresahint/
http://www.angelfire.com/blog/myspace-login
http://www.angelfire.com/blog/myspacecom0/
http://www.angelfire.com/ultra2/cambo/
http://www.angelfire.com/funky/myspace1/
http://www.angelfire.com/funky/fakemyspace/
http://www.angelfire.com/ultra2/iocinlin/1234567890.html
http://www.angelfire.com/hiphop/rapperzz/
http://www.angelfire.com/dc2/box1/login.html
http://www.angelfire.com/ab/ljshouse/
http://www.angelfire.com/blog/myspcelogin
http://www.angelfire.com/blog/ihatemidgets619/
http://www.angelfire.com/blog/sizeofmylad-login
http://www.angelfire.com/blog/anime6idk/miespacio.htm
http://www.angelfire.com/crazy2/wowo30/ebayo.html
http://www.angelfire.com/ct3/ebaydll
http://www.angelfire.com/blog/password_recovery/login
http://www.angelfire.com/stars5/freeallstars4u/
http://www.angelfire.com/folk/x_jroc_x/haha.html
http://www.angelfire.com/me5/hawaiian/Sign_in.html
http://www.angelfire.com/oz/yahoox2/
http://www.angelfire.com/sk3/hotmail.com/
http://www.angelfire.com/tn3/cardandboardtournies/
http://www.angelfire.com/yt3/liloohaykid/
http://www.angelfire.com/magic/hawaiianstud96817/Log_in.html
http://www.angelfire.com/hiphop3/superstarz/chat.html
http://www.angelfire.com/comics/behnamshayani/Picture.html
http://www.angelfire.com/freak2/friendship0/card.html
http://www.angelfire.com/goth/account/
http://www.angelfire.com/droid/hairytick/update2.html
http://www.angelfire.com/film/tahirrizvi/hotmail.htm
http://www.angelfire.com/in/revolutionize/hotmail.html
http://www.angelfire.com/retro/hackers/java-y.htm
http://www.angelfire.com/mi4/anoop/ServiceLogin.htm
http://www.angelfire.com/crazy2/hobbix/
http://www.angelfire.com/pq/fos2/
http://www.angelfire.com/un/hotmailauthenticity/
http://www.angelfire.com/alt/aimexpress/index2.html
http://www.angelfire.com/cantina/test2/
http://www.angelfire.com/blog2/crimerecord/
http://www.angelfire.com/hi5/bot_remover/
http://www.angelfire.com/ult/dream10/
http://www.angelfire.com/in4/member/yahoomail.html
http://www.angelfire.com/blog/rahul180proof/
http://www.angelfire.com/ia3/falcon23/Yahoo_New.htm
http://www.angelfire.com/blog2/myspacepwnd/
http://www.angelfire.com/biz7/myspace_error/
http://www.angelfire.com/droid/dd3fgadsgasd554/pic.html
http://www.angelfire.com/music2/JDVONmusic/privatephotos.htm
http://www.angelfire.com/funky/andrews/

Why can't we all just get along?

- michael

How Prevalent Are Cross Site Scripting (XSS) Vulnerabilities? Based on a recent experiment, I wasn't surprised to see that they're everywhere and finding dozens at a time doesn't present much of a challenge. Back in September, 2006 I sought to find empirical evidence of the prevalence of SQL Injection flaws. I blogged about my effort to leverage the Google API to find such evidence and it quickly became one of my more popular postings. Since then, I've wanted to conduct a similar experiment to investigate the prevalence of XSS vulnerabilities and have finally found the time to do so.

Mitre CVE statistics tell us that XSS is now the most common vulnerability, accounting for 21.5% of all newly discovered vulnerabilities in 2006. This is an important statistic but it only tells us what is being discovered in commercial and open source software, not what actually exists out there in the abyss we know as the Internet. When it comes to web application vulnerabilities, what's actually deployed is far more meaningful. Web apps commonly contain custom code, and vulnerabilities in custom code don't get CVE numbers. What I'm looking for is statistics on live, publicly accessible web apps.

Search Terms

Google is a powerful tool. It can help you make dinner reservations but it can also help you find vulnerable web sites and in my quest to look for vulnerable sites, I once again sought assistance from my old friend. In order to leverage Google, you need one thing - a search query, but what search terms would assist in identifying sites potentially vulnerable to XSS? XSS flaws exist because user supplied input is not properly sanitized before being included in a dynamically generated webpage. That weakness in turn allows attackers to inject client side script into the page. Therefore, what I needed were search terms that would allow me to identify requests containing user input and web pages that echoed back that same input. I chose to target search pages using GET requests. Search pages are common victims of XSS and identifying those using GET requests would ensure that the user supplied values were included in the URL and would therefore be included in the Google index. I ultimately chose the following terms:

• inurl:"search=xxx" intext:"search results for xxx"
• inurl:"query=xxx" intext:"search results for xxx"
• inurl:"q=xxx" intext:"search results for xxx"

The ‘xxx' within each query was replaced with various words and letters such as ‘the', ‘microsoft', ‘clock', ‘d', etc. Some had meaning, some were chosen simply because it was 3am and it was all that I could come up with. They were however purposely chosen to be very different and hopefully identify results from unique websites. By including ‘inurl' queries, I was able to target variables within the URL sent via a GET method. By combining that with an ‘intext' query I could look for the same value being included within the page itself, a necessary ingredient for a XSS vulnerability. Overall the search terms were designed to identify search result pages that were echoing back the user supplied query.

Automation

Rather than manually run Google queries ten results at a time, I automated the process by once again turning to the Google API, a programmatic interface which would allow me to build a tool to automate interaction with Google. To build the Google XSS tool I simply made a few modifications to the Google SQL Injection tool built back in September, 2006. The only real change involved altering code to clean up the results given the different search terms that were used. Eliminating duplicates turned out to be a real challenge in this experiment. I wanted to ensure that I was testing only one page from each unique website and although I started out with 7,436 search results, my ultimate population was quickly whittled down to 288 when I imposed the restriction of requiring unique sites. This occurs as Google does not limit the number of results that can come from a given site and my search terms were specific enough that they kept drawing from the same web sites.

Detection

Once the target URLs had been identified, it was necessary to devise a test that would determine if the page was vulnerable. XSS is commonly tested by submitting a request that includes code to produce a JavaScript pop-up window such as <script>alert(‘xss');</script>. This code presents two problems for our experiment. First, we would defeat the purpose of producing an automated test if it required sitting in front of a computer screen trying to visually identify pop-up windows. Additionally, many sites implement inadequate blacklist filtering. Although these pages remain vulnerable they would be most likely to catch such a request given its popularity. What I needed was a way for the resulting web page to ‘phone home' when a vulnerability was identified. This could certainly be done using JavaScript, but a far more simple solution exists in standard HTML. IMG tags request content from alternate locations as the page is rendered. Moreover, because exploitation is occurring on the client side, not the server, I can use an IMG tag to request resources on my local network. In the end I settled on the following IMG tag:

• "img+src%3dhttp%3a%2f%2flocalhost%2fxss-" + host + "%3e"

The above is a URL encoded version of an image tag pointed at a non-existent page on my local web server. The Google XSS tool is also dynamically inserting the name of the targeted host into the URL. By doing this, identifying sites vulnerable to XSS is as simple as looking at the log files on my local web server. If a site is vulnerable, the host will show up in the web server log. For example, an unencoded URL for testing would look like the following:

• http://vulnerable.com?search=<img src=http://localhost/xss- vulnerable.com>

If vulnerable.com were indeed vulnerable, our web server log files would include the following entry:

#Software: Microsoft Internet Information Services 5.1
#Version: 1.0
#Date: 2007-01-31 00:57:34
#Fields: time c-ip cs-method cs-uri-stem sc-status
00:57:34 127.0.0.1 GET /xss-http:/vulnerable.com 404

The HTML encoding used in the actual URL is merely a simple obfuscation technique designed to bypass basic validation routines that may check for certain characters but not their encoded equivalents. The results did reveal numerous sites that had some level of validation that would prohibit unencoded JavaScript requests but failed to filter our encoded IMG tag.

Results

Mitre tells us that 21.5% of new vulnerabilities are due to XSS. Jeremiah Grossman recently released a report stating that WhiteHat Security found XSS flaws in 71% of the websites they audited during the first half of 2006. RSnake suggests that the number should be closer to 80%. I believe all of them. In this simple experiment, which looked at a single input vector on each website and supplied only one XSS injection variable, 17.3% of sites were found to be vulnerable. That's scary. The raw results are below:

Who was vulnerable? In order to protect the innocent, I'm not going name names, but I will paint a picture of what I saw. Given the search terms used, not surprisingly, results included blogging, search, video sharing and news sites. There were a few retail web sites as well including a couple of online music stores and a consumer electronics retailer. The sites ranged from small to large with the two most notable participants being a major sports network and one of the largest newspapers in the US. Unfortunately, it's not surprising that even large corporations have vulnerable websites when you look at the names which litter the sla.ckers.org XSS Wall of Shame.

How long did it take me to identify 47 vulnerable websites? Once the methodology was in place and the tool was built - less than five minutes. Once again, we're setting the bar for web application security far too low. It shouldn't be this easy.

- michael

The most logical place to start is by looking at third party product evaluations. Technology publications love to conduct bake offs of competing technologies and score the contestants. Moreover, technology vendors line up to be considered for awards bestowed by the same publications but buyer beware - awards and reviews may require vendors to pay a fee to be considered in the competition, so do your research to ensure that you're receiving an unbiased opinion. Personally, next to hands on experience with the tools themselves, I would place faith first and foremost in the past experiences of current customers that you have an existing relationship with - not the happy customers put forth by the vendor. No one knows the ins and outs of a technology better than those that rely upon it on a daily basis.

While it's great to know what others think, there's no substitute for hands on experience. Making an apples to apples comparison among competing technologies requires using an appropriate benchmark. I would actually recommend against testing security tools by using an in-house application as the benchmark. While this may seem to be a logical approach since you'll be using the tool in your own environment, an in house application is likely (we hope) to only contain a small population of vulnerabilities and as such will not provide a broad view of the strengths and weaknesses of the security tool being evaluated. In the web application security space there are fortunately a number of options available in the form of freely available, intentionally vulnerable web applications that can be used for testing purposes. Foundstone for example provides a series of ‘Hackme' web applications. Each of the Hackme applications are written in different languages which allows you to target the appropriate platform(s) used in your own development efforts. Hackme Bank for example, is written in C#, with a backend Microsoft SQL database, while Hackme Books is a J2EE application. OWASP makes available WebGoat, an insecure J2EE application, but a promising new initiative is their Site Generator project. Site Generator allows users to dynamically design different vulnerable web apps by selecting the desired vulnerable components.

If you still prefer to rely on third party evaluations but aren't comfortable with the potential bias of technology publications, the National Institute of Standards and Technology (NIST), is working on a solution. The Software Assurance Metrics and Tool Evaluation (SAMATE) project, sponsored by DHS, seeks to define the baseline functional behavior that should be present in security tools. The first SAMATE initiative will focus on source code analyzers (SCA). At this point, they are excluding byte code and binary code scanners from the SCA definition but a draft functional specification for this project is already available. Beyond the draft specification, they also plan to develop test suites that will allow for independent analysis of SCAs. In speaking with NIST, it appears that web application scanners will be their next project under the SAMATE umbrella. Given that these specifications only seek to identify baseline functionality for like tools, it remains to be seen how useful they will be in evaluating security tools, but we'll certainly follow their progress.

Regardless of the process that you use when evaluating security tools, never forget that as a buyer, you have more power than you realize. Don't simply hand over a hefty check simply because one vendor has a tool that is better than the others. If additional features are required to meet your needs, ensure that they make it into the product road map. These tools don't come cheap, so get your money's worth.

- michael

Structure

As with all of the Google safe browsing lists, the enchash list can be pulled from a standard URL as noted below:

http://sb.google.com/safebrowsing/update?version=goog-black-enchash:1:1

The final two integers in the URL represent major:minor version numbers, allowing you to pull specific versions of the list. When requesting the enchash list you will see the following structure:

[goog-black-enchash 1.16026]
+000063A6E10172D71383F41E62D518A4   ZFhjcVk2R1mwTTbpCYVT5twpRd6hypeo4...
+0000E099D1DD9B0CA2A834A20A20C7AF   cFhWWGd6NGVz/L8ye10PpA6dgRqtTftTu...
+00011C8D5B3C6B7E58EFE31EBD4DBE04   bFNvcGRvNmq62yRf0TeY3Lwdn7Z+y61S2...
+000351FD5CF55A398FF6360DA108ED03   UUxza1hyQzTbScPPx/MpphX/iQmMbYKET...

The first row simply identifies the version of the enchash list being displayed. The data following is contained in two columns with the first being an MD5 hash of a database salt (see below) + hostname and the second, an encrypted array of regular expressions.

Security

The enchash list isn't designed to be secure per se. Information on its structure and how to decrypt the regular expressions is publicly available. It is designed so that an individual URL can be checked against the list to determine if it is a phishing site, while preventing the entire list from being decrypted at once. This is accomplished by including the hostname in the decryption key. You must start with a hostname that is in the list, in order to decrypt the corresponding regular expressions. Therefore, in order to decrypt the entire list, you would also need to know all of the hostnames represented in the first column. This is likely done simply to prevent competitors from acquiring the full list.

Decryption

In order to understand how to decrypt the regular expressions, we'll walk through a sample record.

1. Hostname

• As mentioned, the list is designed to be able to check a known URL against the list to determine if a match exists. In order to do this, we'll begin with a hostname taken from the unencoded blacklist, namely 210.212.141.146.
• A canonical hostname should be broken down into sub hostnames with each one checked against the list separately. For example, with mail.yahoo.com, both mail.yahoo.com and yahoo.com should be checked separately. Since our hostname is an IP address, this is not required.
• Next, compute an MD5 hash of the ‘database salt' and the hostname. The database salt is a constant equal to ‘oU3q.72p'. The MD5 hash of ‘oU3q.72p210.212.141.146' is equivalent to ‘74AC98F531F37D2DA9C221148F2F35C2'.
• Ensure that all characters in the MD5 hash are capitalized and compare the result against data in the first column. If a match is found, proceed to the subsequent steps. In our case, the MD5 checksum does produce a match.

2. Key

• Once a match is found, it's time to produce the key that will be used to decrypt the data.
• Base64 decode the data
• Strip the first 8 characters from the decoded data. This will be used as the ‘random salt' and in our case is ‘Qjnv90jM'.
• Compute an MD5 hash of the ‘random salt|database salt|hostname'. This produces a 128-bit encryption key.

3. Decryption

• Apply the decryption key generated above using the RC4 algorithm to decrypt the data.

4. Result

• ^http\:\/\/210\.212\.141\.146\:84\/\.confirm\/index\.php\?
• Our example produced a single regular expression but it is possible for the data to contain multiple regular expressions separated by ‘\t' (tab stop) characters.

Code

The following code was provided by Stephan Chenette and Alex Rice from WebSense and will automate the aforementioned decryption procedure. I'd like to thank them both for their invaluable collaboration as they pointed out a key fault in my logic and ultimately saved me from chasing my tail.

#!/usr/bin/perl -w
use strict;
use Crypt::RC4;
use MIME::Base64;
use Digest::MD5 qw(md5);

my $database_salt = 'oU3q.72p';
my $hostname = '210.212.141.146';
my $enc_string = decode_base64('UWpudjkwak0iUBMO+xnGplKuo+fiEw1BVFQSuoi21jQ7DE2nTuO6esC67q88bcsM8TBVHQaEK29wmwzStc7SHQut');
my $random_salt = substr($enc_string, 0, 8);
my $enc_data = substr($enc_string, 8);
my $key = md5($database_salt . $random_salt . $hostname);
my $rc4 = Crypt::RC4->new($key);

printf "Regular exp(s): %s\n", $rc4->RC4($enc_data);

Enjoy!

- michael

This month's bulletins leave us with two major headlines. First, ‘What happened to half of the bulletins?' and secondly, Internet Explorer 7.0 isn't apparently quite as bullet proof as advertised. Even before Black Tuesday arrived this month, we knew that we were going to be receiving less than expected as last Friday Microsoft pulled four of eight planned bulletins. No explanation has been given but it's fair to assume that issues arose during final testing. While it's understandable that Microsoft would want to ensure that the patches are solid before releasing them, it's concerning given the number of outstanding Microsoft vulnerabilities that we're already aware of. For over a month now, Microsoft has admitted to being aware of two 0day Microsoft Word vulnerabilities being used in targeted attacks ( see below), yet the January patch cycle came and went and these vulnerabilities remain outstanding. Beyond this, 3Com's Zero Day Initiative lists six pending Microsoft advisories, while eEye lists two. Expect a large volume of Microsoft bulletins in February.

The other big headline surrounds MS07-004. Microsoft and iDefense have released details of a Vector Markup Language (VML) integer overflow vulnerability which affects all modern versions of Internet Explorer including IE7. Given the significant user base affected by this issue, be sure to make MS07-004 a top patching priority.

The pared down patch release was still significant and left us with 10 vulnerabilities in four bulletins with the following overall severity rankings.

• 7 Critical
• 2 Important
• 1 Moderate

This month's bulletins included patches for 3 public vulnerabilities. More importantly, Microsoft admits to being aware of exploitation using the VML Buffer Overrun Vulnerability (CVE-2006-4704). The following publicly known issues received patches:

• MS07-001 (CVE-2006-5574) Office 2003 Brazilian Portuguese Grammar Checker Vulnerability
• MS07-003 (CVE-2006-1305) Microsoft Outlook Denial of Service Vulnerability
• MS07-004 (CVE-2007-0024) VML Buffer Overrun Vulnerability

Unfortunately, this month's bulletins did not address the following two Microsoft Word file format vulnerabilities which have now been outstanding for over a month. While Microsoft has acknowledged the vulnerabilities and the fact that they are being used in targeted attacks, they have not set release dates for patches.

• Microsoft Security Advisory 929433
• Microsoft Word vulnerability - December 10, 2006 blog posting

Below is a cheat sheet for all 10 vulnerabilities.

Enjoy!

- michael

[Update 01.10.07: In response to some of the queries that I've been receiving, I've published a follow up blog to discuss the structure/decryption algorithm of Google's Encoded/Hashed Blacklist.] 

I recently decided to devote a day to walking through the Google Blacklist. While some of the findings were to be expected, others proved somewhat surprising. The Google Blacklist is a listing of URLs suspected to be phishing sites. It is used by the Google Safe Browsing for Firefox extension which is now part of the Google Toolbar for Firefox. It is also leveraged by the Firefox 2 web browser. Google maintains a number of different safe browsing lists to combat phishing including a URL blacklist, an encoded/hashed blacklist, a URL whitelist, a domain whitelist and a sandbox text list, which contains keywords included in URLs. While Google doesn't reveal exactly how these lists are developed, it's clear that user input is an important variable given that both the Google Toolbar and Firefox 2 allow for optional user feedback when phishing sites are encountered.

My hope was that this exercise would provide some insight into current phishing attacks and it certainly did. The blacklist is continuously updated and specific versions can be requested by including the required major:minor version in the GET request. The full listing (1:1) contained primarily outdated URLs as 86% of the pages or sites were no longer available. While I would like to think that the existence of Google's blacklist had contributed to the demise of these sites, phishing sites tend to emerge and disappear quickly, so I suspect that this is just a natural part of the phishing cycle. I had expected to see a combination of social engineering attacks, known vulnerabilities and 0day attacks used on the sites with the majority falling into the first category. I was therefore somewhat surprised to find virtually all sites using straight social engineering attacks. I was also surprised to see that the top three targets - eBay, PayPal and Bank of America accounted for 63% of the active phishing sites. One amusing finding was that Yahoo! commonly hosts pages that phish...wait for it...Yahoo! credentials. A breakdown of the full findings can be found below.

Summary of All URLs

Note 1: Includes 404 Not Found errors, 503 Service Unavailable errors, domain registrar placeholders, under construction pages, generic search pages, error messages, etc.

Summary of Active Phishing Sites

Note 2: Includes pages with web forms designed to harvest email addresses, social security numbers etc., but the sites were generic in nature and did not target any one company. Most were sites promising financial advice in exchange for providing personal information.

In almost all cases, these phishing sites are fake login pages, password reset pages or various other web forms that require the user to input sensitive data such as a password, credit card number or social security number. Surprisingly, of the 341 active phishing pages that I looked at, only one attempted to use a known vulnerability. All others simply employed social engineering attacks. The pages are generally exact replicas of the original web page and generally pull graphics (*.jpg, *.gif, etc.) from the legitimate web site.

Free Web Hosting Sites

Phishers are apparently cheap as many utilize free hosting sites such as Geocities, Tripod and FreeSpaces to host their phishing sites. While the hosting providers are catching some of these sites, they're clearly not working hard enough as several remained active. Somewhat amusing is that Yahoo Geocities is commonly used to host pages designed to harvest Yahoo! login IDs. Why Yahoo! can't catch phishing pages which they host is beyond me. Below are a handful of such pages which remained active as of this posting:

• http://uk.geocities.com/hardtimekennel/
• http://uk.geocities.com/sexy_pa_4u/
• http://uk.geocities.com/jenny_for_play_2/
• http://uk.geocities.com/lilac_rain111/
• http://uk.geocities.com/pics_for_you_0nly16/
• http://www.geocities.com/l0ts_0f_laffs.com52/
• http://www.geocities.com/sweet_blond3s_1nc/

All of the aforementioned sites appear to be set up by the same group as they all forward login credentials to http://www2.fiberbit.net/form/mailto.cgi. However, it is likely that they were set up at different times as they exhibit different properties. Some display an error page after a failed login while others redirect the user to a porn site or alternate Yahoo! page. Some also utilize JavaScript to prevent the user from accessing the right-click context menu, presumably in an attempt to hinder viewing the web page source code. Others also HTML encode the action attribute.

URL Obfuscation

The majority of active phishing sites took minimal steps to obfuscate the URL. The most common practice was to simply prefix the attacker URL with the targeted domain name (e.g. paypal.evilsite.com). Obviously even a casual inspection of the targeted URL would arouse suspicion but sadly this simple attack appears to fool many users. Other sites utilized IP addresses as opposed to fully qualified domain names and others went a step further by using decimal or hexadecimal forms of the IP addresses which are properly interpreted by most browsers. Hexadecimal encoding of at least portions of the URL itself was also a popular technique.

Cybersquatting

Cybersquatting, although far from a new technique, appears to remain in vogue. The unfortunate part is that domain registrars are allowing these names to be registered in the first place. In the sampling of domain names below, it is clear that these were registered with questionable intensions.

• mail-yahoo-us.tk
• wellsfargo-newupdate.com</