31 Jan Malicious Chrome extensions: a cat and mouse game Fabio Assolini
07 Feb Adobe Incubates Flash Runtime for Firefox Kurt Baumgartner
04 Nov Regaining Trust in the PKI Kurt Baumgartner
24 Sep The SSL Sky is Falling? Kurt Baumgartner
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
Google Chrome users are being targeted these days by a wave of attacks that uses malicious extensions hosted in the official Chrome Web Store. The attack appears to be of Turkish origin and is using Facebook to spread. We saw users of different nationalities infected with the malicious extensions, which the cybercriminals are sending to the official store regularly, in a cat-and-mouse game.
As we already reported in March 2012, Brazilian cybercriminals were able at that time to host a malicious extension in the Chrome Web Store. Since then in June 2012 Google has changed the way users can add third party browser extensions i.e. not allowing the installation that are not hosted on the official Web Store. More recently Google removed the possibility of silent installations, which has been widely abused by third parties.
Maybe for these reasons bad guys started to concentrate their efforts to upload bad extensions to the official store. Now its the turn of Turkish cybercriminals; they were able to host several extensions there in the last few days.
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.
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.
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.