In today’s world of global economy companies recognize a growing need for a single point of responsibility for all security aspects. More and more companies acknowledge a growing need for a single point of accountability for all security aspects by creating the position of information security officer (ISO). One of the main tasks of ISO is to protect companies’ main asset - the data. An ISO has to recognize that for any intruder there are two ways of stealing the data - while in transmission or directly from the database. Traditionally, the main emphasis has been placed on network controls to prevent unauthorized access, and to a lesser extent, protecting data in transmission. However, database security is often overlooked.
While the application is in development and production, several teams share the responsibility of enforcing an application security - architects and developers create multiple security mechanisms that are enforced from UI and database (on an individual schema level); a network group implements network controls; DBAs are in charge of the database's availability and backups. It is often assumed that DBAs are responsible for the overall database security. However, the DBAs only operate with data files, and likely have limited or no business and application knowledge. They often do not know the data flow, roles and user relationships and application dependencies. Thus, there is no one whose job is to make sure that the database as a whole is secure. The lack of clarity creates a gray area in the database protection. This is where ISO and his/her group should “step to the plate” and work with everybody to close the gap.
Working on an assignment as an ISO consultant, I was given the task of internal database penetration testing to answer the following questions: How secure are the databases? How much damage can a malicious user do? How knowledgeable does this culprit have to be? In this test we wanted to concentrate on the internal testing to get network penetration factors (data in transmission) out from the equation.
Since it was an internal security test, I logged into the system as any regular employee would do and tried to connect to one of Oracle databases with famous scott/tiger credentials. I was glad that my attempt failed as well as some other guesses. Then I had another idea that proved to be correct - I went on the Internet looking for default passwords. Within a couple of seconds I found several Web sites that had lists of default users and passwords starting from very early versions of Oracle. I tried a couple from that list, first very obvious and well-known, and then the ones that I did not know. One of them let me right into the database. So, with that first “success,” what can an intruder do, and how bad can the damage can be? I decided to look around and turned on my imagination. Since I was under the impression that I was just using some Oracle default user ID, I did not even look at the current schema. To start with, I was able successfully run
select * from all_users;
With that, I knew all valid users and could try to use brute force to guess the passwords. If their passwords are as obvious as the default, then the hacker could get into more than one schema and access and manipulate the data. It could take a long time before anyone would notice the changes, and if the auditing is not turned on, it could be very hard or even impossible to undo them. And even if the intruder did not make any changes, it’s not good that he could look at the data. As bad as it sounds, unfortunately there was more.
If this user has unlimited tablespace, he could create large tables, which would fill the whole tablespace. This would prevent any normal table growth (valid DMLs - all inserts and some updates - will fail). But even this is not all. The hacker could create fake tables, and run big selects from them (or create Cartesian product selecting from existing ones). This could lead to slow system performance and potentially denial of services to customers (DoS). In this case, DoS could be happening not only on this database or server but on all other resources that are connected to this server. It could start a “chain reaction,” slowing performance of multiple servers linked to the affected machine (common when linked servers and triggers are used to synchronize data).
If you are as unfortunate as my client and the hacker acquired DBA rights, by running the statements below he could get a list of all files that comprise the database, copy them into removable media and “play with it” in the comfort of his home:
select * from v$datafile;
select * from v$controlfile;
I was surprised at how much harm could be done with such little effort. Obviously, a creative and experienced hacker could come up with many more interesting and much more damaging scenarios. In the case of my client, it turned out that coincidently a user that matched an Oracle default was created on a development server. It was later by mistake propagated to production.
The moral of this story is - security measures have to be taken very seriously.
Management often puts the main emphasis on system functionality, without realizing that security constitutes basic system functionality. Every step of the security design - selecting passwords, granting privileges and roles should be well-thought-out.
You might be smiling at this point and thinking that your system is well-protected. Let's hope you are right, but better safe then sorry. Do a “safety check” - you might be surprised.