Um dos problemas dos ataques de phishing é que nos redireccionam para sites falsos em que bastará prestar atenção ao próprio URL para se ver que algo de estranho se passa. Mas, e se na barra de endereços virmos algo perfeitamente legítimo, como um endereço apple.com - e ainda por cima utilizando HTTPS? O problema é que vários browsers, incluindo o Chrome, Firefox e Opera, podem ser manipulados para apresentar um url aparentemente legítimo, quando na realidade se está a aceder a um site fraudulento.
O problema tem a ver com a forma como os browsers apresentam URLs com caracteres Unicode, que permitem a existência de sites com URLs em caracteres chineses, cirílicos, árabes, japoneses, etc. Pelo meio desses milhares de caracteres existem muitos que são réplicas fiéis dos caracteres ASCII e que desde logo abriram as portas à existência de URLs fraudulentos. Por exemplo, um atacante poderia registar um site "apple.com" onde o "a" fosse um caracter Unicode parecido com o "a" real.
Para reduzir esse risco, os browsers optaram por mostrar o URL no seu estado original codificado no formato punycode de modo a demonstrar que se trata de um URL com caracteres Unicode. Mas, para efeitos de legibilidade, browsers como o Chrome optaram por mostrar o endereço nos caracteres Unicode finais sempre que o URL não misturasse caracteres Unicode com caracteres ASCII; o que agora vem demonstrar ser problemático, pois é possível criar URLs aparentemente legítimos usando apenas caracteres Unicode.
Por exemplo, o endereço https://www.xn--80ak6aa92e.com irá levar os utilizadores até uma página que será apresentada como sendo apple.com no Chrome, Firefox e Opera. No Safari, Edge, Internet Explorer e outros, o endereço será apresentado no seu formato em punycode, o que revela logo que não se está no site apple.com.
No Firefox é possível evitar isto indo ao about:confir e mudando o parâmetro network.IDN_show_punycode para "true"; no Chrome não existe solução imediata, mas a Google já terá implementado uma correcção que chegará aos utilizadores nos próximos dias. (Actualização: já foi corrigido com o Chrome 58).
... Por via das dúvidas, nada como escreverem vocês mesmo, manualmente, o endereço que querem vistar - especialmente nos casos em que algum página vos pedir dados de login ou de reposição de passwords!
OMG! que grave D:
ResponderEliminarPodiam fazer o mesmo com a Google, mas isso era ofensa à santíssima…
ResponderEliminarBTW, o Safari não está afecto, porque corrigiu o erro há 12 anos atrás:
https://lists.apple.com/archives/security-announce/2005/Mar/msg00000.html
CVE-ID: CAN-2005-0234
O IE também aparentemente... mas não que isso resolva o problema para mais de 50% do mercado, que utiliza o Chrome.
EliminarFelizmente o processo de actualização do Chrome funciona bem melhor que a do Android.
http://appleinsider.com/articles/17/04/17/google-to-patch-chrome-phishing-vulnerability-already-solved-in-safari-edge
ResponderEliminarHá 10 atrás, meti o myspace.com à venda no eBay e a coisa tornou-se viral. Foi divertido. https://techcrunch.com/2006/10/19/domain-name-%D0%BC%D1%83%D1%95%D1%80%D0%B0%D1%81%D0%B5com-for-sale-affordable/
ResponderEliminarusem o yandex
ResponderEliminarIsto é realmente algo muito chato. Ainda há 2 dias me apareceu um email destes a pedir para fazer alterações no appleid, e logo a mim que não uso apple :P Mas de facto era daqueles emails dos quais tinha 100% de certeza que eram de phishing, mas não estava a conseguir detetar onde estava a aldrabice.
ResponderEliminarAgora, isto só mesmo informáticos é que topam porque de resto é tudo apanhado na marosca.
Impressionante como estão sempre a aparecer falhas críticas deste género. Impressionante mesmo.
Vai ser "patchado" no chrome: https://goo.gl/xisqLh
ResponderEliminar