Database Reference
In-Depth Information
It will take a very long time to crack a passphrase by brute force, but that time can be shortened considerably
if the attacker can count on the phrase consisting entirely of dictionary words and common abbreviations. Thus,
it's good to take the concept of a strong password philosophy and apply it to passphrases as well. An example is to
combine the passphrase and password concept into a Passphord. This is a passphrase with a password included in
the phrase, as in
“This is a secure P4ssph0rd!”
There is an aspect of “cat and mouse” psychology that occurs with passwords. In order to more quickly guess a
user's password, a professional attacker will profile the victim, their role and interests, and the organization for which
they work. Creating a hybrid password file from keywords unique to the company's website and Wikipedia entry will
shorten password guessing during a pentest considerably (a pentest being an authorized audit of how easy it is to
break into a network). So, for example, ACME's website shows that they make widgets, and unsurprisingly the root
password for their web server is “widget1!.” This concept has been automated into the “Who's Your Daddy” password
profiler at the URL below:
Raising the Decryption Bar
In addition to “cat and mouse” trends, the field of Oracle security is seeing a lot of “bar raising.” For instance, with
authentication encryption, Oracle has steadily increased the bit length of encryption keys used by O3LOGON and
then O5LOGON. We have seen the stealth attack against O5LOGON, and the fix is to use 12c authentication protocol.
Unfortunately, 12c authentication protocol is also vulnerable to using a user's password hash to decrypt a packet
capture of their logon in order to gain the plaintext, as shown by the example below:
root@orlin $ ./oradecrypt12c -s E0E2E8A644437AF1AF826BDA694F788888D2CF36E11D83B08794AFE86B11FC26B15
6847707A90CFED7EFC4255AD2B3BF -c 02D999F2C6025C9917F82D895626FFAF12F8749AE658450961F4654956A0D731
EFD1DEF66096FA6A50DC3627768AC617 -a 270862B29FC8C613C315CF1F7E3E9C07428F2058383A748827770489165F5E08
-h 492976D589156D42A26FBC1A4A5A42FA3F332F0EA031B4F508159B81FF940B71BC2DEA6D0AF16FEA1A15116B261D3B146F
E49D5C34D049DD11EC422611F85A2C1BAF25A4E229BD232B13B0437BD42DE4
The AUTH_SESSKEY server is:
A2505EB919AE4AFB33AFFF3C647DBE39E2DEEE656CC164E69CBE73D11AE5690B945C559E165E3A88A6ACE7955AF15
The AUTH_PASSWORD encryption key is:
5DC1AE2D4C083ABEB49207598C35D447DBAF3BE74E9140567D931C6CE47EEC
The password is: Test1234
EA619641CFF531EB5327EC7E73F43CE54657374313233348888888898982993E00000000000D8F82993E00068142DADFF7F00
We will detail this attack and the proper defense in chapter 10. That chapter will also include unpublished
research from the information security community.
DBLink passwords in 12c are also decryptable, as shown here:
[oracle@orlin ~]$ python dblinkdec.py 063B63F52FC4F52B9561ABF8F7F78169ED5195ABF5BA0F4739C8F75CAE5698
AC580D657DE09FE9AF5A4F3FD0D9BCEBB9BFF6164020F9E9F08C32228529795B8ADCB332F9E0F8D9DFA7F1B1B74280795C0
4797F349626FB141D19590C7C0B1F29D63B48E35661120EE2B5BEDAB291B19113F56D5C30516000CF8CEE5AA453DE66
The link password is: Pw123!
Chapter 10 will detail the above and show the recommended defense. These trends are predictable. New
encryption becomes decrypted. The age-old problem of where to hide the key still pervades. Therefore it is imperative
that DBAs do not use privileged accounts for DBLinks, and they must be sure to use a unique password for each link.
Additionally, access to password hashes should be restricted. This is being made easier with improvements such as
omitting SELECT privilege on
sys.user$
from the
SELECT ANY DICTIONARY
privilege in 12c. What is more concerning
as a general trend is the ambiguity of the security risks involved in the “cloud.”
