Analiza pakietu aktualizacji

https://chacker.pl/

W większości przypadków pakiety aktualizacji dla urządzenia można pobrać ze strony dostawcy. Obecnie wiele, jeśli nie większość aktualizacji, nie jest szyfrowanych, dlatego potencjalnie można je zdekonstruować za pomocą różnych narzędzi, takich jak unzip, binwalk i Firmware Mod Kit. W celach instruktażowych przyjrzymy się systemowi opartemu na systemie Linux, ponieważ prawdopodobnie znasz te systemy. W systemach wbudowanych opartych na systemie Linux pakiety aktualizacji często zawierają nową kopię wszystkich niezbędnych plików i katalogów wymaganych do obsługi systemu. Wymagane katalogi i pliki są określane jako system plików głównych (RFS). Jeśli atakujący może uzyskać dostęp do RFS, będzie miał procedury inicjalizacji, kod źródłowy serwera WWW, wszelkie pliki binarne wymagane do uruchomienia systemu, a także prawdopodobnie niektóre pliki binarne, które zapewnią atakującemu przewagę podczas próby wykorzystania systemu. Na przykład, jeśli system używa BusyBox i zawiera serwer telnetd, atakujący może wykorzystać serwer Telnet do zapewnienia zdalnego dostępu do systemu. Dokładniej, serwer telnetd zawarty w BusyBox dostarcza argument, który pozwala na jego wywołanie bez uwierzytelniania i powiązanie z dowolnym programem (/usr/sbin/telnetd –l /bin/sh). Jako przykład zbadamy starszą wersję aktualizacji oprogramowania sprzętowego bezprzewodowego wzmacniacza zasięgu D-Link DAP-1320 (wersja 1.1 sprzętu A). Wybraliśmy tę aktualizację, ponieważ jest to starsza aktualizacja, która została załatana, a ujawnienie podatności (www.kb.cert.org/vuls/id/184100) zostało zgłoszone przez kilku autorów.

Pierwszym krokiem jest stworzenie środowiska do dekonstrukcji oprogramowania sprzętowego. W naszym przypadku użyjemy binwalk. Podstawowym systemem hosta do naszej analizy jest Kali Linux 2021.1. Aby zainstalować binwalk, musimy najpierw zainstalować wymagania wstępne za pomocą menedżera pakietów apt-get, aby zainstalować pip3 i usunąć zainstalowaną wersję binwalk (1). Po spełnieniu wymagań wstępnych instalacja wymaga sklonowania projektu z GitHub, sprawdzenia określonej znanej działającej wersji, zmodyfikowania skryptu deps.sh w celu skorygowania błędów związanych z Kali, uruchomienia skryptu deps.sh (2) i zainstalowania binwalk. Następnie próbujemy wyodrębnić oprogramowanie sprzętowe (3) , a jeśli pakiet i typy zawartości są znane narzędziu, zostaną one wyodrębnione w celu dalszej analizy. Z danych wyjściowych możemy wywnioskować, że narzędzie znalazło zarówno obraz jądra MIPS Linux (4), jak i system plików squashfs (5)(6). Przeglądając ekstrakcję, identyfikujemy ją jako system rootfs (7) i weryfikujemy, czy pliki binarne są kompilowane dla MIPS (8).

Teraz, gdy pakiet aktualizacji został wyodrębniony, nadszedł czas na przeglądanie plików, szukając funkcji, konfiguracji lub nieznanych aplikacji. Tabela  definiuje niektóre elementy, których należy szukać podczas przeglądania.

UWAGA Każda znaleziona wersja pliku wykonywalnego lub biblioteki musi zostać sprawdzona pod kątem znanych luk. Na przykład użyj wyszukiwania Google pod kątem luki <name> <version number>.

Po zebraniu wszystkich tych informacji będziesz chciał zrozumieć, co przetwarza żądania z przeglądarki lub jakichkolwiek uruchomionych usług. Ponieważ wykonaliśmy już wszystkie poprzednie kroki, skróciliśmy poniższy przykład, aby analiza była bardziej skondensowana i prostsza. Odkryto, że serwerem internetowym jest lighttpd (1), który używa lighttpd*.conf (2) i modules.conf (3) do konfiguracji. Ponadto używa cgi.conf (4), który kieruje prawie całą obsługę do /bin/ssi (5) (plik wykonywalny binarny).

Mamy już pomysł, jak postępować i rozpoczniemy analizę podatności.

Statyczna analiza luk w zabezpieczeniach urządzeń wbudowanych

https://chacker.pl/

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.

Wykorzystywanie urządzeń wbudowanych

https://chacker.pl/

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.

Podsumowanie

https://chacker.pl/

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ć.

Ogólny system operacyjny

https://chacker.pl/

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.

System operacyjny czasu rzeczywistego

https://chacker.pl/

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.

Brak systemu operacyjnego

https://chacker.pl/

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.

Bootloader

https://chacker.pl/

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:

  1. Mikroprocesor/mikrokontroler ładuje mały program z ustalonej lokalizacji urządzenia poza procesorem w oparciu o tryb rozruchu.
  2. Mały program inicjuje pamięć RAM i struktury wymagane do załadowania pozostałej części bootloadera w pamięci RAM (na przykład U-Boot).
  3. Bootloader inicjuje wszystkie urządzenia niezbędne do uruchomienia programu głównego lub systemu operacyjnego, ładuje program główny i przenosi wykonywanie do nowo załadowanego programu. W przypadku systemu Linux programem głównym byłoby jądro.

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.

Oprogramowanie

https://chacker.pl/

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:

  • Brak systemu operacyjnego W przypadku prostych systemów
  • System operacyjny czasu rzeczywistego W przypadku systemów ze sztywnymi wymaganiami czasowymi przetwarzania (na przykład VxWorks i Nucleus)

• 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)

SWD

https://chacker.pl/

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.