轉自先知社區(qū)

作者：dot.Net安全矩陣

原文鏈接：.NET 某和OA辦公系統(tǒng)全局繞過漏洞分析 - 先知社區(qū)

0x01 前言

某和OA協(xié)同辦公管理系統(tǒng)C6軟件共有20多個應用模塊，160多個應用子模塊，從功能型的協(xié)同辦公平臺上升到管理型協(xié)同管理平臺，并不斷的更新完善，全面支撐企業(yè)發(fā)展。從此OA C6版本外部已公開的多個漏洞詳情，不難發(fā)現都有一些共同的特點，那就是URL里的 .aspx后都會加上一個 / ，然后再進行傳遞參數。比如 /RssModulesHttp.aspx/?interfaceID=1，為此有一些對.NET感興趣的群友們在星球陪伴的微信群里問起這個原因。
于是筆者帶著這些疑問點抽空研究總結了一下，于是便有了此文。

0x02 ExtensionlessUrlHandler

筆者對.NET系統(tǒng)進行漏洞挖掘時第一步喜歡看一下Web.config配置文件，因為此文件包含了一些關于HTTP請求需要經過的管道或者自定義方法，如下所示。

在這里我們發(fā)現了一個名為ExtensionlessUrlHandler的一般處理程序，關于此handle背景知識是這樣的：.NET WebForms框架早期版本中對于URL請求的設計和管理一直沿用經典的ASP風格，通常URL地址上包含文件及擴展名，比如 UserName.aspx、CheckUser.ashx 等。隨著 Web 開發(fā)的進步和用戶體驗需求的提升，陸續(xù)出現像MVC框架對無擴展名 URL的需求，即 extensionless URL。

無擴展名 URL 更簡潔、易讀，用戶更容易記住和輸入。例如，/about 比 /about.aspx 更直觀和易記。因此.NET框架在后來4.0發(fā)布時引入了一個ExtensionlessUrlHandler這是一個專門用于處理無擴展名 URL 請求的 .NET Handler。

當啟用該配置后基于WebForms框架實現的Web應用便可以像MVC那樣通過使用 / 分割路徑和參數。這比如 /Mall/Product/GetById/10 ，使用該組件時需要當運行在IIS7以上版本，并且需要IIS的一個快速修復程序KB980368，配置Web.config后將會正常處理上面這種 extensionless URL。

在IIS經典模式下，用的是aspnet_isapi.dll，通過映射到System.Web.DefaultHttpHandler進行處理，如下配置所示。

<system.webServer>
<handlers><addname="ExtensionlessUrl-ISAPI-4.0_32bit"path="*."verb="GET,HEAD,POST,DEBUG"modules="IsapiModule"scriptProcessor="%WINDIR%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll"preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
</handlers>
</system.webServer>

在集成模式下，會映射到System.Web.Handlers.TransferRequestHandle來處理，如下配置所示。

<system.webServer><handlers><remove name="ExtensionlessUrlHandler-Integrated-4.0" /><remove name="OPTIONSVerbHandler" /><remove name="TRACEVerbHandler" /><add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" /></handlers>
</system.webServer>

這段配置中path="." 匹配所有無擴展名的 URL 請求，verb="" 表示謂詞，就是IIS處理所有 HTTP 請求方法，包含了GET/POST/DELETE/PUT 等。type更是直接指向"System.Web.Handlers.TransferRequestHandler"：調用使用TransferRequestHandler處理程序解析運行請求。preCondition表示預先處理的條件必須是應用程序池使用集成模式并且運行時版本為 v4.0 時生效。
ExtensionlessUrlHandler 的引入是為了滿足當時WebForms應用具備現代 Web 架構對無擴展名 URL 的需求。隨著.NET后續(xù)版本的迭代和更新，Web框架已不再需要此項配置便可實現無擴展名的URL。

0x03 JHSoft.Log.HttpModule

我們知道在 .NET 應用程序中，HTTP Modules用于處理進入的 HTTP 請求的生命周期事件。通過自定義 HTTP Modules可以為應用程序添加日志記錄、安全驗證防護等功能。在企業(yè)級應用某和OA中，我們可以看到對 HTTP 模塊做了如下配置，例如：

<modules runAllManagedModulesForAllRequests="true"><add name="JHSoft.Log" type="JHSoft.Log.LogHttpModule, JHSoft.Log"></add>
</modules>

上述配置指定HTTP請求需要經過JHSoft.Log.LogHttpModule模塊，從名稱上看應該是記錄請求等日志數據的，其實反編譯后發(fā)現不僅做了日志的處理，還有對整個請求做了安全校驗。具體代碼如下圖所示

Init 方法用于初始化自定義的模塊，并注冊一系列事件處理程序，其中AcquireRequestState事件在獲取當前請求的狀態(tài)時觸發(fā)，常用于檢查請求的數據。具體定義如下圖所示

代碼中對aspx擴展名做了深入的處理，通過 context.Request.Path.ToLower(); 獲取請求路徑并轉換為小寫，然后text.EndsWith(".aspx") 判斷請求路徑是否以 .aspx 結尾，如果是則調用 SqlFilter 方法檢查請求是否包含敏感字符，這是一個防御SQL注入的方法。
這么看如果是.ashx或者.asmx文件有注入漏洞則完全不受該約束，可以順利的進行SQL注入攻擊。
如果沒有注入的風險，程序會繼續(xù)向下執(zhí)行，通過 if ((context.Session == null || context.Session["UserCode"] == null) ... 檢查會話是否為空。接著通過類似這樣的判斷 text.IndexOf("/jhsoft.web.login/password.aspx") == -1 排除特定的頁面，除此之外所有的請求都會被強制重定向至登錄頁。這里和某通一樣在此處定義了很多需要排除驗證的文件，如下圖所示

比如我們選擇其中的一個文件名作為測試，訪問 /jhsoft.web.workflat/isconnect.aspx 返回了預期的結果，并沒有重定向到登錄頁。

0x04 全局繞過權限驗證

經過上面兩小節(jié)的分析得知，某和OA支持像MVC那樣無擴展名的路由請求，而在全局用于檢查的AcquireRequestState事件中錯誤的使用了EndsWith方法判斷URL請求是否包含.aspx，因此我們可以構造出如下請求達到繞過全局的校驗，如下所示。
/c6/JHsoft.web.Workflat/SetImageModule.aspx/id/121212，或者使用 /c6/JHsoft.web.Workflat/SetImageModule.aspx/?id=2222 均可以實現未授權訪問。如圖所示

我們以外部公開的RssModulesHttp.aspx存在SQL注入漏洞為例，查看此文件的Page_Load方法，發(fā)現參數 interfaceID 從 Request.QueryString客戶端獲取后并沒有做任何過濾和處理便進入了 GetRssInfo函數，如下圖所示

GetRssInfo 方法用于從數據庫中獲取特定 RSS 接口的信息。它使用傳入的 interfaceID 參數來查詢數據庫中的 WFRssModule 表，并返回查詢結果，具體代碼如下圖所示。

上述傳入的 interfaceID 直接拼接到 SQL 查詢字符串中并且執(zhí)行查詢，因此觸發(fā)MSSQL注入漏洞，如下圖所示。

0x05 總結

該系統(tǒng)由 ExtensionlessUrlHandler 和 JHSoft.Log.Module 組件兩者配合引發(fā)的全局繞過漏洞，攻擊者只需要構造出特定的URL請求便可實現任意接口的未授權訪問，也證明了 Web應用程序在配置和權限管理上的薄弱環(huán)節(jié)，因此不當的配置可能導致嚴重的安全漏洞。