A página de phishing era a página real
Um kit chamado Bluekit não constrói mais uma tela de login falsa. Ele transmite a tela genuína a partir de um navegador que o atacante controla, captura sua sessão no momento em que você faz login e passa direto pelo MFA. Uma passkey o detém onde um olho mais afiado para falsificações não consegue, e é por isso que o Bromure permite que um perfil compartilhe apenas passkeys do seu Mac.
Por vinte anos, derrotar o phishing significou aprender a identificar a falsificação. O browser-in-the-middle não te dá nada para identificar. Ele te mostra a página de login real e rouba a sua sessão ao vivo enquanto você assiste. O que o detém é uma credencial que você não consegue copiar.
Você recebe uma mensagem sobre um documento compartilhado, um login sinalizado, uma fatura. Você clica. Uma página de login da Microsoft abre, e é a real: as fontes certas, o logo certo, a pequena animação quando você passa de um campo para outro com o Tab, o prompt de autenticação multifator genuíno que faz o seu celular vibrar. Você aprova. Você entrou. Nada pareceu errado, porque quase nada estava errado. A página em que você digitou era a página de login da Microsoft. Mas não era você quem estava falando com ela.
No fim de junho, Harry Everett, da Netcraft, documentou um kit de phishing chamado Bluekit dando esse salto, e a BleepingComputer cobriu o caso na mesma semana. O Bluekit é vendido como serviço: um kit de phishing hospedado com templates para Outlook, Gmail, iCloud, GitHub e uma carteira de criptomoedas ou duas, além de um assistente integrado para escrever o e-mail-isca. Seu novo truque carrega um nome que circula desde que um pesquisador conhecido como mr.d0x o descreveu em 2022: browser-in-the-middle.
A página real, transmitida até você.
O phishing à moda antiga constrói uma falsificação. Alguém clona a página de login, hospeda num domínio parecido e torce para que você ignore a barra de endereços. A defesa cresceu em torno disso: identifique a falsificação, pegue o erro de digitação na URL.
Um kit de proxy reverso como o Evilginx veio em seguida. Ele não clona a página. Ele se posiciona no meio da conexão, um «adversário no meio», e repassa o seu tráfego para o site real, raspando o cookie de sessão à medida que ele passa. (Esse cookie é o pequeno token que um site entrega ao seu navegador depois do login, para que pare de pedir a sua senha a cada clique.) Roubá-lo derrota a maior parte do login multifator, porque o atacante leva a prova de um login concluído em vez da senha.
O browser-in-the-middle é mais estranho e, de certa forma, mais simples. O atacante roda um navegador de verdade no próprio servidor e o aponta para a página de login genuína. Uma biblioteca de código aberto chamada rrweb, criada para reproduzir sessões de usuário, serializa essa página ao vivo e a transmite até você por um WebSocket, um canal persistente de mão dupla entre o seu navegador e o dele. O seu navegador renderiza a estrutura da página real como se você mesmo a tivesse carregado. Você não está vendo uma captura de tela nem um vídeo. Você está controlando remotamente um navegador que está dentro da loja genuína, e as suas teclas digitadas, o seu mouse e a sua aprovação multifator são retransmitidos de volta para ele. Quando o login se completa, ele se completa no navegador dele, e o servidor dele cunha o token de sessão. Eles eram donos da sua sessão desde o primeiro segundo.
Por que se dar ao trabalho? Porque convence de um jeito que um clone nunca convence. Não há página falsa para errar. E como o atacante usa um único navegador consistente para falar com o site real, o login não dispara os alarmes de incompatibilidade de fingerprint (as pequenas inconsistências entre o seu dispositivo e o de um proxy) que às vezes denunciam um kit de proxy reverso. A Netcraft contou cerca de setenta novos hostnames do Bluekit numa única semana. Essa é a produção de um produto.
O que não o detém.
Comece pelas más notícias, porque há muitas.
A autenticação multifator, em suas formas comuns, não detém isso. Um código de uso único e uma aprovação por push provam a mesma coisa, que um login está acontecendo agora, e o ataque precisa que esse login aconteça, porque é o atacante quem está fazendo login. Você faz a prova. Eles ficam com a sessão.
O endurecimento de sessão mais recente ajuda menos do que você esperaria. A Netcraft observa que as Device Bound Session Credentials, um esquema que vincula um cookie de sessão ao dispositivo em que foi emitido, «não conseguem proteger contra o Browser-in-the-Middle, embora ofereçam alguma proteção contra o Adversary-in-the-Middle». A sessão nasce no dispositivo do atacante, então vinculá-la a esse dispositivo protege o atacante, não você. Qualquer coisa acoplada depois do login chega tarde demais, porque a essa altura o atacante detém a sessão por direito.
O isolamento também não o detém, e vale dizer isso com clareza. Um navegador que roda cada aba numa máquina virtual descartável, como o nosso faz, contém o que uma página pode fazer com o seu computador. O browser-in-the-middle não faz nada com o seu computador. Ele toma emprestadas as suas mãos para um login e guarda o resultado num servidor que você nunca vai ver. Você pode jogar fora a sua própria sessão no momento em que fecha a aba. A cópia que importa nunca esteve do seu lado para ser jogada fora. A descartabilidade defende contra uma longa lista de ataques, e o browser-in-the-middle não está na lista.
O que o detém.
Nenhum detector de páginas falsas melhor ajuda aqui, porque não há página falsa. A correção é uma credencial que o atacante não consegue copiar.
Senhas e códigos de uso único compartilham uma propriedade fatal: são strings. Você digita uma string numa página transmitida, o fio a leva e o navegador do outro lado a reproduz. É esse o modelo de negócio inteiro.
Uma passkey é uma chave privada que vive no seu dispositivo e nunca o deixa. Fazer login significa que o seu Mac assina um desafio de uso único depois que você o aprova com o Touch ID, e a assinatura que ele devolve está vinculada ao site exato para o qual você criou a passkey. Seguem-se duas consequências, e ambas quebram o browser-in-the-middle.
Primeiro, não há nada para digitar, então não há nada para retransmitir. O segredo nunca aparece na página, nunca atravessa o WebSocket e nunca fica num campo de formulário para o rrweb transmitir de volta. O navegador do atacante pode pedir o quanto quiser; a assinatura acontece num chip do seu Mac que o servidor do atacante não consegue alcançar.
Segundo, a passkey do seu banco de verdade está registrada no domínio do seu banco de verdade. Quando o host do atacante serve a página na sua frente, o seu Mac procura uma passkey que não existe ali e não oferece nada. O login que deveria levar um toque não acontece. Esse silêncio, o autofill que nunca dispara e a passkey que não está na lista, é o aviso que a barra de endereços falsa costumava te dar e já não consegue mais.
Duas formas de emprestar as credenciais do seu Mac.
O design do navegador importa aqui, porque uma passkey só te defende se ela chegar ao lugar onde você faz login.
O Bromure roda cada sessão de navegação dentro de uma máquina virtual Linux descartável no seu Mac, um pequeno computador separado que ele apaga quando você fecha a janela. Isso contém bem as páginas hostis, mas levanta uma pergunta óbvia: se o navegador vive numa máquina descartável, de onde vêm os seus logins salvos? O Bromure faz você escolher, por perfil, e divide a escolha em dois interruptores de propósito.
Usar Senhas do macOS
A opção ampla, de conveniência. A sessão preenche automaticamente nomes de usuário e senhas a partir das senhas salvas no seu Mac e do Chaveiro do iCloud, e o próprio armazenamento de senhas do Chromium fica apagado. Ela permanece vinculada ao domínio, então não vai preencher automaticamente no host do atacante. Mas uma senha é uma string, e uma pessoa determinada pode digitá-la à mão. Conveniência, com uma borda macia.
Usar Passkeys do macOS
A opção estreita e resistente a phishing. A sessão faz login com passkeys guardadas no seu Mac, e o Touch ID ou a sua senha controlam cada solicitação. Você pode ativar isto deixando o compartilhamento completo de senhas desligado: somente passkeys. Nada para digitar, nada para retransmitir, nada para oferecer no domínio errado. Este interruptor tira o browser-in-the-middle da mesa.
Separá-los é o objetivo. Compartilhar todo o seu Chaveiro com uma sessão é o padrão conveniente; compartilhar somente passkeys é a opção imune ao ataque deste artigo. Somente-passkeys tem o próprio interruptor, então a escolha resistente a phishing te custa um toggle em vez de um projeto de segurança. Você pode rodar um perfil com exatamente uma forma de autenticar, a forma que não pode ser transmitida da sua tela.
O que isto não resolve.
Um toggle não é um campo de força, e os limites importam.
O grande limite merece ser repetido. Se você faz login com uma senha através de uma página browser-in-the-middle, mesmo com um código de uso único ou um push por trás, o atacante ganha uma sessão funcional, e nada sobre uma VM descartável ou um navegador esperto a recupera. O compartilhamento somente-passkeys protege os logins em que você usa uma passkey, e nenhum outro. Muitos sites ainda não as oferecem e, para esses, o velho conselho é o único conselho: não siga links de login de mensagens, abra o site você mesmo.
A detecção ajuda, e o Bromure a usa: DNS filtrado que bloqueia domínios maliciosos conhecidos e uma verificação de phishing por IA que pontua a URL e a estrutura de formulário de uma página antes de você agir. Ambas reduzem as chances. Nenhuma é uma garantia, e o browser-in-the-middle foi projetado para dificultar a detecção. Setenta novos hostnames por semana correm mais rápido que a maioria das blocklists, e um scanner de conteúdo não encontra página falsa para sinalizar. A detecção pega o atacante descuidado. Credenciais resistentes a phishing pegam o cuidadoso.
E o limite mais comum de todos: dá para convencer uma pessoa de muita coisa. Se uma mensagem convincente te leva até um site sem passkey e você digita uma senha que reusou em outro lugar, nenhuma configuração de navegador esteve nesse loop. O compartilhamento somente-passkeys não te torna invencível. Para os logins que mais importam, o seu e-mail, o seu host de código, o seu provedor de identidade, ele remove a string que o atacante veio buscar e deixa uma chave que ele não consegue alcançar.
A barra de endereços falsa está se aposentando.
O conselho que repetimos por duas décadas (confira a URL, procure o cadeado, desconfie da página) presumia que o atacante tinha que forjar algo. O browser-in-the-middle não forja nada. Ele te entrega o artigo genuíno e fica atrás dele com o saco aberto.
A conclusão honesta: um navegador que põe a segurança em primeiro lugar não te torna imune a isto, e preferimos dizer isso a fingir. A resposta migrou dos seus olhos para as suas credenciais. Contra uma página que você não consegue distinguir da real, a defesa durável é fazer login com algo que você não consegue copiar: uma passkey, assinada no seu Mac, vinculada ao domínio real, nunca oferecida ao host do atacante. A parte do Bromure é pequena e específica. Ele torna isso o padrão fácil ao permitir que um perfil compartilhe passkeys e nada mais. Instale-o, ative o somente-passkeys para as contas que você não pode se dar ao luxo de perder, e deixe a próxima página de login de aparência perfeita te pedir um segredo que você não precisa mais dar.