2016年3月8日,某電商平臺的ERP 系統(tǒng)遭到黑客攻擊,事件中使用的SQL注入攻擊是數據庫安全攻擊中幾乎最常見的SQL注入?;诎踩A金和數據庫安全攻防實驗室的技術分析和模擬攻擊過程還原,SQL注入點可能來自Oracle數據庫自身的三個安全機制缺陷。
缺陷1: oracle數據庫自身的存儲過程和函數調用的權限機制存在安全隱患
用戶調用pl/sql子程序的時候,程序在訪問所涉及到的底層對象(包括表格等)時,用戶不必擁有訪問這些對象的權限,只需要用戶有該存儲過程的執(zhí)行權限即可;而執(zhí)行時是參照的是該子程序定義者的權限。
簡單說就是如果用創(chuàng)建者只有創(chuàng)建權限,沒有執(zhí)行權限那么即便用sys賬號也依舊無法執(zhí)行。因為執(zhí)行定義者權限模式的子程序的時候。在子程序中當前賬號權限和創(chuàng)建該子程序用戶權限一致。雖然這給oracle帶來了很大的靈活性,但是會有很大的安全隱患。就像上文的例子一樣。黑客可以利用子程序獲得和子程序創(chuàng)建者一樣高的權限,再以高權限執(zhí)行惡意代碼。黑客可以通過這種手段獲得DBA賬號、甚至控制整個oracle。
缺陷2:oracle中有些系統(tǒng)函數的參數對輸入類型和長度缺乏控制,導致形成注入點。對于這種oracle缺乏控制的的函數的參數需要進一步約束。約束的方法可以等待oracle進行補丁修復后進行補丁升級,也可以通過數據庫防火墻對特定函數使用的范圍做一定的限制。
缺陷3:Oracle自身存在系統(tǒng)存儲過程或函數自身存在提權漏洞
這些系統(tǒng)性的存儲過程或函數需要調用者的權限很低,但通過注入的方式,完成將調用者的權限提升到dba,如:
SYS.LT.COMPRESSWORKSPACETREE、SYS.DBMS_CDC_IMPDP.BUMP_SEQUENCE、SYS.KUPW$WORKER.MAIN、CTXSYS.DRILOAD.BUILD_DML等。
通過以上對Oracle數據庫安全機制缺陷的分析,希望能夠對Oracle用戶提供安全防護思路。對于功能強大的數據庫系統(tǒng)來說,容易存在SQL注入點,通過在數據庫層部署專業(yè)的安全防護產品,能夠更直接有效的避免此類安全事件的發(fā)生。