320 likes | 337 Views
How Safe are Oracle Passwords? Quick Tip Session UGF9198 Troy Ligon. Who is Troy? Over 35 years experience in the IT field Focused on Oracle systems since 1983 (version 3) IBM – Developer Robot Communications and Complier Design Ligon Solutions – President and CEO
E N D
How Safe are Oracle Passwords? Quick Tip Session UGF9198 Troy Ligon
Who is Troy? • Over 35 years experience in the IT field • Focused on Oracle systems since 1983 (version 3) • IBM – Developer Robot Communications and Complier Design • Ligon Solutions – President and CEO • CitiBank – VP Global Database Systems • PriceWaterhouseCoopers – Senior Principal DBA • Nielsen – Principal Architect • President of the SOUG in Tampa, Florida • IOUG Collaborate Track Manager for High Availability track
Authentication Methods Password: • Stored in the database Externally: • O/S Authentication (OPS$) • as ‘PKI_Cert_Distinguished_Name’ (from ssl wallet) • as ‘Kerberos_Principal_Name’ (from Kerberos server) Globally (LDAP): • Shared Global Schema in Enterprise Directory • Schema in Enterprise Directory Distinguished Name
Classic Password Attacks • Guess • Social Engineering • Watching the keyboard (shoulder surfing, camera) • Keylogger (software, USB, built into the keyboard) • Network sniffer (wireshark) • Dictionary attack (checkpwd – Red Database Security) • Brute force attack (woraauthbf – László Tóth) • Rainbow Table attack (ophcrack – Objectif Sécurité) • Dictionary / Rainbow Table Hybrid attack
What’s the Big Deal? With a simple PROFILE setting, wouldn’t the account get locked due to too many failed login attempts?
What if I have access to USER$? ORA10g: sys.dba_users.password = pre-11g version, case-insensitive hash ORA11g: sys.user$.password = pre-11g version, case-insensitive hash sys.user$.spare4 = SHA1(pwd concat with salt) concat with salt select password hash10g, substr(spare4, 3, 40) hash11g, substr(spare4,43,10) salt from sys.user$ where name=&USERNAME;
Of Course it’s Easy if I’m SYS! What if I don’t have access to the database?
Stealth Password Cracking Vulnerability Esteban Martinez Fayo – AppSecInc.com
http://arstechnica.com/security/2012/09/oracle-database-stealth-password-cracking-vulnerability/http://arstechnica.com/security/2012/09/oracle-database-stealth-password-cracking-vulnerability/
https://threatpost.com/en_us/blogs/flaw-oracle-logon-protocol-leads-easy-password-cracking-092012https://threatpost.com/en_us/blogs/flaw-oracle-logon-protocol-leads-easy-password-cracking-092012
https://threatpost.com/en_us/blogs/flaw-oracle-logon-protocol-leads-easy-password-cracking-092012https://threatpost.com/en_us/blogs/flaw-oracle-logon-protocol-leads-easy-password-cracking-092012
What does this Look Like? After the client sends its username, the server responds with the AUTH_SESSKEY and AUTH_VFR_DATA:
So How Would This Work? • Get the SALT (available through AUTH_VRF_DATA field) • Get the encrypted server session key (available through AUTH_SESSKEY field) • Brute force the AES 192-bit encrypted AUTH_SESSKEY to determine the SHA-1 password hash • Once you have the SALT and the SHA-1 hash value, brute force the password.
So How Would This Work? • Get the SALT (available through AUTH_VRF_DATA field) • Get the encrypted server session key (available through AUTH_SESSKEY field) • Brute force the AES 192-bit encrypted AUTH_SESSKEY to determine the SHA-1 password hash • Once you have the SALT and the SHA-1 hash value, brute force the password. Flaw Leaks Unencrypted version of this Key
So How Would This Work? • Get the SALT (available through AUTH_VRF_DATA field) • Get the encrypted server session key (available through AUTH_SESSKEY field) • Brute force the AES 192-bit encrypted AUTH_SESSKEY to determine the SHA-1 password hash • Once you have the SALT and the SHA-1 hash value, brute force the password. With the SALT, you can loop thru possible passwords, generating SHA-1 hashes and comparing them to captured hash. A brute force crack of this type can discover an 8-character password in about 5 hours.
So How Would This Work? • Get the SALT (available through AUTH_VRF_DATA field) • Get the encrypted server session key (available through AUTH_SESSKEY field) • Brute force the AES 192-bit encrypted AUTH_SESSKEY to determine the SHA-1 password hash • Once you have the SALT and the SHA-1 hash value, brute force the password. Now 4. is moot, as it is the password from the brute force loop that generated a matching hash.
5 Hours? Really? A 3-GHz Pentium 4 brute forces the 26-character ASCII namespace in:
5 Hours? Really? One AMD Radeon HD7970 GPU can average 8.2 billion password trys/sec oclHashcat-plus can utilize multiple GPUs for exponential performance improvement Rainbow tables can utilize pre-calculated values to cut even more time
5 Hours? Really? Here’s an 8-Radeon card computer for about $12k that can brute force the entire 8-character namespace (upper/lower/digit/symbol) in 12 hours!!!
Why is this so Insidious? Wouldn’t the account get locked due to too many failed login attempts?
Why is this so Insideous? Wouldn’t the account get locked due to too many failed login attempts? No! You don’t get locked because once you grab the AUTH_VRY_DATA and AUTH_SESSKEY, the rest is offline activity.
How to Protect Against This? Note that this is a flaw in O5LOGON protocol O5LOGON came out with Oracle 11.1 (client and server)
How to Protect Against This? Upgrade to Oracle 12c - or – Go back to O3LOGON protocol
How to Go Back to O3LOGON? alter system set sec_case_sensitive_logon=FALSE scope=BOTH; orapwd file=pwdSID.ora ignorecase=y grant sysdba to USER1; grant sysoper to USER2;
So Now I’m Safe…Right? WRONG!!!
Standing on the Shoulders of Giants Alex Kornbust Pete Finnigen David Litchfield Paul Wright Zsombor Kovács Ettienne Vorster László Tóth Ferenc Spala
If you don't know neither the enemy nor yourself, you will succumb in every battle. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. But if you know the enemy and know yourself, you need not fear the result of a hundred battles. - Sun Tzu, The Art of War Session UGF9198 Troy Ligon tligon@soug.org