A questão crescente das APIs zumbis e o aumento da superfície de ataque

Oferecer uma API aos clientes aumenta sua receita, mas também expande sua superfície de ataque. As empresas podem oferecer uma API que pode ser incorporada em aplicativos de terceiros para facilitar o desenvolvimento. Por exemplo, incorporar mídia social em um aplicativo permite que os clientes discutam um produto sem adicionar grandes despesas à sua equipe de desenvolvimento. A empresa de mídia social ganha tráfego e visibilidade, e o cliente ganha facilidade de desenvolvimento ao adicionar recursos ao seu aplicativo.

Embora uma API seja boa para marketing e receita, adicionar APIs e endpoints expande sua superfície de ataque. Ter uma API é um risco adicional que pode ser gerenciado, mas todos os endpoints devem ser rigorosamente monitorados e protegidos. A maioria dos administradores concorda que as APIs devem ser monitoradas, mas um ambiente de negócios acelerado, com inúmeras atualizações e implantações, pode acabar perdendo o controle das APIs e adicionando, sem saber, um risco de segurança cibernética chamado “APIs zumbis”.

O que é uma API Zumbi?

Uma API zumbi é (em termos básicos) uma infraestrutura esquecida e negligenciada que permanece disponível para uso, mas as organizações desconhecem sua existência. APIs zumbis podem ser criadas em ambientes pequenos ou grandes, mas geralmente são criadas em ambientes onde os recursos de TI são construídos sem procedimentos rígidos de provisionamento e documentação em vigor. O controle de alterações ajuda a evitar situações de API zumbi, mas também podem ocorrer implantações ou configurações emergenciais realizadas para corrigir um erro crítico específico.

Em um ambiente automatizado, os recursos da nuvem são frequentemente implantados junto com o código do aplicativo. A vantagem é que os desenvolvedores e o pessoal de operações não precisam mais se lembrar de implantar o hardware e configurá-lo manualmente. A automação na implantação de software reduz incidentes baseados em configurações incorretas ou evita problemas em que os desenvolvedores se esquecem de incluir solicitações de provisionamento de recursos para dar suporte a seus aplicativos.

Em alguns ambientes, os desenvolvedores têm acesso aos seus próprios servidores de teste. Esses servidores podem estar acessíveis na Internet pública para que os desenvolvedores possam testar novos códigos. Um servidor de teste de API pode estar disponível para a Internet pública e os desenvolvedores podem pensar que ele não será detectado sem ser publicado.

APIs zumbis podem ser criadas de várias maneiras com seus próprios casos extremos, mesmo com os procedimentos de controle de alterações mais rígidos. Quer ocorram por erros ou por má orientação, as APIs zumbis são uma forma de sombra de TI que pode ser especialmente perigoso para a protecção de dados. Sem monitoramento, um invasor pode recuperar dados durante meses sem limitações ou limitação de taxa. Qualquer investigação de vulnerabilidades ou exploração delas não seria registrada, portanto, análises típicas de segurança cibernética não notificariam os administradores sobre tráfego anômalo.

Como os hackers encontram APIs zumbis?

Assim como as inúmeras maneiras pelas quais uma API zumbi pode ser criada com base na situação, o mesmo pode ser dito para encontrar uma API zumbi. Os hackers poderiam encontrar um ponto final por meio de engenharia reversa de código, revisando repositórios de código aberto ou por meio de um conceito chamado “fuzzing”. Fuzzing é um tipo de descoberta em que scripts são escritos para fazer solicitações em nomes de endpoints de API comuns. Por exemplo, é comum que um endpoint de API usado para autenticação tenha um endpoint chamado “/login” ou “/authenticate” ou algo semelhante. As solicitações são feitas para diferentes nomes de endpoints comuns em sua infraestrutura para descobrir endpoints.

A descoberta em repositórios de código aberto é comum. Os repositórios de código aberto também são vulneráveis à divulgação de segredos, o que significa que os desenvolvedores podem esquecer de remover referências a chaves privadas, credenciais de autenticação e outros dados privados. Referências a endpoints de API também estão disponíveis para descoberta e serão investigadas em busca de quaisquer vulnerabilidades. Se a sua organização não tiver conhecimento dos pontos finais referenciados no código, então eles poderão ser investigados sem qualquer mitigação ou limitação de taxa.

