Update – 13 April 2012: Apple have released another update to Java (via software update) which automatically disables Java in Safari, and removes Flashback if it has infected your system. Please use Apple’s update rather than relying on this script!
Update – 10 April 2012: I have edited the script to run the additional commands recommended by TidBITS. The Download button will now return version 0.2 of the script.
It’s finally happened, there has been a serious malware outbreak on the Mac. Over half a million Macs have been infected with the latest variants of the
Flashback malware. Earlier versions of this malware relied on tricking users into running an installer, or approving a request for permission to execute, but that has all changed now. The malware moved from being a simple trojan that relied on tricking people into running it, to a fully automated attack requiring no user interaction. The reason for this transformation is that the malware started to use flaws in Java, first, old vulnerabilities that were patched ages ago, so only affecting people who don’t keep their computers up to date, but this week, attacking flaws that Apple had, at the time, not yet patched. This means that for a few days, even the most diligent Mac users could have been hit.
This infection has no noticeable symptoms, and did not require you do do anything “stupid” to get infected. Any Mac user, not matter how careful, could have been infected. So, you need to check to be sure you are not one of the half million plus victims! Read more
I’ve been looking at different free Mac AV solutions so that I can make recommendations to less-computer-savy family members, and this afernoon I decided to give ClamXav a go. I’d tried it a few years ago and wasn’t very happy, but I’d been told by friends that it has improved a lot since, and a first glance at the GUI suggests they’re right. Unfortunately I didn’t get very far with my initial testing this afternoon because I’m in an environment where I have to use an HTTP proxy server to access the net, and ClamXav appears not to support proxies at first glance. It ignores OS X’s system-wide proxy settings, and it has no interface elements of its own to allow you to specify a proxy server manually. This implies that ClamXav doesn’t support proxies, but it actually does, they just didn’t bother to expose that functionality through the GUI.
ClamXav is just a GUI wrapper for the free and open source Clam AntiVirus toolkit, and it uses Clam’s regular auto-updating tool
freshclam. Although the ClamXav GUI doesn’t give you control over the variables in the
freshclam configuration file, that file does exist as part of ClamXav (
/usr/local/clamXav/etc/freshclam.conf), and if you edit it manually it will respect the settings specified in that file. If you’re not afraid of the Terminal, you can easily edit this configuration file manually to get ClamXav to use a proxy server for updates.
The technosphere is a buzz this week with the news that DropBox’s security has a rather large and rather stupid hole in it. I’m only going to give a brief overview of the issue here, so if you’d like more details please check out the blog post that broke the story. What I do want to say is that this is a really infantile mistake on DropBox’s part, and the fact that they could overlook something so elementary for so long worries me a lot.
Anyhow – the whole problem revolves around the Host ID which DropBox uses to identify a computer within your account. This code acts as both an identifier and a password, and it’s a big long string of random looking gibberish. The problem is not that this ID is easy to guess, but rather that it’s not tied to any particular machine. If a bad-guy gets their hands on the file containing this ID they can effectively clone your machine in DropBox’s eyes, and see your files in perpetuity, regardless of how many times you change your password. The only way to kill the bad guy’s access would be to de-authorise the machine who’s ID they cloned in your account pages on the DropBox website.
The original blog post that broke this story describes in detail where you can find this ID on Windows, but doesn’t mention any other OSes. Quite a few listeners to my various podcasts have asked me if I know where the file is located on the Mac. I didn’t, but I figured it would be worth spending a little time finding the answer.
I don’t normally log in to Twitter directly – I almost always use clients – but today I did, and I noticed something which shocked me – Twitter is sending login details over an unsecured HTTP connection! I have no idea if Twitter’s always done this, or if they are experiencing some kind of bug today, but either way, this is a serious issue.
Were I to be using public WiFi or any other un-trusted network it would be trivial for someone to get both my username and password and take over my Twitter account. Worse still – if I were to use the same credentials elsewhere like so many people do – all those other accounts could be taken over too. This is just not acceptable in 2009.
A worrying looking article that declared the end of WiFi security as we know it made it on to slashdot yesterday. The article looks quite worrying, but it doesn’t seem to stand up to the test of reality. The smack-downs are impressive:
- George Ou –
Debunking the latest fear mongering news on WPA security
- Robert Graham – WPA is NOT obsolete
- Rich Mogull – Your WPA-PSK Wireless Network Is At Risk… If You Are An Idiot
‘Click Jacking’ is the latest browser-based security problem to crawl out of the wood work. Since it’s entirely browser based it affects everyone, regardless of their OS, not even Linux users are safe from this one! This is a cross-browser problem and also affects Flash. The technical details have not been released yet, but there is a proof-of-concept exploit doing the rounds. The basic idea is very simple, trick people into clicking on something you want them to click on but they don’t want to click on. From what I’ve been able to piece together from reading various blog postings and reports the attack uses CSS and iFrames to place invisible content over visible buttons or links. When the user clicks the button or link they see the click gets diverted to what ever is in the invisible layer above it instead. If you can do it by clicking the mouse, then you can be tricked into doing it with Click Jacking.
It’s taken them months, but Apple have finally caught up with the rest of the world and patched the critical DNS flaw disclosed in early June. This is Apple’s second attempt at patching it, they did a very poor job on their first attempt, but thankfully they seem to have gotten it right this time. It’s taken Apple over three months to patch OS X, this is totally rediculous considering Apple users the standard ISC implementation for both their DNS server and DNS resolver in OS X. ISC released patches on the 8th of June, it took Apple till the 15th of September to get their update out!
For a more detailed look at the two major security updates Apple released in the last few days (one for iPhone/iPod Touch, and one for OS X 10.5 and 10.4) check out my analysis on the IMP blog.
[tags]IMP, DNS, Apple, OS X, security, vulnerability[/tags]
I listened to Dan Kaminsiki’s Black Hat talk on the DNS flaw he discovered this afternoon (it’s on the web). I was disappointed by the lack of technical details, particularly about the client attacks, but it did answer some of my questions. For me the biggest deal was that yes, clients are vulnerable, and yes, clients do need to use port randomisation. This is what Apple failed to do in their latest update, and what Apple now need to do ASAP. Dan described the server flaw as being like a nuke, and the client flaw as being like a sniper, both will kill you if they hit you, but you defend against the nukes first, hence the focus on servers.
Another key point is that this is a temporary fix, not a permanent fix. By adding in source port randomisation we’ve bought ourselves some more time, probably a few years, but as networks continue to get faster, even this boost of entropy will cease to be enough. There are two permanent fixes, but neither are easy to deploy, and since DNS is a global system it will take time, and probably the patience of a saint, to get either implemented. At the core of the problem is the fact that DNS uses UDP, which is a connectionless protocol, making it easy to spoof packets. One way around this is so-called DNSSEC, which extends the current DNS architecture to use certificates to authenticate responses. Another solution would be to switch DNS from UDP to TCP. Both sound simple, but no change to DNS is simple, and if you get it wrong you literally kill the internet!
Bottom line, we haven’t heard the last of this yet, not nearly!
[tags]security, DNS, Blackhat, Kaminsky[/tags]
Yesterday Apple released security update 2008-005 which was supposed to fix the DNS flaw I recently complained about Apple not having fixed yet. Well, it appears that Apple only half-fixed the problem. Yes, they have fixed the BIND DNS server in OS X, but in reality that only protects X-Serves running a DNS server. Sure, regular OS X ships with the BIND DNS server installed, but it’s not on by default, and almost no one turns it on. What we all use all the time is the stub resolver that’s part of OS X, and that’s what Apple didn’t fix. This means that regular Mac users are still not protected from this DNS flaw while just about everyone else is.
[tags]Apple, OS X, DNS, vulnerability, security[/tags]
One of the things I really love about OS X is its Unix underpinnings. Under the hood we get all the *nix tools and utilities I’ve come to know and love. Printing with CUPS, remote shell with OpenSSH, Windows sharing with SAMBA, web publishing with Apache, and so on and so forth. This gives OS X great power, but it also places a great responsibility on Apple. Just like with any other software, vulnerabilities surface in open source programs. In general the open source community is very responsive to security issues, and patches are released quickly. Those patches protect those who update, but they leave those who don’t even more vulnerable. The reason for this is that the patches can generally be reverse engineered, making it easy for the bad guys to attack un-patched machines. In order to keep OS X secure Apple need to push out patches in the open source components in OS X to users as quickly as possible. This is where Apple fall down, they are notoriously slow at getting patches out.
[tags]Security, OS X, Apple, DNS, open source, BIND[/tags]