Criptografía: la rama con más historia de la ciberseguridad y con un futuro prometedor

La Criptografía es una materia apasionante. Me gusta recordar que esta ciencia ha escondido los mayores secretos de la Humanidad desde tiempos inmemoriales. Esta ciencia nos ha acompañado a lo largo de la humanidad y ha ido evolucionando con la misma, creando cada vez criptosistemas más sofisticados de modo que pudiera dar respuesta a las demandas de cada época. Pasando por los criptosistemas clásicos, como el famoso cifrado César o Vigenère, se dio paso a la Criptografía moderna, donde contamos con algoritmos tan importantes como el intercambio de claves Diffie-Hellman, el cual marcó un antes y un después en la Criptografía.

Figura 1: Criptografía: la rama con más historia de

la ciberseguridad y con un futuro prometedor

Este algoritmo resuelve el problema de cómo establecer una clave común entre los interlocutores de la comunicación sin la necesidad de utilizar un canal seguro o un contacto previo entre los mismos, el cual hasta 1976 había acompañado a la humanidad. La genialidad de este algoritmo le valió el premio A.M. Turing de 2015 de la Association for Computer Machinery y además dio lugar a la Criptografía asimétrica, en la que, a diferencia de la simétrica utilizada hasta entonces, se utiliza una clave diferente para cifrar y descifrar. 

De hecho, cada interlocutor utiliza un par de claves, una pública y otra privada. Aquí se puede hablar de algoritmos tan relevantes como RSA, la gran aportación de la firma digital y los certificados o las grandes ventajas de la Criptografía basada en curvas elípticas. Además, hay evoluciones de la Criptografía que estamos viendo, como la Criptografía ligera, la Criptografía homomórfica, etc.

La Criptografía, guardiana de la seguridad de nuestros datos y comunicaciones

La Criptografía utiliza el aparataje matemático como base para garantizar el funcionamiento de la misma, dándole aplicaciones que traen grandes aportaciones a la sociedad. De hecho, ha sabido hacer transparente esa complejidad y robustez matemática al usuario, quien la utiliza hoy en día casi sin ser consciente de ello.

¿Sabías que cuando sacas dinero de un cajero automático estás utilizando Criptografía, o cuando hablas por teléfono o cuando ves tu partido de fútbol favorito o cuando navegas por gran parte de las páginas de Internet o cuando envías un mensaje de Whatsapp/Telegram? Tantas acciones cotidianas que hacemos todos los días bajo las que subyace la Criptografía, haciendo de guardiana de la seguridad de nuestros datos y comunicaciones.

Figura 2: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

La Criptografía tiene características únicas respecto a cualquier otra rama de la Ciberseguridad. Además de ser la rama con más historia de la Ciberseguridad, también tiene un futuro prometedor. Hablamos de la Criptografía Cuántica, que permite hacer un intercambio de clave por un canal inseguro (típicamente a través de fibra óptica o aire) utilizando las propiedades de la cuántica, de forma que se puede detectar si hay un espía en el canal. Incluso ya se está trabajando en la Criptografía post-cuántica, es decir, aquella que se muestra resistente a la aparición del ordenador cuántico.

Breve repaso de la evolución de la Esteganografía

Tanto se podría decir de cada uno de los conceptos enunciados, sin embargo, en esta ocasión me gustaría hablar de la Esteganografía: una ciencia complementaria a la Criptografía cuyo objetivo es ocultar el hecho mismo de la transmisión de información. Sabiendo esto se entiende la etimología de la palabra Esteganografía, que proviene del griego “Steganos” (oculto) y “Graphos” (escritura).

Al no conocer el atacante que existe la comunicación, se reducen las probabilidades de ataque, lo que supone una medida extra de seguridad, la cual puede ser muy útil cuando se trata con información sensible o, por ejemplo, en situaciones de censura. Al igual que sucede con la Criptografía, los orígenes de la Esteganografía se remontan tiempo atrás. De hecho, se ha usado desde la antigüedad, en diferentes civilizaciones como la Griega y la China.

Haciendo un repaso por los diferentes sistemas esteganográficos a lo largo de la historia se encuentran curiosos e ingeniosos sistemas para ocultar la información. Se sitúa en el S. V a.C. el mecanismo mencionado por Heródoto, el cual escribía un mensaje en una tablilla y luego se recubría con cera para ocultar el mensaje. También es muy sonado el método de escribir un mensaje en la cabeza del mensajero. ¡Fijaos el tiempo que requería enviar un mensaje oculto de esta manera! Primero había que afeitar la cabeza del mensaje, escribir el mensaje, dejar el pelo crecer, enviar el mensaje y volver a afeitar la cabeza para leer el mensaje. ¡Nada que ver con la velocidad a la que transmitimos hoy los mensajes y la cantidad de información que manejamos!

Otra técnica utilizada durante las guerras mundiales era la utilización de tintas invisibles, como puede ser la de limón. O la ingeniosa idea de escribir el mensaje en un huevo cocido, cuya cáscara porosa absorbe la tinta y luego pelando el huevo se puede leer el mensaje.

Figura 3: Ejemplo de Rejilla de Cardano en Wikipedia

Incluso es frecuente la utilización de textos como soporte para ocultar los mensajes, no solo en textos sino por ejemplo en partituras de música. Otro mecanismo conocido es la Rejilla de Cardano, donde utilizando una rejilla con un patrón se puede leer un mensaje oculto en un texto. Para l@s que tengan curiosidad por esta técnica pueden revisar este post sobre el accidente del Yack-42 en Turquía.

Técnicas actuales donde se utilizan medios informáticos para ocultar la información

Para ocultar los mensajes, la Esteganografía se apoya en un estegomedio, es decir, el recurso utilizado para ocultar la información. Hoy en día es frecuente la utilización de diferentes formatos de archivos, como imágenes, videos, audios, textos, lenguajes de programación, protocolos, ficheros, redes sociales, etc. como “tapadera” o estegomedio. Esto tiene multitud de aplicaciones a día de hoy, desde la protección de los derechos de autor (con las famosas marcas de agua), hasta la vulneración de mecanismos de seguridad como firewalls o antivirus, exfiltración de datos o la creación de estegomalware. Como siempre, las herramientas están disponibles para sus buenos usos u otros menos buenos… La Criptografía y la Esteganografía no son ciencias excluyentes sino complementarias. De hecho, no es extraño hacer una combinación de Criptografía y Esteganografía, cifrando los mensajes ocultos por si fueran descubiertos.

Figura 4: Libro de Esteganografía y Estegoanálisis
de Jordi Serra y Daniel Lerch en 0xWord

