病毒告警
某客戶核心業務系統中招ORACLE數據庫勒索病毒。 告警日誌出現自動任務執行錯誤，對象被鎖，並出現“你的數據庫已被SQL RUSH Team鎖死 發送5個比特幣到這個地址166xk1FXMB2g8JxBVF5T4Aw1Z5aZ6vSE (大小寫一致) 之後把你的Oracle SID郵寄地址 [email protected]我們將讓你知道如何解鎖你的數據庫”的信息（別發，數據丟失他們找不回來，病毒程序雲和恩墨可以處理）。當時的告警日誌如下：
事件處理
修改job參數，防止病毒程序自啓
alter system set job_queue_processes=0;
殺掉job進程，停止正在運行的病毒程序自動任務
ps -ef |grep j0|grep -v grep|awk '{print $2}'|xargs kill -9
禁用數據庫監聽自啓動，關閉監聽,防止攜帶病毒的客戶端再次連接
srvctl disable listener
srvctl disable scan_listener
srvctl stop listener
srvctl stop scan_listener
殺LOCAL=NO的會話
ps -ef|grep LOCAL=NO|grep -v grep|awk '{print $2}'|xargs kill -9
查找病毒程序
select owner,object_name from dba_objects where object_name like '%FUN9%'
select owner,created,object_name,OBJECT_TYPE from dba_objects where object_name like '%DBMS_CORE%';
select owner,created,object_name,OBJECT_TYPE from dba_objects where object_name like '%DBMS_SYSTEM_INTERNAL%’;
select owner,created,object_name,OBJECT_TYPE from dba_objects where object_name like '%DBMS_SUPPORT%';
OWNER CREATED OBJECT_NAME OBJECT_TYPE
-------------------- ------------------- ------------------------------ -------------------
APPUSER01 2019-05-24 10:58:06 DBMS_CORE_INTERNAL PROCEDURE
APPUSER01 2019-05-24 10:58:06 DBMS_SYSTEM_INTERNAL TRIGGER
APPUSER01 2019-05-24 10:58:05 DBMS_SUPPORT_INTERNAL PROCEDURE
APPUSER01 2019-05-24 10:58:06 DBMS_SYSTEM_INTERNAL PROCEDURE
APPUSER01 2019-05-24 10:58:06 DBMS_STANDARD_FUN9 PROCEDURE
刪除病毒程序的存儲過程、觸發器
--一般會跟9個空格，最好是通過sql拼湊drop語句
SQL> drop PROCEDURE APPUSER01."DBMS_CORE_INTERNAL ";
Procedure dropped.
SQL> drop PROCEDURE "APPUSER01"."DBMS_SYSTEM_INTERNAL ";
Procedure dropped.
SQL> drop PROCEDURE "APPUSER01"."DBMS_SUPPORT_INTERNAL ";
Procedure dropped.
SQL> drop TRIGGER "APPUSER01"."DBMS_SYSTEM_INTERNAL ";
Procedure dropped.
SQL> drop PROCEDURE "APPUSER01"."DBMS_STANDARD_FUN9";
Procedure dropped.
在啓動數據庫前，需要將出入病毒的連接IP查找出來加入黑名單，以防再次發生病毒注入。通過監聽日誌查找問題時間段的PLSQL連接
[oracle@host01 trace]$ fgrep "24-MAY-2019 10:5" dd1.log |fgrep "establish" | fgrep "plsql"
24-MAY-2019 10:50:05 * (CONNECT_DATA=(SERVICE_NAME=service1)(CID=(PROGRAM=C:\PLSQL Developer\plsqldev.exe)(HOST=host1)(USER=user1))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.xx.xx.xx)(PORT=xxx)) * establish * epmjc * 0
24-MAY-2019 10:51:01 * (CONNECT_DATA=(SERVICE_NAME= service1)(CID=(PROGRAM=C:\Program Files\PLSQL Developer\plsqldev.exe)(HOST=host1)(USER=user1))) * (ADDRESS=(PROTOCOL=tcp)(HOST=10.xx.xx.xxx)(PORT=xx)) * establish * epmjc * 0
…
查找所有節點的監聽日誌，發現疑似攜帶病毒的機器IP有5個，並同時檢查下面ip對應機器上的三方程序是否有異常。
檢查這些機器是否攜帶病毒需要時間，爲了及時恢復應用，將上述5個ip全部加入數據庫黑名單，sqlnet.ora添加配置示例如下
TCP.VALIDNODE_CHECKING=YES
tcp.excluded_nodes=(xxx.xx.xx.xx,xx.xx.xx.xx)
啓動監聽，檢查數據庫（注意：因爲還有job沒有刪除，job_queue_processes仍然爲0），聯繫應用驗證數據一致性和可用性。
數據丟失
APPUSER01用戶下的表丟失數據，通過數據庫歷史視圖查找數據庫truncate操作
SQL> select * from dba_hist_sqltext where upper(SQL_TEXT) like '%TRUNCATE TABLE%';
DBID SQL_ID SQL_TEXT COMMAND_TYPE
---------- -------------------------- -------------------------------------------------------------------------------- ------------
2584110390 b1undrf93t007 DECLARE job BINARY_INTEGER := 1; broken BOOLEAN := TRUE; next_date DATE := SYSDA 47
2584110390 48v643w2mr5ax DECLARE job BINARY_INTEGER := 1; broken BOOLEAN := TRUE; next_date DATE := SYSDA 47
2584110390 9up4qgk4udmq3 DECLARE job BINARY_INTEGER := 1; broken BOOLEAN := TRUE; next_date DATE := SYSDA 47
…
108 rows selected.
從上面的歷史sql視圖反應，數據庫在注入病毒後，於2019年5月24日11：02分鐘左右病毒程序truncate了約108張表。（小廣告：數據庫中病毒或者數據丟失，可以聯繫雲和恩墨團隊進行專業處理）
Job的處理
檢查病毒相關job
select count(*) from dba_jobs where schema_user='APPUSER01' and what like '%truncate%';
count出來大概有4kw行，system表空間都要撐滿了
逐條刪除job需要花很多時間，可以使用並行來跑
begin
for i in (select job from dba_jobs
where schema_user='APPUSER01' and what like '%truncate%' and mod(job,4)=0 )
loop
dbms_ijob.remove(i.job);
end loop;
end;
/
大概跑了20+小時，幹掉了這些病毒程序的job。
Remove操作有點類似delete，基表job$的段空間是沒有收縮的，水位線仍然是4kw的時候那麼高。雖然查詢dba_jobs很慢，但是出於安全考慮沒有降低基表的水位線，但是實測trunc是沒有問題的，可以備份jobs，然後trunc job$，再創建job應該就沒問題。注意：不要使用move，move會使job$上的索引失效，而且基本無法創建索引，也無法創建job。
原因分析
我們檢查了可疑IP中的4個，發現PLSQL中的AfterConnect.sql和login.sql都沒有異常。其中afterconnect.sql的大小應該是0字節，login.sql打開後只有一句註釋“- -Autostart Command Window script ”。如果這兩個文件裏有其他內容，應該懷疑是病毒。
但最後一個IP，沒有在本地，通過360掃描出了病毒程序
在2019年5月24日10:58:05該機器通過攜帶病毒的PLSQL連接到數據庫的APPUSER01用戶，導致了該數據庫被注入勒索病毒，2019年5月24日11:02該病毒程序刪除了APPUSER01下的部分數據，2019年5月27日11:15病毒程序阻止了數據庫會話登陸，拋出勒索比特幣告警信息，從而導致此次業務長時間中斷和數據丟失。
總結與建議
ORACLE比特幣勒索病毒可以追溯到2016年，國內很多用戶的Oracle 數據庫中病毒。時隔3年，勒索病毒似乎捲土重來。
本次故障直接造成業務長時間無法連接數據庫，造成數據永久丟失，原因就是不安全的PLSQL連接到了核心庫。
幾乎絕大多數客戶端工具，在訪問數據庫時，都可以通過腳本進行一定的功能定義，而這些腳本往往就是安全問題的漏洞之一，來歷不明的工具是數據庫管理大忌。通過此次數據庫勒索病毒事件可以看出，數據庫安全的重要性，不要抱着“不會發生在我身上”的想法管理數據庫，一切都是命運的安排。
爲了防止勒索病毒不再發生，提高數據安全性，建議如下：
1.嚴格管理權限。回收所有業務用戶的dba權限，在保障數據安全和應用可用的前提下，提供用戶最小權限。
2.排查三方工具。大範圍排查是否還可能有不明來源的第三方工具連接數據庫，必須從官方渠道獲取客戶端連接工具。以下列出了常見客戶端工具的腳本位置，需要引起注意
SQL*Plus: glogin.sql / login.sql
TOAD : toad.ini
PLSQLdeveloper: login.sql / afterconnect.sql
3.通過官方渠道下載補丁包。補丁包中也可能包含病毒程序，下載官方補丁包是基本規範操作。
4.設置白名單。限制IP登錄，非白名單中的IP不允許登錄數據庫，提高數據的安全性。
5.日常巡檢。把病毒掃描腳本加入日常巡檢中，早發現早處理。（小廣告，恩墨白求恩產品可以檢查出數據庫是否帶病毒，免費！(https://bethune.enmotech.com)
6.開啓數據庫審計。數據庫審計在跟蹤用戶操作上更加全面，審計會捕獲用戶登錄數據庫及登錄後的各項操作