Los ficheros CFC de ColdFusion: Otro pequeño leak a evitar

Son muchos los trucos que se utilizan para sacar información de los objetivos en un Ethical Hacking. Yo me he dedicado a coleccionar muchos de ellos en Mensajes de Error, configuraciones inseguras, o exploraciones de los diferentes motores que procesan los Query String en una página web. La suma de todos ellos hace que al final sea más fácil conocer el sistema operativo, la versión del servidor web, los "local paths", etcétera, que podrán unirse a otras técnicas para seguir avanzando en el pentesting.

Figura 1: Los ficheros CFC de ColdFusion: Otro pequeño leak a evitar

Todos ellos los comencé a incluir en nuestra FOCA, y con el tiempo pasaron a formar parte de Faast, nuestra plataforma de Cloud Persistent Pentesting en ElevenPaths que utilizamos para escanear miles de dominios de nuestros clientes cada día para reducir las ventanas de exposición de las debilidades al mínimo posible. Hoy os vengo a contar una de las últimas que hemos metido, que no es más que un leak que se produce con los ficheros CFC de ColdFusion.

Figura 2: Búsqueda de ficheros CFC en la ruta cfcomponets/core/
Se pueden encontrar en otras rutas también con un ext:cfc

Este leak me lo paso mi amigo Rootkit (¡gracias una vez más!) y lo descubrió mientras hacia un poco de Hacking con Buscadores, que tanto le gusta. La fuga de información se produce en las aplicaciones de ColdFusion que han dejado estos ficheros de componentes CFC = ColdFusion Component publicados en Internet.

Figura 3: Fichero CFC de ClodFusion

Lo que se obtiene de ello puede llegar a ser de gran utilidad, ya que son los interfaces de invocación de los componentes de una librería, junto con los parámetros que hay que utilizar, el comportamiento del componente y la ubicación local en la que se encuentra el fichero.

Figura 4: Rutas locales de la intranet en el servidor Windows

En algunas ocasiones, se puede acceder a información más detallada, en la que se describen uno a uno los parámetros, lo que ayuda a entender mejor, en un proceso de pentesting, qué es lo que se puede hacer con cada uno de ellos.

Figura 5: Información sobre los parámetros que se usan en cada componente

En estos ejemplos, además, se puede ver cómo algunos de estos sitios forman parte de un hosting, con lo que se podría utilizar esta información para realizar un ataque contra otro dominio alojado en el mismo servidor.

Figura 7: Rutas locales en un servicio de hosting.

No es el primer leak de ColdFussion del que os hablo, y ya he publicado posts sobre los errores 404 de esta plataforma - tirando de JSP como en el ejemplo de Apple - , o de los Errores 500 de Licenciamiento que se pueden obtener. Además, hay que recordar que ColdFusion usa Java al final de la cadena por debajo, así que si restringes el acceso a los CFC, acuérdate de revisar los errores Java que puedas provocar, ya que el leak puede migrar de un motor a otro.

Figura 8: Error de ColdFusion manejado por el motor Java

Al final, la suma de pequeñas fugas, debilidades de configuración, y fallos de seguridad, es lo que permite que un atacante sea capaz de saltarse todas las barreras de seguridad de un sistema - sea una aplicación, un servicio o una red entera -.

Saludos Malignos!

Cómo aprender de los mensajes de error en un pentesting

Este jueves pasé un rato entretenido con los compañeros jugando con unos nodos de un sitio web en Apple. Digamos que por casualidad topamos con un bug de IIS Short Name en uno de sus servidores - sí, Apple también utiliza Windows -, pero cuando íbamos a probar en detalle la vulnerabilidad los resultados eran inconsistentes... ¿cómo era esto posible?

Figura 1: Cómo aprender de los mensajes de error en un pentesting

Pues fácil, ese sitio web estaba siendo soportado por un cluster de servidores Microsoft Windows con Internet Information Services y el fallo no se encontraba en todos, lo que nos llevó a estrujarnos un poco más el cerebro y a que todo fuera aún más interesante.

Los mensajes de error en los servidores web

Muchas veces hemos hablado de la importancia de los mensajes de error en los servidores web. Hay que jugar mucho con querystring para sacar el máximo posible de información de un servidor web y los frameworks que tenga instalado. Cada código de respuesta HTTP puede estar configurado de forma distinta en cada framework, lo que hace que de cada uno de ellos se saquen datos.

Figura 2: Múltiples Frameworks que pueden procesar la petición

Un Error 404 dado por el servidor web no tiene por qué dar la misma información que un Error 404 del framework .NET, o del framework JSP, por lo que hay que conseguir hacer pruebas para obtener códigos de error HTTP en todos los motores del servidor web.

Múltiples nodos de un servicio

Para rizar un poco más el rizo, un sitio web puede estar soportado por un cluster de equipos publicado detrás de un balanceador - que además podría utilizar una CDN - por lo que hay que tener cuidado. Cuando un servicio utiliza más de un equipo para ofrecer su servicio, la labor del administrador debe ser configurar los dos de la misma forma, sin embargo esto no es siempre así. En el mundo de los servidores DNS esto es algo común y por eso en FOCA añadimos la opción de comprobar todo en todos los servidores DNS, pero también puede pasar en el mundo de los frontales web.

