Now this story interests me on so many levels.
It has put Wollongong on the map again people. I'll admit I was raised in the Gong, so it is good to see someone even making notoriety that is from Wollongong. The last renowned intelligent export we had was Evelyn Owen or Sir Lawrence Hargrave (1939 and 1915 respectively) so it has been some time between.
I also dislike apple, there practices annoy me; there practice of dumbing down everything even the extremely technical is the same as dropping superfluous words from the English language to make it easier for speakers, we only need one word for cold right? They also stand on the shoulders of giants, yet give little recognition to those. Yes they made Unix "usable" (so did Linux without the pompousness), but try and find their references of gratitude to all their stolen code, or stolen ideas, nope. Apple have fallen down in the security world repeatedly, and this is a glaring example who sets the same password on every device when you can assume with pretty high certainty that people are going to attack it and find out your password, hence the unlocking.
The other reasons this is interesting is it is a virus that Rickrolls people, hilarious. Rickrolling is something I have done, and had done to me a fair few times, it almost always makes me smile. The other humorous point of this is the author is Ashley Towns, so the meme of Rick Astley is almost made for him.
Well if you own an iphone (hisss) then you can secure it against this virus here(a simple passwd to fix it), bear in mind that this virus will probably hang around for a few years like code red and slammer, funny stuff.
Tuesday, 17 November 2009
Wednesday, 2 September 2009
Revocation, just rolls off the tounge
First an overview, SSL is pretty much the only protection available when banking, shopping etc. It means the user has to look for the https:// up the top rather than the http:// to ensure the session from their browser to the websites server is encrypted in transit (this isn't perfect people can fake some certificates, and security researchers are trying to find its holes all the time). Don't trust the lock or the little green bar that EV certs give you as these can be faked several ways, generally though the https and certificate information can be trusted. Also look at an extension for FireFox called SSL blacklist for FireFox that will notify you if a certificate is bad due to one of many reasons.
One of the interesting things about certificates is of course they have to be able to be revoked, when for some reason they become compromised or some such other reason.
CRL or certificate revocation lists as some are probably aware are basically a list stored on the company that provided the certificates website, basically a list of all the certs that have been revoked. Excellent idea, but look at most certificates details and CRL is hosted on a good ole plain http site eg; http://crl.thawte.com/ThawteSGCCA.crl
YAY, so if you want just own a few crl via DNS poisoning or man in the middle (MITM) a user (can we say web cafe) and serve up a fake crafted CRL to revoke heaps of certificates or just remove your revoked cert for their bank etc. Of course there are a lot of variables here, you need to know the CRL that is going to be requested though if you have MITM'd them you can just serve all of them up, they are usually signed, but not always, you also need to know sites they are going to go to, but you can dynamically do this as well.
Their digital signing doesn't look that good from what I have seen from reading the crl's either, but they are supposed to sign it with their SSL certificate available from their site via a link, so no trust their just sign it with your own cert and serve that up at their site as you are already in the middle.
But the nice thing as far as a denial goes is that most operating systems cache this info (for 24 hours usually), and the Certificate hierarchy is good just blacklist the vendors root certificate.
To do any real damage you still need to get a certificate registered that has been falsely registered, or do a bit of social engineering, blacklist all certs and pop up a page saying the user needs to update their certificates, redirect them to a legit looking site that asks them to install a certificate package full of your own generated root certificates, all SSL sites from then on are readable as you re-sign them with your key on the way through.
Of course SSL isn't a fix for the revocation lists as no one will see that it requests the list from https instead of http, I have even seen some installs of Internet Explorer that have certificate revocation checking turned off, I am not sure if this is default, but bad none-the-less.
Well I hope this long winded odd rant is at least made some people think. It is a very odd setup and I am surprised all CRL's don't require possibly multiple signing by at least two vendors kind of like nuclear launch codes.
One of the interesting things about certificates is of course they have to be able to be revoked, when for some reason they become compromised or some such other reason.
CRL or certificate revocation lists as some are probably aware are basically a list stored on the company that provided the certificates website, basically a list of all the certs that have been revoked. Excellent idea, but look at most certificates details and CRL is hosted on a good ole plain http site eg; http://crl.thawte.com/ThawteSGCCA.crl
YAY, so if you want just own a few crl via DNS poisoning or man in the middle (MITM) a user (can we say web cafe) and serve up a fake crafted CRL to revoke heaps of certificates or just remove your revoked cert for their bank etc. Of course there are a lot of variables here, you need to know the CRL that is going to be requested though if you have MITM'd them you can just serve all of them up, they are usually signed, but not always, you also need to know sites they are going to go to, but you can dynamically do this as well.
Their digital signing doesn't look that good from what I have seen from reading the crl's either, but they are supposed to sign it with their SSL certificate available from their site via a link, so no trust their just sign it with your own cert and serve that up at their site as you are already in the middle.
But the nice thing as far as a denial goes is that most operating systems cache this info (for 24 hours usually), and the Certificate hierarchy is good just blacklist the vendors root certificate.
To do any real damage you still need to get a certificate registered that has been falsely registered, or do a bit of social engineering, blacklist all certs and pop up a page saying the user needs to update their certificates, redirect them to a legit looking site that asks them to install a certificate package full of your own generated root certificates, all SSL sites from then on are readable as you re-sign them with your key on the way through.
Of course SSL isn't a fix for the revocation lists as no one will see that it requests the list from https instead of http, I have even seen some installs of Internet Explorer that have certificate revocation checking turned off, I am not sure if this is default, but bad none-the-less.
Well I hope this long winded odd rant is at least made some people think. It is a very odd setup and I am surprised all CRL's don't require possibly multiple signing by at least two vendors kind of like nuclear launch codes.
Wednesday, 24 June 2009
Vmware issues
Not so much a dedicated security issue (though Availability is in the CIA triangle that should be drummed into everyone by now), but something I thought I would blog about as I found it no where else.
I was having an interesting issue with a guest on one of the ESX clusters I manage, looking at the ESX host, none of its other guests were having issues. The guest in questions came up as disconnected, not powered on. But I could RDP to it.
I logged into the host and checked esxtop and noticed the Guest was in the list.
Checking the tasks of the Guest in the Vmware client I noticed its VCB backup last night died, and that the error I was getting on the guest was Unable to communicate with host, since it is disconnected, I got this same message when trying to power on the guest.I quickly checked the vmware.log and dmesg on the ESX host that was hosting the guest, nothing obvious, googling around gave me no answers. It was then I noticed the last entry in the vmware.log was early this morning, to do with CD rom errors. I thought it could be a simle management disconnect, so I ran
/etc/init.d/mgmt-vmware restart
The whole ESX server disconnected from the VMware client as you expect, then it came backup, the problem host came backup too, no downtime, no mess. Ran a quick manual backup and all done.
I was having an interesting issue with a guest on one of the ESX clusters I manage, looking at the ESX host, none of its other guests were having issues. The guest in questions came up as disconnected, not powered on. But I could RDP to it.
I logged into the host and checked esxtop and noticed the Guest was in the list.
Checking the tasks of the Guest in the Vmware client I noticed its VCB backup last night died, and that the error I was getting on the guest was Unable to communicate with host, since it is disconnected, I got this same message when trying to power on the guest.I quickly checked the vmware.log and dmesg on the ESX host that was hosting the guest, nothing obvious, googling around gave me no answers. It was then I noticed the last entry in the vmware.log was early this morning, to do with CD rom errors. I thought it could be a simle management disconnect, so I ran
/etc/init.d/mgmt-vmware restart
The whole ESX server disconnected from the VMware client as you expect, then it came backup, the problem host came backup too, no downtime, no mess. Ran a quick manual backup and all done.
Subscribe to:
Posts (Atom)