Bitsquatting

Wpisując nazwę strony WWW w pasku przeglądarki, czasami zdarzają się pomyłki. Zamiast odwiedzić właściwą witrynę trafiamy wtedy na tzw. parking domen lub do zupełnie innego serwisu. Bywają też mniej bezpieczne sytuacje, np. serwisy łudząco podobne do oryginałów, które służą do wyprowadzania danych bądź infekowania komputera szkodliwym oprogramowaniem. Wyobraźmy sobie, że istnieje prawdopodobieństwo wystąpienia podobnej sytuacji nawet wtedy, gdy wpisany adres był poprawny…

Bitsquatting to specyficzna odmiana typosquattingu, która z kolei jest wariantem cybersquattingu (z ang. cyber – cybernetyczne, squatting – dzikie zasiedlanie). Ten ostatni polega na rejestrowaniu nazw domenowych takich samych lub różniących się jedynie nazwą domeny najwyższego poziomu (np. .pl, gdy istnieje .com) od nazw już należących do znanych marek czy osób.

Zamiarem cybersquattera (cybernetycznego dzikiego lokatora) jest późniejsza odsprzedaż domen ich prawowitym właścicielom lub wykorzystanie ich do innych celów: serwowania reklam, gromadzenia danych osobowych, niszczenia wizerunku, a nawet infekowania komputerów szkodliwym oprogramowaniem. Przykładem nazwy domenowej zajętej przez cybersquattera mogłaby być randomseed.io, gdyby zauważył, że istnieje już nazwa randomseed.pl.

Odmianą cybersquattingu jest typosquatting (z ang. typo – literówka). W jego przypadku rejestrowane są nazwy podobne do oryginalnych, lecz różniące się jedną literą: sąsiadującą na klawiaturze z właściwą, zamienioną miejscem z inną, brakującą lub powtórzoną. Typosquatter rezerwuje więc takie nazwy, które mogą być efektem pomyłek podczas wpisywania oryginalnych, włączając w to błędne przepisywanie ze słuchu, np. zamiast randomseed.pl ktoś mógłby wpisać randomsed.pl.

„Kuzynem” typosquattingu jest omawiany tu bitsquatting (z ang. binary digit, skr. bit – cyfra dwójkowa). Polega on na rejestrowaniu nazw, które od oryginalnych różnią się jednym bitem.

Kto myli bity?

Pomyłki w pojedynczych bitach przydarzają się nie tylko uznanym muzykom nurtu hip-hop, ale również komputerom i urządzeniom aktywnym odpowiedzialnym za przesyłanie danych w sieci Internet. W przypadku systemu nazw domenowych (ang. Domain Name System, skr. DNS) nazwy są łańcuchami tekstowymi zbudowanymi w oparciu o alfabet składający się z dużych i małych liter, cyfr i znaków dywizu (-).

Urządzenia cyfrowe nie operują bezpośrednio na literach. To, że możemy się z nimi komunikować z użyciem alfabetu języka naturalnego zawdzięczamy przyjętej konwencji, czyli standaryzowanej tabeli zwanej zestawem znaków, w której liczbom odpowiadają czcionki ekranowe przeznaczone do wyświetlenia bądź wydrukowania. Przypomina to znane z programów graficznych kodowanie informacji o barwach z użyciem trzech liczb.

Zawartość umownej tabeli i sposób przypisywania wartości do symboli nazywamy rodzajem kodowania. Najprostszy i najbardziej rozpowszechniony rodzaj kodowania to ASCII (skr. od ang. American Standard Code for Information Interchange), gdzie liczby z zakresu od 0–127 wyrażają kolejne litery podstawowego alfabetu łacińskiego, niektóre znaki specjalne i sekwencje sterujące. Istnieje również rozszerzony wariant ASCII, który zawiera więcej dodatkowych symboli, lecz wymaga większego zakresu liczb (0–255).

