Un RFD (Remote File Downloading) "protegido" por ofuscación

Hace no demasiado, cuando recordaba las charlas que había dado con mi amigo Palako por todo el mundo de hacking, me vinieron las demos de RFD (Remote File Downloading) que contamos en Noruega o Washington D.C. en la que utilizando diferentes ataques de SQL Injection íbamos descargando ficheros del servidor web, junto con otras técnicas de LFI (Local File Inclusion) o RFI (Remote File Inclusion).

Figura 1: Un RFD (Remote File Downloading) "protegido" por ofuscación

En todas estas técnicas, la idea es siempre la misma, ver cómo utilizar código Server-Side para que al final se acceda a un fichero que está en el servidor web y nos lo entregue vía web browser. Ni sé cuantos proyectos de Ethical Hacking a empresas o pentesting a aplicaciones web se han terminado con una sola técnica de estas, ya que en el momento en el que te puedes descargar ficheros del servidor vas a ir a por los "juicy files" que te van a entregar las configuraciones de acceso a la base de datos, los usuarios del servidor web, los datos de la DMZ por las configuraciones de red, etcétera.

Figura 2: Hacking Web Applications: Client-Side Attacks

De hecho, cuando te enfrentas a una auditoría de un sitio web, es una de las cosas que primero buscas. SQL Injection, Blind SQL Injection, errores verbose que te dan información jugosa, Client-Side Attacks como XSS/CSRF/SSRF y descarga de ficheros. Por eso los pentesters en los Red Team, en los equipos de QA de seguridad y en los equipos de Ethical Hacking, estas disciplinas se entrenan con fuerza. En muchos CTFs de las CONs, conseguir una bandera es descargar un fichero - o muchos - del servidor web. 

Un RFD protegido por ofuscación

El caso que os voy a contar es uno de muchos, pero me hizo gracia encontrármelo de casualidad, ya que, en lugar de hacer las cosas bien, han puesto un parche de oscuridad que seguro que a los bots, y a los menos expertos evita, pero desde luego no a ningún pentester profesional. 

Figura 3: Aplicación PHP que descarga ficheros

En esta implantación, el código que te permite acceder a los ficheros es un fichero PHP que devuelve un fichero PDF o un PNG. Hasta aquí tiene toda la pinta de ganarse la atracción de cualquier auditor de seguridad profesional, pero lo que más llama la atención es que utiliza dos parámetros para conseguir la descarga. El primero de ellos un hash y el segundo un Ln.

Figura 4: Analizando el hash con Hash Analyzer

Lo primero que puedes pensar es que se trata de un esquema tipo cucharón, donde el programa tira un Select contra una base de datos, y puedes intentar hacer un UNION para que devuelva un Path al fichero que tú quieras. Es un esquema típico de RFD, pero no era así. Analizando el Hash se ve rápidamente que era un BASE64, así que se puede decodificar fácilmente.

Figura 5: Libro de Hacking Web Technologies 2ª Edición en 0xWord de
Chema Alonso, Enrique Rando, Amador Aparicio, Pablo González y Ricardo Martín

Al decodificarlo, se ve que aparece una ruta a un fichero, pero que cuenta con unos caracteres de más al inicio, y otros caracteres del más al final, como si llevara más información de la que es necesaria en esa ruta. 

Figura 6: Decodificando el hash. Aparecen caracteres antes y después de la ruta

Tras probar las cosas que hay que probar, es decir, probar el Hash original con valores aleatorios de LN se observa que no descarga nada y salen todos los ficheros vacíos, pero cuando se pone un LN+1 se descarga un fichero vacío con un nombre que tiene una letra más que el nombre del fichero correcto, y eso hizo saltar el dato final.

Figura 7: con LN+1 busca un fichero con extensión pngo que no existe

Al principio confundí los caracteres de inicio como parte del Path pero viendo este comportamiento y contando LN caracteres hacia atrás desde .png y ver que acaba en la barra de /home, es fácil asumir que el valor de LN es el límite de caracteres que se debe tomar del string de caracteres que viene en el HASH Base64 del parámetro de llamada. Pero... ¿para que sirve la cadena de  caracteres al inicio y la cadena de caracteres al final?

Figura 8:Codificando la ruta de /etc/passwd con los caracteres sobrantes

Para probar si esta suposición es correcta y si tenemos que hacer algo más con los caracteres al inicio y al final, basta con hacer una sencilla prueba. Vamos a dejar los caracteres al principio y los caracteres al final tal y como están, y vamos a meter la ruta al /etc/passwd en el medio. Después vamos a codificar en BASE64 esta cadena. Y ahora hacemos la llamada al programa PHP poniendo este Hash como parámetro uno y como parámetro LN al valor de lenght(/etc/passwd), y vemos si el fichero descarga y que hay dentro.

Figura 9: Fichero /etc/passwd descargado

Como se puede ver, tenemos el fichero /etc/passwd descargado, y haciendo lo mismo todos los ficheros del servidor a los que tenga acceso el usuario del servidor web - que no es root -. Tras unas cuantas pruebas, y ver que con ese sencillo algoritmo era posible descargar todos los ficheros, la respuesta de para qué sirven esos caracteres al inicio y al final es sencillo. Son "Tokens de ofuscación" que el programador ha metido para que no le sea tan fácil a un script kiddie o a un bot automático descargar los ficheros.

