Michael Sutton's Blog

Michael Sutton's Blog Status Change

mark.painter — Wed, 22 Apr 2009 20:36:00 GMT

Michael Sutton's Blog will no longer be an active HP Application Security Center blog. Michael is no longer with HP, and won't be actively maintaining this blog. While no future comments will be accepted, all posts will still be archived and available for viewing. For other perspectives on web application security, see both the HP Security Laboratory Team Blog and Following the White Rabbit, the blog of Rafal Los.

PCI Requirement 6.6 - The Clock is Ticking

erik.peterson — Thu, 31 Jan 2008 10:24:00 GMT

Welcome to 2008. By now you have no doubt made and broken a number of New Year's resolutions. Not to worry if you've already wasted $50 bucks on a gym membership, there's always next year. I do however hope that taking PCI seriously was on the list and that it remains a top priority. Why this year? What's different about PCI in 2008?

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

Microsoft Black Tuesday - June 2007

erik.peterson — Wed, 13 Jun 2007 01:09:00 GMT

The June edition of Microsoft Black Tuesday marked two important events - an all out assault on client side vulnerabilities and the end of the security honeymoon for Windows Vista. I've been saying for some time now that we're in the midst of a revolution as attackers shift their focus from gaping server side vulnerabilities, which are becoming increasingly rare, to stealthy client side holes that make phishers salivate. This month's patches illustrated that we need to focus our efforts on better securing client side applications as there are a plethora of holes ripe for exploitation. Vista also received a dose of reality as the latest and greatest operating system appeared in 8 of the published vulnerabilities, with 3 of them being critical. Also of interest is MS07-035, a remote code execution vulnerability in the Windows API which can apparently be exploited via Internet Explorer. This is certainly one to keep an eye on as it will be interesting to see if public exploit code emerges in the coming days.

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

Bulletin	Title
MS07-030	Visio Version Memory Corruption Vulnerability CVE-2007-0934 Important Public: No Exploited: No
MS07-030	Visio Document Packaging Vulnerability CVE-2007-0936 Important Discovered By: Chris Ries of Vigilant Minds Public: No Exploited: No
MS07-031	Vulnerability in the Windows Schannel Security Package CVE-2007-2218 Critical Discovered By: Thomas Lim of COSEINC Public: No Exploited: No
MS07-032	Permissive User Information Store ACLs Information Disclosure Vulnerability CVE-2007-2229 Moderate Discovered By: Robbie Sohlman Public: No Exploited: No
MS07-033	COM Object Instantiation Memory Corruption Vulnerability CVE-2007-0218 Critical Discovered By: An anonymous researcher working with iDefense VCP Tom Cross of ISS Public: No Exploited: No Advisory: iDefense
MS07-033	CSS Tag Memory Corruption Vulnerability CVE-2007-1750 Critical Public: No Exploited: No
MS07-033	Language Pack Installation Vulnerability CVE-2007-3027 Critical Discovered By: An anonymous researcher working with TippingPoint Public: No Exploited: No Advisory: ZDI-07-037
MS07-033	Uninitialized Memory Corruption Vulnerability CVE-2007-1751 Critical Discovered By: Sam Thomas working with TippingPoint Public: No Exploited: No Advisory: ZDI-07-038
MS07-033	Navigation Cancel Page Spoofing Vulnerability CVE-2007-1499 Moderate Public: Yes Exploited: No
MS07-033	Speech Control Memory Corruption Vulnerability CVE-2007-2222 Critical Discovered By: Will Dorman of CERT/CC cocoruder of Fortinet Security Research Public: No Exploited: No
MS07-034	URL Redirect Cross Domain Information Disclosure Vulnerability CVE-2006-2111 Important Public: Yes Exploited: No
MS07-034	Windows Mail UNC Navigation Request Remote Code Execution Vulnerability CVE-2007-1658 Critical Public: Yes Exploited: No
MS07-034	URL Parsing Cross Domain Information Disclosure Vulnerability CVE-2007-2225 Important Discovered By: SANS ISC Public: No Exploited: No
MS07-034	Content Disposition Parsing Cross Domain Information Disclosure Vulnerability CVE-2007-2227 Moderate Discovered By: Yosuke Hasegawa of WebAppSec.JP Public: No Exploited: No
MS07-035	Win32 API Vulnerability CVE-2007-2219 Critical Discovered By: Billy Rios from VeriSign Public: No Exploited: No

Identifying Web Application Technologies

erik.peterson — Fri, 08 Jun 2007 18:13:00 GMT

