True History: Dados em Rota de Fuga. Entenda como dados foram extraviados

Tudo o que eu queria era uma viagem… acabei encontrando uma vulnerabilidade. 

Sou apaixonado por viajar, e decidi tirar um tempo para mim — longe das telas, do teclado e do ambiente digital. Entrei no primeiro site que encontrei de passagens de ônibus, comprei minha passagem e fui dormir tranquilo. 

Mas no meio da noite, aquela curiosidade, que só quem trabalha com segurança conhece, bateu forte: “Como será que estão tratando os dados dos usuários?” 

Voltei para o computador e, com uma análise simples — sem técnicas avançadas, apenas um acesso comum na plataforma— comecei a observar como as informações eram transmitidas e gerenciadas pela aplicação. E foi aí que a viagem tomou outro rumo. 

A aplicação expunha dados sensíveis de forma totalmente desprotegida: 

• Nenhuma autenticação era exigida para acessar pedidos; 

• Bastava um código para obter detalhes pessoais; 

• E, o mais preocupante: isso podia ser feito de forma automatizada, em larga escala. 

 

De acordo com dados públicos da própria empresa, mais de  60 milhões de bilhetes já foram emitidos. Ou seja, milhões de registros com  PII (Personally Identifiable Information) potencialmente acessíveis por qualquer pessoa, como por exemplo:

 

• Nome Completo de todos os passageiros do ticket; 

• CPF de todos os passageiros do ticket; 

• Telefone dos passageiros; 

• Email dos passageiros; 

• Trajeto comprado; 

• Endereço da pessoa que compra o ticket; 

• Data de expiração do cartão de crédito; 

• Nome impresso no cartão; 

• Os 6 primeiros digitos e os últimos 4; 

• Data de Nascimento.

 

O objetivo era viajar, mas acabei encontrando um exemplo clássico de vulnerabilidade… 

 

API1:2023 Broken Object Level Authorization 

A aplicação expõe uma falha de controle de acesso ao permitir que qualquer usuário  sem autenticação  acesse diretamente dados sensíveis associados a pedidos, bastando apenas conhecer ou adivinhar o identificador do recurso. 

Essa ausência de autenticação e, principalmente, de  validação de autorização no nível do objeto  representa uma violação clara do controle previsto na categoria  API1:2023 — Broken Object Level Authorization, permitindo que agentes mal-intencionados consultem informações que deveriam ser restritas ao titular do dado. 

Além do risco técnico, essa exposição também configura um possível descumprimento da  LGPD (Lei Geral de Proteção de Dados), ao permitir acesso não autorizado a dados pessoais e, potencialmente, dados financeiros (como informações de transações ou padrões de consumo). 

 

 

API4:2023 Unrestricted Resource Consumption 

Uma vez identificado que os pedidos podem ser acessados via código, entra em cena um segundo vetor de risco: a previsibilidade e a baixa complexidade desses identificadores. Os códigos de pedidos possuem apenas 8 caracteres alfanuméricos, o que os torna suscetíveis a ataques de força bruta com esforço relativamente baixo. 

Embora a aplicação implemente um mecanismo de  rate limiting, esse controle pode ser facilmente contornado com o uso de pequenos delays entre as requisições. Esse “slow brute-force” torna o ataque mais demorado, mas não o inviabiliza — especialmente para um atacante persistente ou automatizado. 

Além disso, a própria empresa, inadvertidamente, contribui para a previsibilidade desses códigos ao expor padrões parcialmente mascarados em plataformas públicas como o Reclame Aqui. Em muitos casos, apenas um dígito está oculto, o que reduz drasticamente o espaço de busca. Para descobrir o valor oculto, um atacante precisa realizar no máximo 36 tentativas (A-Z + 0–9) — uma tarefa trivial para scripts automatizados. 

Esse cenário representa um claro exemplo de exposição ao risco classificado em  API4:2023 — Consumo Irrestrito de Recursos, já que: 