Figura 10: Probando con /etc/hosts y los mismos caracteres sobrantes

Realmente es una solución inútil, porque cualquier pentester profesional va a encontrarlo fácilmente, y si tienes que hacer una aplicación web, más vale que conozcas las técnicas de hacking de aplicaciones web, y que sepas cómo desarrollar de forma segura, porque lo que te puede parecer una buena idea, puede ser un desastre de seguridad.

¡Saludos Malignos!

Chema Alonso (Contactar con Chema Alonso) (Consigue Tempos gratis con ESET)

Chema Alonso en MyPublicInbox

PacsOne Server “All bugs in One” en la gestión de imágenes radiológicas

Hace ya varios meses que publique un artículo en el blog de ElevenPaths hablando sobre las "Debilidades y fugas de información en sistemas médicos (PACS)". A partir de esto, he venido jugando con varias aplicaciones de este estilo y esta ocasión he querido compartir varios fallos de seguridad encontrados en un proyecto denominado “PacsOne Server”, concretamente en su componente DICOM Web Viewer.

Figura 1: PacsOne Server “All bugs in One” en la gestión de imágenes radiológicas

PacsOne combina varios componentes que permiten implementar de manera muy versátil un servidor PACS (almacenamiento de imágenes radiológicas) a través de un solo instalador como lo considera el proyecto ‘PACS Server In One Box’. En su arquitectura principal dicho software mantiene componentes que son comunes en este tipo de soluciones como el Servidor PACS, Servidor DICOM, Servidor Archivos (imágenes), Visor Web DICOM, entre otros; lo que permite para una empresa hospitalaria o de la salud tener todas las prestancias dentro de la mismo plataforma integrada y brindarlas a sus clientes.

Figura 2: Instalador y configurador inicial de PACSOne Server

La curiosidad que al momento me ha despertado mucho interés, son los Visores Web DICOM, los mismos que permiten a través de una interfaz web manipular tanto a médicos o pacientes, las imágenes radiológicas y toda la información involucrada con los pacientes y sus estudios; ya sea desde el mismo computador o remotamente desde internet.

Figura 3: Acceso a Web Viewer de servidor PACSOme expuesto a Internet

Figura 4: Estructura de archivos después de la instalación y código fuente de aplicación web

Cuando inicie con la revisión a una parte del código fuente del Visor Web DICOM, pude evidenciar mediante diferentes pruebas la falta de validaciones y una correcta aplicación de controles de seguridad en el desarrollo de este software, lo cual conllevo a que los resultados se determinen varias vulnerabilidades web entre las cuales puedo destacar Cross-Site Scripting (XSS), Directory Transversal o SQL Injection entre otras.

Figura 5: Código fuente de nocache.php

Mediante la revisión de la aplicación web, se puede identificar claramente falencias en la validaciones de entradas por parte del usuario, por ejemplo la Figura 5 en el archivo nocache.php el input "path" recibido no está validado correctamente lo cual desencadena en una vulnerabilidad explotable.

Figura 6: Código fuente de archivo userSignup.php

En este artículo pretendemos exponer ciertas evidencias de las vulnerabilidades encontradas y explotadas de manera controlada luego del análisis realizado a parte del código fuente, el mismo que es accesible luego de la instalación del software.

Figura 7: Ataque de XSS en archivo login.php

Como podemos ver las vulnerabilidades explotadas pueden llegar a archivos sensibles dentro del servidor [Figuras 8] así como otras de tipo inyección [Figuras 7 y 9], las mismas que podrían llevar desde poner en peligro la información almacenada de los pacientes que se ha realizado estudios, comprometer el servidor o una amplia puerta de entrada a una infraestructura hospitalaria o de la salud.

Figura 8: Ataque LFI (Local File Inclusion) en archivo nocache.php

La base de PacsOne (como indica en su sitio web) ha sido usada por varios proyectos, fabricantes y desarrolladores en general, para integrarlo de manera parcial o total en sus propias implementaciones, con lo cual hace más amplia la exposición de esta aplicación y sus vulnerabilidades.

Figura 9: Ataque SQL Injeciton con sqlmap

Por último, quiero comentarles que las vulnerabilidades expuestas fueron reportadas al equipo de contacto del proyecto, los cuales tuvieron un muy buen tiempo de respuesta tanto en las comunicaciones como en la solución a los fallos reportados de lo cual hemos sido notificados que se han solucionado en su última versión; con lo cual, esperamos seguir colaborando con este tipo de proyectos.

Autor: Carlos Avila (@badboy_nt) Chief Security Ambassador – CSA at ElevenPaths

Big Data Security Tales: Los Known-Bugs en WSO2 Carbon Server #BigData #Pentesting

