Operación Cleaver: Irán detrás de ataques informáticos a 16 paises

Un informe de la compañía Cylance desvela las actuaciones de un grupo de atacantes iraníes que durante los dos últimos años han conseguido recopilar información de más de 50 organizaciones críticas en 16 países.

La compañía Cylance ha publicado un completo informe en el que detalla como desde al menos 2012 un grupo iraní ha estado atacando, se ha establecido de forma permanente y ha llegado a extraer información altamente sensible de redes de agencias gubernamentales y de compañías de infraestructuras críticas (transporte, comunicaciones energía…) de los siguientes países: Canadá, China, Inglaterra, Francia, Alemania, India, Israel, Kuwait, México, Pakistán, Qatar, Arabia Saudí, Corea del Sur, Turquía, Emiratos Árabes Unidos y los Estados Unidos.

Bautizado como "Operación Cleaver" debido a que la cadena "cleaver" aparece en múltiples piezas de software empleadas en los ataques (especialmente en diferentes rutas y directorios).

Todo indica a que Irán se ha tomado la revancha, podemos recordar como durante los años 2009 a 2012 fue víctima de diferentes campañas de sabotaje industrial y espionaje como Stuxnet, duqu o Flame. Estas muestras de malware se centraron en el programa nuclear iraní, y operaciones de petróleo y gas.

Según Cylance, el grupo de atacantes trabajaban desde Teheran (Irán) aunque se han identificado miembros auxiliares en otras localizaciones como Países Bajos, Canadá y el Reino Unido.

Los objetivos incluían instalaciones militares, gobiernos, servicios públicos, aerolíneas, aeropuertos, hospitales, empresas químicas y aeroespaciales. También compañías petroleras, de gas, de energía, de transporte, de telecomunicaciones y de tecnología.

Durante los dos últimos años, Cylance confirma que ha recogido más de 8 GB de información, que incluyen más de 80.000 archivos de datos extraídos, herramientas, registros de las víctimas y datos de reconocimiento altamente sensibles.

Metodología

Para realizar los ataques el grupo aprovechó con éxito tanto herramientas disponibles públicamente como otras personalizadas (en algunos casos la personalización pasaba por modificar el nombre del autor). Aunque evidentemente los métodos empleados han sido eficaces, tanto por haber logrado sus objetivos como por haber permanecido ocultos durante tanto tiempo, tampoco hay muchas novedades detrás de ellos (inyecciones SQL, campañas de spear phishing o uso de exploits públicos).

La campaña de Cleaver usa una variedad de métodos en múltiples etapas de ataques. El objetivo inicial era lograr la intrusión en la red atacada y conseguir la ejecución de código arbitrario. Para este compromiso se emplearon principalmente técnicas de inyección SQL y campañas de spear-phishing.

Después se trataba de lograr una elevación de privilegios, lo que permitía a los atacantes conseguir acceso a zonas restringidas del sistema, así como atacar otros sistemas de la red. Igualmente tampoco se empleaban técnicas novedosas, según Cylance han encontrado varios exploits públicos conocidos. PrivEsc un exploit compilado que explota la vulnerabilidad con CVE-2010-0232 sobre sistemas Windows sin actualizar, NetC (Net Crawler), un exploit en Python para aprovechar la vulnerabilidad MS08-067, Jasus y hasta el conocido Cain & Abel.

Para la extracción de datos el informe enumera diferentes servidores ftp anónimos. También se describe el uso de NetCat (también empleado como Shell inversa), que posteriormente fue reemplazado por una utilidad desarrollada por el equipo de Operación Cleaver que opera de forma similar a NetCat. También se ha usado PLink (utilidad incluida en la suite SSH PuTTY) y hasta el uso de correo mediante servidores SMTP con el relay abierto.

Para mantenerse en los sistemas atacados principalmente se utilizaron diferentes versiones de TinyZBot, una puerta trasera desarrollada en C#. Según indica el informe esta muestra de malware es el mayor desarrollo realizado por la organización (y aun así no fue desarrollada completamente por Cleaver).  

En el propio informe, con el objetivo de prevenir y detectar infecciones de esta amenaza, se comparten los IOCs (Indicators of Compromise) descubiertos durante la investigación. Estos incluyen dominios, direcciones de correo, direcciones IP, exclusiones mutuas, nombres de servicios instalados, MD5 y SHA-256 de cientos de muestras y firmas YARA.

Más información:

Operation Cleaver

http://www.cylance.com/assets/Cleaver/Cylance_Operation_Cleaver_Report.pdf

una-al-dia (19/10/2011) Duqu, ¿el nuevo malware descendiente de Stuxnet?

http://unaaldia.hispasec.com/2011/10/duqu-el-nuevo-malware-descendiente-de.html

una-al-dia (15/01/2011) Según el New York Times, Stuxnet fue creado por el gobierno de Estados Unidos e Israel

http://unaaldia.hispasec.com/2011/01/segun-el-new-york-times-stuxnet-fue.html

una-al-dia (29/05/2012) TheFlame: reflexiones sobre otra "ciberarma" descubierta demasiado tarde

http://unaaldia.hispasec.com/2012/05/theflame-reflexiones-sobre-otra.html

Antonio Ropero

antonior@hispasec.com

Twitter: @aropero

¿Qué ha pasado con el certificado de Adobe?

Vuelve a darse un golpe a la confianza en la criptografía en general y a las PKI en particular. Se ha robado un certificado de Adobe y se ha utilizado para firmar código ajeno. En estos momentos, un programa firmado en los últimos meses por un certificado válido de Adobe, no ofrece garantías sobre su legitimidad.

El jefe de seguridad de Adobe reconoció el jueves que sus sistemas habían sido vulnerados y que, de alguna forma, habían conseguido firmar código ajeno con sus certificados. En la práctica, significa que recibieron varios ficheros.

