Atak homograficzny polega na zarejestrowaniu domeny zbudowanej ze znaków, które wyglądają identycznie jak te w prawdziwej domenie, lecz nimi nie są - na przykład cyrylicka litera "a" w miejscu łacińskiej litery "a" - więc adres, który czyta człowiek, i adres, który rozwiązuje przeglądarka, to dwie różne rzeczy. Sztuczka działa, ponieważ system nazw domen rozumie tylko ASCII, więc każda domena spoza ASCII zostaje przetłumaczona na formę ASCII zwaną punycode, oznaczoną przedrostkiem xn--, zanim w ogóle dotknie DNS. Przeglądarki dekodują to z powrotem do czytelnej wersji na potrzeby wyświetlania, i właśnie w tym kroku dekodowania kryje się oszustwo.
Nowoczesne przeglądarki wyłapują dziś oczywiste przypadki i pokazują surowy punycode, gdy etykieta miesza alfabety w podejrzany sposób, zamykając drogę większości łatwych ataków, które działały dekadę temu. Ale ta ochrona nie wychodzi poza pasek adresu przeglądarki.
Na co dzień analizuję przypadki podszywania się pod marki i dobre podróbki wciąż na pół sekundy przyciągają mój wzrok, zanim zarejestruję, że coś jest nie tak. Ten wpis pokazuje, jak działa atak homograficzny, gdzie kończy się obrona przeglądarki i co z tym zrobić - niezależnie od tego, czy zaraz masz kliknąć link, czy jesteś właścicielem domeny, pod którą ktoś się podszywa. Szersze pytanie o to, czy same krótkie linki są godne zaufania, omawia wpis czy skracacze URL są bezpieczne; ten wpis dotyczy domeny leżącej pod spodem linku.
Czym jest punycode i po co powstał
DNS został zbudowany dla ASCII i kropka. Nie ma natywnego sposobu przechowywania liter z akcentami, cyrylicy, arabskich czy chińskich znaków, z których składa się większość systemów pisma na świecie, co stało się realnym problemem w chwili, gdy rejestracja domen otworzyła się poza rynkami anglojęzycznymi.
Punycode jest rozwiązaniem: odwracalnym kodowaniem, znormalizowanym jako RFC 3492, które zamienia etykietę Unicode na litery, cyfry i myślniki ASCII, jakie DNS może przenieść bez żadnej zmiany protokołu transmisji. Niemiecka piekarnia rejestrująca domenę z umlautem albo ukraiński sklep rejestrujący domenę cyrylicą otrzymuje działającą umiędzynarodowioną nazwę domeny, która rozwiązuje się dokładnie tak jak każda inna, bo pod spodem to po prostu kolejna etykieta ASCII. Zakodowana forma zawsze zaczyna się od xn--, sygnalizując: "to jest punycode, zdekoduj to, zanim pokażesz człowiekowi".
Nic z tego nie jest samo w sobie luką bezpieczeństwa - umiędzynarodowione nazwy domen to prawdziwa, niezbędna funkcja, a nie obejście, które ktokolwiek powinien wyłączać. Kłopoty zaczynają się warstwę wyżej, w momencie gdy przeglądarka decyduje, jak wyświetlić Ci z powrotem tę zdekodowaną nazwę.
Jak działa atak homograficzny
Atak homograficzny wykorzystuje lukę między tym, co domena faktycznie zawiera, a tym, jak wygląda po wyrenderowaniu. W praktyce spotyka się dwa warianty i nie są one równie powszechne.
Wariant obejmujący cały alfabet rejestruje całą domenę w nie-łacińskim alfabecie, którego kształty liter przypadkiem przypominają markę będącą celem. Jest rzucający się w oczy w budowie i łatwiejszy do wyłapania przez obrońców, bo cała etykieta jest obca.
Wariant mieszający alfabety to ten, który faktycznie jest używany, bo wymaga tylko jednej podmiany. Weźmy domenę taką jak novacloud.com. Zamień łacińskie "o" na wizualnie identyczne cyrylickie "о" (U+043E) i otrzymasz nоvacloud.com - ten sam kształt, ta sama długość, inny punkt kodowy, i domenę, która koduje się do xn--nvacloud-nbh.com. Reszta etykiety pozostaje nietknięta, więc oko prawie nie ma czego wychwycić. Badacze bezpieczeństwa nazywają tego rodzaju parę znaków łudząco podobnych "confusable", a garstka takich par pokrywa większość alfabetu łacińskiego.
Gdy domena jest już zarejestrowana, reszta ataku to zwykły phishing: strona logowania skopiowana piksel w piksel, pilna wiadomość wskazująca na sfałszowany link i cel, który nie ma powodu wątpić w adres wyglądający dokładnie tak, jak powinien.
Co dziś robią z tym przeglądarki
Producenci przeglądarek zamknęli większość łatwej wersji tego ataku lata temu za pomocą reguły określającej, które alfabety wolno mieszać w jednej etykiecie. Polityka Chrome, opisana w jego przewodniku po obsłudze IDN, sprawdza, czy każdy znak w etykiecie prawdopodobnie należy do jednego alfabetu albo do niewielkiego zestawu kombinacji alfabetów, które prawowicie występują razem, jak japońskie kanji z hiraganą. Zmieszaj alfabety spoza tego dozwolonego zestawu, a przeglądarka pokaże surową formę xn-- zamiast ją dekodować - najlepszy atut ataku, domena wyglądająca zupełnie normalnie, zamienia się z powrotem w oczywiście zakodowany ciąg znaków. Firefox wykonuje porównywalną kontrolę, opisaną w algorytmie wyświetlania IDN Mozilli, a Safari stosuje własną wersję.
To nie jest pełna ochrona. Etykieta mieszająca alfabety, zbudowana wyłącznie ze znaków należących do jednej dozwolonej kombinacji, wciąż może przemknąć jako czytelna, zwodnicza nazwa, a reguła jest egzekwowana przez każdą przeglądarkę z osobna, bez żadnego wspólnego autorytetu decydującego, co uchodzi za bezpieczne.
Gdzie ta ochrona się kończy
Kontrola mieszania alfabetów mieszka w kodzie renderującym pasek adresu przeglądarki. Nie podróżuje wraz z adresem URL nigdzie indziej, i właśnie w tej luce sfałszowana domena wciąż wyrządza realną szkodę.
Klienty pocztowe są największym obszarem ekspozycji: wiadomość może wyświetlić dowolny tekst kotwicy nad linkiem niezależnie od celu, a większość aplikacji pocztowych w ogóle nie sprawdza znaków mylących. Aplikacje czatowe rozwijają udostępniony link w kartę podglądu zbudowaną z metadanych strony, a nie renderer świadomy punycode. Kody QR całkowicie usuwają etap tekstu - lukę, którą omawiamy we wpisie czy kody QR są bezpieczne - a materiały drukowane nie mają żadnej warstwy oprogramowania między okiem a oszustwem.
| Kanał | Pokazuje prawdziwy cel, zanim podejmiesz działanie | Typowa ekspozycja |
|---|---|---|
| Nowoczesna przeglądarka desktopowa | Zwykle, dzięki regułom mieszania alfabetów | Niska dla popularnych przeglądarek, na bieżąco |
| Klient poczty | Rzadko - tekst kotwicy może mówić cokolwiek | Wysoka, zwłaszcza w mobilnych aplikacjach poczty |
| Aplikacje czatowe i komunikatory | Rzadko - podglądy linków korzystają z metadanych | Wysoka, rozwinięcia linków wyglądają identycznie |
| Kod QR | Nie - nic się nie renderuje przed skanem | Wysoka, decyzja zapada w ułamku sekundy |
| Materiały drukowane | Nigdy - żadne oprogramowanie nie bierze udziału | Najwyższa, kontrola techniczna jest niemożliwa |
Jeśli Twój zespół wysyła linki pod domeną, którą klienci już rozpoznają, sfałszowana podróbka ma znacznie mniej miejsca, żeby przekonująco Cię naśladować we wszystkich tych kanałach naraz. Zobacz, jak działa własna domena marki w Elido, jeśli wciąż wysyłasz linki ze współdzielonej albo ogólnej domeny.
Dlaczego własna domena marki to Twoja najlepsza obrona
Atak homograficzny działa dzięki wykorzystaniu rozpoznawalności - potrzebuje rozpoznawalnej marki, którą może podrobić. Brzmi to jak argument przeciwko budowaniu własnej, rozpoznawalnej domeny, a jest dokładnie odwrotnie. Charakterystyczny markowy krótki link, który Twoi odbiorcy już z Tobą kojarzą, to coś, z czym mogą porównać podejrzaną wiadomość; ogólna albo pożyczona domena skracacza daje atakującemu szablon, którego klienci i tak nie odróżnią od prawdziwego dostawcy, bo żadna z nich nie wygląda jak "Ty".
Skonfigurowanie własnej domeny dla krótkich linków oznacza, że każdy wysyłany link nosi nazwę, którą odbiorcy rozpoznają, co podnosi poprzeczkę każdemu, kto próbuje go podrobić. Warto to odróżnić od maskowania linków i ukrywania adresów URL - świadomej, jawnie ujawnionej decyzji o przekierowywaniu linków przez własną domenę. Atak homograficzny to ruch odwrotny - ukrywanie tożsamości atakującego przy jednoczesnym naśladowaniu Twojej - a obroną jest przejrzystość co do tego, która domena naprawdę jest Twoja.
Kontrole u rejestratora, które naprawdę mają znaczenie
Gdy jesteś już właścicielem domeny wartej ochrony, większość realnej pracy wykonują dwie kontrole, działające na różnych poziomach stosu.
Registrar lock to ta codzienna - flaga statusu, często pokazywana jako clientTransferProhibited, która blokuje rutynowe, automatyczne żądania transferu wewnątrz panelu Twojego rejestratora. Każda aktywnie używana domena powinna mieć ją włączoną; nic to nie kosztuje. Registry lock znajduje się poziom wyżej, angażując bezpośrednio operatora rejestru, więc każda zmiana, transfer albo usunięcie wymaga ręcznej weryfikacji poza standardowym kanałem - rozmowy telefonicznej albo bezpiecznego hasła - zanim zacznie obowiązywać. To tarcie należy się jednej lub dwóm domenom, na których nieautoryzowana zmiana byłaby naprawdę kosztowna, co dla większości firm oznacza co najmniej główną domenę marki.
Żadna z tych blokad nie powstrzyma nikogo przed zarejestrowaniem domeny łudząco podobnej obok Twojej. To wymaga aktywnego monitorowania: obserwowania nowych rejestracji domen i publicznych dzienników przejrzystości certyfikatów pod kątem nazw wizualnie bliskich Twojej marce, żebyś mógł zgłosić to rejestratorowi albo ostrzec klientów, zanim kampania z jej użyciem do kogokolwiek dotrze.
Co umieścić w polityce ochrony marki
Jeśli jesteś właścicielem domeny wartej podrobienia, sekcja bezpieczeństwa Twojej polityki ochrony marki powinna być na tyle konkretna, żeby osoba nowa w zespole mogła ją wykonać bez pytania Cię wcześniej o zdanie.
- Registrar transfer lock na każdej domenie należącej do firmy, z registry lock dodanym na głównej domenie marki i na wszystkim, co obsługuje płatności albo logowania.
- Cykliczne skanowanie nowych rejestracji domen i dzienników przejrzystości certyfikatów pod kątem nazw wizualnie bliskich Twojej marce, a nie jednorazowa kontrola.
- Defensywna rejestracja etykiet łudząco podobnych o najwyższym ryzyku oraz mylących domen najwyższego poziomu, jakie potrafisz uzasadnić, uszeregowanych według tego, jak bardzo są zbliżone do Twojej głównej domeny.
- Wyznaczony właściciel i ścieżka eskalacji do zgłaszania wykrytej domeny łudząco podobnej jej rejestratorowi, a także wewnętrzne wytyczne, żeby pracownicy wsparcia rozpoznawali ten wzorzec, gdy zgłosi go klient. Lista kontrolna bezpieczeństwa przy wyborze dostawcy linków opisuje pokrewne kontrole dostawców.
Przepis na weryfikację, który każdy może zastosować
Nie musisz rozumieć punycode, żeby bezpiecznie sprawdzić link. Cztery kroki, wykonane po kolei, wyłapują niemal wszystko, na czym opiera się atak homograficzny.
- Najpierw rozwiń link, zamiast klikać go bezpośrednio. Jak sprawdzić, dokąd prowadzi krótki URL omawia narzędzia do tego, a własny link checker Elido robi to samo, nie każąc Ci najpierw zaufać celowi.
- Odczytaj domenę rejestrowalną - część znajdującą się bezpośrednio przed domeną najwyższego poziomu - a nie cokolwiek, co pojawia się przed nią. To jest część, którą atakujący musi kontrolować w całości.
- Sprawdź, czy nie ma przedrostka xn--, czy to w surowym rozwiniętym adresie URL, czy w pasku adresu przeglądarki. Jeśli widzisz go tam, gdzie spodziewałeś się zwykłej nazwy marki, zatrzymaj się i traktuj to jako domenę łudząco podobną, dopóki nie udowodnisz inaczej.
- Potwierdź nazwę w certyfikacie witryny docelowej. Certyfikat odzwierciedla to, co faktycznie zostało wydane właścicielowi domeny, co jest trudniejsze do przekonującego podrobienia niż wyrenderowana etykieta.
Żaden z tych kroków nie zajmuje więcej niż kilka sekund, gdy stanie się nawykiem, a wszystkich czterech możesz nauczyć nietechnicznego współpracownika w czasie potrzebnym na jednorazowe przeczytanie tej sekcji.
Atak homograficzny to problem z wyświetlaniem przebrany za problem bezpieczeństwa. Punycode robi dokładnie to, do czego został zaprojektowany; oszustwo dzieje się w luce między tym, czym domena naprawdę jest, a tym, co zamiast tego pokazuje Ci oprogramowanie. Przeglądarki zamknęły większość tej luki w pasku adresu. Wszędzie indziej luka wciąż jest otwarta, dlatego rozwijanie linku i odczytywanie domeny rejestrowalnej pozostaje nawykiem, który działa niezależnie od tego, jaki kanał postawił link przed Tobą.
Powiązane na blogu
Najczęściej zadawane pytania
Czym jest atak homograficzny IDN?
Atak homograficzny IDN polega na zarejestrowaniu domeny przy użyciu znaków z innego alfabetu, które wyglądają identycznie lub niemal identycznie jak te w prawdziwej domenie, więc czytelnik nie jest w stanie odróżnić ich wzrokowo. Klasyczny przypadek zamienia pojedynczą literę łacińską na cyrylicki lub grecki odpowiednik wyglądający tak samo, na przykład cyrylicką literę a na łacińską literę a, podczas gdy reszta domeny pozostaje bez zmian. Ponieważ znak zastępczy ma inny, leżący u podstaw punkt kodowy, obie domeny są technicznie odrębne i mogą być zarejestrowane oraz kontrolowane przez różnych właścicieli. Atak działa wyłącznie dzięki wyglądowi, dlatego celem stają się rozpoznawalne, zaufane nazwy marek, a nie te mało znane.
Czym jest punycode i po co powstał?
Punycode to kodowanie, które zamienia etykiety domen spoza ASCII na ciąg ASCII, jaki system nazw domen potrafi przechować i rozwiązać, zdefiniowane w RFC 3492. Istnieje, ponieważ DNS rozumie tylko ograniczony zestaw znaków ASCII, więc domena zapisana cyrylicą, po arabsku, po chińsku albo z akcentowanymi literami łacińskimi musi zostać przetłumaczona na tę postać, zanim będzie można ją wyszukać. Zakodowana etykieta zawsze zaczyna się od przedrostka xn--, który informuje resolwery i przeglądarki, że to, co następuje dalej, jest ciągiem zakodowanym w punycode, a nie zwykłą nazwą ASCII. Przeglądarki dekodują ją z powrotem do oryginalnego alfabetu na potrzeby wyświetlania, co jest funkcją prawowitą i niezbędną, a nie samą w sobie luką bezpieczeństwa.
Co oznacza przedrostek xn-- w adresie URL?
Przedrostek xn-- oznacza, że etykieta domeny jest zakodowana w formacie ASCII Compatible Encoding, wytworzonym przez punycode, co sygnalizuje, że czytelna nazwa została przetłumaczona ze znaków spoza ASCII. Wszystko po przedrostku to zakodowana forma oryginalnej etykiety - xn--nvacloud-nbh.com, na przykład, dekoduje się do domeny wyglądającej jak novacloud.com z jedną literą zamienioną na łudząco podobny odpowiednik. Zobaczenie formy xn-- tam, gdzie spodziewałeś się zwykłej nazwy marki, to dokładnie ten sygnał, którym przeglądarki Cię ostrzegają, bo oznacza on, że etykieta mieszała alfabety w sposób, który przeglądarka uznała za niebezpieczny do wyrenderowania w ładnej postaci. Domena bez żadnych znaków spoza ASCII nigdy nie wytwarza formy xn--, więc jej pojawienie się zawsze warto sprawdzić dwa razy.
Czy przeglądarki chronią przed atakami homograficznymi?
Nowoczesne przeglądarki stosują reguły dotyczące mieszania alfabetów, które wyłapują większość prób ataku homograficznego i w takim przypadku pokazują surową formę punycode zamiast zwodniczej. Zarówno Chrome, jak i Firefox sprawdzają, czy znaki etykiety domeny prawdopodobnie należą do jednego alfabetu albo do niewielkiego zestawu alfabetów zwyczajowo używanych razem, a jeśli nie, wyświetlają wersję xn--, zamiast dekodować ją do czegoś, co mogłoby uchodzić za znajomą nazwę. To zamyka drogę najłatwiejszym atakom opartym na całym obcym alfabecie, choć atakujący wciąż mogą znaleźć znaki w dozwolonych zestawach, które są wzrokowo mylące z literami łacińskimi. Ta ochrona jest też ściśle ograniczona do paska adresu przeglądarki - żaden inny element stosu nie dziedziczy jej automatycznie.
Jak rozpoznać domenę łudząco podobną, zanim klikniesz link?
Najpierw rozwiń link, żeby zobaczyć pełny cel, a nie jego skróconą albo obciętą wersję, a potem odczytaj domenę rejestrowalną, a nie cokolwiek, co znajduje się przed nią. Jeśli pasek adresu albo narzędzie do rozwijania linków pokazuje przedrostek xn-- tam, gdzie spodziewałeś się zwykłej nazwy marki, traktuj to jako domenę łudząco podobną, dopóki nie udowodnisz inaczej. Sprawdzenie nazwy w certyfikacie witryny docelowej to przydatna ostatnia kontrola, ponieważ certyfikat odzwierciedla to, co faktycznie zostało wydane, a nie to, co jedynie się wyświetla. Nic z tego nie wymaga specjalnego oprogramowania - wystarczy nawyk robienia tego, zanim wpiszesz hasło albo numer karty.
Czym jest registry lock i czy Twoja domena tego potrzebuje?
Registry lock to zabezpieczenie ustawione na poziomie rejestru domeny, które blokuje każdą zmianę, transfer lub usunięcie domeny, dopóki nie zostanie to ręcznie zweryfikowane poza standardowym kanałem - zwykle telefonicznie albo za pomocą bezpiecznego hasła - co powstrzymuje nawet przejęte konto rejestratora przed przeniesieniem domeny. To silniejsza gwarancja niż bardziej powszechny registrar lock, który tylko zapobiega rutynowym, automatycznym transferom wewnątrz panelu Twojego rejestratora. Registry lock jest wart swojego niewielkiego rocznego kosztu dla każdej domeny, której przestój albo przejęcie byłyby kosztowne, co dla większości firm oznacza co najmniej główną domenę marki. Nie powstrzyma to nikogo przed zarejestrowaniem podobnie wyglądającej domeny obok Twojej - to osobny problem, który rozwiązuje monitorowanie, a nie blokada.
Wypróbuj Elido
Wklej URL, otrzymaj krótki link
Bez rejestracji. Link działa 30 dni. Zarejestruj się, aby zachować go na zawsze.
Za darmo, bez rejestracji · 2 dziennie