Jeff Forristal has an interesting initiative and for those able to help out, there are cash and prizes to be had! Well ok, no cash, but you could walk away with some stylish SPI clothing or a few drinks on us. Jeff is looking for assistance in identifying the devices (web servers and proxies) that are responsible for some odd but consistent response headers. To see if you can help out, take a look at the three response challenges that he's identified.

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:

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 - 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.

Microsoft Black Tuesday - May 2007

erik.peterson — Wed, 09 May 2007 01:05:00 GMT

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

Bulletin	Title
MS07-023	Excel BIFF Record Vulnerability CVE-2007-0215 Critical Discovered By: Manuel Santamarina Suarez, working with TippingPoint Public: No Exploited: No Advisory: TippingPoint
MS07-023	Excel Set Font Vulnerability CVE-2007-1203 Critical Public: No Exploited: No
MS07-023	Excel Filter Record Vulnerability CVE-2007-1214 Critical Discovered By: Greg MacManus of iDefense Labs Public: No Exploited: No Advisory: iDefense Labs
MS07-024	Word Array Overflow Vulnerability CVE-2007-0035 Critical Public: No Exploited: No
MS07-024	Word Document Stream Vulnerability CVE-2007-0870 Critical Discovered By: Craig Schmugar of McAfee Avert Labs Andreas Marx of AV-Test Public: Yes Exploited: Yes
MS07-024	Word RTF Parsing Vulnerability CVE-2007-1202 Critical Discovered By: iDefense Labs Public: No Exploited: No Advisory: iDefense Labs
MS07-025	Drawing Object Vulnerability CVE-2007-1747 Critical Public: No Exploited: No
MS07-026	Outlook Web Access Script Injection Vulnerability CVE-2007-0220 Important Discovered By: Martijn Brinkers of Izecom Public: No Exploited: No Advisory:
MS07-026	Malformed iCal Vulnerability CVE-2007-0039 Important Discovered By: Alexander Sotirov of Determina Security Research Public: No Exploited: No Advisory: Determina Security Research
MS07-026	MIME Decoding Vulnerability CVE-2007-0213 Critical Public: No Exploited: No
MS07-026	IMAP Literal Processing Vulnerability CVE-2007-0221 Important Discovered By: Joxean Koret, working with the iDefense Public: No Exploited: No Advisory: iDefense Labs
MS07-027	COM Object Instantiation Memory Corruption Vulnerability CVE-2007-0942 Critical Discovered By: Public: Yes Exploited: No Advisory:
MS07-027	Uninitialized Memory Corruption Vulnerability CVE-2007-0944 Critical Discovered By: TippingPoint Public: No Exploited: No Advisory: TippingPoint
MS07-027	Property Memory Corruption Vulnerability CVE-2007-0945 Critical Discovered By: Public: No Exploited: No Advisory:
MS07-027	HTML Objects Memory Corruption Vulnerabilities CVE-2007-0946, CVE-2007-0947 Important Discovered By: JJ Reyes of Secunia Research Public: No Exploited: No Advisory:
MS07-027	Arbitrary File Rewrite Vulnerability CVE-2007-2221 Critical Discovered By: cocoruder of Fortinet Security Research Public: No Exploited: No Advisory:
MS07-028	CAPICOM.Certificates Vulnerability CVE-2007-0940 Critical Discovered By: Chris Ries of VigilantMinds Inc. Public: No Exploited: No Advisory:
MS07-029	DNS RPC Management Vulnerability CVE-2007-1748 Critical Discovered By: Mark Hofman of the SANS ISC Handlers Bill O'Malley with the Information Security Office at Carnegie Mellon University Public: Yes Exploited: Yes Advisory:

Educating Developers

erik.peterson — Wed, 11 Apr 2007 12:03:00 GMT

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.

Microsoft Black Tuesday - April 2007

erik.peterson — Tue, 10 Apr 2007 16:56:00 GMT

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

