Antes que nada quiero aclarar dos cosas:

1. Las vulnerabilidades ya las “corregimos“
2. Este articulo lo publico con la COMPLETA AUTORIZACIÓN de la “SECRETARIA DE ASUNTOS ESCOLARES de la Facultad de Arquitectura“

Hace unas semanas me encontre algunas simples vulnerabilidades que afectaban gravemente el sistema de la “Secretaria de Asuntos Escolares” de la facultad de Arquitectura, estas vulnerabilidades afectaban a los alumnos de la siguiente forma:

• Revelaban TODA su información confidencial!!! (Cuando digo toda, es TODA!!!!) entre lo que se destacaba (Nombre, Fotografia, dirección COMPLETA, Fecha de Nacimiento, CURP, Telefono, celular, mail, y contacto de emergencia)
• Permitía cambiar sus datos personales. (Hasta se podia modificar el Nombre)
• Permitía modificar su fotografia.
• Revelaba sus materias inscritas y por ende su horario.
• Se podían crear cuentas falsas para subir cualquier tipo de contenido (Imagenes, documentos, texto, malware, pornografía,etc…)
• Y por ultimo se podian averiguar numeros de cuentas validos de los alumnos.

Vamos por partes y ver cada uno de los puntos.

El sistema vulnerable es el que otorga acceso a los alumnos para poder actualizar sus datos y obtener su ficha de comprobante. En este panel se pide el numero de cuenta y contraseña (Por defecto fecha de nacimiento)

Al ingresar LEGITIMAMENTE para actualizar los datos, la url formada es algo así:

http://escolares.arq.unam.mx/escolares_l/view/datos_alumno/actualizarDatosAlumno.php?sid=NUMERO-DE-SESION&carrera=ARQUITECTURA

En primera instancia vemos que los datos se estan pasando por el metodo GET y la variable “sid” es la que obtiene el Numero de Sesion. Este numero de sesion es aleatorio y de 26 caracteres. Cuando vi ese numero de sesión supe podia haber algo medio chueco. Asi que lo que hice fue restarle -1 al ultimo caracter para ver que sucedia. Si el numero de sesion era 89e94f7c8c505c77fa9ca94112 lo converti a 89e94f7c8c505c77fa9ca94111

Obviamente esto no me llevo a nada. Sin embargo se me ocurrio algo mejor =)

SQL inyection

Si a la variable “sid” le inyectaba un SQL inyection. VOILA!!! Al final nuestra URL maliciosa sera:

http://escolares.arq.unam.mx/escolares_l/view/datos_alumno/actualizarDatosAlumno.php?sid=%27%20or%20%271%27%20=%20%271&carrera=ARQUITECTURA

¿Que pasa con esa URL?

Al ingresar a esta URL nos devolvia un perfil seleccionado aleatoriamente de cualquier alumno. Pudiendo ver todos sus datos como se muestra en la siguiente imagen:

Como se entenderá esto es muy grave!! Imagínense esta información en manos de un acosador, extorsionador, difamador, etc…

Mas aún, que existe la posibilidad de MODIFICAR los datos!!

Un atacante puede modificar, TODA (NOMBRE, dirección, CONTACTO DE EMERGENCIA, telefonos, correo,etc…)y repito TODA la información de cualquier alumno. E incluso se puede modificar la FOTOGRAFIA y remplazarla por una nueva.

Por ejemplo la imagen de esta alumna. Vemos su información confidencial mas su fotografía. Pero dándonos la opción de modificarla.

Podemos ver como intentamos suplantar la imagen de la alumna por cualquier otra.

Al final vemos como la foto de la alumna es suplantada, y actualizada en el sistema. Ahora cada vez que la chica haga un tramite Formal en la facultad, en vez de ver su fotografía, vera un simpatico cocodrilo (Y probablemente a ella le de un paro cardíaco)

NOTA: Todo cambio fue regresado a la normalidad. Y en ningún momento las pruebas que hice fueron permanentes. AL FINAL NINGÚN alumno fue afectado por esta demostración. Así mismo la facultad de Arquitectura posteriormente arreglo todo y dejo todo a la normalidad.

<< No solo la foto. También el Nombre. >>

De los datos mas sensibles a modificar serian la fotografía y el nombre.. SI EL NOMBRE!!!

Aunque en si se tiene una pequeña protección del HTML para no poder modificar ese campo. Todo se manda al final. Y si cachamos eso por ejemplo con Tamper Data!! Voila!!! Podemos modificar Exitosamente su información.

Como se puede ver en el siguiente ejemplo capturamos todos los campos y desde ahí los podemos modificar (Como el nombre que se supone no se puede modificar):

Ahora que ya vimos podemos modificar la información de nuestra victima (alumno) veamos que podemos recabar varia información de está.

Esto es posible ya que otro script es vulnerable. Ahora nos referimos al script inscribe.php que posee la misma vulnerabilidad por lo que la url era la siguiente: http://escolares.arq.unam.mx/escolares_l/view/datos_alumno/inscribe.php?sid=%27%20or%20%271%27%20=%20%271&carrera=ARQUITECTURA (Este Script ya fue dado de baja por lo que devuelve un 404)

En este script nos da acceso a imprimir el “Comprobante de Inscripción definitivo” Osea las materias que se inscribieron. ¿Cual es el problema con este “Disclosure”?

El problema radica en que sabiendo las materias/grupos que el comprobante provee, se puede saber el Salón y HORARIO del alumno.

