Banca Online en Chile y la inSeguridad de sus protocolos SSL/TLS

En los últimos meses se han divulgado una serie de vulnerabilidades que afectan a los protocolos de comunicación segura SSL/TLS. Estas vulnerabilidades afectan la integridad y confidencialidad de la información y en algunos casos facilitan los ataques de denegación de servicio. Las vulnerabilidades consideran distintos aspectos de una comunicación segura, como los protocolos utilizados, los […]

En los últimos meses se han divulgado una serie de vulnerabilidades que afectan a los protocolos de comunicación segura SSL/TLS. Estas vulnerabilidades afectan la integridad y confidencialidad de la información y en algunos casos facilitan los ataques de denegación de servicio.

Las vulnerabilidades consideran distintos aspectos de una comunicación segura, como los protocolos utilizados, los mecanismos o algoritmos de cifrados, la robustez de las llaves y configuraciones desde el lado del servidor.

Con el fin de poder entregar una visión general de la seguridad y la privacidad del homebanking chileno, seleccionamos los principales bancos y los sometimos a las pruebas que demuestran sus vulnerabilidades y debilidades.

En este estudio, solo se consideraron aquellas que ponen en riesgo la privacidad e integridad de los datos.

Las pruebas a las que fue sometida la banca online, permitieron verificar el estado de vulnerabilidades conocidas como POODLE, LogJam, CRIME, RC4, Heartbleed y FREAK.

Un resumen de cada vulnerabilidad

• POODLE (Padding Oracle On Downgraded Legacy Encryption): Publicada el 14 de Octubre de 2014, permite descifrar el tráfico realizando tan solo 256 peticiones por byte.
• LogJam (Weak Diffie-Hellman): Publicada el 20 de Mayo de 2015, permite descifrar e inyectar tráfico aprovechandose cuando se utiliza el cipher DHE_EXPORT.
• CRIME (Compression Ratio Info-leak Made Easy): Publicada el año 2012, permite el robo de cookies/sesiones supuestamente seguras, utilizadas bajo los protocolos HTTPS y SPDY.
• RC4: Es un sistema de cifrado débil y obsoleto. Existen distintos ataques relacionados con este algoritmo. El último se presentó el año 2015 descifrando con exito una sesión/cookie supuestamente segura en 75 horas.
• Heartbleed: Publicado el 8 de Abril de 2014, permite a un atacante poder acceder a las llaves privadas o PK de un servidor, o bien interceptar y robar otro tipo de información cifrada. Afecta sólo a OpenSSL en una versión en específica.
• FREAK (Factoring Attack on RSA-EXPORT Keys): Publicada a comienzos del 2015, permite a un atacante interceptar y descifrar el tráfico seguro entre un cliente y un servidor vulnerable.

Todas estas vulnerabilidades tienen un nivel complejo de explotación, si bien existe mucha documentación técnicas relacionada a cada una de ellas, existen pocas pruebas de concepto donde se de a conocer el impacto real de cada vulnerabilidad. De todas formas, existen registros de ataques incluso antes de que se hicieran públicas, por lo que se recomienda aplicar las contramedidas necesarias y no exponerse a riesgos innecesarios.

Las protecciones para estos tipos de ataques deben venir tanto por el lado del navegador (cliente) como del servidor. En la actualidad los principales navegadores (Chrome, Firefox, etc) han deshabilitado ciertos mecanismos de cifrado y son capaces de detectar cuando una comunicación segura es débil.
Por el lado del servidor, existen documentos técnicos que ayudan a mitigar todos estos puntos. En la práctica no requiere muchas modificaciones o configuraciones.

¿Es la Banca Chilena inSegura?

Los resultados de las pruebas realizadas indican que de un total de 13 Bancos analizados, al menos el 53% usa un cifrado débil y obsoleto (RC4), esto facilita ataques contra el protocolo SSL/TLS que permiten descifrar información que va desde el cliente al servidor. Por otra parte un 30% de los bancos son vulnerables a POODLE, un 15% a LogJam y un 7% a FREAK. Sin embargo ninguno de estos ellos se ve afectado a vulnerabilidades como CRIME o Heartbleed.

Resulta muy alarmante que a la fecha, sitios transaccionales como los bancos tengan vulnerabilidades y debilidades en sus protocolos SSL/TLS, sobre todo si se trata de vulnerabilidades conocidas y que en algunos casos la forma de mitigación es tan simple, como cambiar el algoritmo de cifrado que se utiliza para mantener la comunicación segura.