A very important “internet trust” discussion is underway that has been hidden behind closed doors for years and in part, still is. While the Comodo , Diginotar, and Verisign Certificate Authority breaches forced discussion and action into the open, this time, this “dissolution of trust” discussion trigger seems to have been volunteered by Trustwave's policy clarification, and followup discussions on Mozilla's bugzilla tracking and mozilla.dev.security.policy .

The issue at hand is the willful issuance of subordinate CAs from trusted roots for 'managing encrypted traffic', used for MitM eavesdropping, or wiretapping, of SSL/TLS encrypted communications. In other words, individuals attempting to communicate over twitter, gmail, facebook, their banking website, and other sensitive sites with their browser may have their secure communications unknowingly sniffed - even their browser or applications are fooled. An active marketplace of hardware devices has been developed and built up around tapping these communications. In certain lawful situations, this may be argued as legitimate, as with certain known DLP solutions within corporations. But even then, there are other ways for corporate organizations to implement DLP. Why even have CA's if their trust is so easily co-opted? And the arbitrary issuance of these certificates without proper oversight or auditing in light of browser (and other software implemented in many servers and on desktops, like NSS ) vendor policies is at the heart of the matter. Should browser, OS and server software vendors continue to extend trust to these Certificate Authorities when the CA’s activities conflict with the software vendors’ CA policies?

The Adobe AIR and Adobe Flash Player Incubator program updated their Flash Platform runtime beta program to version 5, delivered as Flash Player version 11.2.300.130. It includes a "sandboxed" version of the 32-bit Flash Player they are calling "Protected Mode for Mozilla Firefox on Windows 7 and Windows Vista systems". It has been over a year since Adobe discussed the Internet Explorer ActiveX Protected Mode version release on their ASSET blog, and the version running on Google Chrome was sandboxed too.

Adobe is building on the successes that they have seen in their Adobe Reader X software. Its sandbox technology has substantially raised the bar for driving up the costs of "offensive research", resulting in a dearth of Itw exploits on Reader X. As in "none" in 2011. This trend reflects 2011 targeted attack activity that we’ve observed. 2011 APT related attacks nailed outdated versions of Adobe Flash software delivered as "authplay.dll" in Adobe Reader v8.x and v9.x and the general Flash component "NPSWF32.dll" used by older versions of Microsoft Office and other applications. Adobe X just wasn't hit. IE Protected Mode wasn't hit. Chrome sandboxed Flash wasn't hit. If there are incident handlers out there that saw a different story, please let me know.

The SSL PKI has been in use and implemented for 15 years now to secure online communications. From its initial proprosals and immediate growth, the need for secured online communications has been met with challenges. The infrastructure and protocol itself is showing signs of wear, with multiple attacks and corrections to the scheme itself. And in its 15th year, an alternative to the Cerificate Authority infrastructure is finally being given some competition with the release and debate around Convergence, an open source alternative to the current system of Certificate Authorities. Feel free to right click and download for the full sized version; the graphic below provides a list of some of the major events for SSL/TLS PKI in the past 15 years.

Overshadowed by the Duqu madness yesterday, Oracle released a slew of critical updates (please see "Related Links" in the right column of this page). Most interesting, but perhaps with little impact, is the Java SE BEAST update. Oracle claims to have pushed 57 different fixes across their product lines, including patches for Java and their virtualization Sun Ray product. But the hottest thing to talk about, of course, is the patch closing up CVE-2011-3389, or holes in the JSSE.

The BEAST researchers' demo at Ekoparty Argentina that we posted on last month developed a fresh exploit to crack SSL/TLS sessions with a technique described almost a decade ago. The trick is always in the implementation, not the discussion, so it was impressive work that left the major software vendors with some heavy work. That list of vendors included Oracle, because the exploit developed for the demo abused vulnerabilities in Java code (the researchers claimed that vulnerabilities exist in Microsoft's Silverlight and Javascript code too, they just didn't deliver the exploit in those forms. Unfortunately, Silverlight BEAST exploit code is publicly available). The exploit almost turned into more of a disaster when Mozilla considered blocking all Java add-on use from their browsers: "We are currently evaluating the feasibility of disabling Java universally in Firefox installs and will update this post if we do so." So, it is somewhat surprising that Oracle rated this fix low within their risk matrix with a "Base Score" of 4.3 (on a scale of 1-10, with 10 being the most risk).