El primero es PwDump7.exe. Es una evolución de los clásicos pwdump, programada por los conocidos hermanos Tarasco, y de la que particularmente hacemos uso en nuestras auditorías. Sirve para volcar los hashes LM o NTLM de Windows. Normalmente es detectada como malware o PUA (Potentially unwanted application) por los antivirus. A pesar de no pertenecer a Adobe, estaba firmada por ellos. Junto a este recibieron libeay32.dll, que necesita pwdump para funcionar y un tercero también firmado myGeeksmail.dll, que al contrario que el resto, no es una herramienta pública.

Aclarando conceptos

Por supuesto, no tiene por qué existir relación alguna entre los creadores de la herramienta (conocidos programadores e investigadores de seguridad) y el robo del certificado. En principio, la herramienta firmada parece que no ha sido alterada. Probablemente un tercero necesitaba que esta herramienta pasase desapercibida por los antivirus, y la firmó con el certificado de Adobe. De hecho, algo ha conseguido.

El resultado de la herramienta (sin firmar) en VirusTotal es de 34 positivos:

https://www.virustotal.com/file/b20f667c2539954744ddcb7f1d673c2a6dc0c4a934df45a3cca15a203a661c88/analysis/

La misma herramienta firmada con Adobe, da 20 positivos:

https://www.virustotal.com/file/e374fd4f7dfabe7e3471021b023ed7f5fb23b76898575c750a84b77d11c23d14/analysis/

Y es que a los antivirus les gustan los ficheros firmados... algo que deben empezar a replantearse. Resulta un poco extraño vulnerar una PKI de una gran compañía con el único objetivo de pasar desapercibido para algunos antivirus, puesto que existen otras maneras más sencillas... Pero aún es pronto para cualquier hipótesis.

Esta es la misma técnica que usó TheFlame al firmar con un certificado de Microsoft su código: pasó desapercibido años y consiguió el sueño de todo creador de malware... Pero lo usó para ataques mucho más sofisticados. Quizás en el futuro aparezcan otros ficheros de malware firmados por Adobe (aunque ya esté revocado el certificado). Quién sabe.

Tampoco significa que las herramientas de Adobe firmadas con este certificado que tenemos en nuestro sistema (que seguro tenemos, se puede usar esta herramienta para saberlo), se encuentren comprometidas. No se sabe desde cuándo ha podido estar comprometido el certificado y un potencial atacante ha podido firmar código propio de Adobe con diferentes intenciones... pero lo más probable es que las herramientas firmadas y descargadas desde el sitio oficial de Adobe, sean perfectamente válidas aunque se encuentren firmadas con un certificado que ha sido robado. Lo que sí se sabe es que el pwdump7 fue firmado el 27 de julio de 2012 con lo que, al menos, desde entonces el atacante ha podido firmar cualquier cosa. Si hubiera conseguido además distribuir código de Adobe desde sus canales habituales se hubiera producido una catástrofe. Pero parece que no es el caso y que la alarma no debe ir mucho más allá. El problema real ha sido pues para Adobe, el varapalo a su credibilidad en cuestión de seguridad (que nunca ha sido excesiva) y la tarea de encontrar ahora el cómo y el cuándo han entrado en sus redes.

No se tienen demasiados detalles de cómo ha ocurrido. Por supuesto, Adobe aduce que se trata de un ataque de altísimo nivel y con un objetivo muy claro. También, que su PKI cumplía todos los requisitos de seguridad.

Qué pasa ahora

Dos cosas: Primero es necesario actualizar las herramientas de Adobe. Estas serán las mismas o una versión posterior pero firmadas por otro certificado.

Segundo, Adobe ha pedido a Microsoft que revoque el certificado. De nuevo, se añadirá uno o varios certificados robados al sistema de desconfianza. Sería la quinta revocación masiva de certificados en 11 años. Cuatro de ellas en los últimos dos. Esto da una idea de cuánto se ha movido últimamente el asunto de los ataques a certificados. Por supuesto, el referente ha sido TheFlame, que consiguió robar un certificado de Microsoft con métodos sorprendentes. Con Adobe parece que el robo ha sido más "mundano".

Para los usuarios que deseen mover ya el certificado al repositorio de no confiables antes incluso de que se produzca la revocación, deben saber que por defecto no detendrá la ejecución de un hipotético código firmado por atacantes.

Aunque Adobe no especifica por qué, no funcionará con solo marcar el certificado como no confiable. Es necesario realizar un cambio en el sistema. En concreto, activar authenticodeenabled con el valor 1 en la rama:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifier

Una vez realizado este cambio, sí que se bloquearán las herramientas con él firmadas.

Pero no se recomienda porque según Adobe, sí que podría tener algún efecto negativo sobre el código legítimo del usuario (el funcionamiento de sus programas reales). Muy probablemente, a lo que se refiere es a que supondría un problema para el proceso de actualización. El certificado se bloqueará el día 4 de octubre y tiene el número de serie 15e5ac0a487063718e39da52301a0488.

Más información:

Inappropriate Use of Adobe Code Signing Certificate

http://blogs.adobe.com/asset/2012/09/inappropriate-use-of-adobe-code-signing-certificate.html

Security Advisory: Upcoming Revocation of Adobe code signing certificate

http://www.adobe.com/support/security/advisories/apsa12-01.html

Searching For That Adobe Cert

http://blog.didierstevens.com/2012/10/01/searching-for-that-adobe-cert/

Sergio de los Santos

ssantos@hispasec.com

Twitter: @ssantosv

Actualización automática ¿Bendición o condena?

El caso TheFlame ha promovido muchas reacciones: los articulistas rellenan páginas con prefijos "ciber" y la palabra "guerra". Las casas antivirus lo usan como arma de venta  (aun sin haberlo detectado en cinco años) y Microsoft queda en evidencia con su PKI y la refuerza. TheFlame ha minado también la confianza: en los gobiernos, en los antivirus... pero sobre todo, en la criptografía y en la actualización automática.

Criptografía