Por supuesto, el software que se utiliza en los entornos de Big Data es susceptible de contener fallos de seguridad que van siendo descubiertos a lo largo del tiempo. La gestión de las actualizaciones es un proceso fundamental que debe tomarse en serio. A veces esta gestión no es trivial, y la ventana de oportunidad para explotar un bug conocido (Known-Bug) puede ser grande, por lo que hay que prestar especial cuidado a las listas de seguridad, y tener los procesos de gestión de parches bien engrasados.

Figura 1: Los known-bugs en WSO2 Carbon Server Technologies

En la conferencia de Big Problems with Big Data que os dejé hace unos artículos, el ponente ponía el ejemplo de cuál es el proceso de aplicación de un parche de, por ejemplo, una librería como JQuery en un entorno de Big Data. 

El ciclo de vida de un Known-Bug

El bug es descubierto y publicado en JQuery que después se aplica a la siguiente distribución de Django. Este framework se utiliza para construir Apache HUE, por lo que en la siguiente compilación en la que se compruebe que la nueva versión de Django no rompe nada se aplicará, con la consiguiente corrección del bug que había en JQuery. Apache HUE saca su nueva versión, y esta debe ser empaquetada en la nueva compilación de Apache Hadoop, por lo que para que el known-bug de JQuery esté parcheado en la versión de Apache HUE que acompaña tu distribución de Apache Hadoop hay que esperar un paso más.

Figura 2: Ciclo de vida de actualizaciones de un Know-Bug

Esto, por supuesto, se alarga si has utilizado una distribución como Cloudera o HortonWorks que deberán hacer su nueva release en la que haya probado que la nueva distribución de Apache Hadoop que lleva la nueva versión de Apache HUE compilada y probada con la nueva versión del framework de DJango que incorpora la nueva versión de JQuery parcheada no rompe nada. Y después deberá instalarlo el cliente si ha decidido ir a un entorno de Big Data basado en una instalación OnPremise, o en Cloud pero gestionada por él mismo.

Esto por supuesto no es siempre un proceso tan lento, y cuando un bug de seguridad es crítico se acortan los plazos al máximo, pero aún así hay una ventana temporal de explotación de known-bugs muy grande. Por eso es especialmente importante estar al día de los posibles bugs que puedan ser descubiertos en los programas que usas en tu instalación de Big Data. 

Known-Bugs en WSO2 Carbon Server

En el caso de WSO2 Carbon Server, recientemente se publicaron en las listas de seguridad una serie de ellos que deben tenerse en cuenta. Lo curioso es que al ir a mirar el histórico de los Security Advisories de todos los productos de la familia, solo pude localizar Security Advisories en 2016 y solo los que había leído en la lista de contactos.

Figura 3: Security Advisories en WSO2

Sin embargo, si entramos en la lista de parches disponibles sí que podemos ver todo el histórico de parches de seguridad para todos los productos, y ahí podemos revisar si en una determinada instalación existen o no vulnerabilidades.

Además, en los productos de WSO2 es extremadamente sencillo descubrir la versión de un determinado producto ya que sin necesidad de tener iniciada una sesión se puede acceder al botón de "About" y conocer qué versión exacta es la que está instalada. 

Figura 4: Versión exacta de una instalación de WSO2 Identity Server

Una vez conocida la versión, revisar la lista de parches da exactamente la lista de known-bugs que se tiene en esta instalación concreta. Para nuestro sistema de pentesting persistente Faast esto es perfecto ya que nos permite avisar a nuestros clientes rápidamente cuando una versión desactualizada es detectada.

Figura 5: Known-Bugs en la versión 5.0.0 de WSO2 Identity Server

Gracias a ello es sencillo localizar versiones inseguras, pero también para la propia organización detrás del software, por lo que sería sencillo localizar clientes a los que hacer un aviso de seguridad personalizado con el objeto de ayudarles a estar más seguros.

PoC con WSO2 Data Services Server

Una de las versiones inseguras de WSO2 Data Services Server permite la ejecución de código en Java desde la consola de Tools, a la que se puede acceder sin necesidad de haberse autenticado en la plataforma. Desde esa misma consola es posible ver cómo cuando se intenta hacer una conexión, la página web pone el código que esta ejecutando.

Figura 6: Se muestra el comando y el mensaje de error

Tener este panel, expone en primer lugar los servidores de la DMZ para hacer un ataque de XSPA, pero también es vulnerable el interfaz con un bug de HTML Injection que permite hacer cosas como este Ataque de David Hasselhoff.

Figura 7: Un HTML Injection con un homenaje de Ricardo Martín al David Hasselhoff Attack

Y si además hay una gestión de credenciales insegura en alguna de las bases de datos de la DMZ y se llega a un servidor como este con un usuario sa de Microsoft SQL Server sin contraseña, sin necesidad de haberse conectado al servidor WSO2 Data Services Server es posible acceder a ficheros del servidor viendo el código en el mensaje de error.

Figura 8: Un LFI en el mensaje de error

Al final, la gestión de parches es algo fundamental, y es verdad que el número de aplicaciones y tecnologías que suele tener un entorno de Big Data en una empresa es grande, pero si no se hace esa gestión de forma robusta y planificada al igual que se hace con el resto de las tecnologías, explotar un "Known-Bug" va a ser muy sencillo para un atacante.

