{"id":22047,"date":"2020-04-06T13:33:07","date_gmt":"2020-04-06T11:33:07","guid":{"rendered":"https:\/\/mailcommsgroup.com\/blog\/como-atacantes-evitam-a-nova-identificacao-de-dois-factores-e-como-proteger-os-seus-utilizadores\/"},"modified":"2023-09-08T09:38:24","modified_gmt":"2023-09-08T07:38:24","slug":"como-atacantes-evitam-a-nova-identificacao-de-dois-factores-e-como-proteger-os-seus-utilizadores","status":"publish","type":"post","link":"https:\/\/mailcommsgroup.com\/pt\/blog\/como-atacantes-evitam-a-nova-identificacao-de-dois-factores-e-como-proteger-os-seus-utilizadores\/","title":{"rendered":"Como os atacantes contornam a nova identifica\u00e7\u00e3o de dois factores e como proteger os seus utilizadores"},"content":{"rendered":"

[vc_row type=”grid” css=”.vc_custom_1547557263471{margin-bottom: 0px !important;padding-bottom: 0px !important;}”][vc_column dp_animation=”” el_class=”El nuevo reglamento europeo obliga a recabar el consentimiento expl\u00edcito para el tratamiento de los datos de car\u00e1cter personal” font_color=”#81d742″][vc_single_image image=”5437″ img_size=”full”][\/vc_column][\/vc_row][vc_row type=”grid” css=”.vc_custom_1555933626160{margin-top: 0px !important;padding-top: 20px !important;}”][vc_column dp_animation=”” css=”.vc_custom_1547557427896{padding-top: 0px !important;}”][vc_column_text dp_animation=””]<\/p>\n

Preparar o ataque<\/strong><\/h2>\n

Para executar o ataque, vamos usar uma combina\u00e7\u00e3o de duas ferramentas, Muraena e Necrobrowser. Muraena \u00e9 um
\n proxy reverso<\/a>
\n<\/em> que ir\u00e1 executar a nossa p\u00e1gina de phishing<\/em>. A p\u00e1gina de phishing<\/em> ser\u00e1 a p\u00e1gina original com a qual a v\u00edtima ir\u00e1 interagir. Depois de a v\u00edtima se autenticar na sess\u00e3o, o Muraena entrega a sess\u00e3o ao Necrobrowser, permitindo que o atacante assuma o controlo da sess\u00e3o ou automatize os passos seguintes do ataque. Como a Muraena actua como um proxy<\/em> reverso, n\u00e3o haver\u00e1 qualquer diferen\u00e7a entre o nosso site malicioso e o site original, para al\u00e9m do URL. A Muraena pode ser configurada para utilizar SSL com certificados obtidos atrav\u00e9s de, por exemplo, LetsEncrypt. Do ponto de vista da v\u00edtima, toda a experi\u00eancia parecer\u00e1 leg\u00edtima, uma vez que simula a intera\u00e7\u00e3o com a p\u00e1gina original. Passar\u00e3o pelo processo de autentica\u00e7\u00e3o normal, incluindo 2FA. Se a 2FA consistir numa palavra-passe de uso \u00fanico (OTP) normal enviada por SMS, token<\/em> de hardware ou software, a v\u00edtima introduzi-la-\u00e1 como habitualmente. No entanto, mesmo os m\u00e9todos modernos, como uma notifica\u00e7\u00e3o autom\u00e1tica para um dispositivo m\u00f3vel ou a leitura de um c\u00f3digo QR no ecr\u00e3, ser\u00e3o ignorados por este ataque.[\/vc_column_text][vc_empty_space height=”20px”][vc_single_image image=”5449″ img_size=”full” alignment=”center” dp_animation=””][vc_empty_space height=”20px”][vc_column_text dp_animation=””]<\/p>\n

    \n
  1. O utilizador visita a p\u00e1gina de phishing<\/em>, que tem o SSL ativado.<\/li>\n
  2. O proxy<\/em> reverso (Muraena) procura a p\u00e1gina banc\u00e1ria leg\u00edtima e entrega uma c\u00f3pia \u00e0 v\u00edtima.<\/li>\n
  3. A v\u00edtima tenta iniciar sess\u00e3o na p\u00e1gina e \u00e9-lhe solicitada a autentica\u00e7\u00e3o de dois factores.<\/li>\n
  4. Depois de a v\u00edtima ter completado o processo de autentica\u00e7\u00e3o, o proxy <\/em>reverso (Muraena) entrega a sess\u00e3o ao atacante (Necrobrowser) para assumir o controlo, cortando o acesso \u00e0 v\u00edtima.<\/li>\n<\/ol>\n

    Na imagem abaixo pode ver-se Muraena a alojar o Google no dom\u00ednio phish.anti. Para efeitos de demonstra\u00e7\u00e3o, ser\u00e1 configurado um DNS local para resolver isto na sua m\u00e1quina de teste e tamb\u00e9m emitir certificados utilizando a sua pr\u00f3pria CA, na qual o browser confia. No entanto, \u00e9 exatamente este o aspeto que teria da perspetiva da v\u00edtima se fosse implementado no seu pr\u00f3prio dom\u00ednio utilizando certificados v\u00e1lidos.[\/vc_column_text][vc_empty_space height=”20px”][vc_single_image image=”5447″ img_size=”full” alignment=”center” dp_animation=””][vc_empty_space height=”20px”][vc_column_text dp_animation=””]<\/p>\n

    Prote\u00e7\u00e3o contra ataques<\/strong><\/h2>\n

    Agora que entendemos como o ataque funciona, podemos identificar quais os passos necess\u00e1rios para identificar ou proteger contra este tipo de ataque.<\/p>\n

    A liga\u00e7\u00e3o din\u00e2mica<\/strong> proporciona uma boa primeira camada de defesa contra uma variedade de ataques. A liga\u00e7\u00e3o din\u00e2mica \u00e9 uma autentica\u00e7\u00e3o de dois factores realizada no momento da transa\u00e7\u00e3o, que incorpora os detalhes da transa\u00e7\u00e3o no processo de assinatura; frequentemente referida como O que se v\u00ea \u00e9 o que se assina<\/em>porque o utilizador final deve receber os detalhes da transa\u00e7\u00e3o antes de concluir o processo de assinatura. Uma vez assinada, a assinatura deve ser v\u00e1lida apenas para esta transa\u00e7\u00e3o espec\u00edfica, tornando mais dif\u00edcil ao atacante contorn\u00e1-la. Normalmente, a liga\u00e7\u00e3o din\u00e2mica \u00e9 implementada atrav\u00e9s de tokens<\/em> de hardware, tokens<\/em> de software ou integrada como parte de uma aplica\u00e7\u00e3o banc\u00e1ria. Aqui est\u00e3o dois exemplos de liga\u00e7\u00f5es din\u00e2micas, o primeiro para um pagamento leg\u00edtimo e o segundo quando um atacante tenta modificar o pagamento.[\/vc_column_text][vc_empty_space height=”20px”][vc_single_image image=”5445″ img_size=”full” alignment=”center” dp_animation=””][vc_empty_space height=”20px”][vc_column_text dp_animation=””]<\/p>\n

      \n
    1. O utilizador cria uma transa\u00e7\u00e3o no banco online.<\/li>\n
    2. O utilizador submete a transa\u00e7\u00e3o.<\/li>\n
    3. O banco envia os detalhes da transa\u00e7\u00e3o para o telem\u00f3vel do utilizador.<\/li>\n
    4. O utilizador verifica os dados da transfer\u00eancia e autoriza o pagamento com dados biom\u00e9tricos (ou outro segundo fator).<\/li>\n
    5. A aplica\u00e7\u00e3o m\u00f3vel gera uma palavra-passe de uso \u00fanico (OTP) utilizando os dados da transa\u00e7\u00e3o e a chave do token<\/em> na aplica\u00e7\u00e3o m\u00f3vel.<\/li>\n<\/ol>\n

      [\/vc_column_text][vc_empty_space height=”20px”][vc_single_image image=”5443″ img_size=”full” alignment=”center” dp_animation=””][vc_empty_space height=”20px”][vc_column_text dp_animation=””]<\/p>\n

        \n
      1. O utilizador tenta efetuar um pagamento na banca online.<\/li>\n
      2. O atacante modifica o pagamento para ter uma nova conta e\/ou montante de dinheiro.<\/li>\n
      3. O banco envia os detalhes da transa\u00e7\u00e3o para o telem\u00f3vel do utilizador.<\/li>\n
      4. O utilizador recebe a informa\u00e7\u00e3o de pagamento modificada e rejeita o pagamento.<\/li>\n<\/ol>\n

        Os exemplos acima ilustram tamb\u00e9m a import\u00e2ncia de utilizar a encripta\u00e7\u00e3o de extremo a extremo ao implementar a liga\u00e7\u00e3o din\u00e2mica. Al\u00e9m disso, mostra que a pr\u00f3pria aplica\u00e7\u00e3o m\u00f3vel deve ser protegida, uma vez que o atacante pode tentar atacar a aplica\u00e7\u00e3o para ocultar os dados de pagamento modificados do utilizador.<\/p>\n

        Outra forma eficaz de reconhecer e defender-se contra uma grande variedade de ataques \u00e9 implementar uma monitoriza\u00e7\u00e3o cont\u00ednua<\/strong> nas suas plataformas digitais. Ao monitorizar a sess\u00e3o desde o momento do in\u00edcio de sess\u00e3o at\u00e9 ao fim da mesma, podemos contextualizar melhor as ac\u00e7\u00f5es dos utilizadores e os dispositivos ou contas a que est\u00e3o associados. A monitoriza\u00e7\u00e3o cont\u00ednua combina perfeitamente com outras camadas, como a 2FA ou as liga\u00e7\u00f5es din\u00e2micas, uma vez que tamb\u00e9m permitem que o banco se contextualize a partir destes dispositivos de autentica\u00e7\u00e3o.[\/vc_column_text][vc_empty_space height=”20px”][vc_single_image image=”5441″ img_size=”full” alignment=”center” dp_animation=””][vc_empty_space height=”20px”][vc_column_text dp_animation=””]O banco pode ent\u00e3o monitorizar indicadores t\u00edpicos de ataques conhecidos, tais como novos dispositivos, localiza\u00e7\u00f5es, presen\u00e7a de proxy <\/em>ou outros. Esta informa\u00e7\u00e3o pode ser correlacionada com a sua base de utilizadores para compreender melhor o risco destes elementos. Podemos tamb\u00e9m ter em conta as opera\u00e7\u00f5es que o utilizador efectua durante toda a sess\u00e3o e compar\u00e1-las com o seu comportamento habitual. Esta abordagem estabelece um perfil de risco cont\u00ednuo para a sess\u00e3o que pode mudar com cada a\u00e7\u00e3o tomada pelo utilizador final. Isto n\u00e3o s\u00f3 permite que o banco tome medidas automatizadas em tempo real quando s\u00e3o detectadas anomalias, como tamb\u00e9m permite que o banco reduza o atrito das sess\u00f5es leg\u00edtimas, reduzindo o n\u00famero de autentica\u00e7\u00f5es necess\u00e1rias para sess\u00f5es reais.<\/p>\n

        Conclus\u00e3o<\/strong><\/h2>\n

        Embora o ataque neste artigo fale de tecnologia e conceitos que existem h\u00e1 s\u00e9culos, vemos que a sua aplica\u00e7\u00e3o correcta ainda pode conduzir a um grande sucesso e lutar contra v\u00e1rios m\u00e9todos de autentica\u00e7\u00e3o implementados atualmente. \u00c9 importante que os bancos utilizem uma abordagem por camadas, uma vez que a maioria das camadas individuais pode ser atacada ou dinamizada. Ao implementar liga\u00e7\u00f5es din\u00e2micas, os bancos devem garantir que estabelecem uma linha de comunica\u00e7\u00e3o segura com o utilizador final. Por exemplo, confiar nos SMS j\u00e1 n\u00e3o \u00e9 fi\u00e1vel, uma vez que as mensagens podem ser roubadas, falsificadas ou interceptadas pelo atacante. No entanto, ao implementar aplica\u00e7\u00f5es m\u00f3veis, os bancos devem tamb\u00e9m estar conscientes de que estas aplica\u00e7\u00f5es se tornam um alvo e devem proteger as suas aplica\u00e7\u00f5es m\u00f3veis de ataques externos. O objetivo deste artigo \u00e9 principalmente demonstrar que os ataques de phishing<\/em> podem ser modernizados para derrotar a autentica\u00e7\u00e3o de dois factores no in\u00edcio de sess\u00e3o e que a implementa\u00e7\u00e3o da 2FA por si s\u00f3 n\u00e3o oferece uma prote\u00e7\u00e3o completa contra o phishing<\/em>. Por \u00faltimo, mencion\u00e1mos algumas camadas que os bancos podem implementar para proporcionar uma maior prote\u00e7\u00e3o aos seus utilizadores finais, bem como as armadilhas a evitar ao faz\u00ea-lo. Em suma:<\/p>\n