推薦大家使用官方提供的免費版本的客戶端工具，如 SQL developer ：http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html。或開源免費的資料庫客戶端工具，如 DBeaver 社群版 ：https://github.com/dbeaver/dbeaver/releases 

當前是否被注入病毒排查方式如下：

1、檢查是否有結果

select OWNER, TRIGGER_NAME, TRIGGER_TYPE, TRIGGERING_EVENT from dba_triggers
where TRIGGER_NAME like '%DBMONITOR%';
 

2、檢查 $ORACLE_HOME/rdbms/admin/prvtsupp.plb 裡是否有 create or replace procedure DBMS_SUPPORT_DBMONITORP 的程式碼    

3.檢查

select 'DROP TRIGGER '||owner||'."'||TRIGGER_NAME||'";' from dba_triggers 
where TRIGGER_NAME like  'DBMS_%_INTERNAL% '
union all
select 'DROP PROCEDURE '||owner||'."'||a.object_name||'";' from dba_procedures a 
where a.object_name like 'DBMS_%_INTERNAL% ';
 

背景介紹

最近有部分黑客採用各種手段對資料庫進行 sql 注入或者直接加密等損壞方式攻擊客戶的資料庫。需要說明的是這裡並非黑客用多麼高深的手段或者技能攻破 Oracle 資料庫或者由於 Oracle Bug 引起的，Oracle 被無辜躺槍。相反，這類攻擊完全是使用盜版客戶端工具或者客戶網路（或者主機）安全有漏洞，入侵主機或者直接使用盜版客戶端（部分網上下載的非官方工具已經是被黑客篡改過的）對資料庫登入時進行 SQL 注入的方法。

故障描述

於定期巡檢期間發現數據庫alert日誌中有如下錯誤：

Errors in file /home/oracle/diag/rdbms/ora11/ora11/trace/ora11_ora_181625.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-20315: 你的資料庫已被SQL RUSH Team鎖死  傳送5個比特幣到這個地址 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE (大小寫一致)  之後把你的Oracle SID郵寄地址 
 
[email protected] 我們將讓你知道如何解鎖你的資料庫  Hi buddy, your database was hacked by SQL RUSH Team, send 5 bitcoin to address 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE (case sensitive),  after that send your Oracle SID to mail address [email protected], we will let you know how to unlock your database.
ORA-06512: at "NEUSOFT_RPT.DBMS_CORE_INTERNAL         ", line 25
ORA-06512: at line 2

後經核實是由於開發人員使用了帶有病毒程式的客戶端（PL/SQL Developer）導致如果使用者從某些不明來源下載了 PL/SQL Developer 工具後(尤其是各種綠色版、破解版)，這個工具的安裝目錄存在一個指令碼檔案 AfterConnect.sql，正常安裝這個指令碼是空檔案，但是被注入的檔案，該指令碼包含了一系列的 JOB 定義、儲存過程和觸發器定義。受感染的 AfterConnect.sql 指令碼開頭偽裝非常正常的程式碼，後續內容卻是加密的惡意程式碼。

病毒主要物件有：

 資料庫啟動後執行觸發器 DBMS_SUPPORT_INTERNAL

DBMS_SUPPORT_INTERNAL 主要的意義是：
1. 當資料庫建立時間大於1200天之後，開始備份tab$表
2. 刪除 tab$ 中除掉 owner# 為 0 和 38 的記錄(sys，xdb)
3. 通過 SYS.DBMS_BACKUP_RESTORE.RESETCFILESECTION 清理掉備份資訊(v$controlfile_record_section)
4. 然後通過 DBMS_SYSTEM.KSDWRT 在你的 alert 日誌中寫上2046次的提示資訊
Hi buddy, your database was hacked by SQL RUSH Team, send 5 bitcoin to address 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE (case sensitive), after that send your Oracle SID to mail address [email protected], we will let you know how to unlock your database.
你的資料庫已被SQL RUSH Team鎖死 傳送5個比特幣到這個地址 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE (大小寫一致) 之後把你的Oracle SID郵寄地址 [email protected] 我們將讓你知道如何解鎖你的資料庫
5. 再丟擲一個前臺的和4類似的警告資訊

資料庫登入觸發器 DBMS_SYSTEM_INTERNAL

當你的非 SYSTEM,SYSAUX,EXAMPLE 之外的所有表的最小統計資訊時間大於 1200 天，而且非 C89239.EXE 程式，就會報出來” 你的資料庫已被 SQL RUSH Team 鎖死 傳送5個比特幣到這個地址 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE (大小寫一致) 之後把你的Oracle SID郵寄地址 [email protected] 我們將讓你知道如何解鎖你的資料庫 Hi buddy, your database was hacked by SQL RUSH Team, send 5 bitcoin to address 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE
(case sensitive), after that send your Oracle SID to mail address [email protected], we will let you know how to unlock your database.”的資訊

資料庫登入觸發器DBMS_CORE_INTERNAL

