Obraz w głowie programisty, czyli CVE-2021-40866

Jedną z metod, które używam do znalezienia błędów bezpieczeństwa jest czytanie dokumentacji. A konkretniej, szukanie w niej miejsc, w których programista implementujący daną rzecz mógłby uznać, że coś na pewno będzie miało miejsce, „bo tak każe dokumentacja”. I o ile tego konkretnego błędu, który sprowokował powstanie tego artykułu, nie znalazłem w ten sposób, to mogę się założyć, że jego geneza wywodzi się właśnie z założenia, że świat dostosuje się do tego „co kazała dokumentacja”.

We wrześniu 2021 roku odkryłem błąd w firmware niektórych urządzeń sieciowych firmy NETGEAR, który, zgodnie z moim poczuciem humoru nazwałem za pomocą generatora nazw zespołów metalowych – Demon’s Cries (CVE-2021-40866). W zasadzie bardziej adekwatne byłoby stwierdzenie, że go „ponownie odkryłem”, ponieważ jak się okazało, błąd był już znany od 2012 roku, choć dotyczył innych modeli urządzeń sieciowych. Co zabawne, podatność była traktowana jako ficzer, który przydawał się adminom do resetowania haseł w razie, gdyby ich zapomnieli.

Demon’s Cries dotyczył serwisu Smart Control Center, oraz obsługiwanego przez niego protokołu NETGEAR Switch Discovery Protocol (NSDP). Serwis ten de facto udostępniał informacje o konfiguracji switcha oraz pozwalał – jeśli się znało hasło administratora – zmienić konfigurację wedle uznania. Przyznaję, że jestem fanem analizowania „chałupniczych” protokołów tego typu, tj. takich stworzonych na szybko, przez inżynierów, bez zbędnych rozważań na temat bezpieczeństwa – zawsze znajdzie się w nich coś ciekawego.

Sam NSDP jest binarnym protokołem używającym datagramów UDP do transportu pakietów i składa się z nagłówka, po którym następuje seria „poleceń” w postaci TLV (type/length/value) – całość Big Endian.

Nagłówek:

Offset    Typ      Opis

0         byte     wersja (1)

1         byte     polecenie (1 lub 3)

2         word     status

4         word     kod błędu

6         word     reserved

8         byte[6]  adres MAC menedżera

0xe       byte[6]  adres MAC urządzenia

0x14      dword    numer sekwencyjny

0x18      string   magic "NSDP"

0x1C      dword    reserved

TLV:

Offset    Typ      Opis

0         word     typ

2         word     długość danych

4         byte[]   dane

Pole „polecenie” w nagłówku przyjmuje wartość 1 lub 3, w zależności od tego czy chcemy odczytać informacje o konfiguracji (1), czy zmienić ustawienia urządzenia (3).

I teraz dochodzimy do mojej hipotezy z początku artykułu. Tj. coś mi mówi, że gdzieś w dokumentacji dostępnej programiście implementującemu protokół NDSP był jakiś paragraf tego typu:

W przypadku zmiany konfiguracji (polecenie=3) pierwszym TLV w serii jest TLV uwierzytelniający (typ=10). Podczas uwierzytelniania, w przypadku podania błędnego hasła, przetwarzanie reszty pakietu MUSI zostać przerwane/zakończone.

Co za tym idzie, w pakiecie UDP po nagłówku powinien być TLV z hasłem administratora, a za nim powinna być seria kolejnych TLV mówiących o tym, co przekonfigurować:

[nagłówek(polecenie=3)]

[TLV(10→uwierzytelnienie): hasło "alamakota"]

[TLV(3→zmiana nazwy urządzenia): nowa nazwa "switch 17"]

[TLV(7→zmiana maski): nowa maska 255.255.255.0]

[TLV(0xffff): koniec TLV]

Całość ma oczywiście sens – ponieważ pierwszym TLV musi być polecenie uwierzytelnienia, to już na tym etapie możemy – w przypadku nieprawidłowego hasła – odrzucić resztę pakietu UDP. A jeśli hasło było dobre, to możemy dalej przetworzyć resztę pakietu i przekonfigurować urządzenie wedle życzeń administratora.

Problem polega na tym, że niestety konkluzją z powyższych rozważań jest również: skoro TLV uwierzytelniający był pierwszym poleceniem w serii, to przy obsłudze kolejnych TLV wiemy, że administrator jest już uwierzytelniony. Bo w końcu gdyby „administrator” podał złe hasło, tj. uwierzytelnienie by się nie powiodło, to reszta pakietu byłaby odrzucona, a wykonanie nigdy by nie dotarło do obsługi kolejnych TLV w serii.

I na to wszystko przychodzi hacker, który zapomniał przeczytać dokumentację (lub gorzej! nie uszanował tego, co tam było napisane!), i wysyła pakiet w ogóle bez uwierzytelniającego TLV – a więc nigdy w ogóle nie dojdzie do wykonania kodu, który miałby szansę sprawdzić hasło i odrzucić resztę pakietu:

[nagłówek(polecenie=3)]

[TLV(10→uwierzytelnienie): hasło "alamakota"]

[TLV(9→zmiana hasła): nowe hasło "thanksNDSP!"]

[TLV(0xffff): koniec TLV]

Błąd można sprowadzić do prostego „programista zapomniał o autoryzacji”, ale to jest zbyt niskopoziomowy wniosek. Domniemany błąd faktyczny był raczej w dokumentacji, która sprawiała, że czytająca ją osoba miała w głowie jedynie prawidłową maszynę stanów, a nie maszynę stanów, która w praktyce była możliwa:

Wnioski na koniec są dwa:

Po pierwsze, tworząc dokumentację musimy pamiętać zarówno o kwestiach związanych z bezpieczeństwem, jak i o tym jaki obraz rysujemy w głowie czytającego.

Po drugie, podczas badań bezpieczeństwa zawsze warto wejść głęboko w detale implementacyjne protokołów – bardzo często znajdzie się tam coś ciekawego.

~Gynvael Coldwind

HexArcana