En cuanto a los mecanismos de ocultación, hay muchos que se pueden utilizar. Uno muy utilizado en imagen digital es la técnica LSB (Least Significant Bit en inglés), que como su nombre indica consiste en la sustitución de los bits menos significativos de una imagen por el mensaje a ocultar. Si la cantidad de información a ocultar no es demasiado grande, este mensaje pasará inadvertido a los ojos de los visualizadores de la imagen.

El estegoanálisis es el encargado de descubrir estos mensajes ocultos, para lo cual se suele buscar información redundante, que al modificarla no afecte al estegomedio y que permita descubrir esos canales de comunicación encubiertos.

Herramientas para trabajar con Esteganografía

Hay varias disponibles, como OpenStego, Steghide, Xiao Steganography, S-tools, etcérera. Cada una tiene sus particularidades, algoritmos de cifrado, medios que soporta, etc. Para ilustrar un ejemplo de cómo se puede aplicar la Esteganografía en imágenes digitales, os voy a hablar de S-tools, una herramienta muy sencilla que permite ocultar y descubrir mensajes ocultos en imágenes. 

Su utilización es muy sencilla e intuitiva. Para visualizar la imagen que servirá como estegomedio simplemente podemos arrastrar la imagen (en formato BMP). En este caso se ha usado la imagen “Figuras.bmp”.

Figura 5: Figuras.bmp antes de introducir el mensaje secreto

El fichero que se va a ocultar es “MensajeSecreto.docx” que contiene el texto “Ataque al amanecer”. Para ocultar este archivo con el mensaje en la imagen simplemente basta con arrastrar el archivo a ocultar encima de la imagen que se usará como tapadera. Entonces la herramienta nos pedirá que introduzcamos una clave y el algoritmo de cifrado que se quiera usar. Como algoritmos se pueden emplear varios: IDEA, DES, TripleDES y MDC. En este caso se elige IDEA con la clave 9512.    

Figura 6: Selección de opciones de ocultación del mensaje secreto

A continuación, pulsamos sobre la imagen, que ya tiene el fichero oculto incrustado y seleccionamos la opción de guardar, dándole el nombre de “Hidden.bmp” a la imagen resultante. Cuando el destinatario recibe la imagen esteganográfica, si quiere descubrir el mensaje secreto primeramente debe arrastrar la imagen para abrirla con S-tools. 

A continuación, pulsando el botón derecho y usando la opción Reveal, podemos introducir de nuevo el algoritmo de cifrado y la clave (previamente debe haber un intercambio de clave entre los interlocutores) y…¡tachán!…esto esto es lo que obtenemos:

Figura 7: Hay un fichero oculto en la imagen

Usando la opción de guardar podemos traernos a local este fichero, abrirlo y descubrir el mensaje secreto:

Figura 8: Fichero extraído con S-tools de la imagen

Como se puede ver, esta herramienta permite ilustrar fácilmente los conceptos de la esteganografía. Por supuesto, todo es cuestión de imaginación para hacer cosas interesantes 😊 

Figura 9: Criptografía y ciberseguridad de forma sencilla y divertida por Carmen Torrano

Si te interesan estos temas te invito a ver esta ponencia sobre ciberseguridad y criptografía (que acaba de publicarse en abierto) en el CTO Summit, el evento en el que participé junto a más de 20 profesionales del sector de la tecnología el pasado 2020.

Figura 10: Temario del BootCamp de Ciberseguridad

Además, si quieres especializarte en esta área y dar un salto profesional en tu carrera, te invito a que eches un vistazo al programa del Bootcamp Online Ciberseguridad (empieza el 24 de septiembre) del que formo parte también y junto a un equipo de docentes con muchísima experiencia en el sector. Si has llegado leyendo hasta aquí te doy las gracias y espero que lo hayas disfrutado.

¡Hasta pronto!

Autora: Carmen Torrano, experta en Ciberseguridad en Telefónica y docente en cursos de Ciberseguridad.

Contactar con Carmen Torrano

El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)

Como hemos visto en la parte anterior de este artículo, ya habíamos solucionado los problemas de usabilidad e interconexión entre los diferentes ecosistemas de usuarios, para que todos ellos pudieran enviar y recibir correos utilizando todo tipo de clientes de escritorio, web, móviles, etcétera a usuarios que se encontraran en cualquier otro destino. Se había conseguido una infraestructura global e interconectada, algo que desde luego no han fomentado las redes sociales en versiones posteriores y de lo que hablaremos un poco más adelante.

Figura 4: El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)a

Con la construcción de esta infraestructura global interoperable y compatible para la comunicación, aparecieron los primeros problemas de seguridad, que tenían que ver más con las comunicaciones sobre Internet, un medio que se definió de forma insegura sin un modelo de amenazas claro desde el principio, lo que nos llevó a aplicar las primeras soluciones de cifrado y firma digital para garantizar la integridad y confiabilidad de la información que sobre el e-mail se envía.

Para el cifrado y la firma digital de los correos electrónicos aplicamos túneles SSL a los protocolos de red, y para el cifrado y la firma digital de los mensajes se puede utilizar a día de hoy S/MIME (certificados digitales para e-mail) o PGP (Pretty Good Privacy), que permiten firmar y cifrar extremo a extremo - sin contar con que los servidores de correo electrónico aplican una capa de seguridad o no -. Los clientes de correo electrónico, por su parte, avisan a los usuarios del nivel de cifrado y privacidad utilizado en cada uno de los mensajes. Pero no es suficiente ni mucho menos para todas las amenazas que fueron apareciendo.

Más soluciones de seguridad para saber de dónde viene un correo:
Reverse MX Lookup, SPF, SenderID, DKIM & DMARC

Con el escenario de envío masivo de mensajes no solicitados a direcciones de correo electrónico comenzamos a poner un montón de soluciones para ir tapando la sangría de problemas que supone para una persona y una organización – no olvidemos que el 90% de los APTs de seguridad han provenido por un correo electrónico en un ataque de spear phihing enviado a una persona de la empresa - que su buzón de correo electrónico esté abierto y disponible para cualquiera que conozca la dirección.

En esta primera remesa de soluciones vamos a intentar centrarnos en el problema de la suplantación del remitente o e-mail Spoofing, que da lugar a los ataques de Phishing y Spear Phishing. Por supuesto, la firma digital S/MIME y PGP son lo ideal, pero como hemos dicho repetidas veces, no es muy popular en el mundo global.

Reverse MX Lookup

Para evitar que suplantaran las direcciones de correo electrónico de nuestra organización, es decir, que nadie pudiera enviar mensajes de correo en nuestro nombre como se hace en los ataques de phishing, comenzamos a indicar cuáles eran los servidores de correo electrónico que pueden enviar mensajes con un remitente de nuestro dominio. La primera solución fue sencilla, pero inútil. Como al principio el servidor de correo entrante - donde están los buzones y se implementan POP3 - era el mismo que por el que salían los correos electrónicos - donde se implementa SMTP - algunos servidores de correo comenzaron a aplicar el filtro de Reverse MX Lookup.