- Big Data Security Tales: ¡Vigila que tu MongoDB no le de tus datos a cualquiera! (Level 100)
- Big Data Security Tales: Cómo funcionan las MongoDB Injection
- Big Data Security Tales: MongoDB y Cassandra (Level 101)
- Big Data Security Tales: Apache Hadoop expuesto por no configurar HUE (Level 102)
- Big Data Security Tales: Django en HUE en modo DEBUG y con Directory Listing (Level 103)
- Big Data Security Tales: Las Interfaces de acceso al HDFS
- Big Data Security Tales: Apache Amabari Default Admin
- Big Data Security Tales: WSO2 Carbon y la ayuda para el Login
- Big Data Security Tales: Los Known-Bugs en WSO2 Carbon Server
- Big Data Security Tales: Kibana & ElasticSearch objetivos del ransomware
- Big Data Security Tales: Apache CouchDB Relax... o no
- Big Data Security Tales: Riak NoSQL Database

Saludos Malignos!

Nuestro nuevo libro de "Hacking Web Technologies" @0xWord #pentesting #hacking

Hoy estoy contento, pues después de varios meses de trabajo ya esta disponible desde hoy un nuevo libro de 0xWord en el que he podido trabajar con grandes amigos. Haciendo equipo con Enrique Rando, Pablo González, Ricardo Martín y Amador Aparicio hemos escrito un libro orientado al pentesting y hacking de tecnologías web, y desde hoy lo puedes comprar: Hacking Web Technologies

Figura 1: Nuestro nuevo libro de "Hacking Web Technologies" @0xWord

El libro está centrado en explotar diferentes vulnerabilidades de los sistemas basados en tecnologías web, sin tocar para nada las técnicas de SQL Injection, de las que ya sabéis que escribimos otro libro Enrique Rando y yo. En éste libro nos centramos en otros tipos de ataques como son, por ejemplo, los ataques a las tecnologías LDAP, ataques a Connection String, los ataques de Info Leaks, las técnicas de Local File Inclusion o XPath Injection. 

Figura 2: Libro de Hacking Web Technologies

Además, en el libro se tocan temas como el uso de herramientas de auditoría web como ZAP Proxy de manera profesional, las técnicas de ataque de PHP Object Injection o la explotación de ataques de MongoDB Injection. El índice del libro lo he subido a SlideShare para que lo podáis ver en detalle.

Figura 3: Índice del libro "Hacking Web Technologies"

Este es el libro número 40 de la colección de libros de 0xWord, y por ahora está dentro ya del pack de Colección Completa, aunque probablemente lo incluyamos pronto en algún pack. Puedes comprarlo online y solicitarlo a nuestros distribuidores en latinoamérica para que te llegue lo antes posible.

Saludos Malignos!

Simular un falso ataque de LFI para que “cante” el WAF

Antes de realizar un ataque a una servidor, conviene tener información sobre qué medidas de seguridad tiene. Saber si el sistema tiene algún firewall delante protegiendo con redes el tráfico entrante, un reverse proxy para ocultar la ubicación real o una solución antimalware concreta que esté vigilando los ficheros que se suben, puede venir bien antes de preparar una intrusión. En el mundo del pentesting de aplicaciones web, cuando se realiza un escaneo, conviene saber si delante de la web hay algún WAF (Web Application Firewall) que pueda bloquear los intentos de explotación de vulnerabilidades. Localizar si existe, y cuál es, algún WAF es una buena idea, además de que puede ayudar a generar mucha más información del escenario completo con el que te encuentras.

Figura 1: Simular un ataque LFI para que "cante" el WAF

Existen muchas formas de saber si hay un WAF en un sitio web, pero hay una que es bastante sencilla y que funciona relativamente bien. Normalmente, cuando un WAF bloquea una petición, éste genera un menaje de respuesta HTTP 403 Forbidden, con una página de respuesta por  defecto que debería ser configurada para dar poca información a un posible atacante. Con el objeto de conseguir forzar ese error HTTP 403 del WAF, lo suyo es simular un ataque, y una forma muy sencilla de hacerlo es conseguir que el WAF crea que se está produciendo un ataque de LFI (Local File Inclusión) para acceder a ficheros sensibles.

Figura 2: Mensaje de error del WAF de un blog tecnológico

Estas técnicas se utilizan mucho en auditorías de seguridad e intrusiones de atacantes, y suelen tener la característica de querer escalar en el árbol de directorios del servidor web con la cadena ../../, algo que las reglas por defecto de la mayoría de los WAF - incluyendo el popular mod_security que se utiliza para fortificar servidores web GNU/Linux -, detectan por defecto y bloquean. Basta con añadir a una URL algo como ?file=../../ para hacer creer al WAF que se está produciendo el ataque, y ver qué mensaje obtenemos.

Figura 3: Mensaje 403 de un dominio de Apple.com

Como en los muchos casos vistos con los mensajes de error de los servidores web, estos mensajes pueden ser igual de útiles, no solo para saber que hay un WAF, sino para conocer exactamente el tipo de WAF y hacerse una idea del tipo de posibilidades que ofrece.

Figura 4: Mensaje de Error 403 de una empresa que indica la detección del LFI

