Calls for Visual Studio security tweak fall on deaf ears despite one-click RCE exploit

Perceived weaknesses in the security of Microsoft's Visual Studio IDE are being raised once again this week with a fresh single-click exploit.

Developed by Zhiniang Peng, principal security researcher and chief architect of security at Sangfor, the proof of concept (PoC) exploits the default implementation of the IDE's "trusted locations" feature.

Following the 2021 targeting of security researchers by North Korea's state-sponsored offensive cyber group Lazarus, Microsoft rolled out trusted locations to prevent malicious Visual Studio projects being used to achieve remote code execution (RCE).

Published this week, Peng's exploit highlights how this feature that could prevent a tried and tested attack vector is still not enabled by default, putting unaware users at risk.

Peng argued that enabling the feature by default would go a long way to protecting developers opening projects from the web, but Microsoft has declined to comment on why user intervention is still required to benefit from the feature.

Microsoft told the researcher that it doesn't consider the issue to be tantamount to a security vulnerability, saying that opening a Visual Studio project downloaded from a platform like GitHub is inherently "an insecure operation."

The exploit itself involves a maliciously crafted project that's downloaded and opened on a user's machine. Peng devised a way to achieve RCE before a project even compiles.

It involves using the .suo binary file, one that's automatically created inside a .vs folder when a project is opened, which can be manipulated to trigger code execution.

What makes the attack especially deceptive is the fact that folders and files beginning with a period aren't displayed by default in a project's file explorer, meaning it requires additional manual effort to find these, and even when they are found, they're more difficult to read than plaintext files.

"There is also limited documentation describing the structure of this file, making it easier to overlook even with careful inspection," Peng said.

The researcher's full writeup details the exploit's inner workings at length, and while it's far from a novel attack vector, Peng was keen to highlight Microsoft's longstanding stance on the issue – that it doesn't consider it a true vulnerability and thus won't be patched.

After Lazarus started targeting security researchers with Visual Studio exploits in 2021, Microsoft's trusted locations feature was designed to automatically present a user who opened an untrusted Visual Studio project with a dialog window, warning of the security risks associated with opening projects downloaded from the web.

Trusted locations also eventually received an update adding a "restricted mode" to that dialog box, allowing users to open projects in a safer way that wouldn't allow for any code to be executed on the machine.

"After enabling [trusted locations], all content opened inside Visual Studio 2022 is considered untrusted until you or your organization (via Group Policy) adds it to the list of 'trusted locations'," Microsoft said in a blog post at the time.

• It's 2023 and Microsoft WordPad can be exploited to hijack vulnerable systems
• Researcher bags two-for-one deal on Linux bugs while probing GNOME component
• Trio of TorchServe flaws means PyTorch users need an urgent upgrade
• Thousands of Juniper Junos firewalls still open to hijacks, exploit code available to all

"You can trust a folder location, a git repository, or a git repository owner directly from the trust dialog or the trust settings dialog."

The issue Peng raised is that trusted locations is a feature users must enable manually and isn't enabled by default, which is still the case in 2023.

A Microsoft spokesperson dodged The Register's questions about why trusted locations isn't enabled by default and whether the latest PoC would change its stance on the matter.

However, it did provide the following statement: "To reduce the security risk of working with untrusted code, we recommend customers follow our guidance on how to configure trust settings to better protect themselves.

"In addition to the security feature improvements we have already announced, we will continue to evaluate our services to help protect our customers from these types of threats."

"This setting needs to be manually enabled," Peng said. "However, even two years after the article was published, this setting remains disabled by default. There might be something preventing Visual Studio from enabling it."

Mark of the Web (MOTW) also isn't adhered to in Visual Studio, Peng said, and solution (.sln) files downloaded over HTTP can be opened without any MOTW-related warnings.

MOTW is a security feature first implemented in Internet Explorer that tags files downloaded from the internet so Microsoft Defender SmartScreen is triggered to perform extra safety checks.

"All in all, we can bypass the double protection of trust zones and MOTW without any effort, which poses a significant risk for unaware users," Peng said.

"No SmartScreen warning, no trust need, no further interaction needed. But it will not be fixed, because Microsoft consider it's not a vulnerability."

Earlier this year, red team service provider Outflank published its own pre-build Visual Studio exploit and was met with a similar response from Microsoft, alluding to the fact that its own PoC simply used Visual Studio's intended behavior, which doesn't warrant a fix. ®