Using emails, control panel, electronic banking system all these operations and others should be fully secure and protected. If all data are transmitted over a secure SSL connection many people think that it is fairly secure. But the question is that true?
The answer is yes but not 100%. To transmit data like login and password in a clear text is unsafe because an attacker can easily intercept, modify or replace it. That is why instead of using HTTP to check mail or to authenticate users we use secure HTTPS which is slower but provides encryption over SSL protocol.
SSL is built on asymmetric key. The public key is distributed to everyone, and with it data are encrypted. And each user has a private key to decrypt the data on the server. The public key is available from server to client and is issued as a certificate signed by the CA (Certification Authorities), and contains the following:
– Dates of Issue
– validity (date of expiring)
– The total (unique)reference of the issuer
– Public key publisher Name (source of certificate)
Actually there are two types of website certificate, the first is Root CA which is the most trusted and it is embedded in the browser so it can guarantee that the site is legitimate, the second is intermediate CA this one also can be used for signing website but it does not guarantee that the site is legitimate and are not embedded in the browser.
Now let’s imagine this scenario:
We have certificate for Sectechno.com; it is the last link at the certificate chaining (Root CA- Intermediate CA – Intermediate CA – Sectechno.com). Why don’t we make the site also as an intermediate? For example paypal.com or whatever the chain will looks like this (Root CA – Intermediate CA- Intermediate CA – Sectechno.com – paypal.com).
So here the browser will not check the value of these fields and he will determine it as a Root CA for paypal.com website and you can create certificate to any domain without the browser suspect that it is not a valid one.
This type of attack was demonstrated by Researcher Moxie Marlinspike at the Black Hat conference by using his tool SSLSniff , the SSLSniff allow a hacker to perform MITM (Man in the Middle) attack by intercepting all traffic that client request over the HTTPS protected website(login ,password…). So an attacker can create a certificate for a certain website and sign it with an existing certificate, and sniff all data sent by the victim and the vulnerability remains unpatched in Microsoft’s CryptoAPI.
Microsoft are planning for next week a bunch of patches for several products, about 13 fix to repair 34 vulnerabilities but there still nothing mentioned about the CryptoAPI bug.
make sure you subscribe to my RSS feed!