Español | English
rss facebook linkedin Twitter

Peligros del doble encoding en HTTP

En ocasiones, en el transcurso de una auditoria, nos encontramos con servidores intermedios cuya función es balancear las peticiones HTTP que les llegan por tal de distribuir el tráfico, para que no se congestione su red, o simplemente porque según el recurso al que se acceda con cada peticiones HTTP lo proporciona un servidor u otro.

En el servidor web apache, se puede utilizar el módulo “mod_jk” (http://tomcat.apache.org/connectors-doc/) para realizar este balanceo de carga. Para ello, se configuran un conjunto de workers (cada uno de los servidores a los que distribuiremos las peticiones HTTP), con las ip-s, puertos donde realizar las conexiones, etc.

A continuación se muestra la configuración establecida para el entorno en el que se realizarán las pruebas, se puede observar como en el caso de acceder a los directorios “Directorio1” y “ Directorio2” la petición se redirige hacia el servidor “workerArea” y en caso de acceder al directorio “Directorio3” la petición se envía hacia el servidor “workerArea2”.

• Archivo site.conf:

JkMount /Directorio1/* workerArea
JkMount /Directorio2/* workerArea
JkMount /Directorio3/* workerArea2


• Archivo worker.properties:

worker.list=workerArea
worker.workerArea.port=8009
worker.workerArea.host=XXX.XXX.XXX.XXX
worker.list=workerArea2
worker.worerArea2.port=8010
worker.workerArea2.host=XXX.XXX.XXX.XXX


A continuación, se muestra un esquema de la estructura de servidores, para aclarar el comportamiento del entorno.




A continuación, disponemos de dos peticiones en las que se puede visualizar como al realizar una petición se nos redirige hacia un servidor u otro en función del recurso solicitado.

shell:~$ curl -I http://site.es/
HTTP/1.1 301 Moved Permanently
Date: Fri, 19 Feb 2010 10:07:21 GMT
Server: Apache/2.0.52 (Red Hat)
Location: http://site.es/Directorio1/
Content-Type: text/html; charset=iso-8859-1



shell:~$ curl -I http://site.es/Directorio1/
HTTP/1.1 302 Movido temporalmente
Date: Fri, 19 Feb 2010 10:07:17 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
Set-Cookie: JSESSIONID=95E824FB90952A67B7AB14EF5AF22AF1; Path=/
Location: http://site.es/Directorio1/Page/Page.do;jsessionid=95E824FB90952A67B7AB14EF5AF22AF1
Vary: Accept-Encoding,User-Agent
Content-Type: text/html;charset=ISO-8859-1


Como se puede observar, en ambos casos, una de las cabeceras devueltas, nos indica que el servidor que recoge las peticiones es un Apache/2.0.52, mientras que en la segunda petición, al acceder a “Directorio1”, contiene la cabecera "X-Powered-By" que indica que, además, se trata del gestor de contenidos JBoss.

¿Que información podemos extraer de aquí? Pues que cuando se accede a dicho directorio se nos reenvía hacia otro servidor que está ejecutando un JBoss.

Sabemos que JBoss, dispone de dos directorios en los que se muestran dos paneles de administración:

• jmx-console
• web-console

En estos dos paneles se dispone de varias funcionalidades, como el poder acceder a información del servidor o incluso subir archivos al servidor para desplegar una aplicación y de esta manera tener acceso a la máquina (se recomienda la lectura de: “Who’s the JBoss now”: http://www.redteam-pentesting.de/publications/2009-11-30-Whitepaper_Whos-the-JBoss-now_RedTeam-Pentesting_EN.pdf).

Así pues, el siguiente paso será el de realizar una búsqueda de estos directorios para poder comprometer la máquina. Como estos directorios son del servidor, deberán encontrarse en la raíz de éste, y no en ninguno de los subdirectorios existentes en él. Esto viene a decir, que deberemos hallar la manera, de poder acceder a un directorio por encima del que nos encontramos. Para esto, utilizamos los ".." para acceder al directorio inmediatamente superior:

shell:~$ curl -I
http://site.es/Directorio1/../jmx-console/
HTTP/1.1 404 Not Found
Date: Fri, 19 Feb 2010 10:07:28 GMT
Server: Apache/2.0.52 (Red Hat)
Content-Type: text/html; charset=iso-8859-1


Como se puede ver en la anterior respuesta, nos indica que no se ha detectado el directorio, pero... la razón es, porque no se ha buscado en el lugar indicado. Como se puede ver, en las cabeceras que nos devuelve, indica que se está buscando en el servidor Apache que hace de intermediario, ya que interpreta el ".." como una orden hacia él, y en realidad realiza la búsqueda como si fuese la siguiente:

• http://site.es/jmx-console/

Por lo que deberemos realizar algún tipo de codificación a la cadena ".." para que aunque sea interpretada por el servidor intermediario, podamos llegar hasta nuestro objetivo. Así que, realizaremos una doble codificación en hexadecimal (codificar el símbolo, y a continuación el %), ya que si tan solo realizamos una el servidor intermediario decodificará la cadena, verá que es “..” y la seguirá interpretando.

Por lo que:

Normal: .
Hex Encoding: %2e
Doble Encoding: %252e


De esta forma, la petición resultante sería la siguiente:

shell:~$ curl -I
http://site.es/Directorio1/%252e%252e/jmx-console/
HTTP/1.1 200 OK
Date: Fri, 19 Feb 2010 10:07:36 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: Servlet 2.4; JBoss-4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)/Tomcat-5.5
Set-Cookie: JSESSIONID=8E3A3C9CA110AF43C224D4F5D74EF48B; Path=/
Content-Length: 287282
Vary: Accept-Encoding,User-Agent
Content-Type: text/html; charset=iso-8859-1


Como se puede observar, en este caso, el servidor que nos contesta es el JBoss, ya que el primer servidor interpreta la cadena %252e%252e, y esta queda como resultado %2e%2e. Éste, toma el valor de %2e%2e como si fuese un nombre de archivo, y dado que sigue estando dentro del directorio que él interpreta como que tiene que redirigir a otro servidor, se lo envía al servidor en el que se ejecuta el JBoss, sin tener en cuenta nada más. Por su lado, el servidor JBosss al recibir la petición, decodifica %2e%2e como ".." y al interpretarlo se accede a la consola jmx. El problema, radica en que el módulo "mod_jk" de Apache, que es quien realiza la redirección, decodifica la URL que recibe antes de enviarla hacia su destino, por lo que al realizar la doble codificación, es posible llegar hasta el servidor objetivo y acceder a recursos de éste (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-1860 ).


Abel Gómez
S21sec Auditoría

1 comentario:

Txalin dijo...

Hombre, proteger la jmx y la web console y que pida pass al acceder es (al menos yo) lo primero que hago al montar un jboss/tomcat/loqueseaconjava. De cualquier manera buen truco el del hexadecimal :)


(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2013 - Todos los derechos reservados


login