Aby wyrazić zestaw znaków języka naturalnego w pamięci bądź medium transmisyjnym, każdy jego element musi zostać przekształcony do postaci numerycznej. Z kolei każdą z takich wartości można odzwierciedlić w formie zapisu binarnego, czyli ciągu zer i jedynek. Stąd już prosta droga do elektronicznej reprezentacji, tzn. użycia zestawu ładunków elektrycznych w celu zapamiętania bądź przesłania danych. W taki właśnie sposób zrozumiałe dla człowieka napisy są przechowywane i przesyłane w urządzeniach cyfrowych.

W uproszczeniu: do zapamiętania stanu pojedynczego bitu wykorzystywany będzie bardzo mały kondensator. Możemy go sobie wyobrazić jako mikro-baterię, która może być naładowana (1) lub rozładowana (0). Zestaw kondensatorów pozwoli nam wyrazić sekwencję bitów, której można użyć do przedstawienia liczb całkowitych. Na przykład w tabeli ASCII znakowi spacji odpowiada liczba 32, którą binarnie można wyrazić jako 00100000 przy założeniu, że operujemy na ośmiu bitach. Będziemy więc mieli osiem baterii, ale tylko trzecia od lewej będzie naładowana.

Układy elektroniczne mogą wykonywać podstawowe operacje na sygnałach wyrażonych w sposób opisany wyżej – przesyłać je i magazynować. Wystarczy przyjąć, że jedynce odpowiada pewna różnica potencjałów między dwoma punktami obwodu lub pola, a zerze brak tej różnicy bądź inna przyjęta wartość. Oczywiście w celu zwiększenia przepływności, szczególnie przy transmisji danych, korzysta się z systemów, które do przesłania wykorzystują jednocześnie więcej niż jeden parametr (np. różną częstotliwość czy kształt fali) i pozwalają w tym samym kwancie czasu zakomunikować więcej niż jedną wartość.

Zauważając jednak, że za przetwarzanie ruchu DNS odpowiadają głównie podzespoły komputerów i popularnych urządzeń sieciowych (bazujących na cyfrowych jednostkach obliczeniowych), możemy przyjąć model, w którym nazwy domenowe reprezentowane są właśnie jako ciągi cyfr w zapisie dwójkowym, czyli bitów. Z racji ograniczonego alfabetu idealnie nadaje się do tego celu upowszechnione na przestrzeni dziesięcioleci kodowanie ASCII. W zapisie tym nazwa randomseed.pl będzie reprezentowana w następujący sposób:

Zgodnie z dokumentem RFC 1035, który określa sposób funkcjonowania DNS, przed każdą etykietą (składnikiem nazwy) umieszczona powinna być wartość określająca jej długość w liczbie oktetów, a jej dwa pierwsze (bardziej znaczące) bity w zapisie dwójkowym muszą być wyzerowane. Poza tym pełna nazwa domenowa powinna być zakończona ośmioma wyzerowanymi bitami oznaczającymi domenę główną (.). Nasza nazwa będzie więc zakodowana w następujący sposób:

Pierwsza wartość w sekwencji (10, binarnie 00001010) informuje o długości etykiety randomseed (10 oktetów). Kolejna specjalna wartość (2, bin. 00000010) określa długość etykiety pl (2 oktety).

Powyższe liczby mogą być przechowywane w komórkach pamięci zdolnych zapamiętywać tylko stan wysoki lub niski jako następująca sekwencja ośmiobitowych bajtów:

00001010 01110010 01100001 01101110 01100100
01101111 01101101 01110011 01100101 01100101
01100100 00000010 01110000 01101100 00000000

Dla lepszego zobrazowania możemy utworzyć prostą tabelę:

LF, STX i NUL to nazwy sekwencji kontrolnych ASCII (nowa linia, początek tekstu i znak pusty), które w DNS nie mają znaczenia, a pojawiły się, ponieważ niektóre wartości przekładają się właśnie na nie, chociaż nie stanowią semantycznej części nazwy domenowej.

Wciąż jednak nie odpowiedzieliśmy sobie na pytanie o to, gdzie i w jakich warunkach dochodzi do przekłamań, a także jakie są ich skutki. Żeby precyzyjnie zauważyć słabe punkty, warto spojrzeć na symboliczną reprezentację przykładowego zapisu nazwy randomseed.pl. Będzie ona zlepkiem 120 bitów przechowywanych w pamięci operacyjnej komputera, routera dostępowego i pośredniczących w procesie uzyskiwania adresu serwerów DNS:

⊥⊥⊥⊥⊤⊥⊤⊥⊥⊤⊤⊤⊥⊥⊤⊥⊥⊤⊤⊥⊥⊥⊥⊤⊥⊤⊤⊥⊤⊤⊤⊥⊥⊤⊤⊥⊥⊤⊥⊥
⊥⊤⊤⊥⊤⊤⊤⊤⊥⊤⊤⊥⊤⊤⊥⊤⊥⊤⊤⊤⊥⊥⊤⊤⊥⊤⊤⊥⊥⊤⊥⊤⊥⊤⊤⊥⊥⊤⊥⊤
⊥⊤⊤⊥⊥⊤⊥⊥⊥⊥⊥⊥⊥⊥⊤⊥⊥⊤⊤⊤⊥⊥⊥⊥⊥⊤⊤⊥⊤⊤⊥⊥⊥⊥⊥⊥⊥⊥⊥⊥

Łączenie tego typu danych w jeden strumień lub blok jest możliwe, ponieważ każda ich porcja reprezentująca pojedynczą literę ma zawsze taką samą długość – w tym przypadku jednego oktetu czyli ośmiu bitów. Algorytmy odpowiedzialne za przetwarzanie danych będą więc „wiedziały”, w których miejscach należy dokonać podziału, aby zachować numeryczne, a następnie alfabetyczne znaczenie komunikatu. Na przykład drugi oktet nazwy „wygrawerowany” w stanach kondensatorów płata pamięciowego jako ⊥⊤⊤⊤⊥⊥⊤⊥ odpowiada literze r.

Warto wspomnieć, że aby utrzymać zawartość dynamicznej pamięci RAM – z którą mamy do czynienia w większości komputerów – potrzebne jest cykliczne odświeżanie jej zawartości, realizowane przez wyspecjalizowane układy wewnątrz samego modułu pamięciowego lub przez CPU (obecnie rzadkość). Polega ono na doładowywaniu aktywnych komórek, tzn. takich, które przechowują wartości (⊤). W tym przykładzie, aby komputer pamiętał tylko pojedynczą literę, będą musiały występować 3 takie doładowania w bardzo krótkich odstępach czasu (kilka milisekund, co sumarycznie przekłada się na około 0,4% całego czasu pracy pamięci).

Biorąc pod uwagę liczbę operacji na pamięci i liczbę urządzeń uczestniczących w komunikacji, mogą czasem wystąpić pomyłki. Gdyby podczas przesyłania, zapisywania, odświeżania lub po prostu trwania danych w pamięci operacyjnej ostatni aktywny bit ostatniego oktetu nazwy randomseed.pl został wygaszony (01101000 zamiast 01101100), to literę l zastąpiłaby litera h, a przeglądarka działając w oparciu o taką informację wyświetliłaby zawartość filipińskiej witryny widocznej pod nazwą randomseed.ph. Znając tę podatność cybersquatter mógłby zarejestrować właśnie taką nazwę i liczyć na to, że pewien odsetek odwiedzających trafi do jego serwisu.

Przyczyny

Błędy w obsłudze pamięci polegają na tym, że wartość odczytywana różni się od wartości wcześniej zapisanej. Te, które tu opisujemy polegają na pomyłce w obrębie jednego bitu (ustawieniu lub wygaszeniu) i zdarzają się bardzo rzadko. Do ich przyczyn należą:

• promieniowanie kosmiczne,
• promieniowanie neutronowe pochodzenia ziemskiego,
• promieniowanie wewnętrzne układów,
• zakłócenia wewnętrzne układów,
• zbyt wysoka temperatura i inne czynniki środowiskowe.

Pierwsze trzy czynniki mają związek z oddziaływaniem cząstek elementarnych na potencjały kondensatorów używanych do zapamiętywania informacji, a także na przewodnictwo w towarzyszących im tranzystorach. Wraz ze zwiększaniem zagęszczenia elementów półprzewodnikowych rośnie prawdopodobieństwo wpływu promieniowania na ich działanie.

