Bien conocido es que los Google/Bing dorks siguen siendo una de las formas más sencillas para detectar vulnerabilidades en servidores y servicios web, de ahí que me decida a hacer esta pequeña publicación hablando del que considero uno de los dorks más eficaces a la hora de detectar rápidamente servidores potencialmente vulnerables a Remote Code Execution.
JBoss es un servidor de aplicaciones Java Enterprise Edition muy utilizado a nivel global. Como es sabido, los aplicativos basados en Java EE suelen tener un gran tinte enterprise. Es decir, es muy común encontrarse aplicaciones empresariales de gestión escritas en Java, tal y como ocurre con .NET de Microsoft.
Una de las particularidades de JBoss es que provee, por defecto, de una consola de administración vía web que permite gestionar, configurar y desplegar servicios dentro del servidor JBoss. ¿Dónde está lo interesante? JBoss permite desplegar servicios contenidos en paquetes “WAR” directamente desde la consola web, de modo que si ésta puede ser accedida desde internet sin ningún tipo de restricción, cualquiera podrá desplegar servicios Java en el servidor JBoss.
La consola de JBoss se encuentra de forma general en la ruta /jmx-console. No es común cambiar el nombre de esta ruta, de modo que resulta sencillo encontrar consolas abiertas mediante una búsqueda en Google: inurl:«/jmx-console». El servicio suele encontrarse en puertos frecuentemente asociados a desarrollo (8080, 8081 …), aunque pueden encontrarse también multitud de ellas en puertos relacionados con entornos de producción (80 y 443) e incluso en puertos menos comunes.
Un ejemplo práctico
Al acceder a una de estas consolas, encontramos una interfaz similar a la de la siguiente imagen:
La consola muestra un índice con todos los servicios disponibles. Nos centraremos en el servicio MainDeployer, aunque también puede ser interesante el servicio ServerInfo.
El servicio ServerInfo muestra información sobre la arquitectura del servidor y el sistema operativo sobre el que corre la JVM.
El servicio JBoss MainDeployer permite hacer el despliegue de contenedores WAR. Lo peligroso es que acepta una URL como fuente del contenedor WAR.
¿Qué ocurre si el contenedor que pasamos por parámetros se encuentra en un servidor que controlamos y cuya finalidad es desplegar un JSP que acepte por parámetros POST o GET, comandos que posteriormente se ejecutarán en el sistema?
Bad news. Es posible ejecutar código remoto en el servidor. En el caso de la imagen anterior (caso ficticio en un entorno local a modo demostrativo), se obtiene control como usuario root en el servidor. Como lector, si tu perfil no es técnico, esto significa básicamente control total y absoluto sobre el servidor vulnerable.
Al automatizar la búsqueda de consolas JBoss haciendo algo de scrapping, se encuentran en pocos segundos más de dos centenares de servidores vulnerables distintos. Interesante ¿verdad?
[:]
