6 posts • joined 15 Jul 2009
We can all learn from this...
After such a high profile site is compromised it serves as a good point in time to review all your systems to be sure you haven't made the same mistake...
1. Always use SSH password/passphrases on keys...
2. Make them complex and long.
3. Never allow inbound SSH to systems that can publish to the greater world, from the greater world.
4. Always check the checksums, but --not against-- the site you got the file from.... Software companies need to start publishing and signing the checksums separate from the website.
Blackhat, BIOS's, raising security awareness
As happens every year around this time, security gets a lot of attention... Blackhat, Defcon, and some vendors, like Intel, fessing up to coding errors and airing their own laundry. Although very different to the Blackhat presentation in terms of the flaw, this is increasing our awareness of how the growing sophistication of BIOSes and related technologies (Asus ExpressGate, etc) could compromise a system. All OS level software would consider these bits a rootkit merely because of their hidden/lower-level nature. The more concerning one disclosed by Core Security has more information available from our blog (without the hype.) http://www.sophos.com/blogs/sophoslabs/v/post/5716
Can't come soon enough...
Adobe's advice is interesting, however terribly incomplete and to some degree bad advice. Going to the linked article from Adobe it tells users to delete/disable authplay.dll. Of course this is of no use to Maq, Linux, or Solaris users whatsoever. On Linux at least the file in question appears to be /opt/Adobe/Reader9/Reader/intellinux/lib/libauthplay.so and on Mac it appears to be /Applications/Adobe Reader 9/Adobe Reader.app/Contents/Frameworks/AuthPlayLib.bundle. Of course, moving this file only protects you against malicious PDF's and not the Flash exploit.. And Adobe's advice for that? "Flash Player users should exercise caution in browsing untrusted websites." What the heck is a trusted site these days? And how are users to know if a site contains Flash??? I recommend using NoScript in the interim (http://noscript.net) to prevent flash from loading through ANY site until this hole is fixed.
Which leads to my next question.. When is Adobe going to provide tools to network admins to actually roll out these updates in a controlled manner? Without something better than a quarterly patch Tuesday its only a gesture towards really caring about the security of users of their products. These flaws are being actively exploited (http://www.sophos.com/blogs/sophoslabs/post/5524) so protect yourselves immediately!
Adobe can do better than this
The advice from Adobe is a bit lacking... Linux, Mac, and Solaris users are left to their own.. And I am not sure what an "untrusted website" is considering that many popular websites, ad networks, etc have been compromised the last 18 months.
Linux users should move their libauthplay.so somewhere or delete (usually in /opt/Adobe/Reader9/Reader/intellinux/lib). This does NOT protect against the Flash exploit, only against Flash in PDF files.
Mac users should move /Applications/Adobe Reader 9/Adobe Reader.app/Contents/Frameworks/AuthPlayLib.bundle (Just use Spotlight to search for AuthPlayLib in Applications).
Windows, Mac, and Linux users should use something like NoScript (http://noscript.net) rather than follow Adobe's advice of "exercise caution in browsing untrusted websites". We published more info on our blog, as this is being actively exploited in the wild (http://www.sophos.com/blogs/sophoslabs/post/5524).
Chet Wisniewski (@chetwisniewski)
I was not suggesting that people simply trust anything that is digitally signed, and clearly that is not the recommendation of Sophos, nor the manner in which our products are designed. The intent of the comment was directed towards users who are taught to look for the padlock in their browsers and consider that as some sort of validation that a website is secured. Clearly readers of El Reg are more sophisticated than most, and you are correct in pointing out that blindly trusting signed content means nothing.
Digital Signatures are only the beginning
It's interesting to me that it has taken this long for a "legitimate" signing certificate to be used for nefarious purposes. This is always a danger when a central authority like RIM or Verisign authorize someone to sign code/sites on their behalf without any oversight. This reminds me of how we used to tell users not to open .scr or .exe attachments, and now the baddies are using PDF and .ppt to infect via email. Now we can't simply inspect a file for an appropriate signature, we need to decide if we trust the publisher, and whether we need the update. We had published a blog article (http://www.sophos.com/blogs/sophoslabs/v/post/428) instructing users on being vigilant regarding signatures, perhaps this calls for an update.
I hope RIM takes some action regarding this abuse of trust...
- Opportunity selfie: Martian winds have given the spunky ol' rover a spring cleaning
- Spanish village called 'Kill the Jews' mulls rebranding exercise
- NASA finds first Earth-sized planet in a habitable zone around star
- New Facebook phone app allows you to stalk your mates
- Battle of the Linux clouds! Linode DOUBLES RAM to take on Digital Ocean