Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

曲速未来 消息:Oracle数据库勒索病毒死灰复燃

0
0

曲速未来 消息:Oracle数据库勒索病毒死灰复燃
2018-11-30 16:45 区块链 技术
曲速未来 消息:Oracle数据库勒索病毒死灰复燃
615 收藏

区块链安全咨询公司曲速未来表示:近日,Oracle数据库勒索病毒又活跃了,其实这并非新病毒,早在2年前,即2016年11月就发现了,期间沉寂了1年多,直到最近,该病毒突然呈现出死灰复燃之势。

一、事件背景

区块链安全咨询公司 曲速未来 表示:近日,Oracle数据库勒索病毒又活跃了,其实这并非新病毒,早在2年前,即2016年11月就发现了,期间沉寂了1年多,直到最近,该病毒突然呈现出死灰复燃之势。

中毒截图证明如下:


曲速未来 消息:Oracle数据库勒索病毒死灰复燃

早在5月28号就发现多起Oracle数据库被勒索的案例中,中毒之后数据库会显示如下勒索信息:


曲速未来 消息:Oracle数据库勒索病毒死灰复燃

提取到相应的样本之后,经过深入分析,确认该病毒是RushQL数据库勒索病毒,是由于使用了破解版的PL/SQL导致的。

二、技术分析

RushQL病毒样本是在现场提取的,该样本是一个PL/SQL自带的AfterConnect.sql自动运行脚本,此文件一般在官方PL/SQL软件中是一个空文件,而该样本提取自破解版PL/SQL是有实际内容的,如下图所示:


曲速未来 消息:Oracle数据库勒索病毒死灰复燃

脚本的关键代码,采用了 Oracle数据库专用代码加密工具wrap进行了加密:


曲速未来 消息:Oracle数据库勒索病毒死灰复燃

将该病毒脚本解密,其主要功能是创建4个存储过程和3个触发器,下面分别分析其功能。PROCEDUREDBMS_SUPPORT_INTERNAL


曲速未来 消息:Oracle数据库勒索病毒死灰复燃

以上DBMS_SUPPORT_INTERNAL存储器的主要功能:

如果数据库创建日期 > 1200 天之后则:

(1)创建并备份sys.tab$表的数据到表 ORACHK || SUBSTR(SYS_GUID,10)

(2)删除sys.tab$中的数据,条件是所有表的创建者ID 在(0,38)范围

(3)通过SYS.DBMS_BACKUP_RESTORE.RESETCFILESECTION清理掉备份信息

(4)通过DBMS_SYSTEM.KSDWRT在你的alert日志中写上2046次勒索信息

(5)抛出一个警告提示勒索信息


曲速未来 消息:Oracle数据库勒索病毒死灰复燃

以上DBMS_SYSTEM_INTERNAL存储器的主要功能:

如果当前日期 数据表(不含SYSTEM, SYSAUX, EXAMPLE)的最小分析日期 > 1200 天,且当前客户端程序进程名不是“C89239.EXE”,则触发警告提示勒索信息


曲速未来 消息:Oracle数据库勒索病毒死灰复燃

此存储过程主要功能是:如果当前日期 数据表(不含SYSTEM, SYSAUX, EXAMPLE)的最小分析日期 > 1200 天,则:1、删除所有名字不含“$”且名称不是 ORACHK || SUBSTR(SYS_GUID,10)的数据表;2、如果当前客户端程序进程名不是“C89238.EXE”(这个“C89238.EXE”推测是制作者搞了个KillSwtich,当收取赎金后,以这个进程名访问数据库将不会导致数据库进入异常,从而为恢复数据提供便利)则触发告警信息(见概述中的告警信息);


曲速未来 消息:Oracle数据库勒索病毒死灰复燃

以上DBMS_STANDARD_FUN9存储器的主要功能:动态执行PL/SQL脚本

三、解决方案

区块链安全咨询公司 曲速未来 表示: 从技术分析知道,病毒会根据数据库创建时间、数据库的数据分析时间等因素来判断是否发作,因此会有一个潜伏期,潜伏期病毒不发作时是没有明显症状的,这时该如何自查是否感染这种病毒呢?其实病毒感染数据库主要是通过4个存储过程和3个触发器完成,也即判断是否存在如下存储过程和触发器即可知道是否感染了RushQL病毒:存储过程DBMS_SUPPORT_INTERNAL存储过程DBMS_STANDARD_FUN9存储过程DBMS_SYSTEM_INTERNA存储过程DBMS_CORE_INTERNAL触发器DBMS_SUPPORT_INTERNAL触发器DBMS_ SYSTEM _INTERNAL触发器DBMS_ CORE _INTERNAL一旦不幸感染了这种病毒该如何处置?从技术分析知道,病毒删除数据是由存储过程DBMS_SUPPORT_INTERNAL 和 DBMS_CORE_INTERNAL来执行的,他们的执行条件分别是:1 当前日期 - 数据库创建日期 > 1200 天2 当前日期 数据表(不含SYSTEM, SYSAUX, EXAMPLE)的最小分析日期 > 1200 天当以上条件不满足时,病毒不会触发删除数据的操作,此时删除以上4个存储过程和3个触发器即可。如果前面的2个条件中任何一个满足,就会出现数据删除操作,下面给出应对措施:

措施一:(当前日期 - 数据库创建日期 > 1200 天) 且 (当前日期 数据表(不含SYSTEM, SYSAUX, EXAMPLE)的最小分析日期 <= 1200 天)(A) 删除4个存储过程和3个触发器(B) 使用备份把表恢复到truncate之前(C) 使用ORACHK开头的表恢复tab$(D) 使用DUL恢复(不一定能恢复所有的表,如truncate的空间已被使用)

措施二:(当前日期 - 数据库创建日期 > 1200 天) 且 (当前日期 数据表(不含SYSTEM, SYSAUX, EXAMPLE)的最小分析日期 > 1200 天)(A)删除4个存储过程和3个触发器(B)使用备份把表恢复到truncate之前(C)使用DUL恢复(不一定能恢复所有的表,如truncate的空间已被使用)

本文内容由 曲速未来 (WarpFuture.com) 安全咨询公司整理编译,转载请注明。 曲速未来提供包括主链安全、交易所安全、交易所钱包安全、DAPP开发安全、智能合约开发安全等相关区块链安全咨询服务。

本文为作者“区块链安全档案”,原创文章,转载时请保留本声明及附带文章链接。 内容仅供读者参考,并非投资建议,本网站将保留所有法律权益。


曲速未来 消息:Oracle数据库勒索病毒死灰复燃

Viewing all articles
Browse latest Browse all 12749