Três sinais de um ataque de aplicativo que os desenvolvedores devem saber
Os aplicativos estão sob cerco. Os ataques ocorrem com frequência alarmante – a cada 39 segundos, de acordo com uma pesquisa conduzida pela Universidade de Maryland – com probabilidade assustadoramente alta de sucesso.
Os desenvolvedores, que cada vez mais assumem o fardo de proteger esses aplicativos, estão bem cientes da ameaça. Uma pesquisa do final de 2017 com desenvolvedores node.js feita pela NodeSource e Sqreen descobriu que “mais de um terço de todos os entrevistados (34%) acreditam que há uma grande chance de sua organização ser alvo de um ataque em larga escala nos próximos seis meses”. Considerando nossas próprias descobertas de que o vetor de ataque inicial em 86% dos ataques é o próprio aplicativo ou identidades, essa crença é mais do que razoável.
Pode ser perturbador descobrir então que “35% dos entrevistados não tinham certeza de como identificar um ataque enquanto ele estava acontecendo”. Eles esperam uma, mas não sabem como reconhecê-la quando ela acontece. Se você não tem certeza de como identificar um ataque em andamento, é extremamente difícil detê-lo.
Isso torna ainda mais preocupante o número de 23% de desenvolvedores Node.js (23%) que não usam nenhuma forma de proteção em tempo real contra ataques.
A boa notícia é que, com base em nossa própria pesquisa sobre o estado da entrega de aplicativos 2018, a maioria das organizações usa algum tipo de proteção em tempo real contra ataques. Quatro em cada cinco usam duas ou mais tecnologias, incluindo firewall de aplicativo da web (57%), autoproteção de aplicativo em tempo de execução (11%) e análise de comportamento do usuário (26%).
A característica que todas essas tecnologias têm em comum é o que muitas vezes falta aos desenvolvedores: visibilidade. A visibilidade é necessária porque, para detectar (e, quem sabe, identificar) um ataque, você precisa ser capaz de reconhecer comportamentos anormais.
Os aplicativos e seus serviços têm padrões de uso bastante previsíveis. Por exemplo, aplicativos de logon único (SSO) tendem a ter uso intenso nas manhãs de segunda-feira e uso moderado nas tardes de sexta-feira. Os aplicativos financeiros tendem a ser muito utilizados pouco antes de eventos financeiros – dias de pagamento, encerramentos de períodos fiscais e encerramentos de anos fiscais.
Até mesmo aplicativos voltados para o consumidor têm padrões de uso previsíveis que podem ser usados para ajudar a detectar comportamentos incomuns (e potencialmente perigosos). Por exemplo, em abril de 2017 , a Malauzai Software divulgou um de seus relatórios mensais de “pequenos dados” com base em dados de uso coletados de mais de “435 bancos e cooperativas de crédito, cobrindo 13,2 milhões de logins de 730.000 usuários ativos de Internet e Mobile Banking”. Nele, aprendemos que “100% dos usuários finais veem seus saldos e revisam o histórico de transações recentes. Isso ocorre porque os saldos e o histórico recente são exibidos na página de destino para que todos possam ver. E é por isso que eles vêm. 77% das vezes. Em 77% das vezes, tudo o que o usuário faz é verificar saldos e históricos. Apenas 23% das interações gerais no banco digital vão além de saldos e históricos para executar alguma outra tarefa.”
Você poderia inferir, então, que um interesse repentino em outros tipos de transações poderia ser indicativo de um ataque.
Infelizmente, essas estatísticas nem sempre estão disponíveis para todas as aplicações. É por isso que a visibilidade (monitoramento) é importante, para que você possa estabelecer uma linha de base contra a qual as anomalias se tornam óbvias. É claro que nem todas as anomalias são indicativas de um ataque. Um pico no uso do serviço SSO no meio da semana pode ser devido a um prazo para alterar senhas corporativas ou porque segunda e terça foram feriados e não havia ninguém no escritório. Ainda assim, ter uma linha de base lhe dá uma vantagem na identificação do comportamento que pode indicar que um ataque está em andamento.
Não deixe de verificar esses três padrões de uso anormais caso eles sejam, de fato, um ataque. Porque muitas vezes eles são.
1. Aumento dramático nas conexões. Talvez você tenha se tornado viral, mas é provável que haja algo mais acontecendo. Quando você vê um aumento significativo nas taxas de conexão, é uma boa ideia verificar imediatamente se há um aumento correspondente no tráfego de rede. Caso contrário, seus sentidos de aranha devem estar formigando, pois isso é um ataque em potencial. Os ataques DDoS baseados em HTTP são os mais fáceis de perpetuar, porque eles dependem simplesmente de pulverizar uma tonelada métrica de HTTP GETs em um aplicativo e nada mais. Muitas vezes, eles nem tentam acessar URLs reais, porque o objetivo é apenas consumir o máximo de conexões possível e forçá-lo a uma situação de sobrecarga.
Se o aumento for direcionado especificamente a URLs ou serviços que fornecem logins, você poderá ser vítima de um ataque de força bruta para obter acesso.
Procure por erros de servidor, desempenho cada vez mais degradado e exaustão de recursos como sinais de um ataque em andamento.
2. Tamanho da resposta de saída. Uma resposta de saída repentinamente grande pode indicar um ataque de exfiltração bem-sucedido, no qual o invasor obteve acesso a dados que não deveria ter. Este é um dos principais sinais de alerta de um ataque SQLi bem-sucedido, pois os invasores geralmente usam curingas para obter acesso não autorizado aos dados. Você pensaria que o SQLi é um vetor de ataque tão bem compreendido que agora já teríamos coberto isso. Mas o SQLi está consistentemente entre os ataques mais bem-sucedidos todos os anos em vários relatórios do setor.
Basicamente, o ataque é projetado para contornar restrições de acesso a dados. Então, em vez de receber um único registro (ou mesmo alguns), o ataque pode receber milhares . Um ataque bem-sucedido, então, será perceptível porque a quantidade de dados retornados será significativamente maior do que o normal.
Qualquer diferença significativa no tamanho da resposta deve ser suficiente para justificar uma investigação imediata.
3. Falhas e travamentos. Embora isso possa ser explicado por defeitos ou entradas acidentalmente "ruins", elas também podem ser indicativas de tentativas de estourar buffers em bibliotecas de terceiros ou plataformas de servidores web (ou seu aplicativo) na esperança de explorar uma vulnerabilidade nova (ou antiga). Embora seja bom que os sistemas possam simplesmente "reiniciar" a si mesmos hoje em dia, não é bom ignorar o motivo pelo qual eles precisaram ser reiniciados .
Embora possa ser tentador ignorar uma falha ocasional, não faça isso.
Não ignore falhas e travamentos e considere arquiteturas que permitam colocar em quarentena sistemas defeituosos até que você possa examiná-los.
Obviamente, esta não é uma lista completa, mas é um bom começo para identificar quando um aplicativo pode estar sob ataque — e detê-lo imediatamente.
Fique seguro!