25 de maio de 2026
As minhas primeiras Vulnerabilidades Críticas no mundo real
Vulnerabilidades
Há umas semanas, o meu trabalho do dia-a-dia levou-me a algo que não esperava: uma cadeia de vulnerabilidades num serviço de terceiros, algumas delas críticas, que quase de certeza estavam em produção há anos.
Este é um writeup do que encontrei, como encontrei e o que significa.
Como começou
Através do meu trabalho do dia-a-dia, deparei-me com um serviço de terceiros que um parceiro usava em produção. Comecei a olhar para a integração. O fornecedor tinha disponibilizado um documento técnico com os detalhes da API.
O endpoint de produção estava lá. Publicamente acessível. Sem qualquer autenticação.
Abri o WSDL - a especificação completa da API, a listar todos os métodos disponíveis, todos os parâmetros, todos os tipos de retorno. Também público e sem autenticação.
Foi o suficiente para me fazer continuar e querer saber mais.
O que encontrei
WSDL e documentação completa da API expostos publicamente
Tanto o endpoint de desenvolvimento como o de produção estavam acessíveis a qualquer pessoa na internet, com a especificação WSDL completa exposta. Não eram necessárias credenciais para ler a documentação técnica completa do serviço.
O serviço usava ainda tempuri.org como namespace XML - o placeholder predefinido da Microsoft para serviços .NET durante o desenvolvimento. Nunca foi alterado para produção. Uma coisa pequena, mas um sinal claro de que o serviço não tinha a maturidade exigida para produção.
Nota: Para ser justo, documentação de API exposta não é, obviamente, uma vulnerabilidade por si só - para uma empresa open-source ou orientada a desenvolvedores, publicar a especificação completa pode ser uma decisão deliberada e perfeitamente razoável. O que torna esta vulnerabilidade relevante aqui é o contexto: combinada com tudo o resto abaixo, fica claro que a exposição foi acidental e não intencional.
Personificação de parceiro com o nome da empresa em texto simples
Cada chamada à API exigia um campo que identificava o parceiro que fazia a chamada. O valor esperado era o nome do parceiro. Literalmente apenas o nome, em texto simples. Sem token, sem assinatura, sem nada que verificasse a identidade.
Qualquer pessoa que soubesse - ou adivinhasse - um nome de parceiro válido podia fazer chamadas à API em nome dele.
IDOR em carrinhos de compra
O endpoint para obter os dados do carrinho de compras aceitava um ID de carrinho. Estes IDs eram sequenciais.
Sem qualquer autenticação e com IDs previsíveis, os carrinhos eram trivialmente enumeráveis: um simples ciclo sobre valores sequenciais devolveria dados de carrinhos de transações que não a própria - incluindo IDs de eventos e outros metadados pertencentes a utilizadores reais.
Cancelar qualquer reserva sem autenticação
Existia um endpoint para cancelar reservas. Recebia um ID de transação. Sem qualquer autenticação ou verificação de propriedade.
Ou seja, qualquer reserva em aberto podia ser cancelada por qualquer pessoa que tivesse o respetivo ID.
Dados pessoais e de faturação expostos sem autenticação
Outro endpoint devolvia os registos de faturação completos para qualquer ID de transação:
- Nome legal
- Morada
- Número de identificação fiscal
- Identificadores de documento fiscal
- Discriminação completa do pagamento
Sem autenticação. IDs sequenciais. Totalmente enumerável.
Bilhetes gratuitos via confirmação de pagamento não autenticada
Esta foi a descoberta mais grave.
Existia um endpoint para confirmar um pagamento. Uma vez chamado, devolvia um bilhete válido. Exigia duas coisas: o nome do parceiro (referido acima) e um ID de transação.
Sem token de pagamento. Sem callback de um gateway de pagamento. Sem qualquer prova criptográfica de que algum dinheiro tinha mudado de mãos.
Em mais do que um evento, chamar o endpoint devolvia uma resposta bem-sucedida e um bilhete válido e resgatável, sem qualquer transação financeira por trás - para bilhetes com valor até 100 €.
Há quanto tempo é que isto estava assim?
Não sei ao certo. Mas com base na estrutura do serviço, no versionamento da API e na natureza das configurações incorretas, estes não eram erros recentes. Quase de certeza que estava a correr assim há anos.
Divulgação
Documentei as descobertas e reportei-as pelos canais da minha empresa. O fornecedor foi notificado e, entretanto, corrigiu os problemas.
Uma nota pessoal
Esta é a primeira vez que encontro e documento vulnerabilidades do mundo real com verdadeiro impacto de negócio. Do tipo em que alguém podia ter obtido bilhetes gratuitos para qualquer evento, ou acedido aos dados pessoais de milhares de utilizadores, ou cancelado reservas em escala de forma silenciosa.
Estou grato por as ter apanhado. E tenho consciência de que, noutro contexto - com outra intenção - o impacto podia ter sido significativo.
É isto que o trabalho de segurança é, às vezes. Não é um CTF, não é um laboratório. É apenas prestar atenção a algo que a maioria das pessoas teria deixado passar.