Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Jak wykorzystałem podatność log4shell (CVE-2021-44228) w kontrolerze WiFi od Ubiquiti. PoC:
Naszym dzisiejszym bohaterem jest to urządzenie: Cloud Key Gen2 Plus. Nazwa trochę dziwna, ale jest to znany wszystkim użytkownikom rozwiązań firmy Ubiquiti kontroler WiFi (ma również funkcję zapisu feedów z kamer). Całość w eleganckiej formule sprzętowej, z 1TB dyskiem oraz podtrzymywaniem bateryjnym (tj. „na czysto” się wyłącza w momencie ewentualnego zaniku prądu):

Znane jest wykorzystanie podatności log4shell na ekranie logowania, dostępnym w wybranych rozwiązaniach Ubiquiti, jednakże u mnie endpoint /api/login z jakiegoś powodu był niedostępny.
Zatem trzeba zakasać rękawy i wymyślić coś innego. Zaczynamy: logowanie przez ssh na moje urządzenie oraz poszukanie log4j (jak widać mamy tutaj podatną wersję).

OK, ale na jakich portach nasłuchuje java?

Jak widać jest tego trochę… próbowałem na początek znaleźć coś ciekawego na 8080 TCP – ale niestety bez efektu. Nieco później kolej padła na port 5514 UDP, gdzie działa serwer syslog (dlaczego w javie? nie pytajcie :)
Spróbujmy więc wysłać coś do urządzenia (nie wymaga to uwierzytelnienia):

I zobaczmy co się zapisuje w logach (katalog: /usr/lib/unifi/logs/remote):

W skrócie – wygląda to (nie)dobrze! Spróbujmy zatem uderzyć z grubej rury:
Odpalenie exploitu / serwera (nota bene – na urządzeniu zainstalowany jest netcat, więc czemu z niego nie skorzystać do reverse shella? :-)

Na urządzeniu mamy ustawienie trustURLCodebase na false (takie jest w nowszych javach, to było jedno z pierwszych zaleceń dotyczących ew. łatania luki – jak już wiemy – błędne).
Ale wróćmy do wysłania dość specyficznej informacji do logów:

Daje to taki efekt w logach na urządzeniu (co akurat jest mało ważne z punktu widzenia działania exploitu, ale może mieć wartość poznawczą)

Nasz exploit-serwer przyjął połączenie wykorzystujące RMI:

Które następnie spowodowało zestawienie sesji połączeniem wychodzącym do czekającego spokojnie netcata (reverse shell):

Podatność jest już załatana przez producenta (należy zaktualizować komponent Network apps). Pamiętajcie żeby tego typu technik używać etycznie, tylko za pozwoleniem właściciela danego systemu IT.
~Michał Sajdak
Fajna znaleziona podatność. Ciekawe czy Michał Sajdak znajdzie kiedyś też czas na rozwiązanie konkursu na najlepszy artykuł, który trwał do czerwca zeszłego roku i od tego czasu nie ma znaku życia.
Ale jest to podatność w nieaktualny firmware, w najnowszym juz to załatwili
Czytałeś ostatnie zdanie wpisu? :-)
@sekurak
Przedostatnie ;)