Bezpieczeństwo fizyczne – czyli Raspberry Pi w akcji

how2hax.pl 7 miesięcy temu

Dzisiejszy wpis będzie dotyczyć konfiguracji Raspberry Pi do roli backdoora, którego możemy umieścić w siedzibie firmy czy biurze podczas testów bezpieczeństwa fizycznego.
Pomysł na artykuł narodził się, gdy swego czasu brałem udział w projekcie, w którym fizyczne wejście miało być połączone z przełamaniem perymetru i zdobyciem Initial Access w korporacyjnej sieci. Cel ten postanowiliśmy zrealizować właśnie poprzez podłączenie małej kostki w postaci Raspberry Pi do testowanej sieci. Mam nadzieję, iż ten wpis pozwoli komuś zrealizować podobny (lub lepszy!) pomysł i da inspirację do przeprowadzenia fajnych, Red Teamowych testów.

O czym nie będzie ten wpis?

Zanim zaczniemy. chciałbym napisać o czym ten wpis nie będzie. Nie będę tu mówić o technikach przełamywania zabezpieczeń fizycznych, metodach wejść do budynku, tailgatingu, lockpickingu itp. itd. Nie czuję się specjalistą w tym zakresie i nie sądzę, żebym kiedykolwiek nim został. Wierzę jednak w specjalizacje i podział obowiązków w Red Teamach. Zostawmy więc fizyczną konfrontację z ludźmi osobom o większej charyzmie, a my przygotujmy im jak najlepsze narzędzia do pracy.

Założenie

Założenie dla projektu było następujące: przygotować kostkę Raspberry Pi z dwoma interfejsami sieciowymi – jednym nieaktywnym, a drugim podłączonym do sieci Internet za pośrednictwem modemu USB LTE. Po wejściu na teren firmy, zadaniem testera było odłączenie urządzenia wpiętego do sieci, ewentualne odczytanie adresu MAC z tabliczki znamionowej lub panelu administracyjnego i podłączenie Raspberry Pi do sieci wewnętrznej. dzięki drugiego interfejsu, zadaniem „Maliny” było łączenie się do serwera C2 Mythic poprzez CloudFront. W ten sposób otrzymaliśmy stabilne połączenie, dzięki którego mogliśmy zarządzać urządzeniem zdalnie, w razie potrzeby proxować ruch do środka sieci.

Sprzęt

Na samym początku należy skompletować niezbędny sprzęt. Tu bardziej doświadczeni użytkownicy RPi zarzucą nam rozrzutność, ale my do projektu wybraliśmy bezpiecznie Malinę 4B z 4 GB RAM. Po namyśle stwierdzam jednak, iż RPi z 1GB spokojnie by wystarczyło.

Do tego oczywiście należy zaopatrzyć się w kartę MicroSD, zasilacz (byle nie z czarnej listy!) i obudowę. Do tego projektu wybrana została solidna, aluminiowa obudowa z pasywnym radiatorem.

Konfiguracja Raspberry Pi – modem

Paczki po odebraniu wyglądały na prawdę okazale.

Po wstępnej konfguracji rpi, pierwszym zadaniem jest nawiązać połączenie z siecią Internet dzięki Modemu. W naszym projekcie wykorzystaliśmy modemy ZTE MF821 4G LTE, które dość przyjemnie konfigurowało się z programem wvdial. Generalnie, zalecam stosowanie modemów, które są od razu prawidłowo identyfikowane przez Raspbian OS. Ułatwia to prace i oszczędza nerwów przy ewentualnym szukaniu sterowników.

Prawidłową identyfikację modemu możemy podejrzeć dzięki narzędzia lsusb lub z wykorzystaniem dmesg, które wyświetla logi jądra Linuxa.

W celu zainicjalizowania połączenia za pośrednictwem modemu, wymagany jest program wvdial i odpowiednia konfiguracja pliku /etc/wvdial.conf. W celu wykonania wstępnej, automatycznej konfiguracji, należy wykonać polecenie sudo wvdialconf i poczekać na stworzenie pliku /etc/wvdial.conf

Mimo to, automatyczna konfiguracja nie umożliwiła mi połączenia z Internetem. W moim przypadku konieczne było dodanie linijek Init3 oraz Username i Password, widocznych na poniższym obrazku.

W przypadku operatora Play, powyższa konfiguracja powinna działać u każdego. APN w tym przypadku to wartość „internet” w polu Init3. Play nie definiuje użytkownika oraz hasła, więc brak tych wartości również powinniśmy wskazać dzięki dwóch apostrofów. W celu nawiązania połączenia z Internetem dzięki modemu, należy użyć polecenia sudo wvdial.

W przypadku prawidłowego nawiązania połączenia, pojawi się nowy interfejs sieciowy (ppp) i otrzymamy połączenie z Internetem. W przypadku realnego podłączania maliny do sieci, operator nie będzie w stanie wykonywać powyższych czynności. Nasz backdoor musi być więc zautomatyzowany. Automatyzację możemy osiągnąć poprzez stworzenie serwisu wvdial i uruchomienie go zaraz po podłączeniu modemu GSM.

