Aplicativo “Cadê o busão”, de Rondonópolis, deixou expostos dados pessoais sensíveis de ao menos 20.000 usuários

Aplicativo “Cadê o busão”, de Rondonópolis, deixou expostos dados pessoais sensíveis de ao menos 20.000 usuários REPRODUÇÃO

Este relatório consubstancia uma autópsia técnica. Não visa invalidar o esforço de modernização da mobilidade urbana local, e sim, EXCLUSIVAMENTE, dissecar as falhas de arquitetura e governança que culminaram na exposição de dados pessoais sensíveis de 20.000 usuários (incluindo 5.000 menores). O objetivo é extrair diretrizes corretivas operacionais e legais. Caso seja procurado pra dar exclarecimento e/ou explicações sobre o relatório, não possuo especial interesse pelo anonimato, meu perfil público profissional está disponivel aqui.

1. Arquitetura da Exposição (Over-fetching e BOLA)
A vulnerabilidade, resolvida provisoriamente em 10 de março de 2025 e relatada a um desenvolvedor do app via LinkedIn no dia anterior, residia no endereço de rede (endpoint) responsável pela consulta de saldos dos cartões https://appamtc.rondonopolis.mt.gov.br/api/v2/consultar-cartao. Essa falha se apoiava em erros clássicos de engenharia de software. O primeiro é o over-fetching, que ocorre quando a interface do aplicativo esconde os dados na tela do usuário, mostrando apenas o saldo e a parte inicial do nome, mas o servidor envia “por baixo dos panos” o pacote de dados completo, contendo CPF, data de nascimento e endereço. Na prática, a segurança foi erroneamente delegada à camada visual do aplicativo, em vez de ser tratada no servidor.

 

Resposta do servidor, ao consultar somente o número do cartão. Quando a falha estava ativa, somente esse último era exigido.
O segundo erro foi uma Autorização Quebrada, tecnicamente chamada de Broken Object Level Authorization ou IDOR, onde a interface de consulta exigia apenas o número do cartão para liberar os dados, sem pedir qualquer senha ou autenticação de sessão. Para agravar o cenário, esses identificadores físicos dos cartões possuem entropia nula, ou seja, são apenas números sequenciais de 4 a 5 dígitos. Como um cartão é simplesmente o número do anterior somado de um, e considerando a população local, o universo total de cartões gira em torno de cem mil registros. Isso torna a tentativa de adivinhação e a extração automatizada do banco de dados inteiro uma tarefa trivial para qualquer script de automação básico.

 

O número do cartão do passe possui de 4 a 5 dígitos não anonimizados
2. Regra de Negócio como Vetor de Desanonimização Determinística
A falha técnica foi gravemente amplificada pelas diretrizes operacionais da Autarquia Municipal de Transporte Coletivo (AMTC). A lógica do sistema funcionou como um filtro geográfico excuso. Isso ocorreu porque as regras de negócio exigem obrigatoriamente o preenchimento do endereço residencial completo para a emissão de cartões de gratuidade ou subsídio, como o “Passe Livre” e o “Meio Passe”, uma exigência que não se aplica universalmente aos cartões comuns.

O impacto geodemográfico dessa regra é direto: ter gratuidade significa necessariamente ter a localização residencial exposta atrelada ao nome. Como consequência, a extração de dados mapeou de forma determinística e específica exatamente a parcela mais vulnerável da população do município, que inclui crianças, adolescentes e idosos. O que começou como uma simples falha de software converteu-se, assim, em um risco real e tangível à segurança física dessas pessoas.

3. Rate Limiting por IP
O sistema possuía uma defesa de perímetro configurada para tolerar apenas uma requisição a cada vinte segundos por endereço IP, técnica conhecida como Rate Limiting. Contudo, essa barreira estática colapsou rapidamente ao enfrentar um ataque com topologia dinâmica. Um invasor poderia evadir o bloqueio orquestrando diversas máquinas virtuais temporárias (contêineres Docker) que roteavam o tráfego através da rede de anonimato Tor.

A mecânica do ataque consiste em criar uma máquina virtual, realizar o pedido de dados saindo por um nó aleatório da rede Tor para mascarar a origem da solicitação, capturar o arquivo JSON com as informações do cidadão e, imediatamente, destruir a máquina. A principal conclusão desse episódio é que atrelar a identidade cibernética de um usuário exclusivamente ao seu endereço de IP é uma prática obsoleta. Diante da rotação constante de endereços promovida pela rede Tor, o firewall da prefeitura tornou-se cego, registrando o ataque coordenado e massivo como se fosse um tráfego legítimo de usuários normais dispersos pelo mundo.