Además, si la página ha sido personalizada, tal vez se pueda acceder a alguna información útil que haya podido quedarse allí por una mala configuración.

Figura 5: Mensaje de Error 403 en la web de DefCon generado por McAfee Global Threat Intelligence

Si tienes un WAF, comprueba los mensajes de bloqueo que estás mostrando en los HTTP 403. Si puedes evita dar demasiada información a los atacantes. Puedes configurar el WAF para devolver un HTTP 200 genérico con un bonito mensaje de error, y habrá mucha menos información que un atacante pueda llevarse a la boca.

Saludos Malignos!

Cómo te pueden robar la Base de Datos de tu sitio web con bugs de Path Transversal & Local File Inclusion

A punto de terminar este 2014, la vulnerabilidad Path Transversal o Ruta Transversal sigue copando una de las primeras posiciones dentro del top ten establecido por la fundación OWASP sobre vulnerabilidades en aplicaciones web. Detectar páginas web que puedan sufrir este tipo de vulnerabilidad es relativamente sencillo aplicando un poco de hacking con buscadores, debido a que hay tipos de páginas que tienen este fallo muy tipificados. Uno de ellos muy común es el de una aplicación para descargar ficheros que no asegure correctamente la ruta ni la extensión del fichero que se le está pasando por parámetro.

Figura 1: Cómo te pueden robar la Base de Datos de tu sitio web con Path Transversal & Local File Inclusion

En el caso del paso del nombre de un fichero, es común encontrar, como veremos más adelante, parámetros file o fichero con el nombre y la ruta completa dentro del servidor, pero también es posible que el parámetros sea el nombre codificado en BASE64 o similares, por aquello de evitar la exposición al ojo del nombre del fichero. Si por el contrario se hace un acceso indirecto por medio de un ID, será necesario averiguar de qué forma guarda la tabla que recoge cuál es la asignación ID a ruta de fichero. Esto podría ser mediante un fichero de texto, un archivo XML o directamente una tabla en una base de datos - que suele ser lo más común en los CMS personalizados -.

Detectar este tipo de páginas en los buscadores es fácil, tal y como se explica en el artículo de "Cómo localizar webs vulnerables a LFI con Google" ya que el patrón que suelen seguir sus URLs es de la forma:

Figura 2: Resultados devueltos por Google

Como se puede ver en los resultados, el número de aplicaciones que cumple ese patrón es alto pero no todos son vulnerables. Para evaluar si ese tipo de aplicaciones son vulnerables o no, primero hay que determinar la estructura con la que se está accediendo al fichero. Este acceso puede ser de forma directa, para lo que se está pasando un nombre de fichero, o indirecta, mediante el paso de un identificador que le sirve a la aplicación para localizar la ubicación del fichero.

Al final objetivo de un Path Tranversal es obtener acceso a ficheros o directorios que se encuentren dentro del directorio raíz de un servidor web pero no accesibles directamente desde la aplicación web, sino utilizada por ésta para, por ejemplo, conectarse con la base de datos del sistema para validar un usuario, etc… Otras veces se aprovecha esta vulnerabilidad para acceder a ficheros fuera del directorio web como puedan ser /etc/passwd y /etc/shadow y, tras fusionarlos con herramientas de tipo unshadow, aplicar fuerza bruta sobre las claves hasheadas de los usuarios para intentar obtenerlas en texto claro, con herramientas como John The Ripper, etc…

Cuando se puede escalar de esta forma por la estructura de directorios de un servidor, esta vulnerabilidad podría venir acompañada de otras dos: Local File Inclusion para ver el contenido de los ficheros y/o Remote File Inclusion para ejecutar código remoto. La primera permite incluir ficheros locales donde se encuentra la web que presenta la vulnerabilidad y la segunda cargar ficheros de manera remota, básicamente para intentar ejecutar comandos dentro del servidor o ejecutar scripts.

Paso 1. Búsqueda de una web vulnerable.

En la siguiente prueba de concepto se muestra cómo localizar webs que puedan ser vulnerables a este tipo de ataque, cómo explotar el ataque para ver la información sensible que se puede obtener si no se ha pasado una auditoria web de seguridad. Para ello vamos a hacer un poco de hacking con buscadores y, para acotar los resultados, vamos a buscar páginas que se encuentren bajo un determinado dominio y que los ficheros tengan una determinada extensión.

Figura 3: Resultados de aplicaciones web que descargan archivos con la ruta del mismo

En este ejemplo, vamos a seleccionar una en la que el nombre del fichero venga directamente en el parámetro. Si viniera un ID, habría que ver si en él se puede inyectar un comando SQL Injection para poder hacer algo como:

MySQL -> id=-1 UNION SELECT "/etc/passwd"
Oracle -> id=-1 UNION SELECT "/etc/passwd" from dual
SQL Server -> id=-1 UNION SELECT "/etc/passwd" from sysobjects --

Al final, habría que construir una consulta INBAND con UNION para conseguir que la consulta que esté construyendo el programador devuelva un recordset vacío y se le una un recordset creado por nosotros. Construir la consulta INBAND en cada caso requiere reconocer el motor de la base de datos, analizar la consulta del programador mediante pruebas, etcétera. Si quieres saber más de esto tienes que dominar las técnicas de SQL Injection.

