IDN

IDN to standard umożliwiający wykorzystanie znaków spoza alfabetu łacińskiego w nazwach domenowych.

Architektura i mechanika działania domen wielojęzycznych

System DNS (Domain Name System) został zaprojektowany w latach osiemdziesiątych dwudziestego wieku z rygorystycznym ograniczeniem dopuszczalnego zestawu znaków. Standard zdefiniowany w dokumencie RFC 1035 dopuszczał w nazwach domen wyłącznie litery alfabetu łacińskiego bez znaków diakrytycznych, cyfry oraz myślnik, przy czym myślnik nie mógł znajdować się na początku ani na końcu etykiety. Zestaw ten, znany jako LDH (Letter-Digit-Hyphen), oparty na 7-bitowym kodowaniu ASCII, okazał się niewystarczający w obliczu globalizacji sieci i potrzeby rejestracji nazw w lokalnych językach, wykorzystujących znaki z zestawu Unicode, takich jak znaki cyrylicy, znaki chińskie czy polskie litery diakrytyczne.

Zamiast przebudowywać całą światową infrastrukturę serwerów DNS, co byłoby procesem powolnym i generującym błędy routingu, organizacja IETF (Internet Engineering Task Force) przyjęła w standardzie IDNA (Internationalizing Domain Names in Applications) architekturę opartą na warstwie aplikacji. Oznacza to, że same serwery DNS pozostają nieświadome istnienia znaków Unicode i nadal operują na czystym ASCII. Ciężar konwersji spoczywa w całości na oprogramowaniu klienckim, takim jak przeglądarki internetowe, klienty poczty elektronicznej czy biblioteki systemowe służące do rozwiązywania nazw. Mechanizm ten jest przezroczysty dla infrastruktury sieciowej analizującej pakiety.

Wdrożenie IDN wymagało stworzenia stałego systemu mapowania, normalizacji i konwersji. Aplikacja kliencka, otrzymując adres zawierający znaki spoza puli ASCII, musi najpierw poddać go procesowi Nameprep (w starszej wersji IDNA2003) lub nowszym regułom przetwarzania zdefiniowanym dla IDNA2008. Proces ten obejmuje między innymi operację rzutowania znaków na małe litery oraz eliminację znaków niedozwolonych lub niejednoznacznych wizualnie w specyficznym kontekście znakowym. Dopiero po takiej normalizacji ciąg jest poddawany właściwej transformacji do formatu zgodnego z wymogami protokołu DNS, zwanego formatem ACE (ASCII-Compatible Encoding).

Zastosowanie rozwiązania aplikacyjnego sprawia, że aktualizacje standardu IDNA nie wymuszają modyfikacji kodu źródłowego serwerów BIND czy unbound. Zmiany zachodzą na poziomie implementacji bibliotek takich jak libidn. Przejście ze standardu IDNA2003 do IDNA2008 przyniosło zaostrzenie reguł dotyczących dozwolonych znaków, usuwając mechanizmy mapowania, które mogły prowadzić do błędnej interpretacji adresów, na przykład w przypadku niemieckiego znaku eszett, co wiązało się z koniecznością przebudowy parserów w aplikacjach klienckich.

Proces konwersji znaków i struktura algorytmu Punycode

Głównym mechanizmem konwersji w standardzie IDN jest Punycode, specyficzny algorytm kodowania opisany w dokumencie RFC 3492. Umożliwia on jednoznaczne przekształcenie dowolnego ciągu znaków Unicode na ciąg znaków należących wyłącznie do zestawu LDH. Punycode reprezentuje typ kodowania o zmiennej długości (generalized variable-length integer), zaprojektowany w ten sposób, aby wynikowy ciąg był możliwie najkrótszy i zawsze mieścił się w sprzętowym i protokołowym limicie 63 bajtów przypisanych pojedynczej etykiecie domeny w architekturze DNS.