這裡比較明顯，把表名不含 $，不含 ORACHK，不是 cluster 的表放到一個遊標裡面，然後取非 SYSTEM,SYSAUX,EXAMPLE之外的表空間的表的最小統計資訊收集時間和當前時間比較如果大於 1200天 就執行 truncate table 操作，操作完成之後判斷如果登入程式不為 C89239.EXE，則報出來異常，” 你的資料庫已被SQL RUSH Team鎖死 傳送5個比特幣到這個地址 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE (大小寫一致) 之後把你的Oracle SID郵寄地址 [email protected] 我們將讓你知道如何解鎖你的資料庫 Hi buddy, your database was hacked by SQL RUSH Team, send 5 bitcoin to address 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE
(case sensitive), after that send your Oracle SID to mail address [email protected], we will let you know how to unlock your database.”。

由於之前做了許可權收縮收回了DBA角色與大多數許可權，導致病毒程式許可權不足，無法建立JOB，觸發器編譯失敗，導致部分病毒程式無法執行，未造成重大影響。

解決方案

第一 ：被攻擊的資料庫使用者中沒有重要的業務物件時

1.這段程式碼的執行都是通過job來操作的，高版本預設的job_queue_processes已經是1000了，所以當時通過作業系統看到後臺有700多個job程序在跑這段程式碼。
通過把job_queue_processes設定為0，重啟例項它這段指令碼就跑不起來了。只有沒有跑這段程式碼，儲存過程等物件才能刪除。

2.從作業系統登入到資料庫（sys 使用者），找出非法的儲存過程，job 定義，觸發器，把它們都 drop 就可以，當時由於這個客戶在受攻擊的資料庫使用者下面沒有業務物件，把這個使用者drop，重建就可以了。上述的整個處理過程沒有資料丟失，之所以耗時這麼長是因為客戶擔心丟失先做一次備份。

如果 SELECT NVL(TO_CHAR(SYSDATE-MIN(LAST_ANALYZED)),0) FROM ALL_TABLES WHERE TABLESPACE_NAME NOT IN (‘SYSTEM’,'SYSAUX’,'EXAMPLE’); 小於1200，查詢下列語句，然後刪除掉(正常庫查詢為空)

select 'DROP TRIGGER '||owner||'."'||TRIGGER_NAME||'";' from dba_triggers where
TRIGGER_NAME like  'DBMS_%_INTERNAL% '
union all
select 'DROP PROCEDURE '||owner||'."'||a.object_name||'";' from dba_procedures a 
where a.object_name like 'DBMS_%_INTERNAL% ';

如果SYSDATE-MIN(LAST_ANALYZED)大於1200, SYSDATE-CREATED大於1200天未重啟，或者SYSDATE-CREATED小於1200;就是tab$還未被清理,但是表被truncate，這樣情況可以通過oracle原廠dul工具恢復；

如果SYSDATE-CREATED大於1200天，而且資料庫重啟過，但是SYSDATE-MIN(LAST_ANALYZED)小於1200天，那可以直接通過把ORACHK’||SUBSTR(SYS_GUID,10)中備份資訊插入到$tab中；

SYSDATE-CREATED大於1200天，而且資料庫重啟過，但是SYSDATE-MIN(LAST_ANALYZED)大於1200天，Oracle 原廠dul之類工具結合ORACHK’||SUBSTR(SYS_GUID,10)備份表中資料進行恢復；

第二 ：當被攻擊的資料庫使用者中有重要業務物件時：

1. 如果是對檔案加密，根據具體客戶情況，可以考慮比對正常檔案（沒有被攻擊的資料庫的檔案）和有問題檔案比對，找到端倪後，拼接等等思路

2. 根據實際情況，如果上面的“1.”不可行，那麼考慮停止黑客的異常job，過程，觸發器等等（可以採用倒推等方式或者直接查詢DBA_OBJECTS 中的LAST_DDL時間），根據實際情況，如果有必要的話，還可以根據報錯時間點進行logminer來進行檢查和確認損壞過程，並找到黑客備份的系統表，進行還原（請在Oracle Support或者專業DBA指導下完成）。

3. 如果上述的“1.”和“2.”都不可行，那麼可以考慮使用各種可以進行邏輯挖掘的工具挖出資料。
.
當然根據不同的黑客入侵方式，可能還有其他解決方法，這裡要重點討論的是我們如何防患於未然：
1，請使用正版工具或者使用Oracle官方推薦的免費SQL客戶端工具：
http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html
上面地址是官網正版下載地址，功能非常強大，完美支援12c和以前的資料庫版本，並且免費。

2，如果發現類似問題，儘量保護現場，並根據報錯資訊的時間點，追查原因

3，重要資料庫一定要備份，如果配置了ADG，備庫建議開閃回，如此，很多問題處理上就簡單多了。

4，對於資料庫使用者的dba等高階許可權應該有效管理

5.請注意，有些黑客會設定一個潛伏期，例如上面的例子，該攻擊的效果存在1200天的潛伏期：
黑客程式碼中有類似下面的判斷條件：IF (DATE1>=1200) THEN
因此，建議客戶檢查資料庫的異常物件，如果發現異常物件，建議直接刪除相關惡意注入的資料庫物件（procedure，job，trigger等等）

預防策略

1）資料庫裡面查詢異常物件，並及時清理。

2）建議業務使用者儘量限制dba 許可權

3）檢查相關登陸工具的自動執行指令碼 清理掉有風險指令碼
sqlplus中的glogin.sql/login.sql
toad中的toad.ini
plsql dev中的login.sql/afterconnect.sql

4）建議從官方下載工具，不要使用綠色版/破解版等