Promieniowanie kosmiczne, to wysokoenergetyczne cząstki, na które składają się głównie energetyczne neutrony, ale też protony i piony. Gdy przekroczona zostanie ich pewna liczba w stosunku do objętości, mogą zakłócić przekazywanie ładunków w tranzystorze lub doprowadzić do przekroczenia napięcia przy którym pojawi się ładunek w kondensatorze i zostanie on zmierzony jako reprezentacja logicznej jedynki. Według szacunków firmy IBM przeprowadzonych w roku 1996 w komputerze biurkowym błąd spowodowany promieniowaniem kosmicznym może wystąpić raz w miesiącu dla każdych 256 mebibajtów (256 × 2²⁰ bajtów) pamięci RAM¹.

Promieniowanie wewnętrzne układów zdarza się w tańszych podzespołach i jest to promieniowanie jonizujące emitowane przez rozpadające się jądra atomowe. W efekcie elementy pamięci bombardowane są strumieniem cząstek alfa, których źródłem są najczęściej obudowy układów scalonych i ich podstawy wykonane ze źle dobranych do współpracy z elementami elektronicznymi materiałów.

W przypadku promieniowania neutronowego pochodzenia ziemskiego, sprawy przejmowania nazw domenowych czy rzadkich usterek w pamięci komputera schodzą na dalszy plan (przynajmniej u użytkowników cywilnych). Jego obecność – prowadząca do zakłóceń komunikacji czy uszkodzeń w procesie przechowywania danych – świadczy bowiem o niedalekiej eksplozji nuklearnej i/lub użyciu bomby neutronowej.

Zakłócenia wewnętrzne układów i wysoka temperatura również mogą powodować problemy w obsłudze pamięci. W przeciwieństwie do promieniowania kosmicznego czy spowodowanego wybuchem bomby atomowej, można nad nimi zapanować na etapie produkcji i użytkowania sprzętu – zapewniając odpowiednie, zewnętrzne i wewnętrzne warunki pracy, korzystając z dobrej jakości materiałów (np. odpowiednio czystych plastrów krzemu). Usterki tego typu, jeżeli już się zdarzają, są zazwyczaj łatwo rozpoznawalne, ponieważ nie występuje przy nich sporadyczne wygaszenie czy zapalenie pojedynczego bitu, lecz poważniejsze problemy, uniemożliwiające poprawną pracę urządzenia.

Statystyki

Wzmianki o bitsquattingu pojawiły się w roku 2011 dzięki pracy Artema Dinaburga zatytułowanej „Bitsquatting. DNS Hijacking without Exploitation”². W opracowaniu przedstawił on dokładne dane statystyczne dotyczące prawdopodobieństw wystąpienia usterek w obrębie pojedynczych bitów. Na przykład popularna konfiguracja komputera wyposażonego w 4 GiB pamięci typu DIMM „na pokładzie” jest wrażliwa na pojawienie się przekłamania 3 razy w miesiącu. Wartość ta pochodzi z obserwacji, że w tej konfiguracji jeden błąd pojawia się raz na 950 lat, co daje 120 możliwych wystąpień usterek dla każdego z 34 360 megabitów (czyli właśnie 4 GiB).

Przyjęta przez badaczy jednostka FIT (z ang. Failures In Test) oznacza liczbę usterek w jednym megabicie na miliard godzin pracy, zaś przytoczona wcześniej wartość to najniższe zaobserwowane prawdopodobieństwo dla wszystkich badanych typów pamięci bez korekcji błędów.

Gdyby założyć, że na początku roku 2013 do sieci Internet podłączonych było około 9 miliardów urządzeń³, przy czym każde z nich miało średnio 128 MiB pamięci RAM (wartość może wydawać się zaniżona, lecz uwzględniamy również starszy sprzęt, urządzenia mobilne i tylko te pamięci, których nie wyposażono w mechanizmy korekcji błędów), to sumaryczną pojemność pamięci (w gigabajtach) można wyliczyć w następujący sposób:

9 × 10⁹ × 128 MiB = 9,664 × 10¹² Mb = 1 208 000 000 GB

Z kolei całkowitą częstość pomyłek możemy poznać mnożąc liczbę wszystkich podatnych komórek pamięci przez średnie prawdopodobieństwo wystąpienia błędu przy przyjętym wcześniej współczynniku FIT równym 120 (błędów na miliard megabitogodzin):