Działanie algorytmu rozpoczyna się od wyodrębnienia z wejściowego ciągu wszystkich znaków należących do podstawowego zestawu ASCII. Znaki te są kopiowane do ciągu wynikowego bez modyfikacji. W kolejnym kroku, jeżeli w przetwarzanym tekście znajdowały się jakiekolwiek znaki ASCII, algorytm wstawia znak separatora, w tej roli występuje myślnik. Następnie przeprowadzane jest kodowanie znaków Unicode. Punycode wykorzystuje mechanizm maszyny stanów, iterując przez wartości punktów kodowych obecnych w etykiecie i generując na ich podstawie ciąg reprezentujący dokładne pozycje znaków diakrytycznych oraz ich wartości liczbowe z wykorzystaniem liter od 'a' do 'z' oraz cyfr.

W celu umożliwienia serwerom DNS i programom odróżnienia standardowej domeny ASCII od domeny będącej faktycznym adresem IDN w kodowaniu ACE, wprowadzono stały identyfikator. Każda przekonwertowana etykieta otrzymuje na początku prefiks "xn--". Kiedy parser adresów w przeglądarce napotyka ciąg znaków z tym prefiksem, uruchamia operację ToUnicode, dekodując resztę ciągu według zasad Punycode, aby poprawnie wyrenderować nazwę w interfejsie użytkownika. Podczas wysyłania zapytania w drugą stronę, aplikacja wywołuje funkcję ToASCII, generując strukturę gotową do transmisji w protokole UDP na porcie 53.

Standard nakłada ścisłe restrykcje na formatowanie domen w językach zapisywanych od prawej do lewej (RTL), na przykład w języku arabskim. Wymagane jest stosowanie reguł Bidi (Bidirectional), definiujących położenie znaków kontrolnych, co zapobiega błędom w renderowaniu adresu na ekranie. Algorytm kodowania ma również bezpośrednie przełożenie na certyfikaty SSL/TLS. W plikach konfiguracyjnych serwerów wirtualnych oraz w polach Subject Alternative Name (SAN) samego certyfikatu x509 wymagane jest deklarowanie domeny w surowej formie Punycode z prefiksem, ponieważ protokoły kryptograficzne nie przeprowadzają transformacji znaków na etapie negocjacji sesji.

Zagrożenia bezpieczeństwa i błędy w interpretacji kodowania

Podstawowym problemem w obszarze cyberbezpieczeństwa powiązanym z obsługą IDN są ataki homograficzne. Dopuszczenie użycia znaków z całej przestrzeni Unicode spowodowało, że znaki z różnych alfabetów posiadają identyczny wygląd (glif) w powszechnie stosowanych krojach pisma na monitorach komputerów. Przykładem jest łacińska mała litera "a" (U+0061) oraz cyrylicka mała litera "a" (U+0430). Z perspektywy procesora i resolvera DNS stanowią one dwa oddzielne znaki dające inne wartości Punycode, lecz dla oka użytkownika są niemożliwe do odróżnienia. Cyberprzestępcy rejestrują domeny wizualnie równe adresom docelowym, na przykład bankom, zmieniając w nich pojedyncze litery na odpowiedniki z innych języków, co ułatwia kradzież danych uwierzytelniających.

Twórcy nowoczesnych przeglądarek zaimplementowali heurystyczne algorytmy analityczne w celu redukcji tego wektora ataku. Polegają one na matematycznej analizie punktów kodowych w danej etykiecie i weryfikacji, czy nie łączą one znaków pochodzących z niekompatybilnych skryptów w obrębie jednego słowa. Jeśli przeglądarka wykryje anomalię sugerującą manipulację wizualną, blokuje operację ToUnicode dla paska adresu i wyświetla użytkownikowi czysty ciąg ACE ("xn--"). Dodatkowo główne rejestry domenowe (TLD) wdrażają tabele IDN, w których precyzują zbiory znaków dozwolone przy rejestracji nowej domeny w danej strefie.

Błędy wynikające ze standardu ujawniają się często podczas korzystania ze starszych wersji klientów poczty elektronicznej. Pełna zgodność komunikacji e-mail przy użyciu adresów ze znakami narodowymi wymaga wsparcia dla protokołu EAI (Email Address Internationalization) oraz rozszerzenia SMTPUTF8 na serwerach pośredniczących (MTA). Kiedy serwer docelowy nie deklaruje obsługi tego parametru w odpowiedzi EHLO, wiadomość zostaje odrzucona. Kopiowanie takich adresów URL z okien dialogowych programów nieobsługujących poprawnie schowka systemowego skutkuje wklejeniem ciągu rozpoczynającego się od "xn--", co obniża czytelność tekstu.

