Anatomía de una infección por malware

En informática, como en biología, los mejores virus son los mejor adaptados, son aquellos que se aprovechan de su huésped sin que este se percate… hasta que ya es demasiado tarde. También como en biología, no siempre sucede así.

—Iñaki, ¿te pillo por aquí?
—Sí, dime.
—Estoy acojonado. Algo pasa con WordPress. He llamado al hosting porque pensaba que sería problema del mismo, pero lo último que me han dicho es que el archivo “index.php” es 20 veces más grande de lo normal. ¿Es grave?

Inmediatamente le insto a descargar el fichero y a enviármelo, y a machacarlo con uno legítimo de WordPress. En una situación así, no hay tiempo que perder hasta saber a qué nos enfrentamos. Mientras tanto, conviene recabar toda la información posible, buscar más archivos modificados, comprobar la base de datos en busca de usuarios ilegítimos…

El “index.php” de una instalación de WordPress es minúsculo, de menos de 0.5 kB; por tanto 20 veces más, poco más de 8 kB, sigue siendo notablemente pequeño. El archivo que recibo es un “index.php” legítimo de WordPress con una línea (muy larga) añadida al comienzo, y tiene esta pinta:

Una larga cadena de caracteres sin ningún sentido y unas pocas operaciones debajo con menos sentido todavía. Por ahora. Es lo que se llama ofuscación de código, una técnica que tiene dos objetivos principales: por un lado, encubrir el propósito del código, o al menos dificultar su comprensión; por otro lado, dificultar su identificación. Efectivamente, una búsqueda en Google no arroja ningún resultado. Toca, pues, seguir los pasos uno por uno para descifrar el puzle.

El funcionamiento es simple, pero efectivo. El código se asemeja a una matrioska: de un conjunto de caracteres aparentemente aleatorios, se extraen unos cuantos en un orden determinado formando funciones que actúan sobre otras cadenas, que obtienen nuevos chorizos sin sentido y nuevas funciones ilegibles. En el caso que nos ocupa, la ofuscación es particularmente compleja, y me lleva hasta ocho etapas distintas hasta que logro llegar a un fragmento de código que deja de interaccionar consigo mismo y ensambla el verdadero propósito del malware. El corazón del virus tiene nombre: day212().

Esta vez, sí: una búsqueda en Google revela que existe un repositorio donde otros autores realizaron el mismo proceso que yo con otra muestra del virus. Recogen el fragmento original, el código final y detallan el proceso. ¿La fecha? Hace once meses. Lo que podemos deducir del análisis del malware es que, una vez instalado en un servidor legítimo y de una manera bastante sofisticada, inyecta código que obtiene de servidores rusos, con dominios alojados en China, en la web que recibe el usuario final. Pero esto solo es la punta del iceberg.

EITest, el negocio de la distribución de malware

Hace más de dos años, Malwarebytes publicaba una investigación en la que exponía una campaña de distribución de malware a la que apodaron EITest (por uno de los nombres de las variables del código involucrado). Desde entonces, se ha mantenido activa sin que ninguna autoridad competente haya tomado el control sobre los servidores rusos que son centrales a dicha operación. Podemos encontrar nuevos reportes de investigadores de marzo y octubre del pasado año, y ahora nos encontramos ante un nuevo repunte en sus actividades.

EITest se puede definir como una cadena de infección. Se centra en las fases de entrega, explotación de vulnerabilidades e instalación de software malicioso; es decir, su beneficio viene principalmente de la distribución de malware para otros criminales. Todo apunta a que es un negocio rentable y bien engrasado, por su evolución y su perdurabilidad, ya que sus orígenes podrían remontarse a 2011. La muestra de código con la que abríamos este artículo no es otra cosa que la puerta de entrada a esta red de distribución.

Anatomía de una infección