• endpoint pode ser explorado por meio de brute-force lento; 

• Os identificadores são facilmente enumeráveis; 

• rate limiting é ineficaz frente a um atacante paciente; 

• Há um vetor auxiliar de exposição de padrões fora da aplicação principal. 

 

 

Outro endpoint interessante é o endpoint abaixo: 

/app/api/v4/orders/?email=example@example.comize=10&page=1&clientId=ID 

O endpoint exige um e-mail válido como parâmetro. Esse comportamento pode ser explorado em investigações com técnicas de OSINT, permitindo verificar se um determinado endereço de e-mail já foi utilizado para realizar viagens pela plataforma — incluindo detalhes como datas, locais de origem e destino. Essa exposição representa um risco adicional à privacidade dos usuários. 

Autenticação não é o fim — é só o começo 

É fundamental que qualquer aplicação que lide com dados sensíveis implemente  autenticação obrigatória. Isso evita que informações sejam acessadas de forma anônima ou por agentes não confiáveis. 

No entanto, confiar apenas na autenticação é como trancar a porta da frente e deixar as janelas abertas. A autorização precisa ser o segundo passo essencial: validar se o usuário autenticado tem realmente permissão para acessar aquele recurso específico. Só assim garantimos que os dados estão nas mãos certas. 

Sem esses dois pilares — autenticação e autorização — , qualquer controle de acesso se torna  frágil, superficial e altamente explorável. 

 

Embarcando na categoria API6:2023 Unrestricted Access to Sensitive Business Flow 

 

 

Também foi possível pegar carona em outro endpoint com uma falha de lógica, que nos envia os bilhetes dos viajantes. Se trata de mais um endpoint sem autenticação do tipo HTTP POST. 

Para fazer a requisição é necessário enviar no body request um json com os seguintes dados: destination  e o ticket.  

{"destination":"example@example.com","orderPublicId:"XXXXXX"} 

A aplicação permite que você envie seus próprios bilhetes para outro email desde que você esteja no contexto de já ter realizado a autenticação na aplicação web ou mobile. Todavia, o endpoint utilizado na função de envio de email é utilizado sem requisitar nenhum tipo de gerenciamento de sessão. Desta forma, o endpoint permite uma enumeração de ticket com diferentes respostas para eles. 

Cada ticket válido nos retorna um JSON com o "QUEUED" e quando o ticket não é válido nos retorna EMAIL_NOT_FOUND. A mensagem de erro supramencionada está equivocada, pois a mensagem deveria se referir ao ticket e não ao email. É importante ressaltar que o endereço de email nem precisa estar cadastrado nessa aplicação. 

 

Com a falha acima e com posse de bilhetes ainda válidos, o cenário de ataque cresce e a criatividade é o limite. Alguns dos pontos interessantes que imagino são: 

Possibilidade de envio de phishing para o email do viajante, dizendo que a data da viagem foi alterada e viajar no local desse viajante. 

 

Pontos-chave para proteger endpoints sensíveis: 

• Autenticação obrigatória: nenhum dado sensível deve ser retornado sem validação de identidade. 

• Autorização contextual: o usuário autenticado deve ser, de fato, o dono daquele dado (ex: dono do pedido). 

• Rate limiting e limitação de tentativas: para impedir ataques por força bruta ou enumeração de IDs. 

• Logs e monitoramento inteligente: detectar comportamentos suspeitos antes que virem incidentes. 

Linha do tempo 

02/04 — Entrei em contato com a empresa e reportei a falha. 

07/04 — Entrei em contato com a empresa por um email enviado pelo time de AppSec e comuniquei sobre a falha. 

09/04 — Nenhum contato da empresa referente a correção… 

11/04 — Empresa corrigiu e agradeceu pelo report. 

 

Autora: Emma Pinheiro | Ethical Hacker Specialist at Cipher – A Prosegur Company