Oracle 恶意攻击问题分析和解决(一)

常见攻击类型

1 被恶意篡改的数据库安装介质

此类攻击属于恶意破坏,攻击数据库后通常不会索要比特币等,当然也不会提供解决方案。

2 被恶意篡改的PL/SQL Devloper安装介质

此类攻击属于勒索病毒攻击,被攻击后会在告警日志中提示向某个邮箱发送固定数量的比特币,然后提供解锁数据库方式(当然也不一定可信)。

本次主要介绍第一种情况

问题现象

被恶意篡改的数据库安装介质问题现象

Windows环境下数据库,如果安装了 被恶意篡改的数据库安装介质,当攻击程序启动后,会清空数据库tab$表。

问题现象是当 通过PL/SQL工具数据库时,报错:

ORA-00600:internal error code,arguments:[kzrini:!uprofile],[],[],[]

三  影响范围

当前数据库处于open状态(Windows平台下可以open数据库,Linux平台下无法open,只能mount数据库),但是所有非sys用户均无法连接数据库,连接提示报错ORA-00600[kzrini:!uprofile]后连接中断,最终导致数据库无法提供服务。

四  数据库环境

操作系统:Windows Server 2008 R2

数据库版本:Oracle 11.2.0.4.0

五  问题分析和定位

5.1 查看错误日志

查看告警日志,有如下错误:

