Nabyłem sobie ostatnio nowy router WiFi (TL-WR340GD), bo z realizowania access pointa za pomocą OpenBSD ostatecznie zrezygnowałem (bo miałem z tym problemy). W zasadzie wystarczyłby mi zwykły AP a nie router, ale zależało mi na wbudowanym w urządzenie switchu. I w sumie ten post by nie powstał, gdyby nie drobna inspiracja: DEFCON preview: Netgear RP614 CSRF attack video.
TL-WR340GD CSRF i XSS
Temat Cross Site Request Forgery poruszałem między innymi na Bootcamp, a konkretnie w Bootcamp: Cross Site Request Forgery oraz Bootcamp: Cross Site Scripting i Cross Site Request Forgery.
Po interfejsie WWW routera, który jest właściwie aplikacją webową, nie spodziewałem się zbyt wiele, w szczególności wysokiego bezpieczeństwa. I nie zawiodłem się. Zgodnie z przewidywaniami przez CSRF mogę zrobić z routerem praktycznie wszystko, poza jedną rzeczą - zmianą hasła administratora, a to dlatego, że trzeba podać obecne hasło (no dobra, można próbować zgadnąć).
Skoro podałem link do filmiku, to w ramach demonstracji zrobię to samo co w filmiku, czyli włączę funkcję Remote Management.
By włączyć funkcję wystarczy podać port, na którym konsola ma nasłuchiwać i adres IP, z którego ma być możliwość zarządzania, lub 255.255.255.255 by umożliwić zarządzanie z dowolnego adresu IP. Żądanie wysyłane przez przeglądarkę do routera wygląda tak:
GET /userRpm/ManageControlRpm.htm?port=80&ip=0.0.0.0&Save=Save HTTP/1.1
Jak widać wystarczy przesłać odpowiednie parametry, brak jest żadnego tokena, który przed CSRF by bronił. W tym wypadku wystarczy jako wartość parametru ip wysłać 255.255.255.255.
Analogicznie sytuacja wygląda również dla innych operacji:
GET /userRpm/NetworkLanCfgRpm.htm?lanip=192.168.1.1&lanmask=255.255.255.0&Save=Save HTTP/1.1 GET /userRpm/MacCloneCfgRpm.htm?mac1=00-25-ED-37-21-1E&wan=1&Save=Save HTTP/1.1 GET /userRpm/SysRebootRpm.htm?Reboot=Reboot HTTP/1.1 GET /userRpm/RestoreDefaultCfgRpm.htm?Restorefactory=Restore HTTP/1.1
Powyższe przykłady dotyczą zmiany konfiguracji sieci, klonowania adresu MAC, restartu urządzania oraz przywrócenia ustawień domyślnych.
Jeśli ktoś to ciekawi, całość jest na najnowszym (z tego co wiem) firmware: 4.2.1 Build 090106 Rel.56881n.
By atak zadziałał, użytkownik musi być uwierzytelniony do urządzenia, choć ciekawy jestem jak wielu użytkowników zapamiętuje hasło w przeglądarce, w związku z czym warunek wcześniejszego świadomego zalogowania się użytkownika może zostać pominięty. Drugi niezbędny warunek to znajomość adresu, pod jakim interfejs administracyjny jest dostępny, trzeba w końcu gdzieś te żądania wysłać. Ciekawe ilu użytkowników korzysta z urządzenia w konfiguracji domyślnej... Zresztą teoretycznie to problem ten można akurat obejść wykorzystując choćby technikę "przeglądania" historii przeglądarki (patrz: http://www.startpanic.com/).
Jakby tego było mało, to mamy również XSS w funkcji Domain Filtering, można tam osadzić XSS, choć pewnym problemem jest ograniczenie długości pola do 30 znaków. Te 30 znaków jednak może w zupełności wystarczyć, by dołączyć zewnętrzny skrypt (przez script src), który kodu może zawierać już znacznie więcej. Dlatego warto mieć na podorędziu jakąś krótką domenę...
By było śmieszniej, takiego XSS można osadzić przez CSRF...
Nie testowałem tego interfejsu dokładnie. Istnienie podatności CSRF można było zakładać w ciemno po wyglądzie żądań. Podatności na CSRF w zasadzie się nie szuka. To się widzi.
XSS też jest w intuicyjnym miejscu - kontrolowane przez użytkownika dane są wypisywane w kontekście HTML (zresztą wcześniej również w kontekście JavaScript, ale to nie jest istotne). Walidacji danych nie ma. O przepraszam, jest. Po stronie klienta oczywiście. A nazwa domeny nie jest polem o bardzo określonym formacie, takim jak adres IP czy adres MAC, więc była ciekawym kandydatem. Okazało się, że słusznie wytypowanym...
Zweryfikuje zaraz wszystko