El caso de los certificados falsos de Microsoft usados en TheFlame debería lanzar una nueva advertencia sobre la gestión de la criptografía. Si el SSL está "roto socialmente" porque no se entiende, porque se usa mal (todavía con hashes MD5, por ejemplo), porque las autoridades certificadoras sufren intrusiones, o porque se abusa del negocio alrededor de los certificados..., la mala gestión de una PKI como la de Microsoft vuelve a hacerle un flaco favor a la seguridad que proporciona la criptografía en general.

Y hay que cuidarla. Porque la criptografía actual es lo mejor que tenemos, y es en lo único que podemos basar nuestra confianza en estos momentos. Sin criptografía no hay Internet. La criptografía permite, por ejemplo, que se dé vía libre a la ejecución automática de código en el sistema con ciertas garantías (hasta ahora), de forma que se pueda parchear antes  y se reduzca el riesgo. Es esencial.

Automatización

Y es que el software ha migrado hacia la "autoactualización": la automatización total de las actualizaciones. Desde que el año 2000 Microsoft debutara con "Windows Update", y estableciera más tarde por defecto la actualización automática, las aplicaciones se han apuntado al carro. Chrome fue de los primeros programas  populares que no tuvo miedo a dejar de contar totalmente con el usuario para actualizarse. Y le ha ido bastante bien. Sus usuarios no solo parchean en tiempo récord, sino que tienen la sensación de que nunca tienen que hacerlo... lo que vende muy bien estos días.

Luego Mozilla, Acrobat, Flash no hace mucho... Incluso Chrome fue más allá y comenzó a actualizar sus propios plugins... Todos, ante graves problemas de seguridad, han optado finalmente por actualizarse sí o sí, por defecto. Actualizar es la absoluta prioridad en el mundo de la seguridad. Sin embargo no todos los sistemas de actualización están totalmente automatizados (muchos programas todavía confían en que el usuario acepte antes de aplicar el parche) ni todos lo hacen correctamente. Ciertos programas han realizado una mala implementación de sus sistemas de actualización y de eso se aprovecha la herramienta EvilGrade, todo un framework para explorar esas rendijas que proporcionan las actualizaciones de más de 60 programas. Para algo tan delicado como la automatización, los programadores deberían tomar muchas más precauciones.

Y es que fríamente y por definición, la automatización, es una mala idea. Trasladar ciegamente el poder a las máquinas siempre debería ser menos confiable que llevarlo al lado "razonable" del usuario. No podemos dejar total control en las máquinas porque, una vez encontrada la rendija adecuada, puede llevar a unas desastrosas consecuencias. Pero como la criptografía, es lo mejor que tenemos en estos momentos para obligar a actualizar. Incluso así, parece aún peor dejar que el usuario decida:

• En entornos caseros, suele resultar una molestia y aplicarse tarde. Está demostrado que los niveles de parcheo total son muy pobres. El software pirata en este caso, también hace mucho daño en este entorno.
    
• Y en redes corporativas, las actualizaciones automáticas serían muy útiles pero resultan muy "poco populares" entre los administradores. El pánico a interrumpir la producción ante el más mínimo inconveniente les lleva a enterrar la seguridad como prioridad en el trabajo. Esto les resta mucha agilidad a la hora de actualizar y se vuelven muy vulnerables. Las facilidades para automatizar que proporciona Chrome, por ejemplo, es inútil en estos entornos.

Así que no hay respuesta para la pregunta que encabeza este artículo. ¿Centrarse en una automatización más controlada, quizás? ¿Educar al usuario? Al final, se llega al callejón sin salida del tópico: "la comodidad está reñida con la seguridad"... Pero hoy en día, parece que quien se acomode, pierde.

Más información:

flame's impact on trust

http://anti-virus-rants.blogspot.com.es/2012/06/flames-impact-on-trust.html

1.91% of all PCs are fully patched!

http://secunia.com/blog/37/

Sergio de los Santos

ssantos@hispasec.com

Twitter: @ssantosv

TheFlame, el francotirador

En los últimos días, y a modo de reflexión sobre lo ocurrido con el troyano TheFlame, algunas voces se han sumado a la crítica hacia la industria antivirus, como responsable de que el troyano pasara desapercibido durante años. Pero no lo son (en todo caso, no son los únicos). ¿Qué lecciones se pueden aprender de la detección y análisis de este malware?

Mikko Hypponen entonó un razonado "mea culpa" en Wired:

"When we went digging through our archive for related samples of malware, we were surprised to find that we already had samples of Flame, dating back to 2010 and 2011 [...] What this means is that all of us had missed detecting this malware for two years, or more. That´s a spectacular failure for our company, and for the antivirus industry in general."

Y es razonable, por la manera en la que trabajan las casas antivirus (que no los antivirus en sí). Reciben alrededor de 100.000 muestras al día. No todas son malware y, lógicamente, no todas son analizadas a mano. Es imposible. Simplificando el proceso, las muestran pasan por sistemas automáticos que intentan clasificarlas. Si alguna resulta claramente malware, pasa sin más a ser detectada por firma (genérica). Si solo resulta sospechosa, quizás llegue a un segundo filtro manual. Si aquí se confirma como malware (un proceso que puede llevarle muchas horas a un analista) se incluye en las firmas, y se repasan de nuevo las muestras que han llegado para analizarlas con esa nueva firma y detectar más. Este un proceso costoso, sin fin, y muy complejo... cuyos volúmenes están incrementando.

Kaspersky hablaba en Twitter de que, en el último año, el número de muestras "detectadas" diariamente había pasado de unas 75.000 a 125.000. No sabemos si ese "detectadas" está bien empleado. De hecho, Jorge Mieres, de la misma compañía, decía un poco más tarde en Twitter "En los últimos meses ha aumentado un 80% el número de muestras únicas procesadas por día. 125.000."

En este proceso de automatización, los antivirus prefieren pecar por defecto y no caer en detección de falsos positivos. Una muestra firmada por Microsoft, como TheFlame, no tenía la más mínima posibilidad de pasar como sospechosa por ningún filtro.

