Badstore: Seguridad sin meterse en líos

  • 0

Badstore: Seguridad sin meterse en líos

Casi siempre que alguien empieza a comprobar la seguridad en aplicaciones web, comienza con un navegador colando una comilla (‘) en alguna variable para comprobar si salta algún error, no es una práctica muy ética ir inyectando a diestro y siniestro y menos si lo que buscamos es formarnos sobre cómo funcionan los ataques a páginas web. Para ello necesitamos tener nuestro entorno de pruebas en una red local donde podamos hacer todas las perrerías sin tener k preocuparnos por la ley.

badstoreLogo1

Badstore es una imagen ISO de unos 12Mb, incluye una distribución live de Trinux que arranca un servidor web con una página que imita a una tienda, pero con un montón de vulnerabilidades. Para ejecutarla sólo necesitamos una máquina virtual con 64Mb de RAM. Para ello creamos una máquina virtual con cualquier software de virtualización como VM-Ware o VirtualBox. Antes de arrancar la máquina nos aseguramos que la interfaz de red está en modo puente (Máquina>>Configuración>>Red).

Captura de pantalla de 2014-02-24 18:40:59

Una vez hecho esto iniciamos la máquina virtual, Cuando arranquemos estará un rato cargando y nos pedirá que presionemos “enter” para acceder a la consola. Una vez dentro, podemos teclear “help | more” para encontrar un listado de todos los comandos disponibles.

Captura de pantalla de 2014-01-07 10:20:14

Si tenemos un servidor DHCP en la red sólo tendremos que teclear “ifconfig” para averiguar qué dirección ip nos ha asignado. En cambio, si no nos asigna la direccion IP automáticamente, podremos asignarla nosotros con este comando:

ifconfig -a 192.168.x.x

Algunas de las vulnerabilidades que vas a encontrar son:

  • SQLi (SQL Injection)
  • XSS (Cross Site Scripting)
  • Modificación de cookies
  • Denegación de servicio

Poniéndonos a investigar un poco NMap nos devuelve esta lista de puertos disponibles en nuestra máquina virtual.

Not shown: 997 closed ports
PORT     STATE SERVICE  VERSION
80/tcp   open  http     Apache httpd 1.3.28 ((Unix) mod_ssl/2.8.15 OpenSSL/0.9.7c)
| robots.txt: has 5 disallowed entries 
|_/cgi-bin /scanbot /backup /supplier /upload
|_html-title: Welcome to BadStore.net v1.2.3s
443/tcp  open  ssl/http Apache httpd 1.3.28 ((Unix) mod_ssl/2.8.15 OpenSSL/0.9.7c)
|_html-title: Welcome to BadStore.net v1.2.3s
| robots.txt: has 5 disallowed entries 
|_/cgi-bin /scanbot /backup /supplier /upload
|_sslv2: server still supports SSLv2
3306/tcp open  mysql    MySQL 4.1.7-standard
| mysql-info: Protocol: 10
| Version: 4.1.7-standard
| Thread ID: 5
| Some Capabilities: Connect with DB, Compress, Secure Connection

En el reporte podemos comprobar como aparte de los dos puertos web disponibles (80 y 445 para SSL) tenemos el puerto 3306 abierto con MySQL. La primera vulnerabilidad que vemos llega al probar a entrar en el mysql con el usuario administrador (en este caso no tiene password), así por tanto si ejecutamos el comando:

mysql -u root -h 192.168.1.X

una vez dentro podremos ejecutar “SHOW databases;” y seguidamente conectarnos a la base de datos con “CONNECT badstoredb;”

Captura de pantalla de 2014-02-24 18:17:21

Una vez conectados podemos investigar un poco y ver de qué forma está implementada la seguridad de las contraseñas de los usuarios. En este caso vemos que las contraseñas están cifradas en md5 (un campo de pruebas perfecto para probar software como John the ripper o Hashcat) y en algún caso el campo de password está en NULL.

Captura de pantalla de 2014-02-24 18:19:39

Ahora podemos introducir en nuestro navegador del ordenador anfitrión http://ip-del-server y accederemos a nuestro entorno de pruebas para poder realizar cualquier fechoría sin tener que preocuparnos si nos saltamos la ley o no. Una vez accedemos a través del navegador nos encontramos en la página principal.

Captura de pantalla de 2014-02-24 18:45:16

La primera vulnerabilidad que vamos a explotar se encuentra detrás del vínculo “Sigin in our guestbook”, se nos abre un libro de visitas en el cuál podemos realizar ataques XSS de tipo persistente. XSS es un acrónimo de Cross Site Scripting (solo que en vez de C pusieron X para que no se confundiera con CSS),  coexisten dos tipos de ataques XSS, directo e indirecto, el objetivo de los ataques es ejecutar codigo javascript o similar (jquery, ajax…) en el navegador del cliente, con el objetivo de extraer la información de la sesión guardada en el navegador para poder acceder al recurso que sea remotamente. En este caso, podemos escribir código javascript en el formulario, de tal forma que todo usuario que acceda a esa página ejecutará el código que hemos introducido.

En el siguiente post de badstore seguiremos dándole caña, un saludo!!

 

 


Leave a Reply