Bulletin	Title
MS07-018	CMS Memory Corruption Vulnerability CVE-2007-0938 Critical Public: No Exploited: No
MS07-018	CMS Cross-Site Scripting and Spoofing Vulnerability CVE-2007-0939 Important Discovered By: Martyn Tovey of Netcraft Public: No Exploited: No
MS07-019	UPnP Memory Corruption Vulnerability CVE-2007-1204 Critical Discovered By: Greg MacManus of iDefense Labs Public: No Exploited: No Advisory: iDefense
MS07-020	Microsoft Agent URL Parsing Vulnerability CVE-2007-1205 Critical Discovered By: JJ Reyes and Carsten Eiram of Secunia Public: No Exploited: No Advisory: Secunia
MS07-021	MsgBox (CSRSS) Remote Code Execution Vulnerability CVE-2006-6696 Critical Discovered By: Tim Garnett of Determina Security Research Public: Yes Exploited: No
MS07-021	CSRSS Local Elevation of Privilege Vulnerability CVE-2007-1209 Important Discovered By: eEye Public: No Exploited: No Advisory: eEye
MS07-021	CSRSS DoS Vulnerability CVE-2006-6797 Moderate Public: No Exploited: No
MS07-022	Kernel Local Elevation of Privilege Vulnerability CVE-2007-1206 Important Discovered By: eEye Public: No Exploited: No Advisory: eEye

Debug Message XSS Vulnerabilities

erik.peterson — Fri, 23 Mar 2007 00:35:00 GMT

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

Error Diagnostic Information

An error occurred while evaluating the expression:

#Form.XXX#

Error near line 5, column 20.

Error resolving parameter FORM.XXX

The specified form field cannot be found. This problem is very likely due to the fact that you have misspelled the form field name.

The error occurred while processing an element with a general identifier of (#Form.XXX#), occupying document position (5:19) to (5:33).

Date/Time: 03/22/07 22:36:03
Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Remote Address: 69.255.12.149
HTTP Referer: http://www.XXX.org:80/admin/
Query String: action=login&sub=validate

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:

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

What is Web 2.0?

erik.peterson — Thu, 15 Feb 2007 01:02:00 GMT

Web 2.0 may be the most ill defined technology term to date. Everyone uses the term but I have yet to hear a decent definition of it. O'Reilly Media is credited with coining the phrase and Tim O'Reilly defines Web 2.0 as:

"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

Microsoft Black Tuesday - February 2007

erik.peterson — Wed, 14 Feb 2007 00:32:00 GMT

This month Microsoft decided to play catch-up and hit us with a hefty 12 security bulletins covering 20 vulnerabilities, 13 of which were critical. The volume was not surprising given that Microsoft pulled four of eight planned bulletins four days before the January release. We had also been anxiously awaiting patches for a growing number of Microsoft Word vulnerabilities which had been outstanding for up to two months, with public exploit code being available along with admissions from Microsoft of active exploitation. Fortunately, all now appear to have patches available. Once again, client side vulnerabilities were king, with most of the critical vulnerabilities falling into this category.

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

Bulletin	Title
MS07-005	Interactive Training Vulnerability CVE-2006-3448 Important Discovered By: Brett Moore of Security-Assessment.com Public: No Exploited: No Advisory: Security-Assessment.com
MS07-006	Windows Shell Hardware Detection Vulnerability CVE-2007-0211 Important Public: No Exploited: No
MS07-007	Windows Image Acquisition Vulnerability CVE-2007-0210 Important Public: No Exploited: No
MS07-008	HTML Help ActiveX Control Vulnerability CVE-2007-0214 Critical Discovered By: HD Moore of BreakingPoint Systems Public: No Exploited: No
MS07-009	Microsoft Windows MDAC ActiveX Vulnerability CVE-2006-5559 Critical Discovered By: FrSIRT Public: Yes Exploited: No
MS07-010	Microsoft Malware Protection Engine Vulnerability CVE-2006-5270 Critical Discovered By: Neel Mehta and Alex Wheeler of ISS X-Force Public: No Exploited: No
MS07-011	OLE Dialog Memory Corruption Vulnerability CVE-2007-0026 Important Discovered By: Kostya Kortchinsky of Immunity, Inc. Fabrice Desclaux from EADS Common Research Center Public: No Exploited: No
MS07-012	MFC Memory Corruption Vulnerability CVE-2007-0025 Important Discovered By: Kostya Kortchinsky of Immunity, Inc. Fabrice Desclaux from EADS Common Research Center Public: No Exploited: No
MS07-013	Microsoft RichEdit Vulnerability CVE-2006-1311 Important Discovered By: Kostya Kortchinsky of Immunity, Inc. Fabrice Desclaux from EADS Common Research Center Public: No Exploited: No
MS07-014	Word Malformed String Vulnerability CVE-2006-5994 Critical Discovered By: Shih-hao Weng of Information and Communication Security Technology Center Public: Yes Exploited: Yes
MS07-014	Word Malformed Data Structures Vulnerability CVE-2006-6456 Critical Discovered By: Shih-hao Weng of Information and Communication Security Technology Center Public: Yes Exploited: Yes
MS07-014	Word Count Vulnerability CVE-2006-6561 Critical Public: Yes Exploited: Yes
MS07-014	Word Macro Vulnerability CVE-2007-0208 Important Discovered By: USAA Public: No Exploited: No
MS07-014	Word Malformed Drawing Object Vulnerability CVE-2007-0209 Critical Public: No Exploited: No
MS07-014	Word Malformed Function Vulnerability CVE-CVE-2007-0515 Critical Public: Yes Exploited: Yes
MS07-015	PowerPoint Malformed Record Memory Corruption Vulnerability CVE-2006-3877 Critical Discovered By: Chris Ries of VigilantMinds Inc. Public: No Exploited: No
MS07-015	Excel Malformed Record Vulnerability CVE-2007-0671 Critical Public: Yes Exploited: Yes Advisory:
MS07-016	COM Object Instantiation Memory Corruption Vulnerability CVE-2006-4697 Critical Public: Yes Exploited: No Advisory:
MS07-016	COM Object Instantiation Memory Corruption Vulnerability CVE-2007-0219 Critical Discovered By: H D Moore of BreakingPoint Systems Public: No Exploited: No Advisory:
MS07-016	FTP Server Response Parsing Memory Corruption Vulnerability CVE-2007-0217 Critical Discovered By: iDefense Public: No Exploited: No Advisory: iDefense

Phree Phishing

erik.peterson — Fri, 09 Feb 2007 01:15:00 GMT

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)

