Se ha anunciado “otro clavo en la tumba de SHA-1” en forma de estudio que demuestra, de otra manera y una vez más, su debilidad. Aunque suene complejo, no es tan complicado. Cada cierto tiempo se vienen oyendo noticias sobre la debilidad de los algoritmos de hash, pero no siempre somos conscientes de qué significa y si son ataques teóricos prácticos. Vamos a intentar aclararlo.

Pequeña introducción
Una colisión en un algoritmo de hash es conseguir que dos flujos de datos diferentes tengan el mismo hash. SHA-1 son 160 bits y por tanto “solo” 2^160 combinaciones finitas. Pero el flujo de entrada de datos es infinito, así que teóricamente las colisiones son posibles, y de hecho necesitarías en 2^80 combinaciones de media por fuerza bruta para encontrarlas, algo que hoy por hoy es computacionalmente muy complejo. Las colisiones a su vez pueden ser de dos tipos, de prefijos “Idénticos” (o “clásico”) y de “Prefijos elegidos”.

Prefijos idénticos y prefijos elegidos
En las idénticas, digamos que el atacante no tiene control sobre los mensajes en los que se encuentra la colisión, sino que los elige el algoritmo. Por tanto es menos útil desde el punto de vista práctico (para un atacante). Se tiene que partir de la base de que existe un prefijo con mismo hash,y a partir de ahí se le añaden payloads diferentes para que todo el conjunto tenga el mismo hash, aunque el contenido sea diferente.

Esto es muy útil para crear documentos con un mismo hash y diferente contenido. Como un documento o binario con un formato compartido contiene muchas partes idénticas por esa misma razón, es bastante habitual realizar pruebas de concepto de este tipo.

Esto se popularizó con el algoritmo de Xiaoyun Wang y Yu en 2004. Diseñó un código para crear ficheros que podían llegar a ser diferentes en hasta 128 bytes, pero compartir un mismo hash MD5. Un año más tarde se publicó el famoso artículo «Attacking Hash Functions by Poisoned Messages – The Story of Alice and her Boss«, donde se mostraban dos ficheros PS (PostScript) con idéntico MD5. Lo consiguieron Magnus Daum y Stefan Lucks. Recordemos que MD5 son 128 bits y SHA-1, 160. Google no se consiguió lo mismo con SHA-1 hasta doce años más tarde y un coste más elevado.

Esto se mejoró sustancialmente en 2007 cuando Marc Stevens, Arjen K. Lenstra, y Benne de Wege pudieron crear dos binarios ejecutables completamente diferentes con mismo MD5, gracias a los prefijos «elegidos». Con los prefijos elegidos se abría una nueva fórmula, en la que se ponían en peligro los certificados, por ejemplo, con firmas digitales completamente diferentes pero que se podía simular que disponían del mismo hash, puesto que en un certificado solo se firma el hash de su información.

Por tanto, tenemos por un lado los ataques clásicos de Wang y demás con prefijo idéntico y por otro lado, Stevens y demás con sus prefijos elegidos. Uno más sencillo computacionalmente que el otro, y el segundo también más potente.

Y ahora, la carrera por reducir la potencia en cada modalidad
Una vez establecidas las bases de la teoría, tenemos una carrera para reducir la potencia necesaria para su cálculo, porque no olvidemos que todo esto se trata al final de fuerza bruta. No es lo mismo computar 2^80 que 2^60. Uno puede marcar la diferencia con respecto al otro sobre qué es factible hoy en día. Si reducimos el número, puede que se haya conseguido un logro, sin duda, pero quizás siga sin ser factible para la computación actual. Por tanto, tenemos ataques teóricos, donde con algoritmos en papel, reduce la potencia pero pueden ser imposibles hoy. Por otro lado, tenemos ataques prácticos con la computación actual. Por supuesto, con el tiempo los teóricos pueden volverse prácticos.

Para entender qué ha pasado con SHA-1 y por qué debemos preocuparnos, se puede realizar un paralelismo con MD5.