Meanwhile, Oracle gives six different Java patches a base score on their risk matrix of "10", with four of those highest risk level patches impacting the recently released Java 7. They impact logic within the JRE itself, AWT, Deserialization, and Scripting components within the JRE.

I've seen Oracle's virtualization product "Sun Ray" adopted in a variety of corporate cloud situations, and cloud admin should be aware that the platform is impacted with a fix for CVE-2011-3538 and related authentication issues.

With headlines like "New cyber threat compromises financial information - Experts say new threat could affect millions of sites", you would think that the trust model of the internet is finally crumbled.

Following an hour long Friday evening wait for the demo, the Ekoparty demo for the SSL hack was staged. And it was interesting that the attack succeeded in cracking the SSL confidentiality model as implemented by the Mozilla Firefox browser when communicating with paypal.com web servers over https. At the same time, it seemed to be an impractical exploit targeting a weakness that was fixed three months ago in Chromium source code.

Also of note, is the fact that the attack has been well known for almost 10 years, it's just that there hasn't been a practical exploit implementing the attack. And that they refined their blockwise attack model far better than previous chosen-plaintext attack models, making it more effective than prior attacks.

So there seems to be another good security reason to use Google's Chrome browser, for those of you highly sensitive to security issues. Also interesting were some of the tricks they used to make it work. While they couldn't get it to work in pure javascript or flash, they implemented the exploit in a Java applet and attacked the stream between Firefox and https://paypal.com. The "tricks" they used to bypass "Same Origin Policy" with Java were surprising, and they came up with the entire stolen session cookie with which to log in to paypal.com as the victim over http in under three minutes. While I am sure that the other browser vendors will update their CBC encryption routines to better randomize their IV and overcome this attack as suggested almost ten years ago, one could use Chrome and maintain secure communications in regards to this exploit. To me, this exploit is a low risk one because of its impracticality. Whether they properly disclosed their work to all browser vendors, giving developers plenty of time prior to disclosure remains a question to me, but they did contact at least the Chrome team. Interesting research and impressive effort implementing a difficult to work concept certainly. These guys know crypto and communications technologies. But the sky has not fallen. Yet.

For related technical information, and thoughts from relevant developers and researchers, please check out my "Related Links" list to the right side of the post text. I try to be thorough in my selection.

UPDATE(9/26): Microsoft advises that they are investigating the matter for their Internet Explorer browser customers, stating that the issue is low risk anyways, "Considering the attack scenario, this vulnerability is not considered high risk to customers". Perhaps they were one of the browser vendors that were not contacted about the vulnerability.

The Democratic Party of Hong Kong's website was compromised and malware uploaded to the web server. Interestingly, the server was distributing malicious flash and spyware nearly identical to the compromised UK Amnesty International servers at the beginning of this month. The server is being cleaned up.

The english version of the website did not include injected iframe links pointing to the exploit.html page, which in turn delivers three different version-appropriate malicious variants of flash detected by Kaspersky as "Exploit.SWF.CVE-2011-0611". The malicious flash was 0day at the beginning of this month, and will be effective on unpatched systems.

Instantly this news became  very fruitful  for all kinds of cybercriminals. Here is  some of the proof we found:

1) SEO optimized Google image searches leading to a malicious site with the exploit for the “Help Center URL Validation Vulnerability”. The exploit drops into the system a malicious executable file which is a password stealer malware. 

At the moment we found it, Kaspersky Anti-Virus detected the sample as Heur.Trojan.Win32 .  Meanwhile the Jotti multiscanner results were 1/20

The exploit also works with Opera and Firefox browsers by dropping into the system a malicious PDF file:

2) SEO optimized for all non-Russian Google searchers leading to Rogue AVs, in particular to “XP Anti-Virus 2011” which  actually  is quite  aggressive in blocking Internet access and extorting money for the activation

The infection scheme is quiet simple: a victim looks for pictures with the topic “Royal Wedding” and when the click comes with a Google reference a special malicious script redirects the victim to a malicious .cc domain with a classic Fake AV window.

3) Scams related to a fake Satellite TV where a victim should pay for the fake service. And of course, the credit card is being stolen once the payment is accepted.