Why can't we all just get along?

- michael

How Prevalent Are XSS Vulnerabilities?

erik.peterson — Wed, 31 Jan 2007 13:27:00 GMT

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:

Unique sites identified by Google	288
Unique sites accessible at time of testing	272
Sites with confirmed XSS vulnerabilities	47
Percentage vulnerable	17.3%

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

Evaluating Security Tools

erik.peterson — Fri, 26 Jan 2007 15:50:00 GMT

All companies face the challenge of evaluating security tools that they will procure, but knowing where to start can be a daunting task. While there's no perfect way to ensure that a product meets your needs a little due diligence is essential. Fortunately, various resources are available to assist.

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

Decoding the Google Blacklist

erik.peterson — Wed, 10 Jan 2007 16:07:00 GMT

After publishing last week's blog entitled ‘A Tour of the Google Blacklist', I received a few queries about Google's encoded/hashed blacklist (enchash). This blacklist is separate from the unencoded blacklist that was the focus of the previous blog. It is also much larger, currently maintaining 14,000+ entries to the 1,000+ entries contained in the unencoded blacklist. Beyond that, it takes a more functional approach by providing regular expressions to match phishing URLs as opposed to exact string matches.

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

Microsoft Black Tuesday - January 2007

erik.peterson — Tue, 09 Jan 2007 14:13:00 GMT

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

Bulletin	Title
MS07-001	Office 2003 Brazilian Portuguese Grammar Checker Vulnerability CVE-2006-5574 Important Public: Yes Exploited: No
MS07-002	Excel Malformed IMDATA Record Vulnerability CVE-2007-0027 Critical Discovered By: Jeff Gennari of CERT Public: No Exploited: No
MS07-002	Excel Malformed Record Vulnerability CVE-2007-028 Critical Discovered By: Jie Ma of Fortinet Security Research Team Public: No Exploited: No Advisory: Fortinet FG-2007-01
MS07-002	Excel Malformed String Vulnerability CVE 2007-0029 Critical Discovered By: NSFocus Security Team Public: No Exploited: No
MS07-002	Excel Malformed Column Record Vulnerability CVE-2007-0030 Critical Discovered By: Greg MacManus of iDefense Labs Public: No Exploited: No Advisory: iDefense
MS07-002	Excel Malformed Palette Record Vulnerability CVE-2007-0031 Critical Discovered By: Greg MacManus of iDefense Labs Public: No Exploited: No Advisory: iDefense
MS07-003	Microsoft Outlook VEVENT Vulnerability CVE-2007-0033 Important Discovered By: Lurene Grenier of Sourcefire Public: No Exploited: No
MS07-003	Microsoft Outlook Denial of Service Vulnerability CVE-2006-1305 Moderate Public: Yes Exploited: No
MS07-003	Microsoft Outlook Advanced Find Vulnerability CVE-2007-0034 Critical Discovered By: Stuart Pearson of Computer Terrorism Public: No Exploited: No
MS07-004	VML Buffer Overrun Vulnerability CVE-2007-0024 Critical Discovered By: Jospeh Moti working with the iDEFENSE Public: Yes Exploited: Yes Advisory: iDefense