Welcome to Volume 3, Issue 23 of The Internet Security Conference newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me.
Enjoy, and be safe,
Dave
Editor's Corner
I routinely lurk on several security mailing lists and await the inevitable "here's an interesting hyperlink about foo". Recently, "foo" was Oracle, in the form of a very extensive discussion of Oracle exploits and countermeasures at http://www.pentest-limited.com/oracle-security.htm. Exploiting and Protecting Oracle has been very well received throughout the security and Oracle communities. To date, over 4000 visitors, including several leading Oracle security experts, have downloaded the paper and provided comment and contributions to the author, Pete Finnigan.
I invited Pete to provide an executive summary for Insight. This summary attempts to convey the salient aspects of Pete's paper. Pete and I hope this summary encourages you to read this most extensive paper in full.
Pete Finnigan, PenTest Limited
There are numerous books about security and many about Oracle, but so far only two about Oracle security. In general, there is little information on the Internet about Oracle Security that doesn't just regurgitate the manuals and sales literature. EXPLOITING AND PROTECTING ORACLE, an ongoing white paper published by PenTest, fills part of this hole. It also highlights the need for application security and to understand that the data used within a business is probably not secure.
There are a number of security holes known in Oracle. These are reported in a number of places including Oracle's OTN website. However, the main cause for concern in the Oracle (user) community is the unfortunate lack of security awareness within Oracle data base administrators (dba's) and developers. This is most evident when dba's configure and maintain their databases, and developers incorporate Oracle into applications. This paper highlights the main components of Oracle and describes the most commonly exploited configuration errors. An objective of this paper is to help the dba and his staff to think like an attacker so that he (they) may become aware of, and eliminate, potential vulnerabilities in Oracle configuration.
Most of the issues with Oracle security are due to misconfiguration and lack of awareness. One other major issue with database security is that an attacker is most frequently an insider who doesn't need to steal a super user account to get what he wants. Most of a company's highly critical data is usually accessible from multiple low-level user accounts. This should be the most alarming to companies and should make them sit up and think carefully about the security of their crown jewels: their data!
Oracle's products are now so large and complex, leaving so many possibilities for bugs to be found or misconfigurations to take place. A Wiley hacker can easily find a crack to get what he needs.
Take a typical business using Oracle as the database backend. Application access to the database may occur through SQL*Net, maybe through ODBC, without logging directly onto the host server. The company has implemented its own security using some of Oracle's ideas by creating their own version of roles and administration. They are secure in the knowledge that each group cannot access data that is intended to be accessed by another group. Wrong!
Suppose that an attacker guesses a default user's password, He can then access the database via many of the common tools used to do so, bypassing the company's application and security altogether. He can then enumerate the meta data and find what he needs. Although developers created their own security measures, not much thought has gone into the configuration and security of the database itself. This is a common mistake.
Take the backups - please do! An attacker could quite easily, either by taking insecure file system backups or export files lying around, or by accessing the DR system itself. The dba may not think of these backups as the data, but they are. Even if the backup is secure, a hacker could contact your offsite backup storage company and arrange to courier the backup tapes to your office to be collected by himself. He could then take the tapes and rebuild your database on his own systems at his leisure. It's been done!
What about your Oracle archive logs? If these are not protected, they can be taken and read in an attacker's database using command line techniques or with Log Miner.
Quite often, an enterprise will have a number of machines and databases, Other less secure databases can provide access to a more secure database using database links. For example, most test systems are not as secure as the production system and can be used to learn the structure of your data and to find out usernames and passwords and as an access point to the production system. If Operating System access can be gained, then lots of clues can be found to help access a database, usernames displayed while programs run, usernames hardcoded in scripts, etc.. The list is endless.
It is relatively easy for anyone to get a copy of Oracle, install it, and learn about how it works and how easy it is to misconfigure. Oracle also uses its own proprietary network protocol. Again, clues can reveal what databases exist even by just compromising a client machine on a company network. If the Oracle client is installed, then it's easy for an attacker to access the database using one of the Oracle command line tools or ODBC in Microsoft Excel or Access.
Oracle provides an unbelievable amount of possible default users with known passwords. This is the easiest way for an attacker to get into your system. Ensure that these default users are removed or the default passwords are changed.
Understanding how Oracle works internally can be useful in our goal to think like an attacker. Oracle uses a lot of initialisation parameters and events. Many of these can give an advantage to an attacker, so it's important to turn off anything that's not needed.
There are a number of commands that can be executed to dump internal structures of a running Oracle instance to a trace file, revealing quite alarming data if it can be read. Using a simple command, it's possible to dump the library cache and see any passwords of users that have been added or changed. If a simple initialisation parameter has been wrongly set, then a hacker can read the trace file and get the passwords.
Incorrect permissions or roles granted to arbitrary users can create a chink in your armour and allow malicious actions to be performed. Permitting the CREATE LIBRARY command actually lets an attacker call any OS command, even if he didn't have OS access when he entered the database.
There are many PL/SQL packages shipped with Oracle that have execute access granted to everyone. Using these packages, it is possible for someone to write email, create a TCP connection, and read and write operating system files. Imagine the possibilities, if you will.
Some of these packages, such as DBMS_SYS_SQL, could allow an attacker to create a Trojan to gain escalation of privileges to access the data they need. Some common tools provided as PL/SQL packages, such as the debugger and trace facilities, can help determine what's running from a user application and to work out how to remotely "SQL inject" an attack later.
Utilising a database trigger, it's possible to steal data from a database table that the user cannot even see. Even the Oracle PL/SQL wrap utility that encrypts stored procedures cannot stop attackers from altering the package and creating a Trojan.
I hope that this short summary has interested readers enough that they would want to read the full paper or even to read one of the two books on the subject.
An attacker may wish to steal certain data stored in some nondescript users database schema. He does not need escalation of privileges to oracle or root in the normal sense to achieve his goal. All he may need to do is escalate his privileges from Mr Brown the HR clerk to Mrs Smith the Accounts receivable clerk!!
Remember, the final point is "the important data probably isn't secure". You might have secured the network and the host server and placed everything behind secure firewalls, but a lowly business user account where the password could be easily guessed could provide access to the database without access to the server itself and this could be enough to steal the most critical data. Please read the full document published at PenTest and start to think about how you can protect your data.
© 2001 - 2006 Core Competence & Mactivity, Inc.