Resistência a phishing em primeiro lugar
A autenticação resistente a phishing é a base atual para autenticação segura, o que significa FIDO/WebAuthn, FastPass, PIV/CAC, etc. Esta postagem se concentrará em como aqueles que já atendem a essa linha de base podem levar a segurança para o próximo nível.
Senhas, SMS, notificações push e códigos de uso único são vulneráveis a ataques muito menos sofisticados do que os descritos neste artigo, por isso não os recomendamos.
Onde a resistência ao phishing fica aquém
Como observado acima, FastPass, Passkeys e outros autenticadores FIDO são uma excelente maneira de proteger sua organização contra ataques de phishing, essencialmente exigindo que o invasor ganhe algum tipo de presença em seu dispositivo (ou até mesmo roube fisicamente uma chave).
Os autenticadores resistentes a phishing dependem de dois requisitos definidos pelo NIST: Vinculação do Nome do Verificador e Vinculação de Canal [este é um rascunho da especificação, os comentários estão 'fechados'], que juntos previnem com sucesso a maioria dos ataques de phishing. Tanto o FIDO quanto o FastPass dependem da Vinculação do Nome do Verificador, por exemplo.
Além desses requisitos, os autenticadores resistentes a phishing devem criar um canal protegido entre o navegador e o autenticador para evitar espionagem ou ataques de retransmissão a um dispositivo remoto. Mas os requisitos não levam em conta uma presença maliciosa no dispositivo do usuário. Como resultado, uma classe de ataques mais sofisticados pode ocorrer e, quando bem-sucedidos, permitir que os invasores atendam aos requisitos de resistência a phishing.
Exemplo de ataque: Autenticação entre dispositivos via SOCKS
Imagine uma vítima que clicou em um link que instalou malware em seu sistema. Como linha de base para este ataque, o invasor já deve ser capaz de executar código como o usuário em sua máquina.
|
1 |
O invasor cria um proxy reverso SOCKS entre o dispositivo comprometido e seu próprio dispositivo (Etapa 1 no diagrama). Com a configuração certa, o invasor pode então retransmitir desafios FastPass ou FIDO2 de seu próprio dispositivo para o dispositivo comprometido por meio do proxy SOCKS. |
|
2-3 |
O invasor tenta acessar os recursos do usuário a partir de seu próprio dispositivo e retransmite o desafio de autenticação para o dispositivo do usuário por meio do proxy. |
|
4 |
O navegador pesquisa diretamente do dispositivo do invasor para o servidor Okta, aguardando que o desafio de autenticação seja satisfeito. |
|
5 |
O invasor deve fazer com que o dispositivo comprometido assine a resposta ao desafio com seu TPM.
Uma política bem configurada exigirá a presença do usuário, acionando um prompt voltado para o usuário para biometria ou senha do dispositivo, o que pode levantar suspeitas do usuário. Dado um cenário em que o malware está no dispositivo, no entanto, o invasor pode fornecer uma senha ou cronometrar inteligentemente o ataque de forma que o usuário não se surpreenda com o prompt (por exemplo, quando o usuário estiver longe de sua máquina ou esperando um prompt de autenticação de qualquer maneira). |
|
6-8 |
Finalmente, a resposta do desafio é enviada do dispositivo comprometido para o servidor Okta, passando nas verificações de chave TPM, resistência a phishing e garantias de confiança do dispositivo.
Como resultado, o dispositivo do invasor agora tem uma sessão válida porque conseguiu fazer o proxy transparente da autenticação entre seu navegador da web e o autenticador no dispositivo comprometido. |
Inserir filtros de aplicativos confiáveis
Em agosto de 2024, a Okta lançou um recurso para mitigar esse tipo de ataque para FastPass: Filtros de Aplicativos Confiáveis. Essa configuração de alta segurança permite que os administradores bloqueiem automaticamente qualquer tentativa de autenticação por aplicativos que não estejam especificamente na lista de permissões ou que não estejam assinados ou assinados por um certificado de assinatura de código não confiável.
Como funciona
Quando um aplicativo como o Chrome tenta autenticar usando o FastPass, o widget de login do Okta tentará se conectar ao Okta Verify em execução no dispositivo e, em seguida, fornecerá o desafio de autenticação do backend do Okta.
Enquanto esta conexão está ativa, o Okta Verify rastreia a porta e o processo que criou a conexão no dispositivo. Se a porta e o processo não puderem ser encontrados, pode indicar que a origem era remota e a conexão é descartada.
Se o processo puder ser identificado, o Okta Verify coletará dados detalhados de assinatura sobre o executável, verificando se a assinatura corresponde ao certificado de assinatura de código e se o certificado de assinatura de código é confiável pela cadeia de confiança local.
Por exemplo, usamos SecCodeCopySigningInformation (macOS) WinVerifyTrust (Windows) para obter informações detalhadas sobre o processo. Depois que todos esses dados são capturados, eles são enviados em um desafio-resposta junto com a comprovação de gerenciamento e sinais do dispositivo, tudo reunido e assinado com uma chave vinculada ao hardware.
Monitoramento
Se você usa o FastPass no macOS ou Windows, esses dados estão atualmente disponíveis em seus SysLogs.
Este é um exemplo de login no Okta Dashboard usando o Chrome para macOS.
Ao examinar seus logs, você pode ver com quais aplicativos seus usuários estão se autenticando e criar fluxos de trabalho para alertá-lo sobre novos aplicativos que estão sendo usados. Você vai querer ter um bom entendimento de quais binários estão associados aos aplicativos que estão sendo acessados em sua organização. Por exemplo, os usuários devem se autenticar com o Slack apenas por meio de um navegador ou do aplicativo nativo do Slack.
Aplicação
Depois de compilar uma lista completa de aplicativos que se aplicam a uma determinada política de autenticação, você pode aplicar os Filtros de Aplicativos Confiáveis para bloquear esses ataques antes que eles comecem. Isso pode ser um pouco complexo, por isso, é mais simples criar regras de política de autenticação separadas para cada plataforma de desktop (por exemplo, defina a regra de garantia de plataforma ou dispositivo para macOS ou Windows para uma determinada regra).
Uma vez que sua Expression Language esteja no lugar, qualquer aplicativo que não passar na verificação de assinatura (por exemplo, malware não assinado) será bloqueado, juntamente com a Entrada SysLog relevante. Aplicativos assinados que não estão na lista (como o daemon SSH) também serão bloqueados.
Exemplo 1: Chrome, Firefox e Safari no macOS
Neste exemplo, permitimos todos os principais navegadores compatíveis com macOS, usando a extensão SSO ou as associações de Loopback. Isso significa que apenas as duas associações resistentes a phishing acionarão a regra para FastPass. Observe que aplicativos nativos com suas próprias webviews como o O365 não satisfariam esta regra. Se você quiser permiti-los, precisará incluir seus identificadores também.
Exemplo 2: Edge e Chrome no Windows
O Windows é um pouco mais simples, pois LOOPBACK é a única associação válida para esta verificação. Observe que isso também impedirá fluxos não resistentes a phishing acionados pela associação CUSTOM_URL.
Combinando filtros de aplicativos confiáveis com FIDO ou outros autenticadores
Se você quiser usar um autenticador diferente do FastPass, por exemplo, uma chave de segurança FIDO, também poderá impor Trusted App FIlters nessa regra de autenticação, desde que uma conta Okta Verify esteja registrada nesse dispositivo também.
Para fazer isso, crie uma regra com tudo o que segue:
- Uma condição registrada ou gerenciada
- A linguagem de expressão de filtros de aplicativos confiáveis
- Permita os autenticadores que você gostaria de suportar ou use “Permitir qualquer método”
Se você estiver usando o FastPass no macOS ou Windows em sua organização, poderá começar a monitorar quais aplicativos nativos estão acionando a autenticação do FastPass hoje! Depois de ter uma imagem clara de quais aplicativos confiáveis estão sendo usados, você deve adicionar esses aplicativos à lista de permissões e impedir que todos os outros usem o FastPass.
Se você quiser ver mais sobre este assunto, incluindo uma ótima demonstração de Zach Newton, confira nossa palestra do Oktane 2024 (é necessário registro gratuito).
Tem alguma dúvida sobre o FastPass ou a segurança do dispositivo? Participe do fórum da comunidade Okta FastPass e inicie uma conversa.
Tem perguntas sobre esta postagem do blog? Entre em contato conosco em eng_blogs@okta.com.
Explore mais Blogs de Engenharia perspicazes da Okta para expandir seu conhecimento.
Pronto para se juntar à nossa equipe apaixonada de engenheiros excepcionais? Visite nossa página de carreiras.
Desbloqueie o potencial de gerenciamento de identidade moderno e sofisticado para sua organização. Entre em Contato com o Departamento de Vendas para obter mais informações.