4. Topologia de Defesa Comportamental
A contenção eficiente de ataques distribuídos exige abandonar a simples análise de rotas baseada em IP e adotar ferramentas de Análise Comportamental Heurística, que verificam a “assinatura” tecnológica e o comportamento da requisição. Existem soluções aplicáveis de nível corporativo e sem custo para resolver esse problema. Uma delas é o uso de sistemas colaborativos de prevenção de intrusão, como o CrowdSec, que analisam os registros de acesso de forma assíncrona para identificar padrões de varredura automatizada e velocidades anômalas. Essa ferramenta aplica o banimento do tráfego diretamente na camada de rede com base em uma inteligência global alimentada por outros servidores que sofrem ataques parecidos.

Outra alternativa é a adoção de um Firewall de Aplicação Web (WAF) de borda, como o Cloudflare Turnstile, que impõe desafios criptográficos invisíveis no navegador do usuário. Scripts de automação simples (programas do tipo headless) não conseguem resolver essa matemática em segundo plano e são bloqueados antes mesmo de encostarem no servidor da prefeitura. Por fim, pode-se utilizar a identificação por “fingerprinting” de transporte, que bloqueia o acesso com base na assinatura criptográfica da conexão inicial (JA3/JA4). Como robôs automatizados escritos em linguagens de programação geram assinaturas de rede completamente diferentes daquelas geradas por navegadores reais de celulares, essa técnica torna a tática de ficar trocando de IP totalmente inútil.

5. Governança do Incidente e Obrigações Notificatórias
As comunicações entre a equipe de desenvolvimento da interface do aplicativo e o provedor do banco de dados indicam que a resposta inicial ao incidente consistiu na adoção de um bloqueio intermediário provisório para conter o vazamento. A observação aponta que a ausência de auditoria sobre os dados retornados pela API terceirizada, combinada com uma delimitação pouco clara de responsabilidades entre as partes envolvidas, foram os fatores que permitiram o envio excessivo de dados ao aplicativo.


Um aspecto relevante que emerge das comunicações é a preocupação dos profissionais técnicos envolvidos com possíveis consequências individuais. Cabe observar, no entanto, que a LGPD, em seu Artigo 48, atribui a responsabilidade primária pela notificação de incidentes de forma objetiva ao Controlador dos dados — neste caso, a Autarquia Municipal de Transporte Coletivo. A responsabilização pessoal de desenvolvedores, nos termos da legislação, dependeria da demonstração de dolo direto ou de negligência qualificada, elementos que o contexto técnico do incidente não sustenta.

Até a data de publicação deste relatório, não há registro público de que a ANPD ou os responsáveis legais dos menores afetados tenham sido formalmente notificados sobre o incidente. O Artigo 48 da LGPD estabelece que o Controlador deve comunicar à Autoridade Nacional e aos titulares afetados, em prazo razoável, a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante. A ausência dessa notificação tem implicações práticas diretas: sem o conhecimento do vazamento, as famílias dos quase cinco mil menores cujos dados foram expostos ficam impossibilitadas de adotar medidas preventivas contra o uso indevido de seus CPFs e demais informações pessoais.

6. Transparência Ativa, Anonimização Pericial e o Endpoint Exposto
A exposição técnica atinge sua materialidade na revelação do vetor de ataque: o endpoint público https://appamtc.rondonopolis.mt.gov.br/api/v2/consultar-cartao. Para fins de auditoria e dimensionamento deste relatório, é imperativo esclarecer a metodologia de análise empregada. Na estrita observância da legislação vigente e na ausência de autorização legal para a retenção de dados pessoais de terceiros, nenhuma informação identificável foi armazenada durante a constatação da vulnerabilidade.

A volumetria demográfica citada neste documento — os vinte mil usuários e quase cinco mil menores — foi processada utilizando funções de espalhamento criptográfico, processo conhecido como hashing. Ao aplicar um algoritmo matemático unidirecional exclusivamente sobre as informações de CPF e Nome (os únicos identificadores diretos presentes na carga de dados), foi possível transformar esses textos em códigos únicos e irreversíveis. Essa técnica permitiu excluir do cálculo os cartões duplicados pertencentes à mesma pessoa, garantindo a precisão estatística do incidente e mantendo, simultaneamente, a anonimização absoluta da base.

O propósito desta publicação, reitera-se, não reside em descredibilizar a Autarquia Municipal de Transporte Coletivo ou minar a relevância do aplicativo “Cadê o Busão”, que presta um serviço essencial à população de Rondonópolis. A motivação primária é estritamente ética e legal. Diante da recusa categórica da instituição em deflagrar o protocolo de notificação compulsória estabelecido pela LGPD, este documento atua como um instrumento de transparência ativa. O objetivo final é forçar a adequação irrestrita da infraestrutura tecnológica municipal às normas de proteção e, fundamentalmente, garantir que as milhares de famílias cujas residências e identidades foram expostas tenham o conhecimento necessário para exercer seu direito inalienável à autodefesa cibernética.