Para saber dónde está el servidor de correo entrante de una organización, en el servidor DNS de esa organización se crea un registro especial llamado MX (Mail eXchanger) que apunta a la dirección IP o hostname del servicio que recibe el correo electrónico de ese dominio. Lo que hacían algunos servicios de correo electrónico entrante es rechazar cualquier correo electrónico que viniera de @otrodominio.com si el servidor que entregaba ese mensaje no tenía la dirección que tenía alguno de los registros MX del dominio otrodominio.com.

Como os podéis imaginar, cuando los servidores de correo saliente se separaron físicamente de los servidores de correo electrónico entrante, este filtro dejó de ser útil, ya que nunca coincidían las direcciones IP de los servidores que entregaban los mensajes con los registros MX. Por eso, hubo que crear otro registro. El registro SPF, donde se da la lista de cuáles son los servidores autorizados desde nuestra organización para entregar correos electrónicos que tengan como remitente uno de nuestros usuarios.

SPF (Sender Policy Framerwork)

Creando los famosos registros SPF (Sender Policy Framework) - también conocido como SPFv1 - se identifican los servidores de correo saliente que usa esa organización y qué debería hacer el servidor de correo entrante de un tercero si recibe un mensaje de este dominio que no viene de esos servidores identificados en SPF. A priori, suena como una medida útil, pero tiene muchos "peros" a la hora de su implementación y uso.

Figura 5: Registro SPF de Gmail.com.

Por desgracia, como las empresas tienen cedidos "alias" de correo de sus dominios a campañas de de marketing que se envían desde servidores externos a la organización o que no son controlados por ellos, la política de seguridad suele ser “Softfail” que se identifica con un "~". Para que os hagáis una idea, cuando usamos SPF lo que hacemos es irnos al DNS de nuestra empresa y decir algo como:

"Estos son los servidores que pueden enviar correo de @miempresa.com o @mibanco.com. Si te llega un correo de alguien que dice que es de @mibanco.com debes aplicar esta política."

La política más férrea debería ser “Hardfail” (-), o lo que es lo mismo, “tíralo y no lo entregues al destinatario, que es falso”, pero por desgracia sucede lo que he comentado antes, y las políticas son “Softfail” o lo que es lo mismo:

 “Míralo bien y ponlo un poco en alerta, pero no estoy seguro de que no sea mío”.

La cosa se complica a la hora de detectar si un registro realmente viene de una organización o no, yo que hay muchas variantes. Muchas personas tienen delegada la gestión de su buzón de correos a terceros, por lo que hay casuísticas en las que una persona manda un mensaje en nombre de otra.

SenderID o SPFv2 (antes conocido como CallerID)

Así, en un e-mail tenemos los campos from, pero también sender y también resent-from y resent-sender. y es ahí donde apareció el estándar SenderID, empujado por Microsoft, y conocido como SPFv2. Su idea es garantizar que el remitente de un correo viene realmente de la organización que tiene el servidor de correo electrónico que lo entrega.

Así que, determinar si un correo electrónico viene o no de una organización realmente es complejo. SenderID intentó centrarse en identificar esa casuística del emisor, pero no consiguió ser un estándar de facto, y su aplicación fue residual en el mundo de Internet, así que encontrar registros SPFv2 con políticas Hardfail fue como localizar un unicornio o un mirlo blanco.

De hecho, al final, se utilizan otras cabeceras como Return-Path y X-Return-Path (las cabeceras X- no son parte del estándar oficial y son introducidas por servidores de correo electrónico para dejar información extra que consideran útil hasta que son estandarizadas... o no.)

DKIM (Domain Keys Identified Mail)

Intentar determinar que un mensaje no es legítimo cuando la situación es tan completo hizo que SPF no fuera el único estándar que salió para evitar la suplantación de los remitentes en los mensajes de correo. Y así nació DKIM, con una aproximación distinta, tratando de decir algo como:

"No sé si este correo electrónico que viene de un servidor que no conozco y un resent-from o resent-sender extraño es un correo electrónico legítimo de esta organización o no, pero este otro que viene firmado por uno de mis servidores de correo saliente sí que es mío y puedes estar más que seguro de que su contenido es legítimo."

Como veis, la idea de DKIM (Domain Key Indentified Mail) es que cada correo electrónico que ha salido de un servidor autorizado de la organización, va firmado por una clave privada que tiene configurado el servidor de correo saliente y cuyo par de clave pública está accesible para todo el mundo en el servidor DNS de la organización y se puede consultar.

Figura 6: Clave DKIM usada por un servidor de yahoo.com

Es decir, recibo un correo de paco@yahoo.com y en el texto del mensaje aparece una cabecera DKIM con un HASH, que se supone que ha generado el servidor de correo saliente de Yahoo.com que ha entregado el correo. Así que se mira qué servidor ha entregado el correo, nos vamos al servidor DNS de Yahoo.com, pedimos la clave pública DKIM de ese servidor y comprobamos que el hash que nos han entregado es correcto.

Figura 7: Correo de Ebay firmado correctamente por DKIM

Como veis, la aproximación es diferente, mientras que con Reverse MX Lookup, SPF o SenderID se trata de eliminar lo que no venga entregado desde el dominio correcto, con DKIM se trata de indicar que, si el correo ha llegado desde la IP correcta, el usuario lo sepa con un icono especial, tal y como podéis ver en esta captura con correos de Ebay tiempo atrás. Pero como la mayoría no lo usa, pues otro intento fallido para diferenciar los correos legítimos de los no legítimos.

Como veis, el uso de Reverse MX Lookup, SPF, SenderID y DKIM hace que haya mucha información en el cuerpo de un mensaje para analizar un correo electrónico. Esta información no es concluyente ninguna por sí misma, ya que los casos son muchísimos, y es lo que hizo que los clientes de correo electrónico no se atrevieran a marcar definitivamente un mensaje como malo o como bueno.

El Proyecto "Apolo"

Para poder dar más información al usuario, nosotros creamos en Informática 64, un plugin para el navegador que se leía el cuerpo de los mensajes en el cliente web de Gmail y Hotmail, buscaba la información SPF, DKIM, SenderID, las direcciones IP en los registros MX y hacía las comprobaciones desde el propio navegador, y luego mostraba información de ayuda al usuario sobre los mensajes de correo electrónico que estaban en su bandeja de entrada. Fue un proyecto de investigación más que una verdadera herramienta, pero lo llamamos el Proyecto Apolo.

Figura 8: Información del proyecto Apolo

Si el registro SPF era correcto en el mensaje, mostramos un icono verde. Si no cumple DKIM, ni Sender ID, ni SPF, ni MX Reverse Lookup, lo poníamos en alerta roja. Una prueba para dar más información a los usuarios avanzados.

