In the ever-evolving landscape of cybersecurity, securing development environments has burgeoned into a topic of paramount concern, particularly given the omnipresence of software in modern societal infrastructures. A recent uptick in concerns regarding Microsoft’s Visual Studio IDE security, amplified by the release of a potentially pernicious one-click exploit, underscores the criticality of tool integrity in safeguarding software development processes.
He explores a new exploitation technique for Visual Studio projects, particularly focusing on .sln files. The concept of using code projects for phishing attacks isn’t new. For instance, in early 2021, the Lazarus APT group utilized a technique where they embedded malicious event commands within Visual Studio project files, which allowed the execution of harmful code during project compilation. This incident highlighted the security concerns related to Visual Studio and other IDEs like JetBrains’ IDEs and VSCode, which also have vulnerabilities when opening unsafe projects. These products have introduced trust zone mechanisms to disable certain risky functionalities in untrusted environments to protect users.The exploit, devised by esteemed principal security researcher Zhiniang Peng from Sangfor, sheds light on potential vulnerabilities within Visual Studio’s “trusted locations” feature – a safety measure instituted post the notorious 2021 Lazarus group attack.
This feature, while a notable counteraction against utilizing Visual Studio projects for malicious remote code execution (RCE) ventures, surprisingly isn’t activated by default, thereby leaving an array of developers unwittingly susceptible to threats. The exploit operates with deceptive simplicity: an ostensibly harmless project is downloaded, secretly harboring a malicious .suo binary file within. The file, surreptitiously auto-generated in a .vs folder upon project opening, pivots to become the epicenter of the attack, exploiting the clandestine nature of folders/files starting with a period.
Exploitation Technique
The repository presents a new exploitation technique for Visual Studio projects and provides a proof of concept. The intention is to raise awareness about the potential risks involved and empower individuals to avoid being hacked. The exploitation technique revolves around the .sln or .csproj project files. When a project is opened, Visual Studio automatically generates a .vs folder in the project’s root directory, which contains a special binary file called .suo. According to the Visual Studio documentation, when the environment opens a .suo file, it enumerates all currently loaded VSPackages. If a VSPackage implements the IVsPersistSolutionOpts interface, then the environment calls the LoadUserOptions method on the VSPackage, asking it to load all of its data from the file.
Proof of Concept
The proof of concept involves using ysoserial.net to generate a payload and attempt to write it to the .suo file. When opening the project in Visual Studio, the malicious .suo file will be automatically loaded and trigger the execution of arbitrary code in memory. The repository provides a sample evil project structure as follows:
$ tree -a
├── App1
│ └── Form1.cs
├── App1.sln
└── .vs
└── App1
└── v17
└── .suo
Despite the evident risk, Microsoft does not consider this a security issue. The official response from Microsoft states, “Opening a Visual Studio project is an insecure operation,” aligning with the response provided in outflank’s blog. Therefore, this exploit will not be fixed. However, the authors of the repository believe that there are more undisclosed files that automatically load when you open a project, and simply opening such a project is enough to compromise your machine.
Protective Steps in Navigating the Exploit Landscape:
- Enabling Trusted Locations: Aligned with insights from Microsoft’s narrative, “Improving developer security with Visual Studio 2022“, it’s imperative to activate trusted locations, ensuring content within Visual Studio 2022 is deemed untrusted unless explicitly added to the ‘trusted locations’ list.
- Vigilant Project Handling: Developers must adopt an inherent skepticism towards unfamiliar projects. Opening such entities within Visual Studio, or indeed any development environment, navigates a path laden with inherent cybersecurity risks.
In extending the dialogue to the cybersecurity community, it’s crucial to acknowledge the broader implications and potential adaptations of this exploit in other development environments. JetBrains’ IDEs, VSCode, and various text editors, while deploying their own sets of trust zone mechanisms, aren’t innately impervious to vulnerabilities, especially when managing unverified projects. Here lies an implicit call to action for software development and cybersecurity professionals alike: a unified, proactive stance towards enhancing the intrinsic security mechanisms of development tools, in a bid to safeguard the integrity of global digital infrastructures. Moreover, fostering an environment that thrives on collective knowledge sharing and alertness to potential threat vectors is crucial in navigating through the multifaceted cybersecurity challenges of our digital age.
Collectively, we must embark on a path of strategic vigilance, ensuring that our digital crafting tools are not only functionally robust but also fortified against the myriad of cybersecurity threats that persistently loom in the digital shadows.
He is a cyber security and malware researcher. He studied Computer Science and started working as a cyber security analyst in 2006. He is actively working as an cyber security investigator. He also worked for different security companies. His everyday job includes researching about new cyber security incidents. Also he has deep level of knowledge in enterprise security implementation.