Figura 3: Un ejemplo de servidores DNS con diferentes configuraciones en Menéame en 2010

Localizar que un sitio web está detrás de un balanceador o que es parte de un cluster a veces se puede localizar directamente en las cookies. Sistemas como BigIP permiten localizar entornos con más de un sistema dando servicio a un servidor web.

Figura 4: Cookies de BigIP que dan información de los nodos

Otras veces simplemente hay que fijarse en todos los detalles para localizar la fuga de información necesario que nos haga descubrir la existencia de más de un nodo detrás de un servicio, como vamos a ver más adelante.

Dos nodos sirviendo distintos headers

En este caso, la característica que nos llevó a detectar múltiples nodos en un sitio web fue un header. Al revisar uno de los servidores web de Apple que tiene con tecnología Microsoft IIS, vimos que cuando pedíamos un documento ASPX que no existía, obteníamos una página de Error 404 aparentemente similar pero que no lo era. Esta es la respuesta del Nodo 1.

Figura 5: Mensaje de Error 404 del Framewok .NET en el Nodo 1

Si nos fiamos en los Response Headers de la siguiente imagen, podemos ver que el Nodo 2 tiene configurada la respuesta con el campo Server, donde se indica que es un Microsoft-IIS/6.0.

Figura 6: Mensaje de Error 404 del framework .NET en el Nodo 2

Por supuesto, de esto nos hubiéramos dado cuenta si nuestro sistema de pentesting persistente Faast no nos hubiera marcado que en este servidor se podía hacer un listado de directorios con el truco del IIS ShortName, así que, sabiendo que había dos nodos había que probar si este fallo estaba en uno o en los dos nodos.

Dos configuraciones distintas en los nodos

Probar un valor True con el bug del IIS Shortname exige poner el comienzo de un nombre de archivo que exista y un False el de uno que no exista. Esto nos permite hacer un proceso de booleanización para sacar los valores del nombre del archivo carácter a carácter. Con los servidores IIS 6.0 el resultado que se debe obtener, siguiendo la siguiente tabla de valor, es un Error 404 cuando existe un archivo que comienza por esa cadena y un Error 400 cuando no hay ningún archivo que comience por esa cadena.

Figura 7: Tabla de explotación del bug de IIS Shortname

Si miramos los resultados que se obtienen en el Nodo 1, se puede ver que cuando hay un archivo que comienza por esa cadena, en este caso la letra "a", se obtiene un Error 404 con un mensaje,

Figura 8: Archivo comenzando por letra "a" (sabemos que existe) da un Error 404 en Nodo 1

Por el contrario, cuando se solicita un archivo que comienza por la letra "X" y esta petición llega al Nodo 2, el resultado que se obtiene es un Error 404 con el mismo mensaje, lo que deja claro que NO se puede hacer un listado de directorios en formato 8:3 en este nodo del sitio web usando estas técnicas.

Figura 9: Archivo comenzando por letra "X" (sabemos que NO existe) da un Error 404 en Nodo 1

Por el contrario, si miramos los resultados que se obtienen con el Nodo 2 notamos diferencias. Cuando el archivo existe vemos un Error 404 con un mensaje de una única línea, tal y como indica la tabla de comprobación.

Figura 10: El archivo existe, así que se obtiene un Error 404 en Nodo 2

Pero cuando ponemos la cadena de un archivo que no existe, obtenemos otro Error 400 de Bad Request debido a que el archivo NO existe. Tal y como dice la tabla que se explotan estos fallos en la versión de IIS 6.0.

Figura 11: El archivo NO existe. Se obtiene un Error 400 en Nodo 2

Esto quiere decir que el Nodo 2  adolece de esta debilidad, mientras que el Nodo 1 está configurado de una forma que no permite esta manera de explotarlo.

Dos nodos con dos configuraciones distintas también en ASP

Esta configuración distinta de los tratamientos de errores se pude encontrar en muchos otros sitios, por ejemplo, en el código de Error 404 de ASP se puede ver que en el Nodo 1 sale un mensaje no controlado. 

Figura 12: Error 404 de framework ASP en el Nodo 1

Ese mensaje de arriba deja a las claras que es un IIS 6, ya que si no probablemente nos hubiéramos encontrado un mensaje de Error ASP de un servidor IIS migrado, mucho más verbose que éste. 

Figura 13: Error 404 ASP controlado en el Nodo 2

En el caso del Nodo 2, el mensaje de Error 404 de ASP está controlado y sale una página de Apple totalmente maquetada para evitar cualquier fuga de información. 

Más errores: ASP.NET, ColdFusion y JSP

Ya para terminar, volviendo al principio, no tiene porque pasar lo mismo en todos los frameworks, y si probamos con un archivo que no existe en el framework de ColdFusion, lo que obtendremos en todos los nodos es el mismo mensaje de error. Un Error 400 en este caso.