¿Y? Imaginemos esto en malas manos y tendremos == “Acosadores/Extorsionadores/Bromas/Hostigadores/ a la orden del dia”

Esto en las manos de un Extorsionador es mucho poder. Saber donde vives, como te ves (Foto), como te llamas, tu telefono, tu correo, tu contacto de emergencia y mas aún, saber DONDE ESTAS TODOS LOS DIAS EN QUE HORARIO Y EN QUE SALÓN…yo no se ustedes pero esto suena a GRAVE no?

::: Afortunadamente todos estos problemas ya fueron corregidos :::

Uff Ya fue todo verdad?……….¿VERDAD?

Aun hay detalles técnicos interesantes!!

El upload de las imágenes no realizaba verificación alguna de los datos que se subían. Permitia subir cualquier cosa que no fuera una imagen JPG. Lo único que hacia, era revisar el nombre del archivo que se subia, borraba la extensión que tuviera y le adjuntaba la extensión JPG.

Ej: algo.exe > algo.jpg

Se hizo una pequeña prueba subiendo el siguiente archivo 69696969.php

Y al consultar el archivo se verifico que borro el .php y lo cambio por .jpg

Ya se!! Ya se!! Me dirán…¿Qué caso tiene, si no puedo subir una shell? Recuerden que yo estoy auditando, no quiero fregarme a nadie. Pero en si tenemos un poderoso “Hosting” donde podríamos distribuir malware y vendría de un servidor de la UNAM.

Ya por ultimo. Una de las cosas que me divirtió bastante (puesto que use bash ) fue una pequeña “”vulnerabilidad”" (Notese la doble comilla) en como se guardaban las fotografías de los alumnos.

¿Qué pasaba aquí? El problema que yo vi es que los nombres de los archivos eran los números de cuenta de los alumnos. Esto deriva que si yo se el numero de cuenta de alguien, puedo bajarme su fotografía. Ahora para los que no son de la UNAM, deben saber que estos números de cuenta siguen un patrón!! Por lo que con un simple programa de fuerza bruta puedo adivinar números de cuenta VALIDOS y bajarme las fotografías!!

En la siguiente imagen cree un pequeño script en bash que hace consultas a la URL donde se guardan las fotografías y a partir de ahí hago un bruteforce de los números, si la consulta de devuelve un 404 es que la cuenta no existe y pinta un punto (.) si existe me pinta una cruz (+). Y como verán en las primeras consultas salieron 2 numeros de cuenta validos. Y podemos visitar el numero de cuenta de esa persona y ver su fotografía.

Ahora un atacante se puede ir a comer una pizza mientras deja el script corriendo y puede obtener 766 números de cuentas como yo conseguí en un par de horas. Y claro bajar las imágenes. Aquí una pequeña muestra de la porcion de cantidad de imágenes de alumnos que conseguí

¿Bueno y qué? ¿Ya te crees bien buenote por conseguir unos números de cuenta validos no? ¿Qué puedes hacer con ellos?

En sí, son muy útiles ya que con ellos puedo lanzar otro ataque de fuerza bruta y mandar el formulario, ya que la contraseña de los usuarios es su fecha de nacimiento. Así que basta con hacer unos simples bucles y en unas horas la contraseña de algunos estarán en nuestras manos.

Hasta aquí es todo. Decir que la facultad de Arquitectura me dio permiso explicito de publicar esta información y mas aun feliz por que me pidió volverlos a auditar

Sobre mis actos Ilegales:

Debo decir que lo que realice fue “ILEGAL” antes de realizarlo yo sabía esto y se hizo sabiendo las posibles consecuencias. Entrar a un sistema “protegido” por algún método (Aunque este sea vulnerable) de manera no autorizada, en México es Ilegal. Agradezco mucho a la facultad de Arquitectura y a la “Secretaria de Servicios escolares” por ser tan abiertos y tomar en cuenta las observaciones sin tomarlo de mala manera.

Sobre la Ilegalidad de la UNAM y la LFPDPPP:

La UNAM incurrió también en un delito y es imprescindible los alumnos y la UNAM sepan esto. La UNAM esta obligada a cumplir con la Ley Federal de Protección de Datos Personales en Posesión de Particulares” Esto quiere decir que la UNAM debe ASEGURAR que nuestros datos están protegidos y bajo que sistemas están protegidos. Y estas vulnerabilidades hacen incurra en un delito. En esta parte un alumno podría presentar una queja formal ante la IFAI.

Las anteriores aseveraciones fueron respaldadas en mi asesoramiento con el experto abogado en Delitos Informáticos Joel Gomez.

Sin mas hasta aqui es suficiente. Posiblemente después hable sobre algunas fallas que la facultad de Ingeniería también tiene. (Y debo decir que son peores )

Nota: Al atacante (anonmx) de Neobits.org de hace unas semanas debo decirle que sino había publicado este post era por que no estaba terminado!! (No era difícil deducir eso). Al final agradezco no paso a mayores estragos. Pero para la próxima lo invito a mandarme un mail a hecky@neobits.org o mandeme un tweet ya que esta al pendiente de mi por esa red social

Ahora sí hasta aquí es todo. Gracias por leer.

P.D. Alumos de Arquitectura, pueden dormir tranquilos que sus datos YA ESTAN PROTEGIDOS!!! Y un Aplauso para la pronta Respuesta de la “Secretaria de asuntos escolares de la Facultad de Arquitectura!

Saludos

Atentamente: Héctor Cuevas Cruz (hecky)

hecky@neobits.org

Sigueme en Twitter: http://twitter.com/hecky