Ssllabs.com has upgraded its ssl tests with Poodle-attack (taxonweb.be and hospital are vulnerable)

http://ssllabs.com has upgraded its tests and included the test to look if the Man In The Middle (MITM) attacks that can intercept all your authentification and transaction details is possible with the Noodle attacks. 

There are other scanners like poodlescan.net but these are not that complete and the information they give is confusing. They only indicate what a hacker will see when he does a global scan (that is scanning if something is possible) before starting his real attacks. So if you have left the port open for sslv3 but have mitigated the use of it (when did you leave the port open) than you will have all that scanning and attack traffic afterwards. 

an example of this is 

belgium.be : not vullnerable but didn't desactivate protocol sslv3 https://www.ssllabs.com/ssltest/analyze.html?d=belgium.be  they have 

vlaanderen.be : not vulnerable but SSL configuration needs some work  (how they are configuring openssl is openly documented on the web for everybody to read - and the freedom they leave to the local developers - https://mft-ti.vlaanderen.be/doc/en/MOVEitDMZ_SystemConfiguration_SSLAndSSH_SSL_SSLConfiguration.htm)  https://www.ssllabs.com/ssltest/analyze.html?d=vlaa... (this is stupid because it indicates there may be other infrastructure that has used this freedom to downgrade and may be vulnerable) Well such technical documentation should never be published on the web for all to see, there is no reason for that. 

taxonweb.be  vulnerable  they have a very badly configured certificate (since several years already) https://www.ssllabs.com/ssltest/analyze.html?d=taxonweb.be  and they have a bad SSL configuration which makes several man in the middle attacks possible https://www.ssllabs.com/ssltest/analyze.html?d=ccff02.min...

oh yes and they will say there is double authentification with your EID and so on but what they forget to tell you is that that information on your EID and the login comes over a tunnel that is encrypted. Well if the information in that tunnel is only encrypted in ssl v3 than the malware in the computer can intercept it and decrypt it or interfere with the transaction during the transaction. It will probably have to interrupt the connection to oblige the user to restart and make suir that at that time the restart for the encryption is done in the vulnerable ssl protocol so that any information that goes through the tunnel (transaction between the EID reader and the portal) will be intercepted 

in 2008 a proof of concept was developed that did just that (intercepting all the information that was on the EID that was read by an EID reader) by only changing something in the registry of the computer. It took 6 months of discussions to get it accepted as a securitybug and to get a patch out. 

inami.be vulnerable https://www.ssllabs.com/ssltest/analyze.html?d=inami.be  the central station of ehealth 

University hospital of Antwerp VERY VULNERABLE https://www.ssllabs.com/ssltest/analyze.html?d=uantwerpen.be (they probably will have to go offline for maintenance)

securemyethias.ethias.be  vulnerable  https://www.ssllabs.com/ssltest/analyze.html?d=securemyethias.ethias.be

homebanking.santander.be  vulnerable and very very BAD ssl configuration https://www.ssllabs.com/ssltest/analyze.html?d=homebanking.santander.be+ 

this means that 

* if clients are infected with bankingtrojans that are capable of doing a MITM attack they can interfere with the SSL protocol and downgrade it to ssl V3 so they can break it and get the authentification and all other information necessary 

* if the servers are compromised they can oblige the clients which haven't upgraded their browsers or blocked the ssl v3 to reset their encryption to ssl v3 and transfer the authentification data to the datadump where it can re-used or sold to somebody else 

  For the servers it is important the keep-alive function is also activated and possible because the attacker will need to have this to make his attack work (with the knowledge at the present time). It proves another time that the keep alive in authentification services is something that will be on its way out..... (and in fact it is so insecure if you think about it that you wonder why it was introduced in the first place except for the only reason any unsecure method or protocol was introduced and that is because of the clientpeople who think that servicability is more important than security (while in fact it is the other way round and people will respect that)) 


Permalink | |  Print |  Facebook | | | | Pin it! |

The comments are closed.