Oracle数据库勒索病毒死灰复燃（数据库中了勒索病毒）

一、事件背景

近日，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的空间已被使用）

（作者：区块链安全档案，内容来自链得得内容开放平台“得得号”；本文仅代表作者观点，不代表链得得官方立场）