Database Reference
In-Depth Information
print "@OraCheck\n";#this is a good sid
(@OraResult) = `./oralogonsid.pl -h $host -l orapwshort.csv -S
$OraCheck[8]`;
print "@OraResult\n";
print MYFILE "@OraCheck\n";
print MYFILE "@OraResult\n";
}
}
else
{
print "No Oracle listener at $host\n";
print MYFILE "No Oracle listener at $host\n";
}
$count++;
close (MYFILE);
}
}
//oralogonsid.pl, oralogon.pl and tnscmd10gOneLine.pl are detailed in Chapter 6 with full code
The signature for this type of attack is a single failed logon for multiple accounts at the same time. This can be
seen in
sys.user$,
where many accounts will show a single
lcount
at a similar
ltime
. It is well worth setting up an
alert for this signature and, even better, to create a form of “Native IPS” event to
act
upon the alert—i.e., actually fix the
problem. We will do this in Part II.
Attacking the Standby Database
Main production systems in security-sensitive organizations are likely to have regular password checking through a
dedicated-state monitoring system like Symantec's ESM. ESM is a host-based agent that checks configurations daily
against a security policy and reports violations centrally.
An alternative for a knowledgeable attacker would be to carry out a similar remote password-guessing process
on the standby rather than on production. Oracle's Replication solution has a standby configuration called Active
Dataguard (ADG), which enables the standby to be open to SELECTs in READ-ONLY mode. This is very useful, as it
means that business reporting can be load balanced between standby and production, and if production goes down
then there is an immediate alternative. The problem is that the standby being READ-ONLY means that it cannot count
Failed Logins and therefore does not know if it is the victim of a remote brute-force attack. The password on standby is
the same as the password on production, so the result is that an attacker can quite quickly brute force all the accounts
on ADG and then log in to production with the same credential. Not good. ADG for new 12c has the ability to write to
Global temporary tables so this issue should be fixed.
The solution to this problem is to set more-complex passwords than normal and to carry out listener logging
and/or other monitoring. Careful internal routing and firewalls can also reduce the risk. Putting ADG in a network
silo partly defeats the purpose of making the standby available for “production” business reporting, but it should be
possible to reduce risk partially by DMZ'ing the ADG server so only known legitimate applications are allowed access.
If an attacker can't get into the standby then another option is to attack the backups.
