15-letnia luka 0day w Makach: root dla każdego szkodnika, a łatki wciąż brak

Nowy rok zaczyna się dla Apple bardzo starym bugiem. Podatnośćwystępująca w systemie macOS (który nazywał się wtedy jeszczeMac OS X) od przynajmniej 15 lat, została wykorzystana przez hakerao pseudonimie s1guza do zbudowania exploitu, pozwalającego nazdobycie uprawnień administratora przez dowolny nieuprzywilejowanyproces. Twórcy złośliwego oprogramowania na Maka mogą byćzadowoleni – w Sieci pojawił się nie tylko gotowy exploit, aleteż i kompletna dokumentacja luki. Apple jak to Apple milczy, pókico łatki brak.

Jeden mały, brzydki błąd, popełniony w czasie, gdy Makikorzystały jeszcze z architektury PowerPC. Zapewne tygodnie męczącejpracy i niezwykła chęć jej udokumentowania – rzadko się zdarzaatak tak dokładnie udokumentowany, jak zrobiłto Siguza. IOHIDFamily to rozszerzenie kernela, które dostarczaabstrakcyjny interfejs dla urządzeń interfejsu użytkownika (HID).Rozszerzenie to występuje zarówno w macOS-ie jak i iOS-ie, jednakna Maku jest obszerniejsze. Zawiera klasę o nazwie IOHIDSystem, wktórym właśnie znalazła się podatność.

W ogromnym uproszczeniu można powiedzieć, że wspomniana klasazawiera trzy klienty użytkownika, z których jeden, IOHIDUserClient,ma ogromne uprawnienia w systemie, a podczas normalnej pracy możewystępować tylko jedna jego instancja, sterowana przezWindowServer, czyli systemowy komponent rysujący wszystko co widzimyna ekranie. Cały ten system oferuje pewną ilość pamięci nakolejkę wydarzeń i dane związane z kursorem, które możeprzekazać do przestrzeni adresowej WindowServera. Mamy oczywiściefunkcje do zarządzania tą pamięcią, a jedna z nich,IOHIDSystem::initShmemsłuży do czyszczenia i inicjalizacji struktur danych. I to ona jestszczególnie interesująca, można bowiem zmieniać w niej wartośćglobalnego offsetu i zmusić wskaźnik by wskazywał gdzie indziej,niż zamierzano.

Zbudowanie exploita nie było trywialne – choćby dlatego, żeWindowServer trzyma sobie jedyną dostępną instancjeIOHIDUserClienta i trzeba mu ją wykraść. Co więcej, trzeba byłozrobić to tak, by nie potrzebować do tego roota. Haker odkryłjednak, że WindowServer na chwilę puszcza swojego klienta, wmomencie wylogowania użytkownika z systemu. Można więc wymusićwylogowanie i w tym momencie mamy już naszego klienta i manipulujemyjego pamięcią. Ale wciąż przecież trzeba być użytkownikiem, bysię wylogować – czy nie można zrobić tego lepiej?

Fuck it, dropping a macOS 0day. Happy New Year, everyone. https://t.co/oG2nOlUOjk

— Siguza (@s1guza) December 31, 2017Najwyraźniej można. Któryś z programistów macOS-a popadłbowiem w chwilowe szaleństwo, oprogramowując zachowanie okienkadialogowego potwierdzającego chęć wylogowania. Okienko to w ogólenie weryfikuje skąd przyszło żądanie wylogowania, więc wylogowaćsię może każdy proces, nawet jakieś nobody – wystarczy do tegojeden wiersz AppleScriptu.

Trzecia metoda to stworzenie programu, który działając sobie wtle, czeka na sprzyjające warunki, w końcu użytkownik swojego Makawyłączy lub zrestartuje. W tym właśnie momencie złośliwy kodmoże sobie porwać potrzebnego mu IOHIDUserClienta.

Mając już dostęp, s1guza poeksperymentował z różnymimetodami uszkadzania pamięci i analizowania jej zawartości. W gręwchodzi tu spora struktura – od macOS-a 10.12.0 do 10.13.1 idziecałe dwa gigabajty RAM. Między Sierrą a High Sierrą występowałypewne różnice, ale udało się w końcu znaleźć sposób nazmaksymalizowanie szansy wylądowania tam, gdzie pamięć zostałazmodyfikowana za pomocą przeróżnych sztuczek ze wspomnianąfunkcją IOHIDSystem::initShmem.

IOHIDeous Udostępniony przez hakera exploit składa się z trzech elementów: – poc (make poc): celuje we wszystkie wersje macOS-a, zawieszając kernel by wykazać istnienie uszkodzenia pamięci, – leak (make leak): celuje w macOS-a High Sierra, by udowodnić że nie potrzeba tu specjalnego obejścia KASLR, – hid (make hid): celuje w macOS-a Sierra i High Sierra, zapewniając pełen dostęp do systemu i wyłączając System Integrity Protection, by pokazać, że nieuprzywilejowany użytkownik może zrobić to wszystko.

Pozostaje jeszcze poradzić sobie z zabezpieczeniami samegokernela (KASLR) – co już samo w sobie było niezłym wyczynem.Proces ten zajmuje 12 kroków, prowadzących do zbudowania fałszywegozadania pod określonym adresem i zmuszenia portu zadań kernela dojego odczytania. Kolejną częścią układanki jest atak ROP(Return-oriented programming), który prowadzi do uzyskania roota, anastępnie podłączenie portu zadań kernela do przestrzeniużytkownika, zainstalowanie powłoki z uprawnieniami roota iwyłączenie obsługi podpisów plików wykonywalnych oraz blokadymodyfikacji plików systemowych. Efekt? macOS przechodzi pod pełnąkontrolę napastnika. Jedyną pociechą jest to, że nie jest to atakzdalny, exploit musi znaleźć się na maszynie ofiary.

Wraz z rosnącą popularnością Maków takich starych luk wsystemie znajdzie się pewnie jeszcze więcej. System Apple’awydaje się ogromnie skomplikowany, jest w nim pełno „ruchomych”części… a to oznacza, że wiele można w tym wszystkim popsuć.Użytkownikom można jedynie poradzić, by korzystali z antywirusówi nie uruchamiali oprogramowania z podejrzanych źródeł. Jak widaćpo tym ataku 0day, jedno kliknięcie w może doprowadzić to tego,że wasz komputer przestanie należeć do was.