【安全预警】Oracle数据库勒索病毒死灰复燃

区块链安全档案
区块链安全档案 机构得得号

Dec 03, 2018 隶属于曲速未来安全区,安全问题深度分析、一手威胁情报披露

摘要: 近日,Oracle数据库勒索病毒又活跃了,其实这并非新病毒,早在2年前,即2016年11月就发现了,期间沉寂了1年多,直到最近,该病毒突然呈现出死灰复燃之势。

一、事件背景

近日,Oracle数据库勒索病毒又活跃了,其实这并非新病毒,早在2年前,即2016年11月就发现了,期间沉寂了1年多,直到最近,该病毒突然呈现出死灰复燃之势。

中毒截图证明如下:

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

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

二、技术分析

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

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

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

以上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)抛出一个警告提示勒索信息

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

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

此存储过程主要功能是:如果当前日期 – 数据表(不含SYSTEM, SYSAUX, EXAMPLE)的最小分析日期 > 1200 天,则:

1、删除所有名字不含“$”且名称不是 ORACHK || SUBSTR(SYS_GUID,10)的数据表;

2、如果当前客户端程序进程名不是“C89238.EXE”(这个“C89238.EXE”推测是制作者搞了个KillSwtich,当收取赎金后,以这个进程名访问数据库将不会导致数据库进入异常,从而为恢复数据提供便利)则触发告警信息(见概述中的告警信息);

以上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的空间已被使用)

(作者:区块链安全档案,内容来自链得得内容开放平台“得得号”;本文仅代表作者观点,不代表链得得官方立场)

链得得仅提供相关信息展示,不构成任何投资建议
本文系作者 区块链安全档案 授权链得得发表,并经链得得编辑,转载请注明出处、作者和本文链接

更多精彩内容,关注链得得微信号(ID:ChainDD),或者下载链得得App

分享到:

相关推荐

    评论(0

    Oh! no

    您是否确认要删除该条评论吗?

    分享到微信