Otra frase de Hypponen llama la atención:

"Yet we failed to do that with Stuxnet and DuQu and Flame. This makes our customers nervous."

                          

Los antivirus están sometidos a un gran peso comercial, de imagen, de ventas y beneficios. Deben contentar a sus clientes. Y la alerta mediática generada les pone nerviosos. Sin embargo, no se debe perder el foco. Aunque se deban invertir recursos en detectar muestras extremadamente sofisticadas, es mucho más importante controlar de forma eficaz la inmensa oleada de malware "común" como las nuevas versiones de Zeus o SpyEye. Quizás no usen certificados de Microsoft para ocultarse, pero podemos asegurar que sus índices de infección (y robo real de cuentas bancarias) son infinitamente más altos. ¿Cómo repartes tus recursos entonces? ¿Es mejor invertir en medicinas para curarte de una enfermedad mortal detectada en algunos puntos de Irán que afecta principalmente a una raza característica? ¿O dedicarlos a la lucha contra las enfermedades comunes? Los clientes de antivirus lo querrán todo... pero eso sería una evaluación de riesgos muy pobre. Por otro lado, culpar únicamente a las casas antivirus sería injusto.

Un antivirus no está diseñado para detectar malware de este calibre, simple y llanamente. Si hacemos una analogía de guerra, un antivirus sería como un chaleco antibalas. Puede llegar a proteger del fuego cruzado, de las balas perdidas... Es posible que no se muestre eficaz con cierto tipo de munición destinada específicamente a traspasarlo, pero puedes reforzarlo periódicamente y proteger tu cuerpo. Por supuesto, esto no exime al que lo acarrea de ocultarse en lo posible de la primera línea de fuego y otros métodos para salvarse. Pero ¿quién te protege de un francotirador que, apostado estratégicamente en un edificio, apunta a tu cabeza desde hace días? TheFlame es un francotirador, con mucha puntería y la mejor arma. Un chaleco antibalas no protege contra francotiradores.

¿Se tambalea entonces la confianza en los antivirus? No. No hay que quitarse el chaleco antibalas. Lo que hay que hacer es mejorarlo y complementarlo. Si se cuestiona algo, que sean los cimientos de los procesos automatizados y de las políticas de seguridad aplicadas. Una bofetada que debería hacernos despertar y replantear incluso aquello que parece que "funciona bien". Porque pueden existir otros métodos.

Más información:

Why Antivirus Companies Like Mine Failed to Catch Flame and Stuxnet

http://www.wired.com/threatlevel/2012/06/internet-security-fail/

Kaspersky

http://twitter.com/e_kaspersky/status/210735208369094657

Jorge Mieres

http://twitter.com/jorgemieres/status/212161627716452352

Sergio de los Santos

ssantos@hispasec.com

Twitter: @ssantosv

La creación del certificado falso usado por TheFlame, ridiculiza la estructura PKI de Microsoft (y II)

Seguimos estudiando qué hicieron los atacantes para conseguir una maniobra critptográfica del calibre de TheFlame. Veamos cómo solucionaron el problema que les suponía la mejora introducida por Microsoft en la critpoApi de Windows Vista, 7 y 2008.

Los certificados de Terminal Server, poseen una extensión crítica llamada Hydra (que es un nombre que antiguamente se le daba a Terminal Server). El certificado usado para el ataque no la tenía. En teoría, no debería haber validado en Windows XP SP3, Vista, 7 y 2008, puesto que su CriptoApi no acepta firmar código con certificados que contengan extensiones críticas no establecidas para tal fin, así que los atacantes tenían que quitar la extensión del certificado y que siguiera siendo válido. ¿Cómo lo hicieron?

Fuente: http://rmhrisk.wpengine.com/wp-content/uploads/2012/06/mslic-3.png

La colisión

Para crear un certificado falso, no es necesario crear uno perfecto, sino uno lo suficientemente "real" como para que el servidor firme una petición. Recordemos que una autoridad certificadora toma los datos del certificado (a quién se emite, fecha de validación...), calcula su hash, y lo firma con su clave privada. Este proceso puede ser automático. Los atacantes crean dos certificados. Una licencia de Terminal Server "normal" (con todos los campos correctos) y otro que será usado para el fraude con los campos modificados. En este caso, se creó uno con el campo crítico establecido (que impediría su validación para firmar código) y otro sin el campo establecido.

Manipulan ambos, introduciéndoles datos y caracteres, hasta que consiguen que, el hash MD5 de ambos sea el mismo. Este tipo de ataque ya es posible, se demostró en 2008. Los atacantes mandan el certificado "bueno" a la autoridad certificadora, que lo firma porque, aunque manipulado, parece correcto. El atacante ya tiene un hash MD5 firmado que le conviene. Ahora solo tiene que cortar y pegar la firma de la autoridad en el certificado creado a su gusto. Desde ese momento dispone de dos certificados diferentes, con un mismo MD5... pero uno sirve a sus intereses.

Un ataque muy avanzado

En principio el tipo de ataque parece uno de colisión MD5 con "prefijo conocido", del que ya se había estudiado algo en 2008, pero que todavía no se había visto en la práctica. Esta semana se ha conocido que, aunque puede estar basado en ese estudio de 2008, la colisión se ha conseguido con métodos nuevos de criptoanálisis. Están estudiándolo.

Esto es, sin duda, lo más relevante de TheFlame: la puesta en práctica (y muy ingeniosa) de métodos criptográficos nuevos y muy costosos en recursos. Esto marca la diferencia incluso con otras "ciber-armas" como Stuxnet o Duqu. Es peligroso porque supone introducir criptografía avanzada en el espionaje, igual que en la segunda guerra mundial, legiones de matemáticos estudiaban el cifrado de las máquinas Enigma.

