Descubrir servidores TomCat con errores JSP

Estos días, además de la compra de Motorola Mobility por parte de Google, se sigue hablando de lo de siempre, fallos de seguridad. Uno de los que estos días ha dado que hablar ha sido un bug que ya estaba resuelto, pero que ha vuelto a ser introducido en el proyecto TomCat, y que permite escribir ficheros protegidos desde el entorno de usuario. Aún cuando en la versión vulnerable exista el fallo, se tienen que dar una serie de condicionantes que en Una al día recogieron.

El caso es que, sorprendentemente, encontrar sitios con TomCat es mucho más sencillo de lo que parece, y lo es simplemente por un fallo a la hora de configurar de forma segura los mensajes de error que ofrece un servidor web. La idea es que, uno de los trucos más viejos a la hora de averiguar software que está corriendo un servidor consiste en generar un mensaje de error 404.


Figura 1: Error 404 en dominio .mil
Con este mensaje, en muchas ocasiones, se obtiene información más que suficiente como para saber la versión exacta de un servidor web e incluso algún módulo que está cargado en él. Por ello, muchos administradores, a la hora de poner en producción un servidor web el mensaje de error 404 lo controlan, mostrando un mensaje genérico.

Sin embargo, cuando se solicita un fichero que no existe, pero que está vinculado a un manejador de extensiones, es decir, un .aspx, un .jsp, o un .cfm, por poner algunos ejemplos, son estos frameworks los encargados de gestionar los mensajes de error. Y estos son los que el administrador se suele olvidar de cambiar.

Así, si por ejemplo hacemos una búsqueda por .jsp en los dominios .mil, encontramos una cantidad aproximada de 139.000 urls. Basta con abrir esas URLS y borrar una letrita del nombre del fichero, para ver qué mensaje de error se obtiene cuando se invoca un fichero JSP no existente.


Figura 2: Sitios con JSP en dominios .mil
Como se puede ver, sorprendentemente, la mayoría de los sitios contesta con la versión exacta de TomCat (o JBOSS). Yo elegí este dominio porque pensé que sería uno de los más fortificados, pero como se puede ver no es así.






Evidentemente, si pedimos el mismo fichero, pero con una extensión distinta, salvo que todas las extensiones estén asociadas al mismo framework, obtendremos mensajes 404 comunes, como en la figura 1. Una vez que se sabe que hay JSP, y qué servidor de aplicaciones se está utilizando en concreto, las labores de búsqueda del panel de administración son mucho más sencillas. Tal vez baste con pedir la misma URL por el puerto 8080, tal vez o sea necesario hacer un escaneo de todo el rango de red por el puerto 8080, pero lo que es evidente es que saber la tecnología del servidor te ayuda a tomar el mejor camino.

En los ejemplos he puesto casos con TomCat, pero esto también pasa con el resto de servidores de aplicaciones, como Oracle Application Server, JBOSS (y sus magníficas consolas con passwords por defecto), etc...

Saludos Malignos!