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ę...
![](http://static.mroczna-zaloga.org/tplink-xss.png)
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