" Critical vulnerabilities have been identified in Adobe Reader 9.3.1 (and earlier versions) for Windows, Macintosh, and UNIX, Adobe Acrobat 9.3.1 (and earlier versions) for Windows and Macintosh, and Adobe Reader 8.2.1 (and earlier versions) and Adobe Acrobat 8.2.1 (and earlier versions) for Windows and Macintosh. These vulnerabilities could cause the application to crash and could potentially allow an attacker to take control of the affected system." Essentially opening a PDF file within an affected version of the products can possibly lead to arbitrary code execution. The updates cover the following CVE entries: CVE-2010-0190, CVE-2010-0191, CVE-2010-0192, CVE-2010-0193, CVE-2010-0194, CVE-2010-0195, CVE-2010-0196, CVE-2010-0197, CVE-2010-0198, CVE-2010-0199, CVE-2010-0201, CVE-2010-0202, CVE-2010-0203, CVE-2010-0204, CVE-2010-1241.

As security testers we tend to always be on the lookout for new or updated tools to test the security of web based applications. Some of these are of course commercial, but most of us also make extensive use of the free and/or open source offerings. In no particular order here are the ones I am currently making use of:

Please let us know if there are any I haven't mentioned that you find useful, and why! I'll add them to an update of the list after wards.

firebug - http://getfirebug.com/
webscarab - http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
curl and wget
Various versions of different web browsers
Various scripts in different scripting languages

I've deliberately decided to exclude commercial scanners, either web application specific or network scanners that can also do some web application tests.

We will update issues on this page for about a week or so as they evolve.We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY

(*): ISC rating

We use 4 levels:

PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.

Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.

Important: Things where more testing and other measures can help.

Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.

The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.

The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.

Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.

All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them

A few readers pointed us to an announcement by the Apache Foundation about a breach of their bugtracking software.

First of all: Kudos to Apache for publishing a nice and detailed incident report [1]. The attack included a number of elements that in itself are frequently ignored, but if combined in an attack like this one, turn out to be deadly.

Reading the blog post, a cross site scripting attack or simple password brute forcing was used to compromise the attack. While either attack appears to have the potential to succeed, it is not clear which one was finally used to gain access.

The cross site scripting attack used an additional twist in hiding the malicious URL via tinyurl.com. This made it more likely that an administrator would actually click on the URL.

Once the bug tracking system was compromised, the attacker modified it to log passwords. An administrator happened to use the same password to log in to the bug tracker as they use on the system itself.

Lets skip to the lessons learned:

While it is not clear if the XSS attack was successful, it is important to note that attacks like this happen and can work. A simple mitigation would be to use the "httponly" option for session cookies. This way, session cookies can not be stolen via injected Javascript. It doesn't fix the XSS vulnerability, but it makes exploiting it harder.

It is important to mitigate against brute forcing attacks. This mitigation should include two parts: (1) detection of brute force attacks and an automatic lock out mechanism. (2) a strong password policy backed up by password audits (to avoid "strong" passwords like password1! that may satisfy the policy but are still easily guessed.

Don't forget the ability to quickly un-lock accounts to avoid a brute force attack turning into a DoS attack.

Shared passwords are bad. Really bad. I actually recommend that people use some form of "password safe" software or write them down (yes... flame me for it. But I currently list 540 strong passwords). In the past I recommended different types of passwords for different purposes. But I found that sometimes a password starts out as "unimportant" and later becomes "important".

This is more of a reminder then "breaking news". But it may be worthwhile to include this in an awareness newsletter or similar presentation to keep your staff up to date on current social engineering malware. Our reader Andy sent us this e-mail he received. The domain name in the link has been modified. We of course had similar malware in the past claiming to be court documents or intellectual property violation notices.

----------------
Subject: Notice: Contract terms breached.
5 April, 2010
Hello,
You are hereby put on notice that as of 7/1/2010 you are in breach of our contract dated 3/12/2007.
The nature of said breach is: False Advertising, Breach of Contract, Bad faith Breach of Contract, Fraud and Deceit.
It is our desire to inform you of the foregoing and afford you the opportunity to cure said breach.
You may in any event be held responsible for all damages arising from said breach.
To view a copy of the complaint please visit our company website: http://---URL REMOVED---/
Please use the CASE ID located at the end of the document to find the copy of the complaint.
You have until 10th of May 2010 to cure said breach, after which we will be forced to pursue further legal action.
Regards,
Jim Karter
CASE ID: 4322524