ID_IDEA: 009
Tecnología: Seguridad en la web
Descripción: HTTPS es el protocolo de seguridad de facto para los buscadores web, sin embargo, incidentes de seguridad reportados ampliamente como DigiNotar, #gotofail de Apple, Heartbleed de OPENSSL entre otros, han evidenciado importantes vulnerabilidades de este protocolo. La idea de esta propuesta es ahondar en las vulnerabilidades del protocolo HTTPS para proponer estrategias para mejorar el gobierno de HTTPS con el propósito de mitigar los riesgos de seguridad en implementaciones sobre la web.
Entre
las plataformas físicas pueden estar: ordenadores grandes y medios ordenadores
departamentales y personales, solos o formando parte de red,
e incluso ordenadores portátiles.
PLANTEAMIENTO
DEL PROBLEMA
La
Universidad Nacional Abierta y a Distancia, aunque cuenta con un sistema de
seguridad informática que permite gestión de vulnerabilidades y riesgos,
actualmente se encuentra expuesta contra amenazas de seguridad web dada la
cantidad de usuarios y la falta de políticas y controles que permitan mitigar
las amenazas.
Si
bien existen procedimientos establecidos sobre el uso de contraseñas, no existe
definida una periodicidad para realizar el cambio, tampoco existe un número de
intentos determinados para acceder al campus, ni alertas que les indiquen a los
usuarios que sobre el hecho, de manera que alguien diferente al usuario
puede intentar entrar al sistema hasta
lograrlo.
Con
el avance de los sistemas de información se hace necesario ir implementando
distintos mecanismos que permitan lograr una mayor seguridad en la Web, de
manera que no se expongan los datos de los usuarios y la misma infraestructura
tecnológica de la organización. De manera que siempre es pertinente hacer una
revisión de aquellos mecanismos de seguridad web que se tienen en el momento y
los que se pueden ir adoptando para mejorar los estándares de seguridad.
APLICACIÓN WEB.
Según el grupo de
ingeniería del Software de la Universidad del Sevilla (2004). Una aplicación
Web es una aplicación informática distribuida cuya interfaz de usuario es
accesible desde un cliente web, normalmente un navegador web. Estos servicios
cliente/servidor, (Navegador Web, Servidor Web y protocolo HTTP) están
estandarizados y no es creado por el programador.
SEGURIDAD EN LA WEB
La
seguridad en la web es una rama de la Seguridad Informática que
se encarga específicamente de la seguridad de sitios
web, aplicaciones web y servicios web.
A
un alto nivel, la seguridad de aplicaciones web se basa en los principios de
la seguridad de aplicaciones pero
aplicadas. Las aplicaciones, comúnmente son desarrolladas usando lenguajes de
programación, tales como PHP, Java
EE, Java,
Python, Ruby, ASP.NET, C#, VB.NET o ASP clásico.
En el caso puntual de la
UNAD cuyo dominio es www.unad.edu.co
se ha realizado una prueba de seguridad al protocolo SSL que permite
identificar las principales vulnerabilidades de la página en cuestión. Para
hacer la prueba se ha utilizado la herramienta SSL Server Test el resultado se
puede ver en https://www.ssllabs.com/ssltest/analyze.html?d=www.unad.edu.co.
De los resultados obtenidos se presenta la configuración de los protocolos TLS
y SSL que son los que han presentado mayores vulnerabilidades a través del
tiempo. Se debe tener en cuenta que HTTPS no es más que HTTP normal sobre
SSL/TLS.
SSL/TLS (Secure Sockets
Layer/Transmission Layer Security) son dos protocolos para enviar paquetes
cifrados a través de Internet, siendo el último el más moderno. Sirven igual
para HTTP que para cualquier otro protocolo de comunicación.
Imagen 1: Configuración
protocolos TLS Y SSL servidor www.unad.edu.co
ATAQUES A LOS PROTOCOLOS HTTPS
TTPS (Protocolo seguro de transferencia de hipertexto) es un protocolo de comunicación de Internet que protege la integridad y la confidencialidad de los datos de los usuarios entre sus ordenadores y el sitio web. Por ejemplo, cuando un usuario introduce sus datos en el formulario de un sitio web para suscribirse a notificaciones o para comprar algún producto, HTTPS protege la información personal de dicho usuario entre él y el sitio. Los usuarios esperan poder proporcionar sus datos de forma segura a través de un sitio web cuando utilizan Internet.
1.
Ataques
del tipo DNS Spoofing
Recordar
el número: 190.66.14.221, que es la IP de esta web: http://www.unad.edu.co no es sencillo,
es por esta razón que cada vez que queramos visitar www.unad.edu.co estaremos consultando a un servidor de DNS para saber cuál
es la dirección de IP asociada al nombre de este dominio en cuestión y poder
acceder a ella. Es decir el DNS es el encargado de resolver por nosotros la
asociación de un nombre de dominio en una dirección de IP. Este servidor se
define en la configuración de Internet del usuario encada máquina que accede a
Internet.
Si se
puede cambiar esa configuración y definir otro servidor de DNS, uno que las
asociaciones entre nombres de dominios e IPs las determine un atacante
malintencionado. En el mejor de los casos no será posible acceder al sitio Web.
Esto seguramente no resulta ser tan grave. Pero si se visita una Web que debería
ser segura pero está asociada a una IP que no lo es. Un atacante puede
modificar una Web legítima para que en lugar de enviar los credenciales de
acceso al servidor oficial los envíe en texto plano al de éste.
Supóngase el caso hipotético: La Web www.unad.edu.co realiza sus conexiones utilizando HTTPS, de esta manera se imposibilita la captura de los campos de autenticación por un tercer. Pero si el DNS es controlado, se pueden redirigir las conexiones hacia otra Web espejo. La web luce exactamente a la original, pero se ha modificado el botón entrar para que envié las credenciales de acceso a un texto plano y el usuario se redirige a la página verdadera, de manera que no logra siquiera darse cuenta de lo sucedido.
Supóngase el caso hipotético: La Web www.unad.edu.co realiza sus conexiones utilizando HTTPS, de esta manera se imposibilita la captura de los campos de autenticación por un tercer. Pero si el DNS es controlado, se pueden redirigir las conexiones hacia otra Web espejo. La web luce exactamente a la original, pero se ha modificado el botón entrar para que envié las credenciales de acceso a un texto plano y el usuario se redirige a la página verdadera, de manera que no logra siquiera darse cuenta de lo sucedido.
2.
Ataque
falsificar certificados
Las conexiones HTTPS, mostrara sin ningún tipo de alarma toda página web
que tenga un certificado firmado por una Agencia de Certificado. En los últimos
años han aparecido una cantidad de AC que emiten certificados muchas veces sin
control. Un atacante puede obtener uno de estos certificados y espiar las
actividades de los usuarios.
En el diario el País (2011), se puede ver el informe sobre la empresa
Cómodo que emitió certificados con los que el gobierno IRANI pudo espiar las
comunicaciones de sus internautas.
3.
Ataque de
renegociación
TLS / SSL permite a los servidores y clientes para iniciar una
renovación o renegociación completa de los parámetros de cifrado utilizado para
TLS / SSL conexiones. Esta capacidad permite a las partes la comunicación de un
proceso abreviado para reanudar una previamente existente TLS / SSL sesión, a
menudo con un conjunto más seguro de los parámetros criptográficos. Al explorar el comportamiento de la renegociación, un
atacante puede insertar contenido que le permita llevar a cabo una nueva clase
de ataque de CSRF, Cross-Site
Request Forgery.
Según Sergio de Luz (2014), se han
identificado cuatro vulnerabilidades del protocolo TLS, este protocolo es usado
actualmente por la UNAD. A continuación se detallan las vulnerabilidades.
ü Los
investigadores han identificado cuatro vulnerabilidades en el protocolo TLS: En
el handshake con RSA, el cliente envía el PMS (Pre-master secret) al servidor
de forma cifrada bajo la clave pública de A. Si A es un servidor malicioso,
podría actuar como cliente de un servidor S legítimo enviando el mismo PMS en
una nueva conexión. Estas dos conexiones se pueden “sincronizar” porque A puede
usar los mismos valores aleatorios y el identificador de sesión en ambas
conexiones, por tanto comparten el mismo identificador, MS (Master Secret) y
claves de conexión. En el ámbito del intercambio de claves, esto es un ataque
UKS (Unknown key-share), que por sí mismo no es una vulnerabilidad grave.
ü En el handshake DHE (Diffie-Hellmann), el
servidor malicioso podría elegir un grupo no primo por lo que el PMS estaría
bajo su control, por tanto, podría montar un ataque MITM como ocurre con RSA
para montar dos sesiones que comparten identificador, MS y claves de la
conexión (otro ataque UKS).
ü En
la reanudación de una sesión TLS, el protocolo sólo verifica que el cliente y
el servidor comparten el mismo MS, suite de cifrados y el identificador, no
re-autentica al cliente en el servidor. Por tanto, esta forma de funcionar
permite a un servidor malicioso montar un ataque UKS con dos sesiones. La
renegociación segura se realiza en la misma conexión, pero esto no se aplica si
la sesión se reanuda en una nueva conexión.
ü Durante
la renegociación, los certificados del cliente y servidor pueden cambiar. El
protoclo TLS lo permite pero no fija
cómo se debe adoptar este cambio. Algunas implementaciones lo asocian al primer
certificado y otras al último.
4.
Ataque
BEAST
El atacante inserte código en la sesión actual del
navegador. Esto puede conseguirse con distintas técnicas, por ejemplo, usando
un Iframe incrustado o con un ataque de secuencias de comandos de sitios
cruzados (XSS). A continuación, este código obliga al navegador a que incluya
un fragmento conocido de texto sin formato en el servidor a través del canal
SSL. De nuevo, esto puede conseguirse fácilmente con Javascript. Antes de
insertar este código, el atacante también necesita poder capturar el tráfico
SSL del usuario, ya sea ejecutando un rastreador en el equipo objetivo o bien
capturando el tráfico mediante un ataque MitM. De cualquier forma, basta con
texto sin formato y una carga cifrada para que ahora el atacante pueda ejecutar
algunas herramientas de criptoanálisis y esperar a conseguir una cookie (Tredimo.es).
5.
Ataque
CRIME
Es una vulnerabilidad explotada es una combinación de inyección de texto plano y de fuga
de información a través de
compresión de datos. Esta se basa en que el atacante sea capaz de observar el
tamaño del ciphertext enviado por el navegador mientras al
mismo tiempo inducir al navegador a hacer múltiples conexiones cuidadosamente
diseñadas al sitio web objetivo. El atacante entonces observará el cambio en el
tamaño de la información solicitada, la que contiene tanto la cookie secreta
que se envía por el navegador al sitio web, contenido variable creado por el
atacante y como el contenido variable es alterado. Cuando el tamaño del
contenido comprimido es reducido, se puede inferir que es probable que en
alguna parte del contenido inyectado, ésta sea igual a parte del contenido
original, la que incluye el contenido secreto que el atacante desea descubrir.
El exploit CRIME fue creado por los investigadores de seguridad Juliano Rizzo y Thai
Duong, quienes también crearon el exploit BEAST. El exploit fue revelado en detalle en
la conferencia de seguridad informática ekoparty 2012 (Wikipedia).
6.
Ataque
Lucky Thirteen
Según el diario noticias sobre seguridad de la información (2013), Lucky Thirteen es un ataque criptográfico y se trata de una nueva variante del Padding Oracle Attack (ya solucionado). En verificación de integridad MAC, la mayoría de las implementaciones de TLS son vulnerables al ataque. Todos los conjuntos de cifrado TLS y DTLS que incluyen el modo de cifrado CBC (Cipher-Block-Chaining) son potencialmente vulnerables a los ataques
Lucky Thirteen utiliza una técnica conocida como Padding Oracle en el motor de cifrado principal en TLS, responsable de realizar el cifrado y garantizar la integridad de los datos. Los datos se procesan en bloques de 16 bytes utilizando una rutina conocida como MEE (MAC-then-Encode-then-Encrypt), que pasa los datos a través de un algoritmo MAC (Message Authentication Code); a continuación, los codifica y los cifra. La rutina añade "relleno" (Padding) al texto cifrado para que los datos resultantes queden perfectamente alineados al límite de 8 o 16 bytes. Este relleno más tarde se extrae al momento de descifrar TLS
El ataque comienza con la captura de texto cifrado a medida que viaja a través de Internet. Usando una debilidad antigua de CBC (modo de cifrado en bloque) en TLS, los atacantes reemplazan los últimos bloques con varios bloques escogidos y observan la cantidad de tiempo que le toma responder al servidor. Los mensajes que contienen un relleno correcto tardarán menos tiempo en procesarse. Un mecanismo en TLS hace que la transacción falle cada vez que la aplicación se encuentra con un mensaje que contiene datos alterados. Mediante el envío de grandes cantidades de mensajes TLS y el muestreo estadístico de tiempos de respuesta, se puede "adivinar" el contenido del texto cifrado
ALGUNAS SOLUCIONES
En la plataforma se deben implementar políticas
de seguridad que mitiguen los problemas generados por la ausencia de estas
políticas con respecto a las contraseñas de usuarios del campus virtual de la
UNAD, Como lo indica el planteamiento del problema, la universidad cuenta con
política de cambio de contraseña, pero este es muy esporádico y también permite realizar múltiples intentos de
acceder a una cuenta y así dar paso a un atacante para que este pueda lograr
una falsa autenticación poniendo en riesgo la información de las personas que
se encuentren registradas en el campus, también se deben revisar y corregir
posibles vulnerabilidades en el protocolo SSL como el conocido HeartBleed o
como el actual DROWN que afecta SSLv2 y muchas otras vulnerabilidades que se
deben parchear desde que son conocidas, es de suma importancia realizar
auditorías de seguridad periódicamente para verificar que la plataforma se
encuentre segura así como los datos de los estudiantes, docentes etc. que
ingresan a esta, también es muy importante capacitar a los usuarios
constantemente ya que el usuario es considerado como el eslabón más débil de la
cadena por los atacantes, por lo tanto si un usuario no está bien informado
sobre esto, un atacante a través de engaños o ingeniería social podría realizar
ataques como el phishing, o tratar que este le entregue sus datos personales, el
servidor debe tener sistemas de defensa contra los DOS o DDOS ya que estos son
los más utilizados por grupos de personas para dar de baja aun servidor.
Una prueba realizada para verificar si los
servidores de la universidad son vulnerables al ataque Drown arroja los
siguientes resultados la solución seria pasar a las últimas versiones de TLS ya
que las versiones de SSL son consideradas obsoletas.
De cómo se utilizará la tecnología escogida
en la resolución del problema.
De acuerdo a las
debilidades identificadas en el sistema web de la Universidad Nacional Abierta
y a Distancia UNAD (www.unad.edu.co), se
proponen a continuación una serie de recomendaciones orientadas a mejorar la
seguridad en la plataforma de la UNAD.
Recomendaciones
de autenticación.
- Se debe proveer de un mecanismo para expirar las contraseñas y obligar a los usuarios al cambio de la misma.
- Limitar el número de intentos de acceso sin éxito consecutivo
- Al superar el número de intentos de acceso sin éxito, debe enviarse un e-mail al usuario informando de un posible acceso por terceros.
- Como medida opcional, se recomienda implementar el sistema de identidad protegida, donde los usuarios además de la clave de acceso, responda a una pregunta previamente establecida de la que solo él debe saber la respuesta. Ya que este método posiblemente resulte algo tedioso para los usuarios, se hace necesario registrar los equipos en los que generalmente ingresa un usuario, esto con el fin de no tener que responder preguntas en un equipo determinado.
- Que el usuario pueda conocer los equipos que aparecen registrado en su cuenta como seguros.
Recomendaciones
de configuración de los protocolos TSL/SSL
- Comprobar el certificado, este debe estar debidamente actualizado.
- Comprobar que el certificdo ha sido emitido por una autoridad acreditada.
- Tener desabilitado SSLv2
- Tener desabilitado SSlv3
- Verificar que SSL 3.0 este deshabilitado
- No usar cypher RC4
- No usar cypher DES
- Comprobar que CRIME este mitigado, para hacerlo es necesario deshabilitar la comprensión del trafico TSL.
- Implementar longitud de clave 1048 bits
- TLS 1.2 y habilitar la extensión de TLS_FALLBACK_SCSV para evitar que los atacantes fuercen protocolos más antiguos.
Cómo se evidencia la innovación tecnológica o apropiación de conocimiento luego de dar solución a la problemática aplicando la tecnología moderna escogida.
Al investigar los casos de ataques al protocolo HTTPS, se ha llegado a la conclusión que el concepto de seguridad en la Web, es relativo, TSL seguridad en la capa de transporte y SSL "Capa de conexion segura", han sido vulnerado una y otra vez, dajando obsoletas versiones cada cierto periodo de tiempo, de manera que al establecer otros mecanismos de seguridad donde el acceso de usuario sea parte fundamental y complementado con certificados fiables y una adecuada configuración del HTTPS, se puede tener un nivel de seguridad mas alto en la plataforma. Ahora bien la innovación esta orientada a la aplicación de buenas practicas de seguridad Web, por medio de un conocimiento profundo del funcionamiento de HTTPS.
Al investigar los casos de ataques al protocolo HTTPS, se ha llegado a la conclusión que el concepto de seguridad en la Web, es relativo, TSL seguridad en la capa de transporte y SSL "Capa de conexion segura", han sido vulnerado una y otra vez, dajando obsoletas versiones cada cierto periodo de tiempo, de manera que al establecer otros mecanismos de seguridad donde el acceso de usuario sea parte fundamental y complementado con certificados fiables y una adecuada configuración del HTTPS, se puede tener un nivel de seguridad mas alto en la plataforma. Ahora bien la innovación esta orientada a la aplicación de buenas practicas de seguridad Web, por medio de un conocimiento profundo del funcionamiento de HTTPS.
Escuela tacnica superior de Ingenieria Informatic (2004). Introducción a las aplicaciones Web, Consultado el 18 de Marzo de 2015, disponible en: http://www.lsi.us.es/docencia/get.php?id=854
Alandete, David. (2011). Un ataque pone en duda la seguridad de HTTPS. El pais. Consultado el 18 de marzo de 2016, disponible en: http://elpais.com/diario/2011/03/25/radiotv/1301007601_850215.html
De luz Sergio (2014). El triple Handshake de TLS es vulnerable a ataques Man In The Middle. Consultado el 18 de marzo de 2016, disponible en: http://www.redeszone.net/2014/03/04/el-triple-handshake-de-tls-es-vulnerable-ataques-man-middle/#sthash.C5655j2G.dpuf
Noticias sobre seguridad
de la información. Ataque de Lucky Thirteen. Consultado el 18 de Marzo de 2016,
disponible en: http://blog.segu-info.com.ar/2013/02/ssl-y-tls-en-peligro-lucky-thirteen.html
Trendmicro.es (2011).
BEAS y la seguridad TLS/SSL: lo que significa para los usuarios y
administradores Web. Recuperado el 18 de Marzo de 2016, disponible en: http://blog.trendmicro.es/?p=1650
Wikipedia (s.f). CRIME.
Consultado el 18 de marzo de 2016, disponible en: https://es.wikipedia.org/wiki/CRIME
¿Qué
pasa si una página web no utiliza https? Disponible en: https://www.osi.es/es/actualidad/blog/2014/02/28/que-pasa-si-una-pagina-web-no-utiliza-https.html
No hay comentarios:
Publicar un comentario