Todo empieza con un servidor web legítimo comprometido por alguna razón. Las posibles vías son múltiples: una instalación desactualizada, un plugin vulnerable, un servidor mal configurado… Una de las principales vías de infección conocidas fue, durante largo tiempo, una vulnerabilidad en MailPoet, un popular plugin para WordPress. No son infrecuentes tampoco los ataques distribuidos contra el panel de control de WordPress y otros gestores de contenidos (este mes precisamente ha habido un incremento que hemos notado en este blog; por eso es tan importante escoger una contraseña robusta y limitar los intentos de acceso fallidos). De una manera u otra, el código que encabeza la entrada o similar acaba en la cabecera de uno o más archivos —se han llegado a reportar cientos en un mismo servidor.

La infección está diseñada para parasitar sin perturbar demasiado al huésped y tiene unos targets muy determinados. Cuando un usuario apunta con su navegador al sitio en cuestión, está despertando a la bestia sin percatarse. El código entra en funcionamiento no sin antes comprobar cuidadosamente una serie de parámetros para asegurarse de que se encuentra ante un usuario legítimo con unas características determinadas. Pasará, por tanto, desapercibido ante bots como el de Google o Microsoft para evitar que el sitio sea identificado como portador de malware. Se ha reportado que EITest busca equipos Windows con Chrome o Internet Explorer como navegador, pero en la muestra analizada he podido comprobar que también buscan navegadores Firefox y sistemas Android.

Una vez confirmado el target, el código contacta con un tercero que será el que devuelva un regalito hecho a la medida del navegador. Parece ser que este servidor malicioso realiza más comprobaciones para asegurar que el contenido va directo a una web infectada, y además evita una misma IP durante un periodo de 24 horas [1]. Como resultado, el usuario carga la web en cuestión… y algo más. Y, de repente…

Chrome no encuentra la fuente

Cuando el cliente es Google Chrome, el usuario verá un pop-up similar al siguiente:

Da la impresión de que el navegador nos insta a descargar un pack de fuentes necesario para visualizar la página actual, pero evidentemente es un truco. De hecho, un navegador jamás necesita descargar fuentes: si no encuentra una, simplemente usa una por defecto. Pulsar ese botón desencadena otra ristra de comprobaciones, de que Chrome es en realidad Chrome, y una petición a otro servidor infectado que inicia la descarga de un archivo: “Chrome_Font.exe” o “Font_Update.exe”.

La manera en que ese archivo es servido, de nuevo para asegurarse de que la petición viene de una víctima legítima, y cómo está protegido para evitar la detección por antivirus son dignos de mención (para los curiosos, todos los detalles se encuentran en [1]). Pero sobra decir que la ejecución del archivo consuma la infección. En el caso particular de Chrome, lo que se distribuye es un virus que se dedica a lanzar múltiples instancias invisibles de Internet Explorer y a navegar autónomamente, todo apunta que para generar dinero a base de clicks fraudulentos en publicidad. Los investigadores han sido capaces de identificar 7000 sitios web infectados y 30000 IPs únicas de usuarios que han descargado el malware diseñado para Chrome [1], principalmente de Estados Unidos, durante las últimas semanas.

¿E Internet Explorer?

Peor lo tienen los usuarios de Internet Explorer —aunque todo apunta a que un Windows 10 bien actualizado mitiga las probabilidades de infección, ya que el principal sistema infectado es Windows 7—. EITest distribuye una amplia variedad de malware sin intervención del usuario utilizando como vía de entrada este navegador. En concreto, la estrategia consiste en inyectar código para descargar un ejecutable de Adobe Flash Player capaz de explotar dos vulnerabilidades diferentes. La única acción necesaria por parte del usuario es visitar la web infectada.

En ese momento, y si la versión de Flash Player es vulnerable, se inyecta un script capaz de “llamar a casa” y descargar y ejecutar cualquier tipo de malware que se provea desde los servidores de EITest: desde ransomware hasta programas capaces de convertir un PC en parte de una red de bots sin levantar las sospechas de su dueño.

El patrón es claro: de día trabajan y de noche descansan cuando el dueño apaga su computadora, ya que las víctimas principales son ordenadores personales, y se aprecia cómo el número de bots ha crecido de forma sostenida durante estas últimas semanas. Para un análisis pormenorizado, por si no me he reiterado lo suficiente todavía, lean [1].

[1] Exposing EITest campaign, Malware Traffic Analysis.

