[ISN] Oracle DB Worm Code Published

[InfoSec News]

http://www.eweek.com/article2/0,1895,1880648,00.asp

By Ryan Naraine 
November 1, 2005 

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 [1] 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 [2] 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. It's 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 I'd 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, we'll 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, it's safe to assume that 100 percent of admins are 
running some databases with default usernames and passwords. It's 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, we'll see someone modify the exploits and launch an 
attack. This proof-of-concept shows that it's 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.

-=-

[1] http://lists.grok.org.uk/pipermail/full-disclosure/2005-October/038290.html 
[2] http://www.red-database-security.com/advisory/oracle_worm_voyager.html