Cómo pude haber aprobado un máster sin estudiar... pero lo reporté

Hace un tiempo comencé a buscar información sobre algún Máster para profundizar en mis estudios de informática. En la actualidad, con lo amplio que es el mundo del conocimiento en informática, se quedan cortos los pocos años de la Ingeniería de Informática de Sistemas que he estudiado en la URJC y quería profundizar algo más. Así que, utilicé Internet para revisar las ofertas de másteres en las universidades que más me llamaban la atención, escrutando la información que ofrecen en sus páginas web.

Figura 1: Cómo pude haber aprobado un máster sin estudiar... pero lo reporté

Pero la "deformidad profesional" que tengo en el desarrollo de "canales digitales" - una manera muy moderna de llamar a los puntos de interacción con los clientes, ya sean páginas web, aplicaciones móviles, los famosos chatbots o las redes sociales - me llevó a profundizar un poco más en algunas de las webs de las universidades en cómo estaban diseñadas y acabar haciendo algo de Hacking Web Technologies, lo que me llevó a descubrir un fallo de seguridad bastante relevante en la web de UAB.

Está página me llamo la atención porque descubrí que estaba desarrollada con un gestor de contenidos sobre el que tengo bastante conocimiento, Oracle Webcenter Sites. En concreto, delató el uso de este gestor de contenidos el formato no amigable de las URLs.

Figura 2: URLs del portal de contenidos

Esto se puede configurar de otra forma, pero a partir de este pequeño detalle, un cúmulo de errores mucho mayores en la gestión de la seguridad da a cualquier persona la capacidad de acceder a la base de datos de la web, al gestor de contenidos e incluso poder ejecutar una Shell Remota contra los servidores de la universidad. En definitiva, cualquier persona podría aprobar el máster sin pasar por clase - a falta de ver otros controles que se tengan más allá del sistema informático .-  Para entender bien el problema, hay que tener en cuenta dos cosas principalmente.

• Arquitectura de Webcenter Sites: La arquitectura común de Webcenter Sites, es similar a la de cualquier otro gestor de contenidos. Existe un usuario "lector" capaz de navegar por la web de manera pública, pero sin acceso a la aplicación de gestión de contenidos. Este "bloqueo" de acceso, como en otros gestores está basado en permisos de usuario. 

• Aplicaciones de Gestión de Webcenter Sites: Es habitual en este gestor de contenidos instalar una "extensión" comúnmente conocida como Support-Tools que nos brinda unas herramientas para detallar la configuración del servidor donde se instala Webcenter Sites, y que además nos habilita de un catálogo operaciones de mantenimiento/administración extremadamente útiles. El acceso a esta extensión, como ocurre con el acceso a la interfaz de "contribución" de contenidos está basado en Roles.

Los errores en esta web

En este caso existían dos errores graves que permitían el ataque:

1.- Se ha dejado accesible desde internet el acceso a la herramienta "Support-Tool" 

2.- Se ha otorgado al usuario "lector" el ROL necesario para acceder a la herramienta "Support-Tool"

Y a partir de esto,  cualquier atacante podría tomar control del sistema. Vamos a ver cómo es el proceso. Como ya os he dicho, conocía el gestor de contenidos, así que lo primero que miré al llegar a la web fue ver si estaba accesible la herramienta Support-Tool desde Internet, y como veis el resultado fue positivo.

Figura 3: Support-Tool expuesta a Internet

Esto es un error de fortificación, ya que habría que reducir la superficie de exposición, haciendo que solo estuviera accesible desde dentro de la red, o vía conexiones VPN, pero en muchos casos, acaban siendo publicadas en Internet.

Como se puede ver, el portal además se ofrece vía HTTP, y no bajo HTTPs, lo que es un problema que permite a cualquier ataque de sniffing o man in the middle, capturar las credenciales de los usuarios, algo muy peligroso cuando hablamos de un sistema expuesto a Internet.

Figura 4: Páginas de administración indexadas en Google

Lo siguiente, lógicamente, era comprobar las credenciales, para ver si tenían los usuarios por defecto con sus passwords por defecto, si habrían implementado sistemas de Segundo Factor de Autenticación como Latch o como un TOTP, o no. Probé con los usuarios por defecto, los cuales rechazaban el login. Pero una última prueba me reveló el problema del rol que os comenté antes. Las páginas de administración de la herramienta eran accesibles sin necesidad de password de administración o gestión.

Figura 5: Páginas de administración accesibles sin necesidad de sesión de administración

Una vez dentro se pueden realizar multitud de operaciones, entre ellas tirar consultas contra el motor de la base de datos del gestor de contenidos. Siendo posible poder recuperar, por ejemplo, el listado de usuarios existentes con los hashes de las passwords.

Figura 6: Consulta para sacar los usuarios del SGBD

Realizar cambios sobre el SGBD ya nos da acceso casi completo a la web, pero la sorpresa vino cuando al tratar de descifrar el password del usuario administrador desde una herramienta de coincidencias online, se produjo un "match".

Figura 7: Hash de password de administrador descifrado

Este match quiere decir que tenemos acceso a la herramienta como usuario administrador. Lo que nos permitirá además de modificar la web a nuestro antojo, subir diferentes programas Java - como una Shell Remota, o un RansomWare tan de moda últimamente - que se  ejecutará sobre la máquina el usuario que esté corriendo el servidor. Por supuesto, no había configurado ningún 2FA como Latch, por lo que una vez que se tiene la password, cualquiera puede entrar.

Figura 8: Acceso como Administrador

En resumen, lo que me encontré fue:

- Exposición de portal de administración en Internet. 

-  Páginas de login sin usar conexiones cifradas bajo HTTPs. 

- Gestión de sesiones inseguras, lo que permitía acceder a administración. 

- Usuarios sin 2FA. 

- Webs sin auditorías de seguridad.

- Mala gestión de las opciones de indexación del sitio web.

Después de esta aventura no acabé con cinco másters y una beca pre-concedida para el resto de mi vida. Les avisé de todo esto a los administradores del sitio, y a día de hoy la web ha sido cambiada por completa. Con esto aprendí que antes de que se publique cualquier tecnología por un "canal digital" hay que hacerle unas buenas pruebas de seguridad.

Saludos y a estudiar mucho, no seáis malignos!

Autor: Eduardo Trujillo, Ingeniero de Sistemas.