Firmware Analysis
Last updated
Last updated
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Oprogramowanie układowe to niezbędne oprogramowanie, które umożliwia urządzeniom prawidłowe działanie, zarządzając i ułatwiając komunikację między komponentami sprzętowymi a oprogramowaniem, z którym użytkownicy wchodzą w interakcję. Jest przechowywane w pamięci trwałej, co zapewnia, że urządzenie może uzyskać dostęp do istotnych instrukcji od momentu włączenia, co prowadzi do uruchomienia systemu operacyjnego. Badanie i potencjalna modyfikacja oprogramowania układowego to kluczowy krok w identyfikacji luk w zabezpieczeniach.
Zbieranie informacji to kluczowy początkowy krok w zrozumieniu budowy urządzenia i technologii, które wykorzystuje. Proces ten obejmuje zbieranie danych na temat:
Architektury CPU i systemu operacyjnego, na którym działa
Szczegółów bootloadera
Układu sprzętowego i kart katalogowych
Metryk bazy kodu i lokalizacji źródłowych
Zewnętrznych bibliotek i typów licencji
Historii aktualizacji i certyfikatów regulacyjnych
Diagramów architektonicznych i przepływowych
Oceny bezpieczeństwa i zidentyfikowanych luk
W tym celu narzędzia inteligencji open-source (OSINT) są nieocenione, podobnie jak analiza wszelkich dostępnych komponentów oprogramowania open-source poprzez procesy przeglądu ręcznego i automatycznego. Narzędzia takie jak Coverity Scan i Semmle’s LGTM oferują darmową analizę statyczną, która może być wykorzystana do znalezienia potencjalnych problemów.
Pozyskiwanie oprogramowania układowego można podejść na różne sposoby, z różnym poziomem złożoności:
Bezpośrednio od źródła (deweloperzy, producenci)
Budując je na podstawie dostarczonych instrukcji
Pobierając z oficjalnych stron wsparcia
Wykorzystując zapytania Google dork do znajdowania hostowanych plików oprogramowania układowego
Uzyskując dostęp do chmury bezpośrednio, za pomocą narzędzi takich jak S3Scanner
Przechwytując aktualizacje za pomocą technik man-in-the-middle
Ekstrahując z urządzenia przez połączenia takie jak UART, JTAG lub PICit
Podsłuchując żądania aktualizacji w komunikacji urządzenia
Identyfikując i używając twardo zakodowanych punktów końcowych aktualizacji
Zrzucając z bootloadera lub sieci
Usuwając i odczytując chip pamięci, gdy wszystko inne zawiedzie, używając odpowiednich narzędzi sprzętowych
Teraz, gdy masz oprogramowanie układowe, musisz wyodrębnić informacje na jego temat, aby wiedzieć, jak je traktować. Różne narzędzia, które możesz użyć do tego:
Jeśli nie znajdziesz wiele za pomocą tych narzędzi, sprawdź entropię obrazu za pomocą binwalk -E <bin>, jeśli entropia jest niska, to prawdopodobnie nie jest zaszyfrowany. Jeśli entropia jest wysoka, prawdopodobnie jest zaszyfrowany (lub w jakiś sposób skompresowany).
Ponadto możesz użyć tych narzędzi do wyodrębnienia plików osadzonych w firmware:
File/Data Carving & Recovery ToolsLub binvis.io (code), aby zbadać plik.
Za pomocą wcześniej omówionych narzędzi, takich jak binwalk -ev <bin>, powinieneś być w stanie wyodrębnić system plików.
Binwalk zazwyczaj wyodrębnia go w folderze nazwanym zgodnie z typem systemu plików, który zazwyczaj jest jednym z następujących: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.
Czasami binwalk nie ma magicznego bajtu systemu plików w swoich sygnaturach. W takich przypadkach użyj binwalk, aby znaleźć offset systemu plików i wyciąć skompresowany system plików z binarnego i ręcznie wyodrębnić system plików zgodnie z jego typem, korzystając z poniższych kroków.
Uruchom następujące polecenie dd, aby wyodrębnić system plików Squashfs.
Alternatywnie, można również uruchomić następujące polecenie.
$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs
Dla squashfs (używanego w powyższym przykładzie)
$ unsquashfs dir.squashfs
Pliki będą w katalogu "squashfs-root" po tym.
Pliki archiwum CPIO
$ cpio -ivd --no-absolute-filenames -F <bin>
Dla systemów plików jffs2
$ jefferson rootfsfile.jffs2
Dla systemów plików ubifs z pamięcią NAND
$ ubireader_extract_images -u UBI -s <start_offset> <bin>
$ ubidump.py <bin>
Gdy oprogramowanie układowe zostanie uzyskane, istotne jest jego rozłożenie w celu zrozumienia struktury i potencjalnych luk. Proces ten polega na wykorzystaniu różnych narzędzi do analizy i wydobywania cennych danych z obrazu oprogramowania układowego.
Zestaw poleceń jest dostarczany do wstępnej inspekcji pliku binarnego (nazywanego <bin>). Te polecenia pomagają w identyfikacji typów plików, wydobywaniu ciągów, analizie danych binarnych oraz zrozumieniu szczegółów partycji i systemu plików:
Aby ocenić status szyfrowania obrazu, sprawdzana jest entropia za pomocą binwalk -E <bin>. Niska entropia sugeruje brak szyfrowania, podczas gdy wysoka entropia wskazuje na możliwe szyfrowanie lub kompresję.
Do wyodrębniania plików osadzonych zaleca się korzystanie z narzędzi i zasobów, takich jak dokumentacja file-data-carving-recovery-tools oraz binvis.io do inspekcji plików.
Używając binwalk -ev <bin>, można zazwyczaj wyodrębnić system plików, często do katalogu o nazwie odpowiadającej typowi systemu plików (np. squashfs, ubifs). Jednak gdy binwalk nie rozpoznaje typu systemu plików z powodu brakujących bajtów magicznych, konieczne jest ręczne wyodrębnienie. Polega to na użyciu binwalk do zlokalizowania offsetu systemu plików, a następnie polecenia dd do wycięcia systemu plików:
Po tym, w zależności od typu systemu plików (np. squashfs, cpio, jffs2, ubifs), używane są różne polecenia do ręcznego wyodrębnienia zawartości.
Po wyodrębnieniu systemu plików rozpoczyna się poszukiwanie luk w zabezpieczeniach. Zwraca się uwagę na niebezpieczne demony sieciowe, twardo zakodowane dane uwierzytelniające, punkty końcowe API, funkcjonalności serwera aktualizacji, niekompilowany kod, skrypty uruchamiające oraz skompilowane binaria do analizy offline.
Kluczowe lokalizacje i elementy do sprawdzenia obejmują:
etc/shadow i etc/passwd w celu uzyskania danych uwierzytelniających użytkowników
Certyfikaty SSL i klucze w etc/ssl
Pliki konfiguracyjne i skrypty w poszukiwaniu potencjalnych luk
Wbudowane binaria do dalszej analizy
Typowe serwery internetowe urządzeń IoT i binaria
Kilka narzędzi pomaga w odkrywaniu wrażliwych informacji i luk w zabezpieczeniach w systemie plików:
LinPEAS i Firmwalker do wyszukiwania wrażliwych informacji
The Firmware Analysis and Comparison Tool (FACT) do kompleksowej analizy oprogramowania układowego
FwAnalyzer, ByteSweep, ByteSweep-go i EMBA do analizy statycznej i dynamicznej
Zarówno kod źródłowy, jak i skompilowane binaria znalezione w systemie plików muszą być dokładnie sprawdzone pod kątem luk. Narzędzia takie jak checksec.sh dla binariów Unix i PESecurity dla binariów Windows pomagają zidentyfikować niechronione binaria, które mogą być wykorzystane.
Proces emulacji oprogramowania układowego umożliwia analizę dynamiczną działania urządzenia lub pojedynczego programu. Podejście to może napotkać trudności związane z zależnościami sprzętowymi lub architektonicznymi, ale przeniesienie systemu plików root lub konkretnych binariów na urządzenie o dopasowanej architekturze i endianness, takie jak Raspberry Pi, lub na wstępnie zbudowaną maszynę wirtualną, może ułatwić dalsze testowanie.
Aby zbadać pojedyncze programy, kluczowe jest zidentyfikowanie endianness programu i architektury CPU.
Aby emulować binaria architektury MIPS, można użyć polecenia:
Aby zainstalować niezbędne narzędzia emulacyjne:
Dla MIPS (big-endian) używa się qemu-mips, a dla binarnych w formacie little-endian wybór padłby na qemu-mipsel.
Dla binarnych ARM proces jest podobny, z emulatorem qemu-arm wykorzystywanym do emulacji.
Narzędzia takie jak Firmadyne, Firmware Analysis Toolkit i inne, ułatwiają pełną emulację firmware, automatyzując proces i wspierając analizę dynamiczną.
Na tym etapie używa się rzeczywistego lub emulowanego środowiska urządzenia do analizy. Ważne jest, aby utrzymać dostęp do powłoki systemu operacyjnego i systemu plików. Emulacja może nie idealnie odwzorowywać interakcje sprzętowe, co wymaga okazjonalnych restartów emulacji. Analiza powinna ponownie przeszukać system plików, wykorzystać ujawnione strony internetowe i usługi sieciowe oraz zbadać luki w bootloaderze. Testy integralności firmware są kluczowe do identyfikacji potencjalnych luk backdoor.
Analiza w czasie rzeczywistym polega na interakcji z procesem lub binarnym w jego środowisku operacyjnym, wykorzystując narzędzia takie jak gdb-multiarch, Frida i Ghidra do ustawiania punktów przerwania i identyfikacji luk poprzez fuzzing i inne techniki.
Opracowanie PoC dla zidentyfikowanych luk wymaga głębokiego zrozumienia architektury docelowej i programowania w językach niskiego poziomu. Ochrony w czasie rzeczywistym w systemach wbudowanych są rzadkie, ale gdy są obecne, mogą być konieczne techniki takie jak Return Oriented Programming (ROP).
Systemy operacyjne takie jak AttifyOS i EmbedOS zapewniają wstępnie skonfigurowane środowiska do testowania bezpieczeństwa firmware, wyposażone w niezbędne narzędzia.
AttifyOS: AttifyOS to dystrybucja mająca na celu pomoc w przeprowadzaniu oceny bezpieczeństwa i testów penetracyjnych urządzeń Internetu Rzeczy (IoT). Oszczędza dużo czasu, oferując wstępnie skonfigurowane środowisko z wszystkimi niezbędnymi narzędziami.
EmbedOS: System operacyjny do testowania bezpieczeństwa wbudowanego, oparty na Ubuntu 18.04, wstępnie załadowany narzędziami do testowania bezpieczeństwa firmware.
Aby ćwiczyć odkrywanie luk w firmware, użyj następujących wrażliwych projektów firmware jako punktu wyjścia.
OWASP IoTGoat
Projekt Damn Vulnerable Router Firmware
Damn Vulnerable ARM Router (DVAR)
ARM-X
Azeria Labs VM 2.0
Damn Vulnerable IoT Device (DVID)
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
