Oracle 惡意攻擊問題分析和解決(一)

一 常見攻擊型別

1 被惡意篡改的資料庫安裝介質

此類攻擊屬於惡意破壞，攻擊資料庫後通常不會索要比特幣等，當然也不會提供解決方案。

2 被惡意篡改的PL/SQL Devloper安裝介質

此類攻擊屬於勒索病毒攻擊，被攻擊後會在告警日誌中提示向某個郵箱傳送固定數量的比特幣，然後提供解鎖資料庫方式(當然也不一定可信)。

本次主要介紹第一種情況

二 問題現象

被惡意篡改的資料庫安裝介質問題現象

Windows環境下資料庫，如果安裝了 被惡意篡改的資料庫安裝介質，當攻擊程式啟動後，會清空資料庫tab$表。

問題現象是當 通過PL/SQL工具資料庫時，報錯:

ORA-00600:internal error code,arguments:[kzrini:!uprofile],[],[],[]

三  影響範圍

當前資料庫處於open狀態(Windows平臺下可以open資料庫，Linux平臺下無法open，只能mount資料庫)，但是所有非sys使用者均無法連線資料庫，連線提示報錯ORA-00600[kzrini:!uprofile]後連線中斷，最終導致資料庫無法提供服務。

四  資料庫環境

作業系統：Windows Server 2008 R2

資料庫版本：Oracle 11.2.0.4.0

五  問題分析和定位

5.1 檢視錯誤日誌

檢視告警日誌，有如下錯誤：

