Cryptography, Information Security, Network Administration, System Administration, Wiretapping

Alice and bob are no longer online

In the past few years Diffie-Hellman has become unsupported in the main internet websites, do you know the implications?

But this is not the only thing happening, many reputable websites, including banks, social networks and search engines have chosen to continue to support for TLSv1.0 and SSLv2 “for compatibility reasons”

The semi-formal common response on the Internet is:

“We must maintain the support for every legacy operating system … even for those deprecated versions of Windows 2000 and XP SP1 which are vulnerable to all kinds of malware”

However, to what extent is cipher important for us?

Encryption techniques today are not only used to transmit secret messages between two submarines in wartime. Or, even for those who think they are very smart about the subject: “To protect banking information so hackers can not see your credit card number“.

and who cares? As banks are insured, and people know that if at any time they see something wrong with your credit card, the bank will return the money.

Without realizing it, encryption for us has become more and more important:

  1. Privacy and Confidentiality: No one wants to expose his e-mail to a hacker… It doesn’t matter if you don’t think that your info is not valuable enough. If you are malicious enough, then you might think, and if someone stole or read e-mail, can they steal my twitter? my facebook account, perform any kind for social+economic harm, etc? The answer is simple: YES.
  2. Authentication: When you use your online banking passphrase, you want this passphrase to reach only the bank, not anyone else …
But hey, those are the most common things. There is a world of things that work with encryption that we don’t see, and are far more dangerous for us.

Let’s talk about W32.FLAME-A.

A few months ago news appeared about an Internet worm that exploited a vulnerability in … The mechanism of certain versions of Windows XP MD5 signed with the authenticity of its updates …

That sounds nice and very technical, but what does this really mean?

It means that the self-replicating program (aka worm) could impersonate Microsoft and could install anything on your machine like the windows update does.

And what did FLAME?

flame, more than a self-reproducible automata, it was just a botnet with remote targeted  infection capabilities. It was designed to avoid massive spread and to avoid being found before it fulfilled it’s purpose…

Flame could infect their victims and hear their conversations using the computer microphone to listen in real time. They had capabilities to see your screen, read your mail and read whatever you type … and it was described as: “very sophisticated”

Kaspersky told me that this level of sophistication, can only be achieved by states… So I must be secure, I’m not an state target.

Well, perhaps no. If you know a little of the history of hacking, you may ask: what’s the difference between that and Sub7 (written 1 decade ago)?

It differs in that that the sub7 server weighted about 300kb and flame about 20Mb (The VXer community must be very sad about it, I remember that a 300kb virus or worm was a dinosaur…). However flame had some interesting self-replication and modular capabilities…

Without elaborating so much in that, the main idea is that FLAME is not as sophisticated as it said to be. Basically is a meterpreter copycat.

Meterpreter is an opensource tool that has:

  • Remote self-propagation capability (as flame does) 😉 msf3 route + meterpreter Rul3z!
  • Cryptor engine (as flame barely does), in order to prevent antivirus software to recognize the malware inside.
  • Screen sharing capabilities.
  • Voice and network wiretapping
  • Webcam takeover
  • Firewall evasion techinques using proxies and reverse connections.
  • Plugins (Instead LUA, Meterpreter uses python)
  • Multiplatform
  • Run over many languages (bin, php, etc).
  • Etc…
Returning to the main idea, in 2004 it was announced that MD5 was broken (collision found), and not many people paid attention. Who cares about crypto paranoids? …
Then flame used this vulnerability to inject itself in an elegant way, and as did flame, it is possible that any hacker can inject any code (I.E. Sub7) into your computer if your windows still using MD5.

And knowing how important it is for us now, in which things we are failing?

Not only MD5 has been found vulnerable.

In the world there are many encryption protocols, each is good for something different, and each alone may be vulnerable if used incorrectly.

Walking in the field of encryption, is like walking into a minefield.

For example, almost all websites are using RC4 to transmit an encrypted text, this algorithm is preferred because it is the simplest, the lightest and most supported.

The pretext of those who set up websites is:

It is lightweight and is the most compatible, on the other hand, is safe enough.

However, RC4 is a flagged encryption algorithm. If you know the transmitted text (that in most cases you know it), you can eventually find the key through certain statistical analysis.

In theory, this does not apply to SSL / TLS using RC4. There are certain design considerations and limitations that prevent such attacks, However, the block cipher AES-256 has been recommended in replacement.

Then, everybody uses the pre-text that RC4 is lightweight, and although AES functions are now accelerated by the new Intel processors, they are still putting RC4 ahead. To make things worse, many internet websites still support insecure versions of SSL / TLS, and specifically disabled the DH support.
Do you think that they care about?

It’s clear that they unplugged Alice and Bob.

How SSL/TLS works:

To summarize, and possibly in a vague explanation:

  •  The client initiates a connection to the server
  •  They share information that supports each (encryption algorithms, etc)
  •  The client and server send their public certificate signed by the CA
  •  The client validates the certificate is signed by the CA
  •  The server (if required), validates that the client is signed by the CA.
  •  The client and server exchange key (signed and encrypted)
  •  Both validate that the  signature is ok for the shared key (using shared certificates)
  •  The rest of the traffic is encrypted using symmetric encryption using the shared key, and if required, are signed by a hash.