Uma API zumbi nem sempre é vulnerável a explorações de bugs. Por exemplo, a exploração de vulnerabilidades de injeção de SQL pode causar a divulgação de dados de informações confidenciais, mas alguns endpoints são codificados adequadamente com resiliência contra ameaças. Em uma situação de API zumbi, a API pode funcionar normalmente, mas pode ser usada para coletar dados sem quaisquer limitações. É possível que o endpoint tenha um erro de lógica de negócios que possa ser explorado, mas sem monitoramento, qualquer atividade suspeita passaria despercebida.

Violações de dados do mundo real de APIs zumbis

Um bom exemplo de uma API funcionando normalmente, mas sendo usada para enumerar dados silenciosamente, é o Incidente JustDial . JustDial é um dos maiores diretórios locais da Índia, com mais de 100 milhões de usuários. Em 2019, um pesquisador de segurança descobriu que JustDial tinha uma API zumbi aberta para a Internet pública sem qualquer monitoramento implementado. A API retornou informações como nome, e-mail, número de celular, endereço e sexo para qualquer pessoa que fizesse uma solicitação ao endpoint. Nenhuma autenticação foi necessária e o JustDial não estava monitorando para detectar o incidente.

Depois que um pesquisador de segurança detectou a API zumbi, JustDial alegou ter remediado o incidente, mas o mesmo problema foi detectado novamente em 2020. Não está claro se algum terceiro além do pesquisador de segurança, mas porque o endpoint estava aberto à Internet pública com sem monitoramento, o JustDial não pode avaliar a extensão da exfiltração de dados.

Outro exemplo é uma das grandes empresas de tecnologia de São Francisco, conhecida por alguns dos melhores desenvolvedores do mercado, o Facebook. O Facebook teve vários casos de APIs zumbis. Em 2016, os desenvolvedores implantaram um subdomínio (mbasic.beta.facebook.com) para testar a funcionalidade de redefinição de senha. A versão de produção da API tinha limitações de taxa, de modo que os invasores não podiam forçar a senha de seis dígitos enviada aos usuários para redefinir suas senhas. A versão beta não tinha essa limitação, portanto, uma senha de seis dígitos poderia ser forçada em segundos, limitada apenas por uma conexão com a Internet, largura de banda e velocidade de processamento de back-end dos endpoints da API.

Em 2018, o Facebook sofreu outro ataque de API zumbi . A vulnerabilidade foi encontrada no recurso “Ver como” do Facebook. O recurso permitiu que os usuários visualizassem seus perfis como outras pessoas os veem. O endpoint da API para esse recurso não foi bloqueado ou monitorado, então os invasores poderiam visualizar perfis de outros usuários e roubar seus tokens de acesso. Com um token de acesso, um invasor pode roubar o perfil de um usuário e seus dados. O Facebook estimou que 40 milhões de usuários foram afetados e 90 milhões de usuários tiveram que se autenticar novamente para garantir que seu token de acesso não fosse roubado.

Uma empresa menor – mas significativa violação de dados de uma API zumbi – ocorreu em 2022 com um endpoint do Travis CI. Travis CI é um fornecedor de automação usado para implantar infraestrutura e código. Um dos endpoints da API do Travis CI não exigia autenticação e permitia solicitações para obter eventos de log do cliente. Para piorar a situação, os logs eram armazenados em texto simples, para que os dados de log do usuário, incluindo chaves de acesso, pudessem ser recuperados sem quaisquer limitações. Quando o problema foi relatado, a Travis CI estimou que 770 milhões de registros de usuários, incluindo tokens de acesso, chaves e credenciais de nuvem, foram roubados.

Descoberta de API zumbi