9,664 × 10¹² Mb × 120 / (8,322 × 10⁹ Mbh) = 139 351 / h

Co w sumie daje nam 139 351 możliwych błędów w każdej godzinie.

Nie tylko DNS

Bitsqatting jest tylko emanacją znacznie większego zjawiska. W przypadku jednobitowych usterek pojawiających się w przestrzeni pamięci odpowiedzialnej za odwzorowywanie nazw, prawdopodobieństwo jest o wiele mniejsze, jednak i tak duże w porównaniu z danymi innego przeznaczenia. Wynika to z faktu, że w procesie przechowywania i zmiany nazwy domenowej w adres IP bierze udział wiele komponentów: pamięć podręczna serwera DNS, pamięć podręczna HTML serwera pośredniczącego, bufor HTML w przeglądarce klienta, pamięć podręczna przeglądarki, pamięć podręczna i operacyjna resolvera w systemie klienta, a także bufory systemu operacyjnego i bibliotek odpowiedzialnych za obsługę komunikacji sieciowej oraz plikowego wejścia/wyjścia.

W praktyce więc bitsquatting stanowi realne zagrożenie dla serwisów internetowych, które obsługują naprawdę duży ruch – od kilku milionów do kilku miliardów odwołań dziennie.

Przegrzana Java

Pierwszy dobrze udokumentowany atak wykorzystujący sprzętowe usterki pamięci w obrębie jednego bitu miał miejsce w roku 2003. Sudhakar Govindavajhala i Andrew W. Appel, badacze z Uniwersytetu Princeton, przeprowadzili eksperyment, w którym udało im się nakłonić maszynę wirtualną Javy (IBM JVM) do wykonania kodu poza przestrzenią ochronną (tzw. piaskownicą, ang. sandbox).

Używając odpowiednio spreparowanej aplikacji Javy, wykorzystując usterkę w słabym generatorze liczb pseudolosowych i polegając na szczęśliwym trafie (jednobitowym błędzie w obsłudze RAM) udało im się uzyskać dostęp do przestrzeni pamięci należącej do innego obiektu działającego w wirtualnym środowisku. Nie czekali jednak na przypadkowy błąd wywołany promieniowaniem kosmicznym, ale sprowokowali zakłócenia posługując się lampą cieplną o mocy 50 W. Jej użycie podnosiło temperaturę kości pamięci od 80℃ do około 100℃ i sprawiało, że w 70% przypadków dochodziło do całkowitego zatrzymania JVM, natomiast w pozostałych maszyna wirtualna funkcjonowała wadliwie, a w kilku przypadkach zgodnie z tym, czego oczekiwali badacze⁴.

Sudhakar Govindavajhala

Jawny klucz prywatny

W przypadku komputerów nieuprawniony dostęp czy kontrolę nad aplikacją można uzyskać na wiele sposobów, a wykorzystanie pamięciowych pomyłek jest tylko jednym z nich i przyznajmy – nieco wysublimowanym. Istnieją jednak zastosowania, w odniesieniu do których ten wektor ataku jest jednym z niewielu skutecznych czy możliwych do zastosowania. Mowa o wszelkiej maści urządzeniach, gdzie na poziomie sprzętowym zabezpiecza się pewne przestrzenie adresowe pamięci operacyjnej lub nieulotnej przed odczytem, czyli na przykład o kartach kryptograficznych. Używa się ich do szyfrowania i cyfrowego podpisywania danych, uwierzytelniania osoby w systemie dostępowym czy do dekodowania sygnału telewizji satelitarnej.

Crackerzy przełamujący zabezpieczenia czipów korzystają z przeróżnych sposobów, aby nakłonić komórki pamięci do zmiany stanu: zmniejszają częstotliwość taktowania zegara, podgrzewają karty, prowokują krótkie spięcia lub chwilowe zwiększenia napięcia na wejściach, a nawet traktują układy falami radiowymi. Po wielu próbach udaje się zaburzyć działanie zaszytego podprogramu i zmusić go do wygenerowania zrzutu części lub całości pamięci, której normalnie nie da się odczytać.

