W ostatnim wpisie przedstawiłem mechanizm ataku na sieć węzłów Bitcoin. W tamtym przypadku wystarczyło podzielić istniejącą sieć na mniejsze „partycje” sieci, przy wykorzystaniu ataku na routing w sieciach internetowych (BGP hijacking).

Czas na zaprezentowanie drugiego scenariusza, którego celem jest zaburzenie poprawności działania sieci Bitcoin. Scenariusz dotyczy nie tylko Bitcoina, ale także każdej sieci blockchain, dla której czas autoryzacji transakcji/zdarzenia jest kluczowy.

Metoda ataku wykorzystuje trzy kluczowe reguły Bitcoina.

Pierwsza reguła sieci Bitcoin: Asymetria

Reguła jest prosta – wykorzystujemy Asymetrię. Asymetria dotyczy komunikacji węzłów Bitcoin (użycie wiadomości INV, GETDATA i BLOCK).

Wszystkie węzły w sieci Bitcoin nieustannie wyczekują na informację rozgłoszeniową o nowych transakcjach/zdarzeniach.

Informacja rozsyłana jest do węzłów przy wykorzystaniu wiadomości INV, w której zawarty jest hash rozgłaszanego bloku.

Jeżeli węzeł stwierdzi, że w wiadomości INV jest nowy hash, wówczas wysyła do rozsyłającego wiadomość INV węzła – wiadomość GETDATA. Zapytany węzeł odpowiada wiadomością BLOCK, w której zawarte są oczekiwane przez pytający węzeł informacje. Cała komunikacja odbywa się asymetrycznie.

Druga reguła sieci Bitcoin: Brak szyfrowania

Komunikacja w sieci węzłów Bitcoin nie jest chroniona przed naruszeniem/zafałszowaniem przesyłanej informacji. Wysyłając wiadomości INV, GETDATA, BLOCK czy inne komunikaty, nie wykorzystuje się żadnego szyfrowania, żadnego SSL, nie ma nawet mechanizmu, który generowałby jakąś sumę kontrolną każdej przesłanej wiadomości. Kompletnie NIC. Pakiety transportowane są protokołem TCP, na porcie 9888, i to właściwie jedyny mechanizm zawierający mechanizm bezpieczeństwa transmisji, jaki wykorzystywany jest do komunikacji pomiędzy węzłami.

Segment TCP wymaga generowania sumy kontrolnej (bardziej do sprawdzenia, czy nie nastąpiły przekłamania bitów w ramce, niż dla celów ochrony informacji), poza tym ten sposób komunikacji traktowany jest jako tryb połączeniowy wymagający „3-way handshake”, w przeciwieństwie do pakietów UDP. To sprawia, że sieć jest w miarę bezpieczna, np.  w zakresie wolumetrycznych ataków DDoS. Zapewne twórca blockchain nie chciał dokładać dodatkowych operacji obliczeniowych, jakie wymagają metody szyfrowania komunikacji. „Opakowanie” komunikacji w segmenty TCP odbywa się na poziomie karty sieciowej, więc nie obciąża głównych procesorów odpowiedzialnych za obliczenia wartości kolejnego bloku w łańcuchu informacyjnym.

Trzecia reguła sieci Bitcoin: Timeout

Transmisja komunikatów pomiędzy węzłami Bitcoin odbywa się asynchronicznie. Dlatego twórcy przewidzieli sytuację, gdy zapytany węzeł z jakichś powodów nie udzieli odpowiedzi.

Na wypadek takiego scenariusza stworzono wymóg, który definiuje, że odpowiedź powinna nadejść po czasie nie dłuższym niż 20 minut.

Jeżeli w czasie 20 minut od zapytania nie nastąpi odpowiedź, wówczas węzeł pytający zamyka taką komunikację i rozpoczyna „dialog” z innym węzłem sieci Bitcoin. Wtedy scenariusz komunikacji się powtarza – INV i oczekiwanie na odpowiedź w postaci wiadomości GETDATA.

W ten sposób węzły wymieniają się informacjami i współdzielą informację o transakcji/zdarzeniu, które ma zostać zarejestrowane w łańcuchu informacyjnym.

Istnienie powyższych aspektów sieci Bitcoin pozwala na stworzenie scenariusza ataku, który wykorzystuje te reguły do swoich celów. Jak?

Scenariusz ataku

Atakujący sieć węzłów Bitcoin wykorzysta asynchroniczność komunikacji do tego, aby specjalnie opóźniać komunikację atakowanego węzła sieci Bitcoin i wymuszać czekanie przez całe 20 minut, zanim węzły wymienią między sobą dane. A co ciekawe, działanie atakującego jest całkowicie niewykrywalne, ponieważ nie ma mechanizmu, który wykrywałby taką ingerencję Atakującego.

W czasie trwania ataku, atakowany węzeł nie otrzymuje aktualnej informacji o wydobytym bloku Bitcoina czy nowej transakcji, która ma zostać dołączona do łańcucha informacyjnego. Jak to wygląda w praktyce?

Stan początkowy: Załóżmy, że mamy 3 węzły sieci Bitcoin A, B i C. Celem ataku jest węzeł C, do którego węzły A i B wysłały wiadomość INV (komunikacja zaznaczona kolorem niebieskim). Załóżmy, że komunikat INV z węzła A dotarł do atakowanego węzła C szybciej niż INV z węzła B.

