| |
 |
|
Oracle Worm may become a threat
Oracle Tips by Burleson Consulting
Don Burleson
|
Oracle security has become more critical than ever before with
malicious hackers exploiting "human error" security holes,
caused by poor DBA security practices. This is noted in
the book "Oracle
Privacy Security Auditing", where Arup Nanda (Oracle
DBA of the Year), made the scary prediction of possible of
web-based Oracle viruses and worms
The "Voyager" worn is a primitive "proof of
concept" worn that was delivered from a British e-mail list
titled "Trick or Treat Larry". This is not a dangerous
worm, but it could be enhanced to become self-propagating.
Click below to see the original publication and the PL/SQL
source code of the Voyager worm.
http://lists.grok.org.uk/pipermail/full-disclosure/2005-October/038290.html
The Voyager worm exploits human errors (i.e. an
under-trained Oracle DBA) has not changed the Oracle user
accounts from their default passwords. Here are the attack
passwords, from the Voyager worm source code:
if iLoop = 1 then
username1 := 'system';
password1 := 'manager';
else if iLoop = 2
then
username1 := 'sys';
password1 := 'change_on_install';
else if iLoop = 3
then
username1 := 'dbsnmp';
password1 := 'dbsnmp';
else if iLoop = 4
then
username1 := 'outln';
password1 := 'outln';
else if iLoop = 5
then
username1 := 'scott';
password1 := 'tiger';
else if iLoop = 6
then
username1 := 'mdsys';
password1 := 'mdsys';
else if iLoop = 7
then
username1 := 'ordcommon';
password1 := 'ordcommon';
While primitive, this worm could be enhanced to
seek-out user and password information in tnsnames.ora and
listener.ora files, making it a real threat. MOSC has
issued
this warning about the Voyage worm, recommending immediate
checks for all databases.
http://MOSC.oracle.com/MOSC/plsql/showdoc?db=NOT&id=340009.1
MOSC suggests these protective acts,
checking for "sloppy" security:
"1) Account lock and expire the
password for unused default database accounts. Review
infrequently used database accounts and consider account
locking, password expiry or setting a more complex password.
2) For database releases prior to Oracle Database 10g
Release 1: you should set an administrative password for the
TNS listener. For Oracle Database 10g Release 1 and later
releases, the default authentication mode for the TNS
listener is local OS authentication, which requires the TNS
listener administrator to be a member of the local dba
group. Setting a password for the TNS listener in Oracle
Database 10g Release 1 and higher simplifies
administration. However, setting a password requires good
password management to prevent unauthorized users from
guessing the password and potentially gaining access to
privileged listener operations. Customers may wish to
consider not setting a password for the TNS listener
starting with Oracle Database 10g Release 1 because the TNS
listener is secure by default without a password in this and
later releases.
3) Revoke the create database link system privilege from
database users who don't require it. Please note that the
default Oracle database role resource is granted the create
database link system privilege. Please note that the
default Oracle database role connect is also granted the
create database link system privilege through Oracle
Database 10g Release 1. (The connect role was modified in
Oracle Database 10g Release 2 to only be granted the create
session system privilege.)
4) Establish password management policies inside the
Oracle database to enforce password complexity, length and
expiration.
5) Consider changing the default port for the Oracle TNS
Listener process from 1521."
According to
DBA Village, the new worm is written in PL/SQL and these are
the Oracle worm access details. It appears that the most
vulnerable database are those prior to Oracle 10g (where default
passwords were used), and where the DBA forgot to lock-down with
new passwords:
-
Obtains the IP address of the server (using
the utl_indaddr procedure)
-
Scans all IP addresses in the same network
range, Voyager checks for active listeners on other servers
(using the utl_tcp procedure to issue "lsnrctl stat"
commands)
-
Each active listener responds with the $ORACLE_SID,
and Voyager now has the three things needed to access a
database via TNS (protocol, IP Address, ORACLE_SID).
-
Voyager then issues a series of logon
attempts using the Oracle installers default user/ID
combinations (prior to 10g). These would include
"system/manager" and sys/change_on_install".
This article suggests that the
Voyager worm might become a threat if it was enhanced to become
self-propagating and deployed:
"Especially worrying about this Oracle concept worm,
compared with the SQL Slammer pest, is that it actually
enters the database and can meddle with the data stored in
it, said Shlomo Kramer, CEO of security vendor Imperva.
"Today, the payload is not malicious. But adding a malicious
payload to it can do enormous damage," he said.
A variant of the worm could erase information or send it
somewhere else, Kramer noted. "The potential impact of this type
of database worm can be very serious," he said.
A hardened database would be protected against database
worm attacks, according to Kornbrust. "A real malicious Oracle
worm could destroy thousands of Oracle databases within hours
and cause a damage of several billion dollars," he said.
|
|
|
and include the URL for the page.
