Inspeção de SSL/TLS e Ataques Man-in-the-Browser

Atualmente, o HTTPS representa mais de 90% do tráfego Web — incluindo downloads de Malware, canais C2 e exfiltração de dados. As ferramentas de Security de perímetro que não conseguem inspecionar TLS veem apenas blocos criptografados, criando um ponto cego que os invasores exploram ativamente. A inspeção de SSL/TLS (também chamada de interceptação de SSL, SSL bumping ou inspeção profunda de pacotes para HTTPS) permite que os gateways de Security descriptografem, inspecionem e criptografem novamente o tráfego HTTPS antes que ele chegue ao endpoint. Essa visibilidade é essencial para a filtragem de conteúdo Web, DLP e a verificação antimalware em ambientes onde a maior parte do tráfego usa HTTPS.

A inspeção de SSL é tecnicamente um man-in-the-middle controlado, realizado pela própria infraestrutura de Security da organização. O processo: Etapa 1: o Client estabelece TLS com o proxy (usando o Certificate do proxy assinado pela CA corporativa). Etapa 2: o proxy estabelece uma sessão TLS separada com o Server real, usando o Certificate real do Server. Etapa 3: o proxy descriptografa o tráfego do Client, inspeciona-o, depois o criptografa novamente e o encaminha ao Server (e vice-versa). O Client confia no Certificate do proxy porque o Certificate da CA corporativa é pré-instalado em todos os endpoints gerenciados por meio de MDM ou Group Policy.

Nem todo tráfego deve ser inspecionado. As organizações normalmente isentam categorias que transportam dados sensíveis do ponto de vista jurídico ou ético: sites bancários e financeiros, portais de Healthcare, bancos de dados de pesquisa jurídica, URLs de transparência de Certificates e OCSP (para evitar a quebra da validação de Certificates) e sites que usam fixação de Certificate (que rejeitarão Certificates novamente assinados e farão o aplicativo parar de funcionar). As exceções são mantidas como uma lista de desvio na Policy de inspeção. Em algumas jurisdições, as leis de monitoramento de funcionários podem restringir a inspeção da navegação Web pessoal, exigindo divulgação clara nas políticas de uso aceitável.

A fixação de Certificate é uma técnica na qual um aplicativo grava o Certificate ou a chave pública esperada de um Server específico e recusa a conexão se o Certificate não corresponder — mesmo que o Certificate seja válido e confiável pelo repositório de CA do OS. Isso interrompe a inspeção de SSL porque o Certificate novamente assinado pelo proxy não corresponde ao valor fixado. Aplicativos móveis (aplicativos bancários e de pagamento) usam frequentemente a fixação de Certificate como medida contra MitM. As empresas precisam desviar esses aplicativos da inspeção, ou eles deixarão de funcionar. Isso também significa que invasores que desejem evitar a inspeção de SSL por parte de seu Malware podem implementar a fixação.

SSL stripping é um ataque man-in-the-middle no qual um invasor intercepta o tráfego HTTPS e o rebaixa para HTTP, permitindo ler e modificar o conteúdo em texto simples. O ataque funciona em conexões que começam como HTTP antes de redirecionar para HTTPS: o invasor intercepta a Request HTTP inicial, mantém uma conexão HTTP com a vítima enquanto estabelece HTTPS com o Server legítimo e retransmite o tráfego de forma transparente. Do ponto de vista da vítima, o site parece usar HTTP. O HTTP Strict Transport Security (HSTS) defende contra SSL stripping informando aos Browsers que sempre usem HTTPS para um domínio, mesmo que o usuário digite HTTP.

Um ataque Man-in-the-Browser (MitB) é uma forma de Trojan bancário que se insere dentro do Browser — como uma extensão maliciosa ou uma injeção no processo do Browser — e modifica páginas Web e transações sem que o usuário perceba. Diferentemente de um MitM de rede, o MitB opera dentro da sessão criptografada, na camada do Browser, portanto o TLS não oferece proteção. O Malware MitB (Zeus, SpyEye) pode: alterar valores de pagamentos, modificar números de contas de destinatários, capturar senhas de uso único e modificar formulários silenciosamente depois que o usuário os preenche. As modificações ocorrem depois da descriptografia TLS e antes que o usuário veja a página renderizada.

