Black Hat researcher, Moxie Marlinspike revealed SSL VPN vulnerabilities that attackers can use to hijack the auto-update functionality in Mozilla Firefox (all versions but 3.5.x) to infest your computer with malware. Fortunately, the attackers are limited to man-in-the-middle attack vectors. However, there are quite a few plausible scenarios available to them. For now, disable Firefox auto-update until Mozilla definitively deals with this.

The fundamental vulnerability in SSL VPN is an authentication and validation issue. Attackers can take advantage of nearly every web browser. When a web browser negotiates an https or ssl tunnel, if it finds the server’s certificate to be invalid, it warns the end-user and/or terminates the tunnel session. However, if an attacker pretending to be the server the end-user wishes to engage instead replies with an online certificate status protocol (OCSP) response message known as “Try Later”, most web browsers will proceed normally with no indication of risk. Further, OCSP “Try Later” does NOT require any response status. This effectively bypasses validation of a server’s digital signature, or authentication.

This has implications far beyond Mozilla Firefox and I’ll explore this in another post. For now, remember or read my post on the merits of using multiple web browsers.

Here, let’s look at this Mozilla Firefox risk. After you launch Mozilla Firefox, if it has automatic updates enabled, it phones home to check for updates. If an attacker can intercept these messages, the attacker can fool Mozilla Firefox into accepting a fake update.  The attacker could install just about anything.

This requires a man-in-the-middle attack and there are plausible scenarios. In the enterprise, a single infected machine can be the attackers “man” in the middle, using a variety of methods, most likely DNS poisoning. If a LAN’s network administrators are particularly effective, they would snuff out a DNS poisoning attack. If they’re not around or not aggressive, users are at risk.

People are most at risk in shared broadband Internet access areas such as public Wi-Fi, weakly secured private Wi-Fi, and hotel broadband.

Home users are at low risk if their Internet access is all wired because a man-in-the-middle attack would require a wire-tap or breach in your ISP. If any part of their access is wireless, they are only at risk in as much as they are at risk from wireless war-driving where hackers would be driving around their neighborhood. A WPA2 configuration in a home wireless LAN will curb these risks. WEP wireless security, on the other hand, common in home wireless, is completely useless.

The good folks at Mozilla just need to disable this OCSP “Try Later” capability. There will probably be an update available or a “workaround” that does so within a week. Obviously, implement the update where your risks from man-in-the-middle attack are low.

AppGuard and AppGuard Enterprise Plus Users

As you know, AppGuard and AppGuard Enterprise Plus do not allow guarded applications to update themselves until you suspend one or more of these protections. Of course, there is the exception where the update is performed by another process as is the case for Microsoft and Apple software applications.   Technically, you do NOT have to disable Firefox auto-updates. However, as you may at some point “Suspend All” for whatever reason, you might as well disable auto updates. Doing so takes less than a minute.

Instructions for Disabling Mozilla Firefox Auto Updates

From the main menu in Firefox, select “Tools” and from it select “Options…” Go to the “Advanced” tab and uncheck all of the update boxes.

Uncheck the Checkboxes As Shown

[UPDATE]

An unconfirmed report states that Moxie Marlinspike says that Mozilla has corrected this issue in Firefox 3.5.  Users of 3.x versions of Firefox, however, remain vulnerable to these attacks.

Related Articles

Disable Non-Microsoft/Apple Software Auto Update Features

Why Should UnPatched PC Software Concern You?

Secunia Casts More Doubt on Signature-based-Only Anti-Malware Defense

Posted: Friday, July 31st, 2009 - Endpoint Security
RSS 2.0 - Comment - Trackback