Krok 1 ataku: „Pobudzony” wiadomością INV węzeł C odpowiada węzłowi A wiadomością GETDATA, żądając przesłania bloku informacyjnego X. Jednocześnie węzeł C uruchamia zegar, który rozpoczyna pomiar czasu, aby wiedzieć, kiedy upłynie 20 min. W tym momencie wkracza Atakujący. Przechwytuje komunikat GETDATA i modyfikuje go w taki sposób, aby węzeł A wysłał do węzła C „stary blok”. Jak to robi? Wystarczy, że zastosuje metodę ataku BGP hijacking, o której pisałem w cz.1. W ten sposób cała komunikacja węzłów sieci Bitcoin przechodzi przez sieć ISP, w której Atakujący ma pełną kontrolę nad przesyłanymi wiadomościami węzłów Bitcoin. Dzięki temu Atakujący może buforować komunikację pomiędzy węzłami i sprawiać, że poszczególne komunikaty pomiędzy węzłami trafią do „poczekalni”, gdzie spędzą prawie 20 minut, zanim zostaną dostarczone.

W dodatku Atakujący może dowolnie modyfikować zawartość komunikatów, ponieważ nie są one w żaden sposób szyfrowane. Nawet nie musi się wysilać do tego, aby je specjalnie fałszować. Wystarczy, że za każdym razem uszkodzi wiadomość, a węzeł zażąda przesłania bloku informacyjnego ponownie. Z tym, że pytanie i odpowiedź znowu spędzą w „poczekalni” prawie 20 minut, zanim zostaną dostarczone.

Krok 2 ataku: Węzeł A przesyła do węzła C „starą informację”, ponieważ o taką „zapytał” węzeł C lub też stwierdza, że wiadomość została uszkodzona i ponownie wyśle informację. W tym wypadku także Atakujący odsyła komunikat do „poczekalni”,  w której spędzi on prawie 20 minut, zanim zostanie dostarczony do węzła C.

Krok 3 ataku: Cykl komunikacji pomiędzy węzłami A i C zostaje powtórzony, gdzie za każdym razem komunikaty są przechwytywane przez Atakującego, modyfikowane i przetrzymywane w buforze przez prawie 20 minut.

Efekt?

Zaatakowany węzeł C nie został zaktualizowany, w dodatku komunikacja pomiędzy węzłami została wyciągnięta w czasie do maksymalnego okresu 20 minut.

Ponadto komunikacja zaatakowanego węzła C z węzłem A wciąż jest utrzymana. A to oznacza, że węzeł C nie będzie komunikował się z innymi węzłami sieci Bitcoin.

Podsumowanie

Jaki może być praktyczny efekt tego typu ataku na sieć węzłów Bitcoin?

Dla osób realizujących płatność on-line przy wykorzystaniu Bitcoinów efektem będzie bardzo długi czas potwierdzenia transakcji. W skrajnym przypadku może dojść do sytuacji, gdy transakcja w ogólnie nie zostanie potwierdzona. Istnieje także niebezpieczeństwo „rozdwojenia się” łańcucha (double spend), gdzie część węzłów będzie miała jedną wersję łańcucha informacyjnego, a druga część przechowywać będzie całkiem inną wersję łańcucha informacyjnego.

Dla „górników” opóźnienie rejestracji transakcji/zdarzeń w łańcuchu informacyjnym także nie jest obojętne, ponieważ obniża ich efektywność obliczeniową oraz ekonomiczną. Komputery bez względu na to czy dokonują obliczenia czy też czekają, wymagają ciągłego zasilania. Wprowadzenie opóźnienia powoduje, że komputery jałowo czekają przez długi okres na zamknięcie procesu komunikacji węzłów, a tym samym nie dokonują żadnych obliczeń. W efekcie pobierają prąd, za który trzeba płacić, nie generując w tym czasie żadnych profitów – nie ma potwierdzenia transakcji, nie ma opłat za ich potwierdzenie.

Atak oddziałuje również na zwykłe węzły sieci Bitcoin, ponieważ znacząco obniża ich wkład do sieci Bitcoin i znacząco opóźnia propagację aktualnego łańcucha informacyjnego (blockchain) w sieci Bitcoin.

Jak widać, oddziaływanie ataku dotyczy praktycznie każdego uczestnika sieci Bitcoin. Efekt działania ataku można porównać do ataku aplikacyjnego DDoS.

Z tą różnicą, że w przypadku klasycznego ataku aplikacyjnego DDoS następuje utylizacja dostępnych zasobów, poprzez wywoływanie fałszywych sesji nawiązywanych np. z serwerem (każda sesja rezerwuje zasoby, które nie są zwalnianie aż do zakończenia sesji).

W przypadku ataku na sieć węzłów Bitcoin atak DDoS ma inne zadanie – spowolnienie procesów komunikacyjnych w sieci, a tym samym zarówno zakłócenie komunikacji, jak również mocne ograniczenie wykorzystania zasobów obliczeniowych udostępnionych na potrzeby sieci Bitcoin.

Czy można z tym coś zrobić? Czy można się przed tym ochronić? Odpowiedź na to pytanie będzie tematem następnej części.