0
0
Quando se trata de ataques contra interfaces de programação de aplicativos (APIs), os blocos de construção que fornecem acesso a muitos de nossos aplicativos, o OWASP API Top Ten é visto como definitivo – e com razão. Compilada em 2019 com base em uma análise de risco conduzida por um grupo de trabalho da OWASP, bem como na experiência de campo de profissionais de segurança, a lista funciona como uma bíblia para desenvolvedores e profissionais de segurança. Mas delineia muito claramente entre cada um dos tipos de ataque. O que estamos vendo hoje é que ferramentas, técnicas e procedimentos de ataque (TTPs) não seguem mais essas definições claras. Em vez disso, eles estão combinando várias variantes.
Durante o primeiro semestre de 2022, vimos o surgimento do primeiro ataque trinity que utilizou três TTPs da lista OWASP. Eles combinaram autenticação de usuário quebrada (API2) com exposição excessiva de dados (API3) e gerenciamento inadequado de ativos (API9). Embora nosso rastreamento tenha revelado que esses ataques representavam apenas uma pequena proporção dos ataques monitorados – 100 milhões – a taxa de ataques trinity foi consistente ao longo do ano, indicando que deve estar valendo a pena como técnica.
golpe triplo
Os ataques Trinity são poderosos porque permitem que o invasor use cada um dos ataques juntos, resultando em formas complementares de comprometimento. Um preenchimento de credenciais em que os invasores direcionam os mecanismos de autenticação para obter logins de usuários geralmente está associado à autenticação de usuário quebrada (API2), enquanto a exposição excessiva de dados (API3) normalmente vê as APIs exporem muitos dados pessoais. Normalmente, um ataque de preenchimento de credenciais bem-sucedido usará uma funcionalidade de verificador para verificar as APIs de informações do usuário em busca de dados confidenciais do cliente que podem ser roubados imediatamente após o login e, se essa API do verificador retornar mais dados do que o necessário, o invasor efetivamente ganha o jackpot.
Quando se trata de gerenciamento impróprio de ativos (API9), um bom exemplo disso é a Shadow API – uma API que foi criada e esquecida ou negligenciada a ponto de ser efetivamente invisível: ninguém sabe que está lá, gerenciando ou monitorando . Essas APIs geralmente são vulneráveis porque não estão no radar da equipe de segurança. O invasor pode descobri-los facilmente usando padrões de API conhecidos antes de iniciar um ataque de preenchimento de credenciais ou fazer com que a API vaze quantidades excessivas de dados.
Detectar ataques de trindade é problemático para muitas empresas porque elas simplesmente não têm visibilidade da superfície de ataque, pois não conseguem inventariar suas APIs e mantê-las atualizadas. Eles também não monitoram ataques que parecem estar fazendo solicitações legítimas, mas em grandes volumes. Se a solicitação por meio da API parecer válida, ela não acionará um alerta porque os sistemas de segurança da API normalmente não monitoram usando análise baseada em comportamento.
A solução certa para o trabalho?
Muitas organizações viram sua infraestrutura de API crescer organicamente ao longo do tempo e, portanto, começaram e continuam contando com soluções de segurança projetadas para monitorar e detectar aplicativos da Web, como WAFs(web application firewalls ). Essas soluções usam um mecanismo de alerta baseado em assinatura e, portanto, são incapazes de detectar e bloquear, muito menos de se defender contra ataques de trindade. Outros podem confiar em suas ferramentas de bot, mas elas usam JavaScript para determinar e bloquear um ataque. As APIs RESTful usam JSON ou XML, não JavaScript, o que significa que não podem ser monitoradas por software bot.
Como já mencionamos, geralmente há um elemento bot nos ataques de trindade. Eles enumeram rapidamente em toda a infraestrutura, portanto, geralmente são automatizados por bots. Mas, como os WAFs são cegos a ataques de alto volume que fazem solicitações legítimas da API e que as soluções de bot não podem ler as cargas úteis da API, esses ataques simplesmente os ignoram sem serem detectados e sem contestação. Essa falta de compreensão da relação entre a segurança do bot e a segurança da API continua a persistir com os dois frequentemente tratados como problemas separados pelos fornecedores de segurança.
É uma distinção artificial que favorece os invasores e é por isso que faz mais sentido considerar a proteção da API como um problema que requer detecção e mitigação de bots, bem como gerenciamento da segurança da API por meio de descoberta, detecção e defesa. Então, por onde o negócio deve começar?
Uma estratégia unificada de proteção de API
Inicialmente, é imperativo que você controle suas APIs determinando quantas você tem, o que elas fazem e que você faça provisões para poder documentar quaisquer alterações continuamente usando um inventário de tempo de execução. Surpreendentemente, os responsáveis por seu ecossistema de API raramente sabem quantos têm e rotineiramente subestimam os números, por isso pode ser fácil ficar sobrecarregado quando essa descoberta é realizada. No entanto, como os riscos apresentados pelas APIs são diferentes, é relativamente simples priorizá-los.
Algumas APIs serão puramente informativas, enquanto outras podem expor dados confidenciais, como informações de identificação pessoal ou dados de cartão de crédito. Alguns podem não ser devidamente autenticados, enquanto outros podem estar sujeitos a ataques de lógica de negócios, como controle de contas ou raspagem.
A avaliação de risco das APIs permitirá, portanto, que a empresa priorize o inventário, mas lembre-se de que o risco representado por uma API pode mudar com o tempo. Os invasores podem e continuarão a investigar APIs em busca de pontos fracos, e um problema com a configuração ou uma conexão com um sistema menos seguro pode introduzir novas vulnerabilidades.
Com o inventário pronto, você pode considerar qual proteção de tempo de execução deve ser implementada. Isso deve verificar abusos de lógica de negócios, vazamentos de dados e outros tipos de ataque comuns, conforme coberto pelo OWASP Top Ten, mas também deve ser capaz de lidar com mudanças no cenário de ataque, valendo-se da tecnologia de aprendizado de máquina para realizar ataques baseados em ameaças e comportamentais análise. Isso pode determinar a intenção das transações (realizadas por bots ou indivíduos) e rastrear continuamente ataques de API sofisticados à medida que eles se reequipam para evitar a detecção. A ação pode então ser tomada para bloquear ou desviar o ataque, desde o bloqueio básico e limitação de taxa até a inserção e decepção do cabeçalho HTTP.
Um divisor de águas
É apenas observando todo o ciclo de vida da API que a empresa pode esperar proteger suas APIs das formas de ataque atuais e emergentes. Do teste de segurança no desenvolvimento, passando pelo gerenciamento da API como parte de um ecossistema que é rastreado e gerenciado usando um inventário de tempo de execução, até a defesa ativa que procura padrões de ataque, é preciso haver uma abordagem do berço ao túmulo.
O ataque da trindade indica que os invasores estão se tornando muito mais hábeis em analisar como cada API funciona, interage com outras e prevê o resultado de uma determinada transação. É um aumento significativo nas apostas de segurança da API e, no momento, muitos desses ataques não são detectados e não são contestados simplesmente porque as organizações não sabem que estão acontecendo até que seja tarde demais. A forma como realizamos a segurança da API, portanto, deve mudar se quisermos acompanhar a evolução dos ataques .
FONTE: HELPNET SECURITY