El certificado usado tenía además un campo oculto que ya no usa Microsoft (el RFC 2459 no lo recomienda en X.509v3): "Issuer Unique Identifier". Tanto Issuer Unique Identifier  como las extensiones son opcionales en la estructura X.509v3.

En ese campo (aunque no está destinado a ello) los atacantes introdujeron una estructura de certificado X.509v3 válida, con las extensiones que habían eliminado del "original". No queda claro por qué, pero probablemente tenga que ver con el ataque de colisión. En ese "sub-certificado" oculto se comprobó que la extensión llamada Microsoft Hydra sí que estaba establecida como crítica, con su valor 1.3.6.1.4.1.311.18. Esto es lo normal en un certificado, pero recordemos que, el "original", tenía las extensiones borradas.

Qué errores ha cometido Microsoft

Se han leído comentarios acerca de la "falta de seguridad de Windows" a raíz del caso TheFlame. En primer lugar, ante un ataque de estas características, absolutamente ningún sistema operativo hubiese estado a salvo. En segundo lugar, el problema no es en absoluto Windows (excepto en el caso de XP y 2003,  que como hemos dicho, valida certificados aunque un campo crítico no sea correcto). Y por supuesto, nadie ha entrado en sus sistemas de PKI como ocurrió con Diginotar. El problema ha sido de "concepto" de Microsoft a la hora de diseñar una PKI, cosa infinitamente más grave que una vulnerabilidad típica y mucho más allá de los tópicos desfasados y los prejuicios establecidos.

Para empezar, el método de distribución de los certificados de Terminal Server les jugó una mala pasada. Además estos certificados de Terminal Server están validados en última instancia por la propia raíz certificadora de Microsoft, madre de todos los certificados de la compañía. Con eso, conseguían que al final, el certificado validase independientemente de su función. Si hubiera existido otra madre certificadora exclusivamente para esto, el problema se hubiera mitigado. Confirman que ya se han puesto a ello para construir una jerarquía certificadora independiente.

Esa es la razón por la que invalidaron toda la jerarquía subcertificadora relacionada con Terminal Server y no un certificado en cuestión. Por supuesto, que una entidad certificadora se fíe de un hash MD5 es otro grave error que debían haber corregido hace tiempo.

Las claves RSA usadas en estas licencias Terminal Server son de 512 bits. Algo totalmente desfasado para las fechas actuales, donde el estándar son 2048 bits. RSA de 512 fue ya refactorizado en 1999.

En definitiva, una desafortunada puesta en evidencia de la PKI de Microsoft, anticuada y mal gestionada. No tanto un problema de su sistema operativo.

Más información:

MSRC 2718704 and Terminal Services License

Certificateshttp://rmhrisk.wpengine.com/?p=60

MSRC 2718704 and Nested EKU enforcement

http://rmhrisk.wpengine.com/?p=57

Flame malware collision attack explained

http://blogs.technet.com/b/srd/archive/2012/06/06/more-information-about-the-digital-certificates-used-to-sign-the-flame-malware.aspx

Sergio de los Santos

ssantos@hispasec.com

Twitter: @ssantosv

La creación del certificado falso usado por TheFlame, ridiculiza la estructura PKI de Microsoft (I)

Ya es definitivo: para crear TheFlame, han sido necesarios no solo unos programadores expertos con gran motivación (léase, dinero) y profundas habilidades técnicas, sino expertos en criptografía que parecen haber desarrollado y puesto en práctica una novedosa técnica para crear colisiones MD5. Por estos motivos, y ahora sí, se puede decir que TheFlame es un punto y aparte en el malware y en el espionaje en general.

Microsoft examinó el certificado falso. Comprobó que las extensiones oficiales habían sido borradas. Lo lógico quizás hubiera sido que tuviese el valor 1.3.6.1.4.1.311.2, que define que el certificado está creado para firmar código. Pero no. Entonces, ¿por qué la cadena de certificación lo dejó pasar?

A la izquierda, las extensiones de un certificado usado para firmar un programa cualquiera. A la derecha, el certificado falso de TheFlame

Lo que han detectado son dos problemas por separado, además de otros adicionales. Vayamos por partes.

¿Un certificado que sirve para licenciar Terminal Server y firmar código?

Un certificado debe estar restringido en su uso a través de las extensiones Extended Key Usage. Así, un certificado puede ser usado para autenticar un servidor a través de SSL o para cifrar un correo (S/MIME). En el RFC 5280 donde se especifica la implementación, no se aclara totalmente el cómo hacerlo. Microsoft eligió la manera equivocada. En resumen, el certificado final hereda EKU (Extended Keys Usage) "por omisión", debido a que las autoridades certificadoras superiores se lo proporcionan "indirectamente".

Si se examina la cadena de certificación del certificado usado por TheFlame, se comprueba que finalmente, el certificado puede llegar a servir para firma código, aunque no posea un campo EKU explícito. ¿Y por qué "puede llegar"? Microsoft considera que si no se define el uso específico del certificado EKU, se puede decir que es "bueno para todo", pero, si uno de los certificados "padre", define alguna EKU, no puede usarse para algún uso diferente al de los ya definidos.

Con estos descubrimientos en la PKI de licencias de Terminal Server de Microsoft, los atacantes ya podían firmar código a partir de una licencia de Terminal Server. El código pasaría como totalmente válido (creado y validado por Microsoft) en Windows 2003, XP... y sin necesidad de colisión ni nada parecido. Podrían enviar una petición de firma a un servidor de licencias, y usar la clave privada de esa clave pública para firmar un programa y que pareciese totalmente de Microsoft. Es por esta razón que en la alerta de Microsoft se afirmaba que el ataque era posible también "sin necesidad de colisión". Y esto ha ocurrido hasta que apareció Vista y el service pack 3 para XP. Esto es un absoluto desastre.

