Database Reference
In-Depth Information
Crucially, the way to prevent this attack from happening to your own organization is to do the following:
1.
Treat
tnsnames.ora
as a security-sensitive
piece of data.
Do not publish the file
widely, especially not on Internet-facing pages. Perform a Google search on your own
organization to verify that your
tnsnames.ora
files are not visible.
2.
Regularly check for default accounts, as they can regress.
Lock such accounts, change
their passwords, and preferably drop unused default account schemas. See the following
URL for information on past default password regressions:
3.
Ensure the SYS password
is complex.
In 11g and in 12c beta, the SYS password is
immune to the complexity function. Thus you have to physically check the complexity
manually or put a separate privilege-management service in charge of the SYS account.
My experience is that universities and SMEs are likely to be vulnerable to having their
tnsnames.ora
files found
through an Internet search, but commercial organizations and banks rarely are. However, it is possible that even
banks are vulnerable to this attack due to data-center moves, mergers, and faulty firewall configurations caused by
overly complex and difficult to read rule sets.
Attacking without tnsnames.ora
What follows is the process used to attack an Oracle server from another host on the network without credentials:
1.
Port scan for TNS.
A full port scan of a single host takes a long time, so on a large
network an attacker will look to quickly find weakly secured hosts-i.e., TNS on TCP 1521,
and then use the credentials and trusts on that low-value machine to “
pivot
” over to
other more valuable assets within the organization. It is likely that there will be similar
passwords between development and production, for instance, but dev is likely to be less
well secured, so an attacker will pivot from dev to production. Servers with ambiguous
ownership tend to be the initial foothold, as they have not been maintained, so striving
for 100% coverage rather than 100% depth is important for a compliance program. For
the purpose of checking coverage, we use tnsping supplied with Oracle Software install to
detect Oracle listeners on a given subnet in the Perl Audit Tool, coming up later.
2.
SIDGuess.
In order for an attacker to attempt default username/password combinations
they first need to guess the name of the database. One irony of Oracle security is that the
complexity of the database name has historically been limited by DOS compatibility; i.e.,
SIDs are eight characters long or less for Windows. Having said that, most DBAs don't
use the full namespace of the DB name anyway, as it has not been considered a security-
sensitive configuration.
It is, however, and a very important one at that, so a strong
recommendation of this topic is to use longer, more complex, but still memorable SIDs.
3.
Username/default guessing.
After the port and SID have been gained it is simply a case of
making a single username/password guess for each commonly weak default account.
The above 1-2-3 process can be automated into a Perl Audit Tool (PAT), shown below and expanded upon in
Chapter 6. The code below scans a given Class C network on port 1521 and attempts to connect with default accounts.
This is a useful verification to check that security configurations have actually been implemented. Note that high-
security organizations will have internal and external honeypots to catch unauthorized scanners. On the other side
of the coin, it is a good idea to allow DBAs to scan their DB network in order to verify compliance and licensing. In
Chapter 6 we will work through how to set up this code on your machine so you can carry out your own internal audit.