Migración y acceso por HTTPS

Esta última semana hemos completado una migración a un nuevo proveedor de hosting para enchufa2.es y puratura.com, y si todo ha ido tan bien como parece, nadie habrá notado ni notará nada.

No obstante, gracias al nuevo proveedor, DreamHost, ambos dominios cuentan con acceso IPv6 y certificados SSL gratuitos cortesía de Let’s Encrypt, un excelente proyecto colaborativo patrocinado por gigantes como Akamai, Cisco, Google o Facebook, y cuyo objetivo es hacer de las conexiones cifradas algo ubicuo en la WWW. Esto último implica que, al acceder a cualquiera de los dos dominios, seréis automáticamente redirigidos a la versión segura, bajo HTTPS.

De la T4 a Madrid: ¿coche o transporte público? (2)

Gracias al artículo de ayer, De la T4 a Madrid: zonas favorecidas y maltratadas, algunos usuarios de Twitter de Vallecas se dieron cuenta de que los tiempos no eran correctos para su barrio. Efectivamente, Vallecas tiene una geografía peculiar: tiene mucha zona no urbanizada y la zona urbanizada se apelotona en un extremo de su territorio. Por tanto, el método original de calcular un centroide geográfico sobrestima distancia y duración en estos casos, y sobrestima el tiempo más en transporte público que en coche, lógicamente.

Marco volvió a sacar los datos de Google Maps, pero esta vez pasando a Google Maps el nombre del barrio y dejándole decidir cuál es ese destino (que parece que no lo hace mal). En el artículo de ayer ya vimos que la gráfica de tiempo vs. distancia cambiaba, y Vallecas y otros ya no aparecen fuera de la tendencia general. Ya adelantábamos, sin embargo, que la media calculada en De la T4 a Madrid: ¿coche o transporte público? a partir de los datos de los centroides no cambia mucho con esta nueva metodología.

bap4

La diferencia entre la media ponderada de distancia en coche y en transporte público, prácticamente desaparece. No obstante, las medias ponderadas de duración del viaje se mantienen similares: unos 23 minutos en coche por más de 1 hora en transporte público.

De la T4 a Madrid: zonas favorecidas y maltratadas

Por sugerencia de Almudena, continúo el artículo de ayer, De la T4 a Madrid: ¿coche o transporte público?, con otra gráfica interesante: el tiempo de viaje vs. la distancia al aeropuerto. Del mismo modo que en dicho artículo, cada punto representa un barrio, con el tamaño del punto proporcional a su población. Además, las regresiones están ponderadas por población.

bap2

La información que nos proporciona es qué barrios están mejor o peor comunicados. En principio, esperamos que el tiempo aumente proporcionalmente con la distancia, como ocurre en el caso del viaje en coche. En el caso del transporte público, la pendiente es mayor, por lo que un aumento de distancia penaliza más en tiempo, cosa que también es razonable.

Pero además hay puntos concretos que se alejan sustancialmente de la línea por abajo (lo que significa que están especialmente bien comunicados) o por arriba (lo que significa que están especialmente mal comunicados). En la primera categoría, destaca El Plantío, un pequeño barrio del distrito de Moncloa-Aravaca que es el más lejano de Madrid, pero se encuentra especialmente bien comunicado. En la segunda categoría, destacan Fuentelareina, Vicálvaro y Vallecas. El primero tiene poca población, pero Vicálvaro y Vallecas son dos de los barrios más grandes de Madrid, y sin embargo cuentan, comparativamente, con las peores conexiones en transporte público con la terminal T4.

Actualización

Me comentan por Twitter que la conexión desde Vallecas no es tan mala. Efectivamente, una consulta a mano desde zonas razonables del barrio arroja tiempos más bajos. Compruebo en los mapas de Madrid que el territorio del barrio Casco Histórico de Vallecas es bastante amplio, pero la zona urbanizada está apelotonada en el norte y este de la zona.

Dado que los cálculos se han hecho automáticamente a partir del centroide del barrio, esto con toda probabilidad ha hecho que se sobrestimen los tiempos en barrios con una geografía poco homogénea como Vallecas. Las conclusiones, en tales casos, son erróneas.

