Researcher details one-click RCE on Microsoft Visual Studio
The security of development tools is paramount. As software becomes more integrated with our daily lives, the importance of maintaining the security and integrity of the tools that craft it cannot be understated. This week, concerns surrounding Microsoft’s Visual Studio IDE’s security have surged once more, culminating with the release of a potentially dangerous one-click exploit.
Developed by the renowned Zhiniang Peng, the principal security researcher at Sangfor, this proof of concept (PoC) is shining a spotlight on Visual Studio’s “trusted locations” feature. This feature came into existence following the infamous 2021 attack on security researchers by Lazarus, North Korea’s state-sponsored cyber group. “Trusted locations” was Microsoft’s countermeasure to prevent Visual Studio projects from being used maliciously to achieve remote code execution (RCE).
While Visual Studio is under scrutiny, it’s imperative to understand that it’s not alone in facing these challenges. JetBrains’ IDEs, VSCode, and even text editors aren’t immune to vulnerabilities when opening unverified projects. Their response? Implementing trust zone mechanisms designed to protect users by disabling riskier functionalities in untrusted scenarios.
Peng’s recent revelation emphasizes a disconcerting fact: the very feature designed to thwart malicious attacks isn’t activated by default. This omission leaves many unsuspecting developers exposed.
The exploit operates in a simple yet deceptive manner. Consider a developer downloading a seemingly innocuous project. Unbeknownst to them, lurking within this project is a malicious .suo binary file. This file, auto-generated in a .vs folder upon opening a project, becomes the attack’s pivot point.
Here’s the catch: folders and files starting with a period, like the .vs folder, are stealthily hidden by default in Visual Studio’s file explorer. This invisibility, coupled with limited documentation on the .suo file’s structure, makes it an ideal vector for malicious intent. Peng elaborates on this point, noting that even meticulous inspection could easily overlook this exploit.
Surprisingly, despite this being a non-novel attack vector, Microsoft maintains a peculiar stance on the issue, refraining from categorizing it as a genuine vulnerability. This means that as of now, no patches are in the works.
Rewind to 2021, when Lazarus employed Visual Studio exploits against security researchers. Microsoft’s response was swift, resulting in the trusted locations feature. Its function? When opening an untrusted Visual Studio project, the user would be greeted with a warning dialog window, cautioning them of the risks.
Microsoft even bolstered this feature with a “restricted mode”, providing users with an option to open projects in a manner that nullifies the risk of code execution.
A concerning revelation from Peng’s research using Sourcegraph showed that a staggering 10,570 repositories on GitHub contain .suo files. The big question: Are any of these repositories laced with malicious intent? Only time (and thorough inspection) will tell.
In the face of this exploit, certain measures can ensure your development environment remains uncompromised:
1. Enable Trusted Locations: As highlighted in Microsoft’s post, “Improving developer security with Visual Studio 2022“, make sure to activate trusted locations. This will render all content within Visual Studio 2022 untrusted unless explicitly added to the ‘trusted locations’ list.
2. Exercise Caution: A golden rule for all developers – refrain from opening unfamiliar projects in Visual Studio. Echoing Microsoft’s sentiments, such an action is inherently fraught with risks.