• 1992: se publica MD5 y en teoría se debería poder romper en 2^64 con fuerza bruta (se le suele llamar ataque cumpleaños).
• 1993: ya se habla de pseudo colisiones, pero nada preocupante para la época (vectores de inicialización diferentes que ofrecían el mismo digest).
• 2004: como hemos mencionado, colisiones de prefijo idéntico conseguidas en 2^40. Algo ya «práctico» en una hora.
• 2005: ficheros diferentes, mismo MD5 con prefijos elegidos. Crean dos certificados con mismo MD5.
• Curiosidad: en verano de 2005, un australiano consiguió anular una multa de tráfico. El abogado que representaba al amonestado recurrió una denuncia,  argumentando que no se había probado que la imagen obtenida por la cámara asociada al radar no hubiese sido modificada de ninguna forma. Las autoridades australianas de tráfico respondieron que se utilizaba el algoritmo MD5 para obtener el hash de las imágenes obtenidas. No encontraron a ningún perito que demostrase ante el tribunal la validez de este algoritmo, y por tanto se libró de la multa.
• 2006: colisiones de prefijo elegido en 2^49.
• 2009: se perfeccionan los ataques hasta unos 2^16 los idénticos y 2^39 los elegidos. Se crea una autoridad de certificación falsa con mismo MD5 gracias a 200 consolas PlayStation calculando colisiones. Cualquier certificado puede aparecer como válido ante una CA que use MD5. Muere definitivamente en la práctica y en la teoría.

Por otro lado, la historia de SHA-1 va más o menos así.

• 1995: se publica SHA-1. En teoría se debería romper en 2^80 (la mitad de 160) con fuerza bruta.
• 2005: SHA-1, se publica un primer ataque de colisión con prefijos idénticos en 2^69, algo computacionalmente costoso para el momento y por tanto complejo en la práctica. Aun así ya el NIST recomendó ir migrando. Lo consideraría obsoleto en 2011.
• 2012: se consigue mejorar los ataques de prefijo idéntico en 2^61. Algo posible, pero muy caro. Ese mismo año se consiguen que los ataques de prefijo elegido caigan a 2^77.1.
• 2017: Google consigue dos PDF diferentes con mismo hash. Utiliza ataques de prefijo idéntico, que en teoría estaban en 2^61, pero ellos lo consiguen en 2^63 tras varios meses de computación y un coste de más de 100.000 dólares (en GPU).
• 2019: Se consigue reducir la complejidad del algoritmo de colisión de prefijos elegidos hasta entre 2^66 y 2^69. Esto hoy por hoy requeriría bastante computación, pero… ¿y mañana?

Por tanto el paralelismo el claro, muy pronto podremos ver ataques prácticos de colisión de prefijos elegidos en SHA-1, bien porque se mejore aún más el algoritmo, bien porque la capacidad de computación lo permita. Como pasó con MD5, el siguiente paso será crear un certificado o entidad certificadora falsa con mismo SHA-1. Para entonces, más nos vale haber dejado de usar SHA-1 para siempre.

Lo queramos o no, el malware y todo el ecosistema que lo rodea es una industria más. Ilegal, pero con todas las características de una organización: maximizar beneficios con la menor inversión posible. Posee hasta su propio componente de I+D e incluso entre los grupos antagonistas se copian técnicas y recursos para competir por el mismo objetivo: infectar y capitalizar esa infección. Existe toda una taxonomía de técnicas y procedimientos para conseguir ese objetivo. Desde aquellos primeros virus primigenios que imitaban con gran exactitud a sus contrapartes biológicas, hasta sofisticadas armas digitales capaces de desactivar o neutralizar infraestructura industrial.

Pensemos por ejemplo en STUXNET y el cambio de juego que provocó su aparición: ya no se trata de minar o secuestrar archivos, ahora sabemos que estas creaciones pueden devolver a una ciudad o una nación entera al siglo XIX sin tan siquiera disparar una sola bala. Las técnicas de infección evolucionan, así como las técnicas de aprovechamiento una vez controlada la víctima. De estas últimas tenemos dos clásicos contemporáneos (salvo motivaciones de otra naturaleza, tipo APT): minar criptomoneda o bien ransomware. En los últimos meses hemos visto una oscilación o auge entre estas dos finalidades muy ligada a la cotización del bitcoin. Es decir, cuanto más se depreciaba el Bitcoin, menos interesaba desplegar clientes, puesto que era una fuente de rentabilidad relativamente baja. Una curiosidad: podemos observar estas dos gráficas, correspondientes a la cotización del Bitcoin y la tendencia en búsquedas del término «cryptominer«.

