Luki w zabezpieczeniach DAO i Blockchain

Kwestie bezpieczeństwa zastępują wszystkie inne względy ogólnie w oprogramowaniu, aw szczególności w łańcuchu bloków. Jeśli bezpieczeństwo zawiedzie, nic innego się nie liczy. Blockchain udowadnia, że ​​zdecentralizowane, pozbawione zaufania transakcje działają, ale mimo to wiele luk w zabezpieczeniach łańcucha blokowego pozostaje.

Exploity bezpieczeństwa istnieją na poziomie projektu i architektury, na etapie kodowania oraz w fazie operacyjnej. A jeśli się zastanawiasz, tak, łańcuch bloków można zhakować.

Luki w zabezpieczeniach Blockchain – stąd do wieczności

Diamenty są wieczne, a inteligentne kontrakty działają tak długo, jak długo łańcuch bloków, na którym są wdrażane, będzie nadal używany. W związku z tym wszystkie błędy i luki w zabezpieczeniach blockchain również istnieją tak długo, jak długo obowiązuje umowa.

Zazwyczaj każdy łańcuch bloków zapewnia własny język programowania do wdrażania inteligentnych kontraktów. Przyjrzyjmy się bliżej.

Języki inteligentnych umów

Środowiska Blockchain zawierają własne języki do tworzenia inteligentnych kontraktów.

Na przykład platforma Ethereum zawiera język Solidity do pisania inteligentnych kontraktów. Twórcy zaprojektowali Solidity jako kompletny język Turinga.

Kompletny język Turing zasadniczo pozwala programiście zaimplementować wszystko, do czego jest zdolny bazowy system. W konsekwencji daje to programistom takie możliwości, jak implementowanie pętli w kodzie, które mogą potencjalnie powodować luki w zabezpieczeniach łańcucha bloków.

Kompletność Turinga

Kompletne języki Turing są z natury złożone, a złożoność prowadzi do błędów i luk.

Sieć Bitcoin ma również język programowania, który nazywa skryptem. Skrypt celowo nie jest kompletny w Turingu, aby zwiększyć bezpieczeństwo.

Im mniej opcji dostępnych jest programiście, tym mniejsze prawdopodobieństwo, że luki w zabezpieczeniach łańcucha bloków dostaną się do systemu.

Aby zminimalizować ryzyko wypuszczenia błędnego kodu na wolność, programiści muszą zrozumieć typowe pułapki i przeciw wzorcom nieodłącznie związane z programowaniem inteligentnych kontraktów. (Anty-wzorce oznaczają złe praktyki programistyczne).

The DAO Hack: The Reentrancy Problem

Obraz luk w zabezpieczeniach blockchain

Hack DAO

Problem z ponownym wejściem prawdopodobnie zajmuje najwyższe miejsce wśród programistów związanych z bezpieczeństwem blockchain zakodowanych w inteligentnych kontraktach. Reentrancy opróżnia konto poprzez wielokrotne wydatki związane z tą samą transakcją. Przypadek użycia przetwarzania zwrotów nadaje się do tego exploita, ale ta wada wpływa na każdy rodzaj transakcji, jeśli nie zostanie rozwiązana na etapie projektowania i kodowania.

W jednym z najbardziej niesławnych dotychczas ataków na kryptowalutę hakerzy z DAO wykorzystali ponowne wejście. Żaden lider organizacji nie dyktował, jak prowadzić DAO (lub zdecentralizowaną organizację autonomiczną), a DAO zaproponował, aby dać użytkownikom możliwość głosowania nad projektami, w które można inwestować.

W pierwszym miesiącu zebrał ponad 150 milionów dolarów finansowania. 17 czerwca 2016 r. Hakerzy wydobyli z organizacji 50 milionów dolarów w wyniku błędu ponownego wejścia. Hard fork od Ethereum Classic (ETC) do Ethereum (ETH) zaowocował próbą rozwiązania problemów, które stworzył ten hack.

Anty-wzór podatny na ponowne wejście

Podatna logika ponownego wprowadzenia kodu wygląda następująco:

funkcja przetwarzania płatności () {

(1) sprawdzić ważność transakcji, odbiorcę i stan konta;

(2) przetworzyć transakcję;

(3) zaktualizować stan systemu, aby pokazać, że transakcja została przetworzona;

}

Na pierwszy rzut oka logika wygląda na poprawną i kompletną, ale wada tkwi w kolejności wykonywania kroku 2 przed krokiem 3.

Podczas gdy pierwsze wywołanie funkcji kontynuuje przetwarzanie kroku 2, kolejne wywołanie tej samej transakcji może wejść do funkcji. Ponieważ informacja o stanie pozostaje w swoim stanie początkowym i nie została jeszcze przetworzona w etapie 3, drugie wywołanie jest sprawdzane jako ważna transakcja do przetworzenia.

W konsekwencji system wydaje walutę na to samo zobowiązanie po raz drugi. Hakerzy przyspieszają wiele transakcji do funkcji, zanim stan zostanie prawidłowo ustawiony.

Lekarstwo na reentrancy

Ta zmiana w algorytmie rozwiązuje powyższy problem:

funkcja przetwarzania płatności () {

(1) sprawdzić ważność transakcji, odbiorcę i stan konta;

(2) zaktualizować stan systemu, aby pokazać, że transakcja została przetworzona;

(3) przetworzyć transakcję;

}

Kod musi uwzględniać całą niezbędną obsługę wyjątków, a także musi uwzględniać wszystkie zależności logiczne.

Przelewowy

Przepełnienie to kolejna powszechna luka w zabezpieczeniach, o której muszą wiedzieć programiści.