DMARC (Domain-based, Message Authentication, Reporting & Conformance)

Al final, lo que nosotros hicimos en el Proyecto Apolo tenía todo el sentido. Había que hacer algo que mezclara todo, y así, tiempo después, nació DMARC. El funcionamiento de este protocolo es el que se ve en la figura siguiente. En él se puede ver en la fila del medio del gráfico que, cuando llega el mensaje al destinatario, el servidor valida la información DKIM, valida la información SPF y después, con estas dos comprobaciones previas, valida la información DMARC para aplicar una de las políticas que se pueden ver en la fila inferior.

Figura 9: Flujo de funcionamiento de DMARC

Por último, si un mensaje de correo electrónico cumple todas las validaciones correctamente, es decir, viene firmado por DKIM correctamente con una clave de firma que está en el DNS de la organización y pasa la comprobación SPF al ser enviado desde una de las direcciones IP marcadas en el registro SPF como una de las autorizadas, entonces el proveedor podrá tener las máximas garantías de legitimidad del mensaje posibles - que aún así siempre inferiores a que el mensaje venga firmado digitalmente con una clave de remitente -, para lo que vamos a necesitar alguna tecnología extra.

PCL (Phishing Confidence Level)

Al final, ni con DMARC se garantiza que un mensaje no sea malicioso. Existen casos concretos en los que es posible pasar DMARC o no hay información suficiente para tomar una decisión firme. En algunos mensajes habrá información de Return-Path o X-Return-Path útil. En otros habrá información de direcciones IP que podremos consultar en bases de datos de salud que nos dirán si son de hosters que nunca hacen ataques o de otros con "mala reputación". Además, si miramos el cuerpo del mensaje podremos ver si tienen textos utilizados normalmente en ataques de phishing o no, etcétera.

Figura 10: Configuración de umbrales PCL en Microsoft Outlook

Es decir, que si independientemente de los estándares que intentan garantizar que un mensaje viene o no viene de un determinado dominio, podemos aplicar técnicas avanzada de Machine Learning a los mensajes que utilicen toda la información en el mensaje disposnible, y todo el conocimiento histórico que tengamos de nuestro correo electrónico para generar un índice, que llamamos PCL (Phishing Confidence Level) y que generar mi servidor de correo para clasificar el mensaje en función del número que salga.

Así, creamos unos umbrales para decidir qué mensajes entran en la carpeta de entrada, cuáles entran en ella pero con funcionalidad limitada - carga de imágenes, alertas mostradas y deshabilitación de funciones -, cuáles van a la carpeta de Spam y cuáles no se entregan al buzón.

Es un trabajo avanzado e ímprobo, y muchas veces tiene errores, pero es la solución que aglutina todos los intentos anteriores existentes para sacar el máximo de la información disponible. Además, para poder tener la información actualizada y el PCL vaya ajustándose, es necesario contar con la colaboración de los usuarios, que deberán ir reportando aquellos mensajes sospechosos. Pero esto es solo para los ataques de Phishing.

Y aún así no son suficientes y se intentan cosas nuevas.

Aún nos queda el SPAM por donde vienen la mayoría de los problemas de malware, robo de tiempo de las personas para convertir el e-mail en improductivo y molesto para las personas. Y mucho peor, los problemas de identidad asociados a las direcciones de correo electrónico, así que nos queda mucho por hablar todavía de la muerte y resurrección del e-mail.

Como os podéis imaginar, a pesar de todas estas tecnologías, el correo electrónico sigue siendo un caos. Al final un mensaje puede entrar en el buzón de entrada de un destinatario o no dependiendo de la configuración de estas tecnologías en su servidor de correo, lo que permite que un mensaje de Spam o un Phishing puedan entrar o no dependiendo de la configuración que tengas.

Nos quedan muchas cosas, y lo iremos viendo en las partes siguientes de este artículo. Espero que estéis disfrutando la lectura tanto como yo la escritura.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

********************************************************************************************************
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 3 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 4 de 4)
********************************************************************************************************

El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)

El correo electrónico, o e-mail, es un caos maravilloso. Esa es una de las frases que solía utilizar yo cuando hablaba de cómo funcionaba y cómo había evolucionado, durante las charlas que di en el año 2009 con mi querida Informática 64 en la charla "Hay una carta para ti". Un caos maravilloso que usamos a diario, pero que tiene muchas lagunas de funcionamiento y apaños, de los que os voy a comenzar a hablar por aquí.

Figura 1: El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)

En este artículo, que he dividido en cuatro partes, voy a intentar hacer un recorrido didáctico y somero, sobre todas las vicisitudes que ha ido pasando, y las cosas que hemos ido construyendo sobre él y alrededor de él para terminar con alguna idea nueva. Espero que os guste, y sobre todo que os entretenga la lectura.

La necesidad de comunicación

Comunicarse es una necesidad humana. Lo utilizamos para todo. Para planificar la caza de un animal  que diera sustento a toda la banda de Homo Sapiens en tiempos de nuestra etapa de cazadores-recolectores, o para establecer una cita amorosa con una pareja que nos ha estimulado el sistema químico a través de una app de contactos en la que nos hemos dado de alta. Necesitamos comunicarnos para trabajar, para demostrar afecto, cariño, y hasta para estar enfadados con el mundo en Twitter.

El ser humano se comunica, y necesitamos hacerlo por cualquier nuevo medio en el que haya otros como nosotros, nos conozcamos o no. Es por eso que, en cada medio en el que nos hemos ido desenvolviendo a lo largo de nuestras vidas hemos desarrollado sistemas de comunicación en él. Desde mensajes en los árboles, señales de humo, o cartas escritas enviadas por mensajeros a caballo.

En la era moderna, ya con la tecnología de los computadores aquí, también lo hemos hecho. Cuando aparecieron los primeros sistemas de tiempo compartido, en los que muchos usuarios podían utilizar un mismo servidor para ejecutar sus algoritmos, apareció la necesidad de comunicarse entre los usuarios de ese ordenador central. El administrador del servidor debía enviar comunicaciones a los usuarios, tales como normas de comportamiento, periodos de indisponibilidad por mantenimiento, o actualizaciones de información sobre nuevas características en el servicio.

Por supuesto, entre los propios usuarios también aparecieron estas necesidades de comunicación. Estos podrían trabajar en grupos, dentro de proyectos que realizaban conjuntamente, para los que necesitaban compartir ideas, resultados o propuestas. Había que comunicarse a través del medio común, es decir, el servidor que daba vida a ese ecosistema creado alrededor de él.

Del e-mail al Webmail, pasando por SMTP, POP3, IMAP

