原文鏈接：EvilSln: Don't open .sln files
譯者：知道創宇404實驗室翻譯組

背景

利用項目代碼進行網絡釣魚攻擊并不是一個新概念。2021 年初，Lazarus APT 組織針對安全研究人員活動采取了一種特定的攻擊技術。他們在 Visual Studio 項目文件中嵌入了惡意事件命令，允許在編譯項目時執行有害代碼，詳情可見：針對安全研究人員的新活動。

此次事件讓Visual Studio安全問題再次進入公眾視野。值得注意的是，Visual Studio 并不是唯一存在此類風險的產品。JetBrains 的 IDE、VSCode 和其他文本編輯器在打開不安全項目時也會遇到類似漏洞。作為回應，這些產品引入了信任區域機制，在不受信任的環境中禁用某些風險功能，以此來保護他們的用戶。

在這個代碼庫中，我們提出了一種新的Visual Studio項目利用技術（Microsoft認為這不是安全問題），并提供了一個概念驗證。目的是提高人們對潛在風險的認識，幫助個人避免被黑客攻擊。

數據分析

執行

以下是一些公開披露的利用 Visual Studio 的方法：

1、PreBuildEvent: 在工程編譯前執行任意命令。

<PreBuildEvent>
    <Command>
    cmd /c calc
    </Command>
</PreBuildEvent>

2、 GetFrameworkPaths Target: 查看代碼時進行觸發

<Target Name="GetFrameworkPaths">
    <Exec Command="calc.exe"/>
</Target>

3、COMFileReference: 項目打開TypeLib加載時觸發

<COMFileReference Include="files\helpstringdll.tlb">
     <EmbedInteropTypes>True</EmbedInteropTypes>
</COMFileReference>

參考鏈接

我們希望找到一種無需編譯即可執行代碼的方式，只需打開*.sln或*.csproj項目文件。然而我們發現，在打開一個項目后，Visual Studio會自動在項目的根目錄中生成一個名為.vs的文件夾，其中包含一個名為.suo的特殊二進制文件。

信息來自于Visual Studio文檔：https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/solution-user-options-dot-suo-file?view=vs-2022

當環境打開 .suo 文件時，它會列舉所有當前加載的 VSPackages。如果 VSPackage 實現該IVsPersistSolutionOpts接口，環境會調用LoadUserOptionsVSPackage 上的方法，并要求其從.suo文件中加載所有數據。

而這意味著在加載.suo文件時將調用IVsPersistSolutionOpts#LoadUserOptions函數。

通過檢查VSPackage實現OnLoadOptions，我們可以找到VSCorePackage。

// Microsoft.VisualStudio.dll
// Microsoft.VisualStudio.VSCorePackage
protected override void OnLoadOptions(string name, Stream stream)
{
    if (name.Equals(typeof(VsToolboxService).Name))
    {
        VsToolboxService vsToolboxService = this.GetService(typeof(IToolboxService)) as VsToolboxService; 
        if (vsToolboxService != null)
        {
            vsToolboxService.LoadOptions(stream); // [1]
        }
    }
}

在[1]處，VSCorePackage將stream傳遞給OptionService并調用vsToolboxService.OnLoadOptions(stream)。

// Microsoft.VisualStudio.Toolbox.VsToolboxService
internal void LoadOptions(Stream stream)
{
    BinaryReader binaryReader = new BinaryReader(stream);
    BinaryFormatter binaryFormatter = new BinaryFormatter();
    int num = binaryReader.ReadInt32();
    for (int i = 0; i < num; i++)
    {
        string text = binaryReader.ReadString();
        int num2 = binaryReader.ReadInt32();
        for (int j = 0; j < num2; j++)
        {
            string text2 = this.Links.Read(stream);
            VsToolboxService.ToolboxItemContainer toolboxItemContainer = (VsToolboxService.ToolboxItemContainer)binaryFormatter.Deserialize(stream); // [2]
            if (text2 != null && File.Exists(text2))
            {
                toolboxItemContainer.LinkFile = text2;
                this.Links.TrackLink(text2);
                this.Items.GetFilteredList(text).Add(toolboxItemContainer);
            }
        }
    }
}

而在[2]處將調用BinaryFormatter.Deserialize來從流中獲取一個對象。這是 BinaryFormatter 反序列化的常見用法。由于類型限制不夠，我們可以直接使用ysoserial.net生成payload并嘗試將其寫入.suo文件。當在Visual Studio中打開項目時，惡意的.suo文件將被自動加載，并觸發calc.exe的執行。