Ahora bien... en Windows XP Service Pack 3, Vista, 2008 y 7, este método no sería válido, porque cambió la forma en la que se manejaban las extensiones. En los certificados, se puede marcar un campo como crítico. Los campos definidos como críticos (en la interpretación gráfica de los certificados, aparece con un signo de admiración), hacen que el certificado falle en su validación si no están establecidos convenientemente. O sea, si a la hora de dar por válido un certificado que está siendo usado para firmar código, se encuentra en su interior una extensión crítica que dice que es para otro uso, se daría por inválido el certificado (pero solo en sistemas post-Vista, no en los anteriores).

Los certificados de licencias de Terminal Server suelen tener la extensión "Hydra" marcada como crítica. Así que si los atacantes querían un certificado para firmar que funcionara en todas las versiones, tenían que eliminar por completo ese campo crítico (así a la hora de validarlo, no se encontraría con que el certificado hacía una función, pero en su interior decía que estaba destinado a otra) y que aun así el certificado siguiese siendo válido.

¿Qué hicieron entonces los atacantes? Lo veremos en la siguiente entrega.

Más información:

MSRC 2718704 and Terminal Services License Certificates

http://rmhrisk.wpengine.com/?p=60

MSRC 2718704 and Nested EKU enforcement

http://rmhrisk.wpengine.com/?p=57

Flame malware collision attack explained

http://blogs.technet.com/b/srd/archive/2012/06/06/more-information-about-the-digital-certificates-used-to-sign-the-flame-malware.aspx

Investigadores consiguen hacer que cualquier certificado SSL parezca válido

http://unaaldia.hispasec.com/2008/12/investigadores-consiguen-hacer-que.html

Sergio de los Santos

ssantos@hispasec.com

Twitter: @ssantosv

El ingenioso método de distribución de TheFlame en redes internas

Según los últimos datos registrados en Virustotal, ya se puede confirmar la existencia de TheFlame desde 2009, además de que otros investigadores se remontan hasta finales de 2008. Veamos su interesante funcionamiento para apoderarse de toda una red interna.

TheFlame utiliza numerosos módulos para llevar a cabo sus diferentes funcionalidades. Una de las formas más ingeniosas es su método de propagación por la red interna. Stuxnet (ya lo apuntamos en una una-al-día anterior) cometió el error de transmitirse indiscriminadamente por USB, lo que aceleró su descubrimiento. El método de ejecución era totalmente nuevo e ingenioso (lo conseguía incluso con el Autorun/Autoplay desactivado), pero indiscriminado. TheFlame juega mejor sus cartas en este sentido.

En resumen, una máquina ya infectada, intercepta las llamadas a Windows Update realizadas por los otros servidores de la red local. Simula un proxy mediante el protocolo estándar WPAD (Web Proxy Autodiscovery Protocol). Este protocolo funciona así en Windows:

Cuando se inicia Internet Explorer, si está configurado el proxy en "Detectar automáticamente" (por defecto) comenzará un proceso que lleva al problema de hombre en el medio, y que ya ha sido explotado anteriormente por otras herramientas antes que por TheFlame.

Si el servidor DHCP de la red interna no proporciona el lugar de este archivo de configuración de proxy wpad.dat, IE intentará acudir wpad.company.com. Si no lo encuentra, usará WINS/NetBIOS para intentar resolver. Esto es lo que permite un ataque MITM, y que el sistema víctima acuda a un servidor incorrecto. NetBIOS es un sistema "punto a punto" y muy sencillo de falsificar. Un equipo solo tiene que realizar una difusión por la red proclamando que tiene un nombre concreto. Esto es lo que hace la máquina ya infectada, consiguiendo engañar al resto en la LAN y que acudan a ella a descargar el la supuesta configuración del proxy. Esta configuración del proxy está modificada para que las máquinas que la apliquen lleguen a un sitio falso de Windows Update.

Habitualmente, aunque se acudiese a un sitio falso de Windows Update a actualizar, la actualización no sería posible porque esta falsificación no tendría los paquetes firmados por Microsoft. Pero como ya sabemos, TheFlame sí los tenía firmados, con lo que se completa el ataque de forma limpia y silenciosa.

Por tanto, los módulos encargados de este proceso, son:

Fuente: http://www.symantec.com/connect/sites/default/files/images/flamer1.png

 

• Snack: Se trata de un sniffer de red local NetBIOS, encargado de capturar las resoluciones a la configuración wpad.dat.
     
• Munch: Alojado también en la misma máquina. Un falso servidor de actualizaciones, que se identifica mediante el nombre NetBIOS “MSHOME-F3BE293C” y que distribuye el malware en forma de un paquete de Windows Update malicioso. El resto de sistemas en la red lo aceptarán porque está firmado, y así consigue pasar totalmente desapercibido.
     
• Gadget: Transmite el malware a las máquinas ya infectadas en la red. Se llama así porque se reparte entre las máquinas en forma de actualización llamada "Allows you to display gadgets on your desktop."

El proceso completo sería el siguiente:

1. Los clientes realizan peticiones WAPD a través de NetBIOS, porque tienen configurado la autoconfiguración del proxy pero no definida en la compañía por DHCP o DNS.
      
2. TheFlame devuelve una configuración WPAD maliciosa. El proxy les engaña y redirige al equipo infectado cuando quieren actualizar.
      
3. Los clientes una vez configurados realizan peticiones Windows Update, pero en realidad se la están haciendo a un servidor en la red interna controlado por TheFlame, con el nombre MSHOME-F3BE293C.
      
4. TheFlame les devuelve un binario firmado dentro de un cab. Tumbler (con nombre de archivo WuSetupV.exe).
      
5. Tumbler descarga e instala TheFlame en los equipos de la red interna.

Así, en una red con un equipo infectado, los sistemas adyacentes totalmente actualizados acababan con el troyano. ¿Cómo era posible? Lo lógico ha sido pensar en una nueva vulnerabilidad... pero no es que aprovechara un 0-day, es que se distribuía como nueva actualización. Ingenioso.

