- Credenciais da nuvem corporativa da Microsoft foram expostas em um subdomínio da calculadora de prêmio de seguro da Eicher Motors, permitindo login na conta de email
noreplyda TTIBI - A API de envio de email em questão enviava mensagens sem autenticação, e o log de envio na resposta de erro do servidor revelou uma senha codificada em base64
- A conta exposta continha 657.000 emails enviados a clientes e cerca de 25 GB em PDFs de apólices de seguro, dados de clientes, links de redefinição de senha e OTPs
- A conta não tinha autenticação em duas etapas e também permitia acesso a outros recursos de nuvem da Microsoft, como diretório corporativo, SharePoint e Teams
- Após a notificação, a API vulnerável foi corrigida para exigir autenticação mais de 2 meses depois e, em 27 de janeiro de 2024, a senha da conta de email também foi alterada, impedindo novos logins
Violação da TTIBI começou na calculadora de prêmio da Eicher
- Ao investigar os sistemas da Eicher Motors, foi exposta a conta de email Microsoft
noreplyeicher@ttibi.co.inda Toyota Tsusho Insurance Broker India, daqui em diante TTIBI - A TTIBI é uma corretora de seguros indiana ligada à japonesa Toyota Tsusho Insurance Management Corporation e foi fundada em 2008
- A Eicher Motors é uma fabricante automotiva indiana que produz motocicletas da Royal Enfield Motors e veículos comerciais da VE Commercial Vehicles, joint venture com o Volvo Group
- As duas empresas tinham uma parceria relacionada a seguros, e o site da TTIBI tinha um subdomínio dedicado à Eicher
Como a vulnerabilidade foi descoberta
- Ao analisar o app Android MY EICHER, foi encontrada a URL da calculadora de prêmio em uma classe Java da interface da API
- O código-fonte do site da calculadora de prêmio incluía um mecanismo de envio de email no lado do cliente
- Havia indícios no código do uso de Bearer Authorization, então parecia exigir autenticação, mas ao montar uma requisição direta para a API, em vez de
401 Unauthorized, o email foi realmente enviado - A resposta de erro do servidor retornava junto o log de envio do email, que incluía uma senha codificada em base64
Dados que permaneceram na conta noreply
noreplyeicher@ttibi.co.inera uma contanoreplypara envio automático de emails, mas na TTIBI era uma conta com login real- Nessa conta permanecia o histórico de todos os emails enviados aos clientes
- Total de 657.000 emails
- Cerca de 25 GB
- Dados de clientes
- PDFs de apólices de seguro
- Links de redefinição de senha
- OTPs
- Como era possível ver até OTPs e links de redefinição de senha, havia informações que poderiam ser exploradas para assumir contas de seguro de clientes
- A mesma conta também permitia acesso a recursos de nuvem da Microsoft
- Diretório corporativo
- SharePoint
- Teams
Falhas de segurança que ampliaram a vulnerabilidade
-
Função de envio de email no lado do cliente
- Uma função de envio de email em que o cliente controla assunto, corpo e destinatário pode ser explorada para disparar mensagens maliciosas
- Como o envio ocorre a partir de uma conta real, isso pode levar a dano de reputação do email e phishing
-
Ausência de autenticação na API
- Havia indícios no frontend do uso de token de autenticação, mas o servidor não verificava de fato o token
- Se o servidor tivesse validado o token, é possível que esse ataque tivesse sido bloqueado
-
Respostas de erro da API excessivas
- Quando ocorria um erro no processamento da API, o servidor retornava informações demais ao cliente
- Neste caso, a resposta de erro expunha diretamente a senha
-
Ausência de autenticação em duas etapas
- No login da conta Microsoft, não havia autenticação em duas etapas nem outros prompts de verificação de login
- Se houvesse autenticação em duas etapas, é possível que um login bem-sucedido tivesse sido mais difícil
-
Retenção de emails
- Todos os emails enviados e recebidos pela conta eram preservados, permitindo acesso fácil a um grande volume de dados de clientes
- Se houvesse uma política de retenção, seria possível reduzir o impacto da exposição dos dados dos clientes
Resposta e estado atual
- Em 17 de janeiro de 2024, embora a TTIBI já soubesse da vulnerabilidade havia mais de 5 meses, a senha da conta de email ainda não tinha sido alterada
- Segundo atualização de 27 de janeiro de 2024, a senha da conta de email foi alterada, então já não era mais possível fazer login nessa conta
- A API vulnerável acabou sendo corrigida para exigir autenticação
- Não foi possível confirmar se houve alertas de login anormal da Microsoft; se houve, podem ter sido ignorados ou não verificados
Linha do tempo da notificação
- Como a TTIBI não fazia parte do programa de divulgação de vulnerabilidades da Toyota no HackerOne, o caso foi reportado ao CERT-In da Índia
- 7 de agosto de 2023: relatório detalhado da vulnerabilidade foi enviado ao CERT-In
- 8 de agosto de 2023: o CERT-In emitiu um ID de caso e respondeu que entraria em contato com a TTIBI
- 1º de setembro de 2023: foi solicitada uma atualização de andamento
- 6 de setembro de 2023: o CERT-In respondeu que havia encaminhado a vulnerabilidade à TTIBI e que compartilharia novas atualizações
- 8 de outubro de 2023: o site afetado saiu do ar, mas a API vulnerável continuava ativa, então o CERT-In foi avisado
- 11 de outubro de 2023: o CERT-In respondeu que a TTIBI havia corrigido a vulnerabilidade, mas a verificação mostrou que ela ainda permanecia
- 18 de outubro de 2023: a vulnerabilidade foi corrigida quando a API de envio de email passou a exigir autenticação
- Depois disso, continuaram conversas para confirmar se haveria recompensa de bug bounty, mas a TTIBI não respondeu e o caso foi encerrado em 22 de dezembro de 2023
1 comentários
Comentários do Hacker News
Não sou indiano, mas, do ponto de vista de quem trabalha em uma grande empresa de TI do tipo Tata, isso parece real demais
Há um peso enorme de uma cultura de gestão que recompensa entregar tudo do jeito mais barato possível, além de sufocar a autonomia e a realização profissional dos desenvolvedores
Se eu visse algo assim nos EUA, sairia imediatamente, mas eles praticamente não têm escolha, porque ao pedir demissão há clawback de 90 dias de salário
A maioria dos gestores vem de áreas não técnicas, então só ouve o que quer ouvir e não quer escutar quando algo está errado
Também pode ser incorreto tratar isso como resultado do mesmo time ou da mesma empresa, porque os desenvolvedores são isolados em silos extremos: desenvolvedor de API, desenvolvedor de Office 365, desenvolvedor de frontend, e ninguém mexe em algo para o qual não foi “certificado”
Até em reuniões de projetos de 100 milhões de dólares ficam brigando seriamente pelo custo do SendGrid, e no fim algum desenvolvedor diz que pode fazer com Office 365, porque ninguém ali tem “experiência com SendGrid”
O orçamento de segurança é o primeiro a ser cortado porque “isso já deveria estar seguro”, e falar com o jovem contratado para cuidar da segurança acaba em uma atitude do tipo: por que se dar ao trabalho se o governo ou alguém não vai processar ninguém?
O desenvolvedor não é incentivado a desenvolver, mas a fechar tickets e não fazer perguntas
Trabalho com desenvolvedores brilhantes da Índia, mas isso não é uma cultura de inovação; é gente tratada como call center. Não saia do script, fique no seu problema estreito, e se você não falhar, então está vencendo
Isso também pode chegar até nós em breve
Em meados para o fim dos anos 2000, uma concessionária de carros afiliada à Honda com a qual lidei estava armazenando solicitações de financiamento com IDs numéricos sequenciais
Não denunciei, mas consegui consultar dados sensíveis de vários moradores de Nova Jersey, como SSN, data de nascimento, nome e endereço
Na época praticamente não existia bug bounty, mas o CFAA existia, então não denunciei
Fiz com que apagassem a minha solicitação, mas a vulnerabilidade permaneceu por anos, até trocarem o sistema, e o sistema novo também parecia vulnerável
Nunca mais fiz negócio com aquela concessionária e, até hoje, sou extremamente cauteloso com pedidos de financiamento em concessionárias. Mesmo pagando um pouco mais caro, normalmente financio em outro lugar
https://eaton-works.com/2023/06/06/honda-ecommerce-hack/
Estou trabalhando nisso em outra área, a de verificação de identidade, em https://cerebrum.com, e este comentário me deu muitas ideias
O erro de segurança em si é terrível, mas dá para explicar em parte como um caso em que deram a um desenvolvedor inexperiente uma tarefa muito além do que ele conseguia compreender
Mas eu realmente não consigo entender como alguém aprovou armazenar documentos confidenciais de clientes em uma conta de email
Isso significa que não existe ninguém responsável que saiba como operar esse negócio, e também que, se isso foi feito por subsidiária ou parceiro terceirizado, ninguém jamais auditou nada
É algo próximo de negligência criminal, tanto por parte do dono da empresa quanto de quem terceirizou esse trabalho
Provavelmente havia uma função de salvar emails enviados no servidor de email, e isso surgiu como efeito colateral da decisão idiota de usar uma conta real em um endereço “noreply”
Servia ao mesmo tempo como trilha de auditoria, ferramenta de depuração e backup de banco de dados
Só mudaram isso quando descobriram que os funcionários levavam todos os dados dos clientes para o novo emprego
Se “já se passaram mais de 5 meses e a TTIBI, mesmo sabendo da vulnerabilidade, ainda não trocou a senha da conta de email”, então eu espero ao menos que tenham removido a senha em Base64 dos logs de erro
Com certeza fizeram isso. Fizeram, né?
O impacto é gigantesco, literalmente no nível de acesso total a SharePoint e Outlook, mas o vetor é apenas olhar o JavaScript do lado do cliente, então é uma vulnerabilidade bem incomum
Um detalhe pequeno: no screenshot, acho melhor cobrir dados sensíveis com blocos pretos do que aplicar desfoque. Todo cuidado é pouco
Por causa dessa estrutura que termina com um “agradecimento”, a maior parte dessas vulnerabilidades não é reportada nem divulgada por white hats, e acaba sendo explorada ativamente por hackers
Precisamos de um marco legal que responsabilize empresas por um certo nível de má gestão de segurança envolvendo dados pessoais de clientes
A Índia tem problemas maiores do que vazamento de dados
Um deles é o fornecimento estável de energia elétrica
Estou esperando o dia em que a Índia terá eletricidade suficiente para que hacking vire a principal preocupação
Estão instalando 100 mil km de fibra óptica por mês e construindo 350 estações-base 5G por dia
Também é preciso notar que o endpoint de email de monitoramento foi essencialmente projetado como um operador/agente/runner de comunicações e, por ter sido deixado de lado, continuou crescendo sem controle
Isso significa que ninguém monitora o uso desse email e que também não existem controles compensatórios para detectar comportamentos anômalos, tipo “por que esse alias de email está custando várias vezes mais para armazenar do que os outros?”
A frase central é: “a conta noreply pode ser a conta mais importante da organização, porque potencialmente contém todo o histórico do que foi enviado aos clientes”
Se uma “corretora de seguros líder em toda a Índia” não tem dinheiro para contratar desenvolvedores competentes, então no mínimo deveria pagar alguma coisa à pessoa que encontrou vários problemas graves que colocavam clientes em risco e os reportou de forma responsável
Mas não fizeram isso, e é inacreditável que nem sequer tenham redefinido a senha da conta de email comprometida
Como confiar em uma empresa que age assim e esperar que faça qualquer coisa direito?
A Toyota Tsusho Insurance Broker India parece uma empresa a ser evitada como se fosse uma praga
Não é alguém ignorando deliberadamente alertas de segurança importantes; é simplesmente gente que não entende do que você está falando
Não compreendem de forma fundamental o ambiente que operam nem o problema que têm pela frente, e o jargão técnico que você usa não significa nada para eles ou para o time, então só querem que você desapareça
É a atitude de “parem de mandar esses emails confusos, temos coisas importantes para fazer”
Para resolver isso, seria preciso uma troca da cúpula em nível organizacional, e o responsável por TI e tudo o que ele tocou teria de sair
Parte do problema é que usaram essa caixa de entrada na prática como uma conta SMTP “gratuita”, para evitar pagar pelo envio de emails
Se tivessem usado algo como SES, provavelmente não haveria tanta informação sensível na caixa de saída/entrada dessa conta
O SES custa só US$ 0,10 por 1.000 emails
Seria preciso armazenar todos os emails enviados e criar uma interface para que pessoas de áreas não técnicas pudessem consultar e buscar mensagens antigas
Se estavam usando toda a funcionalidade desse acesso SMTP “gratuito”, então o custo de desenvolvimento e manutenção seria bem alto