*Por Pedro Garcia
O rápido crescimento das fintechs, as startups de tecnologia financeira, tem trazido ganhos extraordinários a investidores e serviços de qualidade para o usuário, a custos justos. Porém, esta acelerada expansão tem deixado brechas de segurança que colocam em risco não só projetos robustos como ecossistemas inteiros.
É o que mostra relatório recente da Salt Security , empresa líder mundial em segurança de API, que detalha uma falha de SSRF (Server-Side Request Forgery) descoberta em uma plataforma fintech, responsável por uma ampla gama de serviços para centenas de bancos e milhões de clientes.
A vulnerabilidade permitia o controle administrativo de contas, dando a possibilidade aos criminosos de ganhar acesso administrativo ao sistema bancário, aos dados bancários e pessoais de clientes e transações financeiras, além, é claro, de realizar transferências de recursos não autorizadas para as contas de criminosos.
Plataformas como esta são consideradas alvos prioritários por invasores que procuram abusar das vulnerabilidades de APIs. Isso acontece por duas razões principais. Primeiro, o cenário da API e a funcionalidade geral são muito ricos e complexos, o que deixa muito espaço para erros ou detalhes ignorados no desenvolvimento. Segundo, se um mau ator pode abusar com sucesso desse tipo de plataforma, os lucros potenciais são enormes, pois pode permitir o controle de milhões de contas bancárias e fundos de usuários.
Para entender a extensão da vulnerabilidade, vale lembrar que os ecossistemas de API de provedores de serviços financeiros são vastos, com clientes, bancos e cooperativas de crédito trocando informações via APIs em uma rede complexa de sites, aplicativos, integrações personalizadas, webhooks e muito mais.
No caso em questão, os profissionais da Salt conseguiram manipular várias dessas interações externas que exigem valores de entrada, como valores de URL, que levaram à descoberta do SSRF. Abaixo, os principais trechos das descobertas.
Como a Salt descobriu a vulnerabilidade ?
Como conta no relatório, a estratégia inicial da Salt em casos como este é simplesmente navegar pelas regiões relevantes do site enquanto registra todo o tráfego. Mais tarde, os técnicos poderiam dar uma olhada no tráfego para identificar lugares que podem conter bugs. E, durante uma dessas verificações iniciais, eles encontraram uma página no site da fintech que suportava a funcionalidade de transferência de fundos da plataforma.
Até aí, tudo bem. A página fazia exatamente o que se esperaria dela: permitir a transferência de fundos para um banco externo. O usuário podia escolher para qual banco transferir os fundos e preencher todos os detalhes necessários – então os fundos eram transferidos. A funcionalidade era direta para o cliente, mas como ela funciona nos bastidores? Os pesquisadores então observaram o tráfego real sendo enviado depois que os fundos eram transferidos.
Um aspecto que descobriram foi que o corpo da solicitação carregava um token JWT Bearer, que nada mais é que uma chave assinada criptograficamente que permite ao servidor saber quem é o usuário solicitante e quais permissões ele possui.
Foi então que, olhando os dados da solicitação, eles perceberam que os parâmetros de solicitação incluíam, como deveriam, os dados necessários para essa transferência de fundos. Mas para qualquer um que lida com segurança na web, um parâmetro chamava a atenção imediatamente: “InstitutionUrl”.
Ora, “InstitutionUrl” é um valor fornecido pelo usuário que inclui um URL apontando para algum valor GUID colocado no site do banco receptor. A parte mais interessante de entender disso era saber como o servidor web do banco lida com uma URL fornecida pelo usuário. A plataforma tenta entrar em contato com esse URL por conta própria? O que acontece se um usuário inserir um URL arbitrário, como www.google.com? O servidor web ainda tentará alcançá-lo? Se isso acontecer, isso seria um problema de segurança potencialmente muito crítico – uma falsificação de solicitação do lado do servidor (SSRF).
Para determinar se o servidor realmente contata qualquer domínio arbitrário fornecido pelo usuário, os pesquisadores forneceram o próprio URL do banco. Claro que a transferência de fundos provavelmente falharia, mas analisando o tráfego de entrada do próprio URL, eles poderiam verificar esse ponto e inspecionar ainda mais o tráfego recebido.
Mandada a solicitação, o resultado foi um strike: havia uma conexão chegando ao servidor. Ver esse tráfego validou a suspeita e significou que o servidor confiava cegamente nos domínios fornecidos a ele nesse parâmetro e emitia uma solicitação para essa URL.
Depois disso, ao inspecionar esta nova solicitação que estava chegando ao nosso servidor, eles encontraram um outro token JWT, usado para autenticação. Como os tokens JWT contêm campos de texto simplesmente codificados (e assinados), foi possível facilmente inspecionar seu conteúdo.
Olhando para dentro, perceberam que a solicitação do servidor continha um token JWT diferente do original, e esse token continha um escopo chamado “service-request/request”, também diferente do JWT da solicitação original. E parecia que este novo token não continha restrições de grupo.
Neste ponto, a dúvida dos pesquisadores era saber como usar esse novo token JWT com o site. Eles então tentaram incorporar esse novo token JWT em uma solicitação que haviam encontrado anteriormente. A solicitação de API foi para um endpoint chamado “/accounts/account”. E quando usado com o token JWT original, essa solicitação simplesmente retornou as informações da conta dos pesquisadores.
Mas, o que ele retornaria se fosse usado o novo token JWT? O resultado foi simplesmente uma lista de todos os usuários e seus detalhes na plataforma. Mas não parou por aí.
Em seguida, os profissionais da Salt fizeram mais uma solicitação para um endpoint de API diferente, desta vez usando o endpoint “/transactions/transactions”. Você consegue adivinhar o que receberam em resposta? Uma lista de todas as transações feitas por cada usuário no sistema bancário!
Como diz o relatório, no mínimo, um invasor poderia ter vazado todos os dados pessoais dos usuários da plataforma e todas as suas transações bancárias. Por razões de ética nos negócios, a Salt não pesquisou além, mas, a partir das descobertas, já tinha a certeza de que o dano potencial teria sido muito mais significativo, permitindo potencialmente a manipulação de fundos de usuários e talvez até esvaziando contas de todos os seus fundos.
Lições para desenvolvedores
A Salt destaca que, nessa vulnerabilidade, a entrada controlada pelo usuário foi a grande culpada. “Tais parâmetros nunca devem ser confiados cegamente. Os desenvolvedores de software e API devem sempre certificar-se de aplicar o máximo de proteções possível a qualquer entrada do usuário, especialmente se os valores de entrada forem suscetíveis a ataques como valores de URL que podem levar a SSRF ou outras classes de vulnerabilidade”, afirma o relatório.
Para a Salt, a proteção mais eficaz neste caso seria uma combinação de proteções estáticas – como saneamento básico ou whitelisting – combinadas com proteções de tempo de execução que identificariam anomalias de tráfego de API. Tais proteções seriam capazes de fechar quaisquer lacunas ou desvios feitos nos métodos estáticos.
Vale dizer que essa pesquisa de ameaças mostra o risco comum e o dano potencial que acompanha qualquer implementação de API. O aspecto mais preocupante dessa situação é que todo o ataque – todas as pesquisas da Salt, no caso – passaram completamente despercebidas pelo banco. Isso porque a fintech usava soluções WAF tradicionais para proteger seus sites e, infelizmente, esses dispositivos não conseguem detectar as manipulações sutis características dos ataques de API.
“Essa fintech não é caso isolado”
Para Daniela Costa, diretora para a América Latina da Salt Security, “a investigação do Salt Labs ganha ainda maior relevância pelo fato de esta fintech oferecer um serviço de transformação digital para bancos de todos os portes, permitindo que eles entreguem online muitos de seus serviços bancários tradicionais, através de uma plataforma já ativamente integrada aos sistemas de muitos bancos e cooperativas de crédito, com seus serviços sendo usados diariamente por milhões de pessoas”.
Em documento divulgado pela Salt à imprensa, ela afirma ainda que “este caso reforça a importância de sempre se buscar o equilíbrio entre a demanda por uma rápida entrega de uma solução eficiente e a prioridade absoluta que a segurança sempre teve ter, como a fórmula ideal para se mitigar riscos”, acrescentando que o emprego de APIs de terceiros é um dos fundamentos do Open Banking.
“Todos os problemas detectados nesta investigação foram corrigidos e faz parte da missão mais ampla do Salt Labs compartilhar as descobertas como forma de aumentar a conscientização em torno das vulnerabilidades das APIs. A análise incluiu detalhes do padrão de ataque e quais as técnicas mais adequadas para aumentar a segurança de API”, explica.
Após destacar que a fintech estudada não é um caso isolado, Daniela Costa chama a atenção para o fato de que, para evitar fugas de informação sensível e interrupção de serviços, as equipes de segurança e desenvolvimento devem trabalhar em colaboração. “Proteções estáticas, aliadas a análises ao longo do tempo para identificar anomalias no tráfego da API, entregam uma segurança mais eficaz”, afirma.
Por fim, ela salienta que “o aspecto mais preocupante nesta situação é que todo o trabalho de pesquisa sobre vulnerabilidades e ataques a APIs que o Salt Labs realizou passou completamente despercebido por esta fintech”.
Novas abordagens
Por tudo isso, é fundamental que todo o corpo diretivo das empresas atue mais de perto com os CISOs em prol da segurança da informação. A tendência é que aumente mais a pressão para que elas demonstrem responsabilidade e entreguem aos seus clientes processos e políticas robustos para mitigar riscos.
Os ataques só tendem a aumentar. Em contraponto, o uso de inteligência artificial para a defesa, como é o caso da Salt Security, possibilita aprender o comportamento do atacante, alimentando uma base de conhecimento em tempo real e permitindo identificar ataques e mobilizar defesas, mesmo nos casos mais criativos.
Essa é uma boa notícia, e muito necessária. Principalmente se lembramos que, de acordo com o relatório Salt Security State of API Security Report do primeiro trimestre de 2022, 95% das organizações sofreram um incidente de segurança de API nos últimos 12 meses. Além disso, pesquisas mostraram um crescimento de 681% do tráfego de APIs maliciosas no mesmo período.
É para se preocupar, mas, principalmente, para se proteger.
SSRF no Top 10 da OWASP
A falha detectada pela Salt e divulgada recentemente é de uma categoria, a chamada Server-Side Request Forgery (SSRF), que entrou, em 2021, no Top 10 do ranking realizado pela OWASP.
O OWASP Top 10 é um documento de conscientização de padrões para desenvolvedores e segurança de aplicativos da web. Ele representa um amplo consenso sobre os riscos de segurança mais críticos para aplicativos da web e é reconhecido globalmente pelos desenvolvedores como o primeiro passo para uma codificação mais segura.
A ideia do ranking é que as empresas passem a adotar o documento e iniciem o processo de garantir que suas aplicações web minimizem esses riscos. Usar o OWASP Top 10 talvez pode ser um primeiro passo mais eficaz para mudar a cultura de desenvolvimento de software em uma organização no sentindo de produção de um código mais seguro.
Além do SSRF, que está em 10º lugar, o ranking traz ainda as seguintes falhas: 1º, controle de acesso quebrado; 2º, falhas criptográficas; 3º,
injeção; 4º, design inseguro; 5º, configuração incorreta de segurança; 6º, componentes vulneráveis e desatualizados; 7º, falhas de identificação e autenticação; 8º, falhas de software e de integridade dos dados; e 9º, falhas de registro e de monitoramento de segurança.
- Pedro Garcia é diretor da Datanary Cyber Intelligence, empresa que atua como um Hub de soluções líderes de mercado com a aplicação de Inteligência Artificial para segurança e proteção de dados.