O malware de ataque no navegador conecta-se às APIs do navegador na camada de aplicação. No Windows, ele injeta código nos processos do navegador (Chrome, Firefox, IE) usando injeção de DLL ou sequestro de COM e, em seguida, conecta-se às funções JavaScript e às APIs de manipulação do DOM. Quando um usuário acessa o banco, o malware intercepta o JavaScript que renderiza a página e a confirmação da transação, alterando a conta do destinatário para a conta do invasor. O servidor vê a transação correta; os registros HTTPS no servidor não mostram nada incomum. O usuário vê a confirmação correta — com o valor pretendido — enquanto a transferência real vai para a conta do invasor.

A defesa contra ataques no navegador exige controles em camadas. O isolamento do navegador (Menlo Security, Zscaler Browser Isolation) executa a renderização do navegador em uma VM remota na nuvem e transmite apenas pixels para a tela do usuário — o malware não consegue injetar código em um processo do navegador executado em um ambiente remoto. Verificação da transação: os bancos confirmam os detalhes da transação (valor + destinatário) por meio de um canal independente (OTP por SMS que inclui os detalhes da transação), para que o usuário precise verificar o que o servidor realmente recebeu. O EDR do endpoint que detecta injeção de DLL em processos do navegador pode identificar infecções desse tipo. A lista de permissões de extensões do navegador impede extensões maliciosas.

Extensões maliciosas do navegador representam uma ameaça significativa aos endpoints. As extensões têm permissões amplas — podem ler o conteúdo das páginas, modificar solicitações, interceptar envios de formulários e acessar cookies. Uma extensão que se disfarça de ferramenta útil (bloqueador de anúncios, modo escuro) pode coletar credenciais, injetar anúncios, redirecionar o tráfego ou atuar como agente de ataque no navegador. Controles corporativos: use Group Policy ou MDM para restringir a instalação de extensões a uma lista de permissões aprovada. Bloqueie a instalação de extensões provenientes de fontes que não sejam a Chrome Web Store ou os Firefox Add-ons. Audite regularmente as extensões instaladas nos endpoints gerenciados para identificar violações de políticas.

As organizações que implementam inspeção de SSL devem lidar com as implicações de privacidade para os funcionários. Muitas jurisdições e leis trabalhistas exigem um aviso claro antes do monitoramento de tráfego criptografado. Boas práticas: publique uma Política de Uso Aceitável (AUP) que declare explicitamente que o tráfego de rede, incluindo HTTPS, pode ser inspecionado; solicite que os funcionários confirmem a AUP durante a integração; implemente categorias de desvio para sites de bancos e serviços médicos pessoais; e armazene os registros do tráfego descriptografado somente pelo tempo necessário (normalmente de 30 a 90 dias). A assessoria jurídica deve revisar o programa de inspeção antes da implantação, especialmente nos países da EU, onde o GDPR impõe limites mais rigorosos ao monitoramento de funcionários.

Certificate Transparency é uma estrutura (RFC 6962) que exige que todos os certificados TLS publicamente confiáveis sejam registrados em registros CT públicos, auditáveis e somente de acréscimo, antes que os navegadores confiem neles. O CT permite que os proprietários de domínios monitorem certificados emitidos indevidamente: se um invasor conseguir convencer uma CA a emitir um certificado para seu domínio (como aconteceu com a DigiNotar em 2011), os registros CT permitirão uma detecção quase em tempo real. Ferramentas como crt.sh permitem que as equipes de segurança pesquisem nos registros CT todos os certificados emitidos para seu domínio. Os navegadores impõem o CT exigindo uma prova de inclusão no registro (Carimbos de data e hora de certificado assinados, SCTs) incorporada ao handshake TLS.

Teste sua compreensão dos conceitos do CompTIA Security+ (SY0-701) abordados nesta lição.

Nesta lição, você aprendeu que: a inspeção de SSL/TLS descriptografa, inspeciona e criptografa novamente o tráfego HTTPS em um proxy usando um certificado de CA corporativo confiável pelos endpoints gerenciados; a remoção de SSL reduz HTTPS para HTTP e é impedida pelo HSTS; e os ataques do tipo intermediário no navegador injetam código no processo do navegador acima da camada TLS para modificar transações de forma invisível, exigindo isolamento do navegador ou verificação independente da transação como defesas. A seguir, exploraremos a substituição de protocolos Insecure por seus equivalentes Secure.