一 说明
近期，国内通过重写 PL/SQL Developer 破解版中的 AfterConnect.sql 和 login.sql 脚本，当开发运维人员通过该工具连接 Oracle 数据库，登陆账号具有创建存储过程触发器等权限，则会自动创建一系列的存储过程和触发器，通过用户登录，数据库重启等条件，触发器调用相应的存储过程。
该病毒的主要触发条件如下：
1. 数据库创建时间是否大于 1200 天
2. 非系统表空间的用户表未进行统计信息收集天数是否大于 1200 天
3. 数据库是否重启
所以，该病毒有一定可能在 Oracle 数据库感染后不会立即触发删除表的动作，具有较长的潜伏期。
勒索病毒针对数据库，而不会因为操作系统（类 unix 或 windows ）不同而导致病毒失效，所以在所有的 ORACLE 数据库环境，均需要预防该病毒的感染，而不考虑操作系统版本和数据库版本。
二 检查方法
1 连接至 Oracle 数据库 2 复制以下 sql 执行：
|
-- 查询表未统计信息收集天数是否超过 1200 天 SELECT NVL(TO_CHAR(SYSDATE-MIN(LAST_ANALYZED)),0) FROM DBA_TABLES WHERE TABLESPACE_NAME NOT IN ('SYSTEM','SYSAUX','EXAMPLE'); -- 查询病毒相关的触发器和存过 select 'DROP TRIGGER '||owner||'."'||TRIGGER_NAME||'";' from dba_triggers where TRIGGER_NAME like 'DBMS%INTERNAL% ' union all select 'DROP PROCEDURE '||owner||'."'||a.object_name||'";' from dba_procedures a where a.object_name like 'DBMS%INTERNAL% '; |
如果该 sql 输出一下记录，则数据库已感染病毒
|
对象名 |
对象内容 |
|
DBMS_SUPPORT_INTERNAL |
TRIGGER |
|
DBMS_SUPPORT_INTERNAL |
PROCEDURE |
|
DBMS_SYSTEM_INTERNAL |
TRIGGER |
|
DBMS_CORE_INTERNAL |
TRIGGER |
|
DBMS_SYSTEM_INTERNAL |
PROCEDURE |
|
DBMS_CORE_INTERNAL |
PROCEDURE |
|
DBMS_STANDARD_FUN9 |
PROCEDURE |
该病毒通过触发器的方式来实现对数据库的破坏 , 分为三部分 :
DBMS_SUPPORT_INTERNAL
该触发器为数据库启动触发 , 启动后执行如下操作
1. 检查数据库创建时间是否大于 1200 天 , 如果超过 1200 则创建 ORACHK 表来备份 tab$ 表 , 此后删除 tab$ 中除掉 owner# 为 0 和 38(sys,xdb) 的行 .
2. 接着通过 dbms_backup_restore 清理整个数据库的备份信息
3. 然后通过 dbms_system 在 alert 日志中写入相关告警提示信息
DBMS_SYSTEM_INTERNAL
该触发器为数据库登陆触发 , 该触发器作用主要是针对除了 SYSTEM ， EXAMPLE ， SYSAUX 三个表空间以外的对象进行统计信息最后分析时间的对比 , 如果存在 1200 天以上的表未做统计信息分析则会判断下是否属于 C89239 的客户端的进程 , 如果不是则出发事件告警 . 告知登陆用户数据库被锁定 .
DBMS_CORE_INTERNAL
该触发器为数据库用户登陆触发 . 在用户登陆后 , 会触发对归属于当前登陆用户的不在 SYSTEM ， EXAMPLE ， SYSAUX 表空间的表并且过滤掉带 $ 的表以及 orachk 备份表 , 簇表进行统计信息收集的时间进行收集对比 , 如果存在超过 1200 天未收集统计信息 , 则 truncate 对应的表 ( 不是全部表 truncate, 还是有条件的 ). 然后告警 .
三 处理步骤
1 如数据库创建时间（ SYSDATE-CREATED ）未达到 1200 天，病毒不会触发删除数据的操作。
处理办法：
直接手工删除以上的存储过程和触发器。
|
select 'DROP TRIGGER '||owner||'."'||TRIGGER_NAME||'";' from dba_triggers where TRIGGER_NAME like 'DBMS%INTERNAL% ' union all select 'DROP PROCEDURE '||owner||'."'||a.object_name||'";' from dba_procedures a where a.object_name like 'DBMS%INTERNAL% '; |
2 如果数据库创建时间（ SYSDATE-CREATED ）大于 1200 天 , 数据库未重启且对应表格（不在 SYSTEM ， EXAMPLE ， SYSAUX 表空间的表）的统计信息收集时间（ SYSDATE-MIN(LAST_ANALYZED) ）小于 1200 天。
处理办法：
|
a 直接手工删除以上的存储过程和触发器。（命令详见操作 1 ） b 使用 DUL 恢复（不一定能恢复所有的表，如 truncate 的空间已被重用） |
3 如果数据库创建时间（ SYSDATE-CREATED ）大于 1200 天 , 数据库已经重启且数据表未收集统计信息（ SYSDATE-MIN(LAST_ANALYZED) ）小于 1200 天。
|
a 直接手工删除以上的存储过程和触发器。 b 通过病毒的备份表 ORACHK 恢复 tab$ c 使用 DUL 恢复（不一定能恢复所有的表，如 truncate 的空间已被重用） |
4 数据库创建日期大于 1200 且数据表未收集统计信息大于 1200 天，数据库重启过
|
a 删除 4 个存储过程和 3 个触发器 b 使用备份集把业务表恢复到 truncate 之前 c 通过病毒的备份表 ORACHK 恢复 tab$ d 使用 DUL 恢复（不一定能恢复所有的表，如 truncate 的空间已被使用） |
四 后续步骤
建议客户自行排查连接数据库的开发运维人员的 PL/SQL Developer 安装目录，查找 afterconnect.sql 和 login.sql 文件（文件在安装包解压后所在的目录下）。
其中 afterconnect.sql 文件默认是空白， 大小应是 0 字节，
login.sql 打开后只有一句注释“ - -Autostart Command Window script ”，
如果这两个文件里有其他内容，怀疑是感染病毒的工具，由其确认是否为自己添加相关命令，还是病毒。
建议清空相关脚本内容。
从运维角度来说：
1 做好用户权限的控制，减少数据库被感染的风险；
2 使用正版的数据库工具
3 如果网络上下载的破解工具，检查相关登陆工具的自动运行脚本 清理掉有风险脚本
|
sqlplus 中的 glogin.sql/login.sql toad 中的 toad.ini PL/SQL Developer 中的 login.sql/afterconnect.sql |
4 定期执行上述 sql ，检查数据库是否近期有被感染
5 数据库定期做备份，并建议在备份集不放在服务器本地
