4 X Security Team

After years of lagging behind on important security features, Apple has finally added a malware-blocker, a phishing filter and support for EV (extended validation) certificates into the latest refresh of its Safari Web browser.

The malware roadblock headlines a list of Safari 4 security features that also includes cookie blocking, private browsing, secure encryption, safe downloads and parental controls.

[ SEE: PayPal: If a browser doesn't have anti-phishing technology (like Safari) ditch it ]

Apple has been heavily criticized in the past for neglecting basic security features in Safari. PayPal CIO Michael Barrett went so far as to suggest that end users should avoid the browser because of the missing protections.

Now, it looks like Apple has finally caught up. According to a source, the crucial malware block is powered by Google’s blacklist of malicious sites and will trigger a warning when a user lands at known malware sites.

Microsoft’s Internet Explorer, Mozilla’s Firefox and Opera all provide the ability to issue similar warnings.

The support for EV-Certs (see right) is also important. This allows Web surfers to easily identify legitimate Web sites and businesses. For sites that have an EV Certificate, Safari 4 will display the site’s name in green on the right side of the address field.

[Source: zdnet]

A security researcher wants Microsoft to follow the lead of other browser makers and start fixing Internet Explorer security problems outside of the Patch Tuesday cycle to help contain the Windows malware epidemic.

[ Microsoft: ‘Consistent exploit code likely’ for IE vulnerabilities ]

According to Wolfgang Kandek, chief technology officer at vulnerability management firm Qualys, IE’s dominant userbase and high risk profile exposes Windows users to a wide range of malicious hacker attacks but, despite years of warnings, business users are not rushing to install IE patches ahead of other critical updates (see chart below).

[ SEE: Hackers exploiting (unpatched) IE 7 flaw to launch drive-by attacks ]

The chart, powered by data collected by Qualys over the last six months, shows that critical IE patches are applied in very much the same speed as other high-priority updates.

I had a chat with Kandek about his findings and he was adamant that the risk presented by a critical IE vulnerability is higher than another critical flaw in another piece of software that doesn’t interact directly with the Internet.

• “Every month when Microsoft issues it security advisories we get asked what patch to apply first. Typically we are reluctant to elevate one vulnerability over the other, however looking at the 2008 data we agree that Internet Explorer vulnerabilities should be given the highest priority and patched first. The browser is the heaviest used software application that interacts with the Internet, the most likely source of malicious content. It is not only used for professional purposes but also in private interactions – e-commerce, social networking, private e-mail, etc. Browser patches are heavily tested by Microsoft and unlikely to break any existing functionality on the desktop.

Unfortunately, Kandek says the vulnerability data shows that companies treat browser patches just like all other patches — their deployment cycle correlates very closely with other critical patches.

The answer? Kandek argues that Microsoft should borrow from the Mozilla Firefox playbook and fit an automatic-update utility directly into IE to handle patching on the fly.

“Think about it. There’s a very big exposure area. Hackers are increasingly targeting the browser. Enterprises are on a tight patch schedule. If IE got moved out of Patch Tuesday, won’t it be better?” he added.

[ GALLERY: How to configure Internet Explorer to run securely ]

“Patches would be deployed faster and we would have a healthier IE population,” Kandek added, nothing that IE add-ons like Flash and other media players would benefit from an automatic update tool embedded in the browser.

The Qualys data was culled from 9.5 million IP scans per month.

* Hat tip to Gregg Keizer at ComputerWorld.

[Source: zdnet]

Mozilla’s flagship Firefox 3 browser has undergone another security makeover to fix at least 7 documented security vulnerabilities that expose users to malicious hacker attacks.

The Firefox 3.0.6 upgrade patches at least two critical Firefox flaws that may lead to arbitrary code execution attacks and another “high risk” bug that could be used to steal a victim’s data.

The raw details:

• MFSA 2009-06: Paul Nel reported that certain HTTP directives to not cache web pages, Cache-Control: no-store and Cache-Control: no-cache for HTTPS pages, were being ignored by Firefox 3. On a shared system, applications relying upon these HTTP directives could potentially expose private data. Another user on the system could use this vulnerability to view improperly cached pages containing private data by navigating the browser back.
• MFSA 2009-05: Developer and Mozilla community member Wladimir Palant reported that cookies marked HTTPOnly were readable by JavaScript via the XMLHttpRequest.getResponseHeader and APIs. This vulnerability bypasses the security mechanism provided by the HTTPOnly flag which intends to restrict JavaScript access to document.cookie. XMLHttpRequest.getAllResponseHeaders. The fix prevents the XMLHttpRequest feature from accessing the Set-Cookie and Set-Cookie2 headers of any response whether or not the HTTPOnly flag was set for those cookies.
• MFSA 2009-04: (Moderate severity) Mozilla security researcher Georgi Guninski reported that the fix for an earlier vulnerability reported by Liu Die Yu using local internet shortcut files to access other sites (MFSA 2008-47) could be bypassed by redirecting to a privileged about: URI such as about:plugins. If an attacker could get a victim to download two files, a malicious HTML file and a .desktop shortcut file, they could have the HTML document load a privileged chrome document via the shortcut and both documents would be treated as same origin. This vulnerability could potentially be used by an attacker to inject arbitrary code into the chrome document and execute with chrome privileges. Because this attack has relatively high complexity, the severity of this issue was determined to be moderate.
• MFSA 2009-03: (High severity) Mozilla security researcher moz_bug_r_a4 reported that a form input control’s type could be changed during the restoration of a closed tab. An attacker could set an input control’s text value to the path of a local file whose location was known to the attacker. If the tab was then closed and the victim persuaded to re-open it, upon restoring the tab the attacker could use this vulnerability to change the input type to file. Scripts in the page could then automatically submit the form and steal the contents of the user’s local file.
• MFSA 2009-02: (High severity) Mozilla security researcher moz_bug_r_a4 reported that a chrome XBL method can be used in conjuction with window.eval to execute arbitrary JavaScript within the context of another website, violating the same origin policy. Firefox 2 releases are not affected. Disable JavaScript until a version containing these fixes can be installed.
• MFSA 2009-01: (Rated Critical) Mozilla developers identified and fixed several stability bugs in the browser engine used in Firefox and other Mozilla-based products. Some of these crashes showed evidence of memory corruption under certain circumstances and we presume that with enough effort at least some of these could be exploited to run arbitrary code.

The patch is being released automatically via Firefox’s built-in update mechanism. This should be treated as a high-priority update for any user that has Firefox installed, whether you use the browser or not.

[Source: zdnet]

Mozilla is joining Microsoft and Opera on the browser patching treadmill.

The open-source group has rolled out the final security fix for the Firefox 2 branch and a new version of Firefox 3 to plug about a dozen security holes that could lead to remote code execution attacks, browser crashes and information disclosure issues.

[ SEE: ‘End of life’ beckons for Firefox 2 ]

In all, Mozilla released eight different bulletins with details on the security flaws. Three of the bulletins carry a “critical” label, meaning they can be exploited “to run attacker code and install software, requiring no user interaction beyond normal browsing.”

One of the bulletins carry a “high severity” rating, meaning it can be used by hackers “to gather sensitive data from sites in other windows or inject data or code into those sites, requiring no more than normal browsing actions.”

[ SEE: ‘Extremely severe’ vulnerabilities in Opera browser ]

The details:

• MFSA 2008-69 XSS vulnerabilities in SessionStore
• MFSA 2008-68 XSS and JavaScript privilege escalation
• MFSA 2008-67 Escaped null characters ignored by CSS parser
• MFSA 2008-66 Errors parsing URLs with leading whitespace and control characters
• MFSA 2008-65 Cross-domain data theft via script redirect error message
• MFSA 2008-64 XMLHttpRequest 302 response disclosure
• MFSA 2008-63 User tracking via XUL persist attribute
• MFSA 2008-60 Crashes with evidence of memory corruption (rv:1.9.0.5/1.8.1.19)

Some of the bugs only affect Firefox 3 so it is important for all Firefox users to apply the update that’s released via the browser’s automatic patching mechanism.

As I previously reported, Mozilla is not planning any more security and stability updates for Firefox 2. If you are still on the old version, also note that the Google-powered anti-phishing protection will no longer be available for Firefox 2 users.

ALSO SEE: As attacks escalate, MS readies emergency IE patch

* Image source: _sarchi’s Flicker photostream (Creative Commons 2.0)

[Source: zdnet]

DEFCON, the 9000+ attendee hacker conference in Vegas has become a sort of hydra conference. It has become more like a global fair than what most people think of conferences; even the badge is highly unique.

I say this because there are so many things to do at DEFCON, other than going to talks, that you could spend your whole weekend looking at the “World’s Largest Boar!”, so to speak. One of the CTF (Capture the Flag) contest winners this year actually exclaimed that he only made it to 2 talks in 12 years! I am also one of those individuals who barely get a chance to go to talks and now that the speaker pool is so diverse, it’s hard to find all of the “stuff” they release.

Before anyone has a chance to post “it’s all on the DEFCON CD dummy,” I want to challenge them to try. After a weekend of googling (which came back with few results) and making contact with some of the speakers, I provide you with a mostly accurate list of “stuff” that was released at DEFCON this year. If any of the information is inaccurate, or a tool is missing, please contact me and I will update this post.

Beholder – by Nelson Murilo and Luis Eduardo

Opera Software has shipped a new version of its flagship Web browser with fixes for at least seven documented security problems but details on one vulnerability — a cross-site scripting issue reported by Chris Weber– is being kept under wraps.

Opera warned that one of the seven flaws is rated “extremely severe” because of the risk of arbitrary code execution.

The skinny on what’s included in Opera 9.52:

• Advisory #1 (extremely severe): When Opera is registered as a handler for a given protocol, it can be started by external applications. In some cases, being started in this way can cause Opera to crash. To inject code, additional techniques will have to be employed. This bug affects Opera for Windows.
• Advisory #2 (highly severe): Scripts are able to change the addresses of framed pages that come from the same site. Due to a flaw in the way that Opera checks what frames can be changed, a site can change the address of frames on other sites inside any window that it has opened. This allows sites to open pages from other sites, and display misleading information on them.
• Advisory 3# (currently a secret): Fixed an issue that could allow cross-site scripting, as reported by Chris Weber of Casaba Security: details will be disclosed at a later date.
• Advisory #4 (moderately severe): Custom shortcut and menu commands can be used to activate external applications. In some cases, the parameters passed to these applications are not prepared correctly, and may be created from uninitialized memory. These may be misinterpreted as additional parameters, and depending on the application, this could allow execution of arbitrary code. Successful exploitation requires convincing the user to modify their shortcuts or menu files appropriately, pointing to an appropriate target application, then to activate that shortcut at an appropriate time. To inject code, additional means will have to be employed. This flaw affects Opera for Microsoft Windows, Linux, FreeBSD and Solaris.
• Advisory #5 (less severe): When insecure pages load content from secure sites into a frame, they can cause Opera to incorrectly report the insecure site as being secure. The padlock icon will incorrectly be shown, and the security information dialog will state that the connection is secure, but without any certificate information.
• Advisory #6: (less severe): As a security precaution, Opera does not allow Web pages to link to files on the user’s local disk. However, a flaw exists that allows Web pages to link to feed source files on the user’s computer. Suitable detection of JavaScript events and appropriate manipulation can unreliably allow a script to detect the difference between successful and unsuccessful subscriptions to these files, to allow it to discover if the file exists or not. In most cases the attempt will fail.
• Advisory #7 (not severe): It has been reported that when a user subscribes to a news feed using the feed subscription button, the page address can be changed. This causes the address field not to update correctly. Although this can mean that that misleading information can be displayed in the address field, it can only leave the attacking page’s address in the address bar, not a trusted third party address.

I’m happy to learn that IE8 is going to implement a less ambitious version of a feature which NoScript users have enjoyed for more than one year now. The announcement posts seem not to notice the resemblances of “XSS Filter” with NoScript’s Anti-XSS Protection, the most striking being their non-blocking approach: loading the target page in a “neutralized” form and emitting a warning as an info-bar, which doesn’t require interaction and therefore doesn’t necessarily interrupt user’s workflow. But that’s fine: in facts, under the hood, their filter looks quite less sophisticated than NoScript’s InjectionChecker engine, as it is based on a limited blacklist, apparently targeted to the most common reflective XSS attack patterns as seen in proofs of concept:

The XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. […]

The fact that our filter effectively blocks the common “>”… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.

Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8.

And there I started smiling: you realize, guys, that those listed “on sites like XSSed.com” are not “XSS vulnerabilities” which will “stop working in IE8″, but just minimal exploit test cases — alert("XSS") — which can be refactored and obfuscated in endless ways to obtain the “IE8 compatible” certification. Yeah, it will be great to see.

Ouch. Read on.

If Giorgio is correct (and I have no reason to doubt his knowledge on the subject), the IE 8’s anti-XSS filters are seriously lacking behind the widely popular NoScript plugin which protects the Firefox browser. I agree with Giorgio, there’s so many iterations of XSS attacks that this becomes extremely difficult to stop without a great amount of effort going into the black list. Here’s a few examples of outlier cases where XSS is still possible due to difficulties finding black list matches:

• Use of alternate encodings, similar to some of the UTF-7 attacks that were seen
• Use of regular UTF-8 encodings, i.e. %3c for < (ok, this is an easy one, they should have this)
• HTML attribute injection
  • If dynamic code looks like this:
    • Where “USERVALUE” is controlled by the user
  • Then attackers can supply an attack string like ” onfocus=alert(document.cookie)
  • This results in and an XSS attack
• Injection straight to JavaScript code
  • User supplied input goes directly into javascript code. Attacker must make previous JavaScript valid, but typically requires no <, >, or ” to make the exploit happen.

This all not to mention the numerous HTML tags that can be used, including things you’d never expect, like . It will be interesting to see how the IE 8 anti-XSS filter stands up to scrutiny by the community, but I do applaud them for the effort. At a minimum something is being done and progress is being made, if things turn out great, then we may have some of the NoScript features that protect Firefox.

This brings up an interesting question… why is NoScript not just a part of the Firefox browser, not simply a plugin?

Finally, is there any protection like this for Safari? I’ll answer that for you. There’s not.

[Source: zdnet]