 So hello and good afternoon everyone. My name is Sid and I'll be talking about how SQL injection worms can affect the Oracle applications. Most of you must be aware that there was a worm which affected the internet like a year ago that mainly targeted the MS SQL back in database. So I'm going to be presenting how these worms could target the Oracle applications. A little bit about me, I work as a senior IT security consultant in UK. And that's my blog, NotSoSecure.com. All the tools and the demos will be available on this blog. I'm a little bit pressed for time so if you can keep your questions to the end and if I'm not able to answer them, just catch me after the talk and I'm happy to answer them. So let's get started. When we talk about SQL injection in Oracle, there can be two broad categories depending on where your injection point is. Your injection point could be in an anonymous PL SQL blog which will typically be called as a PL SQL injection or you can have the injection in a single SQL statement like a select query. So a common example is a wear clause in a select query where you have your injection point. So if you have a PL SQL injection, mostly things are quite straightforward. It is more or less like having an SQL plus access to an Oracle backend where you can just copy paste stuff or just throw queries to it and it will get executed. Things get a little difficult when you are encountering SQL injection in a single SQL statement like select query. Why are they different? That's because if you have the injection in the SQL statements like select query, then Oracle by design does not support semicolon in the single SQL statements. So you cannot end the query and do like create function. So it gets a little difficult if you are encountering injections there. But if it's a PL SQL injection, things are quite straightforward. You can execute DML or DDL statements. You can use autonomous transaction to commit changes and all in all things are quite easy. I'll touch upon the SQL injection a little later. So this is how a typical PL SQL injection would look like. Over here I've created a sample procedure called ORA SSO dot test. It takes a variable and that variable basically then gets embedded into a begin and strings and it basically is used in construction of an anonymous PL SQL block which then gets dynamically executed. So over here you can clearly see it's a PL SQL injection and you can take control of that PL SQL block. So you can do, you can provide that parameter Q as a null and then execute immediate, maybe grant DBA to public. And so over here you don't have any restrictions. You can use semicolon and execute multiple statements. As I said, and exploitation is fairly straightforward. So when we are talking about web applications, when will you typically encounter a PL SQL injection from web applications? A classical example of this is Oracle application servers. Now Oracle application servers have had a series of vulnerability in the past. This particular example was a flaw in the PL SQL gateway which was fixed by Oracle in 2006. And the idea to show this as an example is not to demonstrate a vulnerability which was fixed in 2006, but to give you a general idea of how do you go about exploiting PL SQL injection from web applications. So over here this is how a standard Oracle application servers URL look like. The part after PLS is called that database access descriptor. So this vulnerability allowed you to inject arbitrary PL SQL, but the PL SQL which you inject gets executed with the privileges of the dad user. So now from here on, you can, as long as you can execute PL SQL, you can then, you will then be able to exploit the vulnerable packages stored in the backend database, and then using the vulnerabilities in them, you know, exploit them and become DBA. Once you become DBA, then you will be able to do nasty things like OS code execution. In this particular example, this dad user happens to be a really low privileged user. It's called ORA SSO underscore public. SSO stands for single sign-on. It's one of the default packages which it ships with when you install Oracle application servers. So this user doesn't even have the create function privileges. So I mean, to get past that, you use something called as cursor-based injection exploits, and there are tons of them available on Milworm. Once you become DBA, then you can execute OS code. Again, in an earlier talk, someone touched about how do you go about executing OS code. I will be showing a small example with Java. So I wrote a simple perl script called OAPHacker, which basically exploits this flaw. I'm going to show a quick demo of this. So what I said earlier, this demo is basically to prove how do you go about exploiting PLSQL injection from web applications. So this is a default install of Oracle application server, 10G second release. It comes with a lot of default packages. One of them is called SSO, ORA, single sign-on, which we will be using here. It is a flaw in the PLSQL gateway. So it has nothing to do with the applications which you have deployed on the application server. Your applications which you have deployed on this server might be completely flawless, but because it's a flaw in the gateway, you still are vulnerable. So using this flaw, you can execute SQL queries like select user from dual. And I don't know if you can see that. If I throw it a query called select user from dual, it says ORA SSO underscore public. So that's the user privileges with which I'm running my SQL queries. So now if I change this query and do something like select star from sys.user$, which contains the password hashes, then you will see this will fail because our user doesn't have the privileges to query this table and we can't get the Oracle hashes. But because we can execute PLSQL, now we can exploit the packages present in the backend database and then we have our privileges. So all you do is take this URL and pass this to my, to this Perl script. OAP hacker.pl and you give it the OS command which you want to execute like in this case, maybe IP config or whatever. And it will first check if the URL is vulnerable or not. If it's vulnerable, then it will check for the current privileges whether you are DBA or not. If you are not DBA, then it will launch a series of exploits and eventually give you DBA access. Once you have DBA access, then it will build up a Java function with which you can execute OS code. So now it says we are not DBA. It's going to run a privilege escalation exploit. The first exploit maybe didn't work, so it's going to run it again. So now it has given us the DBA privileges. Now it's going to build up a function for OS code execution. So that's it. It has now built up a function through which you can execute OS command and get the output in the web browser itself. So you don't really need any other tool. So now all you have to do is copy paste this URL into a browser, change the argument which you want to execute. And that's it. You are done. I'm struggling to copy in this example. So I'm going to run the command who am I? And I don't, if you can see it here, it says entity authority slash system. That's basically how Oracle runs in Windows. So this was an example of how will you go about exploiting PL SQL injection from applications. Right. Now we move on to something more difficult and something which you will probably more encounter, which is SQL injection in a single SQL statement. Now, as I said earlier, Oracle by design does not support execution of stacked queries in SQL. It does so in PL SQL, but not in SQL. So if you find an injection in a select query such as this, you are really limited. So in order to execute multiple statements like, you know, even if you want to exploit vulnerable packages, you need to find a way by which you can execute multiple statements. So you essentially need to find a way to inject PL SQL. So one of the ways to inject PL SQL in SQL is if you can call some function which is vulnerable to PL SQL injection. So you can pass the PL SQL as an argument to that function and then call that function in your SQL. Right. This will get elaborate on this a little bit more. So this is actually something not very new. In 2005 at Black Hat, somebody actually touched on this. So there are other functions which you can call in SQL. There are functions which are vulnerable to buffer overflow which you can call here. For example, this one, this was showed in 2005 Black Hat talk. This was a function which basically was vulnerable to buffer overflow. And as you can see, you can just directly execute the command and it gets executed with system privileges. So you don't really need anything over here now. But I'm not going to touch buffer overflows here. I'm going to touch functions which are vulnerable to PL SQL injection. So functions will not be able to PL SQL injection. Again, you can have two cases there. You can have the function defined with AuthID definer or that function defined with AuthID current underscore user. If the function is defined by AuthID definer and it is owned by a high privileged user such as Sys, then what it means is that you are basically injecting PL SQL with Sys privileges. So in simple words, it means it's game over really. If you are injecting PL SQL with Sys privileges, then you are DBA already, just execute OS code and it's not very difficult. If you are injecting PL SQL with AuthID current user, then it means that now you can execute multiple statements. Although you are not executing those statements with the high privileges, but because you can execute multiple statements, then you can exploit vulnerable packages and again indirectly do privilege escalation and then again become DBA. And essentially, so using these two vectors, once you become DBA, then you can execute OS code. So Oracle has had this function, DbMS export extension, which has had a series of vulnerability in past. In fact, the 2009 CPU, which was just released, had again addressed issues in this package. In particular, this package has a function called get domain index tables, which is vulnerable to PL SQL injection. Again, this is something which was fixed by Oracle in 2006, but because of the way Oracle patches work, it is still common to find databases which have this package as vulnerable still. So this function, this has the auth ID of a definer. It is defined by Sys, and it's vulnerable to PL SQL injection. So what it means is that, what it means is that you can now execute PL SQL as Sys user. You don't really have to do anything more here. So just call this function in your SQL. Every time you find injection and select or insert or update query, call this function, pass the argument to this function, whatever PL SQL you want to get executed, and that will execute with Sys privileges. So this is a sample exploit. This was reported by David Lichfield, and it's actually mentioned in his book, Oracle Hackers Handbook as well. So we've declared this transaction as with autonomous transaction because you want to make it independent. This was fixed in 2006. There is, there is yet another PL SQL injection in the same function, and this has been reported by Alexander Kornbust, but I'm not going to be talking about this, maybe, maybe in the next DevCon. And these are the vulnerable versions in which this will be affected. So I wrote up a small tool, it's called BSQLBF. There are n number of SQL injection tools out there, so I'm not going to talk about another SQL injection tool here. There are a few features of this tool, which I thought was quite unique. The latest version, version 2.3, is dedicated to Oracle. It basically contains this DBMS export extension exploit. So if you find a SQL injection, and if you find that the database, the application connects to the database with certain, you know, unprivileged user in connection string like Scott Tiger or whatever, then you can use this tool. It will do two things. It will do privilege escalation. So normally you can extract data in Oracle, but with privilege escalation you can extract data with this privileges. So maybe you can extract the password hashes from Oracle. Then it does the OS code execution. For OS code execution, again, it takes three sub type. It can execute OS code with Java. If you are exploiting an Oracle application server express edition XE, then Java will not be installed. So you can then rely on DBMS scheduler, or if you are exploiting Oracle line, then it also supports PLSQL native make utility. It also gives you read write access, so you can read files from the back end database. I don't really have time to show you the demo for this, but the demo is available on my website, not to secure.com, and if you want to go through this. So going back to the original topic, the SQL injection worm, those of you who do a little bit of forensics must have seen this hex string in the logs. This was how the MS SQL worm looked like. All it would do is basically find the applications which are vulnerable to SQL injection. Then this massive string will look into the database, do a massive update, so that the web front end now changes. So the end users who now visit these websites, this website now contains some malicious JavaScripts, and these JavaScripts basically points to some browser exploits. So it didn't really target the server so much, but it targeted the end users. That was how it operated. So I basically wrote a simple proof of concept on how the similar thing can be achieved under Oracle. Again, it's not just about doing a massive update and hacking the end users. As we have already seen, you can execute OS code and hack the Oracle server itself. So at this stage, the possibilities are really endless. So yeah, exactly. What could the worm do from here? We've already seen that we could execute OS code on the server. We could do something like what MSSQL worm did and do an update and then hack the end users. Again, if you can execute code, then maybe you could do something like a TFTP, GetConflicker, and in fact the internal network. You could, I mean, there could be something which could hack only Oracle, you know, specifically Oracle. There are quite a few things which are out there and begging to get hacked actually. Oracle Secure Backup, there was a remote code execution. So you just send one URL on the internal network and that's it. You get a reverse shell back from it. There was a Secure Backup exploit. I think it's integrated with Metasploit as well. SQL injection in Oracle Enterprise Manager, TNS Listener exploits. There are so many things that a worm could do from this stage. So let me just quickly go through this demo of a sample SQL injection worm. Okay, before I play the demo, just tell it background about this demo. Over here we are seeing a blind SQL injection. I have not shown you the demo for BSQL-BF, but if you see the demo of BSQL-BF then probably you will be able to correlate this better because over there I first used the same application to get OS code execution, but over here we are not going through that. So in this case it's a PHP application which is connecting to the backend Oracle database server, 10G. It is connecting as user-scot-tiger. So we are doing a privilege escalation, becoming a DBA, then doing a massive update, and then that update basically means that the front end, you know, after the worm has infected this website, when I refresh this page, the front end will change and that will point to the Autopone Metasploit, browser Autopone Metasploit module. So in this video over here, there is a putty session over here in which the attacker is running the browser Autopone and when I launch the worm, the worm basically will open a new window in the website and target and point to the browser Autopone. Again this was based on the DBMS export extension exploit and this was doing the update query, but as I said you could do a number of things over here. So I'm setting up the browser Autopone right now in this window. So that launches our browser Autopone. Now I'll give this URL to the worm. So it basically takes the URL as an argument. Okay, so that's it. It sends this massive URL which basically injects PLSQL with its privileges and does the massive update. Now if I go and refresh this browser, then you will see the HTML source code now has a JavaScript tag saying window dot open and that location is that is pointing to the browser Autopone. So I'll refresh the website and now a new window has opened which basically points to the browser Autopone and the browser Autopone of plug-in of Metasploit is now launching a series of exploits in the browser to hack the end user. And as you will see over here now one of the exploits have worked and we now have a Metabitter session open. So if we attach the session and this is the Metabitter shell not from the server but from the end users. Yeah, that basically concludes it. So thank you for your time.