The Art of Exploiting Injection Flaws@Black hat Vegas 2013

Hello All,

The popular course on Injection Flaws will return to Las Vegas at Black hat 2013. The 2 days hands on course covers Injection flaws and ONLY injection flaws. We dont talk about XSS, CSRF, CRLF etc etc. I think, 2 days is not enough time to learn the entire web application security and thus I only focus on Injection Flaws.

I will be appearing on the famous podcast pauldotcom and giving a little insight on the course on April 25th 7PM ET.

A little write-up about this can be found here:

In short, the USP of course are:

Advanced/Insane SQLI
Examples where SQLI gets un-detected by commercial tools
Advanced XPATH Injection (including 2.0)
Advanced LDAP Injection
Advanced HQLI/ORM Injection
Advanced XXE Injection, including blind XXE

The course page can be found here

See you in Vegas!


Update: here is the video from my podcast at pauldotcom:



Video streaming by Ustream

Update: My interview at Dark reading which also gives an insight into the course can be found here

A Collaboration worth mentioning..

Hello All,

It has been a long time since you have heard from me :-(
I am quite excited to share the news that I will be at Black Hat UAE 2012 to present a new talk titled ‘The Art of Exploiting Logical Flaws’. So, as most of you would agree that the application pentests are getting more challenging every day. The automated tools are now part and parcel of every pentester’s arsenal, but do these tools have enough intelligence built into them to identify core logic flaws. Even OWASP Top 10 does not have any mention of Logic flaws. While, there are some examples on internet of using MiTM tool to manipulate requests (e.g. price of a product on an e-commerce site), these are all a bit too common/outdated. We will show some cool logical flaws which we have found in real life pentests and hope that audience can benefit from these.

More details here: http://blackhat.com/ad-12/briefings.html#Siddharth

Secondly, and rather more importantly, what makes this talk really special is that I will be speaking alongside Richard Dean, who heads the penetration testing team at Portcullis Computer Security. How often do you see two researchers from different firms who usually compete with each other, work alongside and produce good results? I think it is really great to see that the 2 companies (7Safe and Portcullis Computer Security) supporting our talk and many thanks to the directors of these firms. I hope other companies will also follow the same path.

See you in Emirates Palace, Abu Dhabi!!!!

-Sid

What to/not to expect from pentest

Hello,

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….

Black Hat Eu 2012

Hello All,

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.

Hacking Oracle From Web: Part 2

It has been a long time since I posted something. In 2010, I released a paper which talked about how to execute OS code when exploiting a SQL Injection in a web app which talks to oracle database. Back then, I was not aware of 2 publicly available functions which could allow execution of PL/SQL statement. These functions change everything. These functions imply that we can issue multiple statements and overcome the limitations of oracle’s SQL language. Interestingly, these 2 functions exist from Oracle 9i upto 11g R2. While I am a little bit puzzled why I didn’t see these earlier, I have put together a few attack vectors in a new article/paper titled: Hacking Oracle From Web: Part 2

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…