Eskalacja uprawnień – CVE-2024-37726

how2hax.pl 3 dni temu

Cześć! Dzisiejszy wpis będzie poświęcony ciekawej technice eskalacji uprawnień z wykorzystaniem systemu MSI Center. Podatność jest całkiem świeża, pochodzi z lipca bieżącego roku. Celem tego artykułu jest opis podatności, ale również szerzej – analiza eskalacji uprawnień z wykorzystaniem operacji na plikach wykonywanych przez aplikacje, które działają z wysokimi uprawnieniami.

Bazą do analizy podatności będzie repozytorium carsonchan12345 z exploitem.

Wstęp

Aplikacja MSI Center to oprogramowanie tworzone przez (niespodzianka!) firmę MSI. Jej celem jest pomoc użytkownikowi w monitorowaniu i zarządzaniu sprzętem tej firmy, optymalizacja wydajności, zarządzanie sterownikami itp. Typowa autorska aplikacja, jakich wiele, mająca swoje odpowiedniki wśród innych producentów takich jak Dell, Asus itp.

Aplikacja jest dostępna na oficjalnej stronie producenta, a link do aplikacji prowadzi do sklepu Microsoft¹.

Operacje na plikach z wysokimi uprawnieniami

Jedną z opcji programu jest export informacji o systemie do pliku txt. Możemy tego dokonać poprzez zakładkę Support, wybierając odpowiedni przycisk.

Co ciekawe, eksport tych informacji jest wykonywany z wysokimi uprawnieniami:

Operacje na plikach z wysokimi uprawnieniami

Podsumowując – nieuprzywilejowany użytkownik może wywołać operację na wybranym przez siebie pliku z uprawnieniami NT Authority\SYSTEM. Taka sytuacja jest zawsze interesująca z punktu widzenia atakującego / badacza, ponieważ niesie to ryzyko np. przekierowania operacji do innego pliku z wykorzystaniem linków symbolicznych. Opisywałem już tę technikę w jednym z moich pierwszych wpisów na blogu.

Zawartość tworzonego pliku

Wśród informacji o systemie takich jak:

Wersja BIOSu
Karta graficzna
Procesor
Poprawki Windows

znajduje się tam jeszcze lista zainstalowanych przez nas programów:

Schemat ataku

Logiczny schemat ataku wygląda następująco:

Program MSI Center usiłuje zapisać informacje o systemie w pliku C:\users\public\test\test.txt. W tym momencie uruchamiany jest OPLOCK (zablokowanie dostępu do pliku) oraz tworzony jest link symboliczny, który wskazuje z C:\users\publoc\test\test.txt na plik C:\programData\Microsoft\Windows\Start Menu\Program\Startup\eop.bat.

W kolejnym kroku zwalniamy Oplock, a program zapisuje informacje o systemie w pliku C:\programData\Microsoft\Windows\Start Menu\Program\Startup\eop.bat, do którego normalnie nie mamy możliwości pisać:

Ale co nam to da?

Uważny czytelnik zastanawia się pewnie co nam to da, skoro aplikacja eksportuje po prostu dane o systemie, takie jak karta graficzna, zainstalowane programy itp. choćby o ile tworzymy skrypt bat, to nie ma tam żadnego skryptu! W tej sytuacji powinniśmy zastanowić się na jakie elementy eksportowanych danych mamy wpływ jako nieuprzywilejowany użytkownik. Jedną z możliwości jest zainstalowanie „Pustego” programu o określonej przez nas nazwie, która będzie prawidłowym skryptem bat. Jako użytkownik nieuprzywilejowany możemy instalować pewne programy bez podnoszenia uprawnień. Posłużymy się w tym celu programem WiX, za pomocą którego stworzymy plik msi, który zainstaluje program o odpowiedniej nazwie, bez uprawnień administracyjnych:

WIX tworzy gotową paczkę MSI, którą możemy zainstalować bez uprawnień administratora, tworząc skrypt instalacyjny z atrybutem Scope=PerUser

