Mostrando entradas con la etiqueta SQL. Mostrar todas las entradas
Mostrando entradas con la etiqueta SQL. Mostrar todas las entradas

lunes, 5 de septiembre de 2016

Inyecciones sin agujas con SQLMap



Buenas a todxs,

Tras unas merecidas vacaciones he decidido volver a escribir una nueva entrada. Esta vez os mostraré la herramienta SQLMap.



SQLMap es una herramienta para la automatización de ataques SQLi, lo cual facilita bastante la tarea del auditor a la hora de buscar este tipo de vulnerabilidades y poder posteriormente explotarlas.
Está desarrollada en python y se encuentra ya instalada en distribuciones como Kali, aunque también podéis descargarla desde https://github.com/sqlmapproject/sqlmap/wiki/Usage. Es bastante completa, pero en esta publicación veremos los aspectos más básicos.

Para usar la herramienta sin necesidad de probar las comodidades que nos ofrece la Guardia Civil o Policía en uno de sus lujosos y bien acondicionados calabozos, probaremos a ejecutarla en DVWA (una plataforma de pruebas ya comentada en anteriores post como: https://fwhibbit.blogspot.com.es/2016/07/poc-evitando-filtros-anti-xss.html y https://fwhibbit.blogspot.com.es/2016/03/guia-metasploitable-2-parte-2.html).

Ejecutamos la plataforma, obtenemos la dirección IP donde se aloja y entramos en ella seleccionando el nivel intermedio.


Nos vamos a la pestaña de "SQL Injection" y probamos a introducir un número cualquiera para comprobar el funcionamiento, a la vez que obtenemos información de la Cookie generada (nos será necesaria más adelante para lanzar SQLMap).

Para obtener la Cookie abrimos el inspector del navegador y accedemos a las pestaña que puede verse en la siguiente imagen:


En este punto (siento por haber ido tan rápido hasta aquí, pero quería centrarme en SQLMap y no en DVWA) empezaremos con lo interesante.

Para ejecutar la herramienta utilizaremos el comando "sqlmap" en una consola con la opción "u" para introducir la URL vulnerable (habiendo introducido antes un ID en la web), con el parámetro "--cookie" insertaremos la sesión que obtuvimos con anterioridad y por último el parámetro "--dbs" para mostrar las bases de datos contenidas en la web.


El resultado será el siguiente:


A partir de aquí, se abrirá ante nosotrxs un abanico de oportunidades para obtener información.

Como era de esperar, podemos indagar un poco más buscando en las tablas de las bases de datos mediante parámetros como "-D" para seleccionar la base de datos y "--tables" para mostrar las tablas contenidas.


Obteniendo como resultado:


Ahora que nos sentimos como auténticos juankers, tras ver lo intuitivo y sencillo que es el manejo de esta herramienta tan potente, el siguiente paso no podría ser otro que mostrar las columnas de una de las tablas obtenidas con los parámetros "-T" para seleccionar la tabla y "--columns" para mostrarlas.


Por cada columna se nos facilitará información sobre el tipo de dato que contiene.


Para sacar la información de las columnas user, first_name, last_name y password, lo haremos de una forma bastante complicada. Sólo algunos juankers como yo podrán hacerlo a través de años de experiencia y estudios... Usando el parámetro "--dump"



Todo esto está muy bien, pero las posibilidades de SQLMap son mas variadas que los gorros de Chema Alonso. ¡No preocuparse primoh!

Algunos parámetros como "--current-user" nos dará información sobre el usuario que se está ejecutando en el servidor.


En nuestro caso, es el usuario "root".


Otra cosa que suele partir ojetes, sería ejecutar el parámetro "--file-read" para leer algo tan interesante como /etc/passwd.



El fichero se guardará en la ruta que nos indica: root/.sqlmap/output/192.168.1.105/files/_etc_passwd


Por último y no menos importante, siempre nos quedará para todo lo demás Mastercard y el parámetro "--help".

No olvidéis que todo esto se trata de información para utilizarla de forma responsable, profesional, académica, blah, blah, blah y debéis NO debéis utilizarlo para liarla pardísima por servidores ajenos sin un permiso correspondiente.



"La revolución empieza por casa SQLMap."

Pablo Lorenzo.



miércoles, 4 de mayo de 2016

La BadStore, explotando vulnerabilidades web sin meterse en lios

Buenas,

Con esa entrada quería comenzar una serie de post's para exponer las principales vulnerabilidades en las principales aplicaciones intencionadamente vulnerables para practicar en un entorno simulado y controlado y olvidarnos de problemas.

En esta entrada quería centrarme en la badstore, una aplicación web para practicar las principales vulnerabilidades web a las que nos podemos enfrentar.

Disponible de una ISO para su descarga en el siguiente enlace:

http://download.vulnhub.com/badstore/BadStore_123s.iso

Para su configuración en virtualbox se crea una máquina virtual y posteriormente se añade la ISO. En configuración -almacenamiento, hay asociar la imagen ISO en el controlador IDE y configurar la máquina virtual para que arranque primero desde el cdrom.


En la opción de red, se configura en la opción de "sólo host anfitrión".




Una vez iniciado, accediendo en el navegador a la url:

http://192.168.XXX.XXX/cgi-bin/badstore.cgi en función de la IP privada de cada uno, se accede a la página principal de la badstore:


Por ejemplo, en la barra de búsqueda se puede inyectar código SQL obteniendo devolviendo todos los artículos de la tienda, esto es, más artículos de los que se ven de primeras.

Introduciendo la consulta SQL: ' or '1'= '1 #


Visitando el libro de visitas, se podría incluir código script para explotar un Cross Site Scripting.



De esta manera introduciendo el típico <script>alert("XSS")</script> se inserta un XSS persistente, tal que al acceder al historial de visitas, se ejecuta dicho código, siendo en este caso un alert.


En la creación de cuentas de usuarios, analizando las peticiones se pueden observar un parámetro en la petición POST muy jugoso, con el nombre de role. Por defecto, viene con valor role=U (user), por lo que si se captura esa petición y se modifica con role=A (admin)



Empleando el plugin TamperData de Firefox o el similar para Google Chrome se puede capturar la petición y modificarla:


De tal manera que se consigue permisos de administrador teniendo acceso al panel de administrador. Bajando en la barra de usuario.


Por último, otra vulnerabilidad se encuentra en las cookies. La vulnerabilidad se basa en que no tienen el atributo HttpOnly. Además como se observan están en texto plano sin cifrar ni hashear.

La vulnerabilidad está basada en inyectar una cookie capturada para conseguir el login de una cuenta de usuario.

Por lo tanto, empleando el XSS documento.cookie se podría reenviar esta traza con esa cookie para loguearse.



Con ese valor de las cookies del carrito de compra:

CartID=1461162597%3A3%3A9010.5%3A1000%3A1004%3A1005

 Se pueden identificar los productos seleccionados para comprar gracias a que están separados por el carácter “%”, siendo sus identificadores:
->1000
->1004
->1005
%3A3 -> Indica el número de produxtos seleccionados
%3A9010.5 -> Indica el precio
%3A1000%3A1004%3A1005 -> Indica el ID de los productos seleccionados

Entonces capturando la cookie y cambiando el valor de la compra:


De tal manera que nos salen gratis =D





La finalidad de este post es totalmente educativo para formar sobre ciberseguridad en un entorno completamente controlado.

La mejor defensa es un buena ataque

Saludos.

NaxHack5

viernes, 11 de marzo de 2016

Hacking con buscadores. Episodio II. El Ataque de Inyecciones SQL.




Saludos hackers!!

Os traigo una nueva entrega de la saga de hacking con buscadores.

En esta PoC, agudizaremos nuestra dork en busca de paneles para que los administradores se logueen.

  • inurl:validacion.asp ext:asp
 Esta dork nos permitirá encontrar paneles de acceso para webs asp.NET:






De acuerdo con mis compañer@s, por motivos de seguridad, voy a evitar poner ciertos paneles, ya que parte de esta PoC, es mostrar los logins, que puede que alguno con simples inyecciones SQL sea vulnerabilizado. Por ese motivo, pondré capturas aleatorias con el fin de evitar el reconocimiento de dichas webs.


En el panel de arriba, puede observarse que con esa simple inyección, es posible poder acceder a la web logueado.

Veremos un error arrojado por una web encontrado con la dork con la que se está trabajando:


Este tipo de error, es una mala configuración en este caso en SQL Server, y que el administrador debería corregir, ya que confirma las inyecciones en esa web.
  • inurl:index.php intitle:Admin * login
 La dork utilizada ahora, nos mostrará páginas index.php en las que se encuentra el panel de acceso para el administrador:



Entraremos en un panel de administración:

 

Indicando esta inyección SQL, nos saldrá un mensaje de error, el error 403, dicho error se produce al entrar en alguna parte en la que no se tiene permiso.




Aunque os preguntaréis que tiene de bueno encontrarnos este error, diré que lo bueno que tiene es que este panel para empezar permite inyecciones SQL. Ya que sino nos arrojaría otro tipo de error, como este usuario o password es incorrecto, o lo lógico, decir que no se permiten el uso de caracteres.


Otro ejemplo:




Y vemos como hemos podido acceder al panel de control del administrador:




  • inurl:index.php intext:welcome admin panel
Vamos a obtener paneles de acceso de administración en PHP, en los que se pueda ver en el texto "welcome admin panel" que esta dork nos proporciona:




Dentro de un panel de acceso, y tras introducir una inyección SQL, podremos ver el siguiente resultado:


Un error fatal, aunque no nos hemos logueado, puede ser aún mucho peor, porque nos está arrojando información sobre tablas, columnas...

Estas pruebas están realizadas con fines educativos, no me hago responsable de lo que personas ajenas realicen.

Google Analytics