Hackeo a una aseguradora mediante el abuso de una calculadora de primas
(eaton-works.com)- En un subdominio de la calculadora de primas de Eicher Motors quedaron expuestas credenciales de Microsoft Enterprise Cloud, lo que permitió iniciar sesión en la cuenta de correo
noreplyde TTIBI - La API de envío de correo en cuestión enviaba mensajes sin autenticación, y el registro de envío en la respuesta de error del servidor reveló una contraseña codificada en base64
- En la cuenta expuesta había 657,000 correos electrónicos enviados a clientes, además de unos 25 GB en PDFs de pólizas de seguro, información de clientes, enlaces de restablecimiento de contraseña y OTP
- La cuenta no tenía autenticación de dos factores, y también permitía acceder a otros recursos en la nube de Microsoft como el directorio corporativo, SharePoint y Teams
- Más de dos meses después del reporte, la API vulnerable fue corregida para exigir autenticación y, al 27 de enero de 2024, la contraseña de la cuenta de correo ya había sido cambiada, por lo que ya no era posible iniciar sesión
Brecha en TTIBI iniciada desde la calculadora de primas de Eicher
- Mientras se investigaban los sistemas de Eicher Motors, quedó expuesta la cuenta de correo de Microsoft
noreplyeicher@ttibi.co.inde Toyota Tsusho Insurance Broker India, en adelante TTIBI - TTIBI es un corredor de seguros de India perteneciente a la japonesa Toyota Tsusho Insurance Management Corporation, fundado en 2008
- Eicher Motors es un fabricante automotriz de India que produce las motocicletas de Royal Enfield Motors y vehículos comerciales de VE Commercial Vehicles, una empresa conjunta con Volvo Group
- Ambas compañías tenían una alianza relacionada con seguros, y en el sitio de TTIBI existía un subdominio dedicado a Eicher
Ruta de descubrimiento de la vulnerabilidad
- Al analizar la app Android MY EICHER, se encontró la URL de la calculadora de primas en una clase Java de la interfaz API
- El código fuente del sitio web de la calculadora de primas incluía un mecanismo de envío de correo del lado del cliente
- En el código había rastros del uso de Bearer Authorization, por lo que parecía requerir autenticación, pero al construir directamente una solicitud al API, en lugar de
401 Unauthorized, el correo se enviaba de verdad - La respuesta de error del servidor devolvía también el registro de envío del correo, y dentro de él venía una contraseña codificada en base64
Datos que permanecían en la cuenta noreply
noreplyeicher@ttibi.co.inera una cuentanoreplypara envío automático de correos, pero en TTIBI era una cuenta en la que sí se podía iniciar sesión realmente- En esa cuenta quedaba el historial de todos los correos enviados a clientes
- Un total de 657,000 correos electrónicos
- Un volumen de aproximadamente 25 GB
- Información de clientes
- PDFs de pólizas de seguro
- Enlaces de restablecimiento de contraseña
- OTP
- Como también se podían ver OTP y enlaces de restablecimiento de contraseña, había información que podía ser usada para tomar control de cuentas de seguros de clientes
- Con la misma cuenta también se podía acceder a recursos en la nube de Microsoft
- Directorio corporativo
- SharePoint
- Teams
Fallas de seguridad que ampliaron la vulnerabilidad
-
Función de envío de correo del lado del cliente
- Una función de envío de correo en la que el cliente puede controlar el asunto, el cuerpo y los destinatarios puede ser explotada para enviar correos maliciosos
- Al enviarse desde una cuenta real, puede derivar en daño a la reputación del correo y en phishing
-
Falta de autenticación en el API
- En el frontend había rastros del uso de tokens de autenticación, pero el servidor no los verificaba realmente
- Si el servidor hubiera validado el token, es posible que este ataque se hubiera podido evitar
-
Respuestas de error excesivas del API
- Cuando ocurría un error durante el procesamiento del API, se devolvía demasiada información al cliente
- En este caso, la respuesta de error expuso directamente la contraseña
-
Ausencia de autenticación de dos factores
- Al iniciar sesión en la cuenta de Microsoft no había autenticación de dos factores ni otros avisos de verificación de inicio de sesión
- Si hubiera existido autenticación de dos factores, es posible que el inicio de sesión exitoso hubiera sido más difícil
-
Retención de correos electrónicos
- Se conservaban todos los correos enviados y recibidos por la cuenta, lo que permitió acceder fácilmente a una gran cantidad de información de clientes
- Si hubiera existido una política de retención, se podría haber reducido el impacto de la exposición de datos de clientes
Respuesta y estado actual
- Al 17 de enero de 2024, TTIBI llevaba más de 5 meses al tanto de la vulnerabilidad, pero la contraseña de la cuenta de correo seguía sin cambiarse
- Según una actualización del 27 de enero de 2024, la contraseña de la cuenta de correo fue cambiada, por lo que ya no era posible iniciar sesión en esa cuenta
- La API vulnerable finalmente fue corregida para exigir autenticación
- No se pudo confirmar si hubo alertas por inicios de sesión anómalos en Microsoft; de haber existido, podrían haber sido ignoradas o no revisadas
Cronología del reporte
- Como TTIBI no estaba cubierto por el programa de divulgación de vulnerabilidades de Toyota en HackerOne, se reportó a India CERT-In
- 7 de agosto de 2023: se envió a CERT-In un informe detallado de la vulnerabilidad
- 8 de agosto de 2023: CERT-In respondió emitiendo un ID de caso y dijo que se pondría en contacto con TTIBI
- 1 de septiembre de 2023: se solicitó una actualización del progreso
- 6 de septiembre de 2023: CERT-In respondió que había transmitido la vulnerabilidad a TTIBI y que compartiría más actualizaciones
- 8 de octubre de 2023: el sitio web afectado fue dado de baja, pero la API vulnerable seguía activa, por lo que se notificó a CERT-In
- 11 de octubre de 2023: CERT-In respondió que TTIBI había corregido la vulnerabilidad, pero al verificarlo se confirmó que seguía presente
- 18 de octubre de 2023: la vulnerabilidad fue corregida cuando la API de envío de correo pasó a requerir autenticación
- Después continuó el intercambio para confirmar si habría recompensa de bug bounty, pero TTIBI no respondió y el caso se cerró el 22 de diciembre de 2023
1 comentarios
Opiniones en Hacker News
No soy indio, pero como alguien que trabaja en una gran empresa de TI al estilo Tata, esto se siente demasiado realista
Aquí influyen mucho una cultura de gestión que premia terminar barato, y una cultura que aplasta la iniciativa o la realización personal de los desarrolladores
Si hubiera visto algo así en Estados Unidos me habría ido de inmediato, pero ellos básicamente no tienen opción porque, si renuncian, les recuperan 90 días de sueldo
La mayoría de los gerentes no tiene formación técnica, así que solo escucha lo que quiere oír y no quiere escuchar cuando algo está mal
Incluso puede ser incorrecto verlo como el resultado de un mismo equipo o una misma empresa, porque aíslan muchísimo a los desarrolladores en silos y los subdividen como desarrollador de API, desarrollador de Office 365, desarrollador de frontend, y nadie toca un área en la que no esté “certificado”
Incluso en reuniones de proyectos de 100 millones de dólares se pelean en serio por el costo de SendGrid, y al final algún desarrollador dice que se puede hacer con Office 365 porque no tiene “experiencia con SendGrid”
El presupuesto del equipo de seguridad es lo primero que recortan porque “ya debería ser seguro”, y si hablas con el sobrino contratado como encargado de seguridad, la actitud es: ¿para qué molestarse si el gobierno o alguien no va a demandar?
A los desarrolladores no se les anima a desarrollar, sino que aprenden a cerrar tickets y a no hacer preguntas
Trabajo con desarrolladores indios inteligentes, pero esto no es una cultura de innovación: es un trabajo tratado como call center. No te salgas del guion, quédate en un área de problemas estrecha y, mientras no falles, estás ganando
A nosotros también nos puede llegar pronto
A mediados o finales de los 2000 traté con un concesionario de autos asociado a Honda que guardaba solicitudes de financiamiento con IDs numéricos incrementales
No lo reporté, pero podía consultar varios datos sensibles de residentes de Nueva Jersey, como SSN, fecha de nacimiento, nombre y dirección
En esa época prácticamente no existían los bug bounties y sí existía la CFAA, así que no lo reporté
Hice que eliminaran mi solicitud, pero la vulnerabilidad siguió ahí durante años hasta que cambiaron a un sistema nuevo, y ese sistema nuevo también parecía vulnerable
Desde entonces no hice más negocios con ese concesionario, y hoy todavía soy muy cuidadoso con los concesionarios y las solicitudes de financiamiento. Normalmente financio en otro lado, aunque cueste un poco más
https://eaton-works.com/2023/06/06/honda-ecommerce-hack/
En https://cerebrum.com estamos trabajando en otra área, la verificación de identidad, y este comentario me dio muchas ideas
El error de seguridad en sí es terrible, pero parece hasta cierto punto explicable como haberle encargado a un desarrollador sin experiencia algo que estaba muy por encima de su comprensión
Pero no entiendo cómo demonios aprobaron guardar documentos confidenciales de clientes en una cuenta de correo
Eso significa que no hay nadie responsable que sepa cómo operar este negocio, y si se trata de una subsidiaria o un socio tercerizado, también significa que nadie lo auditó nunca
Es algo cercano a negligencia penal, tanto por parte de los dueños de la empresa como de quienes les encargaron este trabajo
Probablemente existía la función de guardar correos enviados del servidor de correo, y esto surgió como subproducto de la tonta decisión de usar una cuenta real para la dirección “noreply”
Terminaba funcionando como registro de auditoría, herramienta de debugging y respaldo de base de datos
Solo lo cambiaron después de darse cuenta de que los empleados se llevaban toda la información de clientes a sus nuevos trabajos
Si “más de 5 meses después, TTIBI conocía la vulnerabilidad y aun así no había cambiado la contraseña de la cuenta de correo”, espero que al menos hayan quitado la contraseña en Base64 de los logs de error
Seguro lo hicieron. ¿No?
El impacto es enorme, literalmente al nivel de acceso completo a SharePoint y Outlook, pero el camino es algo tan simple como mirar JavaScript del lado del cliente, así que es una vulnerabilidad bastante peculiar
Un detalle menor: en las capturas, para la información sensible creo que es mejor taparla con bloques negros que desenfocarla. No está de más ser cuidadoso
Por una estructura que termina en una “carta de agradecimiento”, la mayoría de estas vulnerabilidades no se reportan ni se publican a través de white hats, sino que los hackers las explotan activamente
Debería existir un marco legal que responsabilice a las empresas por cierto nivel de mala gestión de seguridad relacionada con datos personales de clientes
India tiene problemas más grandes que las filtraciones de datos
Uno de ellos es el suministro eléctrico confiable
Estoy esperando el día en que India tenga suficiente electricidad y el hacking se convierta en una preocupación principal
Están instalando 100.000 km de fibra óptica al mes y levantando 350 estaciones base 5G al día
También hay que ver que el endpoint de correo de monitoreo básicamente fue diseñado como un trabajador/agente/runner de comunicaciones y, al quedar abandonado, siguió engordando
Eso significa que no monitorean el uso del correo y tampoco tienen controles complementarios para detectar comportamientos anómalos como “¿por qué este alias de correo cuesta varias veces más en almacenamiento que los demás?”
La frase clave es: “la cuenta noreply puede tener potencialmente todos los registros enviados a clientes, así que podría ser la cuenta más importante de la organización”
Si un “corredor de seguros líder en toda India” no tiene dinero para contratar desarrolladores competentes, al menos debería pagarle unas monedas a la persona que encontró varios problemas graves que pusieron en riesgo a sus clientes y los informó responsablemente
Pero no lo hicieron, e incluso es increíble que todavía no hayan restablecido la contraseña de la cuenta de correo comprometida
¿Cómo se puede confiar en que una empresa que actúa así haga algo bien?
Toyota Tsusho Insurance Broker India parece una empresa que habría que evitar como a la peste
Esto no es que alguien esté ignorando activamente una alerta de seguridad importante, sino que no entiende de qué le hablan
No comprende de forma fundamental el entorno que opera ni el desafío que enfrenta, y como la jerga técnica que usas no significa nada para él ni para su equipo, solo quiere que desaparezcas
Es una actitud tipo “deje de mandarme correos confusos, tengo cosas importantes que hacer”
Para solucionarlo se necesita un cambio de cúpula a nivel organizacional, y el responsable de TI y todo lo que haya tocado deben irse
Parte del problema es que usaron esta bandeja de entrada prácticamente como una cuenta SMTP “gratis” para no pagar por el correo saliente
Si hubieran usado algo como SES, no habría tanta información sensible en los enviados/recibidos de esta cuenta
SES es muy barato: 0,10 dólares por cada 1.000 correos
Habría que guardar todos los correos enviados y crear una interfaz para que el personal operativo no desarrollador pueda ver y buscar mensajes antiguos
Si estaban usando toda la funcionalidad de este enfoque SMTP “gratis”, los costos de desarrollo y mantenimiento son bastante altos