Niektóre języki programowania zapewniają mocne pisanie, a inne słabe. Języki z silnymi typami nie pozwalają programistom na przykład przypisywać danych łańcuchowych do zmiennej numerycznej, a języki słabo typizowane pozwalają na takie akcje.

Języki z silną typografią wymuszają ograniczenia zakresu. Jeśli tablica składa się z dziesięciu elementów, programiści nie mogą próbować uzyskać dostępu do jedenastego elementu. Języki słabo wpisane pozwalają na takie zachowanie, ale skutkują awariami. Jeśli maksymalna dopuszczalna wartość, jaką posiada zmienna, to 99 i przypisujesz jej wartość 100, obserwuj, jak się zawiesza po uruchomieniu!

W rezultacie przepełnienie jest exploitem używanym przez hakerów. Jeśli haker przesyła parametr do inteligentnego kontraktu, który jest poza zakresem, jaki może przetworzyć kod, następuje awaria. Taka katastrofa napędza wiele exploitów. Awaria może wywołać atak typu „odmowa usługi” (atak DDoS), a istotne informacje o wewnętrznych elementach systemu czasami ujawniają się w komunikatach o błędach.

W aplikacjach internetowych hakerzy często wypełniają pamięć własnym złośliwym kodem, więc gdy program ulega awarii i trafia do losowego miejsca w pamięci, złośliwy kod jest wykonywany.

Języki słabo typowane zapewniają moc i dynamiczną elastyczność, ale wymagają również bardziej rygorystycznego projektowania i testowania, aby były odporne na ataki.

Wielogłowa Hydra

Obraz luk w zabezpieczeniach blockchain

Wiele problemów związanych z bezpieczeństwem jest plagą świata oprogramowania. Wraz z pojawieniem się nowej technologii pojawiają się nowe zagrożenia. Oprócz wspomnianych powyżej exploitów, te znaczące wady stanowią tylko kilka z wielu innych luk w zabezpieczeniach łańcucha bloków.

Zła kryptografia powoduje wiele bólów głowy. Kryptografia zapewnia prywatność, a kiedy prywatność się łamie, wszystko się psuje. Zespół IOTA popełnił błąd, pisząc od podstaw własną bibliotekę kryptograficzną w początkowej wersji swojego produktu. Problem nieodłącznie związany z rozwijaniem własnej kryptografii polega na tym, że całe złożone oprogramowanie zawiera błędy, więc masz gwarancję, że kryptografia jest błędna.

Ustanowione biblioteki kryptograficzne przetrwały weryfikację przeprowadzaną przez naukowców i okazują się niezawodne w czasie życia na wolności.

W świecie portfeli generowanie liczb losowych musi być naprawdę losowe. Zwłaszcza we wczesnych latach kryptowaluty niektóre portfele nie spełniały tego wymogu.

Adresy kryptowalut wymagają adresów, które muszą być unikalne. Niepowtarzalność pochodzi z generatora liczb losowych, a generator liczb losowych potrzebuje ziarna, aby rozpocząć proces. Jeśli ziarno nie jest naprawdę losowe, system zawiedzie.

Jeden wynik złej losowości oznacza, że ​​ten sam adres zostanie utworzony wiele razy. Wyobraź sobie scenariusz, w którym portfel przypisuje adres X do osoby A, a później przypisuje adres X do osoby B. Kiedy płatność trafia na adres X, trafia tylko do jednej osoby. Która osoba otrzyma pieniądze?

Inny problem ze złą losowością pojawia się, gdy haker odkryje algorytm użyty do utworzenia ziarna. Haker regeneruje ziarno dla siebie i jest właścicielem systemu.

Droga trwa wiecznie, a impreza nigdy się nie kończy

Bezpieczeństwo to niekończąca się walka i nawet jeśli programiści, architekci i testerzy usuną wszystkie luki z kodu, luki operacyjne pozostaną.

W środowisku Proof of Work, jeśli źli aktorzy kontrolują 51% sieci, integralność zostaje zniszczona. Teoria gier zapewnia złagodzenie tego ataku. Nowa kryptowaluta z małą siecią naraża największe ryzyko na ten atak. Ale atak 51% niszczy wartość waluty, więc atakujący po prostu robią sobie krzywdę.

Blockchainy działają w internecie i mają taką samą ekspozycję na hakerów jak Internet. Załóżmy na przykład, że kupujesz monety z giełdy w witrynie internetowej. Dominują ataki typu injection, cross-site scripting, phishing i wszystkie inne tradycyjne ataki na strony internetowe.

Końcowe przemyślenia

Tak jak programiści chronią się przed błędami, programiści muszą brać pod uwagę bezpieczeństwo podczas tworzenia. Istnieją pewne narzędzia, które pomagają programistom w wykonywaniu tych zadań, ale programiści muszą najpierw zrozumieć własne luki w zabezpieczeniach, aby się przed nimi ustrzec.

Plik Projekt zdecentralizowanego bezpieczeństwa aplikacji (DASP) aspiruje do roli repozytorium informacji i zasobów dotyczących bezpieczeństwa blockchain. Oni wzorują się nieco na Open Web Application Security Project (OWASP). Coroczny ranking OWASP Top 10 zdecydowanie wymienia główne istniejące obecnie luki w zabezpieczeniach aplikacji internetowych. DASP Top 10 ma nadzieję zapewnić równoważne zasoby dla łańcucha bloków.

Nie wszystkie ataki są znane z góry. Exploit typu zero-day definiuje exploit, o którym hakerzy wiedzą, zanim zrobią to ktokolwiek inny. Dlatego programiści muszą myśleć jak atakujący podczas projektowania i wdrażania oprogramowania. Jeśli nie znajdziesz luk w swoim kodzie, spodziewaj się, że znajdzie je haker szukający zysku.

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
map