Databases are the fundamental part of any data oriented project. An organization's data is kept in the database. The whole working of your organization depends on the database. Millions of people access your database in order to get information. What if your database gets infected by a database worm? Will your work come to an end? Is there any solution? Will worms ever come to an end?

There are lots of questions but answer is only one that for each passing day worms are becoming more powerful and more resistant. Most of the database worms target the database vulnerabilities and therefore we should always follow the good practices to ensure our database security.

In this article I am going to discuss some of the viruses that infect databases.

The SQL Slammer worm

The SQL Slammer worm is also known as Sapphire, w32.SQLexp.worm, and Helkern. The SQL Slammer worm is only 376 bytes of computer code so it can send itself in a single data packet.

The SQL Slammer worm is able to remotely compromise a vulnerable system. It swamps computers on internet with a copy of itself. The SQL Slammer worm targets the systems that are running SQL Server 2000 and/or Microsoft Desktop Engine (MSDE) 2000.

Prevention:

•  Reboot the infected system, however this solution does not guard against infection again at a later time.

•  Patch the systems by installing SQL 2000 Service Pack 3.

•  Until a patch can be installed, system administrators may block the following SQL server ports at their firewall/gateway:

ms-sql-s 1433/tcp #Microsoft-SQL-Server
ms-sql-s 1433/udp #Microsoft-SQL-Server
ms-sql-m 1434/tcp #Microsoft-SQL-Monitor
ms-sql-m 1434/udp #Microsoft-SQL-Monitor

•  McAfee, Symantec, and Trend Micro have removal tools available for systems infected with SQL Slammer.

The SQL Spida worm

The SQL Spida worm is considered to be the first successful worm to propagate through databases. The SQL Spida worm propagates via Microsoft SQL Server installations with administrator accounts that have no passwords defined.

The worm searches for servers running SQL Server by scanning for port 1433, which is the SQL Server default port. If the worm finds a server, it logs on with a blank (NULL) sa password. The sa log-on gives the worm administrative access to the computer. If successful, the worm broadcasts the address of the unprotected SQL Server database on an IRC channel. It then tries to load and run an executable file. Depending on a given system setup, the worm can get access to other computers.

Prevention:

•  Change the sa account password so that it is not blank or easy to guess.

•  Change passwords for all the accounts on infected machine.

•  Get all of the latest Service Packs and Hotfixes from Microsoft to help prevent general worm infection.

Voyager Alpha Force

In 2001 a Microsoft SQL Server worm known as Voyager Alpha Force was found. "Kaiten" is a Malicious Code that is installed by exploiting null default passwords in Microsoft SQL Server. Various sources have referred to this malicious code as W32/Voyager, Voyager Alpha Force, and W32/CBlade.worm. Voyager Alpha Force never gained critical mass and fortunately died out without causing any harm.

Prevention

•  Set a non-null sa password

•  Use Ingress filtering which manages the flow of traffic as it enters a network under your administrative control

•  Use Egress filtering which manages the flow of traffic as it leaves a network under your administrative control.

MySQL bot

MySQL bot or SpoolCLL is a malicious program that infects computers running the Microsoft Windows and MySQL. The worm gets initial access to a database machine by guessing the password of the system administrator, using a long list of common passwords included in it. It then uses a flaw in MySQL to run another type of program, known as bot software, which then takes full control of the system.

Forbot Variant

Forbot Variant is a version of a common network worm named Forbot. It infects machines by exploiting loosely secured MySQL installations running on Windows machines connected to the Internet. It could infect machines running a wide range of database applications that use MySQL.

Once the worm gains access to the MySQL root account, it uses the MySQL UDF Dynamic Library Exploit to upload and install malicious code to the infected system. The exploit allows an attacker with administrator permissions to expand the default functions. Systems infected with the new Forbot variant connect to an IRC channel that is controlled by the worm author and receive instructions through that channel.

Prevention

•  Strengthen the root account password.

•  Make sure that MySQL does not allow remote logins for the root account.

•  Use a firewall to prevent direct access to port 3306 from the Internet.

UDF Worm

The UDF Worm is self-propagating code that finds MySQL servers running on Microsoft Windows with poor firewall and password security. This worm is Microsoft Windows specific.

The UDF Worm looks for MySQL servers running on Microsoft Windows that have been exposed to the internet and have either weak or no passwords installed on the account named root. Once it finds an account it installs a UDF, and then uses that machine to infect other machines.

Prevention:

•  You can remove the worm by running the SQL statement DROP FUNCTION app_result; However removing the worm does not secure a compromised machine.

•  Use firewalls.

•  Use strong passwords.

Hybrid (DDoS) worm

Hybrid Worm targets the vulnerability in Microsoft SQL server systems. It combines a distributed denial of service attack (DDoS) with the automated propagation techniques used by worms such as Code Red.

Oracle Worm Voyager

A newly revamped and potentially more dangerous version of the Oracle Voyager worm has been published. The new variant of the worm grants administrator access to public database user accounts. Currently it does not have ability to replicate itself. The worm is written in PL/SQL.

Prevention:

•  Change the Oracle listener from the default port of TCP/1521 (and set a listener password while you are at it).

•  Drop or lock default user accounts if possible. Ensure all default accounts do not use default passwords.

•  Revoke PUBLIC privileges to the UTL_TCP, UTL_INADDR packages.

•  Revoke CREATE DATABASE LINK privileges granted to users who do not need to link to remote databases, including the CONNECT role.

 More Oracle Articles, Database Articles and DBA Tips
   Database Security: Step by step guideline
   Top-N Queries for Oracle - SQL, Some Concerns
   Database Tuning Guide for Third Party Applications
   A Few Things To Know Regarding Databases
   Important Concerns related to Oracle Compression!!