Los primeros servicios de correo eran muy sencillos. Los requisitos eran bastante sencillos, ya que todos los usuarios estaban en el mismo servidor, así que no intervenían para nada las redes de comunicación en ese momento. Un usuario se conectaba al servidor por medio de un terminal para tener un shell, por lo que todo lo que hacía se producía directamente en el propio servidor. Al final, su terminal no era más que el equivalente a tener una pantalla y un teclado conectado al servidor desde una ubicación remota. Pero para el software del servidor, una vez el usuario iniciaba sesión, era como si el usuario estuviera sentado físicamente al lado de él.

Para crear un sistema de comunicaciones entre usuarios no había que hacer nada especial que incluyera ubicaciones remotas, múltiples servidores, o redes complejas de interconexión con federación de identidad. La autenticación y el enrutamiento de las comunicaciones se simplificaba al estar todos los usuarios en el mismo servidor. Para resolver el problema de comunicación bastaba con crear un pequeño programa que corriera en el servidor y al que decías a qué usuario querías enviarle el mensaje, por ejemplo a a p0344, cuál era el asunto por el que abrías esa comunicación, y cuál el cuerpo del mensaje.

En ese momento se generaba un fichero y el servicio de e-mail que corría en el servidor creaba un fichero con esta información en la carpeta de ese usuario p0344 - dentro del árbol de ficheros de ese usuario - destinada a recibir el correo. Es decir, el buzón de cada usuario era una carpeta con permisos de escritura para el servicio de “e-mail” donde se le depositaban ficheros de texto con los datos de qué usuario le escribía, cuándo lo hizo, cuál era el asunto y el cuerpo del mensaje. Metadatos que enriquecieran la comunicación electrónica.

Para enviar mensajes el proceso requería hacer algo similar. Había una carpeta de mensajes de salida que el programa, por medio de un “daemon” en el servidor leía periódicamente para ver si había algo nuevo. Cuando aparecía un nuevo mensaje, el servicio de “e-mail” lo borraba de esa carpeta, lo ponía en la carpeta de mensajes enviados para que quedara un copia, y el mensaje era copiado también a la carpeta de entrada del usuario destinatario en su estructura de ficheros particular. Sencillo y funcional.

La cosa se complicó cuando aparecieron más computadores. Ya no teníamos solo un mundo sino un ecosistema de servidores en red y teníamos la necesidad de comunicar usuarios de un servidor, por ejemplo llamado “Albeniz” con otro, por ejemplo llamado “Zipi”. En ese caso había que hacer un protocolo para que el servicio de e-mail de del servidor Albeniz, fuera el que fuera, supiera dónde tenía que enviar el mensaje cuando el usuario no existiera en su mundo y fuera de otro ecosistema, como por ejemplo del servidor "Zipi".

Para poder identificar a qué ecosistema pertenecía cada destinatario de las comunicaciones, inventamos las direcciones con la @servidor y creamos un protocolo que comunicaba el enrutamiento de mensajes entre servidores. El famoso y popular SMTP (Simple Mail Transfer Protocol) que habilitaba cada servicio de e-mail utilizando un puerto, ahora sí, en la red, en este caso el puerto 25. Así, un usuario “chema@albeniz.eui.upm.edu” podía enviar un mensaje a “chema@zipi.fi.upm.edu”. Los servicios de correo electrónico se enviaban los mensajes uno a otro a través de mensajes de red encapsulados en SMTP.

Pero un día los usuarios dejaron de utilizar plataformas de tiempo compartido como si estuvieran sentados en ellas, es decir, dejaron de conectarse a través de sesiones de terminal, y empezaron a usar sus propias estaciones de trabajo. Eso quería decir que el usuario chema@albeniz.eui.upm.es tenía en su despacho otro mundo, en el que había otro usuario, otro sistema operativo, y otras funcionalidades. Había una estación de trabajo y no un terminal, donde se ejecutaba un mundo tipo Solaris, o un MSDos, o un DRDOS, un OS2/Warp o lo que fuera.

Es decir, era otro sistema informático distinto, por lo que si quería enviar correo electrónico utilizando su identidad de chema@albeniz.eui.upm.edu debía actuar como un servidor remoto más y utilizar el protocolo SMTP para conectarse con el servicio de enrutamiento de correos electrónicos en su servidor, pero eso no valía para poder leer sus mensajes recibidos. Había que crear un nuevo protocolo para que pudiera conectarse a ver los mensajes que le habían entrado en su buzón. Y así nació POP3 (Post-Office Protocol v.3), corriendo en la red por el puerto 110.

Al final un puerto no es más que una zona de memoria que comunica a un programa que corre en un servidor con los mensajes que llegan por la red. Cuando arrancamos un programa que enruta mensajes con SMTP en un servidor, lo que hace este programa es hablar con servicio que recibe el tráfico de red en host y decirle:

"Oye, estoy corriendo en el servidor y esperando mensajes. Si te llega algún paquete que venga con el número 25 como destinatario me lo pones en esta zona de memoria". 

Esto mismo hace el protocolo POP3, pero diciendo algo como:

"Oye, estoy corriendo en el servidor y esperando mensajes. Si te llega algún paquete que venga con el número 100 como destinatario me lo pones en esta zona de memoria". 

Cuando los mensajes le llegan al servicio que gestiona las comunicaciones de red en el servidor, este va colocando los mensajes en diferentes direcciones de memoria para enviárselo a los servicios adecuados en función del número de puerto que venga en el destinatario. Es decir, es como el portero de un edificio en el que viven muchos vecinos y reparte los paquetes de Amazon en los distintos casilleros de los vecinos en función del puerto, que en ese caso serán 2º A, 3º C o Bajo C. Como podéis ver por los números de los puertos de los protocolos, la necesidad de conectar servidores nació tiempo antes de la necesidad de descargar el correo del buzón a la estación de trabajo.

Y funcionó. Y se masificaron los usuarios de estos servicios. Cada vez más personas utilizaban el e-mail para todo. Ya no solo trabajo, sino también para socializar entre ellos, lo que hizo que se vieran las limitaciones de estos protocolos creados hasta el momento. SMTP y POP3 tenían que ser extendidos y su arquitectura y concepto inicial ya no eran los requisitos de hoy en día. Estos protocolos eran una evolución de la idea inicial de transferir mensajes en texto plano entre carpetas, y por eso no tenían gran funcionalidad.

Pero con la masificación de su uso se requería enviar comandos para hacer cosas en el buzón remotamente sin necesidad de descargar y enviar ficheros de texto. Si necesito crear una carpeta para organizar el correo y mover un mensaje de una carpeta a otra, descargarse mensajes de textos y volver a subirlos no tenía sentido. Por ello se creó una evolución completa para gestionar los buzones de correos, y entre las muchas propuestas, comenzó a emerger el protocolo IMAP (Internet Message Access Protocol), con una cantidad de evoluciones.

