Um raro representante do tipo de força bruta: a história de um ataque



Enquanto trabalhamos para proteger a loja on-line de um de nossos clientes, encontramos várias vezes um curioso ataque de força bruta, o que não foi tão fácil de combater. Foi baseado em uma solução simples e graciosa que distinguia o ataque das fileiras de sua espécie. O que ela era e como ainda nos defendíamos dela, lida sob o corte.

Como você sabe, a força bruta “clássica” é um ataque de força bruta de dados. Por exemplo, contas conhecidas são obtidas e senhas são selecionadas para elas de acordo com alguns critérios, gerados dinamicamente ou com base em dicionários roubados. Este é o método básico de invadir contas.

E no caso que descrevi, os atacantes agiram de maneira um pouco diferente. Primeiro, eles usaram uma grande botnet distribuída entre diferentes países a partir de várias centenas de computadores infectados. No sistema de monitoramento, tudo parecia como computadores completamente diferentes, ou proxies em que pessoas reais estavam sentadas e acessavam o site. Esse ataque pode passar despercebido por um longo tempo.

A segunda característica do ataque, além de sua forte distribuição geográfica, era uma enumeração não de logins, mas de logins. Os invasores provavelmente usaram dicionários de senhas populares e listas de login roubadas. E primeiro um login foi levado para a senha conhecida, depois outro, terceiro e assim por diante. Era muito parecido com a situação em que usuários comuns conectados através de um provedor não podem fazer login com suas senhas. Isto é, à primeira vista, nada criminoso. Além disso, o acesso ao recurso era muito raro - um ou dois por minuto.

A terceira característica do ataque foi que a botnet tinha um comportamento muito "humano": os clientes processavam JavaScript, aceitavam cookies.

Devido a esse complexo de fatores, o ataque passou despercebido por um longo tempo. Quando o descobrimos, fizemos uma pergunta não trivial: como nos defender? Todos os computadores botnet não tinham nenhum recurso especial de distinção, com exceção de um determinado erro no agente do usuário. Mas não bloqueamos o ataque com base nesse sinal, porque nesse caso deixaríamos de ver as ações do atacante. Foi necessário destacar algumas outras anomalias. Nada de especial aconteceu em termos de endereços IP. Também é impossível bloquear logins que fazem um grande número de tentativas malsucedidas de logon, porque a frequência é muito baixa e o logon não é embaralhado. Havia apenas uma maneira - de introduzir o captcha. Mas o cliente realmente não queria fazer isso, porque acreditava que o captcha poderia alienar muitos clientes. Enquanto isso, os atacantes já conseguiram escolher as combinações certas para algumas contas.

Certamente você está perplexo: por que alguém invadiria as contas dos clientes de uma loja online? O fato é que na sua conta são acumulados pontos de bônus, que podem ser usados ​​para receber descontos em mercadorias. Provavelmente alguém realmente queria comprar ou vender pontos de bônus na Internet.

Como resultado, convencemos o cliente a implementar o captcha usando as ferramentas F5: ele deveria ter aparecido após um determinado número de entradas sem êxito. Mas primeiro, era necessário configurar os critérios para o login bem-sucedido no sistema. Isso acabou sendo um pouco mais complicado do que parecia, porque em alguns casos o recurso fornece o mesmo código de resposta para qualquer tentativa de login. Como critério para o sucesso do login, optamos por enviar os cookies do domínio do cliente.

Na versão mais recente do F5 ASM , tornou-se possível responder às tentativas de seleção em termos de ID do dispositivo - um identificador exclusivo do navegador. Um código JS é adicionado à página e, quando a máquina infectada abre essa página, ele relata seu identificador exclusivo. No caso de nossos invasores, verificou-se que o ID do dispositivo do navegador era o mesmo para cada endereço IP. Na verdade, é um navegador acessado a partir de um endereço IP.



Portanto, você pode definir o seguinte critério: se mais de 5 tentativas de login malsucedidas forem feitas em um navegador em 15 minutos, um captcha será mostrado para esse cliente. Se este for um usuário realmente normal, ele o resolverá e fará o logon com calma. Caso o navegador não suporte JavaScript, adicionamos exceções. Mas, para não enfraquecer a proteção, usamos um critério diferente: se mais de 20 tentativas malsucedidas de login forem feitas a partir de um endereço IP, um captcha será novamente oferecido. Novamente: para um usuário normal, isso não causará problemas.

Mas hoje já existem métodos de burlar a proteção usando o captcha. Por exemplo, as redes de bots enviam captchas para a "terceirização" - para a China ou a Índia, onde os trabalhadores locais por uma pequena taxa resolvem captchas e retornam valores de texto. Mas, nesse caso, você pode tomar as medidas apropriadas: mesmo que as tentativas de login não tenham êxito, as tentativas de login poderão ser bloqueadas de um IP ou ID de dispositivo específico se o número especificado de tentativas malsucedidas for excedido.

A última vez que a loja on-line foi atacada dessa maneira, gerenciamos o captcha e ele funcionou. Após sua introdução, o ataque de força bruta gradualmente começou a desaparecer e eventualmente cessou. Cerca de um ano se passou desde então - não houve recaídas.

Andrei Chernykh, especialista no Centro de Segurança da Informação Jet Infosystems

Source: https://habr.com/ru/post/pt414487/


All Articles