Oracle Worm Voyager - Analysis of the Proof of concept code
On 20-december 2005 an anonymous poster (email@example.com ) posted an variant of the Oracle Voyager Worm. A quick analysis shows that the worm tries to do the following
On 31-october 2005 an anonymous poster (firstname.lastname@example.org) released a proof-of-concept (PoC) PL/SQL source code of an Oracle worm on the full disclosure mailing list. The worm is using the utl_tcp package to find other Oracle databases in the same subnet and uses private database links to connect to remote databases. The payload is harmless (creation of table called x in the remote database) but can be changed easily.
The initial version of the worm must be started in the database manually but it is possible to use the glogin.sql feature of sqlplus to do this without the knowledge of the (database) user if it is possible to modify the file glogin.sql.
In 2001 there was already a database worm called Voyager Alpha Force for Microsoft SQL Server.
Analysis of the code:
1. Get the current IP address with utl_inaddr
2. Loop via all network addresses in the same address range (xx.yy.zz.220 - xx.yy.zz.-216)
3. Send a tns listener status via utl_tcp to port 1521
4. Retrieve the database identifier (SID)
5. Construct a (private) database link using the SID with some common user/password combinations
(system/manager, sys/change_on_install, dbsnmp/dbsnmp, outln/outln, scott/tiger, mdsys/mdsys, ordcommon/ordcommon)
6. If successful create a table called X on the remote database server
7. Continue loop (2.)
1. Change your default passwords in every database (test/development/education/production)
2. Revoke the privilege "CREATE DATABASE LINK" from the (default) CONNECT role (up to Oracle 10g Rel. 1)
3. Revoke the public grant from the package utl_tcp if not needed
4. Revoke the public grant from utl_inaddr if not needed
5. Protect your TNS listener with a strong password. On Oracle 10g always disable local OS authentication and use a strong password instead.
6. Change the TNS listener default port from 1521 to a different port
Update from Oracle
On Saturday, 5-nov-2005, Oracle informed their customers via an email about the so-called Oracle worm.
Oracle recommends to harden the Oracle databases by locking unused accounts, revoke the privilege "create database link" from the connect role, establish a password management policy and consider a change of the default port 1521. Oracle also recommends to set a TNS listener password.
Keep in mind that the 10g local OS authentication is NOT 100% secure. It is better to disable the local OS authentication in 10g and use a strong TNS Listener password instead.
© 2005 by Red-Database-Security GmbH - last update 10-jan-2005