Por supuesto, desde la primera concepción del servicio e-mail en los servidores de tiempo compartido, los clientes de correo electrónico fueron evolucionando. Desde un interfaz basado en comandos, a un interfaz modo texto corriendo en sesiones de terminales, para llegar a los clientes de hoy en día. Con la creación de SMTP y POP3 aparecieron las herramientas de gestión de e-mail en estaciones de trabajo como (Microsoft Outlook – que no es de las primeras ni mucho menos) para tener clientes de correo electrónico con interfaces gráficos, y con la llegada de HTTP y las páginas web aparecieron los primeros servicios como Hotmail o Gmail. Estos, pasaron rápidamente a utilizar IMAP y hoy en día es posible gestionar tu buzón de Gmail con comandos IMAP, como hice yo hace ya muchos artículos.

Los problemas de seguridad

Como os podéis imaginar, con el aumento de la popularidad del correo electrónico, la evolución de la potencia de cómputo de los equipos en clientes y en servidores en Internet, además de la masificación del número de usuarios conectados y la velocidad de las redes de comunicación, los problemas de seguridad con el correo electrónico fueron infinitos.

SMTP y POP3 nacieron como protocolos para mover ficheros de texto plano que estaban en carpetas de un servidor. El esquema de amenazas que había cuando todos los usuarios estaban dentro del mismo servidor era mucho más pequeño que cuando tenemos dos o más servidores. Ya hay un medio por el que los mensajes deben pasar. Y deberían estar cifrados. Así que primero intentamos cifrar las conexiones entre los servidores usando un protocolo como SSL (Secure Socket Layer) para crear un túnel de cifrado servidor a servidor que impidiera que alguien pudiera interpretar el tráfico si interceptaba la señal en el medio. Así, creamos SMTP-S y POP3-S por puertos de rede distintos que la gente ya no se conoce tan de memoria.

Pero también sucedía que el esquema de identificación de remitente y de identificación del host cuando todos los servidores eran confiables y no era fácil conectarse a la red, tampoco valía. Se empezaron a suceder los ataques de suplantación de direcciones IP en los que una estación de trabajo se hacía pasar por un servidor de correo electrónico, usando técnicas de Spoofing o atacando al servidor DNS para cambiar los servidores autorizados para recibir los mensajes de correo de una organización. El esquema de cifrado era inútil frente a ellos, ya que se estaban cifrando las comunicaciones contra el propio atacante, que estaba haciendo un “man-in-the-middle”, así que pasamos a utilizar sistemas como Mutual-TLS donde tenemos no solo que cifrar las comunicaciones, sino también firmarlas por los servidores que están allí.

Figura 2: Libro de Cifrado de las Comunicaciones Digitales:
"De la cifra clásica a RSA (2ª Edición)"

Pero este proceso de enrutamiento de comunicaciones por la red solo por tramos cifrados no es obligatorio para que el e-mail funcione, y una vez que el usuario ha recibido un mensaje de correo electrónico no sabe realmente si el mensaje va a acabar cifrado en el buzón del destinatario o no, y si la comunicación por la que ha venido era un canal cifrado o no. Y por supuesto, ya que se puede suplantar a un servidor de correo electrónico con una estación de trabajo, se puede suplantar a cualquier dirección de remitente que estuviera en ese servidor. Es decir, podrían aparecer mensajes como chema@albeniz.eui.upm.edu que no hubieran sido enviados ni desde albeniz.eui.ump.edu, ni desde luego por chema.

Para ello, sería necesario que el cifrado y la firma de los correos electrónicos fuera extremo a extremos y robusta. Necesitamos no solo garantizar la comunicación de los servidores, sin la comunicación entre remitente y destinatario, para lo que utilizamos sistemas de firma digital como PGP o los certificados digitales de e-mail S/MIME.

Por desgracia, estos sistemas de certificados digitales son bastante poco usados, ya que tienes que  generar certificados en entidades confiables, configurarlos en los diferentes clientes de e-mail que uses (computadoras, ordenadores portátiles, tabletas, diferentes navegadores de Internet) , hay que renovarlos, hay que intercambiarlos antes de establecer una comunicación segura, etc... Demasiadas barreras de usabilidad para la gran mayoría de las personas que utilizan mensajería e-mail por Internet,  por lo que la mayoría de la comunicación por medio de correos electrónicos ni se cifra ni se firma.

Google intentó avisar a los usuarios cuando los correos venían cifrados en tránsito o no, con un candadito rojo como respuesta a las filtraciones de Edward Snowden en las que descubrió que la NSA estaba capturando el tráfico sin cifrar. Y, además, todos los clientes de correo electrónico marcan con un icono especial si el mensaje viene cifrado y/o firmado desde el emisor.

Figura 3: El intento del candado rojo de Gmail. Mucho candado rojo, mejor quitarlo.

Al final, como la realidad es que casi ningún mensaje llega firmado y cifrado extremo a extremo, los usuarios ven normal que un banco o su jefe les envíen un mensaje sin cifrar o firmar. Con lo que se abre el campo para los ataques de suplantación del remitente y de Phishing o los más peligrosos Spear-Phishing que se utilizan en los ataques dirigidos a personas concretas.

A todo esto hay que sumar problemas inherentes al sistema de correo electrónico más, y es que, al ser un sistema de comunicación de coste cero, se ha aprovechado para hacer captura masiva de clientes por medio de mensajes publicitarios, para hacer campañas de estafas masivas engañando a víctimas (Scam), para dar de alta sin autorización en listas de correos, o para simplemente molestar.

Necesitamos más seguridad pero... ¿Será suficiente?

Tras la creación del servicio de e-mail, vimos que la necesidad de usabilidad nos llevó a crear SMTP, POP3 e IMAP, y que las primeras amenazas nos llevaron a aplicar capas de seguridad como SSL, y mecanismos de firma digital y cifrado extremo a extremo sobre sobre el servicio de e-mail, como PGP o S/MIME, pero aún estamos lejos de que poder proteger al servicio de correo electrónico de todos los problemas que se fueron creando, así que hay que hacer más.

En la siguiente parte de este artículo veremos cómo se empezaron a intentar soluciones como Sender Policy Framework, Sender ID, DKIM, o los Filtros Anti-Spam basados en todo tipo de algoritmos, desde listas blancas y listas negras, hasta Inteligencia Artificial pasando por los Filtros Bayesianos o la colaboración de usuarios para detectar Scams, Spam, Spear Phishing, y otros ataques a las personas. Pero aún así... no será bastante, así que habrá que ver qué alternativas han aplicado personas y empresas para lidiar con el e-mail.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

********************************************************************************************************
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 1 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 2 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 3 de 4)
- El e-mail ha muerto. ¡Larga vida al e-mail! (Parte 4 de 4)
********************************************************************************************************

"Cuñado, he visto una oferta genial en la web. ¿Compro o es peligroso?"

