|
January 4, 2005
This is a modified version of the Voyager worm code that was released on Full-Disclosure. Initially, the code tries to grant DBA privilege to PUBLIC by exploiting a known vulnerability in the VALIDATE_STMT procedure of the DRILOAD package. The user CTXSYS owns the package. Since the procedures are not defined with the 'AUTHID CURRENT USER' option, the injected SQL is executed under the privileges of CTXSYS (a DBA).
Regardless of whether the code successfully grants a DBA role to public, it proceeds to create an AFTER LOGON trigger. The trigger selects a random value between 1 and 100. If the value happens to be 32, it sends a HTTP GET request for the URL www.google.com/search?hl=en&q=startc0GtJBi1+full-disclosure&btnI=I%27m+Feeling+Lucky.
The intention is to fetch the worm's code posted on the Full-Disclosure list's website. The PL/SQL code is extracted from the response and executed. Consequently, the code can be re-run later.
Next, the code extracts database usernames and password hashes from the DBA_USERS view. The code then scans the entire subnet to which the host belongs. It repeats the following actions for all the IP addresses in the range.
If the IP address happens to be a multiple of 100, the code tries to send a mail with the extracted hashes to larry@oracle.com through the SMTP server at smtp01.us.oracle.com. It tries to send the same hashes to oracle@<random IP> using the random IP as a SMTP server, as well.
The code then sends the "show log_directory" command to the LISTENER to extract the ORACLE_HOME directory value from the response. Next, the code sets the location of the log file is to $ORACLE_HOME/sqlplus/admin/glogin.sql using the 'set log_file' command. SQLPlus executes this file for every successful user login.
Since all failed listener commands would normally get logged to this file, a SQL string 'alter user mdsys identified by mdsys;' is sent in the listener command in order to log the same to the glogin.sql file. Subsequently, the next time a DBA signs on, the glogin.sql file is executed and changes the password for user 'mdsys' to 'mdsys'. The log file is then reset to the default $ORACLE_HOME/network/log/listener.log.
The code then sends a 'status' command to extract the SID name. Next, the code attempts to create a private database link using a set of select default usernames and passwords. At the end the code issues a 'stop' command, which, if successful, cause a DoS against the database.
In summary, this code does not seem to have implemented a spreading mechanism. As in the previous version, it creates the private database link, but the procedure to spread is missing. The improvements over previous version include the use of a known vulnerability in the VALIDATE_STMT procedure to grant DBA to PUBLIC. The code, with a 1 in 100 chance of execution, implements a Google search for its own code in an AFTER LOGON trigger. The intention is probably to rerun the code at some later point in time. As the subject of the initial posting on Full-Disclosure indicates, the latest version of the worm code tries to mail the username and password hashes to larry@oracle.com and oracle@<random ip>. The last, but important, change from the previous version of Voyager is that it tricks the listener to reset the password for user 'mdsys' to 'mdsys' by abusing the 'set log_file' command. The clear intention is to increase the chances of successfully creating a private link to the database.
How Application Security Inc. Can Help You
As the leading provider of database security solutions, we have published instructions for configuring AppRadar to detect the worm in your environment, and created the AppDetective "New Variant Oracle Voyager Worm" security policies, which will automate the assessment of implementing the recommended protection fixes. |
