Statyczna analiza luk w zabezpieczeniach polega na wyszukiwaniu luk w zabezpieczeniach poprzez inspekcję pakietów aktualizacji, systemów plików i plików binarnych systemu bez konieczności uruchamiania ocenianego urządzenia. W rzeczywistości w większości przypadków atakujący nie musi mieć urządzenia, aby wykonać większość analizy statycznej. W tej sekcji zapoznasz się z niektórymi narzędziami i technikami przeprowadzania analizy statycznej na urządzeniu wbudowanym.
Ta część dotyczy wykorzystywania urządzeń wbudowanych. Temat ten staje się coraz ważniejszy wraz z pojawieniem się Internetu rzeczy (IoT), jak omówiono w poprzednich rozdziałach. Od wind po samochody, tostery i wszystko, co „inteligentne”, urządzenia wbudowane stają się wszechobecne, a luki w zabezpieczeniach i zagrożenia stają się niezliczone. Jak zauważył Bruce Schneier, jest to jak Dziki Zachód lat 90.; wszędzie, gdzie spojrzymy, są luki w zabezpieczeniach tych urządzeń wbudowanych. Schneier wyjaśnia, że dzieje się tak z powodu wielu czynników, w tym ograniczonych zasobów samych urządzeń i ograniczonych zasobów producentów w niskomarżowej dziedzinie produkcji urządzeń wbudowanych. Miejmy nadzieję, że więcej etycznych hakerów stanie na wysokości zadania i zrobi wgniecenie w fali luk w zabezpieczeniach urządzeń wbudowanych.
Krótko omówiliśmy różnice między różnymi pakietami CPU (mikrokontroler, mikroprocesor i SoC), kilkoma interesującymi interfejsami szeregowymi, JTAG i oprogramowaniem wbudowanym. W naszej dyskusji na temat interfejsów szeregowych, zostałeś wprowadzony do JTAGulatora w przykładzie odkrywania portów UART (szeregowych). JTAGulatora można również użyć do odkrywania portów debugowania JTAG i potencjalnie kilku innych interfejsów. Krótko omówiliśmy również różne przypadki użycia oprogramowania, w tym bootloadery, brak systemu operacyjnego, RTOS i ogólny system operacyjny. Na tym etapie powinieneś mieć już wspólne słownictwo dotyczące systemów wbudowanych i kilka obszarów wymagających uwagi, gdy będziesz próbował lepiej je zrozumieć.
Termin ogólny system operacyjny jest używany do opisu systemów operacyjnych innych niż RTOS. Linux jest najczęstszym przykładem ogólnego systemu operacyjnego. Linux dla systemów wbudowanych nie różni się zbytnio od Linuxa dla systemu stacjonarnego. Systemy plików i architektura są takie same. Główne różnice między wersjami wbudowanymi i stacjonarnymi to ograniczenia dotyczące urządzeń peryferyjnych, pamięci masowej i pamięci. Aby pomieścić ogólnie mniejszą pamięć masową i pamięć, system operacyjny i system plików są minimalizowane. Na przykład zamiast używać typowych programów instalowanych z Linuksem, takich jak bash, telnetd, ls, cp i tym podobne, zwykle używa się mniejszego monolitycznego programu o nazwie BusyBox. BusyBox zapewnia funkcjonalność w ramach pojedynczego pliku wykonywalnego, używając pierwszego argumentu jako żądanego programu. Chociaż chciałbym powiedzieć, że nieużywane usługi są usuwane w celu zmniejszenia powierzchni ataku, prawdopodobnie są usuwane tylko w celu zaoszczędzenia miejsca. Chociaż większość urządzeń celowo nie zapewnia użytkownikowi dostępu do konsoli, wiele z nich ma port szeregowy do dostępu do konsoli na płycie. Gdy tylko uzyskasz dostęp do głównego systemu plików, albo przez konsolę, albo przez wyodrębnienie obrazu z pamięci masowej, będziesz chciał poszukać wersji aplikacji i bibliotek, katalogów zapisywalnych przez wszystkich, wszelkich trwałych pamięci masowych i procesu inicjalizacji. Proces inicjalizacji dla Linuksa, znajdujący się w /etc/inittab i /etc/init.d/ rcS, da ci pojęcie o tym, jak aplikacje są uruchamiane podczas rozruchu.
Systemy, które są bardziej złożone i mają trudne wymagania dotyczące przetwarzania czasu, zazwyczaj używają systemu operacyjnego czasu rzeczywistego (RTOS), takiego jak VxWorks. Zaletą RTOS jest to, że zapewnia on funkcjonalność systemu operacyjnego, taką jak zadania, kolejki, stosy sieciowe, systemy plików, obsługę przerwań i zarządzanie urządzeniami, z dodatkową możliwością deterministycznego harmonogramu. Na przykład autonomiczne lub wspomagane przez kierowcę systemy samochodowe prawdopodobnie używają RTOS, aby zapewnić, że reakcje na różne czujniki zachodzą w granicach tolerancji bezpieczeństwa systemu (sztywny). Dla tych, którzy są przyzwyczajeni do systemów z systemem Linux, VxWorks jest zupełnie inny. Linux ma dość standardowy system plików ze wspólnymi programami, takimi jak telnet, BusyBox, ftp i sh, a aplikacje działają jako oddzielne procesy w systemie operacyjnym. W przypadku VxWorks wiele systemów działa w zasadzie z jednym procesem, z wieloma zadaniami i bez standardowego systemu plików lub aplikacji pomocniczych. Podczas gdy Linux ma wiele informacji dotyczących ekstrakcji oprogramowania sprzętowego i inżynierii wstecznej, jest bardzo mało informacji dotyczących VxWorks. Ekstrakcja oprogramowania sprzętowego za pomocą SPI lub I2C lub użycie pobranego pliku dostarczy Ci ciągów i kodu, które można rozmontować. Jednak w przeciwieństwie do Linuksa, zazwyczaj nie otrzymasz łatwo przyswajalnych danych. Analiza ciągów pod kątem haseł, certyfikatów, kluczy i ciągów formatujących może przynieść przydatne sekrety do wykorzystania w aktywnym systemie. Ponadto użycie JTAG do ustawienia punktów przerwania i wykonania działań na urządzeniu jest prawdopodobnie najskuteczniejszą metodą odwrócenia tej funkcjonalności.
W przypadku wielu aplikacji narzut systemu operacyjnego i prostota systemu nie uzasadniają ani nie pozwalają na system operacyjny. Na przykład czujnik, który wykonuje pomiary i wysyła je do innego urządzenia, prawdopodobnie używa mikrokontrolera o niskim poborze mocy, takiego jak PIC, i nie potrzebuje systemu operacyjnego. W tym przykładzie PIC prawdopodobnie nie ma wystarczających zasobów (pamięci masowej, pamięci RAM itd.), aby umożliwić uruchomienie systemu operacyjnego. W systemach bez systemu operacyjnego przechowywanie danych będzie prawdopodobnie bardzo prymitywne, oparte na przesunięciach adresów lub wykorzystujące pamięć NVRAM. Ponadto systemy te zazwyczaj nie mają interfejsu użytkownika lub interfejs jest niezwykle prosty, taki jak diody LED i przyciski. Po pobraniu programu, czy to poprzez ekstrakcję z pamięci masowej, czy poprzez pobranie, format może być całkowicie niestandardowy i niełatwo identyfikowalny dla często używanych narzędzi do analizy plików. Najlepiej przeczytać dokumentację mikrokontrolera, aby zrozumieć, w jaki sposób urządzenie ładuje kod i próbuje go ręcznie zdekonstruować za pomocą deasemblera. Możesz myśleć, że tak prosty system nie byłby zbyt interesujący, ale pamiętaj, że może mieć łączność z bardziej złożonym systemem z połączeniami internetowymi. Nie odrzucaj tych urządzeń jako pozbawionych wartościowej powierzchni ataku bez wcześniejszego rozważenia całkowitego przypadku użycia, w tym podłączonych urządzeń i ich przeznaczenia. Ograniczona przestrzeń instrukcji może oznaczać, że urządzenie nie ma możliwości odpowiedniej ochrony przed złośliwym wejściem, a protokoły prawdopodobnie nie są szyfrowane. Ponadto podłączone systemy mogą wyraźnie ufać wszelkim danym pochodzącym z tych urządzeń i dlatego nie podejmować odpowiednich środków w celu zapewnienia, że dane są prawidłowe.
Aby oprogramowanie wyższego poziomu działało na procesorze, system musi zostać zainicjowany. Oprogramowanie, które wykonuje początkową konfigurację procesora i wymaganych początkowych urządzeń peryferyjnych, nazywa się bootloaderem. Proces ten zazwyczaj wymaga wielu etapów, aby system był gotowy do uruchomienia oprogramowania wyższego poziomu. Uproszczony proces jest zazwyczaj opisany w następujący sposób:
Jeśli używany jest U-Boot, ten bootloader mógł zostać skonfigurowany tak, aby umożliwić alternatywne sposoby ładowania programu głównego. Na przykład U-Boot może ładować się z karty SD, pamięci flash NAND lub NOR, USB, interfejsu szeregowego lub TFTP przez sieć, jeśli zainicjowano sieć. Oprócz ładowania programu głównego, może być używany do zastępowania programu głównego w urządzeniu pamięci trwałej. Ubiquiti ER-X, z naszego wcześniejszego przykładu użycia JTAGulatora, używa U-Boot . Oprócz ładowania jądra, umożliwia on odczytywanie i zapisywanie pamięci i pamięci masowej.
Wszystkie omawiane dotąd urządzenia byłyby bezużyteczne bez czegoś, co definiuje ich funkcjonalność. W systemach opartych na mikrokontrolerach/mikroprocesorach oprogramowanie definiuje możliwości i tchnie życie w system. Bootloader jest używany do inicjalizacji procesora i uruchomienia oprogramowania systemowego. Oprogramowanie systemowe dla tych systemów zazwyczaj mieści się w jednym z tych trzech scenariuszy:
• Ogólny system operacyjny W przypadku systemów, które zazwyczaj nie mają ograniczeń czasowych i mają wiele wymagań funkcjonalnych (na przykład Linux i Embedded Windows)
Serial Wire Debug (SWD) to protokół specyficzny dla ARM do debugowania i programowania. W przeciwieństwie do bardziej powszechnego pięciopinowego JTAG, SWD używa dwóch pinów. SWD zapewnia zegar (SWDCLK) i dwukierunkową linię danych (SWDIO), aby zapewnić funkcjonalność debugowania JTAG. Jak widać w Tabeli 20-4, SWD i JTAG mogą współistnieć, co jest ważne.
Możliwości dla programistów i testerów są takie same, jak te wymienione dla JTAG. Podobnie jak w przypadku JTAG, możliwości, które pomagają producentom, umożliwiają również atakującym odkrywanie luk.
Joint Test Action Group (JTAG) została utworzona w latach 80. jako metoda ułatwiająca debugowanie i testowanie układów scalonych. W 1990 r. metoda została znormalizowana jako IEEE 1149.1, ale powszechnie nazywa się ją po prostu JTAG. Chociaż początkowo została stworzona, aby pomóc w testowaniu na poziomie płyty, jej możliwości umożliwiają debugowanie na poziomie sprzętu. Chociaż jest to zbytnie uproszczenie, JTAG definiuje mechanizm wykorzystywania kilku dostępnych zewnętrznie sygnałów w celu uzyskania dostępu do wnętrza układu scalonego za pośrednictwem znormalizowanej maszyny stanowej. Mechanizm jest znormalizowany, ale rzeczywista funkcjonalność za nim stojąca jest specyficzna dla układu scalonego. Oznacza to, że musisz znać debugowany układ scalony, aby skutecznie używać JTAG. Na przykład sekwencja bitów do procesora ARM i procesora MIPS będzie interpretowana inaczej przez wewnętrzną logikę procesora. Narzędzia takie jak OpenOCD wymagają plików konfiguracyjnych specyficznych dla urządzenia, aby działać prawidłowo. Mimo że producenci mogą definiować więcej pinów, opis czterech/pięciu pinów JTAG znajduje się w Tabeli.
Zbiór pinów jest znany również jako port dostępu testowego (TAP). Chociaż można by pomyśleć, że pięć pinów ma standardowy układ, producenci płyt i układów scalonych definiują własne układy. Niektóre typowe układy pinów są zdefiniowane w Tabeli i obejmują konfiguracje 10-, 14- i 20-pinowe. Układy pinów w tabeli są tylko próbką i muszą zostać zweryfikowane przed użyciem z debugerem.
Dla programistów i testerów powszechnie używane są następujące możliwości:
Jak widać, funkcjonalność dostępna dla interfejsu JTAG jest dość potężna. Producenci sprzętu znajdują się w tarapatach. Aby rozwijać, testować i debugować system wbudowany przez cały cykl jego życia, port JTAG jest niezbędny; jednak jego obecność na płycie daje badaczom i atakującym możliwość odkrywania sekretów, zmiany zachowania i znajdowania luk w zabezpieczeniach. Producenci zazwyczaj próbują utrudnić korzystanie z interfejsu JTAG po produkcji, przecinając linie, nie wypełniając pinów, nie oznaczając wyprowadzeń lub wykorzystując możliwości układu scalonego w celu jego wyłączenia. Chociaż jest to dość skuteczne, zdeterminowany atakujący ma wiele środków w swoim arsenale, aby ominąć zabezpieczenia, w tym naprawianie uszkodzonych ścieżek, lutowanie pinów na płytce, a nawet ewentualnie wysłanie układu scalonego do firmy specjalizującej się w wydobywaniu danych. Niektórzy mogą odrzucić JTAG jako słabość, ponieważ do jego użycia wymagany jest fizyczny, potencjalnie destrukcyjny dostęp. Problem z odrzuceniem ataku polega na tym, że atakujący może dowiedzieć się wiele o systemie za pomocą JTAG. Jeśli w systemie znajduje się globalny sekret, taki jak hasło, celowe tylne wejście do pomocy technicznej, klucz lub certyfikat, może on zostać wyodrębniony i następnie użyty do ataku na zdalny system.