Tenemos así varias capas de ataque. Pero falta aún la pieza que hace se infecte a la primera máquina en la red. Esto podría conseguirse, por ejemplo a través de una vulnerabilidad aún no descubierta en Windows, ingeniería social, etc. No se sabe.

Como vemos, TheFlame tiene especial interés en distribuirse a través de una red interna y una organización. No olvidemos que incluso intentaba contactar con dispositivos bluetooth (móviles, ipads...) cercanos.

Más información:

Stuxnet, Flamer, Flame, Whatever Name: There’s no good malware

http://blog.eset.com/2012/06/03/stuxnet-flamer-flame-whatever-name-there-is-no-good-malware?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+eset%2Fblog+%28ESET+ThreatBlog%29

Spreading the Flame: Skywiper Employs ‘Windows Update’

Http://blogs.mcafee.com/mcafee-labs/spreading-the-flame-skywiper-employs-windows-update/

‘Gadget’ in the middle: Flame malware spreading vector identified

https://www.securelist.com/en/blog/208193558/Gadget_in_the_middle_Flame_malware_spreading_vector_identified

Flame malware used man-in-the-middle attack against Windows Update

http://nakedsecurity.sophos.com/2012/06/04/flame-malware-used-man-in-the-middle-attack-against-windows-update/

W32.Flamer: Microsoft Windows Update Man-in-the-Middle

http://www.symantec.com/connect/blogs/w32flamer-microsoft-windows-update-man-middle

Sergio de los Santos

ssantos@hispasec.com

Twitter: @ssantosv

José Mesa Orihuela

jmesa@hispasec.com

TheFlame, el sueño de todo creador de malware

No por su funcionalidad, sino por el salvoconducto con el que viene acompañado: está firmado por Microsoft. Esto es el sueño de todo creador de malware, por la forma en la que actúan las casas antivirus ante esta garantía, es seguro que se trata de parte de la clave del éxito por la que TheFlame ha permanecido oculto durante al menos 5 años.

Microsoft publicó el domingo una actualización de su repositorio de certificados. Revocaba (marcaba como "no confiables") a tres autoridades de certificación intermedias. La explicación oficial deja algunas lagunas. En algún momento, alguien consiguió manipular un certificado que se usa para licencias de Terminal Server, y firmar código con él. Esto es un grave error por parte de Microsoft. Como explica SecurityByDefault, los certificados tienen unas funciones concretas cuando son creados, y no deben mezclarse.

Microsoft habla también de "older criptography", lo que lleva inmediatamente a pensar en MD5. Al comprobar que los certificados revocados usan ese tipo de hash, más o menos encaja. Si unimos las dos piezas, tenemos que de alguna manera los atacantes han forzado un certificado destinado a Terminal Server y han conseguido firmar código con él, validando hacia arriba la cadena de certificación por ser "débil" la validación de las autoridades certificadoras intermedias. El hecho de que haya revocado toda una autoridad intermedia, en vez de un simple certificado, indica que el problema podría ir más allá. De hecho, lo inquietante del comunicado de Microsoft es:

"The Flame malware used a cryptographic collision attack in combination with the terminal server licensing service certificates to sign code as if it came from Microsoft. However, code-signing without performing a collision is also possible. This is an avenue for compromise that may be used by additional attackers on customers not originally the focus of the Flame malware. In all cases, Windows Update can only be spoofed with an unauthorized certificate combined with a man-in-the-middle attack."

O sea, es posible, sin necesidad de colisión, firmar código con este tipo de certificados que vienen de las licencias de Terminal Server. Por eso preventivamente han revocado las entidades a ese nivel.

El certificado

En concreto hablamos de 1d190facf06e133e8754e564c76c17da8f566fbb, el usado para firmar el componente de TheFlame. Ya todo el mundo sabe que fue firmado el 28 de diciembre de 2010. Pero lo curioso es que en realidad caducó el 19 de febrero de 2012. Esto quiere decir que el certificado ya no era válido de por sí, aunque no estuviera revocado. También alimenta la teoría de que el atacante no pudo elegir este dato. Si yo fuese un atacante y crease un certificado "a la carta" no lo haría caducar en febrero de 2012 sino mucho más adelante. Confirma la teoría de la colisión.

El secreto de su éxito

Stuxnet, también estaba firmado,pero con un certificado de una compañía a la que claramente, le habían robado la clave privada de los certificados. El secreto del éxito de TheFlame para pasar desapercibido, es que está firmado no por cualquier compañía, sino por Microsoft que, como dijo Mikko Hypponen de F-Secure, es "el santo Grial" del malware. Esto quiere decir que los antivirus puede que ni se molestaran en analizarlo o que, por muy extraño que resultara su comportamiento, no se arriesgaran a clasificarlo como malware. Al fin y al cabo, Microsoft nunca jamás firmaría malware... ¿verdad? Todo lo firmado por Microsoft está en listas blancas, casi por definición. Cuando un antivirus ha cometido el enorme error de clasificar un software legítimo (firmado o no) de Microsoft como malware, el sistema puede dejar de funcionar (los componentes críticos de Windows suelen estar firmados)... simplemente no arriesgan. Sería un gran varapalo a la imagen de la compañía si se comete un error de este tipo.

Desinformación

Queríamos también destacar que se está informando de una manera incorrecta sobre la actualización de Microsoft. No corrige ninguna vulnerabilidad, y no podría permitir (o en todo caso sería extremadamente improbable) que se usara para crear phishings. La actualización de Microsoft simplemente deja de confiar en ciertas entidades certificadoras intermedias, y está destinado a prevenir la aparición de más malware firmado por Microsoft.

Más información:

Microsoft certification authority signing certificates added to the Untrusted Certificate Store

http://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store.aspx

Security Advisory 2718704: Update to Phased Mitigation Strategy

http://blogs.technet.com/b/msrc/archive/2012/06/04/security-advisory-2718704-update-to-phased-mitigation-strategy.aspx

Flame y los certificados digitales

http://www.securitybydefault.com/2012/06/flame-y-los-certificados-digitales.html

