There's a new phishing scam e-mail making the rounds claiming to be from the UK tax organization Her Majesty's Revenue & Customs, or HMRC for short. I've written a piece about this for Sophos' Naked Security blog.
I wanted to include some additional details that were less appropriate for the other article but might interest those interested in tracking phishing campaigns. The attachment is an HTML file that contains a basic form that uses the "post" method to submit the form contents to a server. The server is hosted at an IP address owned by Cybercity, a DSL ISP in Denmark:
http:// 94.145.238 .98/h/w.php
Attempting to visit the URL directly in a browser will redirect to the official HMRC site, www.hmrc.gov.uk; the same redirection occurs after submitting data via the form, obviously in an attempt to make the form submission seem to have been legitimate to unsuspecting victims.
Naturally, just because the IP is from Denmark doesn't mean that the scammer is from there. It could simply be the case that the scammer had remote access to a compromised machine that happened to be located in Denmark.
Here are the Web of Trust and IPVoid reports for this IP address:
https://www.mywot.com/en/scorecard/94.145.238.98
http://www.ipvoid.com/scan/94.145.238.98
As observed by URLVoid, the IP is currently on SURBL's phishing blacklist.
Out of the 43 antivirus engines on VirusTotal, only Sophos currently detects the file as malicious (Mal/Phish-A).
A somewhat amusing side note: I don't even live in the UK, nor have I ever traveled there—and the phishing e-mail was sent to an AOL.com (America Online) address—so this is obviously not a targeted phishing scam campaign by any means.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter or Google+.
Thursday, December 29, 2011
Monday, November 28, 2011
How to Update Apple's Safe Downloads List (XProtect.plist Malware Definitions)
UPDATE, 23 Oct 2013: None of these tricks work in OS X Mavericks (version 10.9). If you know of a way to manually check for XProtect updates in Mavericks, please leave a comment.
Apple just released an update for its XProtect.plist malware definitions file (which Apple calls the "safe downloads list"; this is kind of a misnomer because it's actually a list of unsafe downloads). The latest update appears to block a new version of a Trojan horse that masquerades as a Flash Player update, which Apple labels OSX.FlashBack.B. I thought this would be a good opportunity to share with my readers a few ways to manually force an update to Apple's definitions.
To briefly review, Mac OS X Snow Leopard and later (including Lion) include very basic protection against malicious downloads under certain circumstances. In May 2011, after the outbreak of MacDefender malware, Apple released a security update that enabled automatic updating of Mac OS X's built-in definitions file for Snow Leopard. Automatic updating has always been built into Lion since its initial release in July 2011.
Before you update your Mac OS X anti-malware download definitions, you should first make sure you have the latest version of Mac OS X installed (10.6.8 is the final version of Snow Leopard, and 10.7.2 is the current version of Lion as of when I'm writing this). You can check for updates by going to the Apple menu in the top-left corner of your screen and selecting "Software Update...".
After installing all available OS and security updates (and restarting your computer if necessary), you have a few options on how to check for updates to Apple's malware definitions:
As I've mentioned previously, Apple's (un)safe downloads list is not a replacement for true antivirus software. It mostly protects against Trojans downloaded through Safari, Mail, and other applications that add the "quarantine" flag to new downloads that may contain malicious content. Aside from that, Apple's built-in protection does not currently do much; it doesn't protect against viruses (such as Microsoft Word and Excel macro viruses), rootkits, worms, Windows malware, and so forth; all of these have unfettered access to invade and brutalize your Mac unless you've installed full-fledged antivirus software. Sophos has a free home edition for personal use which I like, ClamXav is free for anyone to use (although its features are very limited; it's primarily a manual system scanner, but it includes an automatic download scanner that you can manually configure), and Intego VirusBarrier isn't free but it's produced by a company that specializes in Mac security. A few other commercial options exist for personal or small business use (be sure to get a current version if you buy from anywhere other than the developer's site), and several major antivirus vendors sell enterprise editions of their software for medium to large organizations.
If you found this article useful, please share a link to it on your favorite social networks, and don't forget to subscribe using the links below!
For more from the JoshMeister on Security, please subscribe via e-mail or RSS and follow me on Twitter or Google+.
Apple just released an update for its XProtect.plist malware definitions file (which Apple calls the "safe downloads list"; this is kind of a misnomer because it's actually a list of unsafe downloads). The latest update appears to block a new version of a Trojan horse that masquerades as a Flash Player update, which Apple labels OSX.FlashBack.B. I thought this would be a good opportunity to share with my readers a few ways to manually force an update to Apple's definitions.
To briefly review, Mac OS X Snow Leopard and later (including Lion) include very basic protection against malicious downloads under certain circumstances. In May 2011, after the outbreak of MacDefender malware, Apple released a security update that enabled automatic updating of Mac OS X's built-in definitions file for Snow Leopard. Automatic updating has always been built into Lion since its initial release in July 2011.
Before you update your Mac OS X anti-malware download definitions, you should first make sure you have the latest version of Mac OS X installed (10.6.8 is the final version of Snow Leopard, and 10.7.2 is the current version of Lion as of when I'm writing this). You can check for updates by going to the Apple menu in the top-left corner of your screen and selecting "Software Update...".
After installing all available OS and security updates (and restarting your computer if necessary), you have a few options on how to check for updates to Apple's malware definitions:
- The first (and nicest) solution is to download Adam Christianson's Safe Download Version app from The Mac Observer's site (direct download link). This app automates the whole update process for you; it notifies you what version your current definitions are and their release date, lets you check for updates, and notifies you if you already have the latest version installed.
- The second option is to update via System Preferences (which you can find by clicking on the Apple menu and selecting "System Preferences..."). In the System Preferences main window, click on Security, then click on the General tab, then uncheck and re-check the box next to "Automatically update safe downloads list" (note that you may need to click on the lock and type an administrator password first). You won't get any feedback indicating whether the update process has completed; you'll just have to assume that it worked (this is why I prefer using Adam's Safe Download Version app mentioned above).
- The third option is to run either of the following Terminal commands (pick one):
sudo /usr/libexec/XProtectUpdater sudo launchctl start com.apple.xprotectupdater
You can copy and paste one of those into the Terminal (which you can find by clicking on the magnifying glass in the top-right corner of your screen and starting to type the word Terminal). After running either of those commands, you won't get any feedback indicating whether the update has run; you'll just have to assume it worked—or if you want to see whether the version changed after running the command (note that it may not; Apple often goes a long time in between updates), you can copy and paste this command before and after you run one of the commands above:
more /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
The XProtect.meta.plist file lists the date and version number of the XProtect.plist definitions file which is located in the same directory on your hard drive.
As I've mentioned previously, Apple's (un)safe downloads list is not a replacement for true antivirus software. It mostly protects against Trojans downloaded through Safari, Mail, and other applications that add the "quarantine" flag to new downloads that may contain malicious content. Aside from that, Apple's built-in protection does not currently do much; it doesn't protect against viruses (such as Microsoft Word and Excel macro viruses), rootkits, worms, Windows malware, and so forth; all of these have unfettered access to invade and brutalize your Mac unless you've installed full-fledged antivirus software. Sophos has a free home edition for personal use which I like, ClamXav is free for anyone to use (although its features are very limited; it's primarily a manual system scanner, but it includes an automatic download scanner that you can manually configure), and Intego VirusBarrier isn't free but it's produced by a company that specializes in Mac security. A few other commercial options exist for personal or small business use (be sure to get a current version if you buy from anywhere other than the developer's site), and several major antivirus vendors sell enterprise editions of their software for medium to large organizations.
If you found this article useful, please share a link to it on your favorite social networks, and don't forget to subscribe using the links below!
For more from the JoshMeister on Security, please subscribe via e-mail or RSS and follow me on Twitter or Google+.
Saturday, October 29, 2011
More Mac Malware, DroidSheep, and Opera
Mac malware is on the rise.
On September 23rd, an incomplete Trojan horse for Mac that disguises itself as a PDF was submitted to VirusTotal (possibly to test which vendors if any would detect it), and VirusTotal in turn redistributed it to antivirus vendors (see the F-Secure and Sophos blog posts).
Just three days later, on September 26th, Mac anvirus vendor Intego released a report about a new piece of malware that had been discovered in the wild by a single user, this time an actually functional Trojan purporting to be an Adobe Flash Player installer. This Trojan is fairly believable, in part because new Macs no longer ship with Flash preinstalled. Sophos later reported that the malware "could allow a remote hacker to gain access to your computer or download further malicious code to your Mac."
A few weeks later on October 19th, F-Secure discovered a new version of this so-called "Flashback" Trojan that destroys Apple's XProtect.plist updating mechanism, preventing Mac OS X's built-in malicious download definitions file from being able to update automatically by deleting the actual updater app from the hard drive.
As Sophos pointed out, Apple's CoreTypes/XProtect system provides only rudimentary protection against malicious downloads, and does not provide most of the functionality or protection offered by actual antivirus software. In my experience it always seems to be woefully outdated, and even if it were up-to-date it would still only provide extremely limited protection against files downloaded with certain applications like Mail and Safari. Unfortunately most home Mac users don't run any antivirus software, believing that it's unnecessary because "Macs don't get PC viruses" as Apple's marketing campaign hammered into TV viewers' heads a handful of years ago—and as Apple still ambiguously claims on its "Why you'll love a Mac" page.
Four days ago, this past Tuesday, October 25th (merely six days after the XProtectUpdater-deleting Flashback variant was discovered), ESET and Sophos reported that the Linux backdoor Trojan "Kaiten" had been ported to the Mac. Dubbed "Tsunami," it can be used by remote attackers to initiate a flood of traffic (a distributed denial of service or DDoS attack) to any target host on the Internet. Two days ago, ESET and Sophos reported on the discovery of an updated version of Tsunami.
After all that, you'd think there couldn't possibly be more Mac malware news this month, right? Sorry, no such luck.
This morning Sophos blogged about a new piece of Mac malware being distributed through BitTorrent (bundled with the legitimate Mac app GraphicConverter). This malware is called OSX/Miner-D or "DevilRobber," and much like various types of Windows spyware it slows down your machine, takes screenshots of what you're doing, steals your usernames, passwords, browsing history, and Bitcoin wallet if you have one, and more. Part of the reason it slows down your Mac is that it uses your processor cycles to try to generate new Bitcoins (if your unfamiliar with Bitcoins, you can refer to Security Now! episode 287 - video, audio, transcript - for more info).
If you had any lingering notion that Macs don't need antivirus software, I hope at this point you'll be convinced that additional protection is a good idea. I strongly recommend to my clients and friends who use Macs to install antivirus software, whether a commercial product like Intego VirusBarrier or a free product like Sophos Anti-Virus for Mac Home Edition (which I reviewed in the January 2011 issue of MacTech Magazine). I prefer Sophos because it's free for home use and there's no yearly cost to keep your definitions up-to-date, but if cost is not a concern for you (or you need antivirus protection for small business Macs), Intego may also be a good choice because the company specializes in Mac malware research. For Macs in enterprise, there are various remotely manageable antivirus solutions as well.
Firesheep is still out there. And now so is DroidSheep.
Hey, remember Firesheep? I've mentioned it before a couple of times. Well, it's still around, it's been downloaded roughly 2 million times, and many companies still don't seem to be too concerned about how easy Firesheep makes it for anyone to hijack user sessions and gain access to accounts of anyone on the same public Wi-Fi network (or private, WEP-"secured" network). When it was originally released, Firesheep sparked a firestorm of controversy and forced several major sites including Twitter and Facebook to improve their implementations of SSL/TLS. Although Firesheep has been available for just over a year now, many sites—including some major ones that deal with sensitive personal information—have done little or nothing to improve their security.
Last month, Kaspersky Lab reported on its Threatpost blog that Firesheep has a new portable cousin for Android. Known as DroidSheep, the app takes Firesheep a couple steps further than its original incarnation. First, it attempts to use DNS spoofing to make it work on WPA and WPA2 Wi-Fi networks. Second, it has a "generic mode" which allows an attacker to "see all cookies and capture more accounts" rather than being limited to recognizing a list of sites with handlers written specifically for each one.
In some cases, the worst an attacker can do after hijacking an account via Firesheep is to mess around with settings. Alltop, a news aggregation site, recently launched MyAlltop, a simple service that allows users to share their favorite news sites with others. I pointed out to Alltop co-founder Guy Kawasaki that the site's implementation lacked SSL/TLS encryption and I verified that it was vulnerable to Firesheep hijacking. I further explained that this meant an attacker could add or delete the news sites in a victim's public listing, either as a prank or an attempt at character assassination, for example to make it appear that an Alltop user supports political or social issues that they may be totally against. The biggest targets would be Alltop's list of Internet celebrities who regularly attend conferences where there's public Wi-Fi. Guy responded that "it's probably not a big problem" because people probably won't edit their MyAlltop settings very often, but I would argue that they may still have a browser tab from alltop.com open and may have never logged out, which would leave them vulnerable. Guy may be right that the attack scenario is too limited for most would-be hackers to be interested in messing around with other people's Alltop accounts at conferences. As for me, I would still prefer the peace of mind of having all the sites I use—even the less-critical ones—encrypted end-to-end whenever I'm logged in.
Certainly, potential Firesheep attacks on Alltop users are at the "mostly harmless" end of the attack spectrum. What about sites at the other end of the spectrum?
I'm currently working with a major company everyone knows—a past Fortune 500 company—that has been completely negligent about handling the Firesheep problem even though it seriously impacts the privacy, security, and personal safety of millions of people. As of right now I'm still in private discussions with the company trying to get them to fix their site security, but I may share more about this specific case in the future.
Opera is outdated in the Mac App Store. Again.
I don't know whether I should find this more amusing or disappointing, but once again Apple's Mac App Store is distributing an outdated and insecure version of the Opera browser. The past several times that Opera Software has released security updates for its browser, the new version hasn't made it to the Mac App Store until after I have personally contacted Apple and Opera to report the issue. (I'm not quite sure why it's incumbent upon me to remind them to do their jobs.) You might think that by now they'd have the process figured out and would start releasing the Mac App Store version simultaneously with the version on Opera's site, but sadly such has not been the case.
This time, on October 19th—ten days ago—Opera 11.52 was released, yet again fixing a vulnerability that Opera Software says is of "Critical" severity. I've been extremely busy with my Ph.D. program the past few weeks, so I haven't had the opportunity to remind Apple and Opera to update the version in the Mac App Store, and as of today, 11.51 is still the latest version available for download. I'm kind of curious how long it will take them to discover the problem on their own. UPDATE: Version 11.52 was added to the Mac App Store in the early hours of November 1st. Given the timing in relation to when this article was published (just over 48 hours apart), I suspect that either a reader tipped off Apple and/or Opera about this or an employee from one of the companies took notice.
As always, I advise users of Opera for Mac to download it directly from the Opera site at http://www.opera.com/download/ — and make sure you download other free applications directly from their respective developers' sites, too.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter or Google+.
Saturday, September 10, 2011
Apple Ends Security Updates for 5-Year-Old Macs
Looking for info about more recent Macs? See my 2013 article, "What to Do if Your Mac Can't Run OS X Mavericks."
It's official—Apple has stopped releasing security updates for Macs with PowerPC G4 or G5 processors. Macs purchased as recently as 5 years ago are now left exposed to known security vulnerabilities.
Yesterday, Apple released Security Update 2011-005 to fix the DigiNotar issue (which I have covered extensively on this site). The update was only released for Mac OS X v10.6 "Snow Leopard" and Mac OS X v10.7 "Lion," both of which can only run on Intel-based Macs.
Until yesterday, Apple had been releasing security updates for Mac OS X v10.5 Leopard, the final version of the Mac operating system that is compatible with G4 and G5 processors. Prior to Apple's transition to the Intel architecture in 2006, all Macs had been based on the IBM/Motorola PowerPC G4 and G5 processors.
Apple began converting its entire line of Macs to Intel processors in January 2006 with the MacBook Pro (which replaced the PowerBook G4) and the iMac, followed by the Mac mini in February, the MacBook (which replaced the iBook) in May, the Mac Pro (which replaced the Power Macintosh G5) in August, and finally the Xserve in November 2006.
Those who purchased a pre-Intel Xserve in October 2006 have only owned them for 4 years and 11 months, and those who purchased a Power Macintosh G5 in July 2006 have only owned them for a little over 5 years. Most of these machines are still running perfectly fine, but Apple has completely cut them off from being able to receive critical security updates ever again.
This poses a problem for some businesses and consumers who were not expecting to have to spend thousands of dollars on new hardware this year; note that the Xserve and Power Macintosh G5 in particular were high-end hardware and the most expensive models. For businesses that purchased a large number of Macs prior to the Intel transition, for example schools with computer labs full of iMacs purchased at the beginning of the 2005 school year, the cost of replacing all of the 6-year-old computers at once may be particularly burdensome due to economic factors including budget cuts in education. If they cannot afford to buy that many new Macs this year, they may be forced to seek alternative solutions such as replacing their Macs with sub-$400 Windows PCs.
Apple has a history of only releasing security updates for the most recent and one previous major release of its Mac OS X operating system (in this case, Lion and Snow Leopard, respectively). Apple typically continues to release security updates for some of its software, in particular Safari and QuickTime, for the two-versions-old release of Mac OS X (in this case, Leopard). Consistent with this track record, Apple released Safari 5.0.6 (a security-only update for Leopard) this past July at the same time as it released Safari 5.1 as part of Lion and as a free upgrade for Snow Leopard. In August, Apple released QuickTime 7.7 for Leopard, which was also a security-only update. Apple also releases non-security iTunes updates for two-versions-old releases of Mac OS X for a period of time; iTunes 10.4.1 was released for Leopard in August.
It should be clearly understood that security updates for Safari and QuickTime are not sufficient to make Leopard safe and secure. Since Apple is not releasing updates for the operating system itself, whenever new vulnerabilities are discovered that affect the core of Leopard, Apple will do nothing to help protect Leopard users from these vulnerabilities. So far, Security Update 2011-005 has been the only core OS security patch that Leopard has missed, and since it only addresses the DigiNotar issue, Leopard users can manually protect themselves by deleting the DigiNotar Root CA from the Keychain Access application in Leopard. Future security updates, however, may not be as easy—or may not be possible—to implement manually. For example, given that Apple has historically treated Java security updates the same as Mac OS X updates (only patching Java for the current and one previous version of Mac OS X), don't expect Apple to ever release any more Java security updates for Leopard. As of last year, Java was exploited more often than Adobe Reader and Flash. Last October, a Mac variant of the Koobface malware was found in the wild that installed itself via a Java applet.
Speaking of Flash, users of Leopard on PowerPC-based Macs should be aware that Adobe stopped releasing Flash Player updates for PowerPC in February of this year, beginning with Flash Player 10.2. As of February, Adobe no longer releases security updates for Flash Player 10.1 or Flash Player 9.0, so PowerPC Mac users have been vulnerable to numerous Flash vulnerabilities that have been widely exploited in the wild.
For now, G4 and G5 users running Leopard can hold out on buying an Intel-based Mac for a bit longer if absolutely necessary, as long as they manually implement a few security tweaks. First, they should manually delete the DigiNotar Root CA from their systems. Second, they should disable Java in all browsers. Third, they should uninstall Flash Player (the uninstaller for Flash Player 10.1 is located on the hard drive at /Applications/Utilities/Adobe Flash Player Install Manager.app). If Flash is absolutely necessary for a few trusted sites, users can install the insecure final version of Flash Player 10.1 (.zip file containing a .dmg with Flash Player 10.1.102.64) and block Flash content by default using a browser add-on. Safari 5.0.6 users can block Flash content using the ClickToFlash extension. Flash-blocking add-ons for Firefox 3.6.22 (currently the newest official release that supports PowerPC Macs, although Mozilla says they'll only continue updating it for a short time) include Flashblock and the much more full-featured (but more difficult for novices to use) NoScript. After Mozilla stops releasing security updates for Firefox 3.6.x, you can switch to TenFourFox, an unofficial PowerPC version of Firefox based on more current releases, although it does not support Flash. Regardless of these temporary and limited workarounds, users of PowerPC-based Macs running Leopard would be wise to consider upgrading to newer hardware—Mac or otherwise—as soon as possible.
Another alternative, which many Mac users will find unsatisfactory, is to try using the latest release of Ubuntu Linux for PowerPC as an alternative to Leopard. Those who try Ubuntu for PPC will likely be disappointed by the limited PowerPC support from third-party Linux software developers.
Early adopters of Intel Macs may have cause for concern a couple years down the road, but as long as they have upgraded to Snow Leopard they should be fine for now. Users of early Intel Macs should be aware that if Apple continues its tradition of releasing a new version of Mac OS X every two years and only releasing security updates for the current and one previous version of the OS, they too could be left in the cold around 2013. Snow Leopard was the last release of Mac OS X to support the original Core Duo and Core Solo processors. Intel iMacs and MacBook Pros shipped with a Core Duo processor prior to September 2006, and MacBooks shipped with a Core Duo until November 2006. Mac minis did not receive a Core 2 Duo processor until August 2007. (The Mac Pro and Xserve initially shipped with Xeon processors, which are Lion-compatible.) Assuming a summer 2013 release date for Mac OS X v10.8 (which is highly speculative and based solely on Apple's typical two-year release schedule), Mac minis sold in July 2007 could cease to get security updates just 6 years after purchase.
Meanwhile, Microsoft will continue to offer security updates for Windows XP, the first version of which was released in 2001, until April 2014—12.5 years after the operating system's initial release. At first glance, this makes Apple's dropping of support for 5-year-old computers look especially bad. However, Microsoft allowed PC manufacturers to sell Windows 7 PCs "downgraded" to Windows XP (that is, with Windows XP preinstalled) as recently as October 2010, so users who bought Windows XP computers then will only receive updates for their installed operating system for a total of 3.5 years. The major difference is that unlike Mac users, Windows XP users will have the option to reformat their systems and install a newer version of Windows after the April 2014 deadline; PowerPC Mac users have no similar option because their hardware is no longer supported, not just their operating system. For all consumer versions of Windows from at least XP onward, Microsoft has supported hardware much older than it would be reasonable to continue using; for example, Windows 7's minimum requirements include a 1 GHz processor and 1 GB of RAM, which includes Pentium III systems purchased 11 years ago (which would be excruciatingly slow running Windows 7). Basically, Microsoft lets its users figure out when enough is enough based on the speed and usability of their hardware, which is radically different from Apple's approach of terminating support for hardware that many users still find quite usable for their needs.
Although Apple's philosophy is to ensure only the best experience for users of its products, some might also see Apple's position as a conflict of interest; unlike Microsoft, Apple manufactures the hardware as well as the software, and ceasing to support hardware in a new OS release is a subtle way of forcing users to spend money on new hardware. Apple has high profit margins, with an estimated average net profit of $370 per Mac sold. There's a fine line between ensuring that customers have the best possible experience and artificially expiring hardware to drive hardware sales.
Apple should consider supporting Mac hardware for at least a few years longer than it has been in recent years. If Apple had chosen to support the last generation of G4/G5 Macs with Snow Leopard, and the first-generation Intel Core Solo/Duo Macs with Lion, it would have added an additional two years onto the life cycle of each hardware platform. For many Apple customers, having to throw away their hardware and spend $1,000 or more on a new computer every 5 or 6 years (or risk being exposed to security exploits) is not a very reasonable solution.
Incidentally, Apple only released iOS updates (including security updates) for approximately 2.5 years after the original iPhone and the iPhone 3G initially went on sale, meaning that those who bought an iPhone just prior to when the new model was released (or bought the old model at a discount after the new model was released) only received security updates for their device for about 1.5 years. In the United States, cell phone contracts typically last 2 years, which meant that late-buyers were potentially left vulnerable for several months until their carrier allowed them to buy a new phone at the regular price. Fortunately for iPhone 3GS users, Apple plans to release a (slightly feature-limited) version of the upcoming iOS 5 for the 2-year-old iPhone 3GS, which is still being sold alongside the iPhone 4. The successor to the iPhone 4 is widely expected to ship next month, and some have speculated that the iPhone 3GS will be replaced by the iPhone 4 as the lower-priced model, but only time will tell how much longer AT&T and international carriers continue to sell the 3GS. It will be interesting to see how much longer Apple continues to release iOS updates for the 3GS; it's possible that late-buyers will again be left in the cold less than 2 years after purchase. Thankfully, at $199 with a two-year contract, iPhones are much more affordable than Macs (unless, of course, you factor in the monthly voice and data service fees), so having to buy a new iPhone every 2 years may be less of a financial burden for some people than being forced to buy a new Mac.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Wednesday, August 31, 2011
How to Revoke Trust for DigiNotar Root CA Certs on Mac and in Opera
You may have heard about Dutch root certificate authority DigiNotar issuing valid certificates for *.google.com—to an entity other than Google. The same thing has apparently happened with other high-profile domains as well, including but not limited to login.live.com (used for Hotmail, Bing, and other Microsoft services), login.yahoo.com, *.aol.com, my.screenname.aol.com, www.facebook.com, twitter.com, *.wordpress.com, *.microsoft.com, www.update.microsoft.com, *.windowsupdate.com, *.skype.com, *.logmein.com, *.mozilla.org, addons.mozilla.org, *.torproject.org, *.android.com, and three government intelligence sites: www.cia.gov (U.S. Central Intelligence Agency), www.sis.gov.uk (British Secret Intelligence Service, aka MI6), and *.mossad.gov.il (Israel's Institute for Intelligence and Special Operations). There were also certificates issued for *.*.com and *.*.org (hopefully browsers would be smart enough to distrust these). If you haven't heard the story, see these write-ups about various stages of the investigation written by (in chronological order) F-Secure, Sophos, SC Magazine UK, and Mozilla Security Blog, and a more technical and detailed explanation from Mozilla's Gervase Markham. As of 4 September 2011, the count of certificates that have been identified as fraudulent is up to 531 (listed here). On 5 September 2011, Fox-IT released the details of its DigiNotar systems audit (nicely summarized in English by Sophos).
Suffice it to say that this is a really bad thing, and it points to some of the problems with the certificate authority system in general (see what Dan Kaminsky has to say on that subject).
So, what can you do to protect yourself from illegitimate DigiNotar-issued certificates?
If you use Internet Explorer on Windows, ensure that you have all the latest Windows updates installed. (Microsoft quickly fixed the issue for Windows 7, Windows Vista, and Windows Server 2008, but it took Microsoft until 6 September 2011 to finally release patches for Windows XP and Windows Server 2003. On 13 September 2011, Microsoft released an updated version of the patch for all supported versions of Windows: XP, Vista, 7, Server 2003, and Server 2008.)
If you're a Firefox user, make sure you're running version 6.0.1 or later (or 3.6.21 or later if you're still using 3.6.x). Firefox 6.0.2 and 3.6.22 fix the issue more completely.
If you use Chrome, make sure you have version 13.0.782.218 or later. (Note that Mac users may not have been fully protected at first when using Chrome; my own tests seemed to indicate that on the Mac, Chrome behaved the same as Safari when handling certificates issued by DigiNotar. It appears that Chrome for Mac uses the certificates in the Mac OS X Keychain, not the certificates used in the Windows and Linux versions of Chrome. Apple has since released Security Update 2011-005 which removes DigiNotar from Mac OS X's trusted certificate authorities; see UPDATE 9 for details.)
(NOTE: On 9 September 2011, Apple released a patch to remove trust for DigiNotar certificates from Mac OS X. See UPDATE 9 below for details. Since Apple is no longer releasing security updates for Mac OS X v10.5 Leopard including all G4/G5-based Macs, you still need to manually delete DigiNotar Root CA from Keychain Access in Leopard.) If you use Safari on a Mac,there's no official fix from Apple yet, but you can manually revoke trust for DigiNotar-issued certificates by following these steps:
UPDATE 1: Edward Marczak (a personal friend, Google employee, and Executive Editor at MacTech Magazine) suggests deleting the certificate altogether rather than just disabling it. You can delete it right from within Apple's Keychain Access app using the basic steps outlined above (just right-click on the certificate and select "Delete 'DigiNotar Root CA'"). Ed also provides a tip for Mac sysadmins on how to delete the certificate via a Terminal command, which could be useful if you have remote shell access to the Macs you support.
I'll update this site again soon with instructions on how to block DigiNotar-issued certificates in the Opera browser.
UPDATE 2: On 30 August 2011, a member of the Opera security group blogged about why the company feels that Opera users are better protected against revoked certificates than users of other browsers (the blog post is titled "When Certificate Authorities are Hacked"). In spite of Opera Software's awareness of the issue, the company chose to release Opera 11.51 on 31 August 2011 without removing DigiNotar from its list of trusted root CAs. It's unclear why Opera Software has chosen not to remove it, but I strongly recommend either disabling or deleting the DigiNotar Root CA so you can more fully protect yourself. Here's how.
If you use Opera, make sure you are running the latest version and then follow these steps:
See UPDATE 7 below for Opera Software's current recommendations about securing the Opera browser and avoiding accidental installation of the DigiNotar Root CA when browsing to a site whose certificate was issued by DigiNotar.
Incidentally, long-time readers of this site will be unsurprised to know that the version of Opera in the Mac App Store is still the old version, 11.50. This is not the first (or the second) time that the Mac App Store has lagged behind on Opera security updates. Opera 11.51 fixes two security vulnerabilities, one of which Opera has classified as High Severity ("Unsecured web content may appear to be secure or trusted through Extended Validation") while the other is classified as Low Severity and its details have not yet been disclosed. If you use Opera on a Mac, you should download it directly from Opera's site, not from the Mac App Store.
UPDATE 3: According to Computerworld, Mac OS X does not properly handle extended validation (EV) certificates that the user or administrator has explicitly marked as untrusted. Until Apple fixes this glitch, the best way to avoid DigiNotar-issued certificates is to delete the root CA in Keychain Access (see UPDATE 1 above), or just use another browser such as Firefox 6.0.2 which has completely removed the DigiNotar Root CA.
UPDATE 4: I have added a list of several of the domains other than *.google.com for which DigiNotar issued fraudulent certificates, as well as a link to F-Secure's article on various DigiNotar hacks, and a link to Johnathan Nightingale and Gerv's articles (from 2 and 3 September 2011, respectively) about Mozilla's insights on the issue. Also, I should mention that the version of Opera in the Mac App Store was updated to 11.51 two days after its release, which is much better than the seven days that Apple typically takes to release security updates in the Mac App Store.
As of 3 September 2011, Microsoft still has not released a fix for Windows XP or Windows Server 2003 users, Apple has not released a fix for Mac OS X users, and Opera still has not seen fit to remove the DigiNotar Root CA from its browser.
It occurred to me that nobody seems to be discussing another serious aspect of the DigiNotar problem. So far all the discussion I've seen is how to fix the problem in Windows, Mac, and Linux. What about mobile platforms? Microsoft lists phones running Windows Phone 7 as "non-affected devices," but virtually every other mobile OS manufacturer has been silent about the issue. Apple has a knowledge base article showing that iOS 4.1 and later has DigiNotar Root CA as a trusted root certificate, which means that iPhone, iPad, and iPod touch are affected and currently have no protection. It is quite possible that other mobile platforms may be affected by this issue as well.
UPDATE 5: On 4 September 2011, I added some additional domains at the beginning of this article, and added a link to the source, Gerv's latest blog post. I also mentioned Firefox 6.0.2, which is now available for download and should become an automatic update (or obtainable by clicking on "Check for Updates" in the About Firefox window) later today.
UPDATE 6: Added links for the various Microsoft Windows patches (Microsoft finally released patches for Windows XP and Windows Server 2003). Added link to Sophos' summary of the Fox-IT audit from 5 September 2011. Clarified that Chrome for Mac appears to use the Mac OS X Keychain certificates rather than the custom certificates list used by Chrome for Windows and Linux. Also, I should mention that Mozilla finally released Firefox 6.0.2 officially today, 6 September 2011.
UPDATE 7: During the evening of 6 September 2011, Opera Software announced that it would finally begin dealing with the DigiNotar issue. For now, you still have to manually remove the DigiNotar Root CA if it exists in your copy of Opera, as I described in UPDATE 2 above. Opera Software implies that new installations of Opera (that is, when installing Opera onto systems that did not have it installed previously) will not include the DigiNotar Root CA by default. Opera recommends that if you visit a site with a DigiNotar-issued certificate and it triggers an "Unknown issuer" dialog, click "Reject".
UPDATE 8: It's unclear whether or not this has anything to do with the breach of DigiNotar's certificate security, but it serves as further evidence of how clueless the company was about computer security (as if we need any more convincing after the Fox-IT report): An article (auto-translated by Google) published 7 September 2011 claims that a DigiNotar building in the Netherlands has had a wide-open Wi-Fi network that a local group of hackers has utilized for the past 12 years. (Thanks to Erik Loman for sharing the link and F-Secure's CRO, Mikko Hypponen, for retweeting it.)
UPDATE 9: Apple has finally released an update (namely, Security Update 2011-005) for Mac OS X Snow Leopard version 10.6.8 and Mac OS X Lion version 10.7.1 that removes trust for DigiNotar certificates from the operating system (including the Mac version of Safari). You can read the details about the patch and download the Snow Leopard version or the Lion version of the patch as necessary. If you're unsure which version you need, just click on the Apple menu in the top-left corner of your screen and select About This Mac. From there you can see which version of Mac OS X you're running (if it says 10.5.8 or below, see UPDATE 10), and you can click on the "Software Update..." button to download all available Apple software updates.
UPDATE 10: On 13 September 2011, Microsoft issued a new update which replaced the KB2607712 patches. I had previously given direct links for all 14 versions of the KB2607712 patch in this article. Rather than link to all the new individual patches, I added a link to the new KB2616676 article which contains download links for all supported versions of Windows. Also, I updated this article to mention that Apple did not release (and has no plans to release) Security Update 2011-005 or any future security updates for Mac OS X v10.5 Leopard, including all G4/G5-based Macs, since both Leopard and all pre-Intel Mac hardware have reached the end of their support life cycle.
Also, as of 13 September 2011, Apple still had not released a security update for iOS, so all iPhones, iPads, and iPod touches are still vulnerable to attacks involving DigiNotar-signed certificates.
UPDATE 11: On 12 October 2011, Apple finally patched iOS. Users of iPhone 3GS/4/4S, iPad or iPad 2, or third or fourth generation iPod touch should install iTunes 10.5 (which was released yesterday) and then upgrade their device to iOS 5.0 afterward. Run Apple Software Update to upgrade iTunes, then plug in your device, then click on the device in iTunes, and then click on the "Check for Updates" button to download the latest version of iOS. If you have trouble downloading iOS 5.0 via iTunes, you can find individual download links here and instructions on how to manually install the update here. Apple has a list of security issues fixed in iOS 5.0 here.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Suffice it to say that this is a really bad thing, and it points to some of the problems with the certificate authority system in general (see what Dan Kaminsky has to say on that subject).
So, what can you do to protect yourself from illegitimate DigiNotar-issued certificates?
If you use Internet Explorer on Windows, ensure that you have all the latest Windows updates installed. (Microsoft quickly fixed the issue for Windows 7, Windows Vista, and Windows Server 2008, but it took Microsoft until 6 September 2011 to finally release patches for Windows XP and Windows Server 2003. On 13 September 2011, Microsoft released an updated version of the patch for all supported versions of Windows: XP, Vista, 7, Server 2003, and Server 2008.)
If you're a Firefox user, make sure you're running version 6.0.1 or later (or 3.6.21 or later if you're still using 3.6.x). Firefox 6.0.2 and 3.6.22 fix the issue more completely.
If you use Chrome, make sure you have version 13.0.782.218 or later. (Note that Mac users may not have been fully protected at first when using Chrome; my own tests seemed to indicate that on the Mac, Chrome behaved the same as Safari when handling certificates issued by DigiNotar. It appears that Chrome for Mac uses the certificates in the Mac OS X Keychain, not the certificates used in the Windows and Linux versions of Chrome. Apple has since released Security Update 2011-005 which removes DigiNotar from Mac OS X's trusted certificate authorities; see UPDATE 9 for details.)
(NOTE: On 9 September 2011, Apple released a patch to remove trust for DigiNotar certificates from Mac OS X. See UPDATE 9 below for details. Since Apple is no longer releasing security updates for Mac OS X v10.5 Leopard including all G4/G5-based Macs, you still need to manually delete DigiNotar Root CA from Keychain Access in Leopard.) If you use Safari on a Mac,
- Open the Keychain Access app (found in /Applications/Utilities or just search for it using the Spotlight menu in the top-right corner of your screen)
- Click on System Roots and then Certificates on the left side of the Keychain Access window. In the search bar in the top-right corner of the window, type "diginotar" (without quotation marks)
- Double-click on DigiNotar Root CA, click on the triangle next to Trust to expand that section, and then next to "When using this certificate:" select "Never Trust" (IMPORTANT: Please see UPDATE 3 below for an explanation of why it is actually better to delete the certificate altogether, and UPDATE 1 for details on how to do so)
UPDATE 1: Edward Marczak (a personal friend, Google employee, and Executive Editor at MacTech Magazine) suggests deleting the certificate altogether rather than just disabling it. You can delete it right from within Apple's Keychain Access app using the basic steps outlined above (just right-click on the certificate and select "Delete 'DigiNotar Root CA'"). Ed also provides a tip for Mac sysadmins on how to delete the certificate via a Terminal command, which could be useful if you have remote shell access to the Macs you support.
I'll update this site again soon with instructions on how to block DigiNotar-issued certificates in the Opera browser.
UPDATE 2: On 30 August 2011, a member of the Opera security group blogged about why the company feels that Opera users are better protected against revoked certificates than users of other browsers (the blog post is titled "When Certificate Authorities are Hacked"). In spite of Opera Software's awareness of the issue, the company chose to release Opera 11.51 on 31 August 2011 without removing DigiNotar from its list of trusted root CAs. It's unclear why Opera Software has chosen not to remove it, but I strongly recommend either disabling or deleting the DigiNotar Root CA so you can more fully protect yourself. Here's how.
If you use Opera, make sure you are running the latest version and then follow these steps:
- First, open Opera's Preferences window. If you're using Windows or Linux, you can do this by going to the Opera menu, then Settings, and then "Preferences...", or if you're using Opera on a Mac, just go to the Opera menu (next to the Apple menu) and select "Preferences..."
- Click on the Advanced tab, then Security on the left side, and then click on the "Manage Certificates..." button
- Click on the Authorities tab, then click on "DigiNotar Root CA", click the "View..." button, and put a check next to "Warn me before using this certificate" and then uncheck "Allow connections to use this certificate", and finally click OK (Alternatively, if you want to delete it altogether, click on the Delete button instead of "View...")
- Click OK to close the Certificate Manager window, then OK again to close the Preferences
See UPDATE 7 below for Opera Software's current recommendations about securing the Opera browser and avoiding accidental installation of the DigiNotar Root CA when browsing to a site whose certificate was issued by DigiNotar.
Incidentally, long-time readers of this site will be unsurprised to know that the version of Opera in the Mac App Store is still the old version, 11.50. This is not the first (or the second) time that the Mac App Store has lagged behind on Opera security updates. Opera 11.51 fixes two security vulnerabilities, one of which Opera has classified as High Severity ("Unsecured web content may appear to be secure or trusted through Extended Validation") while the other is classified as Low Severity and its details have not yet been disclosed. If you use Opera on a Mac, you should download it directly from Opera's site, not from the Mac App Store.
UPDATE 3: According to Computerworld, Mac OS X does not properly handle extended validation (EV) certificates that the user or administrator has explicitly marked as untrusted. Until Apple fixes this glitch, the best way to avoid DigiNotar-issued certificates is to delete the root CA in Keychain Access (see UPDATE 1 above), or just use another browser such as Firefox 6.0.2 which has completely removed the DigiNotar Root CA.
UPDATE 4: I have added a list of several of the domains other than *.google.com for which DigiNotar issued fraudulent certificates, as well as a link to F-Secure's article on various DigiNotar hacks, and a link to Johnathan Nightingale and Gerv's articles (from 2 and 3 September 2011, respectively) about Mozilla's insights on the issue. Also, I should mention that the version of Opera in the Mac App Store was updated to 11.51 two days after its release, which is much better than the seven days that Apple typically takes to release security updates in the Mac App Store.
As of 3 September 2011, Microsoft still has not released a fix for Windows XP or Windows Server 2003 users, Apple has not released a fix for Mac OS X users, and Opera still has not seen fit to remove the DigiNotar Root CA from its browser.
It occurred to me that nobody seems to be discussing another serious aspect of the DigiNotar problem. So far all the discussion I've seen is how to fix the problem in Windows, Mac, and Linux. What about mobile platforms? Microsoft lists phones running Windows Phone 7 as "non-affected devices," but virtually every other mobile OS manufacturer has been silent about the issue. Apple has a knowledge base article showing that iOS 4.1 and later has DigiNotar Root CA as a trusted root certificate, which means that iPhone, iPad, and iPod touch are affected and currently have no protection. It is quite possible that other mobile platforms may be affected by this issue as well.
UPDATE 5: On 4 September 2011, I added some additional domains at the beginning of this article, and added a link to the source, Gerv's latest blog post. I also mentioned Firefox 6.0.2, which is now available for download and should become an automatic update (or obtainable by clicking on "Check for Updates" in the About Firefox window) later today.
UPDATE 6: Added links for the various Microsoft Windows patches (Microsoft finally released patches for Windows XP and Windows Server 2003). Added link to Sophos' summary of the Fox-IT audit from 5 September 2011. Clarified that Chrome for Mac appears to use the Mac OS X Keychain certificates rather than the custom certificates list used by Chrome for Windows and Linux. Also, I should mention that Mozilla finally released Firefox 6.0.2 officially today, 6 September 2011.
UPDATE 7: During the evening of 6 September 2011, Opera Software announced that it would finally begin dealing with the DigiNotar issue. For now, you still have to manually remove the DigiNotar Root CA if it exists in your copy of Opera, as I described in UPDATE 2 above. Opera Software implies that new installations of Opera (that is, when installing Opera onto systems that did not have it installed previously) will not include the DigiNotar Root CA by default. Opera recommends that if you visit a site with a DigiNotar-issued certificate and it triggers an "Unknown issuer" dialog, click "Reject".
UPDATE 8: It's unclear whether or not this has anything to do with the breach of DigiNotar's certificate security, but it serves as further evidence of how clueless the company was about computer security (as if we need any more convincing after the Fox-IT report): An article (auto-translated by Google) published 7 September 2011 claims that a DigiNotar building in the Netherlands has had a wide-open Wi-Fi network that a local group of hackers has utilized for the past 12 years. (Thanks to Erik Loman for sharing the link and F-Secure's CRO, Mikko Hypponen, for retweeting it.)
UPDATE 9: Apple has finally released an update (namely, Security Update 2011-005) for Mac OS X Snow Leopard version 10.6.8 and Mac OS X Lion version 10.7.1 that removes trust for DigiNotar certificates from the operating system (including the Mac version of Safari). You can read the details about the patch and download the Snow Leopard version or the Lion version of the patch as necessary. If you're unsure which version you need, just click on the Apple menu in the top-left corner of your screen and select About This Mac. From there you can see which version of Mac OS X you're running (if it says 10.5.8 or below, see UPDATE 10), and you can click on the "Software Update..." button to download all available Apple software updates.
UPDATE 10: On 13 September 2011, Microsoft issued a new update which replaced the KB2607712 patches. I had previously given direct links for all 14 versions of the KB2607712 patch in this article. Rather than link to all the new individual patches, I added a link to the new KB2616676 article which contains download links for all supported versions of Windows. Also, I updated this article to mention that Apple did not release (and has no plans to release) Security Update 2011-005 or any future security updates for Mac OS X v10.5 Leopard, including all G4/G5-based Macs, since both Leopard and all pre-Intel Mac hardware have reached the end of their support life cycle.
Also, as of 13 September 2011, Apple still had not released a security update for iOS, so all iPhones, iPads, and iPod touches are still vulnerable to attacks involving DigiNotar-signed certificates.
UPDATE 11: On 12 October 2011, Apple finally patched iOS. Users of iPhone 3GS/4/4S, iPad or iPad 2, or third or fourth generation iPod touch should install iTunes 10.5 (which was released yesterday) and then upgrade their device to iOS 5.0 afterward. Run Apple Software Update to upgrade iTunes, then plug in your device, then click on the device in iTunes, and then click on the "Check for Updates" button to download the latest version of iOS. If you have trouble downloading iOS 5.0 via iTunes, you can find individual download links here and instructions on how to manually install the update here. Apple has a list of security issues fixed in iOS 5.0 here.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Wednesday, July 13, 2011
AOL Phishing Scam: "***ACCOUNT UPDATE***"
It's been a few months since the last time I blogged about a phishing scam targeting AOL users. Once again, an e-mail claiming to have been sent by AOL is slipping past AOL's filters and is being delivered directly to users' inboxes, even if they have their spam filter set to High (the highest setting). The e-mail claims:
No legitimate company will ever ask you for your password, but there are enough people out there who fall victim to schemes like this that phishers keep trying to prey on the less savvy.
If you have friends or family who use AOL, please teach them how to recognize and avoid phishing scams such as this one.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Note the difference in the way this e-mail looks in the Web interface compared with a legitimate e-mail from AOL (the fake one doesn't have a fancy logo next to it, but the real one does):
Dear AOL User,
This is email from AOL Team and we are sending it to you for verification.Due to the anonymous registration of our account which is causing congestion to our services, we are shutting down some accounts and your account was among those to be deleted, so the purpose of this email is for you to verify that you are the owner of this account and you are still using it by filling the information below after clicking on the reply button:
Username:.......................................Password:.......................................Date of Birth:...................................Country Or Territory:.........................
After following the instructions in the sheet, your account will not be interrupted and will continue as normal. Thanks for your attention to this request. We apologize for any inconveniences.
Thank you,
The AOL Team
No legitimate company will ever ask you for your password, but there are enough people out there who fall victim to schemes like this that phishers keep trying to prey on the less savvy.
If you have friends or family who use AOL, please teach them how to recognize and avoid phishing scams such as this one.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Tuesday, June 28, 2011
Opera Outdated in Mac App Store Again
Not surprisingly, when Opera Software released the new version of its browser earlier today, Opera 11.50, it didn't make it to the Mac App Store.
You may recall that last month Opera 11.11 was released, and the version in the Mac App Store was two versions (and two months) old and contained a publicly-disclosed security issue rated as "critical." After contacting Apple and Opera, and after much press coverage thanks to my article warning users about the issue, Apple finally published the then-current version 11.11 in the Mac App Store.
Apple's Mac App Store is still distributing Opera 11.11, which is now outdated and publicly known to contain no less than three vulnerabilities, two of which have been publicly disclosed. One of the three vulnerabilities (the details of which have not yet been disclosed) is rated by Opera as "moderately severe," while Opera rates the severity of the two publicly-disclosed vulnerabilities as "high" ("Data URIs may be used to initiate cross site scripting against unrelated sites") and "low" ("Issue with error pages can cause a system crash").
Like last month, I notified both Apple's security team and Opera about the issue on the day of the new version's release. It will be interesting to see how long it takes Apple to approve the new version and begin distributing it in the Mac App Store; last time it took a full week after I notified Apple's security team about the issue.
If you missed my previous article on the subject, I recommended that if you have downloaded Opera from the Mac App Store, you can just drag the outdated copy of the application into the Trash, and then replace it with a fresh copy downloaded from Opera's site at http://www.opera.com/download/
On an unrelated note, I have been doing a lot of research lately on the "Mac Defender" malware that has been causing a stir since the beginning of May. I am pleased to announce that I will soon publish my findings here on this site, so please subscribe to be sure you don't miss out on those details.
UPDATE, 6 July 2011: It took Apple just over a week after Opera released version 11.50 before the new version became available on the Mac App Store. Hopefully at some point Apple will begin to improve its app approval process to fast-track security updates, especially when vulnerabilities have been disclosed publicly or exist in popular software. For now, if an app is available directly from its publisher, it's probably a good idea to download it from the publisher's site rather than via the Mac App Store.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
You may recall that last month Opera 11.11 was released, and the version in the Mac App Store was two versions (and two months) old and contained a publicly-disclosed security issue rated as "critical." After contacting Apple and Opera, and after much press coverage thanks to my article warning users about the issue, Apple finally published the then-current version 11.11 in the Mac App Store.
Apple's Mac App Store is still distributing Opera 11.11, which is now outdated and publicly known to contain no less than three vulnerabilities, two of which have been publicly disclosed. One of the three vulnerabilities (the details of which have not yet been disclosed) is rated by Opera as "moderately severe," while Opera rates the severity of the two publicly-disclosed vulnerabilities as "high" ("Data URIs may be used to initiate cross site scripting against unrelated sites") and "low" ("Issue with error pages can cause a system crash").
Like last month, I notified both Apple's security team and Opera about the issue on the day of the new version's release. It will be interesting to see how long it takes Apple to approve the new version and begin distributing it in the Mac App Store; last time it took a full week after I notified Apple's security team about the issue.
If you missed my previous article on the subject, I recommended that if you have downloaded Opera from the Mac App Store, you can just drag the outdated copy of the application into the Trash, and then replace it with a fresh copy downloaded from Opera's site at http://www.opera.com/download/
On an unrelated note, I have been doing a lot of research lately on the "Mac Defender" malware that has been causing a stir since the beginning of May. I am pleased to announce that I will soon publish my findings here on this site, so please subscribe to be sure you don't miss out on those details.
UPDATE, 6 July 2011: It took Apple just over a week after Opera released version 11.50 before the new version became available on the Mac App Store. Hopefully at some point Apple will begin to improve its app approval process to fast-track security updates, especially when vulnerabilities have been disclosed publicly or exist in popular software. For now, if an app is available directly from its publisher, it's probably a good idea to download it from the publisher's site rather than via the Mac App Store.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Saturday, June 18, 2011
Disclosure: iTunes Store Authentication Vulnerability
Apple recently worked with AOL to fix a vulnerability that I discovered in the iTunes Store authentication process. Following is a press release that was just published by upSploit, the advisory management organization I selected to help coordinate with Apple:
EDIT: Apple also acknowledged me at https://support.apple.com/kb/HT1318 for reporting this issue.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
On June 4th, 2011, upSploit Limited released a vulnerability for the iTunes Store, App Store and iTunes. This vulnerability seemed to be a problem in the way Apple integrated AOL usernames and passwords into its services.
Prior to this vulnerability being fixed, Apple would accept incorrect passwords from users logging into the store using an AOL Screen Name. Incomplete passwords, passwords with incorrect letter case, passwords with incorrect or extra characters at the end, or a combination of any or all of these, were accepted by Apple. Knowledge of this vulnerability could potentially have been used by attackers, leading to disclosure of personally identifiable information, identity theft, and fraudulent purchases.
The vulnerability took the whole 6 month disclosure time limit to be announced as Apple were at first unresponsive to the problem and then when they did respond were initially unable to reproduce it. The discoverer of the bug, Joshua Long, contacted them and helped them find the problem and they fixed it almost immediately.
Long had this to say about the process:
"When I discovered this security vulnerability last year, I felt that it was serious enough to warrant submitting it to a responsible third-party vulnerability management organization rather than only to Apple or AOL. I have submitted reports to both companies in the past, and I have found that sometimes it can take them a very long time to respond to a security issue. Case in point: AOL still doesn't seem to care about encrypting its Web-based e-mail service, in spite of Firesheep shining a spotlight on the problem last year. I hoped that bringing in a third party to work with the vendor would help encourage the vendor to take the issue seriously and fix it more quickly. I first approached a leading vulnerability management organization, but their policy was to not accept vulnerabilities in services. I had previously heard about upSploit on a security podcast and I decided to give the service a try. I liked that upSploit automatically and routinely reminds the vendor about the vulnerability and the date on which it will be disclosed to the public. I believe that upSploit's persistence was a major factor in motivating the vendor to take action and to resolve the issue."
Any credit for the vulnerability should be given to Joshua Long aka the JoshMeister. You can follow him on Twitter here - https://www.twitter.com/theJoshMeister and can view his security blog here - http://security.thejoshmeister.com
https://www.upsploit.com/index.php/advisories/view/UPS-2010-0020
EDIT: Apple also acknowledged me at https://support.apple.com/kb/HT1318 for reporting this issue.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Wednesday, May 18, 2011
Apple's Mac App Store Puts Users At Risk
Users of Apple Inc.'s Mac App Store—a feature added to Mac OS X v10.6 Snow Leopard and built into the upcoming v10.7 Lion operating system—may be putting their computer's security at risk.
Third-party Web browser maker Opera has released version 11.11 of its software, which fixes a "critical" security issue. Mac users who have downloaded Opera through the App Store may find themselves using a copy of Opera that is now two versions old, 11.01, which was released back in March and is vulnerable to the security bug patched in 11.11. Users who rely on the App Store to tell them whether their software is up-to-date may not be aware of the security risks and may continue to use an unsafe version of the Opera browser.
I have notified Apple and Opera about this issue. An Opera representative acknowledged that "We are waiting for the App store to approve the next version of Opera for Mac. For now the only solution is to go to www.opera.com/download/".
Opera is not the only software in the Mac App Store that's outdated. For example, the current version of Amazon's Kindle app is 1.5.1, while the version in the App Store is still 1.2.3, which was released in January. Amazon does not publicly disclose its changelog, so there is no easy way to know whether any security issues exist in Kindle for Mac version 1.2.3.
In the past, Apple has come under fire for taking unreasonable amounts of time—sometimes weeks or even months—to approve both new apps and app updates in its iOS App Store. It remains to be seen how quickly Apple will approve the latest Opera update in the Mac App Store.
Lest any readers think that Macs are immune to security issues and this is much ado about nothing, there are indeed active attacks on Macs taking place in the wild today. Earlier this month, noted security researcher Brian Krebs warned about a new crimeware kit that makes it easy for criminals to hack and gain control of Mac systems. The same day, Mac security firm Intego and others warned about new malware spreading on the Web that falsely claimed to be Mac security software called MACDefender (or MAC Defender, and later renamed Mac Security and Mac Protector). Although attacks against Macs may currently be less common than Windows attacks, the threat of Mac security breaches is increasing and should not be taken lightly. Regardless of which operating system you're using—even if it's a mobile platform such as iOS or Android—it's important to follow good Internet safety practices (see OnGuard Online for some basic tips).
If you find that an app you've downloaded from the Mac App Store is outdated, fret not; there's an easy fix to get the latest version, assuming it's a free app that's also available on the Web. You can drag the outdated app from your Applications folder into the Trash (which will require an administrator password due to the way the App Store installs apps), and then you can drag the current version of the application from the developer's Web site into the Applications folder.
UPDATE, 25 May 2011: Finally, a full week after Opera released version 11.11 on its site and publicly disclosed the security vulnerability it had patched, and after a lot of coverage in the tech press resulting from this article, Apple has finally released Opera 11.11 in the Mac App Store. As suggested by other security researchers and tech commentators, one would hope that Apple will begin to improve its app approval process to fast-track security updates, especially when the vulnerabilities have been publicly disclosed or exist in popular software.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Third-party Web browser maker Opera has released version 11.11 of its software, which fixes a "critical" security issue. Mac users who have downloaded Opera through the App Store may find themselves using a copy of Opera that is now two versions old, 11.01, which was released back in March and is vulnerable to the security bug patched in 11.11. Users who rely on the App Store to tell them whether their software is up-to-date may not be aware of the security risks and may continue to use an unsafe version of the Opera browser.
I have notified Apple and Opera about this issue. An Opera representative acknowledged that "We are waiting for the App store to approve the next version of Opera for Mac. For now the only solution is to go to www.opera.com/download/".
Opera is not the only software in the Mac App Store that's outdated. For example, the current version of Amazon's Kindle app is 1.5.1, while the version in the App Store is still 1.2.3, which was released in January. Amazon does not publicly disclose its changelog, so there is no easy way to know whether any security issues exist in Kindle for Mac version 1.2.3.
In the past, Apple has come under fire for taking unreasonable amounts of time—sometimes weeks or even months—to approve both new apps and app updates in its iOS App Store. It remains to be seen how quickly Apple will approve the latest Opera update in the Mac App Store.
Lest any readers think that Macs are immune to security issues and this is much ado about nothing, there are indeed active attacks on Macs taking place in the wild today. Earlier this month, noted security researcher Brian Krebs warned about a new crimeware kit that makes it easy for criminals to hack and gain control of Mac systems. The same day, Mac security firm Intego and others warned about new malware spreading on the Web that falsely claimed to be Mac security software called MACDefender (or MAC Defender, and later renamed Mac Security and Mac Protector). Although attacks against Macs may currently be less common than Windows attacks, the threat of Mac security breaches is increasing and should not be taken lightly. Regardless of which operating system you're using—even if it's a mobile platform such as iOS or Android—it's important to follow good Internet safety practices (see OnGuard Online for some basic tips).
If you find that an app you've downloaded from the Mac App Store is outdated, fret not; there's an easy fix to get the latest version, assuming it's a free app that's also available on the Web. You can drag the outdated app from your Applications folder into the Trash (which will require an administrator password due to the way the App Store installs apps), and then you can drag the current version of the application from the developer's Web site into the Applications folder.
UPDATE, 25 May 2011: Finally, a full week after Opera released version 11.11 on its site and publicly disclosed the security vulnerability it had patched, and after a lot of coverage in the tech press resulting from this article, Apple has finally released Opera 11.11 in the Mac App Store. As suggested by other security researchers and tech commentators, one would hope that Apple will begin to improve its app approval process to fast-track security updates, especially when the vulnerabilities have been publicly disclosed or exist in popular software.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Tuesday, April 26, 2011
AOL Phishing Scam: "Billing update must be performed"
This isn't the first time that this exact thing has happened, but I wanted to alert my readers that a targeted phishing e-mail was sent out this morning to AOL users which managed to slip past AOL's spam filters (even if you had your account's filter set to High). The e-mail claims:
Incidentally, back in 2009 I received a copy of a legitimate e-mail from AOL's billing department that appeared at first to be fake (see the screenshots below). Since the company has a history of not catching AOL phishing scam e-mails, and since AOL also has previously sent actual billing e-mails that look like they could be phishing scams, AOL users should be extremely cautious about opening any e-mails that claim to have been sent by AOL.
Official AOL e-mails are supposed to appear with a special symbol in your inbox if you use the Web-based AOL Mail (as opposed to an e-mail client program like Apple Mail or Windows Live Mail, for example). Following is a screenshot showing the symbol that AOL currently uses in the beta version of AOL Mail:
I have previously recommended using the AOL Mail beta URL — https://beta.mail.aol.com — which provides SSL encryption of the e-mail session rather than just the login page.
For those who may be interested, here's the Web of Trust rating page for the domain hosting the phishing scam page:
https://www.mywot.com/en/scorecard/themostcreativebuildingintheworld.com
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Billing update must be performedExperienced users will immediately recognize warning signs (the generic "Dear AOL Member" salutation, the fact that AOL is not a "banking service," the lack of a special AOL logo next to the e-mail in your inbox if you use the Web-based AOL Mail site, etc.). However, it is quite troubling that AOL still does not always filter phishing scam e-mails that mimic AOL's formatting and links. The phishing link embedded in the e-mail even contained a directory /bill.aol.com/ which should have immediately caused this message to be blocked by AOL's phishing filter, but shockingly it didn't.
Dear AOL Member,
Our records indicate that your account hasn't been updated
as a part of our regular account maintenance.Our new SSL
servers check each account for activity and your information has
been randomly chosen for verification. AOL Member Services strives
to serve their customers with better and secure banking service.
Notification: Failure to update your account information may
result in account limitation at shopping on our portal.
Update your information
To re-secure your account, just confirm your personal information.
Sincerely,
AOL Member Services
Please note that this email address cannot accept replies.
Incidentally, back in 2009 I received a copy of a legitimate e-mail from AOL's billing department that appeared at first to be fake (see the screenshots below). Since the company has a history of not catching AOL phishing scam e-mails, and since AOL also has previously sent actual billing e-mails that look like they could be phishing scams, AOL users should be extremely cautious about opening any e-mails that claim to have been sent by AOL.
Official AOL e-mails are supposed to appear with a special symbol in your inbox if you use the Web-based AOL Mail (as opposed to an e-mail client program like Apple Mail or Windows Live Mail, for example). Following is a screenshot showing the symbol that AOL currently uses in the beta version of AOL Mail:
I have previously recommended using the AOL Mail beta URL — https://beta.mail.aol.com — which provides SSL encryption of the e-mail session rather than just the login page.
For those who may be interested, here's the Web of Trust rating page for the domain hosting the phishing scam page:
https://www.mywot.com/en/scorecard/themostcreativebuildingintheworld.com
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Thursday, March 31, 2011
Updates to Past Blog Posts: URL Shortener Previews, Bindaas Spam
I recently added several URL shortening services to my popular article "How to Preview Shortened URLs (TinyURL, bit.ly, is.gd, and more)". This is a great article to share with friends who are concerned about where short links on Twitter and elsewhere will take them.
I have also added additional domains to the list of Bindaas spam-advertised sites in my article "'Bindaas Spaces' Spam from India".
For more from the JoshMeister on Security, please subscribe to the RSS feed or follow me on Twitter.
I have also added additional domains to the list of Bindaas spam-advertised sites in my article "'Bindaas Spaces' Spam from India".
For more from the JoshMeister on Security, please subscribe to the RSS feed or follow me on Twitter.
Wednesday, March 9, 2011
MacTech: Review of Sophos Anti-Virus for Mac Home Edition
I wrote a review of Sophos Anti-Virus for Mac Home Edition that was published in the January 2011 issue of MacTech Magazine. Although I can't republish the full article here, I certainly recommend grabbing a copy of Issue 27.01 if you're interested in my take on this free-for-home-use Mac antivirus solution. The issue also contains the monthly CoreSec column by Michele (Mike) Hjörleifsson—this time covering the security of VOIP, Apple FaceTime and iChat, and Skype—as well as lots of other great articles including virtualization benchmarks comparing Parallels Desktop 6 and VMware Fusion 3.1.
UPDATE, 8 April 2012: The review is now available to read online:
http://www.mactech.com/articles/mactech/Vol.27/27.01/RealWorldReview-SophosAntiVirus/index.html
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
UPDATE, 8 April 2012: The review is now available to read online:
http://www.mactech.com/articles/mactech/Vol.27/27.01/RealWorldReview-SophosAntiVirus/index.html
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Tuesday, February 8, 2011
AOL Project Phoenix Beta (Still) Lacks Security
In November, AOL announced its attempt to make its e-mail service popular again by promoting its new Project Phoenix beta service. Basically, AOL Project Phoenix is supposed to give you a single site for accessing multiple e-mail accounts from different services, posting to Twitter and Facebook, texting, and instant messaging, and it offers new domains to choose from, for example @love.com instead of @aol.com.
The beta went live in late December, and those who requested invites ahead of time were given access. However, in spite of all the features that have been added, AOL seems to have forgotten the two most important features of all: security and privacy. What's wrong with this picture?
That's right; Project Phoenix provides no encryption whatsoever, except for the initial login page. I found this quite surprising and fairly disturbing since Project Phoenix was announced one month after Firesheep hit the Internet (and Phoenix went live two months after the release of Firesheep, which should have given AOL plenty of time to implement better security).
If you missed my blog post mentioning Firesheep (and if you also missed the zillions of news stories about it), it's a Firefox add-on that allows any wannabe hacker to easily log into other users' accounts who are on the same unencrypted or WEP-encrypted Wi-Fi network. This can be a significant problem if you frequently use public Wi-Fi hotspots at coffee shops, restaurants, hotels, airports, or anywhere else that uses an open (password-free) Wi-Fi access point that anyone can join—or if you have an open or WEP-encrypted Wi-Fi network at home. Firesheep has been downloaded over 1.1 million times so far. Affected sites reportedly included Facebook, Twitter, Amazon, Google, bit.ly, The New York Times, Dropbox, Evernote, Flickr, and others. Support for AOL is already in the works and has been "pending" since October 18th, although it could be fairly trivial for someone to add their own support for AOL sites; the creator of Firesheep provides step-by-step instructions for creating your own "handlers."
If AOL is indeed vulnerable to session hijacking as the Firesheep site implies, it would mean that anyone using the AOL site on a public Wi-Fi network could have their session hijacked, meaning that the attacker could read and send e-mails, instant messages, or text messages posing as the owner of that AOL account or any e-mail account connected with it. Regardless of whether AOL's site is vulnerable to session hijacking, the lack of HTTPS encryption means that the contents of your personal e-mails are sent unencrypted over the network and could be intercepted and read by malevolent third parties.
During December and January, I made at least 9 different attempts using at least 7 different methods to notify AOL about this major vulnerability in Project Phoenix. I received a reply one month ago from the AOL Privacy Team that said, in part:
I strongly recommend that AOL users opt out of Project Phoenix if they've already opted into it (just find and click on the "Switch to Classic Mail" link), and then always use https://beta.mail.aol.com to securely access their AOL e-mail from the Web.
As someone who knows several people who use AOL e-mail, I'm frustrated with AOL's apparent lack of concern for its users' security and privacy (in spite of its claims to the contrary). Fortunately, AOL does offer a method of accessing e-mail via HTTPS if you're lucky enough to know the secret URL above. Several of the sites supported by Firesheep also have optional HTTPS access but don't enforce it.
Here's food for thought: Google's free e-mail service, Gmail, has defaulted to HTTPS for over a year now. Why not AOL Mail, Yahoo! Mail, Windows Live Hotmail, and other e-mail providers? Why not other major sites with millions of users? Do they really care that little about their customers? Or are they really that clueless?
(Before anyone replies mistakenly claiming that SSL is expensive to implement, allow me to correct you: it's not. As for the price, an SSL certificate is easily affordable for anyone who owns a domain, and regarding computational expense, a Google engineer has stated the following about switching Gmail to SSL/TLS: "If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users. ... In order to do this we had to deploy no additional machines and no special hardware.")
The average user does not know anything about the dangers of using public Wi-Fi and has never heard of Firesheep. I strongly encourage you to take action by doing the following:
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
The beta went live in late December, and those who requested invites ahead of time were given access. However, in spite of all the features that have been added, AOL seems to have forgotten the two most important features of all: security and privacy. What's wrong with this picture?
If you missed my blog post mentioning Firesheep (and if you also missed the zillions of news stories about it), it's a Firefox add-on that allows any wannabe hacker to easily log into other users' accounts who are on the same unencrypted or WEP-encrypted Wi-Fi network. This can be a significant problem if you frequently use public Wi-Fi hotspots at coffee shops, restaurants, hotels, airports, or anywhere else that uses an open (password-free) Wi-Fi access point that anyone can join—or if you have an open or WEP-encrypted Wi-Fi network at home. Firesheep has been downloaded over 1.1 million times so far. Affected sites reportedly included Facebook, Twitter, Amazon, Google, bit.ly, The New York Times, Dropbox, Evernote, Flickr, and others. Support for AOL is already in the works and has been "pending" since October 18th, although it could be fairly trivial for someone to add their own support for AOL sites; the creator of Firesheep provides step-by-step instructions for creating your own "handlers."
If AOL is indeed vulnerable to session hijacking as the Firesheep site implies, it would mean that anyone using the AOL site on a public Wi-Fi network could have their session hijacked, meaning that the attacker could read and send e-mails, instant messages, or text messages posing as the owner of that AOL account or any e-mail account connected with it. Regardless of whether AOL's site is vulnerable to session hijacking, the lack of HTTPS encryption means that the contents of your personal e-mails are sent unencrypted over the network and could be intercepted and read by malevolent third parties.
During December and January, I made at least 9 different attempts using at least 7 different methods to notify AOL about this major vulnerability in Project Phoenix. I received a reply one month ago from the AOL Privacy Team that said, in part:
AOL's commitment to security and privacy has always been one of our most important values. ... AOL currently supports SSL in the beta of AOL Mail ... and has plans to support SSL in Project Phoenix, a new version of AOL Mail in the first half of 2011 as a part of the company's ongoing efforts to offer consumers the best online experience possible.This evening I received a mass e-mail from AOL's Senior Vice President of Marketing, Mike Maser, stating that AOL appreciated all the ideas, comments, and feedback they have received, and that "We're taking your input to heart!" That sounded hopeful, but the e-mail only listed a couple of extremely minor updates, and SSL/TLS encryption wasn't one of them. I opted back into Phoenix to test it anyway, and was disappointed to find that all e-mails and interactions with the site are still sent unencrypted, and you still can't manually add an "s" after the "http" to enable encryption.
I strongly recommend that AOL users opt out of Project Phoenix if they've already opted into it (just find and click on the "Switch to Classic Mail" link), and then always use https://beta.mail.aol.com to securely access their AOL e-mail from the Web.
As someone who knows several people who use AOL e-mail, I'm frustrated with AOL's apparent lack of concern for its users' security and privacy (in spite of its claims to the contrary). Fortunately, AOL does offer a method of accessing e-mail via HTTPS if you're lucky enough to know the secret URL above. Several of the sites supported by Firesheep also have optional HTTPS access but don't enforce it.
Here's food for thought: Google's free e-mail service, Gmail, has defaulted to HTTPS for over a year now. Why not AOL Mail, Yahoo! Mail, Windows Live Hotmail, and other e-mail providers? Why not other major sites with millions of users? Do they really care that little about their customers? Or are they really that clueless?
(Before anyone replies mistakenly claiming that SSL is expensive to implement, allow me to correct you: it's not. As for the price, an SSL certificate is easily affordable for anyone who owns a domain, and regarding computational expense, a Google engineer has stated the following about switching Gmail to SSL/TLS: "If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users. ... In order to do this we had to deploy no additional machines and no special hardware.")
The average user does not know anything about the dangers of using public Wi-Fi and has never heard of Firesheep. I strongly encourage you to take action by doing the following:
- Contact the operators of sites you use—especially the high-profile sites that would be the most likely targets of Firesheep attacks—and explain the problems of not enforcing HTTPS encryption for the entire session (i.e. the whole time the user is on the site, not merely when they log in).
- Encourage your friends, relatives, and local coffee shops and restaurants to enable WPA2 encryption on their networks, and offer to help them set this up. They can freely share the Wi-Fi password with anyone they wish to allow on the network; Firesheep doesn't work with WPA encryption.
- Encourage your Firefox-using friends to install the latest development builds of the HTTPS-Everywhere add-on, but make sure they understand that it's not foolproof. In spite of its name, it can't enable encryption on all sites, but it adds a layer of defense by forcing encryption for a limited number of specific sites where HTTPS is normally optional. I don't recommend using HTTPS-Everywhere as your only line of defense on a public Wi-Fi network, although it might be good enough if the only Web sites you ever use are ones that the add-on supports. If browsing all sites freely without worry sounds preferable, a better option is to:
- Encourage your friends to use a VPN to securely log into their home computer when they're on a public Wi-Fi network, and only browse the Web using their browser at home through the secure VPN tunnel. Most people will prefer a simple, easy VPN solution that's free or inexpensive, such as LogMeIn Free (which I haven't used personally, but appears to be a good solution) instead of using their laptop's browser when connected to an open Wi-Fi network.
UPDATE, 13 July 2011: It appears that AOL has finally begun to allows HTTPS access for the domain phoenix.aol.com, although not all parts of the page are encrypted.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Thursday, January 6, 2011
How to Remove "Antivirus Scan" FakeAV Malware
Yesterday I conducted a forensic investigation and cleanup of an infected Windows PC. When I first saw the computer, it was running a fake antivirus program identifying itself as simply "Antivirus Scan," which had attempted to open multiple adult Web sites as well as the Viagra homepage in order to convince the user that its fake scan had really found infections. (The real McAfee VirusScan Enterprise was also running on the system, but it was one day behind in its definitions and seemed completely oblivious to the infection.) Following are screenshots of this malware courtesy of URLVoid Blog, which identifies a connection between this fake AV and the TDSS malware family:
The malware prevented opening the Task Manager or regedit, even after I copied the the exe files to the desktop and renamed them. It also cleverly prevented opening McAfee's main window. I had to boot the machine from a CD (a previously made UBCD4Win disc) in order to examine and repair the computer.
Not only had McAfee been unhelpful at detecting or preventing the infection, but running a fully updated Spybot—Search & Destroy while booted from the CD didn't find any malicious files either. While that scan was running, I searched the hard drive for files modified within the past two days (the machine had reportedly become infected the previous day) and I noticed Windows prefetch (.PF) files for two suspicious executables, which I subsequently discovered residing here:
It turns out that both of these files were actually copies of the same file with different names. The file is currently detected by 28 out of 43 antivirus engines according to VirusTotal:
After rebooting from the hard drive again, the PC could not access the Internet. I ran HijackThis and found the following registry entries which needed to be deleted:
After cleaning these entries, the system was able to get online again. Note that there may be additional registry settings that should be reverted to their previous settings. This Anubis report and this ThreatExpert report show the following additional modifications to registry values:
Following are reports for malicious sites and IPs that have recently been hosting content related to this infection and its variants:
The computer probably wouldn't have gotten infected in the first place if it had been running the latest version of Adobe Reader configured for better security, or an alternative PDF reader.
UPDATE, 10 Jan 2011 @ 11:26 PST: Added additional malware names and current detection rates.
UPDATE, 11 Jan 2011 @ 21:38 PST: Added additional malware names and domains related to a new variant.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
The malware prevented opening the Task Manager or regedit, even after I copied the the exe files to the desktop and renamed them. It also cleverly prevented opening McAfee's main window. I had to boot the machine from a CD (a previously made UBCD4Win disc) in order to examine and repair the computer.
Not only had McAfee been unhelpful at detecting or preventing the infection, but running a fully updated Spybot—Search & Destroy while booted from the CD didn't find any malicious files either. While that scan was running, I searched the hard drive for files modified within the past two days (the machine had reportedly become infected the previous day) and I noticed Windows prefetch (.PF) files for two suspicious executables, which I subsequently discovered residing here:
C:\Documents and Settings\[username]\Local Settings\Temp\glqvcorac\poylsfolajb.exe(Note that the name of the folder and files inside the Temp directory are random, so if you're cleaning this infection you'll have to look for similarly suspicious files inside your Local Settings\Temp folder. In fact, you can usually safely delete the entire contents of that Temp folder. Also note that this is the Windows XP directory structure, so if you're running Windows Vista or Windows 7 the path will be different, possibly C:\Users\[username]\AppData\Local\Temp or C:\Users\[username]\Local Settings\Temp)
C:\Documents and Settings\[username]\Local Settings\Temp\0.9249067424896712.exe
It turns out that both of these files were actually copies of the same file with different names. The file is currently detected by 28 out of 43 antivirus engines according to VirusTotal:
MD5 : 3f26b63042639ba83f12af59ec96b669Here's another variant that I later discovered on another computer:
SHA1 : 08d8df0cdb79519705b7cf57f625fa5b83842129
SHA256: 2114f60f2ee4c600afe9665abea18531fbc0aa913f56dbad68052a73cdd85adb
File size : 321536 bytes
First seen: 2011-01-04 17:26:04
28/43 detection rate as of 2011-01-06 19:46:38 (UTC)
34/43 detection rate as of 2011-01-10 17:33:23 (UTC)
Variously identified as: FakeAlert-SpyPro.gen.bb, Gen:Variant.Kazy.7105, Gen.Variant.Kazy!IK, Generic Malware, Generic4.AZEH, Mal/FakeAV-DO, Mal/FakeAV-IC, Medium Risk Malware, Rogue:Win32/FakeSpypro, Rogue.FakeSpypro (Not a Virus), TR/FakeAV.zrt, Trj/CI.A, TROJ_FAKEAV.SMT1, Trojan.Agent/Gen-Venue, Trojan.FakeAV, Trojan.FakeAV!6BsmWKRLcxY, Trojan.FakeAV!gen39, Trojan.Siggen.64617, Trojan.Win32.FakeAV.zrt, Trojan.Win32.Generic.pak!cobra, Trojan/Win32.FakeAV.gen, UnclassifiedMalware, W32/FakeAV.ACHR, W32/FakeAV.ZRT!tr, Win-Trojan/Fakeav.321536.D, Win32:FakeAV-BCD, Win32:FakeAV-BCI, Win32.GenVariant.Kaz, Win32/Adware.SpywareProtect2009, Win32/AntivirusAction.AM, etc.
MD5 : a931ee4e43fb3e2651811f984bfafc0dI continued my investigation to try to discover the origin of the infection. Searching through the main index.dat History file, I identified a suspicious URL for a PDF file, and I searched the hard drive for that file. Sure enough, a scan on VirusTotal showed that the file was a PDF exploit, and Wepawet also identified it as suspicious. (Incidentally, the infected PC was running an old and vulnerable copy of Adobe Reader, version 9.2.0, and had not been configured for better security.) Here's the current VirusTotal analysis of the PDF, which is currently only detected by about a third of major antivirus vendors:
SHA1 : d5cb58529480fe7d4bd04e997e235591ebbe8c5b
SHA256: d1e997bff5cfadb7b27945c1c30574f8d3eea6ba9afd4a65b87187e037679248
File size : 324096 bytes
First seen: 2011-01-07 02:58:58
36/43 detection rate as of 2011-01-11 20:23:54 (UTC)
In addition to the classifications above, this variant is also identified as: Gen:Variant.Kazy.7430, Generic20.BOWF, High Risk Cloaked Malware, Riskware, Suspicious file, TR/Kazy.7430, TROJ_FAKEAV.GKR, Trojan.Agent/Gen-Frauder, Trojan.FakeAV!F3J+Da8Hqx4, Trojan.FakeAV!gen39, Trojan.FakeAV.zug, Trojan.Win32.FakeAV.zug, Trojan/Kryptik.JMP.gen, W32/FakeAV.ACHN, W32/FakeAV.ZUG!tr, Win32:FakeAV-BCI, Win32.GenVariant.Kaz, Win32/FraudAntivirusScan.F, Win32/Kryptik.JMP.Gen, etc.
MD5 : 2d1eb76fde5a94b14e1436039ffb0d87Since the file was located in the browser cache (the Temporary Internet Files folder), simply emptying the cache should delete this file if it resides on your system.
SHA1 : 441a264f5f0fc30072ab4b4f420d80b70366f645
SHA256: 74b926b64dfa4e81ec0b5883a3bdb1f82de0d0e6103b2fa6861d67805ec92ada
File size : 12458 bytes
First seen: 2011-01-06 00:04:44
16/43 detection rate as of 2011-01-06 19:57:17 (UTC)
18/43 detection rate as of 2011-01-10 17:35:49 (UTC)
Variously identified as: Exploit.AdobeReader.gen (v), Exploit.JS.Pdfka.dcq, Exploit.PDF-JS!IK, Exploit.PDF-JS.Gen, Exploit.PDF.1654, Exploit.PDF.gen, Heuristic.BehavesLike.PDF.Suspicious.I, JS:Pdfka-APU, PDF/Exploit.Pidief.PDS.Gen, PDF/Pidief!generic, PDF/Piedf.F2EB!exploit, TROJ_PIDIEF.SMZB, Troj/PDFJs-ML, etc.
After rebooting from the hard drive again, the PC could not access the Internet. I ran HijackThis and found the following registry entries which needed to be deleted:
R1 - HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings,ProxyServer = http=127.0.0.1:8074(For the O4 entry above, note that the path to the file inside the Temp folder will match the one where the file had previously been located on your system; it won't be named exactly as above.)
O4 - HKCU\..\Run: [qectelup] C:\DOCUME~1\[username]\LOCALS~1\Temp\glqvcorac\poylsfolajb.exe
After cleaning these entries, the system was able to get online again. Note that there may be additional registry settings that should be reverted to their previous settings. This Anubis report and this ThreatExpert report show the following additional modifications to registry values:
HKCU\Software\Microsoft\Internet Explorer\Download CheckExeSignatures = noAccording to Trend Micro, it should be safe to delete the registry values highlighted in bold above (assuming you have a good understanding of how to properly edit the registry).
HKCU\Software\Microsoft\Internet Explorer\Download RunInvalidSignatures = 1
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations LowRiskFileTypes = .exe
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments SaveZoneInformation = 1
Following are reports for malicious sites and IPs that have recently been hosting content related to this infection and its variants:
- WOT report for yourremue .com (which hosted the PDF exploit)
- WOT report for marezer .com (referenced in a malware object found in the cache [identified as HTML/FakeAlert.AT, JS/FakeAV.ZRT!tr, Trojan.HTML.Fraud!IK, Trojan.HTML.Fraud.di, Win32/Adware.SpywareProtect2009 application, etc.]; hosting a fraudulent payment page)
- WOT report for heneya8 .co.cc (hosting a Java exploit [identified as a variant of Java/TrojanDownloader.OpenStream.NAU, Exploit-ByteVerify, Exploit:Java/CVE-2010-0840.W, JAVA_LOADER.HLL, JAVA_LOADER.HLM, Java:Agent-BJ, Java.Downloader.150, Java.S.OpenConnection.3758, Java.Trojan-Downloader.OpenConnection!IK, Java.Trojan.Downloader.OpenConnection.AI, Java/Agent.CG, Java/Cve-2010-0840, Java/ObfusJava.G, JAVA/OpenConnect.CF, Java/Openconnection.9ADE!tr, Mal/JavaJar-A, Trojan-Downloader:Java/OpenConnection.AV, Trojan-Downloader.Java.OpenConnection.cf, Trojan.ByteVerify, Trojan.Java.Agent.dc (v), Trojan/Java.OpenConnection, , etc.] associated with the second variant I've encountered)
- WOT report for geniuscancer .com (hosted the same Java exploit as above; also associated with the second variant I encountered)
- WOT report for 64.111.211 .154 (see also Symantec's Norton Safe Web report)
- WOT report for 69.50.202 .18 (see also Malware Domain List's report)
- WOT report for mumeonline .com (affiliated with 69.50.202 .18 and utilizing the Phoenix Exploit Kit according to Malware Domain List)
- WOT report for yourbouge .com (affiliated with 69.50.202 .18 and utilizing the Phoenix Exploit Kit according to Malware Domain List)
- WOT report for softwarear .com (affiliated with a variant of this malware according to McAfee)
- WOT report for softwareea .com (affiliated with variants of this malware according to McAfee[1][2][3])
- WOT report for afantispy .com (affiliated with variants of this malware according to URLVoid and McAfee)
- WOT report for afantispy .net (affiliated with a variant of this malware according to McAfee)
The computer probably wouldn't have gotten infected in the first place if it had been running the latest version of Adobe Reader configured for better security, or an alternative PDF reader.
UPDATE, 10 Jan 2011 @ 11:26 PST: Added additional malware names and current detection rates.
UPDATE, 11 Jan 2011 @ 21:38 PST: Added additional malware names and domains related to a new variant.
For more from the JoshMeister on Security, please subscribe via e-mail or RSS, or follow me on Twitter.
Subscribe to:
Posts (Atom)
Posts