Eksperyment z DNS

Wróćmy do jednobitowych usterek w pamięci operacyjnej, które pozwalają cybernetycznym dzikim lokatorom na zajmowanie odpowiednich nazw. Jak często się zdarzają i jak popularna musi być nazwa domenowa, aby opłacało się rejestrować podobne do niej, lecz różniące się tylko jednym bitem?

Zamiast posługiwać się statystyką i teoretyzować najlepiej przeprowadzić eksperyment. Podjął się go Artem Dinaburg, który w roku 2011 zarejestrował około 30 nazw, zaczynając od ikamai.net (w oryginale akamai.net), przez microsmft.com (w oryginale microsoft.com), a kończąc na doubleslick.net (w oryginale doubleclick.net). Wszystkie obsługiwane były przez wydzielony serwer DNS, a wskazywały na adres IP serwera WWW uruchomionego w tym samym systemie.

Po siedmiu miesiącach testów okazało się, że do jednobitowych pomyłek dochodziło średnio 59 razy dziennie dla 30 testowanych nazw domenowych. Co ciekawe, niektóre systemy operacyjne okazały się mniej podatne na występowanie błędów niż inne. Na przykład Mac OS X, w porównaniu z ogólną, statystycznie mierzoną popularnością zapytań HTTP, miał znacznie mniej „wpadek”. Zauważono też, że najwięcej usterek wydarzało się w stacjach klienckich lub serwerach proxy (96%), natomiast tylko 3% w komponentach systemu nazw domenowych (serwerach DNS i resolverach). Najczęściej ofiarą pomyłek padały litery q oraz r .

Wektory ataków

W kwietniu 2013 roku Jaeson Schultz z Cisco zaprezentował warianty ataków typu bitsquatting, które pozwalają wykorzystać fakt różnego znaczenia poszczególnych symboli używanych do wskazania miejsca docelowego.

Pomyłki w separatorach nazw domenowych

Zgodnie z dokumentem RFC 1123 nazwa domenowa może składać się z dużych lub małych liter alfabetu łacińskiego bez akcentów i znaków specjalnych, poza dywizem (–). Dopuszczalnym separatorem, oddzielającym części adresu (nazwy domenowe i stacji) jest kropka. Atak polega na zarejestrowaniu takich nazw, dla których w wyniku jednobitowej pomyłki dochodzi do zamiany kropki z literą n, albo litery n z kropką.

Na przykład nazwa domenowa www.randomseed.pl może zostać zmieniona w nazwę domenową wwwnrandomseed.pl, natomiast nazwa zaufanatrzeciastrona.pl w zaufanatrzeciastro.a.pl.

Pomyłki w separatorach ścieżkowych URL

Polegają one na błędach w części odpowiedzialnej za ścieżkę schemat uniwersalnego lokalizatora zasobu – wszędzie tam, gdzie umieszczono znaki ukośnika (/). Z powodu usterki mogą one zmienić się w literę o i vice versa.

Intruz może dzięki temu liczyć na skrócenie adresu, jeżeli litery przed znakiem o są poprawną nazwą domenową najwyższego poziomu, np. i.plo.net zmienia się w i.pl/.net i kieruje do strony działającej pod nazwą i.pl.

Pomyłki w znacznikach kotwiczenia URL

