Malware que instala certificados raíz en Windows y Firefox automáticamente

El malware y el mundo de los certificados parecen condenados a entenderse, y cada vez más. Aunque Avira ya ha hablado sobre una muestra parecida hace unos días, en ElevenPaths hemos encontrado otra evolución que le da una pequeña vuelta de tuerca a esta técnica de inyectar certificados raíz en el sistema. Veremos aquí en qué consiste el detalle y repasamos algunos incidentes anteriores.

Los creadores de malware se están viendo obligados a utilizar técnicas ingeniosas para utilizar inteligentemente la oportunidad que brindan los certificados en todas sus dimensiones y hacer gala así de una legitimidad de la que carecen. Una de las muestras recientemente detectadas por Avira, instala un certificado raíz legítimo de COMODO en el sistema, pidiendo al usuario que sea él mismo quien lo valide. Entendemos que se trata de una primera fase de la infección en la que, una vez con el certificado en el sistema, el malware lo redirigirá a páginas falsas firmadas con certificados hoja que se verán perfectamente legítimas en el navegador de la víctima.

Sin embargo, en ElevenPaths hemos observado una pequeña evolución en la que es el propio malware el que valida la instalación del certificado. O sea, se encarga de hacer desaparecer la ventana de seguridad, pulsando él mismo sobre “Sí” para que la víctima no perciba la instalación.
Además, este malware también inyecta un certificado raíz no solo en el sistema, sino también en el TrustStore de Firefox (que no utiliza el de Windows). Por tanto, use el navegador que use, la víctima confiará en un certificado de un tercero. Esto permitirá que cuando visite un dominio real de su banco (pero alojado en un servidor falso) todo parezca perfectamente legal a ojos del navegador y del sistema.

Mostramos aquí un pequeño vídeo explicativo del funcionamiento en el que se observa la ventana de instalación siendo eliminada rápidamente por el propio malware. En un  sistema “normal” sin demasiada carga de trabajo, la ventana no llegaría ni a percibirse, puesto que sería instantáneamente interceptada por el malware.

Esto es lo que debería ver el usuario, pero que el malware intenta evitar programando un clic rápido sobre el botón de aceptar

Este tipo de ataque nos hace recordar incidentes similares en los que se ven involucrados certificados raíz instalados de serie, como los casos en portátiles Lenovo (Superfish) o eDellRoot. En esos casos, se hizo pública la clave privada, pero en este, la clave pertenece al atacante que además controla el sistema, por lo que el ataque es “personalizado” a la víctima y simplifica mucho la programación. Por ejemplo, al contrario que los míticos troyanos bancarios rusos tipo Zeus, aquí no debe acudir a técnicas de inyección en el navegador, sino que basta con montar un servidor falso para que la página troyanizada se vea bastante legítima. Sin resultar técnicamente espectacular, es una manera muy ingeniosa de mantener la simplicidad y la eficacia.
Por lo demás, el malware resulta sencillo en cierta manera, y es bastante detectado por los antivirus. Puede tratarse de una especie de prueba de concepto o tanteo. Eso sí, el certificado no ha sido revocado aún y parece que está circulando desde hace ya cuatro meses. Algo muy curioso que realiza este malware es el uso de Powershell en general además de eliminar el proxy de Firefox. El registro que almacena el propio malware es bastante autoexplicativo. Instala un certificado y elimina las referencias a un potencial proxy en Firefox, lo que puede significar que el atacante no quiere que nada interfiera en la comunicación. Estas son algunas líneas interesantes.