Stworzenie serwisu ogranicza się do do stworzenia pliku w katalogu /etc/systemd/system/wvdial.service o następującej zawartośći:

[Unit] Description=wvdial [Service] ExecStart=/usr/bin/wvdial Restart=on-failure RestartSec=5

Powyższy serwis należy uruchomić każdorazowo po podpięciu modemu do rpi. Możemy osiągnąć to edytując plik /etc/udev/rules.d/99-com.rules. Dzięki regułom udev możemy definiować zachowanie systemu w przypadku podłączania i odłączania urządzeń sprzętowych. Im wyższa cyfra (w tym przypadku 99), tym niższy priorytet tych działań. Oznacza, iż edytując plik o niskim priorytecie istnieje szansa, iż nie zakłócimy pozostałych, ważnych czynności poodejmowanych przez system. Aby uruchomić nasz serwis przy wpięciu modemu USB należy wprowadzić następującą linijkę

SUBSYSTEM=="tty", KERNEL="ttyUSB2", TAG+="systemd", ENV{SYSTEMD_WANTS}+="wvdial.service"

Modyfikacja pliku 99-com.rules

Konfiguracja Raspberry Pi – Mythic agent

Kolejnym krokiem jest stworzenie pliku Agenta Mythic C2, który będzie umieszczony na naszej malinie i będzie łączyć się z naszym serwerem. Pamiętajmy, aby przy generowaniu payloadu zaznaczyć architekturę ARM64, ponieważ jest to architektura w której pracuje procesor „Maliny”.

Po wygenerowaniu payloadu możemy zignorować pliki pdb przydatne do debugowania i przerzucić plik ELF o nazwie „Agent” na rpi. Po przerzuceniu pliku i przetestowaniu połączenia należy zadbać o niezawodność połączenia i jego wznowienie w przypadku restartu stacji, „ubicia” procesu itp. Do tego celu wykorzystany będzie cron oraz prosty skrypt w bashu.

#!/bin/bash # Check if agent is running if ! pgrep -f "/home/dave/Desktop/New/Agent" > /dev/null; then # jesli nie działa - wystartuj /home/dave/Desktop/New/Agent & fi

Tak przygotowany skrypt dodajemy do crontaba użytkownika systemowego, tak aby był uruchamiany z wysokimi uprawnieniami, co 5 minut.

Po uruchomieniu Raspberry Pi i umieszczeniu modemu w gnieździe USB, po chwili można zaobserwować pojawiający się beacon Mythic w panelu C2.

Po otrzymaniu beaconu, należy wpiąć drugi interfejs sieciowy urządzenia RPI do sieci. Następnie za pośrednictwem Mythica należy włączyć shell /bin/bash, a następnie uruchomić polecenie tcpdump -i eth0, aby podejrzeć ruch sieciowy na interfejsie Ethernet.

Jak widać na powyższym zrzucie ekranu, ilość pakietów które dochodzą do niezaadresowanego interfejsu Ethernet jest na tyle duża, iż jesteśmy w stanie:

odgadnąć podsieć w której się znajdujemy
zidentyfikować aktywne hosty w sieci

Po analizie ruchu sieciowego nie pozostaje nam nic innego jak tylko zaadresować interfejs ETH0 i cieszyć się dostępem do sieci wewnętrznej testowanej organizacji z zewnątrz.

Co można zrobić lepiej?

Powyższe podejśćie do tematu stwarza kilka ryzyk:

Brak OPSEC w przypadku odnalezienia urządzenia
Ryzyko zaalarmowania działu IT poprzez niedziałające pierwotne urządzenie (patrz 1 Rys)
Ryzyko niepowodzenia operacji w przypadku white-listy urządzeń po adresach MAC
Ryzyko niepowodzenia operacji w przypadku zastosowania zabezpieczeń typu 802.1X

W zasadzie pierwsze trzy zagrożenia są możliwe do mitygacji przy mniejszym lub większym nakładzie pracy. Raspberry PI można próbować zabezpieczyć przed potencjalnym forensiciem. Zachowanie funkcjonalności pierwotnego urządzenia mogłoby wymagać dodatkowej karty sieciowej i stworzenia bridge pomiędzy drukarką a switchem i wykorzystanie routingu warstwy 2 dzięki Ebtables. Innym pomysłem (pozdrawiam zdolną młodzież) może być wykorzystanie OpenWRT na urządzeniu zamiast RPi OS.

Jedynym przeciwnikiem którego w tym przypadku niezwykle trudno byłoby pokonać może być protokół 802.1X, do którego korzystania gorąco zachęcam w sieciach korporacyjnych. Bo czy ktoś byłby w stanie zauważyć taką małą kostkę, ukrytą między kablami, wewnątrz drukarki lub (co gorsza!) w podłodze technicznej?