Solucionados los problemas de seguridad en la web de La Moncloa

Pasadas poco más de 24 horas desde que hiciera público el problema de seguridad en la web de La Moncloa, los administradores han hecho lo que debían hacer, configurar el servidor como es debido, cerrando de esta forma la posible vulnerabilidad. Llegados a este punto, es el momento de explicar lo que hicieron mal.

Cualquier producto de software multiusuario en un entorno seguro, corriendo bajo cualquier plataforma, programado en cualquier lenguaje, debe cumplir tres premisas básicas de seguridad:

a) Debe validar los datos que introduce el usuario
b) En caso error, no debe dar información detallada al usuario de que algo ha ido mal
c) No debe facilitar el acceso a información sensible que pueda permitir a un usuario no autorizado conocer los mecanismos internos del software

Ninguna de estas tres premisas se cumplían en el servidor web de La Moncloa. La aplicación web que diseñaron, no validaba, y en este mismo momento sigue sin validar, los datos que introducía el usuario, permitiéndole producir errores en tiempo de ejecución (punto a). Además, estos errores, informaban al usuario con todo detalle de cual era el problema (punto b) facilitándole el acceso a información sensible a la que no debería de poder acceder (punto c).

Un ejemplo práctico de una aplicación web corriendo en un servidor IIS programada en VBScript (esto se puede extrapolar a otro tipo de software, otras plataformas y otros lenguajes).

Supongamos una URL como la siguiente:
http://servidor/noticia.asp?ID=5000

El archivo «noticia.asp» contiene código en VBScript que le permite conectarse a una base de datos, leer el contenido de una noticia específica (en este caso, la 5000) y le devuelve la información al usuario en formato HTML.

Un usuario podría modificar la URL de tal forma que quedara de la siguiente forma:
http://servidor/noticia.asp?ID=’

Solo hemos cambiado el número 5000 por una comilla simple (‘). Podríamos usar otro carácter, como una letra, o un numero muy alto, o simplemente, no poner nada. El código VBScript del archivo debería reconocer que el usuario ha introducido un valor fuera del rango permitido. Si no lo hace, el servidor dejara de procesar el archivo y devolverá un error (para mas información sobre como efectuar la validación de los datos que introduce el usuario, os recomiendo otro artículo escrito por mi: Verificando lo que introduce el usuario).

Si el servidor devuelve demasiada información, el usuario tendría una buena oportunidad para poder crear una cadena de texto malformada que le permitiera seguir investigando el problema, o incluso peor, el acceso a información sensible. El mensaje de error del que estamos hablando podría decir algo asi:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC Microsoft Access 97 Driver] Data type mismatch in criteria expression.
/noticia.asp, line 15

No hay demasiada maldad en ese mensaje, pero si en vez de eso, nos devuelve algo como:

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC Microsoft Access 97 Driver] Data type mismatch in criteria expression.
/includes/database.inc, line 15

Ya hemos facilitado al usuario información adicional que no necesitaba, le hemos revelado que nuestro archivo «noticias.asp» depende del archivo «database.inc», y si este usuario fuera lo suficientemente curioso, lo primero que intentaría hacer sera buscar más información con referencia a ese archivo. Por ejemplo, escribiendo en su navegador la URL:
http://servidor/includes/database.inc

Los archivos con extensión «.inc», suelen ser simples archivos de texto que contienen código común a varios archivos con extensión «.asp». Por convenio para los archivos con código común se suele usar la extensión «.inc», lo que, desde el punto de vista del servidor, los convierte en archivos de texto que pueden ser enviados al usuario, aunque esa no es la finalidad. Los archivos «.inc», al igual que los archivos «.asp», han de ser ejecutados en el servidor, y por ello se le deben asignar solo permisos de ejecución, nunca de lectura. El servidor sabe que tiene que ejecutar los archivos «.asp», pero no sabe que también lo tiene que hacer con los archivos «.inc», por eso debemos fijar estos permisos manualmente.

Volviendo al archivo «database.inc», por el nombre podemos deducir que contiene código común para efectuar una conexión a una base de datos. En las conexiones a bases de datos, por regla general, hay que especificar un nombre de usuario y un password. Si un usuario se hace con esta información, nuestra base de datos podría quedar comprometida.

De esta forma tan simple, fue como conseguí hacerme con el nombre de usuario y el password de la página web de La Moncloa, lo cual no quiere decir que pudiera haber modificado el contenido de la base de datos. Este solo sería el 10% del camino, aún nos quedaría por localizar el servidor que hospeda la base de datos, que podría no ser el mismo que aloja la web, conectarnos a la base de datos si el servidor no se encuentra protegida por un firewall o está una intranet, y además, el nombre de usuario y el password deberían tener permisos de lectura y escritura.

Podría añadir muchas más cosas, pero el tiempo se me echa encima. Además, tengo que guardarme algo para poder seguir escribiendo en el futuro. Solo me queda darle las gracias a aquella gente que ha confiado en mi, a los que me han aconsejado, y a los que me han tenido que aguantar. Gracias a todos, y gracias también a los que se han molestado en leerme.