ORA-00600: internal error code, arguments: [kgmfvmi#3], [], [], [], [], [], [], [], [], [], [], []
ORA-07445: exception encountered: core dump [kgmdelsis()+121] [ACCESS_VIOLATION] [ADDR:0x10] [PC:0x102F7F9] [UNABLE_TO_READ] []
ORA-00600: internal error code, arguments: [kzrini:!uprofile], [], [], [], [], [], [], [], [], [], [], []
ORA-00604: error occurred at recursive SQL level 1
ORA-00957: duplicate column name

5.2 問題分析

根據錯誤號ORA-00600: internal error code, arguments: [kzrini:!uprofile], [], [], [], [], [], [], [], [], [], [], []

初步懷疑資料庫tab$損壞導致以上故障。

檢查tab$表資料量為0。

此類攻擊通常是通過惡意植入DBMS_SUPPORT_DBMONITOR觸發器和DBMS_SUPPORT_DBMONITORP儲存過程方式，攻擊資料庫tab$表；

檢查當前資料庫確實存在這兩個物件，正常情況下是不會存在這兩個物件。

SET LINE 150
COL OBJECT_NAME FOR A35
SELECT OWNER,
       OBJECT_NAME,
       OBJECT_TYPE,
       TO_CHAR(CREATED, 'YYYY-MM-DD HH24:MI:SS')
  FROM DBA_OBJECTS
 WHERE OBJECT_NAME LIKE 'DBMS_CORE_INTERNA%'
    OR OBJECT_NAME LIKE 'DBMS_SYSTEM_INTERNA%'
OR OBJECT_NAME LIKE 'DBMS_SUPPORT%';

###儲存過程：DBMS_SUPPORT_DBMONITORP

###觸發器：DBMS_SUPPORT_DBMONITOR

檢視儲存過程和觸發器攻擊過程如下：

1 DBMS_SUPPORT_DBMONITOR觸發器定義了，當資料庫啟動時會自動執行 DBMS_SUPPORT_DBMONITORP 儲存過程。

2 當執行 DBMS_SUPPORT_DBMONITORP 儲存過程時，會檢查當前時間距離資料庫建立時間是否達到300天，如果大於等於300天，會以CTAS方式對sys.tab$表進行備份，備份的表名為ORACHK加10位隨機不重複的字串，然後執行delete sys.tab$;刪除tab$表資料，並提交刪除操作，生成檢查點。

儲存過程和觸發器如下( 請勿用於其他用途)：

儲存過程：

觸發器：

5.3 問題定位

由於資料庫多了兩個物件，儲存過程 DBMS_SUPPORT_DBMONITORP 和觸發器DBMS_SUPPORT_DBMONITOR，惡意破壞了資料庫基表tab$,導致資料庫無法使用。

六  攻擊可能途徑

此類事件可能攻擊途徑有如下方式

6.1 非官方途徑獲取的資料庫安裝介質

使用非官方途徑獲取的資料庫安裝介質，可能會導致惡意程式碼植入破壞資料庫。

檢查資料庫伺服器上的安裝介質，分別對兩個介質生成SHA1值。

可以使用windows系統自動的certutil工具生成安裝介質的SHA1值，例如：

檢視官方介質SH1值，進行對比

http://support.oracle.com

資料庫/GI PSU，SPU(CPU)，Bundle Patches 和 Patchsets 補丁號碼快速參考 (Doc ID 1922396.1)

曾經遇到過第一個介質P13390677_112040_MSWIN-x86-64_1of7.zip對應的SHA1值不一致，懷疑安裝包檔案被惡意篡改。

檢查安裝包 P13390677_112040_MSWIN-x86-64_1of7.zip解壓後檔案

database\stage\Components\oracle.rdbms.dbscripts\11.2.0.4.0\1\DataFiles\filegroup2.jar\rdbms\admin\prvtsupp.plb

以及資料庫安裝後 $ORACLE_HOME\rdbms\admin\prvtsupp.plb檔案

D:\app\Lenovo\product\11.2.0\dbhome_1\RDBMS\ADMIN\pvtsupp.pLb

發現 prvtsupp.plb 檔案被惡意篡改了

正常檔案內容只有如下內容：

而當前的檔案多了下面兩段內容

儲存過程 DBMS_SUPPORT_DBMONITORP 被加密了

使用DfUnWraper工具進行解密

儲存過程為：

6.2 盜版或綠色破解版PL/SQL Developer

使用盜版或綠色破解版PL/SQL Developer工具或其他破解版工具連線資料庫，可能會導致惡意程式碼植入破壞資料庫。

Oracle PL/SQL Dev軟體中，裡面的一個檔案 A fterconnet.sql

例如：

D:\cjc\plsql\PLSQL Developer 8.0.3.1510\AfterConnect.sql

其中afterconnect.sql的大小應該是0位元組，login.sql開啟後只有一句註釋“- -Autostart Command Window script ”，如果這兩個檔案裡有其他內容，應懷疑是病毒 ,具體排查方法見第二篇部落格，本次只討論第一種場景。

七  資料庫修復建議

7.1 無法通過ORACHKXXX備份表進行修復資料庫

通過攻擊的儲存過程資訊可知，在惡意刪除tab$基表前，對tab$進行了備份，備份的資料存在新建的ORACHKXXX表中。

但是由於tab$表並不是普通的堆表Heap table，而是聚簇表cluster，並且和C_OBJ#通過OBJ#列進行了關聯，從而導致了即使通過之前備份的ORACHKXXX表恢復tab$資料庫，關聯的遞迴資料也並沒有恢復，資料庫仍然無法使用。

檢視tab$表定義如下：

SQL> select * from (select * from SYS.BOOTSTRAP$ order by line#) where rownum<=5;

在測試環境下測試，通過ORACHKXXX表恢復了tab$表，但資料庫仍然報同樣的錯誤，問題沒有解決。

7.2 建議修復方式

常見修復方式是通過第三方修復工具DUL等，或oracle內部工具bbed，直接修改資料塊資訊，去掉tab$對應資料塊內刪除標記，但Oracle官方並不建議直接修改資料塊，可能會引發其他未知的錯誤，有一定的風險。

使用DUL恢復tab$方式如下：

利用dul工具直接更改tab$表資料塊，去除行刪除標記

上傳gdul包到伺服器（win）

替換license _key.dat

停庫，備份SYSTEM01.DBF

將原SYSTEM01.DBF檔案拷貝到D:\CJC目錄下

執行dul

檢視幫助資訊

檢視資料檔案資訊

Remove delete flag from TAB$ blocks.

已恢復tab$表2967行資料。

將system01.dbf替換原檔案

禁用所有觸發器

alter system set "_system_trig_enabled"=false scope=both;

重啟資料庫後，資料庫恢復正常

刪除這兩個物件

drop TRIGGER SYS.DBMS_SUPPORT_DBMONITOR;

drop PROCEDURE SYS.DBMS_SUPPORT_DBMONITORP;

7.3 檢查資料庫是否被攻擊

SELECT OWNER,
       OBJECT_NAME,
       OBJECT_TYPE,
       TO_CHAR(CREATED, 'YYYY-MM-DD HH24:MI:SS')
  FROM DBA_OBJECTS
 WHERE OBJECT_NAME LIKE 'DBMS_CORE_INTERNA%'
    OR OBJECT_NAME LIKE 'DBMS_SYSTEM_INTERNA%'
OR OBJECT_NAME LIKE 'DBMS_SUPPORT%';

八  如何預防此類問題

8.1 建議使用正版連線工具連線資料庫

建議使用正版連線工具連線資料庫，例如使用正版toad連線資料庫，不使用綠色破解版等連線工具連線資料庫。

8.2 使用官方正版或正規途徑獲取的資料庫安裝介質

使用官方正版或正規途徑獲取資料庫安裝介質，避免安裝介質被惡意篡改。

歡迎關注我的微信公眾號"IT小Chen"，共同學習，共同成長！！ ！

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29785807/viewspace-2717459/，如需轉載，請註明出處，否則將追究法律責任。