There are two methods of key exchange in TLS / SSL:

  1. Using RSA / DSA. The client generates a random temporary key, and sends encrypted using the server’s public key (which is known and verified by certification authority). The server will have a key to send encrypted text in their preferred algorithm (eg RC4, AES256, etc). This mechanism is perfect for wiretapping. If you got the RSA / DSA private key from the server, and you took a snapshot of network traffic from the SSL / TLS session, then, you are be able to decrypt the key that was used to encrypt, therefore, you will be able to decrypt the transmitted content. So if in 2 years, the server is seized, assaulted, or stolen, your connection may be decoded without problems.
  2. * DH + using RSA / DSA. In this case RSA / DSA is used only to sign the DH authentication and prevent a man in the middle attack to the DH algorithm. Then, we compute the final key from both sides (client-server) using DH. Unlike pure RSA, all the parameters in random-key generation are kept in memory and never shared directly trough network (we only share a non-reversible numbers). Therefore, closing the session, these parameters will be erased from memory and Even if you have the private key, the information in the network wont be sufficient to reconstruct the symmetric encryption key.

Using DH would make it virtually impossible to do post-portem wiretapping, however, for some strange reason, many servers over the internet have dropped the support for it.

Even in some places is said to be insecure, because “if you solve a complex math problem,” then it would be unsafe (by the way, as I recall, that problem would also insecure RSA). Other critics say it is unsafe because it is vulnerable to attack man in the middle … But that is solved by using the RSA/DSA signatures in SSL / TLS.

Want to try the securest SSL3 with DH over the internet?

Imagine the following scenario:

You have read this article and say: well, I’ll force my browser to use SSLv3, AES-256, Diffie Hellman algorithms, etc..

Firefox is one of the few browsers (if not the only one) that lets you customize the encryption algorithm in which you feel safe.

How to do it? all you have to do is … set up your browser.

WARNING: If you do not know what you are doing, your browser may become unusable on half of the internet.

Let’s start with security.ssl.require_safe_negotiation

This parameter dictates the following:

Setting this preference to “true” is the only way to guarantee full protection against the attack. Unfortunately, as of time of (initial) writing, this would break nearly all secure sites on the web. (Update: As of December 2010, this still applies for a majority of web sites.)

To do this, you have to write in your browser:  about:config and press enter. Then in the search field write: “ssl.req”

Then, switch from “false” to to “true”

Now, navigate and see what happens:

I’m not gonna talk about specific websites who are secured or not, please navigate a lot inside those sites that you consider “supersafe” (like adobe.com) and check for the following message:

Now lets do something very audacious. Disable all the protocols that begin with ssl3.rsa_, leaving the ones who begins with ssl3.ecdh and ssl3.dh

Lets see:

Google.com, Twitter.com, youtube.com:

Microsoft.com, wordpress.com:

www.mozilla.org:

Because I’m bored to navigate this way, I allowed the “super safe navigation” with the RSA key interchange..

You must consider the following thing:

  • Preferably you should activate the require_safe_negotiation parameter and get ride every site not supporting it. Without this, any MITM is a serious risk. That does not only imply risk on eavesdropping, they could also modify, intercept and rewrite your connection. Moreover, they can use that to install malware into your computer.
  • If you don’t have the control and activated the security measures, You cannot consider any SSL communication as a private communication. Remember how the “MEGA” servers were seized.

If you wanna see a proof of concept of SSL interception without MITM and without our friends Alice y Bob, please feel free to read the following articles:

If you wanna bring your clients the highest level of security, eg. on Apache, just modify  ssl.conf (from mod_ssl) and edit the following lines (Consider that some internet browsers wont be able to reach your website):

 # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. #SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW # SSL Protocol support: # List the enable protocol levels with which clients will be able to # connect. Disable SSLv2 access by default: 
SSLProtocol SSLv3
 # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. # SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW #SSLCipherSuite EDH:ADH:!RC4:!MD5:!DES:!AES128:!CAMELLIA128 
SSLCipherSuite HIGH:SEED:!aNULL:!kRSA:!PSK:!RC4:!MD5:!AES128:!3DES:!CAMELLIA128
SSLHonorCipherOrder on

The following algorithms will be used to encrypt:

 $ openssl ciphers 'HIGH:SEED:!aNULL:!kRSA:!PSK:!RC4:!MD5:!AES128:!3DES:!CAMELLIA128' | tr ':' '\n'
 DHE-RSA-AES256-SHA
 DHE-DSS-AES256-SHA
 DHE-RSA-CAMELLIA256-SHA
 DHE-DSS-CAMELLIA256-SHA
 DHE-RSA-SEED-SHA
 DHE-DSS-SEED-SHA

BTW: If you are reading this post on unmanarc.com, is because your browser support the cypher algorithms exposed ;).

Using RSA / DSA. The client generates a random temporary key, and sends encrypted using the server’s public key (which is known and this in turn signed by the certifying authority). The server will have a key to send encrypted text in their preferred algorithm (eg RC4, AES256, etc). This mechanism is perfect for wiretapping. If you get the key RSA / DSA private server, you can take a snapshot of network traffic from the SSL / TLS session, and be able to decrypt the key that was used to encrypt, therefore, be able to decrypt the content transmitted . So if in 2 years, the server is seized, assaulted, or stolen, your connection may be decoded without problems.