Krytyczna luka w Visual Studio załatana – błąd pozwalał na eskalację uprawnień do NT AUTHORITY\SYSTEM

Środowiska developerskiego Visual Studio nie trzeba przedstawiać. To bardzo zaawansowane narzędzie od Microsoft, skrywające wiele ficzerów przydatnych programistom, a także pentesterom i badaczom bezpieczeństwa. 

W ostatni Patch Tuesday Microsoft wypuścił łatkę na podatność umożliwiającą eskalacja uprawnień (privilege escalation), która otrzymała identyfikator CVE-2024-20656. Autorem znaleziska jest Filip Dragovic z MDsec.

W czym leży problem? VS pozwala na rozszerzenie funkcjonalności przez instalację dodatkowych „pakietów”. Jednym z nich jest komponent umożliwiający pracę z projektami w językach C i C++. Wykorzystuje on usługę VSStandardCollectorService150, która pełni role diagnostyczne podczas debugowania projektu. Usługa ta jest uruchamiana w kontekście  NT AUTHORITY\SYSTEM. 

PS C:\\Users\\doom> sc.exe qc VSStandardCollectorService150

[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: VSStandardCollectorService150

        TYPE               : 10  WIN32_OWN_PROCESS

        START_TYPE         : 3   DEMAND_START

        ERROR_CONTROL      : 0   IGNORE

        BINARY_PATH_NAME   : "C:\\Program Files (x86)\\Microsoft Visual Studio\\Shared\\Common\\DiagnosticsHub.Collection.Service\\StandardCollector.Service.exe"

        LOAD_ORDER_GROUP   :

        TAG                : 0

        DISPLAY_NAME       : Visual Studio Standard Collector Service 150

        DEPENDENCIES       :

        SERVICE_START_NAME : **LocalSystem**PS C:\\Users\\doom>

Wykorzystanie podatności wymaga wykonania szeregu działań, które w efekcie umożliwią podniesienie uprawnień użytkownika, które zostały zaprezentowane w dokładnym opisie podatności:

• Create a dummy directory where the VSStandardCollectorService150 will write files.
• Create a junction directory that points to a newly created directory.
• Trigger the VSStandardCollectorService150 service by creating a new diagnostic session.
• Wait for the <GUID>.scratch directory to be created and create new object manager symbolic link Report.<GUID>.diagsession that points to C:\\ProgramData .
• Stop the diagnostic session.
• Wait for the Report.<GUID>.diagsession file to be moved to the parent directory and switch the junction directory to point to \\RPC Control where our symbolic link is waiting.
• Sleep for 5 seconds (not really important but left it there).
• Switch the junction directory to point to a dummy directory.
• Start a new diagnostic session.
• Wait for <GUID>.scratch directory to be created and create a new object manager symbolic link Report.<GUID>.diagsession that points to C:\\ProgramData\\Microsoft
• Stop the diagnostic session.
• Wait for the Report.<GUID>.diagsession file to be moved to parent directory and switch the junction directory to point to \\RPC Control where our symbolic link is waiting.
• After the permissions are changed we delete the C:\\ProgramData\\Microsoft\\VisualStudio\\SetupWMI\\MofCompiler.exe binary.
• Locate and run the Setup WMI provider in repair mode.
• Wait for our new MofCompiler.exe binary to be created by the installer and replace it with cmd.exe
• Enjoy SYSTEM shell 🙂

Jak widać, nadużycie VSStandardCollectorService150 to złożony proces opierający się na resetowaniu DACL (Discretionary Access Control List), odpowiednim wyczuciu czasu oraz żonglowaniu dowiązaniami symbolicznymi.

Luka została już naprawiona, a na GitHubie pojawił się PoC, a także na Twitterze/X https://twitter.com/filip_dragovic/status/1744819969882231206

~fc