Atualmente, estamos vendo regularmente os resultados chocantes de uma bombardeio de impulso ataques à medida que a tática se torna um método de ataque comum. Atualmente, as organizações estão enfrentando mais ataques push bombing de autenticação multifator (MFA), em que um invasor geralmente já tem um dos fatores de autenticação, como nome de usuário/senha. O invasor pode então solicitar notificações por push que serão enviadas para o smartphone do usuário.
Os ataques de bombardeio imediatos dependem de Fadiga do MFA. Mesmo que receber uma notificação push inesperada não seja uma ocorrência normal, o usuário pode aprovar a solicitação. Mesmo que o usuário faça a escolha certa e negue a solicitação na primeira vez, ele pode ficar desgastado ou confuso com as mensagens. É necessário apenas um "permitir" e o invasor é então autenticado. Dependendo da estrutura do ambiente e de outros controles de segurança em vigor, isso pode dar ao agente da ameaça acesso a aplicativos, redes ou arquivos corporativos. Recentemente, detalhamos as especificações que ID Plus usa para detectar e se proteger contra esses ataques em um blog chamado Proteção contra ataques de bombardeio com MFA Prompt.
Lidar com a fadiga de MFA é um desafio de segurança interessante para a maioria das organizações. Embora esse tipo de ataque não deva ocorrer todos os dias, se acontecer, sua equipe de segurança precisa saber e reagir. Isso não significa apenas que você está sendo atacado, mas também que algumas credenciais já estão comprometidas. O bombardeio imediato se enquadra na categoria de baixa ocorrência e alto risco. Esta postagem descreve alguns dos métodos fundamentais para lidar com esse tipo de ataque sob a perspectiva de uma equipe de operações de segurança.
Para estar preparado para o Push Bombing e combater a fadiga do MFA, você precisa começar com o elemento humano.
- Conscientização do usuário. Os usuários precisam estar mais do que cientes: eles precisam estar informados, vigilantes e preocupados. Mas, ao mesmo tempo, promover a conscientização sobre a segurança cibernética precisa ser fácil para eles, caso contrário, fracassarão. Fazer um treinamento de conscientização de segurança uma vez por ano pode satisfazer as necessidades de conformidade e traz alguns benefícios, mas não é suficiente para combater um ataque sofisticado. Os usuários devem ser informados de que, se não iniciaram uma comunicação, devem considerá-la suspeita. Se os usuários tiverem as ferramentas e o treinamento certos, eles podem ter uma chance.
- Educação do usuário. Certifique-se de que seus usuários finais saibam que é possível que recebam uma solicitação push-to-auth incorreta e que não devem clicar automaticamente em "ok" na mesma caixa de diálogo que já viram 100 vezes. Para que essa mensagem chegue a alguns ou à maioria dos usuários, o seu programa de segurança deve ter algum tipo de comunicação regular com os usuários, além de uma forma de manter a comunicação - considere um alerta por e-mail, publique o alerta em uma página de blog persistente que todos os usuários possam acessar e adicione links para o alerta em outras documentações da empresa, na sua página de destino de segurança ou torne-o um tema para o Mês de Conscientização sobre Segurança Cibernética.
- Recursos do usuário. Lembre-se de que, para executar com êxito os ataques MFA Fatigue e Prompt Bombing, é muito provável que o invasor já tenha as credenciais do usuário. Os atacantes mais avançados iniciarão o spear phishing e poderão enviar SMS, alertas do WhatsApp, chamadas telefônicas ou e-mails para o usuário para aumentar a confusão com o MFA Fatigue. Para que os usuários possam neutralizar essas tentativas, eles precisam ter confiança em como relatar um problema e realmente entender como a equipe de Help Desk, Service Desk e Segurança se comunica com eles. Novamente, aqui a conscientização não se trata de um treinamento anual, mas de uma comunicação persistente com os usuários e uma compreensão geral de como encontrar os recursos necessários e como as coisas devem funcionar. Se todos os usuários souberem que devem ligar para o ServiceDesk imediatamente e se o ServiceDesk tiver uma documentação atualizada, ou mesmo se alguém da equipe simplesmente lembrar que esse recurso existe e puder localizá-lo, então sua organização estará bem posicionada.
- Ações do usuário. Um usuário sem recursos que não tenha sido treinado é um bom alvo. Os usuários sabem que devem sempre solicitar contato com a central de serviços por meio das ferramentas apropriadas (Teams, Slack etc.) e não aceitar chamadas telefônicas sem que uma comunicação verificada chegue primeiro? Defina as expectativas e forneça uma maneira de verificar se o usuário não tem certeza.
Em resumo, você deve fazer essas perguntas sobre seu programa de segurança e usar as respostas para aprimorar seus processos conforme necessário:
- Os usuários sabem o que fazer se receberem uma solicitação inesperada de push auth?
- Os usuários podem relatar rapidamente um problema de segurança?
- Todos os usuários sabem como entrar em contato com o Service Desk?
- Sua central de serviços sabe como responder a um problema de segurança?
- Os usuários têm um meio de entrar em contato direto com a equipe de segurança?
- Os usuários sabem como a central de serviços pode entrar em contato com eles de forma legítima e que não se deve confiar em contatos fora desse mecanismo?
- Os usuários sabem como validar se um contato é legítimo?
A primeira maneira de evitar a fadiga da MFA é não permitir que ela ocorra. O não uso de senhas elimina o principal vetor de ataque: um par de nome de usuário e senha que pode persistir por meses. Considere usar o FIDO como seu fator primário. Mas o FIDO pode ainda não ser prático para todos - e, se esse for o caso, o que você deve fazer em vez disso?
Como geralmente acontece com a segurança, a melhor prevenção técnica é uma defesa em várias camadas. Aqui estão alguns dos aspectos a serem considerados. Escolha os que melhor se adaptam ao seu ambiente:
- Se você ainda depende de nomes de usuário e senhas, certifique-se de ter pelo menos um cofre de senhas ou, melhor ainda, uma solução completa de PAM (Privileged Authentication Management, Gerenciamento de Autenticação Privilegiada) para seus acessos mais confidenciais. Verifique também se ela está sendo usada corretamente; talvez seja hora de fazer um exame de saúde
- Se houver qualquer suspeita de credenciais comprometidas, force uma redefinição de senha. A redefinição evitará o bombardeio por push no futuro.
- Embora não seja uma prática recomendada alterar as senhas arbitrariamente (por vários motivos), forçar uma alteração de senha limita o tempo em que as credenciais comprometidas podem ser facilmente usadas para bombardeios push.
- Revise sua configuração de MFA para garantir que os padrões de acesso façam sentido. É possível configurar até mesmo as melhores soluções de MFA para permitir muito acesso com verificação limitada.
- As práticas recomendadas de senhas do senso comum também se aplicam. Eduque os usuários para explicar por que eles não devem compartilhar senhas entre serviços. Dessa forma, se ocorrer um comprometimento, isso limitará a superfície de ataque para o bombardeio por push.
- Se estiver confiando muito na autenticação por push ou para proteger dados muito confidenciais, considere aumentar a frequência das solicitações de senhas de uso único (OTP) usando tokens flexíveis ou rígidos. As solicitações de OTP serão vistas pelo invasor em um cenário de ataque e nunca chegarão ao usuário.
Para detectar programaticamente uma solicitação falsa de autenticação por push, talvez seja necessário que muitas coisas funcionem com êxito. Os logs do seu sistema de autenticação devem ser definidos no nível certo, enviados para o coletor de logs adequado, analisados adequadamente e o conteúdo deve estar no local para gerar um alerta apropriado. A partir daí, um SOC (Security Operations Center, Centro de Operações de Segurança) atento, 24 horas por dia, 7 dias por semana, deve receber e reconhecer esse alerta com um manual atualizado sobre o que fazer em seguida. Isso não parece fácil, e não é mesmo. Diversas ferramentas e mecanismos podem reduzir o esforço envolvido, mas o ponto principal é que você precisa identificar o evento de log que lhe interessa, considerar os limites que lhe interessam e descobrir quais ações devem ser tomadas quando receber um alerta e validar todo o processo.
Talvez você queira considerar a possibilidade de ter um alerta significativo para uma rejeição de autenticação por push e reduzir se isso fizer muito barulho. Lembre-se de que, se os seus usuários forem bem treinados, eles poderão informá-lo sobre um problema muito rapidamente. Eles podem até ser mais rápidos do que um SIEM pode analisar os registros, emitir o alerta e o SOC pode detectar e responder a ele. É sempre bom ter um plano de backup e várias camadas de segurança e monitoramento.
Analise os eventos de registro e os cenários hipotéticos baseados em um ataque. É preciso garantir que você identifique e receba os dados corretos. Verifique se há um evento de log específico para um usuário que nega uma solicitação push como o principal item de interesse. Outro item de interesse são as solicitações de autenticação push abandonadas.
Lembre-se de que a detecção de uma solicitação push incorreta significa que você provavelmente também detectou um comprometimento de credenciais. Portanto, mesmo que um usuário diga "Não" à solicitação push, você já pode estar correndo algum risco se houver algum lugar na sua rede corporativa em que uma combinação de nome de usuário/senha possa permitir o acesso. Se você tiver uma detecção de solicitações de autenticação push incorretas, ela poderá servir como um mecanismo de detecção de credenciais comprometidas.
Os usuários da RSA podem ver como o ID Plus usa a autenticação baseada em risco e outros recursos para detectar e se defender contra bombardeios imediatos.
A resposta adequada ao push-bombing depende do limite com o qual você se sente confortável. Mas mesmo com um Push to Authenticate inesperado, um usuário deve ter as sessões interrompidas e ser forçado a alterar sua senha. Lembre-se de que esse deve ser um evento de baixa ocorrência. Proteja-se, não se arrependa. A alteração da senha também evitará possíveis ataques futuros com essas credenciais de usuário específicas.
Mesmo que as senhas estejam mostrando sua idade, se elas fizerem parte da MFA em sua organização, desenvolva e documente um processo confiável para forçar uma redefinição de senha e obtenha a adesão antecipada da liderança para acionar o gatilho de alteração de senha e revogação de sessão em qualquer suspeita de comprometimento. Quanto mais tempo um invasor tiver acesso à sua rede, mais danos ele poderá causar. Leve em conta o tempo de resposta. Entre em contato rápida e proativamente com os usuários ou seus gerentes por meio de um canal confiável se receber um alerta e determine o mecanismo de contato correto para a sua organização, como uma carta por e-mail, para que os usuários e seus gerentes saibam o que aconteceu e fiquem em alerta. A comunicação ajuda muito a criar confiança, o que trará dividendos para qualquer preocupação futura com a segurança.
Lembre-se de que o push-bombing é um tipo de ataque, e você deve priorizar qualquer resposta a ele em seu programa geral em relação à probabilidade e ao risco para o seu ambiente. Se um invasor for bem-sucedido, você terá de contar com os outros controles de segurança para limitar os danos e garantir uma recuperação rápida.