Una mejora sencilla al método del centroide consistiría en dividir cada barrio en una rejilla de puntos, hacer los cálculos para cada punto y después descartar a partir de cierto umbral. Esto tampoco está exento de problemas, ya que podría haber un barrio con más zona sin urbanizar que urbanizada, por lo que los outliers serían los tiempos reales.

Otra mejora aún más sencilla (y rápida) consiste en dejar a Google Maps decidir dónde está “Casco Histórico de Vallecas” (que parece que no lo hace mal), y así con todos los barrios. Esto es lo que ha hecho Marco rápidamente, me ha pasado los datos y los resultados cambian sustancialmente para la gráfica anterior:

bap3

Buenas noticias: El Plantío ya no aparece como favorecido ni Vallecas como desfavorecido. Fuentelareina y Vicálvaro por su parte sí siguen situándose por encima de la tendencia generalizada. Quedaría actualizar la gráfica del artículo anterior, pero adelanto que las medias para todo Madrid se ven poco afectadas.

De la T4 a Madrid: ¿coche o transporte público?

Kiko Llaneras analizaba ayer en El País el trayecto en coche y transporte público desde el aeropuerto al centro de diversas ciudades españolas en Del aeropuerto al centro: ¿en coche o transporte público? El resultado es el esperado, es decir, que en coche se tarda menos en general, pero con la salvedad de dos casos: Valencia y la terminal T4 de Madrid, donde el tiempo promedio es similar en transporte público.

En concreto, para la T4, se obtienen unos 21 y 26 minutos de trayecto para coche y transporte público respectivamente. Este resultado choca frontalmente con la experiencia cotidiana, pero hay que tener en cuenta que el dato está calculado para el trayecto hasta la parada de transporte público más cercana al ayuntamiento. En definitiva, no parece un dato muy representativo del madrileño medio y ni siquiera del turista medio que vaya hacia su hotel. De hecho, en el artículo añaden que

Mi compañero Marco Gramaglia ha hecho un análisis más extenso del asunto para la T4 de Madrid con el objetivo de obtener una media más representativa. Para ello, ha calculado la distancia y el tiempo, en coche y transporte público, desde la terminal T4 hasta cada uno de los barrios de Madrid. Después, cada barrio contribuye a la media global de manera ponderada por población:

Yo he tomado sus datos y he obtenido la siguiente figura que desglosa distancia y duración del viaje, en coche y transporte público, para cada barrio. El tamaño de los puntos es proporcional a la población del barrio y las líneas verticales marcan las medias ponderadas, cuyos valores exactos también aparecen sobreimpresos.

BAP

Como puede apreciarse en la gráfica de la derecha, la duración del viaje en coche tiene una varianza pequeña. Es decir, vayas a donde vayas dentro de Madrid, en coche tardarás un tiempo cercano a la media ponderada, que es de unos 23 minutos. Por otro lado, la duración del viaje en transporte público varía mucho en función del barrio de destino, cuya media ponderada es de más de 1 hora.

Hay pocos barrios con una media en transporte público cercana a la media ponderada global en coche. Uno de ellos, precisamente, es el barrio de Justicia, colindante con el Ayuntamiento de Madrid, de ahí que el dato obtenido por Kiko Llaneras para el caso de la T4 resulte poco representativo. Probablemente el análisis de las otras ciudades adolecerá de un problema similar, aunque lógicamente la desviación será menor en ciudades más pequeñas.

Metodología

Los diferentes barrios y sus coordenadas se han descargado de aquí; las cifras de población, de aquí. A partir de estos datos, se ha calculado el centroide de cada barrio y, con ayuda de Google Maps, se han obtenido las distancias y duraciones de trayecto desde la terminal T4 hasta dichos centroides, tanto en coche como en transporte público, para hoy 2 de agosto a las 17 horas.

Se podría refinar el análisis obteniendo los datos para diferentes días y diferentes horas, pero la diferencia promedio de duración obtenida entre ambos medios de transporte es lo suficientemente grande como para aceptar que las conclusiones no variarían.