Paso 2. Comprobar si la web es vulnerable.

En este caso, centrándonos en una web en la que se recibe como parámetro el nombre de fichero - y a veces la ruta en un parámetro a parte -, para comprobar si está presente la vulnerabilidad Path Transversal, se usa la secuencia de caracteres especiales conocida como “dot-dot-slash” o ../

Pero también podemos probar a poner parte de la URL localizada - en concreto lo más fácil es intentar descargar el mismo fichero que se usa para descargas - para ver cuál es el comportamiento del navegador. Si es vulnerable, observaremos que nuestro navegador va a realizar una descarga, luego esto nos da la pista de que la vulnerabilidad de Path Transversal está presente en la aplicación web. Además tenemos la certeza de la existencia del directorio archivos dentro del servidor web.

Una vez visto que se pueden descargar ficheros arbitrariamente, intentaremos descargar ficheros como index.php o ../index.php para ver si es posible descargar estos archivos en texto claro y ver si podemos obtener rutas de archivos de configuración, claves de acceso a la base de datos, etc…

Figura 4: Descargando el fichero Index.php

Es en este punto, cuando ya se sabe que se pueden descargar ficheros del servidor, cuando entran en juego todos los data leaks que se puedan conseguir para listar los archivos locales del servidor web. Para eso, aprovecharse de los errores de conversión de tipos de datos en PHP, de las rutas locales mostradas en las páginas de error ASP, TCL o similares, y si es posible también de los directory listing, el bug de IIS Short name, ficheros .listing, archivos .DS_Store, DWSync.xml o módulo de mod_negotiation es de gran utilidad para saber dónde está y qué hay que descargar del servidor. Aquí tenéis un total de 20 técnicas para descubrir los ficheros de un servidor web.

Figura 5: Descubrimiento del fichero funciones.php citado en index.php

En este caso, si observamos el contenido de este fichero index.php, vemos que existe el fichero funciones.php en el mismo directorio junto con el fichero home.php. Además, debido a una mala configuración del servidor, podemos descargarlos. A veces los ficheros del tipo funciones.php contienen usuarios y contraseñas harcodeadas, por lo que siempre hay que mirar su contenido:

Figura 6: Descarga del fichero funciones.php Se descubre admin/conexion.php

Vemos en la imagen cómo es posible descubrir más fichero críticos dentro de una aplicación web, en este caso, conexion.php, que muy probable tenga los parámetros de configuración a la base de datos utilizada por la aplicación web donde puede haber usuarios y contraseñas de acceso, aparte de información sensibles de usuarios. Además también aparecen consultas a la base de datos, lo que nos puede dar una pista de cuáles son las tablas donde se almacena la información crítica de los usuarios, etc… Tras consultar el contenido del fichero conexion.php, se observan hardcodeados todos los parámetros de conexión a la base de datos.

Figura 7: Parámetros de conexión a la base de datos MySQL

Un atacante llegado a este punto podría intentar buscar la URL de acceso a PHPmyadmin o programar y un script de conexión en PHP a la base de datos, suponiendo que el servidor de base de datos acepte conexiones desde fuera del servidor.... o encontrar cualquier otro camino para llegar a la base de datos.

Paso 4. Implicaciones de la vulnerabilidad de tipo Path Transversal y de la fuga de información.

La finalidad de este ataque es poder acceder a ficheros a los que no debería de poder accederse por la información que contienen debido a los errores de programación en la aplicación web. Como hemos visto, podemos obtener los datos de conexión a la base de datos.

Si en la base de datos, a parte de la información de acceso hay información sensible de clientes, la fuga de información puede ser crítica, la pena por el incumplimiento de la LOPD 15/99 puede ser importante, además de que esos datos se puedan vender en el mercado negro tal y como hacen los cibercriminales dedicados al fraude online.

Autor: Amador Aparicio
Twitter: (@amadapa)

Usar Google para descubrir sitos webs con bugs de LFI

Años después, cuando sigo mostrando los sitios defaceados en tiempo real en Zone-h, la gente sigue preguntándome cómo es posible que alguien sea capaz de hacer esos ataques en tanto sitios. No hay ninguna trampa, solo experiencia y técnicas. Lo cierto es que en muchos de esos ataques hay un proceso de automatización basado en el descubrimiento de sitios vulnerables a un determinado fallo o exploit. Es decir, se tiene un exploit para un determinado CMS o Framework de Internet y se automatiza el descubrimiento de servidores con ese software afectado y la explotación del fallo. Por eso hay que tomar medidas de fortificación en los frameworks más populares como Joomla!, WordPress, y similares, ya que cuando se publica un nuevo bug para ellos, se explota de forma automatizada masivamente.

Figura 1: Los sitios defaceados y reportados esta mañana

En otras ocasiones se utilizan herramientas de escaneo automático en busca de vulnerabilidades explotables de SQL Injection, Command Injection, Remote File Inclusion, Métodos Put inseguros o Local File Inclusion, que serán las que más juego den a la hora de subir una Web Shell o meter un fichero para hacer un defacement.

