Un actor identificado como Dianna publicó en un foro clandestino una supuesta filtración atribuida a la Universidad Da Vinci de Guatemala.
La publicación afirma que fueron expuestos 98,099 archivos JSON y 16,000 fotografías de estudiantes. También menciona endpoints del portal uvirtual.udv.edu.gt asociados a consulta de información personal y fotografías.
En este caso, la revisión no se quedó únicamente en la publicación del actor. Se analizó una PoC descargada con dos conjuntos principales de archivos:
- carpeta
estudiantes/con 98,099 JSON - carpeta
udv/con 16,821 JPG - tamaño total aproximado de la muestra revisada: 2.2 GB
No se reproducen datos personales, fotografías identificables, tokens, parámetros completos ni endpoints explotables en esta publicación.
Nota de divulgación responsable
Esta publicación documenta hallazgos técnicos de forma responsable.
Por esa razón:
- no se publican registros JSON completos
- no se publican fotografías de estudiantes
- no se publican identificaciones, teléfonos, correos ni direcciones
- no se publican tokens reales
- no se publican URLs completas con parámetros funcionales
- no se publican valores reales de
CIF,IDUoUsuario
El objetivo es explicar el patrón técnico observado, no facilitar abuso adicional.
Resumen ejecutivo
La PoC revisada contiene un volumen significativo de información personal estructurada.
Se validaron 98,099 JSON válidos y 16,821 fotografías. Los JSON tienen una estructura uniforme y contienen campos como nombre, apellidos, identificación, CIF, dirección, teléfonos y correo electrónico.
La evidencia técnica apunta a abuso de endpoints AJAX del portal uvirtual.udv.edu.gt, con dos patrones principales:
- obtención de fotografías mediante un parámetro asociado al
CIF - obtención de información personal mediante parámetros como
IDUoUsuario
La lectura técnica más relevante es que esto no parece un problema de WAF. El problema apunta a autorización insuficiente a nivel de objeto, tipo IDOR/BOLA.
Si el backend entrega la foto o los datos personales solo porque se cambia un identificador, el control que falla no está en el perímetro. Está en la lógica de autorización del servidor.
Qué contiene la PoC
La PoC está organizada en dos carpetas:
estudiantes/
udv/
La carpeta estudiantes/ contiene archivos JSON. La carpeta udv/ contiene fotografías en formato JPG.
Conteo observado
| Conjunto | Cantidad | Tamaño aproximado |
|---|---|---|
estudiantes/ |
98,099 JSON | 1.2 GB |
udv/ |
16,821 JPG | 1.1 GB |
| Total | 114,920 archivos | 2.2 GB |
La afirmación del actor sobre 98,099 JSON coincide con el conteo observado. La afirmación de 16,000 fotografías también es consistente, ya que la carpeta de imágenes contiene 16,821 archivos JPG.
Estructura de los JSON
Se validaron los archivos JSON del conjunto estudiantes/.
Resultado:
- JSON válidos: 98,099
- JSON inválidos: 0
Todos los registros observados mantienen una estructura uniforme con campos como:
IDUNombreApellidosIdentificacionCIFEstado_CivilFecha_NacimientoLugar_NacimientoDireccionDepartamentoMunicipioZonaCelularTelefono_CasaOtro_NumeroCorreo
Esto no parece una recopilación manual desordenada. La consistencia del formato apunta a una extracción sistemática desde una fuente estructurada.
Datos personales expuestos
En la muestra revisada se observaron campos con información personal sensible.
Campos con alta presencia de contenido:
| Campo | Registros con valor no vacío |
|---|---|
IDU |
98,099 |
Nombre |
98,023 |
Apellidos |
98,019 |
Identificacion |
98,088 |
CIF |
98,097 |
Celular |
98,098 |
Telefono_Casa |
98,098 |
Otro_Numero |
98,098 |
Correo |
89,026 |
Lugar_Nacimiento |
87,112 |
Direccion |
68,265 |
Esto es relevante porque no se trata solo de nombres o correos. La PoC contiene identificadores, teléfonos, direcciones y fotografías asociadas a estudiantes.
Ese tipo de información puede ser utilizado para suplantación, ingeniería social, fraude documental, acoso, extorsión o creación de perfiles personales.
Numeración observada en los JSON
Los archivos JSON están nombrados con identificadores numéricos.
Se observó:
| Métrica | Valor |
|---|---|
| JSON con nombre numérico | 98,099 |
| ID mínimo | 2 |
| ID máximo | 130000 |
| Rango teórico | 129,999 |
| Faltantes estimados | 31,900 |
A diferencia del caso MINEDUC, aquí sí existen gaps en el rango. Eso no descarta enumeración. Puede indicar registros inexistentes, eliminados, no accesibles o respuestas no guardadas cuando no existía información válida.
La lectura más prudente es:
La PoC contiene archivos JSON nombrados con IDs numéricos entre 2 y 130000. Aunque hay huecos, el patrón es compatible con extracción automatizada de registros válidos a partir de identificadores.
Correlación entre JSON y fotografías
Un hallazgo importante fue la relación entre las fotografías y el campo CIF.
El conjunto udv/ contiene 16,821 fotografías.
Se compararon los nombres de archivo de las fotografías contra campos presentes en los JSON. El resultado fue:
| Campo comparado | Coincidencias con nombre de fotografía |
|---|---|
IDU |
0 |
Identificacion |
319 |
CIF |
16,787 |
Celular |
0 |
Telefono_Casa |
0 |
Otro_Numero |
0 |
El patrón dominante es claro: las fotografías correlacionan principalmente con el campo CIF.
De 16,821 fotos, 16,787 coinciden con valores CIF presentes en los JSON. Eso equivale aproximadamente al 99.8% de las fotografías.
Esto sugiere que las fotos no están nombradas al azar. Están asociadas a un identificador presente en los registros del estudiante.
Endpoints AJAX observados
La evidencia apunta a abuso de endpoints AJAX del portal uvirtual.udv.edu.gt.
Se identificaron dos rutas lógicas distintas:
/estudiantes/ajax/obtenerImagen.aspx?cifHijo=<CIF>
/estudiantes/Ajax/Ajax_InformacionPersonales.aspx?IDU=<IDU>&Usuario=<USUARIO>&Compania=<COMPANIA>&Sucursal=<SUCURSAL>&Token=<TOKEN>&_=<CACHEBUSTER>
No se publican valores reales de CIF, IDU, Usuario, Token ni parámetros completos.
Endpoint de fotografías
Se validó que obtenerImagen.aspx permite recuperar fotografías modificando únicamente el parámetro cifHijo.
Esto coincide con la correlación realizada sobre la PoC:
- 16,787 fotografías coinciden con valores
CIF - eso representa aproximadamente 99.8% de las fotos
La lectura es directa: la ruta de imagen depende del CIF y no se observó una validación efectiva de autorización que impidiera consultar fotografías de terceros.
Endpoint de información personal
También se validó que Ajax_InformacionPersonales.aspx devuelve información personal al modificar parámetros como IDU o Usuario.
La respuesta no es únicamente un JSON simple. El endpoint devuelve HTML renderizado de la sección Mis Datos Personales, con datos personales embebidos directamente en la vista.
En el fragmento revisado se observan campos como:
- nombre
- apellidos
- identificación
- CIF
- fecha de nacimiento
- lugar de nacimiento
- dirección
- teléfono celular
- teléfono de casa
- otro número
- correo electrónico
- información familiar
- datos de perfil del estudiante
También se observa que la propia vista carga la fotografía mediante una ruta AJAX con el parámetro cifHijo.
Aunque la URL incluye un parámetro Token, la evidencia observada indica que este no impide la consulta de registros ajenos si se cambian los identificadores.
No se publica el HTML completo porque contiene PII y posibles secretos expuestos del lado cliente.
Hallazgo adicional: respuesta HTML con datos sensibles
El fragmento de respuesta revisado muestra que el endpoint devuelve HTML de la sección Mis Datos Personales con información sensible ya renderizada.
Entre los elementos observados hay campos ocultos, valores de perfil, datos de contacto y una referencia directa a la imagen del estudiante mediante obtenerImagen.aspx?cifHijo=<CIF>.
También se observó un campo oculto asociado a TokenInformacionPersonales con un valor que no aparenta funcionar como token robusto de autorización.
Adicionalmente, en el HTML se observó una clave de servicio de validación de correo expuesta del lado cliente. No se reproduce el valor por razones de seguridad.
Estos elementos refuerzan la lectura técnica: el control crítico no debe estar en que exista un parámetro llamado token, sino en que el backend valide de forma estricta quién puede acceder a qué registro.
Lectura técnica: IDOR/BOLA
El punto técnico central es la autorización por objeto.
Según la validación realizada, al modificar identificadores como cifHijo, IDU o Usuario, el sistema devuelve información o fotografías de otros estudiantes.
Eso encaja con una falla de autorización a nivel de objeto, conocida como IDOR o BOLA.
En términos simples:
- IDOR: el sistema permite acceder a objetos cambiando identificadores
- BOLA: la API no valida correctamente si el usuario tiene permiso sobre el objeto solicitado
El modus operandi observado es abuso de endpoints AJAX. No es necesario asumir explotación compleja ni bypass del WAF.
El WAF no era el punto central. El problema es más básico y más grave: el backend entrega datos de terceros cuando se cambian identificadores.
El problema no es que exista un endpoint AJAX. El problema es que el backend entrega datos personales o fotografías sin validar de forma estricta que la sesión o usuario solicitante tenga derecho a consultar ese registro específico.
Por qué el token no sería suficiente
En el endpoint de información personal se observa un parámetro Token.
También se observa un campo oculto asociado a TokenInformacionPersonales.
Sin embargo, la evidencia indica que el token no funciona como control efectivo si permite consultar registros ajenos al modificar IDU, Usuario o cifHijo.
Un token solo aporta seguridad si cumple condiciones mínimas:
- está vinculado a una sesión válida
- está vinculado al usuario autenticado
- está vinculado al objeto consultado
- expira en un tiempo razonable
- no puede reutilizarse para consultar objetos de terceros
- se valida del lado del servidor en cada solicitud
Si el token puede mantenerse igual mientras se modifican identificadores, entonces no funciona como control de autorización por objeto.
Un token largo o con apariencia aleatoria no es suficiente si el servidor no valida permisos reales.
Modus operandi observado
El modus operandi observado corresponde a abuso de endpoints AJAX.
Con base en la estructura revisada, el flujo sería:
- consultar datos personales modificando identificadores como
IDUoUsuario - obtener respuestas HTML con información personal embebida
- extraer o normalizar campos relevantes desde la respuesta
- usar el campo
CIFpara consultar fotografías mediantecifHijo - guardar las imágenes devueltas por el endpoint de fotografía
- repetir el proceso sobre rangos amplios de identificadores
La PoC no incluye un descarga.log, script o README del actor. Por lo tanto, no puede reconstruirse la ventana temporal, tasa de descarga ni ejecución exacta.
Aun así, la evidencia técnica es suficiente para sostener que la extracción fue estructurada y basada en abuso de endpoints.
El punto clave es este:
solo cambiando identificadores como CIF, IDU o Usuario, el sistema devuelve datos o fotografías de terceros.
Qué debería investigar la institución
La Universidad Da Vinci debería validar y corregir con urgencia lo siguiente:
- Por qué
obtenerImagen.aspxpermite recuperar fotografías modificando únicamentecifHijo. - Por qué
Ajax_InformacionPersonales.aspxpermite obtener información personal modificandoIDUoUsuario. - Por qué el parámetro
Tokenno impide la consulta de registros ajenos. - Si el token está realmente vinculado a la sesión, usuario autenticado y objeto consultado.
- Si existen controles de autorización por estudiante en el backend.
- Si
cifHijopermite obtener fotografías de terceros sin sesión autorizada. - Si hubo consultas secuenciales por
IDU. - Si hubo consultas masivas por
cifHijo. - Si hubo extracción histórica antes de la publicación del actor.
- Si se usaron credenciales válidas, sesiones robadas o acceso sin autenticación.
- Si existen secretos expuestos en HTML del lado cliente.
- Si hay otros endpoints AJAX con el mismo patrón de autorización débil.
Recomendaciones inmediatas
- restringir o suspender temporalmente los endpoints involucrados mientras se valida el alcance
- bloquear acceso directo no autorizado a
obtenerImagen.aspx - bloquear acceso directo no autorizado a
Ajax_InformacionPersonales.aspx - revisar autorización a nivel de objeto, no solo autenticación general
- validar que el usuario autenticado solo pueda consultar su propio registro o registros permitidos
- impedir acceso por identificadores predecibles como
IDU,UsuarioocifHijo - vincular cualquier token a sesión, usuario, objeto consultado, expiración y permisos reales
- usar recursos firmados o temporales para fotografías y documentos
- implementar rate limiting y monitoreo de enumeración
- alertar por cambios secuenciales de
IDU,UsuarioocifHijo - revisar si hubo descarga masiva histórica de HTML, JSON o fotografías
- revocar cualquier clave o secreto expuesto en HTML del lado cliente
- preservar logs de acceso, IP, User-Agent, sesión y hora
- dimensionar el universo de afectados y preparar comunicación responsable
- realizar una revisión completa de seguridad sobre la API y su lógica de negocio
Recomendaciones de fondo
Este caso no debería resolverse únicamente ocultando rutas o bloqueando IPs.
La corrección real debe enfocarse en autorización por objeto y diseño seguro de APIs.
Controles necesarios:
- autorización server-side por cada registro
- validación de sesión en cada solicitud
- tokens asociados al usuario, objeto y expiración
- eliminación de identificadores secuenciales expuestos
- URLs firmadas y temporales para imágenes
- monitoreo de consultas por rangos
- detección de cambios secuenciales de parámetros
- rate limiting por usuario, sesión e IP
- alertas por volumen anómalo
- registros de auditoría por consulta
- revisión de secretos expuestos en cliente
- pruebas específicas de IDOR/BOLA en QA y producción
Conclusión
La publicación de Dianna no debe tratarse como simple ruido de foro.
La PoC revisada contiene 98,099 JSON válidos y 16,821 fotografías, con información personal suficiente para considerar el caso como una exposición seria de datos.
La evidencia técnica apunta a abuso de endpoints AJAX en uvirtual.udv.edu.gt.
La fotografía es accesible mediante cifHijo. La información personal es accesible mediante identificadores como IDU o Usuario. La respuesta del endpoint incluye HTML renderizado con datos personales embebidos.
La falla principal no es “WAF débil”. La falla principal es autorización insuficiente a nivel de objeto.
Si un endpoint entrega datos personales de estudiantes solo porque se cambia un identificador, el problema no es el endpoint en sí. El problema es que el backend no está verificando si quien consulta tiene derecho a ver ese registro.
Esto debe validarse y corregirse con urgencia.
Evidencia visual utilizada en esta publicación
- captura censurada de la publicación del actor
- muestra censurada de JSON expuesto
- muestra censurada de fotografía expuesta
- vista censurada de estructura de archivos
Todas las imágenes fueron tratadas para evitar reproducir información personal.