Microsoft Update and The Nightmare Scenario

http://www.f-secure.com/weblog/archives/00002377.html

Sergio de los Santos

ssantos@hispasec.com

Twitter: @ssantosv

¿Qué nos sorprende del malware?

Hemos podido leer algún artículo en que se califica a TheFlame como una "super-ciber-arma" del futuro. Este llamativo titular no puede más que asustar al lector y prepararlo para un apocalipsis cibernético. Las razones para esta espectacular clasificación son cuando menos desenfocadas. Parece que lo que sorprende del malware, es en realidad lo menos interesante.

"TheFlame es "el espía definitivo", copia datos del disco duro, registra mensajes instantáneos y otras comunicaciones online, registra pulsaciones de teclas, toma capturas de pantalla e incluso enciende el micrófono y graba conversaciones cercanas".

Este párrafo real leído en medios de comunicación, solo recopila características comunes de cualquier malware actual (y de hace años) al alcance de cualquiera. ¿Por qué nos sorprende entonces? ¿Por qué lo destacan los periodistas como hecho diferenciador?

Anclados en el pasado

No hemos asimilado que el malware actual es capaz de esto, aunque lo lleva haciendo varios años. Por ejemplo, Bagle, marcó un punto de inflexión en el mundo del malware: era absolutamente modular (como TheFlame), permitía el robo de información, se difundía a través de varios medios... y nació en 2004. Desde entonces, este modelo no ha parado de evolucionar, hasta el punto de que todas estas funcionalidades se pueden considerar "estándar" para cualquier creador de malware, en forma de kits "Do it yourself", y de módulos programables.

El usuario medio sigue pensando que el malware, en general, solo es capaz de ralentizar el ordenador o, como mucho, mostrar publicidad no deseada. Y sobre todo, que el antivirus (y solo el antivirus) les protegerá. La concienciación en este sentido es muy escasa.

Nos gustan los fuegos artificiales

Sub7 o Back Orifice, eran piezas de software muy sofisticadas en los 90, que permitían un absoluto control del sistema afectado. Sentaron las bases de las RAT (remote administration tool) actuales. Contaban con funcionalidades parecidas a las de TheFlame pero de una forma mucho menos discreta. Sin embargo, todavía hoy, la gente recuerda que su mayor logro era que permitía abrir la bandeja del CDROM remotamente...

El usuario sigue dejándose llevar por las funcionalidades más llamativas, independientemente de su utilidad práctica. Esta es la razón por la que en las series y películas los ordenadores se muestran con gráficos espectaculares, sonidos y efectos especiales en cada movimiento de pantalla, teclado o ratón. Si bien son muy vistosos, en la vida real resultarían insoportables a los cinco minutos de uso. Grabar la conversación, por muy espectacular que pueda parecer (que no lo es), no es útil por ahora para un troyano bancario. Para robar una cuenta no es necesario lucir espectaculares gráficos o emitir soniditos galácticos.

Sin embargo, controlar el DOM del navegador, modificarlo, inyectarse en procesos... todo esto es técnicamente más interesante y peligroso, pero poco llamativo para el usuario de a pie.

¿Nos debe sorprender algo, entonces?

El malware va por delante de las medidas de seguridad, por tanto, deberíamos sorprendernos de las características que convierten al malware en algo tan escurridizo que las elude. Principalmente, lo llamativo del malware actual no es qué puede llegar a hacer, sino el cómo llega a poder hacerlo y mantenerlo. En definitiva, tres puntos clave:

• Cómo consigue infectar los sistemas. Uno de los mayores méritos del malware, verdaderamente sorprendente, son las habilidades técnicas de los exploiters para aprovechar vulnerabilidades, la capacidad de difundir estos exploits, eludir las medidas de protección de los sistemas operativos, y hacerse con el control de la máquina. Esto es un arte complejo, y (no sin razón) es lo más valorado en el mercado negro: conocer una vulnerabilidad es lo que mejor se paga hoy en día, pues permite ejecutar código arbitrario en los sistemas. A partir de ahí todo lo que se consiga, aunque interesante, ya no es "tan complejo". El trabajo duro ha sido conseguido. Una vez con el volante en la mano, conducir el coche no es tan difícil.

•  Cómo consiguen pasar desapercibidos. Los creadores de malware centran sus esfuerzos actuales en la ofuscación de código, empaquetamiento, "técnicas anti debugger"... la inversión se centra en cómo hacer que su código sea más complejo, y su estudio lleve más tiempo. Esto les permite pasar desapercibidos. A veces las técnicas son muy ingeniosas, pero no suelen trascender del laboratorio que las estudia.  

• El uso de la ingeniería social. Debería seguir sorprendiéndonos cómo los atacantes destripan la naturaleza humana y consiguen engañar a los usuarios para que pulsen sobre los enlaces, entreguen sus datos personales o incluso realicen transferencias ficticias en favor del propio atacante... Usando un ejemplo cercano, sería como sorprenderse más de que el "virus de la policía" pueda crear técnicamente una ventana que ocupa toda la pantalla, que del hecho de que haya conseguido una credibilidad en su estafa que consigue un ratio de efectividad tan elevado.

En definitiva, no es que TheFlame sea un malware más sin mérito (en absoluto), sino que llama la atención que, por un lado, no se mencionen las características que realmente lo hacen único  (programación LUA, exploits internos y conexión por bluetooth, recolección de metadatos...). Por otro, que sea necesario un despliegue mediático de este calibre para que al usuario común le llegue el mensaje de unas características que suenan a ciencia ficción... cuando las posee el malware común, el que en estos momentos infecta a millones de máquinas.

Más información:

una-al-dia (29/05/2012) TheFlame: reflexiones sobre otra "ciberarma" descubierta demasiado tarde

http://unaaldia.hispasec.com/2012/05/theflame-reflexiones-sobre-otra.html

Sergio de los Santos

ssantos@hispasec.com

Twitter: @ssantosv