A mayor cotización del Bitcoin, mayor ruido provoca el termino asociado al malware. Intriga el pico, situado en la misma trama temporal que el pico del término.

El otro lado del embudo
Salvando la motivación final de los atacantes, desde el punto de vista del analista es muy interesante el estudio y evolución del vector de entrada, el ariete contra el sistema del usuario; o mejor, de la víctima. Sin una puerta de entrada que les permita una infección rápida y masiva, no se obtiene un gran retorno de inversión, quedando los esfuerzos en una victoria pírrica. Se hace necesario, por lo tanto, invertir en disponer de una palanca hábil que asegure un buen número de puertas abiertas en la vida de una campaña de infección. Es por ello, que los analistas pongan especial énfasis en seguir la evolución de estos vectores.

Hace unos años, el vector de entrada favorito era el triunvirato formado por Java, Adobe Reader y Flash. No había un solo exploit kit que no cubriese con varios exploits para varias versiones del trio. Los investigadores de vulnerabilidades vivieron una auténtica era dorada donde el anuncio de zerodays en estos programas era ya tan común que hasta dejaron de ser noticias y mutaron a un chorro continuo de boletines que se iban transformando en munición para alimentar la incansable maquinaria de campañas de malware.

Fueron días de vino y rosas…hasta que los navegadores dieron un paso al frente y vetaron los plugins que posibilitaban la invocación de complementos binarios para tratar contenido ajeno a los estándares web. Java fue el primero en caer y aunque la muerte de los Applets llevaba en curso desde mucho antes (sobre todo empujada por Flash), el peso de los exploits que iban saliendo para Java aceleró la caducidad de su ticket de viaje en los navegadores.  

Poco después le pasó lo mismo a Flash, aunque tardó algo más que Java en ser condenado al destierro. Curiosamente, incluso Steve Jobs rechazó el uso de Flash en iOS por las mismas razones que fue denostado: es código propietario y tiene graves problemas de seguridad; además de un consumo de recursos incompatible con la autonomía móvil. Flash, que comenzó tomando el terreno de los Applets Java, terminó siendo, a su vez, reemplazado por la tecnología nativa de los navegadores: la web. Todo apunta a 2020 como fecha del final de vida de la tecnología que nació de manos de Macromedia. 

Por último, el problema de facilitar la lectura de documentos PDF colgados en la web, fue solucionado con lectores de este formato implementados en JavaScript, y, por lo tanto, incrustados como una funcionalidad más del propio navegador que hacía ya inútil la inclusión de un complemento que llamase, a su vez, a una aplicación nativa. De nuevo, una puerta más cerrada.

¿Y atacar directamente al navegador? Sí, pero con matices. La Pwn2Own es una competición donde para ganar se debe explotar un navegador, de los principales conocidos, con vulnerabilidades 0-day, no conocidas con anterioridad al concurso. Aunque todos los años ha habido ganadores en todas las categorías, Chrome lleva dos años inmaculado. Las medidas de seguridad van dando sus frutos y consiguen endurecer las reglas del juego entre investigadores y programadores. Ya no vale con un fallo crítico en un componente del navegador, ahora se necesita encontrar una combinación ganadora que permita saltar la sandbox en la que discurre el proceso en ejecución. Si bien es cierto que otros navegadores no pueden presumir del mismo estado de forma, hay una cierta tendencia a moverse hacia Chrome. Por ejemplo, Edge, el navegador de Microsoft está en proceso de cambiar su base a Chromium, al igual que ya lo hizo Opera. Incluso, Microsoft está reforzando la seguridad de los procesos aislando la ejecución de estos en un entorno casi completamente aislado del sistema. ¿Qué hacen los atacantes ante esta situación? Como ya anticipamos al comienzo, su I+D no se detiene y sigue buscando nuevas vías de infección. Clausuradas unas puertas, cambiadas otras por unas nuevas acorazadas, hay que dar una vuelta al lugar y volver a examinar que accesos o posibles brechas pueden seguir siendo rentables para invertir en ellas tiempo y recursos. Y da sus frutos…

Ahora se lleva lo retro
Office, la suite ofimática que ganó la guerra de las suites ofimáticas en la década de los 90, incorporó una tecnología bastante potente para que los usuarios avanzados pudieran ir más allá del, ya de por sí rico, abanico de funcionalidades a su disposición: Incrustar un lenguaje de programación con una gigantesca biblioteca de funciones y objetos a su disposición.

