Hace un tiempo, como FINSIN, nos estamos dedicando a las investigaciones en el área de Seguridad Informática.
De acuerdo a nuestra política de Divulgación Responsable queremos que las vulnerabilidades que se encuentren sean reportadas a la empresa afectada previamente a la publicación general, para que tengan la oportunidad de arreglarla.
En este caso tocó investigar un problema que presentaban dos dominios de Seguros Falabella: viajes.segurosfalabella.com y auto.segurosfalabella.com. Hoy estas vulnerabilidades han sido parchadas, lo cual agradecemos como fundación.
Este tipo de vulnerabilidades tiene que ver con el mal manejo de datos personales de clientes, los cuales se pueden extraer de consultas a las API ligadas a las aplicaciones de esos sitios.
Vulnerabilidad 1
Enumeración de datos, descubrimiento de información interna en seguros de viaje.
Descripción
Al intentar comprar un seguro de viajes dentro de la aplicación en el sitio https://viajes.segurosfalabella.com/, tenemos que al llegar al paso 2 se requiere ingresar un RUT para poder avanzar. Al ingresar ese dato se genera una llamada a una API en la siguiente dirección:
https://api-flujo-viajes.segurosfalabella.com/api/users/%5BRUT%5D
Esa llamada trae consigo mucha de la información que tienen los servidores de la compañía sobre ese RUT, y ésta no está protegida por ningún tipo de autenticación.
Dentro de la información que se recibe están los siguientes campos:
- documentNumber
- documentVerifier
- names
- lastName
- midleName
- gender
- birthDate
- phone
- inWhitelist
- hashedEmail
- hashedPhone
Esa información es, en general, privada de las personas, principalmente los campos: email y phone, los cuales inicialmente están “truncados” porque se les quita la primera parte de ellos.
Si uno se fija en los campos hashedEmail y hashedPhone, podemos encontrar que a estos campos no se les ha aplicado una función de hash (como indica el nombre, y lo haría computacionalmente difícil de revertir), sino que les aplicaron el algoritmo de base64, lo cual es simplemente una traducción fácilmente reversible.
Con esto, basta generar un bot y enumerar todos los RUT que uno desee para obtener información privada de la persona que uno quiera. Como dijimos antes, el hecho de que no tenga ninguna autenticación hace que no importa cuantas llamadas a la API uno haga, ésta siempre va a ser respondida.
Además, como un bonus, en esa misma pantalla, existe un texto que asegura que la información es “estrictamente confidencial” lo cual era finalmente incorrecto.
Vulnerabilidad 2
Enumeración de datos, descubrimiento de información interna en seguros de automóvil.
Descripción
Al intentar cotizar un seguro de automóvil dentro de la aplicación en el sitio https://auto.segurosfalabella.com/ tenemos varios pasos. En el primer paso necesitamos ingresar un RUT para poder avanzar, y al apretar el botón “Continuar” se generan varias llamadas a API dentro de las que se destaca:
Esa llamada trae consigo mucha de la información que tienen los servidores de la compañía sobre ese RUT, y ésta no está protegida por ningún tipo de autenticación. Dentro de la información que se recibe están los siguientes campos:
- birthDay
- dv
- lastNameFather
- lastNameMother
- mobileNumber (vacío en el ejemplo)
- names
- phoneNumber (vacío en el ejemplo)
- phoneNumber2 (vacío en el ejemplo)
- rut
Esa información es, en general, privada de las personas, principalmente los campos birthDay y los teléfonos (los 3 campos), los cuales inicialmente están vacíos, pero no se pudo verificar que en “todos” los usuarios estén vacíos. Por ejemplo, en unas pruebas se recibe el campo email y en otras no, por lo que es probable que en algunos casos se reciban los teléfonos y en otros no.
Parchado
Hoy en día la situación ha cambiado dentro del funcionamiento de ambas API, la situación fue mejorada de distintas formas, dependiendo de cada vulnerabilidad.
Solución vulnerabilidad 1
Para la primera vulnerabilidad, en la API del sitio de seguros de viajes, se implementó un cifrado a los campos que estaban en base64, ya que ahora al hacer la misma consulta se entrega lo siguiente:
Con esto se le coloca una capa más de complicaciones al potencial bot que quiera saber cuál es el correo real del usuario.
Lo “malo” es que a través de esta API uno puede obtener los demás datos de una persona. No somos ilusos en pensar que la asociación de RUT y nombre completo, con sexo y fecha de nacimiento no están en ningún otro sitio en internet, existen muchas de esas páginas, pero el que además de todas las otras opciones esté disponible acá nos parece una prueba más de que la información que uno pensaba en el pasado era personal ahora parece que ya es pública.
Solución vulnerabilidad 2
Para corregir la vulnerabilidad del sitio de seguros de automóviles, cambiaron la definición de la API. Ahora algunos nombres de campos son diferentes (birthday a birthdate), se eliminaron los múltiples números de teléfono y ahora solamente devuelve uno truncado, ya que muestran solamente los últimos 4 dígitos.
Conclusión
Es necesario proteger la información que se guarda de los clientes de la empresa, más aún cuando esta contiene datos personales y, por ende, se encuentra protegida por leyes sobre privacidad y protección de datos personales tanto a nivel nacional como internacional.
En este caso particular, el uso que la aplicación web hacía de la API era muy reducido y a nuestro juicio exponía mucha información de las personas que no era usada, y estos datos estaban accesibles a cualquiera.
Las soluciones cumplen con no exponer los datos “más sensibles”, como el número de teléfono o el correo asociado al cliente, lo cual agradecemos a la gente de Falabella por reaccionar a tiempo con lo pedido.
Timeline
17/04: Reporte inicial por correo a contacto de Falabella
19/04: Se retoma el contacto perdido del primer correo
20/04: Se responde a consultas particulares y fin del contacto
17/05: Se revisa nuevamente la vulnerabilidad y se nota el parche
FINSIN 
Deje un comentario