Hoy os vengo a contar una historia de esas que seguro que os ha pasado alguna vez. Es el momento en el que te preguntas si debes seguir comprando en *esta* página web o no. ¿Es de fiar pagar por un producto que vendrá en el futuro en *esta* web? De eso va el post de hoy, de cómo yo decidí no hacerlo por precaución, sin llegar a saber si el sitio era una estafa o no. Eso os lo dejo a los lectores.

Figura 1: "Cuñado, he visto una oferta genial en la web. ¿Compro o es peligroso?"

La historia comenzó cuando el otro día, un familiar me pidió sugerencia para realizar una compra en una página web. Como os he contado, dudaba de si era segura o no para meter los datos de la tarjeta de crédito y pagar. Su preocupación era que la web fuera insegura y cualquiera haciendo usando alguna de las técnicas de Hacking Web Technologies pudiera llevarse sus datos. O mucho peor, si la web era maliciosa. Para ello, me envió la URL y me encontré varias sorpresas en un primer vistazo que comparto con vosotros.

• La página web no estaba cifrada con SSL. 

• Los precios son en casi todos los productos un 60% más baratos que el propio fabricante. 

• No hay información de ninguna razón social o empresa. 

• El aviso de privacidad esta en ingles mientras que la pagina esta en castellano.

Hasta ese momento eran errores que pueden llegar a estar en webs mal diseñadas - algo que no es extraño. Haciendo un poco de Hacking con Buscadores e indagando en Google encontré más paginas similares en los primeros resultados de la consulta que están utilizando las mismas plantillas, simplemente cambian algo.

Figura 2: Código fuente de una web de venta con descuentos del 81%

A priori, guardando la presunción de inocencia de estos sitios y pensando que son simples errores,  se están utilizando malas prácticas y no se debería comprar en ellas si te preocupa que tengan una brecha de seguridad, o que aparezca un simple SQL Injection que se lleve todos los datos. Este es el listado de algunas de ellas:

• www.sanminer.es
• www.towinbackyourex.com
• www.marjalles.com
• www.treeffestrutture.com
• www.toddandsarahrainey.com
• www.chaletelbosque.es
• www.viajeschavez.es
• www.spiritrhythmband.com
• www.wordsandpublicity.com
• www.compromisoprimarias.es
• www.sosdangereolien.com
• www.abparquitectura.es
• www.city-scout24.es
• www.tallerbicis.es
• www.equipoiseconsulting.com
• www.nosunemontilla.es
• www.equipoiseconsulting.com
• www.mapersonalchef.com

Observando simplemente la descripción del código fuente de unas páginas, no inspira mucha confianza lo que veo. Hay descuentos del 81%, - como de puede ver en la Figura 2 - algo que creo que pocas veces, salvo en liquidaciones de cierre,  suele ser común. Además, en el formulario de compra, aparecen los campos de tarjeta de crédito y el formulario se muestra en una web sin cifrar.

Figura 4: Datos del formulario enviados sin cifrar

Observando más en detalle el código fuente del formulario, observamos también que en el método ACTION, la información se envía por HTTP, esto significa que la información de tus tarjetas de crédito van sin cifrar y cualquier persona podría obtener los datos de dicha tarjeta de una forma sencilla. También la información del formulario esta en inglés y la página web supuestamente esta en castellano y vende productos a España como indica la descripción del sitio.

Figura 5: Envío de los datos sin cifrar

Buscando en las páginas el aviso de privacidad, no encontramos información de la empresa que gestiona nuestros datos, y lo que es peor, nos dice que la información va cifrada por SSL y es completamente falso. Y los enlaces a redes sociales, apuntan al índex de la página, así que son falsos.

Figura 6: Aviso de política de privacidad

Consultando el Whois de algunos dominios, encuentro algunas similitudes entre unos y otros. Los correos electrónicos, por ejemplo. Es probable que los nombres del registrante sean falsos, o hechos de forma automática.

Figura 7: Información de dominios similares

Manteniendo la presunción de inocencia de estas páginas, recomendaría a mi "cuñado" después de lo que se ha explicado antes, no comprar nada en estas web. Mis recomendaciones básicas son siempre comprobar que el certificado SSL es válido, leer la política de privacidad y lo que es más importante, ¡¡los precios!!, nadie va a vender un producto más barato que lo que cuesta al vendedor. Os recomiendo el artículo de Chema Alonso de "Carding Básico: ¡Ojo dónde pones tu tarjeta de crédito!". Aún así, puede que la web cumpla todas estas cosas y al final... sea un fraude o sufra una brecha de seguridad, pero si la web de e-commerce es como estas, mejor no arriesgarse.

Autor: David Hurtado

Meterpreter Paranoid Mode: Conexión segura en tu payload #metasploit

Recientemente he estado probando este script de bash llamado Meterpreter Paranoid Mode. La idea del autor de este script, seguramente, venga de este artículo de Rapid 7 sobre cómo de paranoicos podemos volvernos a la hora de configurar un Meterpreter. Sin duda, es un tema interesante, ya que los payloads que manejamos manejan, al final, información importante. Evitar que nos detecten por la evaluación de la comunicación mediante el cifrado de ésta, es algo que, en algunos entornos, puede ser fundamental. Eso sí, a nosotros nos ha llamado la atención el nombre por nuestro querido WordPress in Paranoid Mode.

Figura 1: Meterpreter Paranoid Mode

Meterpreter Paranoid Mode permite a los usuarios fortificar los staged/stageless de las conexiones de Meterpreter, teniendo que chequear para ello un certificado. La idea es sencilla: el script crea un certificado en formato PEM, el cual será utilizado para validar la conexión. Para tener la conexión validada, el handler al que se conecta el payload, debe disponer de acceso al certificado PEM. Además, se tendrá que tener habilitado el chequeo de este certificado, con la opción stagerverifysslcert a TRUE, dentro de los parámetros de Meterpreter avanzados. Esto lo veremos más adelante.

Figura 2: Meterpreter in Paranoid Mode

Una vez que el payload es creado por el script, mediante la herramienta msfvenom a bajo nivel, se debe configurar el handler para crear la conexión utilizando el certificado PEM. Se utilizará un hash SHA1 para la validación. Este es el resumen de la idea, de todo lo que automatiza el script Meterpreter in Paranoid Mode.

Figura 3: Meterpreter Paranoid Mode

Al ejecutar el script, éste solicita la creación de un certificado o importación de éste. Para hacerlo sencillo, se puede 'impersonar' un dominio. Para este ejemplo, se ha utilizado el dominio de Google. El script proporciona algunos pop-ups a la hora de poder seleccionar opciones, lo hace mucho más sencillo de utilizar por parte del usuario.

Figura 4: Creación de un certificado para un dominio suplantado

