La aplicación oficial del Vaticano, Click to Pray, ha expuesto la información personal de más de 700.000 usuarios a través de un fallo de API no autenticado.

El problema permitía que cualquier persona con un navegador web recuperara datos de cuentas sin necesidad de iniciar sesión. Click to Pray ofrece oraciones diarias y contenido papal a través de su sitio web y aplicaciones móviles.

Los usuarios proporcionaron nombres, direcciones de correo electrónico, contraseñas y, a veces, su país al crear las cuentas, generando un gran volumen de datos que deberían haber estado protegidos.

Analistas de DarkReading identificaron la exposición después de que el hacker ético BobDaHacker descubriera una vulnerabilidad de referencia directa a objetos inseguros, o IDOR, en enero.

DarkReading probó el problema de forma independiente e informó que seguía siendo accesible en el momento de la publicación.

DarkReading señaló en un informe que el caso no es un incidente de malware, sino que resalta cómo un simple fallo de control de acceso puede exponer a los usuarios al phishing, la suplantación de identidad y otras estafas dirigidas.

Una API no autenticada expone registros de usuarios

La API vulnerable asignaba a cada cuenta de Click to Pray un ID de usuario secuencial. Al proporcionar un ID válido al endpoint expuesto, un visitante no autenticado podía ver la información vinculada a esa cuenta y luego repetir el proceso con una amplia gama de usuarios.

Los registros expuestos incluían los nombres y apellidos de los usuarios, direcciones de correo electrónico, identificadores de país, el estado de eliminación de la cuenta y los roles asignados.

Se informó que las cuentas con los números más bajos estaban asociadas al personal, mientras que los usuarios ordinarios estaban marcados con el rol “PRAYER”.

Este tipo de debilidad se conoce comúnmente como fallo IDOR porque una aplicación expone una referencia de objeto, como un ID de usuario, sin confirmar si quien lo solicita tiene permiso para acceder a él.

Un fallo de autorización de objetos rotos reportado anteriormente mostró de manera similar cómo la falta de controles de autorización puede poner en riesgo la información privada.

Los identificadores secuenciales facilitan especialmente la recolección a gran escala. Un atacante podría usar un script sencillo para recorrer los números de cuenta, recopilar registros en masa y crear una lista de personas que podrían confiar en mensajes que parezcan provenir del Vaticano o de su red de oración.

El informe indicó que los atacantes no necesitarían habilidades técnicas avanzadas para acceder a los datos.

La información estaba disponible a través de una solicitud del navegador, reduciendo la barrera para los criminales que quieran preparar campañas de phishing convincentes o engaños de ingeniería social.

Las organizaciones que manejan datos personales deben asegurarse de que cada solicitud de API verifique tanto la identidad como el permiso.

El problema refleja un fallo IDOR en ExHub, donde las verificaciones de autorización insuficientes permitieron el acceso más allá de los privilegios previstos del usuario.

Riesgos de phishing y lecciones de seguridad

Los nombres y las direcciones de correo electrónico pueden hacer que los correos fraudulentos parezcan más creíbles, especialmente cuando los criminales utilizan referencias a la fe, peticiones de oración, donaciones o contenido del Vaticano.

Es más probable que las víctimas abran los mensajes cuando los atacantes pueden personalizarlos con detalles reales de la cuenta.

La exposición también demuestra por qué el control de acceso roto sigue siendo una preocupación seria de seguridad web.

La guía OWASP Top 10 identifica el control de acceso roto como un riesgo importante de las aplicaciones y recomienda aplicar el acceso de privilegio mínimo, denegar el acceso por defecto y aplicar verificaciones de autorización sólidas.

BobDaHacker señaló que muchos marcos de desarrollo gestionan la autenticación, pero no deciden automáticamente si una persona conectada debe acceder a un registro particular.

Tú, como desarrollador, debes integrar esa segunda verificación de autorización en cada función sensible y endpoint de API.

Para los usuarios, el informe recomienda limitar la información personal compartida durante el registro siempre que sea posible.

Algunos usuarios de Click to Pray utilizaron nombres abreviados, identificadores alfanuméricos o la función “Ocultar mi correo electrónico” de Apple, que puede reducir el valor de los datos expuestos al sustituir una dirección real por una de retransmisión.

Quienes hayan utilizado sus datos de contacto reales deben ser cautelosos con los correos inesperados que afirmen representar al Vaticano, a Click to Pray o a la Red Mundial del Papa por la Oración.

Debes evitar hacer clic en enlaces o compartir contraseñas hasta que verifiques la identidad del remitente a través de un canal oficial. Riesgos similares se destacaron en la brecha de datos personales de NVIDIA, donde los identificadores expuestos también podrían servir para ataques de phishing y de credenciales dirigidos.

El incidente es un recordatorio de que las organizaciones no técnicas siguen teniendo responsabilidades de seguridad importantes cuando recopilan datos a gran escala.

Las revisiones de seguridad, las pruebas de autorización de API y un proceso claro para gestionar los informes de vulnerabilidades son protecciones esenciales para cualquier organización que almacene información de usuarios.