O que é Public Key Pinning?
Normalmente, o tráfego entre um aplicativo cliente e seu lado do servidor depende da Infraestrutura de Chave Pública (PKI). Embora este mecanismo seja suficiente para a maior parte do tráfego da Internet, o Compromisso de Identidade Segura da Okta exige que consideremos atacantes avançados, persistentes e direcionados, incluindo até mesmo atores de nível estatal.
O Okta usa PKI e TLS como base para toda a comunicação entre os serviços, incluindo o Okta Verify. Em cenários de ataque avançados, no entanto, um certificado público fora do controle da Okta pode ser comprometido e aceito pelo sistema operacional de um dispositivo ou explicitamente confiável pelo usuário desse dispositivo. Nesses casos, um agente de ameaças pode inspecionar e manipular o tráfego entre o Okta Verify e os endpoints do lado do servidor da Okta por meio de um ataque de invasor no meio (AITM, attacker-in-the-middle), o que causa uma série de problemas que explicaremos mais adiante.
Public Key Pinning é uma forma de permitir apenas os certificados esperados pelo aplicativo cliente, bloqueando todos os outros. Isso significa que, mesmo em caso de comprometimento da autoridade de certificação pública (por exemplo, Digicert), nossos aplicativos cliente não aceitarão esses certificados. Em vez disso, um invasor teria que ter roubado as chaves privadas mantidas internamente pela Okta para se passar por nossos servidores.
Exemplo de ataque: WiFi ou VPN falsos
Imagine que um usuário está trabalhando em uma cafeteria. Outro cliente na cafeteria tem um pineapple na mochila. Este dispositivo pode se passar pelo WiFi da loja e assumir conexões de forma agressiva, fingindo alta intensidade de sinal, entre outras táticas inteligentes.
Quando um dispositivo se conecta a uma rede WiFi, ele recebe configurações de rede, como configurações de DNS e proxy, que permitem rotear todo o tráfego para si mesmo antes de enviá-lo para o destino correto. Com um certificado SSL roubado de terceiros (ou perfil aceito), até mesmo o tráfego HTTPS pode ser descriptografado sem levantar um alarme.
Depois que isso estiver em vigor, fluxos como OpenID Connect tornam-se vulneráveis ao redirecionamento de tráfego, o que pode causar o roubo de tokens de acesso ou a definição para outro URL.
Na sequência acima, ocorre a seguinte sequência:
- O Okta Verify tenta conectar-se à configuração openid-configuration da organização, que é exigida pela especificação do protocolo.
- O tráfego é redirecionado para a infraestrutura do invasor.
- Os valores retornados pela infraestrutura do invasor mudarão os principais parâmetros:
- Altere keys_uri para o endpoint de chaves do invasor. Isso permite que o invasor envie JWTs, que passarão na verificação, apesar de não possuírem chaves privadas legítimas.
- Alterar endpoints como token_endpoint que poderiam fazer com que os fluxos de troca de token definidos pelo padrão fossem roteados para a infraestrutura do invasor (que pode então ser interceptada).
- Nesse ponto, o invasor expandiu significativamente a área de superfície, potencialmente levando à tomada de conta se combinado com algum tipo de phishing.
Como a fixação protege você
Existem três objetivos principais ao fixar nossas conexões TLS: autenticidade, integridade e privacidade.
Autenticidade
As aplicações cliente da Okta são implementadas com proteção anti-adulteração e chaves públicas gravadas. A infraestrutura da Okta detém as chaves privadas, por isso, usamos estas para confirmar a identidade do servidor usando as chaves gravadas. Isto significa que o Okta Verify não pode ser enganado para se conectar a um site de phishing ou a outra infraestrutura controlada por atacantes.
Integridade
Embora a maioria dos dados transferidos entre o cliente e o servidor já estejam encapsulados em estruturas verificáveis, como JSON Web Tokens, os endpoints necessários para verificar essas estruturas podem não estar (por exemplo, `/oauth2/v1/keys`). O _key pinning_ impede que o cliente aceite um conjunto de chaves manipulado, o que pode levar a uma grande superfície de ataque, incluindo erros de configuração e ataques de _phishing_.
Privacidade
Embora a Okta trabalhe para minimizar o uso de informações de identificação pessoal (PII), a natureza do Okta Verify Device Assurance inclui a identificação bem-sucedida do dispositivo e sinais detalhados associados a ele para aumentar a segurança de sua organização. Caso terceiros leiam esses dados, eles podem coletar informações sobre usuários e seus dispositivos para uso em ataques ou coleta de dados.
Exemplo de ataque quando o pinning está ativo
Quando o _pinning_ está ativo, o Okta Verify examina a conexão TLS durante o _handshake_ TLS antes de enviar ou receber quaisquer dados. O cliente então derruba a conexão, eliminando imediatamente qualquer chance de uma infraestrutura não Okta ler ou modificar dados em trânsito.
Essa proteção representa um controle atenuante para o Okta FastPass que não é alcançável por outros autenticadores resistentes a phishing, como chaves de hardware / WebAuthN, pois estes dependem da implementação (não fixada) de PKI + TLS do navegador para enviar declarações assinadas pela internet.
As desvantagens
A principal desvantagem do pinning para a Okta é a complexidade operacional. Como sempre, estamos dispostos a aceitar esse trabalho extra para manter nossos clientes mais seguros.
Algumas organizações têm políticas que inspecionam todo o tráfego dentro de seu perímetro de rede. Se o tráfego do Okta Verify estiver incluído nas regras de inspeção, ele bloqueará suas próprias conexões de rede, assim como faria se um invasor realizasse inspeção ou modificação de tráfego.
Pelos motivos listados acima, não podemos permitir a inspeção do tráfego entre o Okta Verify e sua infraestrutura sem expor os clientes aos cenários de ataque listados acima. Se você precisar inspecionar o tráfego em sua rede, você pode permitir que a infraestrutura da Okta seja listada como exceção nas regras de inspeção. As organizações que precisam inspecionar o tráfego de login entre navegadores e a infraestrutura da Okta podem usar um domínio personalizado e inspecionar o tráfego para esse domínio sem impactar o Okta Verify.
Estamos de olho neste espaço e estaríamos abertos a explorar alternativas que representem melhorias de segurança e operacionais. Você pode ter certeza de que, se isso acontecer, a barra de segurança da substituição estará no nível atual ou acima dele.
A Okta assumiu um compromisso de priorizar a segurança. Nós nos esforçamos todos os dias para tornar o Okta Verify o autenticador mais seguro do mundo, protegendo a Okta e nossos clientes. A fixação de chave é uma peça fundamental da segurança geral do Okta Verify, e continuaremos a fazer tudo o que pudermos para mantê-lo seguro.
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.
