Virusses are nothing new. Victims are infected by opening a mail attachement or the virus is transported via USB disks and other media. And virusses can replicate themselves by utilizing vulnerabilities in an operating system (mostly Windows) or in applications.
An RDBMS also can become the target of a specialized worm. In 2002 and 2003 the Sapphire/Slammer worm used a vulnerability in MS SQL Server 2000 and the MS SQL Server Desktop Engine 2000 in combination with the default sa password (the admin account of SQL Server). In many organizations this password was never changed. The Sapphire/Slammer worm was able to search other SQL Server databases and quickly infect these. In January 2003 it was this network traphic that brought large parts of the Internet to it’s knees in just half an hour after release.
A proof-of-concept Oracle worm, called Voyager, once appeared on Usenet. It was a bit of pure PL/SQL code that would scan IP addresses for standard Oracle listener port 1521. After that it would try to break in to the databases with default accounts and dito passwords. Fortunately Voyager never got to a production version. But if you ever needed motivation to change default passwords: here is another one.
The worm that now gets all the attention, is Stuxnet. Stuxnet is a devious piece of work. When reading the details about it it’s clear it’s not the work of amateurs. It uses an incredible amount of four zero day exploits. These are vulnerabilities for which at the time there was no patch. A zero day exploit can be bought on the black market for about ten thousand dollars. Yes, buying exploits is apparently possible.
But that’s not all what Stuxnet does. Once a computer on a network is infected, the worm uses the four zero day exploits to spread throughout the network. But that’s not it’s ultimate target. The virus can also be spread via USB devices and it is in this way that it manages to arrive at networks that are not connected to the Internet. Like those of control centers of power plants. Of course it tries to infect those networks also, which isn’t really hard, since software on those computers isn’t necessarely up to date. After all, they can’t connect to Internet for that. Once there, the worm will attack Siemens software that controls PLC’s (Programmable Logic Controlers). And recently the worm decided to sabotage PLC’s in power plants and controllers of centers for oil and gas distribution.
Stuxnet is the next move in a battle that you probably rarely heared from. Behind the scenes there is a so-called cyber war going on between hackers from several countries. Stuxnet is one of the first of those battles that directly attacked industrial targets. It’s doubtful this has been the last time. Though the worm specifically attacked targets in Iran, systems got infected worldwide. It just happens to be that the creators of Stuxnet were not targeting us specifically, but what a counter attack has in store for us, remains to be seen.
We’ll have to learn from Stuxnet. Lesson one: apparently it is possible to infect computer systems that are not in direct contact with the Internet. So why should a database server be completely safe? Today Siemens PLC systems. What will it be tomorrow?
So isn’t the least we could do patching the RDBMS? However, in my experience with Oracle databases they are more commonly not patched than patched.
A common argument not to patch Oracle databases is that “hackers will find nothing interesting on our system” and that “our data isn’t interesting”. “We don’t have any financial data”, DBA’s sometimes tell me. Well Stuxnet wasn’t looking for financial data in the first place. It clearly shows that identity data or financial data isn’t always what drives hackers. So maybe it’s time to revice your patch policy on that new information. Only few know where the next battle in cyber war will be fought.
The more I think about it, the more I see what damage an Oracle worm could do. What about a virus that shuts down all Oracle databases in the western world. “We’ll start them up just as easily” you say? Well, what if this virus shuts it down again until you had enough? Or, how about a virus that attempts to corrupt all Oracle databases in the western world? You did test the restore of your backup, did you?
A Dutch version of this article can be found on the Transfer Solutions blog.