Bueno, tras un extenso parón espero poder retomar poco a poco el ritmo del blog. Animo al resto de “editores” a que publiquen algo y así no se note tanto cuando alguno entramos en un agujero negro. Y si alguno de los que estáis por Sevilla en esto de la seguridad queréis publicar algo, pues hacedmelo llegar, ¿ok?
Hoy quiero hablaros de un detalle de inseguridad de los visores de SIG (Sistemas de Información Geográfica). El visor es una aplicación web que extrae las imágenes de un mapa de alguna base de datos con localización geográfica (el SIG propiamente dicho). Sobre estas imágenes es posible añadir ‘capas’ que no es otra cosa que más información relacionada con la posición.
Muchos de estos visores te dejan, como usuario, añadir nuevas capas de otras fuentes para crear tu propio mapa. Otros ya traen sus capas fijas y puedes añadirlas o quitarlas pero sólo esas.
Ahora bien, la implementación de la funcionalidad de añadir capas suele incluir un cuadro de diálogo donde le pones un nombre, le indicas una URL para descargarla y le pones qué tipo de capa es (hay varias opciones).
Internamente, es el servidor el que se conecta al recurso, se lo descarga y lo devuelve al navegador. Lo bueno (o lo malo, según se mire) es que de este modo es posible solicitar cualquier URL que queramos y el servidor la pillará para nosotros.
Analicemos un poco esta situación: básicamente esta funcionalidad es un proxy que se ejecuta en un servidor en una red interna del organismo correspondiente al que le puedes solicitar cualquier URL, incluso de equipos internos. De hecho, en algunos SIG que he visto la URL se llama proxy o MapProxy o similar.
¿Cómo identificar esta funcionalidad? Si se trata de un visor que acepta capas, nada más fácil que añadir una URL cualquier y observar con un proxy de interceptación (Burp, por ejemplo) a ver qué URL utiliza. Si tenéis algún servidor web por ahí, ponedlo y echad un ojo a los logs.
Si no acepta capas, esta funcionalidad de proxy puede estar presente aunque no se use en la aplicación web y conviene echar un ojo al código fuente de los ficheros javascript para identificar la URL en cuestión.
Por lo tanto, si hacemos un análisis de seguridad a un organismo que tiene un SIG con esta ‘vulnerabilidad’ ya tenemos una forma de acceder a sus webs internas.
Pero ojo, ese no es el único problema, que te usen como ‘proxy’ abierto para hacer fechorías te puede traer muchos problemas (consumo de ancho de banda, inclusión en listas negras, ser origen de ‘delitos’, etc.).
Algunas limitaciones de este tipo de proxies:
- El método HTTP está fijado, en algunos es GET y en otros, POST.
- Normalmente no es posible generar solicitudes complejas, ya que la URL que pongamos es un parámetro de otra URL, incluir variables puede no acabar de funcionar.
- Los enlaces de la página interna no funcionan, claro, porque no tienen en cuenta que hemos accedido de una forma subrepticia.
- A veces el Content-Type es xml y el navegador no lo acaba llevando bien.
¿Cómo solucionar esto? Pues si no se trata de un visor SIG con capacidad para añadir capas, desactivando la funcionalidad ‘proxy’.
Por el contrario, si se trata de un visor SIG para añadir capas externas, se podrían filtrar las URLs con algún criterio o comprobar que la vuelta efectivamente corresponde al formato esperado. También se puede hacer que sea el navegador el que descargue el recurso y no el servidor, evitando este problema.
Y, como siempre, registrad logs y echad un ojo de vez en cuando no vaya ser que…
ACTUALIZACIÓN:
Ups “que sea el navegador el que descargue el recurso y no el servidor“. Acabo de comerme la Same-Origin Policy (aka SOP). Luego pensando me he dado cuenta de que igual no es tan fácil esta opción así de primeras.
Probablemente lo mejor sería comprobar que el fichero se ajusta al DTD específico del tipo de mapa que se quiere cargar, evitando servirlo si no es un fichero esperado y no enviando ciegamente lo que se descargue de la URL.