Figura 14: Error 400 con un not found en ColdFusion

Aún así, como veis, jugando con los mensajes de error de los distintos frameworks se puede sacar mucha información. Ya para terminar, me faltaba comprobar el Framework JSP, ya que si hay ColdFusion hay soporte para JSP y dependiendo de la licencia se puede obtener un Error 500 o un Error 404.

Figura 15: Errores por el framework JSP

Ya por último, igual que en el caso de Microsoft.com podemos intentar poner algún carácter o cadena de caracteres no válida para generar algún otro error del framework .NET (que sabemos que está). Simplemente, con dejar la tilde sin poner un número, se obtiene el Runtime Error de .NET.

Figura 16: Runtime Error en el framework .NET. Error 500

Al final, como se puede ver, jugando con los errores de una web, en todos sus frameworks y en todos los nodos de un sitio se puede llegar a obtener una gran cantidad de información. Hay que revisar todo que puede que, como en este caso, el administrador se deje muchos mensajes de error sin maquetar y controlar.

Saludos Malignos!

Un problema de licencia: Error 500 en Coldfusion

Después de hacer las pruebas con los mensajes de error 404 de JSP para incorporarlos a FOCA 3, se me ocurrió que un buen entorno para buscar servidores JSP serían los sitios con Coldfusion. Este servidor, primero de la empresa Allaire, luego de Macromedia y por último de Adobe, hace tiempo que está desarrollado en Java, y tiene soporte para aplicaciones JSP.


Figura 1: Sitios corriendo CFM en Google
Con esta premisa, realicé una prueba similar a la que forzar errores 404 en servidores con soporte a JSP, es decir, busqué sitios que tuvieron aplicativos desarrollados en CFM y solicité el mismo fichero pero cambiándole la extensión a JSP y el resultado me llevó a aprender una cosa curiosa que desconocía.


Figura 2: Error de licencia en un Coldfusion Standar corriendo sobre Apache


Figura 3: Error de licencia pero con poca información


Figura 4: Error de licencia de un Coldfusion Standar corriendo sobre IIS
Por lo visto, Coldfusion tiene varias licencias de venta, y no todas permiten hacer uso del motor JSP. En concreto, si el sitio sólo ha comprado una licencia Standard para desarrollo CFM puro, al invocar un programa con extensión JSP se generará una excepción 500 con un error de licencia muy curioso. Si no hay problema con la licencia, pues se obtendrá un error 404 de JSP como ya vimos.

Los mensajes de error que se obtienen son distintos, dependiendo de la versión exacta que corre de Coldfusion y el servidor web sobre el que se ejecuta. ¿Podría usar Adobe esta información para detectar software pirata de Coldfusion? Este error lo genera Coldfusion del que ya vimos que era bastante "verbose" en los fallos de SQL Injection, y en contadas excepciones he podido constatar que esté controlado, por lo que se puede sacar información del servidor allí implantado. Una curiosidad que integraremos en FOCA para extraer más info del sitio.

Saludos Malignos!

Fríos Errores

En muchos de mis chistes malos hacía sorna de las webs con fallos de seguridad que eran especialmente bonitas, esas en las que se notaba que habían sido hechas por una persona que había realizado un "Curso de Diseñador de Páginas" en lugar de por un "Programador de Aplicaciones Web". Desde hace tiempo las empresas grandes diferencian entre el Programador y el Diseñador, es decir, entre la lógica y la presentación.

Una de las tecnologías para desarrollo de aplicaciones web que se extendió con dignidad fue ColdFusion y nunca le presté mucha atención. Eran pocas las páginas con .cfm que me ponían como trabajo para jugar con ellas. Sin embargo, jugando con una web que-no-diré-dónde-no-diré-quién cerca de mi, me di cuenta que los mensajes de error son superbonitos... y que la mayoría de los sitios los tienen ...¿activos para debugging?

Desbordamiento de Tipos
Tras ver que los errores son bonitos, con su barrita azul, y sus links a documentación, me dio por hacer un poco de GoogleHacking buscando por sitios con aplicaciones del tipo .cfm?id= y el resultado fue... una escabechina. La web que no se come un SQL Injection basado en Errores, se come un Blind SQL Injection.

Error ODBC en SQL Server en Windows
Además, como se puede ver en los mensajes de error nos da la consulta completa, con información extendida, no cómo en los errores ODBC de otras técnologías. En la captura de arriba se obtienen también el nombre del DSN, útil para hacer ataques de webshells y webtrojans (ya hablaremos de ellos), la ruta local y, lógicamente, el tipo de servidor dónde corre la web.

Con MySQL y Linux
En un ratito, salieron un montón de cosas de estas de colorines azules, y sin hacer ninguna cosa extraña. Oracles, SQL Servers, MySQLs y demás amigos en el mundo de las bases de datos. Parecía el paraiso de los SQL Injection y yo muerto de sueño... En fin, menos mal que hoy he descansado.

Y eso, por favor, que el diseñador diseñe y el programador programe.

Saludos Malignos!