Przejął system MDM, zarządzający urządzeniami mobilnymi pracowników Facebooka. RCE bez uwierzytelnienia na popularnym MDM-ie MobileIron.

Jeśli Orange Tsai coś napisze, to jest to od razu uderzenie z Grubej Berty ;-) Tym razem mamy opis podatności klasy unauthenticated RCE w systemie MDM MobileIron.

Dla przypomnienia systemy klasy Mobile Device Management to klucz do królestwa urządzeń mobilnych w całej firmie. Z jednej strony to właśnie w tym miejscu definiuje się, co użytkownicy mogą robić na swoich telefonach, jakie oprogramowanie instalować czy jakie funkcje (typu Bluetooth) mają włączone. Z drugiej strony – mamy admina na MDMie – mamy przejęte wszystkie urządzenia mobilne! Tak zresztą od czasu do czasu się dzieje i hackerzy przejmują tego typu systemy, o czym pisaliśmy niedawno:

After gaining access to the customer’s MDM, the attacker utilized the MDM’s ability to install applications remotely to install malware on more than 75% of the company’s devices.

Wracając do samego researchu – badacz wziął na warsztat komercyjne rozwiązanie MobileIron, w którym do tej pory nie było zbyt wielu zlokalizowanych bugów…Komercyjne oprogramowanie, więc nie będzie dostępnej prosto jego binarki czy źródeł? Błąd – stosując proste techniki rekonesansu (zapraszamy w tym miejscu na nasze szkolenie z reconu – będzie też o tego typu „kwiatkach”) zlokalizował dostępne publicznie rpm-y:

recon

Po wstępnej analizie udało się zlokalizować podatność związaną z deserializacją dowolnych danych przesłanych przez atakującego (skutkuje to najczęściej możliwością wykonania wrogiego kodu na serwerze). Jednak podatne miejsce znajduje się w API, które normalnie nie jest dostępne (wymuszane jest to w regule na serwerze http Apache):

Jeśli jednak w backendzie znajduje się Tomcat (a tak jest w tym przypadku), istnieje pewien trick na ominięcie takiego zabezpieczenia. Sam badacz pokazał to swego czasu na przykładzie Ubera. Tutaj jedynie URL /status był dostępny publicznie, jednak Tomcat, do którego finalnie zostanie wysłany URL poniżej, stwierdził że /..;/ jest katalogiem rodzicem (Apache czy NGNIX uważa że jest to zwykły katalog):

ominięcie filtru

W przypadku MobileIron wystarczył taki trick: https://mobileiron/mifs/.;/services/someService

Dodanie średnika powoduje, że Apache traktuje to jako „normalny” katalog, podczas gdy Tomcat uzna to po prostu jako katalog bieżący (czytaj, usunie ten fragment, zapewniając dostęp do odpowiedniego serwisu).

Z drugiej strony Apache blokuje wszystko w ścieżce: /mifs/services, ale tutaj mamy nie /mifs/services, a /mifs/.;/services ;-) Zatem dostęp jest dawany bez uwierzytelnienia.

Swoją drogą, na podobnym tricku bazowała niedawna podatność klasy unauth RCE na urządzeniach F5.

URL wyglądał w przypadku F5 tak:

Komentarz: logowanie przecież musi być dostępne bez uwierzytelnienia dla wszystkich, ale jeśli URL dojdzie do Tomcata, ten stwierdzi że /..;/ – to katalog wyżej, więc usunie login.jsp i realnie odwołamy się (bez uwierzytelnienia!) do fileRead.jsp.

Wracając do sedna, jeden (z osiągalnych już) serwisów przyjmował dane do deserializacji w formacie Hesjan. Wystarczyło więc przygotować odpowiedni payload deserializacji i voila:

Badacz zgłosił najpierw podatność do producenta. Później monitorował niezałatane instancje MDM-a dostępne w Internecie (cały czas około 40% wszystkich jeszcze nie jest załatana). Wśród celów był również Facebook (MobileIron dostępny był pod domeną: http://vsp.fb.com/). Po 15 dniach od wypuszczenia łaty Facebook dalej nie załatał podatności – więc Orange Tsai odpalił exploita uzyskał shella na serwerze MDM Facebooka oraz zgarnął bug bounty.

–Michał Sajdak