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.
‘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]
This week it was announced that one of the core protocols that holds the internet together is fundamentally flawed. The problem is not with someone’s implementation of the protocol, but with the actual protocol itself. It’s hard to over-state just how big a deal this is. At the moment the details of the vulnerability are being kept secret to give the world time to patch, but you can get some technical information from the advisory issued by the US Cert. On Tuesday all the major DNS server vendors released patches at the same time. This is un-heard of, nothing like this has ever happened before in the history of the internet. That alone should bring home just how big this is.
Although the good-guys have successfully kept the details of the flaw secret to date, despite the large numbers of organisations involved, the reality is that the bad guys are frantically trying to figure this out as I type. It’s not a matter of if they’ll figure it out, but when. The security community have bought us time. That time should not be squandered, but used to protect the internet as a whole, and to protect ourselves.
Apple’s security reputation takes another dent this week with yet another zero-day exploit in its QuickTime media player. There is now proof-of-concept code out there which uses this exploit to remotely compromise computers running both Windows and Mac OS X. The vulnerability exists in QuickTime’s handling of media streamed over the RTSP protocol. If you are a bad guy all you have to do to use this exploit to attack someone is to get them to open a specially crafted RTSP URL (a url starting with
You can get more details from US-CERT. That page also gives you some guidance on protecting yourself. However, those instructions are very windows-centric.
[tags]Apple, QuickTime, Zero Day Exploit[/tags]
Please note that this article is a follow-on article from two previous articles (Eircom Exposes Its Broadband Customers to Serious Security Risks and Eircom Security – More Bad News and Some Suggested Solutions). The previous articles lay out the problems and some suggested solutions in detail. This article will not repeat those detailed explanations and justifications. I am writing this article with the assumption that readers will have first read the two original articles.
This article starts by presenting the details of Eircom’s response before providing a brief analysis leading to some conclusions. For those of you too lazy to read the whole article, were this to be school I’d give Eircom a passing grade, but not a great one. Say a high D or a low C.
[tags]Eircom, Netopia, WEP, WPA[/tags]
It’s not long ago that I posted about Apple not patching their SAMBA implementation for months after a patch became available. Now there is a Quick Time vulnerability in the wild that was apparently reported to Apple about a year ago. I constantly give off to Microsoft for this kind of carry-on, so, each time I catch Apple at it I’m going to highlight it too. The Mac user experience is currently fantastic but Apple’s continued complacency about security is putting that experience at serious risk. How bad will things have to get before Apple cop on to themselves?
For more details on this vulnerability (which affects Windows too) check out this Mac World article
[tags]Apple, Security, QuickTime[/tags]