Archive for enero, 2014

La seguridad de los sitios financieros y públicos en Chile

miércoles 22 de enero, 2014

Si hay una lección importante que aprender de todo lo sucedido el año 2013 es que nuestra privacidad y la seguridad de nuestros datos en la red están siendo atacados en forma incesante por razones tanto [políticas](http://www.theguardian.com/world/the-nsa-files «The NSA files | World news | The Guardian») como [económicas](http://krebsonsecurity.com/2013/10/adobe-breach-impacted-at-least-38-million-users/). Estas historias han puesto en evidencia la importancia de que instituciones públicas y privadas redoblen sus esfuerzos para utilizar los más altos estándares de seguridad cuando se trata de interactuar con ciudadanos o clientes en la red.

Esto es lo que tenía en mente cuando me enteré de que [SSL Labs](https://www.ssllabs.com/ «Qualys SSL Labs») había actualizado sus herramientas para medir la seguridad de la configuración utilizada por servidores web, y que utiliza el sistema norteamericano de letras de A (Excelente) a F (Reprobado) para darle una «nota» al sitio. Armado con mi navegador, el [SSL Server Test](https://www.ssllabs.com/ssltest/index.html), y [las recomendaciones](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet «Transport Layer Protection Cheat Sheet – OWASP») de los expertos, probé la seguridad de los sitios de bancos y otras instituciones críticas de nuestra infraestructura digital.

Los resultados, que publico a continuación, muestran que hay varias instituciones que requieren un llamado de sus usuarios para que solucionen lo que podrían ser serios problemas de seguridad:

## Los mateos:

En este grupo están los que se sacan una «A-» por una buena implementación de estándares modernos y seguros para una conexión segura: [ServiPag](https://www.ssllabs.com/ssltest/analyze.html?d=servipag.com) y [TransBank](https://www.ssllabs.com/ssltest/analyze.html?d=transbank.cl), y los Bancos de [Chile](https://www.ssllabs.com/ssltest/analyze.html?d=bancochile.cl), [Itau](https://www.ssllabs.com/ssltest/analyze.html?d=banco.itau.cl) y [BBVA](https://www.ssllabs.com/ssltest/analyze.html?d=bbvanet.cl).

## Los alumnos promedio:

El [Banco Corpbanca](https://www.corpbanca.cl) saca una «B» por no incluir soporte para los protocolos más modernos de encripción.

El [Registro Civil](https://www.registrocivil.cl) y la [Tesorería General de la República](https://www.ssllabs.com/ssltest/analyze.html?d=tesoreria.cl) tienen sitios que mezclan elementos encriptados y otros que no. [Mala idea](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Do_Not_Mix_TLS_and_Non-TLS_Content), aunque no es el [único problema](https://www.ssllabs.com/ssltest/analyze.html?d=www.registrocivil.cl&s=163.247.64.131 «Qualys SSL Labs – Projects / SSL Server Test / registrocivil.cl»).

Pero los hay peores. Mucho peores.

## Los reprobados:

Y aquí llegamos a esas instituciones que han creado sus sitios web utilizando tecnologías obsoletas, inseguras o con problemas de implementación que ponen en riesgo la seguridad de sus usuarios.

En esta categoría caben realmente dos grupos. En el primero están algunos sitios que, de hecho, obtuvieron una buena nota en el test de SSL Labs, pero cuya implementación le resta un tremendo grado de seguridad a sus sitios. Aquí caben los Bancos [Santander](https://www.ssllabs.com/ssltest/analyze.html?d=santander.cl) y [Falabella ](https://www.ssllabs.com/ssltest/analyze.html?d=www.bancofalabella.cl&s=200.10.172.121), que tienen un sitio seguro (pruébelo usted mismo cambiando http:// por https:// en su navegador) pero que *por defecto* ofrecen la página de acceso que se transmite sin encripción alguna (aunque la información del formulario si se transmite así). Como dicen los expertos de la [OWASP](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Use_TLS_for_All_Login_Pages_and_All_Authenticated_Pages
«Transport Layer Protection Cheat Sheet – OWASP»), esto es una mala práctica:

> La página de autenticación y todas las páginas autentificadas subsecuentes deben tener acceso exclusivo a través de TLS. La página inicial de autenticación, denominada «página de llegada de autenticación» («page landing page»), debe estar servida vía TLS. **El no utilizar TLS para la página de llegada le permite a un atacante modificar el formulario de autenticación, causando que las credenciales de un usuario sean enviadas a un lugar arbitrario**. El no utilizar TLS para paginas autentificadas después del *login* permite a un atacante ver el ID de sesión sin encriptar y comprometer así la sesión autenticada del usuario.

En este grupo merece atención especial el [Banco Bci](https://www.ssllabs.com/ssltest/analyze.html?d=bciimg.bci.cl), que tiene un [sitio seguro](https://www.bci.cl/personas/) que responde con un error, cuyo formulario de autenticación es una [ventana emergente](http://es.wikipedia.org/wiki/Ventana_emergente «Ventana emergente – Wikipedia, la enciclopedia libre») que no le permite verificar al usuario la seguridad de la conexión (¿Aló, 2001?). De esto también es culpable el [muy popular](http://www.alexa.com/topsites/countries/CL «Alexa – Top Sites in Chile») [Mercado Libre](http://www.mercadolibre.cl).

El segundo grupo son instituciones que, a pesar de ofrecer la aparente tranquilidad de una conexión segura, utilizan una configuración que recibe una «F» (¡Reprobado!) en el test de seguridad de SSL Labs. Este hall de la desgracia no es ni pequeño ni poco importante, e incluye nada menos que a los Bancos [Internacional](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancointernacional.cl%2Findex.html), [Consorcio](https://www.ssllabs.com/ssltest/analyze.html?d=bancoconsorcio.cl), [Estado](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancoestado.cl%2Fimagenes%2Fcomun2008%2Fnuevo_paglg_pers2.html), [Bice](https://www.ssllabs.com/ssltest/analyze.html?d=bice.cl), [Paris](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancoparis.cl%2F), [Security (!!!)](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancosecurity.cl%2Fwidgets%2FwPersonasLogin%2Findex.asp),[Penta](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancopenta.cl%2FfrmLogin.aspx%3FReturnUrl%3D%252f), [Rabobank](https://www.ssllabs.com/ssltest/analyze.html?d=secure.rabobank.cl «Qualys SSL Labs – Projects / SSL Server Test / secure.rabobank.cl») y [ScotiaBank](https://www.ssllabs.com/ssltest/analyze.html?d=www.scotiabank.cl&s=200.55.208.28). Es decir, de los 17 bancos que son parte de la [ABIF](http://www.abif.cl) más el Banco del Estado, solo cuatro (24%) han implementado sus sitios en una forma que pasa estos estándares de seguridad y ofrecen ese acceso con una página via [TLS](https://es.wikipedia.org/wiki/Transport_Layer_Security «Transport Layer Security – Wikipedia, la enciclopedia libre»).

Y como guinda de la torta, tenemos al [Servicio de Impuestos Internos](http://www.sii.cl) ((El SII tuvo que cambiar, hace unos años, el certificado que usaba para encriptar sus sesiones web después de que el periodista Christian Leal publicara en su blog que el la longitud de la llave del certificado – 128 bit – era claramente insuficiente para estos tiempos.)). El SII comete el mismo pecado de implementación de varios de los bancos que mencionaba arriba, insertando un formulario de autenticación «seguro» en una página insegura (es decir, sin utilizar https/TLS). Como apunta la OWASP, alguien podría atacar a un usuario o grupo de ellos falsificando la página del SII con ese mismo formulario (el usuario normal no tiene forma de saber si ese formulario envía la información en forma segura). Aún peor, el SII [obtiene una «F»](https://www.ssllabs.com/ssltest/analyze.html?d=zeus.sii.cl «Qualys SSL Labs – Projects / SSL Server Test / zeus.sii.cl») con SSL Labs por varias fallas serias de seguridad, incluyendo aceptar conexiones usando protocolos inseguros, no incluir protocolos más modernos y seguros, y ser susceptibles a ataques que se conocen [desde al menos el año 2009](https://community.qualys.com/blogs/securitylabs/2009/11/05/ssl-and-tls-authentication-gap-vulnerability-discovered «SSL and TLS Authentication Gap vulnerability discovered | Security Labs | Qualys Community»).

Hace años, cerré mi cuenta en ScotiaBank en parte porque los problemas de seguridad que noté en su sitio web ((en ese tiempo aún tenían el formulario de autenticación inserto en una página insegura)) me hizo desconfiar de la capacidad del banco de resguardar mis datos. Este simple ejercicio con SSL Labs (y que está lejos de ser una auditoría de seguridad completa) demuestra que los problemas son mucho más generalizados en la internet criolla. Dada las amenazas comprobadas que han sido reveladas en los últimos meses, parece que el mejor momento para asegurar que la información de millones de chilenos está segura era ayer.

**Actualización 27-Enero**: la versión original del artículo decía que el Banco París había obtenido una buena *nota* en el test de SSL Labs, lo que es incorrecto. A esta fecha, obtienen una F.

Los contenidos de este blog están publicados bajo una licencia Creative Commons Atribución-Compartir-Igual. (c) 2005-2024 El Diablo en los Detalles | Usando WordPress y una versión modificada de Barecity.