ORA-00600: internal error code, arguments: [kgmfvmi#3], [], [], [], [], [], [], [], [], [], [], []
ORA-07445: exception encountered: core dump [kgmdelsis()+121] [ACCESS_VIOLATION] [ADDR:0x10] [PC:0x102F7F9] [UNABLE_TO_READ] []
ORA-00600: internal error code, arguments: [kzrini:!uprofile], [], [], [], [], [], [], [], [], [], [], []
ORA-00604: error occurred at recursive SQL level 1
ORA-00957: duplicate column name

5.2 问题分析

根据错误号ORA-00600: internal error code, arguments: [kzrini:!uprofile], [], [], [], [], [], [], [], [], [], [], []

初步怀疑数据库tab$损坏导致以上故障。

检查tab$表数据量为0。

此类攻击通常是通过恶意植入DBMS_SUPPORT_DBMONITOR触发器和DBMS_SUPPORT_DBMONITORP存储过程方式,攻击数据库tab$表;

检查当前数据库确实存在这两个对象,正常情况下是不会存在这两个对象。

SET LINE 150
COL OBJECT_NAME FOR A35
SELECT OWNER,
       OBJECT_NAME,
       OBJECT_TYPE,
       TO_CHAR(CREATED, 'YYYY-MM-DD HH24:MI:SS')
  FROM DBA_OBJECTS
 WHERE OBJECT_NAME LIKE 'DBMS_CORE_INTERNA%'
    OR OBJECT_NAME LIKE 'DBMS_SYSTEM_INTERNA%'
OR OBJECT_NAME LIKE 'DBMS_SUPPORT%';

###存储过程:DBMS_SUPPORT_DBMONITORP

###触发器:DBMS_SUPPORT_DBMONITOR

查看存储过程和触发器攻击过程如下:

1 DBMS_SUPPORT_DBMONITOR触发器定义了,当数据库启动时会自动执行 DBMS_SUPPORT_DBMONITORP 存储过程。

2 当执行 DBMS_SUPPORT_DBMONITORP 存储过程时,会检查当前时间距离数据库创建时间是否达到300天,如果大于等于300天,会以CTAS方式对sys.tab$表进行备份,备份的表名为ORACHK加10位随机不重复的字符串,然后执行delete sys.tab$;删除tab$表数据,并提交删除操作,生成检查点。

存储过程和触发器如下( 请勿用于其他用途):

存储过程:

触发器:

5.3 问题定位

由于数据库多了两个对象,存储过程 DBMS_SUPPORT_DBMONITORP 和触发器DBMS_SUPPORT_DBMONITOR,恶意破坏了数据库基表tab$,导致数据库无法使用。

六  攻击可能途径

此类事件可能攻击途径有如下方式

6.1 非官方途径获取的数据库安装介质

使用非官方途径获取的数据库安装介质,可能会导致恶意代码植入破坏数据库。

检查数据库服务器上的安装介质,分别对两个介质生成SHA1值。

可以使用windows系统自动的certutil工具生成安装介质的SHA1值,例如:

查看官方介质SH1值,进行对比

http://support.oracle.com

数据库/GI PSU,SPU(CPU),Bundle Patches 和 Patchsets 补丁号码快速参考 (Doc ID 1922396.1)

曾经遇到过第一个介质P13390677_112040_MSWIN-x86-64_1of7.zip对应的SHA1值不一致,怀疑安装包文件被恶意篡改。

检查安装包 P13390677_112040_MSWIN-x86-64_1of7.zip解压后文件

database\stage\Components\oracle.rdbms.dbscripts\11.2.0.4.0\1\DataFiles\filegroup2.jar\rdbms\admin\prvtsupp.plb

以及数据库安装后 $ORACLE_HOME\rdbms\admin\prvtsupp.plb文件

D:\app\Lenovo\product\11.2.0\dbhome_1\RDBMS\ADMIN\pvtsupp.pLb

发现 prvtsupp.plb 文件被恶意篡改了

正常文件内容只有如下内容:

而当前的文件多了下面两段内容

存储过程 DBMS_SUPPORT_DBMONITORP 被加密了

使用DfUnWraper工具进行解密

存储过程为:

6.2 盗版或绿色破解版PL/SQL Developer

使用盗版或绿色破解版PL/SQL Developer工具或其他破解版工具连接数据库,可能会导致恶意代码植入破坏数据库。

Oracle PL/SQL Dev软件中,里面的一个文件 A fterconnet.sql

例如:

D:\cjc\plsql\PLSQL Developer 8.0.3.1510\AfterConnect.sql

其中afterconnect.sql的大小应该是0字节,login.sql打开后只有一句注释“- -Autostart Command Window script ”,如果这两个文件里有其他内容,应怀疑是病毒 ,具体排查方法见第二篇博客,本次只讨论第一种场景。

七  数据库修复建议

7.1 无法通过ORACHKXXX备份表进行修复数据库

通过攻击的存储过程信息可知,在恶意删除tab$基表前,对tab$进行了备份,备份的数据存在新建的ORACHKXXX表中。

但是由于tab$表并不是普通的堆表Heap table,而是聚簇表cluster,并且和C_OBJ#通过OBJ#列进行了关联,从而导致了即使通过之前备份的ORACHKXXX表恢复tab$数据库,关联的递归数据也并没有恢复,数据库仍然无法使用。

查看tab$表定义如下:

SQL> select * from (select * from SYS.BOOTSTRAP$ order by line#) where rownum<=5;

在测试环境下测试,通过ORACHKXXX表恢复了tab$表,但数据库仍然报同样的错误,问题没有解决。

7.2 建议修复方式

常见修复方式是通过第三方修复工具DUL等,或oracle内部工具bbed,直接修改数据块信息,去掉tab$对应数据块内删除标记,但Oracle官方并不建议直接修改数据块,可能会引发其他未知的错误,有一定的风险。

使用DUL恢复tab$方式如下:

利用dul工具直接更改tab$表数据块,去除行删除标记

上传gdul包到服务器(win)

替换license _key.dat

停库,备份SYSTEM01.DBF

将原SYSTEM01.DBF文件拷贝到D:\CJC目录下

执行dul

查看帮助信息

查看数据文件信息

Remove delete flag from TAB$ blocks.

已恢复tab$表2967行数据。

system01.dbf替换原文件

禁用所有触发器

alter system set "_system_trig_enabled"=false scope=both;

重启数据库后,数据库恢复正常

删除这两个对象

drop TRIGGER SYS.DBMS_SUPPORT_DBMONITOR;

drop PROCEDURE SYS.DBMS_SUPPORT_DBMONITORP;

7.3 检查数据库是否被攻击

SELECT OWNER,
       OBJECT_NAME,
       OBJECT_TYPE,
       TO_CHAR(CREATED, 'YYYY-MM-DD HH24:MI:SS')
  FROM DBA_OBJECTS
 WHERE OBJECT_NAME LIKE 'DBMS_CORE_INTERNA%'
    OR OBJECT_NAME LIKE 'DBMS_SYSTEM_INTERNA%'
OR OBJECT_NAME LIKE 'DBMS_SUPPORT%';

八  如何预防此类问题

8.1 建议使用正版连接工具连接数据库

建议使用正版连接工具连接数据库,例如使用正版toad连接数据库,不使用绿色破解版等连接工具连接数据库。

8.2 使用官方正版或正规途径获取的数据库安装介质

使用官方正版或正规途径获取数据库安装介质,避免安装介质被恶意篡改。

欢迎关注我的微信公众号"IT小Chen",共同学习,共同成长!!

请使用浏览器的分享功能分享到微信等