Para localizar las posibles víctimas, desde hace ya muchos años se utilizan los buscadores, que permiten localizar mediante lo que se llamaron "dorks", a los que tienen una determinada característica que denota su vulnerabilidad. Esto se ha utilizado ya en ataques masivos para distribuir malware, buscando fallos de SQL Injection de forma masiva en Google y automatizando la inyección de scripts mediante sentencias Update, como se explica en el libro de Fraude Online. En alguna de ellas llegando a afectar a sitios como la propia Apple.

Saber jugar bien con Bing Hacking, Google Hacking, Shodan, Archive o Robtex es parte fundamental para los defacers, los pentesters, los analistas de seguridad y los investigadores. En el libro de Hacking con Buscadores Enrique Rando cuenta algunos trucos muy interesantes de Google, y explica en detalle cómo utilizar los comodines para localizar objetivos concretos, algo que todos los perfiles citados anteriormente utilizan en algún momento.

Yo uso los buscadores en infinidad de ocasiones para todo tipo de cosas, como para localizar centralitas de VoIP a través de Shodan, localizar sitios vulnerables a HeartBleed por puertos no habituales o para encontrar ficheros ICA usando el operador contains de Bing. Por poner algunos ejemplos de los muchos artículos en los que me han venido.

Por poner un ejemplo de cómo teniendo control de los buscadores se puede sacar petróleo, alguien podría utilizar los comodines para poder localizar sitios vulnerables a LFI (Local File Inclusion). En estas vulnerabilidades lo que se trata de poder acceder a ficheros locales del servidor manipulando los parámetros de algún programa que accede al sistema de archivos donde corre la aplicación web y normalmente se encuentran de dos tipos.

Generalmente las vulnerabilidades más comunes de LFI, llamémoslas de Tipo 1, son ficheros que acceden directamente al sistema de ficheros construyendo la ruta de acceso con algún parámetro que se les pasa desde la URL. Se localizan porque alguno de los parámetros es el nombre de un fichero "loquesea.pdf", lo que atrae la atención del pentester para hacer algunas pruebas, como las que puedes ver en este post de "descubrir un LFI al estilo FOCA" que nosotros automatizamos en nuestro servicio de pentesting persistente Faast.

Figura 2: Descargando el fichero que descarga

Si se descubre el bug, que generalmente se hace intentando descargar el propio fichero que realiza la descarga de los ficheros, basta con introducir la ruta absoluta o relativa,  según sea cada programa de descargas - en el de la Figura 2 se puede ver que es una ruta absoluta cuando el parámetro que se usa es "fichero" y relativa cuando el parámetro que se usa es "serie" -, para pedir el fichero que se desea obtener del servidor.

Figura 3: Un LFI en una web para acceder a /etc/passwd con ruta absoluta

En otras ocasiones, las que llamaremos de Tipo 2,  no viene ningún nombre de fichero como parámetro, pero el nombre de la aplicación es algo como "descargarfichero.php" o el nombre del parámetro es "fichero=identificador", lo que indica que probablemente con ese parámetro se esté accediendo a una tabla en una base de datos - o un fichero XML que sería otra historia de XPath Injection - de la que se está recuperando o el nombre o la ruta completa del fichero. En esos casos hay que hacer un ataque de SQL Injection buscando inyectar la ruta del fichero buscado.

Es decir, en una aplicación en la que apareciera algo como fichero=23, y en la que el programador generase una consulta para acceder a la ubicación donde se almacena el fichero de forma similar a esto:

$SQLCommand="Select ruta from ficheros where id="+$_GET["fichero"]+";"; 

Lo que se debería hacer el algo como:

fichero=-1 union Select '/etc/passwd'

En cada motor de base de datos y en cada aplicación programada habría que ver cómo ajustar la cadena de inyección, pero en regla general sería algo así, pero eso es otra historia para otro libro.

Para las vulnerabilidades del Tipo 1 - que es lo que os venía a contar en esta historia - como en Google se pueden usar los comodines y el truco de la barra para jugar con las búsquedas, se pueden hacer dorks para localizar aquellas URLs que cumplan una serie de condiciones, por ejemplo que tengan la palabra php file y pdf con un patrón, o que sea lo mismo pero en Español.

Figura 4: Muchos resultados para jugar y probar

Figura 5: Miles de ellos en Español

Al final, estos dorks - dale al enlace de "Mostrar más resultados" - muestran una cantidad de sitios que cumplen esa estructura en su URL y que para cualquier herramienta automatizada para la búsqueda de bugs de LFI siguiendo unos patrones será fácil explotar.

Saludos Malignos!

Examen Máster Seguridad UEM 2012-2013

Aquí tenéis el examen del curso 2012-2013 del módulo de Seguridad en Aplicaciones Web del Máster de Seguridad de la UEM. El tiempo de realización es de 1 hora y media. No vale copiar, no vale hablar con el compañero y si estás en tu casa haciéndolo no vale usar Internet para buscar las respuestas. Las soluciones las pongo mañana.

