Sigh

I wanted to say something, but, of course, Schneier has said it so well already…

http://www.schneier.com/blog/archives/2009/12/separating_expl.html

Seeing as the existing methods worked so well in preventing this attempt, it’s a good job they’re bringing in newer and more effective protective mechanisms….

Hacking: SSL testing revisited


 

An analysis of a server offering encrypted communication should always included test for the security of the encryption. Things that spring to mind are of course if the encryption algorithms used are strong enough to withstand a cryptanalysis. So everything under 128 bit should definitely be considered weak. The testing for this can of course be done with openssl s_client –connect [-ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1] servername:443. So for going through all the tests (protocol versions times all supported ciphers) you should either script something up or go for tools like sslscan or for windows thc ssl check.

Note: these tools just test for the normal used cipher suites and you will never end up with a complete picture of all the supported ciphers. So going back to manual testing depends if you find something or not with these tools and how far you want to go.

 

Next thing should of course be to test for weak protocol versions namely SSLv2. Although for SSLv3 there are now also known public weaknesses.

For the testing approach the same techniques as for the weak cipher lengths can be used.

 

Things that might not spring to mind at a first glance – but should definitely be tested for – are key exchange and renegotiation support.

 

Key exchange: The security of the communication relies heavily on the key exchange phase. If the exchange has weaknesses an attacker would not need to attack the cipher as he already got the key. Therefore the certificate of the server should be analyzed if the public key has the appropriate strength. Every key length under 1024 bits should be considered weak. Acceptable for new certificates should only be 2048 or even better 4096 bits. Testing for it is easy. Just download the certificate from the server and look at the public key.

 

Renegotiation support: Basically the renegotiation support with in the TLS protocol allows a man in the middle attack. Not the easiest to exploit but it could allow an attacker to insert traffic in an encrypted channel. In short an attacker sets up a encrypted channel with a server and renegotiates it to be used between the victim and server.

This can be tested again with openssl s_client -connect servername:443 and then

 

HEAD / HTTP/1.0

R

 

The single R in a line should do the trick. If the http request gets completed the server is vulnerable.

 

The last thing that springs to mind for testing ssl is if the certificate is in the right format and is valid. So nothing like a self signed certificate or wrong name or live time expired.

 

This should give a more complete picture of ssl testing.

 

 

The Internet is not Real World

The Internet isn’t the real world.  That’s not that hard a concept is it?  In training courses I’ve felt a little embarrassed when making a point of this early on in the presentation, as it feels like such an elementary point.

But occasionally, due to the nature of some of the mailing lists I’m on, I have to explain this. Some annoyed spam recipient, or a user with new firewall software and mad whois skillz, wants to exact retribution on the dastardly IP address that just attacked him; and I explain how difficult it is to tie received traffic to an IP address, and an IP address to a person.

Then I read this:

“Real Security Is Threat-Centric” at http://taosecurity.blogspot.com/2009/11/real-security-is-threat-centric.html by Richard Bejtlich.

Now if you’re trying to pin down the source of a concentrated attack by many parties, and trying to generally attribute it to a foreign power or a criminal gang, or a concentrated concerted attack, I can see his point about attribution, just, if I squint. However the online equivalents of Bejtlich’s “local residents” are unlikely to come under such an attack, and will more likely be spammed using hacked email accounts or faked sender addresses, compromised through a drive-by download, infected by a worm, simply be some bot, or similar.  In those cases attibution is very difficult, if not impossible.

To stretch Richard Bejtlich’s example even farther… imagine the situation, two suspects were questioned Friday, but the suspects claimed that their bodies had been compromised and were under the control of malicious ghosts, or that the evidence of the break-ins had been remotely faked by a rival of theirs from Brazil; or the victim’s possessions had only been copied, not removed, so no-one noticed they’d been “stolen” for several months, meaning all the forensic evidence of the break-in had been destroyed.

Ridiculous ideas, yes?  But their online equivalents are possible because… wait for it… The Internet is not the Real World, don’t expect the same methods to work on here.

Hopefully

From http://www.wired.co.uk/wired-magazine/archive/2009/12/features/25-ideas-for-2010-neurosecurity.aspx ( 25 ideas for 2010: Neurosecurity ), a quote from Kevin Fu, of the Medical Device Security Centre:

“Hopefully the medical community will have the proper regulatory incentives to manufacture devices that can resist the security and privacy risks introduced by wireless communication,” says the MDSC’s Kevin Fu. “Otherwise it’s a no-brainer that some depraved person will attempt to cause harm.”

Undoubtedly this has been taken out of context.  Partly because the second point doesn’t follow on from the first – the threat will be there regardless of whether it will be resisted or not.  But mainly…  hoping that a community will come together to provide regulatory incentives is obviously overly optimistic: the glacial evolution of the PCI DSS shows that it’s unlikely at best. I’m hoping the BioTechnology Indsutry Organisation Device Security Standard ( BIO DSS ) is alive and well by the time I require one of the devices.

Link: I love Russian ransomware


Here the story from CA:

 

http://community.ca.com/blogs/securityadvisor/archive/2009/11/30/ransomware-blocks-internet-access.aspx

 

Funny, that they produce a key code generator :-)