Bypass信任區和 MOTW

Visual Studio 的情況有些不同。經過搜索，我們在這里找到了一篇詳細介紹的文章。

對于Visual Studio 2022 Preview 3，需要手動啟用“受信任的位置”功能。一旦啟用，Visual Studio將檢測是否嘗試打開不受信任的內容，并顯示一個新的對話框，警告有關安全影響：

這個設置需要手動啟用。然而，即使在該文章發表兩年后，這個設置仍然默認禁用。可能有一些原因阻止Visual Studio啟用它。

但是，我們仍然需要繞過MOTW的保護。

在我們的測試中，Visual Studio似乎不遵循MOTW。包含MOTW標記的從HTTP下載的sln文件可以在沒有任何警告的情況下打開，觸發MOTW警告可能需要特定的方法或配置。

總之，我們可以輕松繞過Trust Zones和MOTW的雙重保護，而這對于不了解風險的用戶構成了重大威脅。

開發

項目結構如下：

$ tree -a
.
├── App1
│   └── Form1.cs
├── App1.sln
└── .vs
    └── App1
        └── v17
            └── .suo

理論上，該項目可能會更小，但就目前而言，這應該足夠了。與純文本 .sln 或 .csproj 文件相比， .suo 它是隱藏的（以.開頭的文件和文件夾在文件資源管理器默認情況下不顯示），其內容更難以閱讀。描述該文件結構的文檔也很有限，因此即使仔細檢查也很容易被忽視。

此外，由于 Visual Studio 在關閉時將新內容保存到.suo 文件中的行為，有效負載內容被清除，為這種利用技術提供了自然的隱藏。此外，此特性可確保該漏洞不會被多次觸發。

Lazarus 向我們展示了如何植入惡意代碼：

在 GitHub 上公開該項目，如針對安全研究人員的 Active North Korean 活動（只需將后門隱藏在代碼中）
通過社交平臺發送項目，如針對安全研究人員的新活動（使用PreBuildEvent技術）

然后，引導受害者打開項目。與2021年不同的是，當打開項目時，代碼將被執行，無需額外的點擊或缺少MOTW（未知來源文件的警告）/不受信任的警告對話框。

利用反序列化的能力，攻擊者可以在內存中執行任意代碼。

概念驗證

復制或下載該項目

git clone https://github.com/cjm00n/EvilSln

雙擊該App1.sln文件使用 Visual Studio 打開它。（*.csproj也可以）
計算器將會彈出。

測試版本：17.7.5（2023年10月的VS2022更新）。

沒有Smartscreen警告，無需信任，無需進一步交互。但它將不會被修復，因為微軟認為這不是一個漏洞。

緩解措施

按照Microsoft的文章中所概述的步驟，手動打開相關設置：使用Visual Studio 2022提高開發者安全性
避免在Visual Studio中打開任何未知的項目。正如微軟所述，"打開Visual Studio項目是一項不安全的操作"。

討論

在發現這一漏洞后，我們迅速與Microsoft取得聯系，尋求澄清，并收到明確的回應，表明這不是一個安全問題。

經過調查，我們的團隊確定該問題不是漏洞。打開 Visual Studio 項目是一種不安全的操作，如下所述：https: //devblogs.microsoft.com/visualstudio/improving-developer-security-with-visual-studio-2022/

這與outflank的博客中提供的回應一致。因此，這是一個無法修復的漏洞，或者更確切地說，是一系列不會被修復的漏洞。但是很明顯存在漏洞。我們認為，在打開項目時會自動加載更多未公開的文件，僅僅這樣最基礎的操作就足以危用戶的的計算機。

是否存在在野惡意項目？

我們很快使用SourceGraph進行了調查，發現GitHub 上至少有 10,570 個包含 .suo 文件的存儲庫。不幸的是，我們沒有時間檢查其中是否包含惡意內容。

無論如何，使用 IDE（尤其是 Visual Studio）時請小心。在其內部機制下，它會執行許多未經察覺的操作。

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.jmbmsq.com/3052/

Paper - 安全技術精粹

Visual Studio 項目新利用技術分析

目錄

背景

數據分析

執行

Bypass信任區和 MOTW

開發

概念驗證

緩解措施

討論