1.- Tienes una empresa con una aplicación web de presencia en Internet que carga los contenidos que se publican dinámicamente desde una base de datos. Desde esa web, hay un acceso especial para clientes que pueden acceder a una aplicación de compras. Además, la empresa tiene una intranet para la gestión del personal. ¿Qué medidas de seguridad consideras que se deberían tomar en cuanto a la arquitectura de servidores y servicios? Cita reglas generales y medias concretas que creas convenientes.

Respuesta: Fortificación de un servidor web Apache. Las leyes de la fortificación

2.- Describe en qué consiste un ataque XSS No-persistente, un entorno en el que se pueda encontrar esta vulnerabilidad y cómo puede ser utilizado para distribuir malware a través de Google.

Respuesta: Buscadores como arma de destrucción masiva: Ataques XSS Google-Persistentes 

3.- Describe como se puede hacer un proceso de hijacking de sesión a un usuario de una red social en la que las cookies no vayan por HTTP-s si la web no tiene una vulnerabilidad de código (ni SQLi, ni XSS).

Respuesta: Firesheep o Wirehsark

4.- Describe algún método para robar una cookie marcada como HTTP-Only con un ataque de XSS.

Respuesta: Usando el método TRACE, usando errores 400 en Apache o usando Applets Java

5.- Una aplicación web de una empresa carga un Applet Java en la página de login para autenticar a los usuarios. Tras probar varios usuarios erróneos, se puede comprobar que la aplicación no hace Post-Back. ¿Qué fallo de seguridad podría tener esta aplicación y cómo debería investigarse?

Respuesta: Validación local. Se usarían decompiladores de Applets 

6.- Una aplicación web en PHP con MySQL es vulnerable a SQL Injection. Se quiere extraer la versión de Mysql realizando un ataque de Blind SQL injection. Describe el proceso que habría que realizar.

Respuesta: Blind SQL Injection en MySQL y Optimización de Blind SQL Injection en MySQL

7.- Describe en qué consisten los ataques de Time-Based Blind SQL Injection y cómo pueden realizarse sin hacer uso de funciones específicas de retardo de tiempo como delay o sleep.

Respuesta: Técnicas avanzadas de ataques Blind SQL Injection

8.- Una empresa de venta online, tras un balance de fin de mes, comprueba que los cobros realizados por las ventas no corresponden con el precio de venta de los artículos vendidos. ¿Qué se debería comprobar en la aplicación web si se sabe que nadie ha manipulado los precios en la base de datos?

Respuesta: Coja su cambio, sea justo.

9.- Dado el siguiente código PHP del lado del servidor ubicado en la ruta web siguiente:

http://www.miweb.test/home/public_html/descargafichero.php

<?php
session_start();

$sDocumento = $_GET['documento'];
header("Content-type: application/force-download");
header("Content-Length: ".filesize($sDocumento));
header("Content-Disposition: attachment;
filename=".basename($sDocumento));
header("Content-Transfer-Encoding: binary");

if (!@readfile($sDocumento)) echo "Error";
?>

Responde a las siguientes cuestiones:

a) Determina qué tipo de vulnerabilidad está presente en él y describe sus riesgos.
b) Escribe una URL de ataque que permita explotarla para poder acceder al código fuente de la página descargafichero.php
c) Escribe la URL de ataque para descargar un fichero con todos los usuarios de un sistema *NIX*.

Respuesta: El cucharón

10.- En una aplicación web, la aplicación autentica a los usuarios con un árbol LDAP, para ello, cada usuario tiene un atributo uid y un atributo password. El programador ha filtrado el * y utiliza la función crypt antes de usar la contraseña en una consulta AND LDAP como ésta.

V_username: valor de usuario introducido en la página web por el cliente.
V_passwd: valor de contraseña introducido en la página web por el cliente.
C_passwd =crypt(v_passwd) 

Consulta que da acceso o no a la aplicación:
(&(uid=+v_username+)(password=+c_passwd+))

¿Con qué inyección LDAP conseguirías entrar si la se está utilizando un árbol LDAP basado en OpenLDAP?

Respuesta: Or uno igual a uno ... en LDAP Injection

Saludos Malignos!

Hoy examen de seguridad de aplicaciones web a las 11:00

Para terminar esta ajetreada semana que me ha llevado por Bilbao, Burgos, Palencia, Valladolid, Madrid y Palma de Mallorca, toca ir hoy a Villaviciosa de Odón a dar una clase y examinar a mis chic@s del Máster de Seguridad de la UEM. El examen se lo voy a poner sobre las 11:00, así que por si alguno quiere hacerlo al mismo tiempo, lo voy a poner al mismo tiempo en el blog. Tenéis 1 hora y media para resolverlo ¡Sin utilizar Google! 

Mientras tanto, puedes repasar con los exámenes de años anteriores, como seguro que ya han hecho ellos:

- Examen Máster Seguridad UEM 2009-2010
- Examen Máster Seguridad UEM 2010-2011
- Examen Máster Seguridad UEM 2011-2012

En el 2008-2009 hice trabajo, pero desde entonces exámen. A ver que tal os sale a vosotros la prueba de este año - que será fácil.. A las 11:00 preparados para responder. }:))

Saludos Malignos!