Idealmente, os desenvolvedores de software documentam as alterações na infraestrutura para que o controle de alterações inclua novos endpoints de API. O pessoal de operações pode então adicionar endpoints aos agentes de monitoramento, e esses agentes coletam dados para que os monitores de segurança cibernética e análise possam informar aos administradores quando atividades suspeitas são detectadas. Uma API zumbi acontece quando os endpoints não estão documentados, então os agentes de monitoramento não têm conhecimento dos endpoints. Sem monitoramento, quaisquer solicitações podem ser enviadas aos servidores sem qualquer análise e alertas do administrador.

Para lidar com possíveis APIs zumbis, os administradores geralmente instalam agentes na rede para detectar tráfego. Os agentes coletam dados de tráfego e detectam conexões abertas em servidores e outras infraestruturas de rede. O problema dessa estratégia é que as APIs zumbis geralmente permanecem inativas, sem tráfego ou solicitações, até serem descobertas. Eles podem ser descobertos por desenvolvedores, operações ou terceiros na Internet. Somente depois que um terceiro encontrar o endpoint o tráfego será registrado, mas isso não significa que as solicitações acionarão alertas. Uma API zumbi permitirá solicitações padrão sem qualquer “hacking” ou consultas malformadas. É o que torna as APIs zumbis tão perigosas para a divulgação de dados.

Usando inteligência artificial para descobrir APIs zumbis

Em vez de depender de agentes para detectar APIs zumbis de forma reativa, uma solução melhor é trabalhar com inteligência artificial e varreduras em seu código. Essa estratégia tem duas fases: verificar o código do repositório em busca de referências a APIs internas e usar logs de eventos para determinar se a API recebe alguma solicitação.

A primeira etapa é verificar o código em busca de referências a APIs. Essas APIs podem ser externas ou internas, mas você deseja focar nas APIs internas, pois essa infraestrutura afeta seus próprios dados. As referências podem estar em vários repositórios, tanto ativos quanto obsoletos. Você pode nem saber que as referências estão no seu código, mas escaneá-lo irá descobri-las para que uma lista possa ser enviada para a inteligência artificial (IA).

A seguir está um modelo de linguagem grande (LLM) usado para ingerir e analisar logs de eventos. Os logs de eventos podem ser potencialmente gigabytes ou terabytes de dados linha por linha. Os logs de eventos são essenciais para a segurança cibernética e o monitoramento do uso da infraestrutura, portanto, devem ser configurados para servidores que hospedam APIs. Se um endpoint de API for referenciado no código, mas tiver poucos ou nenhum evento de tráfego, você poderá ter uma API zumbi. APIs com referências e numerosos logs de eventos estão sendo usadas e monitoradas para que não sejam consideradas uma API zumbi.

Usar LLMs para processar análises em cada referência de endpoint de API leva tempo, mas os resultados podem surpreender os administradores que não conhecem APIs ativas em seu ambiente. Como exemplo, um estudo de caso da Domino's Pizza India encontraram recentemente 189 APIs zumbis, com 11% delas vinculando informações de identificação pessoal (PII). A descoberta veio depois de verificar 2.063 endpoints e passar 2,2 dias analisando logs de eventos em todo o ambiente da Domino's Pizza India.

Você deve monitorar APIs zumbis?

A resposta é sim!" As APIs Zombie podem deixar os dados de seus clientes, dados internos ou outras informações críticas abertas à divulgação. Num ambiente compatível, esta supervisão poderia custar milhões em multas. Litígios, danos à marca, impacto nas receitas e várias outras consequências negativas estão associados à infraestrutura não monitorada que leva a uma violação de dados.

Ter melhor visibilidade do ambiente de uma organização é fundamental para a segurança cibernética e uma resposta mais rápida a incidentes. À medida que mais organizações implantam infraestrutura na nuvem, é mais importante do que nunca garantir que você não tenha pontas soltas, incluindo APIs zumbis. Documentar sua infraestrutura é um ótimo primeiro passo, mas é possível que algumas APIs passem despercebidas. A varredura contínua do seu código ajuda a identificar APIs zumbis, que podem então ser desabilitadas ou adicionadas aos agentes de monitoramento. Uma melhor visibilidade da sua infraestrutura reduz os riscos de exposição de dados confidenciais e reduz a superfície de ataque.