4) Spam on Twitter just abusing TT and leading to misc. junk content sites

We highly recommend using the latest patched Browser with a plugin like NoScript, don’t click on any unknown link, and keep your AV updated and real-time protection working.

Firefox (FF) users should be aware of a use-after-free vulnerability affecting Firefox versions 3.6.11 and earlier. The security team at Firefox has been working on getting a patch out since at least early Tuesday morning, delivering a v3.6.12 release candidate available for brave nightly build developers and testers last night.

A zero day exploit attacking this vulnerability was used at the compromised Nobel Peace Prize website to drop a trojan on unsuspecting visitors' systems, although the 0day was limited in that it did not implement well known ROP or JOP techniques (link to zipped pdf of VB2010 presentation slides) to effectively attack defensive technologies on newer Windows Vista and 7 platforms like DEP and ASLR. It effectively attacked newer FF on older versions of Windows.

To deal with this inadequacy, the attackers' javascript unusually checked for only newer versions of Firefox browsers and older versions of Windows. It only delivers the exploit code for those combinations. The writers must have felt rushed to get this exploit out.

Firefox users also can prevent attacks on the vulnerability by using the NoScript add-on or disabling javascript in their FF browser. Kaspersky Internet Security detects and prevents the exploit code as Exploit.JS.CVE-2010-3765.a.


UPDATE: Mozilla Firefox build 3.6.12 is out! In Firefox 3.6.11, you can click Help -> Check for updates... It includes the patch for msfa2010-73, "Heap buffer overflow mixing document.write and DOM insertion", a problem otherwise described as the previously posted "use after free". Readers interested in technical details of the vulnerability should check out the bug link previously posted above, the report "Interleaving document.write and appendChild can lead to duplicate text frames and overrunning of text run buffers" is now open to the public. Updating Firefox v3.6.11 takes under a minute, but requires a Firefox restart. The browser makes a best effort to restore any tabs that you may have had open at time of restart.

At this point, I suppose the dirty secret buried amongst the "FF 0day are rare!" hype is that the numbers of users hit with this stuff right now are extremely low, for both the Firefox exploit itself and the "Belmoo" trojan that was delivered with it. But now is not the time to be lackadaisical about patching or maintaining security software -- the exploit will predictably be enhanced with ROP (or other DEP/ASLR bypasses) and added to pages all over the web over the next couple of weeks and the following months. Dependent rss reader software is vulnerable too, so expect updates to those packages, and be aware that they run javascript and may be vulnerable.

Over the course of last weekend I was busy setting up some new systems.
During that process I came across an old virtual machine that I decided to fire up.

Upon launching Firefox on that machine I was greeted by the following:

Now what's wrong with this picture? Quite a lot if you take a good look.

The Fire of London began on the night of September 2, 1666, as a small fire on Pudding Lane, in the bakeshop of Thomas Farynor, who was King Charles 2nd's baker. The story goes that one of the servants woke up around midnight to find the house on fire. By eight o'clock the next day, the fire had spread halfway across London Bridge, destroying around 80% of the city and killing nearly a fifth of the population. An example of how quickly a minor incident can turn into a major disaster.

The Mozilla Foundation Security Advisories 2005-43 and 2005-44 deal with two serious vulnerabilities which can be found in the popular Firefox browsers, versions up to 1.0.3, included. The vulnerability was announced last weekend, and it's taken the Firefox developers a long four days to come out with a patch, test it and release it to the public.

In a normal development cycle, four days from patch development to release a fix is an extremely short period of time. In comparison, Internet Explorer patches are released on a monthly basis, and it's not uncommon to wait as long as three weeks for a fix to a critical security bug. Of course, this methodical development cycle is one of the reasons why many users have switched to Firefox, and it's encouraging to see the level of dedication and commitment the Mozilla developers put into maintaining the security of their products.

In a world where virus writers, adware developers and hackers are constantly searching for ways to infect your systems, a timely response to security issues is a must. Sometimes even a day, or why not, an extra hour can matter. And sure enough, there are reports of the above mentioned Firefox bugs already being exploited on the Internet. I don't want to think what might have happened if we had had to wait another another month for the patch.

You can get the Firefox 1.0.4 update here.