<Package Name="Test Program t& calc.exe &" Version="1.0.0.0" Manufacturer="YourCompany" UpgradeCode="3f2504e0-4f89-11d3-9a0c-0305e82c3301" InstallerVersion="200" Scope="perUser"> ```

Po zainstalowaniu programu, możemy zweryfikować, iż program MSI Center umieszcza nazwę w eksportowanym pliku.

Eskalacja uprawnień

Świetnie, jesteśmy gotowi do eskalacji uprawnień.

W pierwszej kolejności ustawiamy oplock na pliku C:\users\public\test\test.txt

Ustawienie oplocka

Kolejnym krokiem jest utworzenie symlinku, co należy wykonać w dwóch krokach:

katalogA -> \RPC CONTROL\ – WYKORZYSTANIE NTFS JUNCTION

\RPC CONTROL\plikA -> katalogB\plikB – WYKORZYSTANIE SYMBOLICZNEGO DOWIĄZANIA

katalogA to katalog C:\users\public\test
plikA to plik test.txt
katalogB to C:\programData\Microsoft\Windows\Start Menu\Program\Startup\
plikB to eop.bat

Problem – katalog C:\users\public\test musi być pusty, aby móc utworzyć NTFS Junction

Pierwszy problem, który napotykamy to brak możliwości utworzenia NTFS Junction z katalogu, który nie jest pusty. W katalogu C:\users\public\test znajduje się plik test.txt, na którym jest nałożony oplock.

Twórca exploita na MSI Center rozwiązał ten problem wykorzystując tzw. callbacki oplocków, czyli funkcje, które mogą być realizowane przez oplocka w momencie gdy dowolny proces zechce uzyskać do niego dostęp. Na szczęście, nie musimy „wymyślać koła na nowo” i możemy skorzystać z projektu Google Project Zero – https://github.com/googleprojectzero/symboliclink-testing-tools, który udostępnia szukane przez nas funkcje.

Mamy tu klasyczny przykład race condition – chcemy wykonać pewne czynności, zanim inny proces (MSI Center) zmodyfikuje plik test.txt.

W omawianym exploicie, autor wykorzystał callbacki, a do „opróżnienia” folderu wykorzystał niskopoziomową funkcję NtSetInformationFile aby za jej pomocą przenieść plik, zmieniając jego nazwę.

Na powyższym rysunku, funkcja cb1 (callback) wykona pewne zadania, zanim program MSI Center zapisze dane do pliku test.txt.

Tworzy katalog C:\users\piotr\desktop\nowy_katalog (tylko na potrzeby pokazania kolejności zdarzeń w artykule, bez znaczenia dla exploita)
Przenosi plik C:\users\Piotr\Desktop\test.txt do C:\users\Piotr\Desktop\sukces\TymczasowaNazwaPliku.

Sprawdźmy jak wygląda to w praktyce:

Na powyższym rysunku przedstawiono kolejność wykonywania operacji. Podsumujmy:

W pierwszej kolejności, zakładany jest oplock na plik C:\users\Piotr\Desktop\test.txt
W drugim kroku, program MSI Center próbuje „dobrać się” do pliku, czym aktywuje oplock.
W trzecim kroku do akcji wkracza callback, który tworzy katalog C:\users\piotr\Desktop\nowy_katalog oraz przenosi plik C:\users\piotr\Desktop\test.txt do C:\users\piotr\Desktop\sukces\TymczasowaNazwaPliku
Oplock jest zwolniony, a program MSI Center zapisuje dane do pliku C:\users\Piotr\Desktop\test.txt

Wiedząc już, iż możemy „wygrać” wyścig z programem MSI Center i wykonywać operacje przed nim, możemy zbudować nasz callback w następujący sposób:

Zmiana nazwy pliku C:\users\public\test\test.txt na C:\users\piotr\Desktop\sukces\TymczasowaNazwaPliku.txt (przeniesienie pliku) a tym samym opróżnienie katalogu C:\users\public\test
Stworzenie NTFS Junction: C:\users\public\test => \RPC CONTROL\
Stworzenie symlinku: \RPC CONTROL\test.txt -> C:\programData\Microsoft\Windows\Start Menu\Program\Startup\runcalc.bat

Schemat działania wygląda w ten sposób:

Powyższa logika znajduje swoje odzwierciedlenie w omawianym exploicie:

Po uruchomieniu narzędzia oplock.exe i striggerowaniu oplocka (próbie zapisu do pliku C:\users\public\test\test.exe), wykonuje się sekwencja zdarzeń okodowana w funkcji cb1, następnie oplock jest zwalniany, a program MSI Center zapisuje dane do pliku C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\runcalc.bat

W pliku runcalc.bat, znajduje się linijka, która uruchamia kalkulator przy zalogowaniu się każdego użytkownika, w tym administratora. Niestety, nie wpadłem na pomysł w jakim można dokonać eskalacji w zautomatyzowany sposób, bez potrzeby czekania na zalogowanie się innego użytkownika. Ogranicza nas nieco wynikowy format plików – muszą być to tekstowe skrypty, takie jak PS1 czy BAT. Nie mamy bezpośrednio możliwości ingerowania w rejestr czy nadpisywania systemowych bibliotek, natomiast kopiowanie skryptu z uprawnieniami NT System to i tak już duży sukces, który w większości systemów przyniesie eskalacje uprawnień.

Jeżeli macie lepszy pomysł na eskalację uprawnień poprzez możliwość dowolnego kopiowania pliku BAT/PS1 – piszcie!

Podsumowanie

Modyfikacja plików z uprawnieniami NT System to ryzykowna sytuacja w przypadku, kiedy nieuprzywilejowany użytkownik może wyzwolić taką operację. Podobny schemat eskalacji uprawnień miał miejsce w innych podatnościach:

CVE-2023-21752
CVE-2020-1088
CVE-2023-37250

No i do tej listy dokładamy CVE-2024-37726.

Ten wpis można traktować jako początek serii wpisów o tego typu podatnościach, ponieważ w polskojęzycznych blogach o IT Security nie zauważyłem do tej pory opracowania tych tematów.