Una vez que rellenamos la opción del dominio y se lleva a cabo la 'suplantación' del dominio, se genera un nuevo certificado en formato PEM, el cual es almacenado en el directorio output. Más tarde, veremos detalles de dicho certificado almacenado. Lo que hay que entender es que es ese certificado el que será utilizado por el handler para validar la conexión segura con nuestro Meterpreter.

Ahora, nos toca elegir si vamos a utilizar un staged o un stageless. La herramienta nos dará dos opciones, la primera nos generará un .bat, mientras que la segunda nos generará un .exe. En este artículo se ve la perspectiva y diferencias entre un staged y un stageless. Es una lectura totalmente recomendada.

Figura 5: Staged payload

Una vez seleccionado el tipo de stage, se debe indicar el tipo de payload que se quiere utilizar. Para este ejemplo, hemos utilizado un staged, por lo que podemos utilizar los siguientes payloads:

" Windows/meterpreter/reverse_winhttps
" Windows/meterpreter/reverse_https
" Windows/x64/meterpreter/reverse_https

Para este ejemplo, hemos utilizado la opción windows/meterpreter/reverse_https. Ahora tenemos, en la carpeta output, generado un fichero .bat con el código adecuado para lograr la conexión cifrada con el handler. Más abajo veremos parte del código para que entendamos qué utiliza.

Figura 6: Elección del payload

Antes de continuar, vamos a mostrar el certificado generado con la herramienta y la opción 'impersonar'

Figura 7: Fichero PEM del certificado del dominio suplantado

El código que está en el interior del fichero .bat es el que se puede ver en la imagen. Como se puede ver, la automatización utiliza Powershell para ejecutar el Meterpreter con las opciones de la validación del certificado activadas.

Figura 8: Script en powershell a ejecutar

Como se puede ver en la siguiente imagen, desde el handler que Meterpreter Paranoid Mode ha configurado se obtiene la sesión.

Figura 9: Sesión establecida

Además, se pueden ver las opciones que se han configurado, lo cual es importante por si se quiere hacer el procedimiento a mano, en vez de utilizar la herramienta. Las opciones importantes son:

" StagerVerifySSLCert a true. Con esta opción el handler verifica la conexión. 

" EnableUnicodeEncoding a true. 

" HandlerSSLCert apuntando a la ruta del certificado en formato PEM.

Por último, os dejamos un video del proceso para que veáis la automatización y algunos de los detalles que se pueden visualizar.

Figura 10: PoC de Meterpreter Paranoid Mode

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths

TicketBleed: Un "Heartbleed" para los productos F5 BIG-IP

El nombre de esta vulnerabilidad que ha sido publicada esta semana tiene claras reminiscencias, claramente, al ya famoso Heartbleed (al que le dediqué un capítulo en el libro de Hacking Web Technologies). De hecho, tiene mucho que ver, aunque a menor escala, ya que en lugar de conseguir un volcado de 64 Kas de memoria, se consigue el volcado de 31 bytes de memoria aleatoria en cada petición, lo que lo hace menos efectivo. Además, F5 TLS solo está presente en los productos de F5 BIG-IP, y la versión vulnerable no en todos. No obstante, el bug es peligroso y debe parchearse cuanto antes.

Figura 1: TicketBleed: Un "Heartbleed" para los productos F5 BIG-IP

El fallo de TicketBleed reside en la implementación que hace el software de F5 TLS en las reconexiones rápidas de sesiones TLS, debido a cómo gestiona el código del producto los Session ID y los Session Tickets cuando se intenta reutilizar una sesión TLS anterior. La idea es bastante sencilla, y tiene que ver con mejorar el rendimiento de los sistemas criptográficos en la web. Os lo intento explicar resumidamente para que entendáis el bug. Si queréis más detalles, la lectura obligatoria es el libro de Cifrado de las Comunicaciones Digitales.

Figura 2: TicketBleed (CVE-2016-9244)

El protocolo TLS tiene un impacto en el rendimiento de los protocolos que se tunelicen sobre él por culpa de los algoritmos criptográficos que añaden privacidad a la comunicación. Estos son especialmente costosos en la fase de negociación inicial de las claves y menos costosos luego en el cifrado y descifrado de paquetes una vez que ya ha quedado establecida la negociación inicial - el famoso saludo -.

TLS Resumption in a nutshell

Como sobre el protocolo TLS pueden ir protocolos no orientados a conexión, es decir, que no mantienen sesiones vivas sino que realizan peticiones discretas y arrítmicas - como visitar una web, leer durante unos minutos una noticia y hacer clic en un link que navega a otra página dentro del mismo servidor - en los protocolos de cifrado se creo el concepto de reconexión rápida, es decir, re-aprovechar la fase inicial de una negociación TLS que no haya caducado para mejorar la velocidad. 

Figura 3: RFC 5077 TLS Session Resumption withos Server-Side State

En el estándar RFC 5077 se especifica que esta es una característica que debe tener soportada el servidor y que para ello el cliente debe enviar el Session ID y el Session Ticket, es decir, el identificador de la sesión que se quiere recuperar y la información necesaria para recuperarla. 

Figura 4: Especificación de gestión del SessionID

El servidor deberá devolver el mismo SessionID al cliente si se puede reutilizar esta sesión, por lo que cuando el cliente pide una reconexión debe enviar un SessionID y un SessionTicket. El servidor comprueba que el SessionID no está vacío y que es válido, por lo que devuelve una sesión con el mismo SessionID que copia directamente desde el SessionID que envía el cliente.

Y aquí está el problema.

La longitud del SessionID puede ser de 32 bytes, pero puede ser también solo de 1 byte. Si un cliente crea una conexión con un SessionID de 1 byte de longitud y el el servidor TLS copia 32 bytes de la memoria donde está el SessionID que ha recibido del cliente copiado, lo que contendrá el SessionID que se envía desde el servidor será 1 byte con el SessionID que envió el cliente, más 31 bytes de la memoria del servidor, en concreto de la memoria que utiliza el proceso TLS, por lo que puede venir cualquier cosa, como en el caso de HeartBleed.

Figura 5: Código vulnerable en F5 TLS

Por supuesto, cada petición solo "leakea" 31 bytes, pero si son los de una contraseña, un id o cualquier otra información sensible, el impacto puede ser muy alto. Además, como en el caso de HeartBlead, se puede poner un cliente a forzar el volcado de estos 31 bytes durante días y ver qué ha ido cayendo en el canasto, que seguro que habrá algo jugoso.

Figura 6: Test de TicketBleed y script en Go para probarlo tú mismo

El investigador Filippo Valsorda ha puesto un sitio en la web para que puedas comprobar si un servidor de F5 BIG-IP tiene este software F5 TLS vulnerable a TicketBleed o no. Nosotros lo hemos añadido a nuestro sistema de pentesting persistente Faast, pero si tienes equipos F5 BIG-IP deberías asegurarte que tienes todo actualizado a la última versión.

Saludos Malignos!