Mientras que la idea podría ser estupenda en un mundo ideal, muy pronto se vieron las posibilidades «armamentísticas» del motor de scripting. Con el nombre de «Melissa», en 1999 fue el nombre con el que se bautizó uno de los primeros virus de macro mediáticos (con el permiso del posterior y popular ILOVEYOU, que afectaba al gestor de correo Microsoft Outlook). Se inauguraba un periodo de «virus de macro» que se extendería hasta bien entrado el milenio…y pocos años después, el silencio. Tras un periodo en el que los fabricantes de malware se centraron en estas macros para difundir sus creaciones, se volvió más rentable invertir en otros vectores más fructíferos, tales como servicios a la escucha sin las protecciones adecuadas o el navegador y sus innumerables conexiones con complementos nativos llenos de desbordamientos de pila y sus coetáneos. El malware basado en macros ya no estaba de moda.

…hasta que alguien se dio cuenta de lo relativamente fácil (que no lo es) que seguía siendo ese olvidado vector, comparado con la bestia de siete cabezas y tres colas en que se convirtió la explotación del navegador como bastión a asediar. Las macros regresaron y, una vez más, los buzones de correos volvieron a llenarse de correos con adjuntos para Office con «las fotos privadas de alguien», «las nóminas de los empleados» o «información que nadie quiere publicar acerca del hecho relevante del momento». Una inadvertida segunda juventud.

Las macros en el siglo XXI
La popularidad en alza de las macros como vector de infección es una clara señal de que existe un movimiento real, impulsado por la necesidad de ampliar el parque de máquinas infectadas (o de operaciones quirúrgicas sobre un objetivo bien definido). Tanto la explotación de vulnerabilidades en Office como del uso de la ingeniería social o combinación de estas, nos sirve para punzar las defensas y abrir brecha. Por supuesto, ayuda bastante a la credibilidad de una campaña de malware el hecho de que estos sean documentos que suelen ser usados para portar información sensible: «factura a devolver.xls» o «lista de contraseñas.docx», son jugosos titulares que atraen a los curiosos a una trampa mortal. Pero también se han añadido a la coctelera técnicas adicionales de ofuscación y la popularidad de powershell, algo que no existía en la primera época dorada. Por tanto, ¿qué aspecto tiene una macro maliciosa hoy en día? Usamos DIARIO (un detector de malware especializado en documentos que no necesita el contenido del documento para analizarlo y por tanto, permite subir información que pudiese considerarse privada ) y analizamos una muestra «típica».

Si se observa, una de las primeras acciones que ejecuta la macro es levantar un proceso en PowerShell, con una cadena que intenta ofuscar de nuevo infructuosamente, ya que se trata de una cadena en base64 y comprimida que es fácilmente reversible. El uso de este tipo de ocultación no impide el análisis, aunque si dificulta la detección por cadenas.

Respecto a codificar el payload en PowerShell en vez de directamente en VBA (Visual Basic for Applications) se debe, en la mayoría de los casos, al uso de frameworks de explotación que utilizan PowerShell creando un stub o envoltorio mínimo y funcional en VBA para ejecutar a este último. Es decir, el creador de este tipo de malware ni tan siquiera se preocupa de conocer el lenguaje de macros, e incluso tampoco PowerShell, ya que el framework crea este tipo de payloads «a la carta».

Hay multitud de este tipo de frameworks, muy conocidos y populares por la comunidad de pentesters o red teams, para los cuales se ideó. Desde Empire, PowerSploit o Nishang, hasta el uso de la suite profesional Cobalt Strike. Aunque son indispensables para evaluar la seguridad de las organizaciones, la otra cara es un impulso a la industrialización de la cadena de producción de malware que permite entrar con un bajo nivel de requerimientos y experiencia.

En resumen, nada se va del todo. Al final el atacante sigue su filosofía de ir por lo (a priori) más fácil y no complicarse la vida. ¿Que ahora es difícil explotar un navegador? Pues apelamos a la ignorancia y la curiosidad del usuario. Es relativamente fácil y tentador colar un documento con malware. A pesar de los filtros, cada vez mejores, el spam sigue colándose de vez en cuanto y suele valer aquello de que el 1% de cien millones sigue siendo un millón. Y un millón da para mucho juego.