Sinopse do incidente
Pesquisadores do Salt Labs investigaram uma grande plataforma de tecnologia financeira (FinTech) business-to-business (B2B) que oferece serviços financeiros por meio de aplicativos móveis baseados em API e software como serviço (SaaS) para pequenas e médias empresas (PMEs) e marcas comerciais. Como resultado de vulnerabilidades de API que nossos pesquisadores identificaram, eles conseguiram lançar ataques onde:
- Qualquer usuário poderia enviar transações não autorizadas contra outros clientes
- Qualquer usuário poderia coletar dados confidenciais sobre clientes
A organização utilizava GraphQL em sua pilha de tecnologia para alimentar as atividades de conta dos clientes que usam aplicativos móveis. A organização também aproveitou uma API de terceiros para recuperar registros de transações anteriores de contas de clientes. A implementação falhou em autenticar e autorizar adequadamente os clientes. Como resultado, os pesquisadores do Salt Labs conseguiram enviar transações não autorizadas contra outros clientes do provedor de serviços financeiros, correlacionar a atividade da conta do usuário e recuperar PII sobre os clientes. Como acontece com muitas implementações de API falhas, vários dos problemas que tornam possível explorar os serviços mapeiam para o OWASP API Security Top 10, incluindo:
- Quebra de autorização em nível de objeto (BOLA)
- Quebra de autenticação
- Exposição excessiva de dados
Os serviços em questão vêm de uma divisão de FinTech de uma grande marca de consumo que oferece uma combinação de ofertas B2B e B2C. Manter o anonimato deste provedor de serviços é essencial, por isso higienizamos quaisquer detalhes técnicos que pudessem identificar a organização. Após identificar a vulnerabilidade, revisamos nossas descobertas e fornecemos a mitigação recomendada à organização. Como parte da missão mais ampla do Salt Labs, estamos compartilhando as descobertas aqui para aumentar a conscientização sobre vulnerabilidades de API, incluindo a explicação do padrão de ataque, o detalhamento das etapas para propagar o ataque e o destaque de técnicas de mitigação.
Motivação da pesquisa
O Salt Labs realiza pesquisas de ameaças para ajudar clientes e potenciais clientes a identificar vulnerabilidades em suas próprias APIs. O laboratório também investiga plataformas públicas para descobrir falhas de lógica de aplicação, seguindo práticas de divulgação responsável e trabalhando com as organizações apropriadas para resolver problemas com as APIs. Publicamos essas informações — anonimizadas quando necessário — para ajudar os profissionais a aprender com os erros dos outros e evitar um incidente resultante.
Neste caso, os pesquisadores do Salt Labs investigaram a plataforma de tecnologia financeira online porque a empresa estava preocupada com possíveis lacunas de segurança de API e entrou em contato com a Salt Security para obter assistência. A implementação fazia uso de serviços GraphQL, que têm crescido em popularidade. Vários aspectos da estrutura da API GraphQL podem criar riscos de segurança que podem ser mais difíceis de avaliar. A conscientização sobre segurança em torno do GraphQL ainda é relativamente baixa, e os detalhes da vulnerabilidade da implementação de API desta organização fornecem valor educacional adicional para o setor.
Os potenciais impactos nos negócios da lacuna de segurança de API que encontramos
Uma vulnerabilidade prevalente relacionada ao GraphQL é que os desenvolvedores devem implementar autorização em cada camada de uma consulta GraphQL de várias camadas para evitar ataques. Esse efeito colateral aumenta a carga sobre as equipes de desenvolvimento e operações, e pode estender os cronogramas de entrega para aplicativos com muitos endpoints de API. Também pode criar uma situação mais vulnerável ao erro humano. Alguns endpoints podem ser esquecidos ou não tratados adequadamente, causando seu próprio conjunto de problemas no futuro. Em contraste, as APIs REST incluem controles inerentes de autenticação e autorização, desde que mecanismos como OpenID Connect (OIDC) e OAuth2 sejam implementados corretamente.
Em média, aplicativos móveis incluem um número significativamente maior de vulnerabilidades do que aplicativos baseados na web. A autenticação e a autorização são frequentemente fracas, corrompidas ou ausentes nos projetos de aplicativos móveis, uma vez que os desenvolvedores se concentram principalmente na mobilidade e na usabilidade. Os canais móveis também costumam ser menos seguros do que os canais web. Alternativamente, as bases de código podem ser mantidas por equipes separadas, o que leva a discrepâncias na postura de segurança da API. Os invasores conhecem essa realidade e alternam entre clientes front-end e serviços back-end para encontrar o elo mais fraco ao visar funcionalidades ou dados. As comunicações de API web são frequentemente criptografadas com SSL ou TLS, o que dá às organizações uma falsa sensação de segurança sobre a resistência de um aplicativo ou API a ataques. Nesse caso, os pesquisadores do Salt Labs conseguiram isolar as chamadas de API, solicitar dados por meio de um navegador web padrão e receber identificadores confidenciais que permitiram ataques contra o mecanismo de autorização usado pelo aplicativo.
Ataque: Enviar transações de conta não autorizadas contra clientes
As organizações precisam atender a vários tipos de front-end de aplicativos, normalmente aplicativos web e móveis, que por sua vez se conectam a muitos serviços back-end. Os fluxos de aplicativos geralmente invocam várias chamadas de API internas e externas para fornecer funcionalidade ou dados, e esses fluxos podem variar de acordo com o tipo de usuário ou o aplicativo cliente associado. Garantir que uma entidade autenticada esteja autorizada a acessar um determinado recurso durante uma sessão é mais fácil de falar do que de fazer, especialmente porque a maioria das organizações também trabalha com outros parceiros para habilitar funcionalidades como parte de uma cadeia de suprimentos digital maior. Uma vez que um invasor obtém uma sessão autenticada com níveis de permissão básicos, ele pode abusar da autorização para acessar outros dados ou funcionalidades fornecidos pelas APIs e como parte do design mais amplo do aplicativo.
Em nossa pesquisa, conseguimos alterar números de conta de chamadas de API e realizar transferências de fundos não autorizadas. Os números de conta são uma forma de PII, mas também são úteis para perpetuar fraudes, já que um invasor pode usar as informações para realizar ações em outras contas se uma API não estiver aplicando a autorização corretamente. Neste incidente, um dos números de conta era um identificador exclusivo emitido pelo governo, e o outro era um identificador de conta financeira. Os números de conta poderiam ser coletados e correlacionados por meio de um endpoint de API de terceiros, o que é abordado na próxima seção deste relatório de ameaças.
Ataque: Desanonimizar e correlacionar a atividade da conta
As organizações terceirizam regularmente o trabalho, incluindo engenharia de sistemas e operações. Essa prática comercial é particularmente comum com aplicativos e APIs, uma vez que o trabalho de desenvolvimento e os artefatos de código podem ser originados parcial ou totalmente de terceiros. Infelizmente, um subproduto da terceirização é, muitas vezes, a falta de conhecimento sobre uma arquitetura completa e fluxos de aplicativos de ponta a ponta. As peculiaridades na experiência do usuário são, muitas vezes, o melhor cenário. Na pior das hipóteses, surgem lacunas de segurança significativas onde a infraestrutura pode estar configurada incorretamente ou o código apresenta fraquezas. Esses erros podem levar à exposição de dados confidenciais, lógica de negócios abusável e vulnerabilidades exploráveis para as organizações.
Em nossa pesquisa, descobrimos uma API de terceiros integrada que expôs inadvertidamente dados confidenciais que desanonimizam os clientes e permitem que os invasores correlacionem a atividade da conta. PII, incluindo nomes, endereços e números de conta, foram expostos por este endpoint de API de terceiros. Os únicos dados necessários para chamar esta API e obter as PII eram um identificador de registro de uma transação anterior. Dados confidenciais como os descobertos aqui estão sujeitos a muitas formas de regulamentações nacionais e regionais que regem a atividade comercial e a privacidade do usuário. Tal exposição de dados pode desencadear penalidades e multas regulatórias.
Os detalhes técnicos desta lacuna de segurança de API
Nossos pesquisadores analisaram o aplicativo móvel e as APIs de back-end por meio de uma combinação de métodos que incluíram:
- Análise de repositório Postman
- Engenharia reversa de aplicativos móveis
Usando um repositório Postman fornecido pelo cliente, nossos pesquisadores examinaram a estrutura da API usada pelos clientes de aplicativos móveis. Os pesquisadores começaram a entender que tipos de solicitações obteriam dados úteis que poderiam ser explorados. Em conjunto, nossos pesquisadores também fizeram engenharia reversa do aplicativo móvel e correlacionaram suas descobertas sobre chamadas de API com os registros do repositório Postman. Nossos pesquisadores encontraram e alteraram o certificado SSL/TLS incorporado no aplicativo móvel que era usado para fixação de certificado e criptografia de comunicações de API. Essa contornação de um controle do lado do cliente permitiu que nossos pesquisadores inspecionassem e manipulassem o tráfego de API originado do aplicativo móvel.
Por meio do aplicativo móvel, um invasor poderia visualizar o destinatário de uma transferência de dinheiro. Exercitar a API via Postman também expôs dados de PII relacionados ao remetente e ao destinatário. Além disso, as chamadas de API incluíam dados valiosos que nossos pesquisadores poderiam usar para correlacionar a atividade do cliente e manipular chamadas de API de modo que pudessem agir em uma conta. Nossos pesquisadores validaram esse padrão de ataque escolhendo um usuário, tentando uma transferência de fundos da conta e visualizando a transação no aplicativo móvel.
Os pesquisadores também descobriram chamadas para um endpoint de API de terceiros não autenticado que respondia com um PDF de um recibo de uma determinada transação quando fornecido com um identificador de transação exclusivo. O endpoint da API de terceiros também retornou outras PII, incluindo nomes, endereços, valores em dólares e identificadores de conta que foram úteis para verificar se as tentativas de transação maliciosas foram bem-sucedidas.
Essas vulnerabilidades de segurança estavam localizadas em um endpoint de API GraphQL, um tipo de API que cresceu em popularidade em relação às APIs REST para projetos de aplicativos móveis. A organização não estava autenticando ou autorizando solicitações verificando a identidade do remetente durante solicitações de transferência de fundos. Técnicas de ataque semelhantes funcionam para projetos de API GraphQL e REST. A complexidade do GraphQL, como consultas aninhadas, muitas vezes exacerba os desafios da autorização, já que uma única chamada de API pode consolidar várias consultas e endpoints de API.
Qualquer usuário poderia enviar transações não autorizadas contra outros clientes
O OWASP define problemas de autorização como autorização de nível de objeto quebrada (BOLA)Atacantes exploram falhas de BOLA para elevar privilégios e obter acesso a dados para os quais não possuem autorização. Neste caso, os pesquisadores do Salt Labs conseguiram manipular consultas GraphQL para alterar os destinos de transferências de fundos e autorizar automaticamente essas mesmas transações.
Os pesquisadores da Salt descobriram que um endpoint de API GraphQL permitia parâmetros de consulta controlados pelo cliente no corpo da mensagem da solicitação da API. O endpoint da API tinha a seguinte aparência:
“/BFF/graphql/mutation/doPayment”
Neste ataque de BOLA, a sequência de chamadas da API consistia nas seguintes etapas:
1. Um atacante chama o endpoint usando o identificador único (UID) da vítima, que deposita fundos de uma conta bancária para uma carteira digital. Não há limite para o valor que pode ser transferido, mas, neste caso, uma transferência de $100 foi tentada como teste.
2. O servidor responde com uma mensagem de status 200 OK, indicando que a transação foi enviada com sucesso. Dentro do payload, a variável “status” também indica que a transação está aguardando confirmação. O design do aplicativo não inclui nenhuma notificação à vítima sobre essa transferência. O proprietário da conta original não saberia que o dinheiro foi transferido de sua conta, a menos que estivesse monitorando a atividade da conta de perto. O valor TID é o identificador da transação que pode ser usado para consultar um registro da transação em um endpoint de API de terceiros separado.
O valor UID aqui é um identificador nacional único. Se esse valor for desconhecido para o atacante, ele pode obter a informação chamando um endpoint de API de terceiros separado, conforme descrito na próxima seção. Ao acessar essa API de terceiros com um identificador de transação, um recibo da transação é apresentado ao atacante em formato HTML ou PDF. Esse recibo de transação inclui o número da conta da vítima, ID da carteira digital, endereço, valor em dinheiro e outros exemplos de dados PII. Com esses dados PII obtidos, o atacante pode iniciar transferências para qualquer outra conta ou usuário.
Qualquer usuário poderia coletar dados confidenciais sobre os clientes
Durante a pesquisa de ameaças, os pesquisadores do Salt Labs também descobriram um endpoint de API de terceiros que não exigia autenticação e também expunha dados confidenciais. O primeiro desses problemas mapeia para OWASP API2: Autenticação de Usuário Quebrada. O segundo problema mapeia para OWASP API3: Exposição Excessiva de Dados.
Os pesquisadores da Salt descobriram uma função dentro do endpoint da API GraphQL que, por sua vez, chamava o endpoint vulnerável da API de terceiros. O endpoint da API GraphQL tinha a seguinte aparência:
“/BFF/graphql/mutation/receiptUrl”
Neste ataque de coleta de dados, a sequência de chamadas da API consistia nas seguintes etapas:
1. Após um usuário enviar uma transação bem-sucedida no aplicativo móvel, que por sua vez chama o endpoint GraphQL para a função doPayment, o aplicativo móvel faz outra chamada ao endpoint GraphQL para fornecer um registro da transação. A solicitação contém o identificador do usuário, UID, e o identificador da transação, TID. Essa solicitação parecia com o seguinte:
2. A resposta a essa chamada da API GraphQL contém uma chamada de API REST aninhada que é, por sua vez, invocada pelo aplicativo móvel para retornar um registro da transação em formato PDF. Essa resposta parece com o seguinte:
3. Essa URL aninhada pode ser chamada diretamente com uma solicitação HTTP GET básica ou simplesmente iniciando a URL em um navegador. Apenas o identificador da transação, TID, era necessário como parâmetro, e nenhuma sessão autenticada era necessária para buscar os dados. A API de terceiros responde com um registro completo da transação em formato PDF. Esse recibo em PDF inclui a conta da vítima, ID da carteira digital, nome, endereço, valores em dólares e outros exemplos de dados PII.
O endpoint da API de terceiros foi útil para validar que o ataque de BOLA funcionou conforme o esperado. A API de terceiros também expôs dados confidenciais demais, e realizar as chamadas fora do aplicativo móvel sem qualquer contexto autenticado validou que os controles de acesso não estavam sendo aplicados. Esses dados são úteis para perpetuar outros tipos de fraude na plataforma, e os dados também podem ser usados para desanonimizar clientes e correlacionar a atividade da conta. O endpoint da API também parecia carecer de quaisquer controles de limite de recursos ou de taxa, o que teria tornado possível a enumeração adicional de identificadores de transação e a raspagem em massa.
Métodos para mitigar esta falha de segurança em APIs
Explorar as vulnerabilidades nesta plataforma de serviços financeiros online B2B exigiria a correlação de dados fornecidos por APIs de terceiros e uma manipulação específica da lógica de negócios envolvida na API GraphQL utilizada pelos front-ends de aplicativos móveis. As técnicas adequadas de remediação e mitigação também devem ser específicas.
Mitigação de falhas de autorização que permitem a um invasor enviar e autorizar transações automaticamente
Uma API segura deve exigir a verificação consistente de que o usuário que solicita dados ou funcionalidades está autorizado a acessá-los. O sistema deve validar continuamente a autorização para cada sessão e em cada solicitação de acesso a dados. Essa abordagem de autorização contínua é fundamental para a prática de segurança de privilégio mínimo, que, por sua vez, é uma premissa crucial da arquitetura de confiança zero (zero-trust).
As organizações devem aplicar as seguintes contramedidas para mitigar as fraquezas de autorização identificadas pelo Salt Labs:
- Autorização contínua - a API e os serviços de back-end integrados devem empregar validação contínua para garantir que o usuário autenticado esteja autorizado a acessar os dados ou a função solicitada.
- Retornar códigos de erro HTTP precisos - Se um usuário autenticado tentar acessar os registros de outro usuário, o servidor deve responder com um código de status HTTP “401 Unauthorized” ou “403 Forbidden” e/ou redirecionar o usuário não autenticado para uma página de login que exiba um código de status HTTP 30X.
- Invalidar sessões de solicitações abusivas - Projete a plataforma para monitorar e invalidar sessões em que os usuários estejam fazendo solicitações excessivas, enumerando registros ou fazendo tentativas repetidas de acessar dados não autorizados.
- Evitar nomes padrão ou simples - Use nomes e índices exclusivos que os invasores não consigam adivinhar, forçar ou enumerar facilmente.
- Usar limites de taxa (rate limits) - Aplique limites de taxa nos endpoints da API para evitar a enumeração, levando em consideração que os invasores reduzirão suas taxas de solicitação para evitar a detecção.
- Garantir que a autenticação e a autorização sejam consistentes entre os canais web e móveis - As plataformas devem ser projetadas para implementar autorização e autenticação nesses endpoints vulneráveis e quando os usuários alternam entre canais ou front-ends. SSL e TLS ajudam a criptografar as comunicações da API, mas essa proteção de transporte pode ser contornada por invasores.
Mitigação do risco de desanonimização e correlação
Muitas implementações de API são ecossistemas expansivos ou cadeias de suprimentos digitais, onde uma organização se integra a vários serviços e APIs de terceiros para facilitar os negócios. Esse foi o caso desta organização financeira, já que um dos endpoints de API de terceiros retornava identificadores de conta que se tornaram úteis para perpetuar o ataque de autorização. Esse endpoint de API de terceiros também não exigia autenticação, muito menos autorização.
Aplique as seguintes contramedidas para mitigar as fraquezas de desanonimização e correlação identificadas pelo Salt Labs:
- Autentique sempre e autorize continuamente — Qualquer API que forneça dados confidenciais deve exigir autenticação e validar continuamente se o usuário autenticado está autorizado a acessar o recurso solicitado.
- Use limites de taxa — Aplique limites de taxa nos endpoints da API para evitar formas básicas de enumeração e mitigar o risco de extração de dados em massa. Esteja ciente de que os invasores também controlarão suas taxas de solicitação para evitar a detecção ou o acionamento de um limite de taxa.
- Use entropia suficiente — Certifique-se de que todos os identificadores sejam suficientemente longos, complexos e aleatórios para limitar a eficácia de técnicas de enumeração e ataques de força bruta. Essa contramedida também pode ajudar a manter a pseudonimização, tornando mais difícil para os invasores correlacionarem contas e dados.
- Evite o uso de identificadores estáticos como fator de autenticação — Os identificadores de registro devem ser suficientemente complexos e aleatórios. Além disso, se tais identificadores forem usados como fator de autenticação, eles devem ser dinâmicos e ter prazo de validade. Com tempo suficiente e dependendo das contramedidas de limitação de taxa, os invasores podem realizar ataques de força bruta nesses valores usados em chamadas de API. Esse tipo de falha de API é semelhante à dependência de chaves de API como único meio de autenticação para os chamadores da API. Esses dados podem ser e serão coletados ou alvo de força bruta por invasores.
- Evite expor dados em excesso nas respostas — Não envie aos clientes dados que não sejam necessários para concluir uma determinada função. Considere também quaisquer regulamentações que impactem a transmissão e retenção de dados confidenciais, particularmente no que diz respeito à privacidade.
- Valide a segurança de serviços de terceiros sempre que possível — Parceiros e fornecedores também devem oferecer um nível de garantia em relação à segurança da API, segurança de dados e privacidade do usuário. Alguns elementos de segurança de terceiros podem ser validados pela organização principal, como a validação de que os endpoints da API exigem TLS e autenticação. Você também pode precisar buscar atestados dos fornecedores, já que nem todo código ou configuração estará visível para a organização principal.
Lições aprendidas
Os três principais problemas dentro do OWASP API Security Top 10 estavam todos presentes nesta arquitetura de aplicação: autorização quebrada, autenticação quebrada e exposição excessiva de dados. A organização estava utilizando uma tecnologia mais recente na forma de GraphQL, que traz complexidade adicional e maior risco de problemas de autorização. O GraphQL está ganhando adoção como um facilitador do padrão de design back-end for front-ends (BFF). Muitas organizações estão buscando ativamente iniciativas de GraphQL onde precisam fornecer vários serviços para grandes bases de usuários, nas quais até mesmo a menor latência potencial para sistemas front-end, como aplicativos móveis, é uma preocupação. Os profissionais devem estar cientes, no entanto, de que as implementações de GraphQL são suscetíveis a muitos dos mesmos padrões de ataque de API que o REST. Riscos de segurança potenciais também podem ser agravados e exacerbados com o GraphQL, particularmente com DoS em nível de aplicação e falhas de autorização quebrada.
Os invasores usam técnicas que funcionam universalmente tanto para APIs GraphQL quanto REST. Um dos maiores recursos do GraphQL, a capacidade de consolidar consultas e endpoints, também eleva o risco de segurança. Implementar uma autorização adequada torna-se um esforço complexo ao considerar todas as maneiras pelas quais um determinado front-end pode utilizar uma API GraphQL, que por sua vez chama outras APIs de back-end. O GraphQL traz alguns outros riscos potenciais de segurança dos quais as organizações devem estar cientes à medida que adotam essa tecnologia mais recente. "Segurança por obscuridade" nunca é uma estratégia forte. As organizações devem operar com a mentalidade de que os invasores farão engenharia reversa regularmente em aplicações e chamadas de API, o que inclui todas as formas de binários de aplicativos móveis e protocolos de API.
Um tema recorrente na segurança de APIs é que a arquitetura importa. Este princípio é verdadeiro para seus próprios designs de API, o que você busca em soluções e como aborda a estratégia de segurança. As organizações frequentemente gastam muita mão de obra testando exaustivamente, às vezes automaticamente como parte de pipelines de compilação, mas sempre com o objetivo de tentar identificar o maior número possível de problemas em nível de código e configurações incorretas antes do lançamento em produção. Infelizmente, testar todos os fluxos de aplicação e sequências de chamadas de API é mais fácil falar do que fazer com ferramentas tradicionais de teste de segurança. Além disso, verificar o código antes de seu lançamento em produção tem seus limites — de fato, a maioria dos casos de lógica de negócios abusável só pode ser encontrada analisando comportamentos em tempo de execução. O problema só piora com o desenvolvimento e operações terceirizados. Uma aplicação totalmente integrada e todos os seus serviços formam uma teia complexa de serviços internos e externos, bem como conexões de parceiros, que pode ser melhor descrita como uma cadeia de suprimentos digital.
O Salt Labs detalhou as vulnerabilidades do GraphQL, as etapas que um invasor poderia seguir e as ações preventivas que as organizações podem tomar para mitigar esses tipos de ataques. É fundamental que qualquer API que forneça dados confidenciais, independentemente do protocolo, exija autenticação e autorização. O controle de acesso e o monitoramento de atividades devem ser contínuos durante todas as sessões para garantir que os chamadores da API não estejam solicitando dados ou funcionalidades para os quais não estão autorizados. Essa abordagem é fundamental para a segurança de APIs, bem como para outros princípios de segurança, incluindo privilégio mínimo e arquitetura de confiança zero.
O Salt Labs publica pesquisas sobre ameaças a APIs e recomendações de mitigação para ajudar a trazer conscientização ao espaço de segurança de APIs e educar os profissionais. Todas as organizações estão criando ou integrando APIs de alguma forma. Muitas também estão trabalhando com parceiros e fornecedores para impulsionar seus negócios e fornecer serviços aos clientes. Todas as organizações podem se beneficiar de uma abordagem de ciclo de vida completo para a segurança de APIs, e muitas devem buscar ferramentas dedicadas de segurança de APIs para que possam encontrar e resolver o conjunto completo de possíveis problemas de segurança de APIs.
Se você tem interesse em ver a plataforma de proteção de API da Salt Security em ação, entre em contato conosco para uma demonstração personalizada hoje mesmo!