前言

本文深入探討 MSSQL 在 public 與 db_owner 權限下獲取 WebShell 或系統權限的六大實戰方法，並嚴謹論證「絕對 public 權限下單靠 SQL 力量提權絕對不可能」的結論，最後給出網管防禦建議。

db_owner 權限下的五種公開提權方法

1. 差異備份生成 ASP： 利用 BACKUP DATABASE ... DIFFERENTIAL 產生 ASP 檔案，成功率不高。
2. 萬能提權（特定條件）： 成功率近乎零，僅極特定環境可行。
3. 讀取 VNC 註冊表加密密碼破解： 利用 xp_regread 讀取 VNC 密碼破解拿系統權限，前提是目標安裝 VNC，侷限性大。
4. 註冊表寫入系統帳號或 WebShell： 利用 xp_regwrite 寫入啟動項，需重啟才生效，成功率較高但有延遲。
5. 利用排程預存程序（sp_add_job 等）： 理論成功率最高，但實測本機常失敗，可能受作業系統影響。

第六、七、八種高成功率方法（作者私藏）

作者宣稱另有至少三種成功率更高的方法，核心為「瞞天過海」：在 master 資料庫擁有 db_owner、其他資料庫僅 public（「相對 public 權限」）時，竟可使用僅限 sysadmin 的 sp_OACreate、sp_OAMethod，可無亂碼寫入 WebShell 或直接加系統帳號。

絕對 public 權限下的不可行性證明

• sp_add_job 等需 SQLSERVERAGENT 服務啟動，預設關閉；xp_servicecontrol 啟動會報錯。
• xp_regread、xp_dirtree 等需建表、插入資料再查詢，但 public 無建表/插入/備份權限，第一關即過不去。
• 其他危險預存/擴展預存程序或權限不足或有限制。
• 結論： 絕對 public 權限下，單靠 SQL 預存/擴展預存程序拿 WebShell/系統權限絕對不可能。

實戰經驗：master 資料庫 db_owner 機率極高

作者實戰經驗：至少 90% 的網站在給預設資料庫 db_owner 時，同步給 master db_owner；資料庫僅 2-3 個時更是 100%。因此「相對 public 權限」極具實戰價值。

網管防禦建議

1. 嚴格最小權限原則：避免給應用程式帳號 db_owner，更勿給 master 權限。
2. 杜絕 SQL Injection：這是根本之道。
3. 不要因公開手法被修補就鬆懈，未公開手法更多，需建立完備防禦體系（WAF、審計、最小權限、定期滲透測試）。
4. 安全是整體，單點防禦不可靠。

結語

MSSQL 提權技術層出不窮，核心在於權限配置失誤與注入漏洞共存。網管應回歸基本面：最小權限、修補注入、纵深防禦，而非賭攻擊者不知某招。