eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
An anonymous hacker has released the first public example of an Oracle database worm.
The proof-of-concept code was published on the Full-disclosure mailing list with the subject line “Trick or treat Larry,” an obvious taunt aimed at Oracle Corp.s chief executive Larry Ellison.
Security experts have already picked apart the code and confirmed that the worm can squirm through Oracle databases with default user accounts and passwords.
Alexander Kornbrust, founder and CEO of Red-Database-Security, described the publication of the proof-of-concept as “a serious wake up call” and warned that the code can be easily modified to cause major damage.
“This version of the worm is not dangerous but anyone can use this as a framework and inject a more malicious payload,” Kornbrust said in an interview with Ziff Davis Internet.
Kornbrust, renowned for his research work around security in Oracle products, published his own analysis of the worm code and made it clear that the use of default usernames and passwords can leave database administrators as sitting ducks for a malicious attack.
He said the worm uses UTL_TCP to send a command to the listener on each IP address in the same net range as the IP the database is on.
If a database is found, the worm creates a private database link and tries to connect on that link using known default username/password schemes.
“At the moment, it just creates a table in the [remote] database if the attack is successful. But, it can be programmed to do much more than that. Its quite easy to replace this payload with a more dangerous payload,” Kornbrust said.
He said the code appeared deliberately “incomplete” to serve as a red flag for database admins who neglect to change the default passwords.
For an attack to be successful, the worm requires the user to have local access. It is not capable of replicating itself.
“This proof-of-concept absolutely works and, in this particular case, Oracle is innocent,” Kornbrust said, stressing that customers are responsible for using strong password schemes in database products.
“In this environment, it is not acceptable to have databases with default defaults. This worm proves that.”
“From my experience, most customers still use default passwords. They may have them changed in some databases, but Id say at least 60 percent of all customers have at least a few databases with default passwords,” he added.
“If someone combines a Windows worm with an Oracle worm, well see a huge attack with enormous damage. The Windows worm can be jumping from one workstation to another workstation worldwide and using an Oracle worm as a payload,” Kornbrust said.
Ted Julian, vice president of Strategy at Application Security, Inc., said the complicated nature of managing multiple databases in a typical enterprise setting creates lucrative opportunities for worm authors.
“In a big company, its safe to assume that 100 percent of admins are running some databases with default usernames and passwords. Its just impossible to keep up with literally thousands of databases,” Julian said in an interview.
Julian, like Kornbrust, expects to see an Oracle database worm squirming one day.
“Eventually, well see someone modify the exploits and launch an attack. This proof-of-concept shows that its getting easier and easier.”
“What if you put in a payload to create an admin account? What if that account is set up to mail information back to an IRC server about all the databases that are infected. What if that account is just set up to hijack data in an automated fashion? That would be a stealthy way of using an exploit to gather data,” Julian added.
Or, a more overt attack scenario could see an attacker use a worm to send a query to a vulnerable database and extract all the results.
“The sky is the limit in that regard, [it] depends on what kind of payload the attacker users.”
In the interim, Kornbrust has a few protection recommendations for enterprise DB administrations:
- Change your default passwords in every database (test/development/education/production)
- Revoke the privilege “CREATE DATABASE LINK” from the (default) CONNECT role (up to Oracle 10g Rel. 1)
- Revoke the public grant from the package utl_tcp if not needed.
- Revoke the public grant from utl_inaddr if not needed.
- Protect your TNS listener with a strong password. On Oracle 10g, always disable local OS authentication and use a strong password instead.
- Change the TNS listener default port from 1521 to a different port.