Ograniczenia napotykane są również na styku z automatycznymi systemami monitorowania zdarzeń sieciowych. Oprogramowanie typu IDS, jeśli nie ma zainstalowanych najnowszych definicji analizy składniowej, klasyfikuje ruch ukierunkowany na domeny Punycode jako komunikację stacji roboczej ze złośliwym oprogramowaniem typu botnet generującym pseudolosowe nazwy, powodując wpisy w rejestrach incydentów (false positives). Wymaga to tworzenia wyjątków w listach kontroli dostępu na zaporach sieciowych.

Rozwiązywanie skutków ataków homograficznych i infekcji systemowych

Należy wyraźnie zaznaczyć, że w aspekcie usterek sprzętowych oraz problemów z systemem Windows u użytkowników prywatnych, incydenty sieciowe spowodowane bezpośrednio brakiem obsługi standardu IDN to w dzisiejszych czasach rzadkość w zgłoszeniach. Obecnie dystrybuowane kompilacje systemów operacyjnych zapewniają hermetyczną obsługę konwersji adresów na poziomie warstwy TCP/IP i natywnych bibliotek. Bezpośrednia ingerencja sprzętowa lub programowa staje się wymagana dopiero wtedy, gdy mechanizmy izolacji zawiodą i urządzenie użytkownika ulegnie udanej infiltracji na skutek odwiedzenia domeny spreparowanej techniką homograficzną.

Jeżeli filtry w przeglądarce nie rozpoznają zagrożenia, połączenie z fałszywym adresem jest nawiązywane, a certyfikat SSL dla takiej domeny weryfikuje się z wynikiem pozytywnym, utrzymując ikonę zielonej kłódki. Nieświadome pobranie i uruchomienie pliku wykonywalnego serwowanego przez cyberprzestępców pod maską aktualizacji lub dokumentu PDF kończy się głęboką modyfikacją struktur systemowych. Kod ładunku może aktywować ransomware szyfrujące partycje dyskowe, zainstalować moduły modyfikujące lokalne usługi DNS lub zagnieździć keyloggery działające na poziomie jądra systemu, niewykrywalne dla powłoki użytkownika.

W obliczu takich uszkodzeń oprogramowania, diagnostyka stacji roboczej wymaga demontażu dysku twardego z komputera lub laptopa i podpięcia nośnika do zewnętrznego systemu analitycznego za pomocą interfejsu blokującego zapis (write blocker). Pozwala to na precyzyjne skanowanie klastrów z pominięciem procedur startowych zainfekowanego OS-u. Warszawskie Pogotowie Komputerowe wykonuje w tym etapie usunięcie wektorów infekcji, czyszczenie gałęzi rejestru modyfikujących routing systemowy, usuwanie obcych certyfikatów Root CA z magazynu Windows oraz przywracanie poprawności rozruchu lokalnego środowiska. W przypadkach niszczących uderzeń oprogramowania szyfrującego wykonywane jest również sprzętowe klonowanie posektorowe układów NAND oraz podstawowy odzysk struktur systemów plików. Dodatkowo weryfikowany jest ogólny stan fizyczny układów – stan płyty głównej, sprawność kości RAM, taśmy matryc oraz parametry układu zasilania, aby wykluczyć jednoczesne usterki eksploatacyjne sprzętu.

Zakres działań obejmuje wyłącznie przywracanie parametrów fabrycznych elektroniki użytkowej. Procesy związane z modyfikacją stref DNS u rejestratorów, audytami bezpieczeństwa sieci szkieletowych czy rekonfiguracją sprzętu w wielkoskalowych środowiskach obliczeniowych wykraczają poza profil napraw punktów wyspecjalizowanych w usterkach mikroukładów BGA, matryc i systemów instalowanych na domowych stacjach roboczych.