Cześć! Dzisiejszy wpis będzie poświęcony ciekawej technice eskalacji uprawnień z wykorzystaniem oprogramowania 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 Microsoft1.
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:
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. Nawet jeżeli 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, dzięki któremu 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ć, że 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
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ż, że 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.
- https://pl.msi.com/Landing/MSI-Center ↩︎
