En esta sección veremos la vulnerabilidad de divulgación de información
Last updated
En esta sección aprendremos sobre como tratar con las vulnerabilidades de divulgación de información, como encontrarlas, atacarlas y sobre todo como evitar tener estas vulns dentro de un sitio web.
Es por este simple hecho que aprender a evaluar y encontrar este tipo de vulnerabilidades, puede ayudar en gran manera en la eficiencia de las pruebas de penetración que uno tome (pentesting) hacía una organización, además de que permite encontrar también por supuesto errores de alta gravedad adicionales.
⚠️ Si por ejm: una disclosure information me revela que la pagina a la cual le estoy haciendo pruebas, sostiene una gran relación con una BD relacional especificamente MySQL (WOW) pues eso ya es mucho, con eso podría empezar yo a encontrar posibles vectores de ataques en relación al tipo de BD que ya sé que tienen.
Bueno la divulgación de información aunque ya sé que es, vamos a repasarla:
La divulgación de información es cuando un usuario interactúa con un sitio web y de forma involuntaria y no esperada el sitio web revela información que se supone no debería ser revelada, puede ir desde información poco precisa y muy minima hasta información realmente grave que puede dar paso a un ataque más complejo, tenemos que tener en cuenta con esto entonces que dependiendo del contexto es que el tipo de información será revelada, pero dentro del tipo de información que se puede divulgar de forma involuntaría, tenemos:
Datos sobre otros usuarios, como nombres de usuario o información financiera.
Datos comerciales o empresariales sensibles
Detalles técnicos sobre el sitio web y su infraestructura.
Como lo había mencionado anteriormente, la divulgación de información que uno como pentester o un atacante encuentre en un sitio web por lo general puede ser de tipo limitado (aunque hay excepciones) y el hecho de que sea limitado no significia que no sea grave ya que esa información aunque es limitada puede dar gran paso a un ataque muchisimo más elaborado por parte del atacante ya que se tiene información vital como base para crear un ataque especifico con base a la información revelada por parte del sitio web.
Algunos ejemplos básicos de divulgación de información son los siguientes:
Revelar los nombres de directorios ocultos, su estructura y su contenido a través de un robots.txtlistado de archivos o directorios
Proporcionar acceso a archivos de código fuente a través de copias de seguridad temporales (con esto podemos hacer analisis de código para ataques posteriores.)
Mencionar explícitamente nombres de tablas o columnas de bases de datos en mensajes de error (BD especificas)
Exponer innecesariamente información altamente confidencial, como datos de tarjetas de crédito.
Claves API codificadas, direcciones IP, credenciales de bases de datos, etc. en el código fuente
Insinuar la existencia o ausencia de recursos, nombres de usuario, etc. a través de diferencias sutiles en el comportamiento de la aplicación. (aqui una tilde o un “.” puede significarlo todo.)
En esta sección aprenderemos a encontrar y explotar la vulnerabilidad de disclosure information, aprenderemos a llevarla, metodos y procesos a seguir con herramientas o tecnicas especificas, también tendremos en cuenta cuales son los puntos más comunes para encontrar estas vulns.
En terminos generales es importante para nosotros no tener una visión del tipo “TUNEL” o de caballo con los miradores al frente ya que realmente la divulgación de información se puede encontrar en cualquier punto o lugar de la aplicación así que cuando menos lo pensemos testeando algo completamente opuesto, pues bueno ahi pueda que encontremos la información que buscamos, así que en estos casos es importante tener una visión bastante amplia y sobre todo contar con la habilidad de reconocer información interesante cuando y donde quiera que uno la encuentre, para usarla más adelante o ahi mismo, pero eso es ESENCIAL.
Veamos unos ejemplos de tecnicas y herramientas de alto nivel para ayudarnos a encontrar e identificar vulnerabilidades “disclosure information” durante nuestras pruebas.
El fuzzing se trata de una prueba repetitiva de un proceso especifico en el que se ingresan varios tipos de datos (Invalidos porsupuesto) con un mismo proposito en común: “Encontrar inconsistencias o irregularidades” con el fin de encontrar vulnerabilidades, claramente de la mano de prestar atención a los efectos que tienen dichos datos sobre el objetivo o aplicación.
Esto es algo que ya hemos probado varias veces desde la herramienta de burpsuite llamada “Intruder”, cuando intentabamos algo al principio de nuestros estudios el cual era ingresar diversos parametros de passwords para el user carlos, y le pasabamos como lista de palabras para el password una lista de diccionario que la misma pagina de portswigger nos daba, así era como llevabamos a cabo un ataque de fuzzing.
La verdad es que hay diversos tipos de fuzzing entre los más presentes están:
Fuzzing a sistemas operativos (IOS): Aunque parezca poco creible y certero, el fuzzing al sistema operativo IOS ha resultado ser bastante efectivo, ya que probando todas las posibles entradas que sostiene y tiene el sistema operativo se han podido llegar a encontrar diferentes inconsistencias.
Fuzzing a aplicaciones Web: Este fuzzing es el que yo estoy aprendiendo jajs, pero si, también se puede automatizar el fuzzing hacia las aplicaciones web, un caso particular ocurrió hace ya unos años cuando se encontró una vulnerabilidad bastante grave a punta de fuzzing a la aplicación web de Whatsapp, donde casi quedan en peligro los datos de los usuarios.
Ahora bien el fuzzing en aplicaciones web no encuentra directamente el error, además de que se tiende a confundir con el web fuzzer que lo que hace es rastrear que direcciones URL de un dominio están activas, para ver si hay contenido vulnerable disponible en ellas.
Y en el caso de encontrarse uno de estos archivos vulnerables en una de estas URLS de ese dominio, algunos programas de bugbounty suelen recompensarlos.
Dirb es un web fuzzer que viene instalado en Kali Linux. Este programa prueba direcciones URL aleatorias para probar si están activas en un dominio web. Al encontrar rutas activas, puedes revisar su contenido y encontrar si allí hay archivos vulnerables, como el código fuente.
Ffuf es una alternativa que se está popularizando y se está prefiriendo por encima de Dirb. También es un web fuzzer, pero su principal ventaja es que está escrito en el lenguaje de programación Go. Dirb, por estar escrito en Python, es un programa mucho más lento.
Así que vamos a probar instalando Ffuf en macOS “Big Sur”.
Muy simple, con Brew Install salió.
⚠️ No Confundir con gobuster o dirbuster, aunque estos también enumeran directorios estas herramientas también pueden hacer peticiones, entre otras cosas lo que las diferencia claramente de un web Fuzzer, son herramientas con más abanico de opciones que solo Fuzzear, por ello es bueno tener una herramienta especifica para cada cosa.
Burp proporciona varias herramientas de participación que puede utilizar para encontrar información interesante en el sitio web de destino más fácilmente. Puede acceder a las herramientas de participación desde el menú contextual: simplemente haga clic derecho en cualquier mensaje HTTP, entrada de Burp Proxy o elemento en el mapa del sitio y vaya a "Herramientas de participación".
Son las herramientas que conocemos de Target> y todas las que podemos ver de ahí.
Una de las que yo llegué a utilizar usandola para poder encontrar el subdirectorio admin/ fue la de “Discover content” o “Descubriendo contenido”
Descubre contenido
Puede utilizar esta herramienta para identificar contenido y funcionalidad adicionales que no están vinculados desde el contenido visible del sitio web.
La divulgación de información puede ocurirr en una variedad de contextos así que el poder encontrarlos varía mucho de donde y como sea la aplicación, ahora bien hay fuentes comunes en las que uno puede aplicar para “X” aplicación para ver si se encuentra Disclosure information, por ejm:
Entonces con esto muchos sitios web proporcionan el archivo robots.txt para ayudar a los rastreadores a navegar por su sitio, entre otras cosas esos archivos suelen enumerar directorios especificos que los rastreadores deberían omitir, por ejemplo, porque pueden contener informacion confidencial y ahí es donde la embarran porque le dan información extra a un atacante que sabe de la existencia de este archivo plano y se encuentra directorios con info confidencial, pues sería perfecto para los fines de un atacante.
Como estos archivos no suelen estar vinculados desde el sitio web, es posible que no aparezcan inmediatamente en el mapa del sitio de Burp. Sin embargo, vale la pena intentar navegar hacia /robots.txto /sitemap.xmlmanualmente para ver si encuentra algo útil.
Suele suceder que los servidores web se pueden configurar para enumerar automaticamente todo el contenido de los directorios que no tienen una pagina de indice presente, y esto supone un gran problema en si ya que permite a un atacante el poder identificar rapidamente los recursos de un posible objetivo de ataque con su directorio completo, esto facilita el poder analizar y explotar estos recursos de una forma facil, sin necesidad de acudir a fuzzing o algo por el estilo.
Imagen para entender mejor:
Los listados de directorios en si nos presentan una vulnerabilidad eso toca tenerlo presente, pero, el hecho de que entre ese listado de directorios no llegase a haber un control de acceso adecuado, si supondría un problema porque se podría buscar filtrando la busqueda para encontrar archivos o información especifica que sea confidencial. Y eso efectivamente si sería grave.
Durante el desarrollo, a veces se agregan comentarios HTML en línea al marcado. Estos comentarios normalmente se eliminan antes de implementar los cambios en el entorno de producción. Sin embargo, a veces los comentarios pueden olvidarse, pasarse por alto o incluso dejarse deliberadamente porque alguien no era plenamente consciente de las implicaciones de seguridad. Aunque estos comentarios no son visibles en la página renderizada, se puede acceder fácilmente a ellos utilizando Burp o incluso las herramientas de desarrollo integradas del navegador.
Estos comentarios pueden dar información util al atacante, pueden ser desde directorios ocultos que no se han tomado en cuenta y están en la aplicación o pero aún pueden dar indicios de la logica de la aplicación, que como sabemos el saber como es la logica de la aplicación nos puede dar bases para ataques del tipo Business Logic Vulnerabilities
Una de las causas mas comunes de divulgación de información son los mensajes de error que aunque no parezcan tan importantes resultan muy utiles cuando están presente debido a la falta de robustez en una aplicación, estos errores detallan todo tipo de información que puede llegar a ser crucial el que esté en manos equivocadas, en este por un atacante o pentester durante una auditoría, por ende es muy importante prestar vital atención a los mensajes de error y tomar detalle de los mensajes en caso tal de que fuesen diferentes.
Los mensajes de errores nos pueden revelar muchos tipos de datos a tener en cuenta, por ejm:
El tipo de datos que se debería ingresar en un input de la aplicación, esto nos ahorraría mucho tiempo intentando identificar el tipo de dato correcto para crear cargas utiles para el tipo de dato en concreto y no lanzando cargas utiles (payloads) a la loca con tipos de datos que no harán ningún cambio.
Los mensajes de error tambien pueden proporcionar información sobre la tecnología de la aplicación, entre las cuales tenemos, se puede revelar el nombre del motor de plantilla que usa la aplicación (el motor de plantilla es el que conecta la BD con un template de estructural para conectar la información de la BD y mostrarla visualmente en una pagina web como documentos web) (adjunto imagen)
Pero claro esto no sería lo unico, tambien se podría revelar información sobre la BD y su versión, o el tipo de BD que existe en la Aplicación si es relacional o No relacional, y esto puede ser muy util porque si conocemos el numero de versión de la BD facilmente podemos estar buscandole un Xploit que ya exista en la Web para poder usarlo y explotar la aplicación al 💯
⚠️ Por ejemplo: si una divulgación de información revela que la página web que estoy probando tiene una fuerte relación con una base de datos relacional, específicamente MySQL (¡guau!), eso es un gran hallazgo. Con esa información, puedo comenzar a buscar posibles vectores de ataque relacionados con el tipo de base de datos que sé que tienen.
Estos tipos de datos que se muestran para fines de depuración en un proyecto en pleno desarrollo la verdad es que son de mucha ayuda porque ayuda a entender y tomar en cuenta los aspectos a ir mejorando de una aplicación, el problema es que definitivamente no es para nada una buena idea si esta en manos de un atacante porque de la misma manera es igual de bueno pero con fines totalmente negativos y es precisamente lo que no necesitamos.
Estos datos de depuración suelen aislarse en vistas separadas de una aplicación como registros almacenados que se van mostrando de lo que se tiene de la aplicación ahora bien, esto viene a ser de mucha utilidad durante la fase de depuración como decía anteriormente pero en un entorno de producción se torna bastante peligroso.
Entre los datos que se pueden lograr recopilar de depuración, tenemos algunos los cuales son:
Valores para variables clave de sesión que se pueden manipular mediante la entrada del usuario. (Users de pruebas durante el desarrollo)
Nombres de host y credenciales para componentes de Backend. (El HOST que se usaba mientras se desarrollaba la aplicación, credenciales del backend para poder hacer peticiones, solicitudes, cosas que ya he vivido en desarrollo).
Nombres de archivos y directorios en el servidor.
Claves utilizadas para cifrar los datos transmitidos a través del cliente: Esta si esta cagadisima, si tenemos la clave para cifrar la transmisión de datos ya practicamente no tendríamos nada que no pudiesemos obtener, todo lo tenemos.
A veces la informacion de depuracion se encuentra en un archivo por a parte asi que si el atacante o uno puede lograr llegar hasta el archivo podriamos encontrar infromacion vital como el funcionamiento o logica de como se lleva la aplicacion, o que datos y tipos de datos podemos tomar para interactuar con la aplicación y de esa forma ver como podemos involucrar datos maliciosos que afecten el funcionamiento del sistema.
Vamos a ver la divulgación de información en un laboratorio más especificamente.
Por lo general las cuentas de usuario mantienen datos que son confidenciales, como por ejm: Correo electronico asociado a la cuenta, username, password, Clave API, Datos guardados de tipo Bancarios, etc… Y es por ello que debe ser importante mantener una seguridad robusta ante la cuenta de usuario de X usuario, ya que si se tiene una logica débil se podrían atacar huecos que harían que un atacante pudiese acceder a información confidencial a la que se supone no debería acceder, por ejm: “Si se tiene la debil fortaleza logica de mantener a un usuario con una su propia cuenta de usuario pero puede acceder a información de otras cuentas estando en su propia cuenta”.
Consideremos que un sitio web toma en cuenta que tipo de user está en la aplicación dependiendo del parametro de user=? que se le pasé:
GET /user/personal-info?user=carlos
La mayoría de sitios web se suponen mantendrían una seguridad responsable que no dejase obtener información de otras cuentas de usuario con tan solo cambiar el parametro de User en la URL, sin embargo habrán paginas que no mantengan como fortaleza la logica de esta forma, y puede que la tengan implementada parcialmente, por ejm:
Si se puede cambiar el parametro de username y no cambia completamente a otra cuenta de user sin embargo el correo electronico se actualiza al nuevo user que está en el parametro, esto sucede porque basicamente la aplicación valida ciertas componentes pero no termina de validar lo que es el correo de user así que no valida el parametro de user asociado con un directo y unico correo electronico.
Estás vulnerabilidades las veremos con más detalle cuando cubramos lo que son las vulnerabilidades de control de acceso. IDOR.
La divulgación de codigo fuente a través de archivos de respaldo ha llegado a pasar sin embargo es muy poco probable, pero cuando esto llega a pasar pueden ocurrir cosas terribles debido a que dentro del codigo fuente la mayoria de veces los desarrolladores pueden dejar comentados datos confidenciales codificados que pueden ser de una importante relevancia, por ejm:
Credenciales para solicitudes o peticiones nivel de Backend.
Claves API
Nombres de usuarios candidatos de prueba
Hostnames
BD, también
Variables de entorno importantes. SECRET_KEY for Example.
¿Porque digo que puede ser dificil obtener directamente el codigo fuente como texto? Porque las aplicaciones normalmente se ejecutan como codigo, el servidor pasa el codigo al cliente o aplicación, pero no como un archivo de texto sino como el codigo a compilar, como una especie de ejecutable, así maneja la logica por ejm: .php y bueno por ello puede ser dificil obtener literalmente el codigo fuente como un texto.
Aunque en algunas situaciones podríamos llegar a engañar al sitio web para que nos devuelva el contenido del archivo osea el codigo fuente como tal, en este caso con ayuda de los Archivos temporales. → Estos archivos son los que se crean en segundo plano cuando el archivo original está siendo modificado por el editor de texto que es el que los genera. en pocas palabras obteniendo nosotros los archivos temporales, estos archivos se nombran casi de la misma manera que el original con la leve diferencia de que estos mantienen una ~ o tilde en el nombre del archivo o agregando una extensión de archivo diferente.
Así que algunas veces podemos solicitar archivos con extension de respaldo y poder obtener el codigo fuente para poder leerlo. (Contenido del archivo)
Perfeccionar nuestro ataque con algo muchisimo más grave, por que tenemos en nuestras manos las tecnologías de la aplicación, el funcionamiento logico de la aplicación, etc.
Xploits y más xploits.
Deserializacion insegura es una de esas vulnerabilidades que podríamos explotar conociendo el codigo fuente.
En fin vamos a ver un lab de practica para terminar de afianzar este conocimiento.
En ocasiones, los sitios web suelen ser vulnerables como resultado de una configuración incorrecta que muchas veces no es propia ni del mismo sitio sino de las tecnologias usadas por terceros.
O bien puede ser también que se dejen cosas activadas en el entorno de produccion que se suponía solo debían ser activadas en el entorno de depuración (Durante la fase de desarrollo).
Ahora bien todas estas malas configuraciones de un sitio web son las que llevan a que se generen accidentalmente divulgaciones de información que pueden llegar a ser graves dependiendo del nivel de la información divulgada.
Uno de los ejemplos más claros es el punto 2. que trata sobre algunos elementos que se olvidan desactivar cuando se pasa a la fase de producción, en este caso por ejm: El TRACE que sabemos es un metodo HTTP para hacer un eco en la dirección del solicitante cuando ya ha recibido respuesta de su solicitud esto con fines de desarrollo “Depuración”, ahora bien el peligro viene cuando esto no se desactiva en producción porque aunque parezca inofensivo puede traer consecuencias graves ya que puede caber la posibilidad de que el TRACE traiga encabezados de autenticación internos al requester durante su proceso de echo de la solicitud en el proceso de devuelta, y esto puede ser de gran ayuda para un atacante ya que solo basta con tener un proxy inverso para tomar las solicitudes analizarla y ver la información referente junto con encabezados de autenticación y que tales. Authorization Header
A día de hoy practicamente cualquier sitio web implementa un sistema de control de versiones, el mas conocido es git este lo que permite es mantener un historial de todos los cambios, del codigo fuente de una aplicación esto con el fin de poder modularizar las diferentes etapas del desarrollo de una aplicación y poder volver a diferentes etapas de la misma en caso tal de que se requiera, git sirve para eso, para poder tener siempre a la mano todas las versiones del software que se crea y a su vez no perderlo.
Ahora bien, todo el historial se almacena en un archivo .git y si una aplicación no oculta este archivo cuando el software ya esté en producción se podría acceder facilmente a el /.git y se tendría acceso al archivo, sin embargo no se podría mirar todo lo que hay, para poder verlo se debería tener git en la computadora del atacante para descargar el archivo y poder revisar todas las modificaciones de codigo que se hicieron y posibles comentarios o datos codificados confidenciales que se añadieron en el codigo fuente, aunque no se podrá ver el codigo fuente en su totalidad si se pueden fragmentos como lo menciono anteriormente y si hay algo que no está sanitizado por ahí se puede crear un posible vector de ataque.
Claro, siempre se debe crear un archivo .gitignore y se deberá añadir .git y todas las carpetas o archivos que no deseemos dentro de .gitignore a la carpeta de producción y así nos evitariamos problemas.
Veamos un lab de POC (proof of concept)
Eso es todo por esta sección, si llegaste hasta aqui gracias por leerme, nos vemos en las demás secciones :)
En ocasiones, es posible que se filtre información confidencial a usuarios que simplemente navegan por el sitio web de forma normal. Sin embargo, lo más habitual es que un atacante necesite obtener la divulgación de información interactuando con el sitio web de forma inesperada o maliciosa. Luego estudiarán detenidamente las respuestas del sitio web para intentar identificar comportamientos interesantes.
