Oracle Worm in Pure SQL (PoC)

One of the neatest demonstrations of what's possible in the worm space that I've seen in a while, even moreso than the MySpace worm, is this gem: a worm which attacks Oracle servers using default accounts and passwords, but does so in pure SQL. In a post to the Full Disclosure list, the author, identified as "oracleworm@hushmail.com" writes, "Voyager Beta worm - not complete - maybe someone else has time to look at it". Looking over the worm, we see the following features (note, this is a course-grained analysis, I'm not an Oracle DBA and I don't fully understand Oracle's SQL procedures):

• It snarfs the local IP address, lops off the last octet and replaces it with the value of '220'. This means if you're local Oracle server is on the host 1.2.3.4, it will start with 1.2.3.220.
• It attempts a TCP connection to TCP port 1521, which is where the Oracle connection service listens. This is, I believe, akin to TCP port 1433 on an MS SQL system, or 3306 on an MySQL system. This is where you would make a connection for a  remote, TCP-based SQL client.
• It then tries  a series of usernames and passwords: 'system'/'manager',  'sys'.'change_on_install', 'dbsnmp'/'dbsnmp',  'outln'/'outln', 'scott'/'tiger',  'mdsys'/'mdsys',  'ordcommon'/'ordcommon'.
• If it can authenticate, create table 'X' with column 'Y', it does not appear to transfer the payload.
• The IP address to connect to next is decremented, unless it falls below a.b.c.216 (ie 1.2.3.216) and the process is repeated.

Simplistic, but it proves the point. Several years ago an MS-SQL worm, SQLSnake, spread by looking for MS-SQL instances with the 'sa' account with a NULL password. That one was written in non-SQL languages (JavaScript and various compiled binaries, if memory serves me correctly). In fact, a new variant of Spybot spreads to MS-SQL servers using weak username and password combinations, this trick still works. This Oracle worm is written in pure SQL, so no random processes would be found on the system, just normal SQL actions and processes. However, it's slow, because it can't thread the connections to parallelize the scanning and can't scan prior to launching attacks. It's going to have to wait for the TCP connections to time out or deal with resets.

This is just begging for someone to finish the job and release a full-scale worm. If you doubt that it could be done, consider this. The DBMS_RANDOM package, ie 'dbms_random.value(min, max)', provides a simple interface to generate random values. All one would have to do is wrap that in a better username/password dictionary, some declarative logic in SQL to perform whatever type of connection scanning you wish, be it 'island hopping', pure random, or what have you and ... you have a fully fledged worm. Now imagine dropped tables, altered values, or stolen data.

If you're an Oracle shop, make sure that you restrict TCP port 1521 (and all Oracle ports) to the servers from unauthorized networks (ie the Internet at large) and clean up those default accounts. You'll go a long way towards defeating such simple attacks.

Update: Be sure to read the tips posted to Oracle Worm Voyager - Analysis of the Proof of concept code on the Red Database Security website.