Łańcuchy URL mogą zawierać symbol kratki (#), który oddziela nazwę domenową i ścieżkę od nazwy etykiety, zwanej też kotwicą (ang. anchor). Jej użycie pozwala doprecyzować, o jaki dokładnie fragment treści dokumentu HTML chodzi odwiedzającemu, czyli określić miejsce, do którego browser powinien się przenieść po wczytaniu strony.

W przypadku pomyłek tego typu może dojść do zamiany znaku # z literą c lub odwrotnie, a kłopot pojawia się wtedy, gdy nie podano ścieżki (znacznik etykiety następuje bezpośrednio do nazwie DNS). Gdy tak się stanie, to możemy spodziewać się na przykład www.pl#.com (nazwa domenowa www.pl) zamiast www.plc.com.

Pomyłki w schematach URL

Ciekawą usterką będzie zamiana / na o (i odwrotnie) w schemacie URL lub literze następującej bezpośrednio po nim. Tylko pozornie nie da się jej wykorzystać, ponieważ nawet błędnie podany schemat przeglądarki internetowe „poprawiają”, zwiększając komfort pracy. Dla przykładu napis http://randomseed.pl/ może zostać zmieniony na http:/orandomseed.pl/, co sprawi, że odwołanie nastąpi do strony pod nazwą orandomseed.pl.

Analogicznie w przypadku nazw domenowych rozpoczynających się literą o błąd typu bitsquatting może doprowadzić do jej zmiany w ukośnik, a mechanizmy korygujące przeglądarki potraktują schemat łańcucha URL jako wpisany omyłkowo i na przykład zamiast odwiedzić http://ovh.net/ użytkownik odwiedzi http:///vh.net, czyli połączy się z vh.net.

Domeny wewnętrzne

Firmy często stosują separację sieci wewnętrznej od publicznych podsieci, a dla wygody (szczególnie w większych przedsiębiorstwach) uruchamiają wewnętrzne serwery systemu nazw domenowych.

Pracownik, który chce skorzystać z wewnętrznego serwisu do zarządzania projektami może połączyć się z nim wpisując w pasku adresowym przeglądarki łatwą do zapamiętania nazwę, np. http://projekty.internal. W nazwie tej .internal to wewnętrzna domena najwyższego poziomu, natomiast projekty to nazwa stacji sieciowej, na której działa usługa WWW.

Gdyby pojawił się błąd typu bitsquatting związany z separatorem, to przeglądarka mogłaby skierować użytkownika pod adres odpowiadający lokalizatorowi http://projekty.inter.al, więc zamiast do wewnętrznego serwera użytkownik mógłby omyłkowo zalogować się do fałszywej witryny imitującej tą działającą w intranecie.

Aplikacje

Zagrożone atakami typu bitsquatting są nie tylko zawartości witryn WWW, ale też wszelkie inne dane, które pobrano, określając ich lokalizację z użyciem nazw domenowych. Przykładem mogą być tu programy komputerowe, czy aktualizacje, które potencjalny napastnik może podmienić na własne wersje, zawierające np. trojana. Scenariusz taki jest bardzo prawdopodobny, ponieważ serwery uaktualnień z racji popularności korzystają często z sieci dostarczania zawartości (ang. Content Delivery Network, skr. CDN). Na przykład Akamai obsługuje około 20% całego ruchu w sieci Internet.

Ochrona

Pierwszą linią obrony przed przypadkowymi zmianami danych przechowywanych w pamięci są wspomniane już, wbudowane sprzętowe mechanizmy korekcji bazujące na sumach kontrolnych. Niestety, korzystające z nich układy (tzw. ECC, z ang. Error-Correcting Code) nie są standardowym wyposażeniem większości urządzeń konsumenckich. Poza tym ich użycie związane jest z odczuwalnym spadkiem wydajności, a żeby zapewnić komputerowi odpowiednią ochronę należałoby wymienić nie tylko RAM, ale także dysk twardy (na taki, którego pamięć podręczna to ECC) czy kartę graficzną (na taką, której pamięć działa w trybie ECC).

Pocieszającym może być fakt, że pewną barierą przed już zniekształconymi informacjami są kontrolery interfejsów (USB, SCSI, PCI itp), które korzystają z własnych sum kontrolnych. W razie wykrycia usterki komponent uczestniczący w komunikacji będzie poproszony o retransmisję lub zgłoszony zostanie błąd. Niestety, ochrona ta nie rozciąga się na jednobitowe pomyłki w pamięci, które wiążą się z bitsquattingiem.

Od strony software’owej ogólny problem usterek w zakresie jednego bitu można rozwiązać stosując cyfrowe podpisywanie lub liczenie sum kontrolnych dla wiadomości komunikacji międzyprocesowej, a także bloków ważnych danych przechowywanych w pamięci. Dodatkowo należałoby na poziomie systemu operacyjnego lub standardowych bibliotek wprowadzić odpowiednie mechanizmy korekcji i/lub redundancji, na przykład ponownego pobierania danych do bufora, w razie wykrytego naruszenia integralności.

Wyprzedzanie bitsquatterów

Jeżeli chodzi o nazwy domenowe, to jednym z obejść jest rejestracja wszystkich tych, które mogą zostać omyłkowo wybrane. Nie zda się to niestety na wiele, jeżeli używana nazwa w przekłamanym wariancie została już przez kogoś zajęta.

Dywersyfikacja

Innym sposobem jest dystrybuowanie ruchu między wiele nazw umieszczonych w posiadanej domenie. (Wszystkie mogą być nawet obsługiwane przez jeden serwer). Nie jest to rozwiązanie dobre dla pojedynczej witryny, ale jak najbardziej możliwe do zastosowania przez dostawcę usług, który ma wielu klientów. Dywersyfikacja przestrzeni DNS może uczynić atak skierowany, polegający na zakupie przez potencjalnego napastnika wielu nazw, nieopłacalnym z powodu dużej ich liczby. Dla utrudnienia odwzorowania można co jakiś czas zmieniać, aby udaremniać próby rejestrowania ich odpowiedników.

Zmiany w aplikacjach

Również projektanci aplikacji webowych lub innych programów komunikujących się przez sieć mogą zminimalizować ryzyko wpływu jednobitowych pomyłek w nazwach na pracę swoich dzieł. Wystarczy, że ograniczą liczbę miejsc, gdzie w pamięci przechowywana jest nazwa DNS czy pełen lokalizator zasobu.

Pomóc mogą nie tylko poważne zmiany w strukturach danych i algorytmach takich aplikacji, ale nawet tak proste zabiegi jak zmiana odnośników bezwzględnych na względne czy zmiana niektórych liter na wielkie (dla poprawnego rozpoznawania nazw w obrębie DNS nie ma to znaczenia, a wielka litera o innym kodzie ASCII może nie mieć tak wielu lub nie mieć wcale bitsquattowych odpowiedników mieszczących się w alfabecie).

Korekcje DNS po stronie klienta

A co z końcowym użytkownikiem, internautą? Również on ma pewne pole manewru w zakresie ochrony. W przypadku usług wewnętrznych, czy nawet często odwiedzanych publicznych serwisów, można pokusić się o dopisanie ich przeinaczonych nazw domenowych do pliku /etc/hosts (Uniksy) lub %SystemRoot%\system32\drivers\etc\hosts (Windows) i skojarzyć z właściwymi adresami IP, albo z adresem pętli zwrotnej (ang. loopback) czyli 127.0.0.1. Problematyczne może być kierowanie ruchu do wspomnianych, właściwych adresów, które przecież mogą po jakimś czasie ulec zmianie. Lepiej więc, gdy jest taka możliwość, użyć własnego serwera nazw domenowych (np. buforującego serwera działającego na domowym routerze czy lokalnej stacji sieciowej) i utworzyć rekordy typu CNAME (nazwy kanoniczne).

Certyfikaty SSL

Pewną i praktyczną ochroną, wymagającą jednak współpracy użytkowników (czy raczej użytkowanych przez nich aplikacji i systemów operacyjnych) z dostawcami aplikacji oraz usług, jest wykorzystanie szyfrowania i cyfrowego podpisywania danych.

W przypadku usług sieci web administratorzy serwerów, poza uruchomieniem obsługi SSL/TLS mogą ustawiać nagłówek HTTP Strict Transport Security (HSTS), który poinformuje przeglądarkę, że z daną witryną powinna się łączyć tylko z użyciem bezpiecznej warstwy gniazdowej. Oczywiście certyfikat serwera powinien pochodzić od zaufanego urzędu.

Cyfrowe podpisywanie kodu

Odpowiednikiem powyżej opisanej metody ochrony w przypadku aplikacji pobieranych z Sieci będzie cyfrowe podpisywanie kodu. W takich przypadkach nawet, gdyby przytrafiło się, że program pochodzi z omyłkowo wybranego źródła, nie zostanie on uruchomiony, jeżeli jego cyfrowy podpis, a właściwie skojarzony z nim klucz publiczny, nie będzie poświadczony przez zaufany organ certyfikujący.