[Firefox::InstallCert(): Init OK]:[firefox]:[92]
[Firefox::InstallCert(): Init find OK]:[firefox]:[98]
[Firefox::InstallCert(): Profile: '%APPDATA%MozillaFirefoxProfiles5
[Firefox::InstallCert(): Init cert OK]:[firefox]:[118]
[Firefox::InstallCert(): CERT_GetDefaultCertDB OK]:[firefox]:[131]
[Firefox::InstallCert(): CERT_ChangeCertTrust OK]:[firefox]:[139]
[Firefox::InstallCert(): Add cert OK]:[firefox]:[142]
[Firefox::InstallCert(): Find OK]:[firefox]:[144]
[Firefox::InstallCert(): Free OK]:[firefox]:[147]
[Cert was added to Firefox!]:[core]:[209]
Remove 'network.proxy.type' from '%APPDATA%MozillaFirefoxProfiles5prefs.js']
Remove 'network.proxy.autoconfig_url' from '%APPDATA%MozillaFirefoxProfiles5prefs.js']
[Pac was added to Firefox!]:[core]:[218] 

Certificado raíz del atacante, que intenta simular venir de Thawte

El certificado en sí está firmado para poder hacer virtualmente cualquier cosa, pero entendemos que la intención del atacante es montar servidores maliciosos con certificados falsos (pero dominios verdaderos), creados para que validen contra esa CA que acaba de instalar en su víctima. El crimen perfecto.
Es interesante comprobar cómo el malware aprovecha un viejo truco de pulsar las teclas por el propio usuario. Esto es algo ya resuelto en UAC por ejemplo con la atenuación de escritorio… pero no se hace con los certificados. Microsoft podría tomar nota y atenuar el escritorio cuando se va a aprobar la instalación de un certificado importante.

Más detalles sobre el certificado que instala el malware

Certificados: Authenticode y TLS

Las razones por las que el malware necesita utilizar certificados son varias. Además desde dos perspectivas diferentes. Intentemos esquematizar las ideas más importantes, de por qué son dos mundos relacionados.

• Desde la perspectiva de Authenticode (código ejecutable firmado en Windows), la necesidad es clara. Hace ya algunos años que Windows obliga a que los drivers en 64 bits se encuentren firmados para poder ejecutarse. Esto hace que quien quiera instalar un rootkit necesite comprar un certificado específico y garantizar en cierta manera su identidad (falsa o no) o robar algún certificado de un tercero. De hecho, desde hace tiempo, el malware firmado en este sentido va en aumento.
• Los atacantes que optan por robar certificados de terceros, han visto tal nicho en este negocio, que ya cuentan con un servicio de “certificados robados” que pueden comprar. Hasta ahora, habíamos visto certificados robados y usados para ataques ad-hoc.
• El hecho de firmar un código, hoy por hoy, tiene cierto peso para los antivirus. Si hablamos de heurística, automáticamente un archivo firmado es menos sospechoso. También, los atacantes que se mueven en la zona gris (adware en general) utilizan certificados para firmar su código y darle un empaque del que carecen, pero que les cubre en cierta manera legalmente y les acerca un poco “más a la luz“.
• Desde la perspectiva de los certificados TLS, la relación con el malware es más indirecta, pero interesante, como muestra este mismo ejemplo, del que podemos sacar varias conclusiones: Podríamos estar ante una nueve tendencia interesante en la que el malware bancario intenta abusar de forma sencilla de los certificados raíz. Si bien esta muestra no es especialmente reciente, es pronto para saber la relevancia del alcance. Además, se podría reclamar a Microsoft, como medida de precaución, que exija la elevación con atenuación de escritorio para instalar certificados raíz. Firefox, por su parte, ni siquiera emite una advertencia de que se va instalar el certificado.
• También desde el punto de vista de TLS, el malware bancario sí que se ha dedicado desde hace mucho a robar certificados cliente instalados en el navegador de la víctima para autenticarse.

Otras aproximaciones a los certificados

Otra aproximación curiosa que realizaba un malware no hace mucho, era la de bloquear a los antivirus aprovechando de nuevo el “TrustStore” de Windows y la firma electrónica de los binarios de los antivirus. En resumen, instalaba como “no confiables” los certificados de varios motores  y así conseguía que dejasen de funcionar. Algo de lo más curioso, y que demostraba de una forma ingeniosa cómo eliminar elegantemente de la ecuación al enemigo natural.