Uwaga na NASy od D-Linka – umożliwiają wykonanie komend

Jeśli jesteście właścicielami starszego modelu urządzenia typu NAS firmy D-Link, przeczytajcie koniecznie – nie mamy dla Was dobrych wiadomości. 

Nowy użytkownik GitHuba netsecfish (konto założone dwa tygodnie temu, posiadające jednego obserwującego oraz trzy publiczne repozytoria) udostępnił informację o podatności dotykającej wielu starszych urządzeń D-Linka z linii dysków sieciowych. Luka sklasyfikowana jest pod numerem CVE-2024-3273 i – jak czytamy w pliku README.md repozytorium – dotyczy następujących urządzeń:

• DNS-320L Version 1.11, Version 1.03.0904.2013, Version 1.01.0702.2013
• DNS-325 Version 1.01
• DNS-327L Version 1.09, Version 1.00.0409.2013
• DNS-340L Version 1.08

Bazując na zaprezentowanym wyniku z wyszukiwarki FOFA (chińska alternatywa dla shodan.io), obecnie do sieci podłączonych jest przeszło 92k urządzeń, które mogą być podatne. To całkiem sporo, dodatkowo dotknięte urządzenia mają status End of Life (EoL) (to znaczy, że nie należy oczekiwać wydania aktualizacji), więc zalecamy ich jak najszybszą wymianę. Wystawienie NASa do sieci Internet samo w sobie może nie być najlepszym pomysłem, dlatego jeśli nie ma innej możliwości (wymiana, zmiana software, wyłączenie) zalecamy wyizolowanie środowiska z podatnymi urządzeniami oraz ograniczenie dostępu do nich.  

Podatność została nazwana backdoorem, co mogłoby implikować celowe umieszczenie jej w aplikacji. Według nas, bardziej prawdopodobne jest przeoczenie, które pozwoliło na wykonywanie komend na urządzeniu z wykorzystaniem poświadczeń na sztywno umieszczonych na urządzeniu. 

Autor znaleziska wskazuje, że błąd występuje w pliku nas_sharing.cgi, CGI (Common Gateway Interface) to mechanizm pozwalający na uruchamianie, przez serwer WWW, zewnętrznych skryptów i programów do przetwarzania zapytań. Jest to bardzo stara metoda, do dzisiaj spotykana między innymi w urządzeniach sieciowych takich jak routery konsumenckie oraz właśnie dyski sieciowe. Wyzwolenie błędu możliwe jest przez dokonanie poniższego zapytania:

Po ostatniej dramie z xz byliśmy ciekawi jak został zaimplementowany ten backdoor. Sprawdziliśmy więc na obrazie firmware dla urządzenia DNS-340 w wersji 1.08. Samo firmware można pobrać stąd. Po rozpakowaniu archiwum oczom okazuje się dokumentacja oraz zapakowany w kolejnego ZIPa plik binarny zawierający obraz squashfs zawierający interesujące nas pliki. Firmware może zostać rozpakowane przy pomocy narzędzia binwalk:

W katalogu z suffixem .extracted znajduje się rozpakowany obraz oraz interesujący nas katalog z zawartością skompresowanego filesystemu; squashfs-root. 

W rozpakowanym obrazie, w katalogu cgi, rzeczywiście znajduje się plik o nazwie nas_sharing.cgi, będący linuxowym ELFem (Executable-Linkable Format) czyli binarnym plikiem wykonywalnym, skompilowanym na architekturę ARM. Dodatkowo jak przystało na produkcyjną wersję, binarka jest ostrippowana (nie zawiera informacji symboli, dodaktowych informacji debugera). 

> file nas_sharing.cgi

Szybka analiza w Ghidrze pozwala określić, gdzie dokładnie występuje błąd. Po pierwsze, w funkcji cgiMain parsowany jest parametr cmd:

Następnie w zależności od wartości tego parametru wybierany jest sposób obsługi żądania. W przypadku tej podatności jest to wartość 15, czyli 0xf hex. Wykonanie programu przenosi się do funkcji FUN_00019108().

W kolejnym kroku pobierane są informacje dotyczące nazwy użytkownika oraz hasła z parametrów żądania HTTP. Ich weryfikacja następuje przez wywołanie funkcji w linii 22. 

W funkcji roboczo nazwanej verifyPwd, program sprawdza czy nazwa użytkownika jest zgodna z założeniami, następnie dekodowane jest hasło (które w przypadku niepustego ciągu będzie stringiem zakodowanym z wykorzystaniem base64). 

Na listingu 6. w linii 30, polecenie przesłane przez użytkownika trafia do wywołania funkcji system, co prowadzi do wykonania komendy na urządzeniu. Polecenie jest przesyłane w formie zakodowanej base64, proces odwrotny jest wykonywany w funkcji FUN_0001dd88, która po prostu korzysta z __b64_pton. 

W linii 37 wczytywany jest plik /etc/shadow, który zawiera hashe haseł użytkowników. Następnie przy wykorzystaniu POSIXowej funkcji fgetpwent pobierane są kolejne wpisy, które są następnie umieszczane w strukturze passwd. W momencie natrafienia na pasujący (linia 45) login pętla przechodząca po wpisach w /etc/shadow jest kończona i pozostaje dokonać sprawdzenia hasha hasła w linii 50 (hash jest liczony przez funkcję FUN_0001e160 wywołującą crypt). 

W pliku /etc/shadow oraz /etc/passwd nie natrafiliśmy na użytkownika messagebus, jednak wyszukanie tego ciągu znaków w katalogu z firmware pozwoliło na ustalenie, że jest to użytkownik dodawany przez jeden ze skryptów, a mianowicie script/rc.messagebus.

Sama usługa messagebus, jest odpowiedzialna za broadcast komunikatów dotyczących zdarzeń systemowych. Na listingu 9 został przedstawiony fragment stworzenia tego użytkownika z pustym hasłem. 

Sam skrypt rc.messagebus jest uruchamiany na początku pracy NASa przez skrypt inicjalizacyjny system_init.

To krótkie dochodzenie pokazuje, że wynikiem powstania błędu jest to, że w systemie pojawia się użytkownik z pustym hasłem. Następnie ta informacja jest wykorzystywana przy uwierzytelnianiu użytkowników wykonujących polecenia przy pomocy interfejsu WWW. Luka jest trywialna i chociaż historii jej powstania pewnie nigdy nie poznamy, można domniemywać, że jest ona wynikiem rozwoju aplikacji przez oddzielne zespoły, które niekoniecznie miały szerszą świadomość sytuacyjną i osoby odpowiedzialne za usługę messagebus nie były świadome, że użytkownik, którego dodają do systemu bez hasła, może zostać wykorzystany w innym miejscu. Raczej nie jest to celowo wprowadzony backdoor – a jeśliby tak było, to jest to zrobione bardzo nieudolnie i łatwe do znalezienia. 

Reasumując, nie ma co liczyć na aktualizację od producenta, dlatego zalecamy wyłączenie podatnych urządzeń, zmianę firmware (jeśli to możliwe) oraz nieeksponowanie podatnych urządzeń w sieci publicznej. Na ten moment w Polsce jest publicznie dostępnych kilkaset takich urządzeń. Administratorów uczulamy i zachęcamy do podjęcia błyskawicznych kroków, ponieważ luka ta ma potencjał na bycie wykorzystywaną w zautomatyzowanych kampaniach.

~fc