 So hello everyone. So it's 5 o'clock now and I think it's nearly beer o'clock so hopefully this won't take long. My name is Sid and I will be presenting on hacking oracle databases from web applications. Specifically I will be talking about some exploitation techniques for exploiting SQL injections in web applications against oracle database. So SQL injection is nothing new. I mean if you don't, if you have not heard of SQL injection you probably are in the wrong room. So for last 20 years we've had exploitation techniques in SQL injections refined. We've got some modern state of art tools for exploiting SQL injections but they're mostly concentrated against MS SQL. When it comes to oracle there are not too many tools. So hopefully this talk will provide some answers to those questions. So a little bit about me. I work as a spend tester for a company in UK called SevenSafe. I'm not an oracle geek so it's quite unusual to have an oracle talk at Defcon and not talk about zero days. So this particular talk is not focused on any particular zero days against oracle databases but mainly focused on what exploits can be used from web applications to achieve certain things. So that's the agenda for today. So I presented this talk at BlackHat yesterday. I have reduced some slides so we will not be talking about extraction of data and if anybody is interested I highly recommend that you go through the original slides which I will be releasing on the Defcon website. Towards the later half we'll talk about PCI compliance and some holes in PCI compliance. We'll look into that. So why am I talking on this topic? Because it's Defcon and we love SQL injections. So there have been a number of talks on hacking oracle databases but sadly most of the talks have been on interactive exploitation. That is if you can connect to the oracle database, if you are on the internal network, then you can hack oracle database pretty much. But all these talks have been on interactive exploitation and not so much from the application side of things. There are no free tools for hacking oracle databases by exploiting SQL injection vulnerabilities. Even there are a few commercial tools which I know of which target oracle database but the techniques which I found out used by these commercial tools are outdated. So if you are exploiting say an 11G via SQL injection, these tools may not work. Before we start, I would like to thank David Litchfield for his pioneering work in the field of oracle security. Most of this talk is inspired from his work and we would also like to thank Alexander Cornburst and Farrah Mavit-Yuna for helping us prepare this talk. Okay, so those of you who are not aware of oracle database, when you install an oracle database it comes with a number of default packages. These default packages have considerably reduced in 11G. If you compare an 11G with an 8I maybe the number of default packages have considerably reduced but still there are quite a few default packages. And these packages will have a number of procedures and functions. By default, these procedures and functions runs with the privileges of Definer. So an easy way to understand this is to compare this with SUID files in Linux. Like SUID files in Linux runs with Definer privileges. Similarly, you have these procedures and functions by default running with Definer privileges. So to change that mode of execution from Definer to Invoker, you must declare this keyword AuthID current ender score user in the declaration of that particular procedure or function. So this is something which we all know about. How do we hack oracle from internal networks? In a nutshell, if there is a SQL injection in a procedure owned by a CIS and public has execute privileges, then whatever you inject gets executed as CIS. So you can elevate your privileges, become CIS. And once you have CIS permissions, then you can execute OS code. So in a few steps, that's how you go about hacking oracle database from internal network. You first enumerate CID, which is the database name. You then enumerate some common users, Scott, Tiger, CIS, change on install, some weak passwords. Once you have done those two steps, then you connect to the oracle database. So you will be connecting with some unprivileged users hopefully. Once you connect them, connect to the oracle database, then you find one such procedure which you can execute, which runs with the privileges of CIS maybe and has a SQL injection that will let you become DBA, grant you DBA role on that user. And once you have DBA, then you can execute OS code. So all of this can be done via metasploit, and this was shown by Chris in last year's DEF CON talk. For example, this was one such procedure which was available for public and was patched by oracle I think a year ago. CIS dot LT dot merge workspace was one such procedure. So you inject into it the string semicolon and scott dot DBA is equal to Y. So essentially the function scott dot DBA which you created then executes with the privileges of CIS. Hence you, the user scott end up with the DBA privileges. So it is important to know that scott dot DBA must have auth ID current underscore user defined. If you don't define this in your function, then again scott dot DBA will be executed with scott which you probably don't want. Okay, so that was hacking oracle from networks which has very well documented. Now when it comes to exploiting SQL injections against oracle database, it's important to understand that in oracle there are two classes of this vulnerability, if I may say so. So that's because oracle has two coding languages. It has PLSQL and SQL. So PLSQL is one coding language embedded in oracle which is really powerful. An easy way to understand PLSQL is to consider this as a free floating code that you have between begin and end. So you have begin and end and in between that you can have n number of statements. So you can have procedure one, procedure two and so on and so forth. Okay, but the second language the SQL in oracle is actually quite limited. And the SQL in oracle by design does not allow execution of multiple statements. And that is one thing which differentiates exploitation of SQL injections in oracle against that of MS SQL. So like for example in MS SQL if you have a SQL injection in a select statement then you can end that statement and issue a next statement like exact xp underscore cmd shell or drop database. You can't do that in oracle because oracle by design in SQL does not support execution of multiple statements. So what are the challenges in exploiting oracle from web apps? Obviously SQL in oracle does not support multiple statements. OS code execution is not as simple as executing xp cmd shell. Not enough documentation and not enough tools available. So based on these two coding languages in oracle you can have two classes of vulnerabilities. You can have a PL SQL injection vulnerability or you can have a SQL injection vulnerability. So a PL SQL injection is when the user's input is used in a construction of an anonymous PL SQL block and then that block gets dynamically executed. That would typically be a PL SQL injection and if you find a PL SQL injection then a PL SQL injection is nothing different from having an interactive access to the database because then you can run multiple statements. So then it's as I mean that is not different from having an interactive access. However you can also have a SQL injection which is injection in a single SQL statement. In that case there are a few restrictions like we said there is no semicolon allowed and you cannot use nested queries. So here is an example of a PL SQL injection. So this is one PHP code which connects to the oracle database with a limited user privilege is a Scott user and so this coder has obviously followed some best practices and he's taking the parameter name and he's binding that parameter into that SQL statement which is passed on as an input to the procedure scott.test. So obviously that particular statement if you look at an dollar SQL it does not look like it's vulnerable to SQL injection or any such thing because the parameter is bound to the query. However if you look at the actual code of the procedure in which this input is passed then you will find that all this procedure does is takes the input which is the name of a procedure and then wrap that name between begin and end. Hence constructing an anonymous PL SQL block and then execute it dynamically with execute immediate. So I mean when people talk about SQL injection defense they talk about using bind parameters but one must understand that there are limitations of using bind parameters for functionality such as this you cannot use bind parameter. So I mean obviously you can does not mean that every time you write code it is vulnerable you can use some sanitization functions but you cannot use bind parameter for this particular functionality. So this particular example is vulnerable to PL SQL injection. So how do we exploit this? David Litchfield showed an exploit at Blackhead DC this year which allows the user which just creates session privileges to grant himself java IO permissions and once this java IO permissions are obtained then OS code execution is possible. This particular issue was fixed by Oracle in the CPU of 2010 April. So this is how the exploit looks like and you can use it from applications. Essentially so if you look at our score test procedure I have passed the argument as null. So basically I'm saying the procedure to execute is null which is which is okay for Oracle and then the next statement is execute immediate and that execute immediate has the entire exploit code which will give the current user java IO permissions and this was basically a logical flaw in the package DBMS JVM export permissions. I mean this is talked in detail by David Litchfield so I'll skip this. So that particular exploit would give you would give your current user java IO permissions so that essentially is a privilege escalation. Once you have java IO permissions then you can call a function which is a which is available in the package DBMS java test and the function is called fun call. This function takes as an argument and a class. The second argument is the method within the class and the other arguments are the arguments passed to the method of that class. So there is by default one class in Oracle which is the Aurora UTL wrapper and this default class in Oracle has a main method and then that main method by default allows OS code execution. So if you have java IO permissions you can call this function and pass this argument and this will basically result in OS code execution. So PLSQL injection vulnerabilities are not very hard to are quite common actually and the best place to look for these vulnerabilities is in the Oracle applications itself so the code written by Oracle themselves. I mean if you look at the history of Oracle application servers or Oracle application portals starting from 2001 to 2002 there has been a series of PLSQL injection vulnerabilities. I mean I was going to talk about doing a privilege escalation via PLSQL injections but the fact is that most of the PLSQL injections in Oracle products have been quite privileged already so talking about privilege escalation does not make sense because already the code executes with higher privileged users. Right so now we move on to the main agenda for today which is SQL injection. So this is a SQL injection 101. Essentially that does not need any introduction. Unsanitized users input is used in SQL calls so for example something like this if you inject colon or one equal to one this will alter the logic of the SQL query and this will return all the rows so you can use SQL injection to compromise confidentiality integrity availability blah blah I mean this is right so let's get started exploiting SQL injections what do we do with exploitation of SQL injections so when we say exploiting SQL injections it can have different meaning to like the picture alright okay so exploiting SQL injections may mean different thing to different people it could mean that somebody may be after sensitive information within the backend database if your database contains credit card information then for me if I can get the credit card information that is sufficient I may not be interested in in running US code on the box so extraction of data is typically one of the aims of SQL injection but that is not the end end goal of a SQL injection a database may not have sensitive data but it may be connected to the internal land and you may want there may be an attack vector by which if you compromise a database you can pivot your attack and go on compromising the internal network so extraction of data is actually something which has quite which has been documented quite well and I will not be talking in this in this 50 minutes of slot essentially extraction of data can be divided into two categories when the error messages are enabled then just like in MS SQL you convert you do typecast conversion errors and you extract the data within the error messages you can do similar things in Oracle when the error messages are disabled you can call union queries you can do blind injection you know then if if the front end does not give you clues about blind injection you might be able to call some time delay functions and lastly you can also do out of band channels in Oracle so all these exploitation techniques are fairly common between Oracle and MS SQL and they're not very different different what I'm more interested in is privilege escalation and OS code execution so this is actually an important point so you found a SQL injection and you are injecting some code via the SQL injection from the web application front end now depending on what by what privileges your code your injected query gets executed I will classify a particular SQL injection as privileged or unprivileged so so for example a privileged a typical privileged SQL injection would be when whatever I am injecting whatever SQL I am injecting gets executed with DBA privileges now it could happen in number of scenarios for example the application itself connects to the database with DBA privileges it is it is not very common to see a developers doing that I mean having said that you often come across applications in ASP and ASPX where you see the application connects to the database with SA user or you know any user which has had been enrolled so it's it's not very common but you still come across these however more importantly you can see DBA privileges in your in your SQL injection when the SQL injection is in a procedure and that procedure is owned by a high privileged user so the application might connect to the database with Scott Tiger permissions standard permissions but the injection point is in a procedure and that procedure runs as a high privileged user so in that case my SQL injection will be privileged irrespective of the connection string and obviously the second category could be the unprivileged SQL injection for example I mean if you if you only have a typical Scott user privileges that would be an unprivileged SQL injection so what I mean by privilege escalation is I know that during interactive exploitation like if I can fire a razor SQL or sorry any SQL client SQL plus to the Oracle database then I might be able to run a procedure which is will not able to SQL injection grant myself DBA permissions and then I can do stuff that is a typical privilege escalation now those of you familiar with MS SQL more you may recall MS SQL it is still possible to do privilege escalation by calling open Rosette so I am after something similar in Oracle and you should remember I talked about that in SQL Oracle does not support execution of multiple statements so you cannot if there is a SQL injection typically which exist in a select statement then you are only restricted to select statement so you cannot end that statement and call a procedure and inject into it what you can do is call functions in the SQL because SQL supports functions you can call functions within the SQL so for exploiting SQL injections we are typically looking for vulnerable functions any function which is which has any vulnerability typically interests typically can be used via exploiting SQL injections so we are looking for functions which are executable by public and are vulnerable to either PL SQL injection or allow PL SQL execution as a feature so we will call the function in the SQL and as an argument to that function we pass PL SQL there are a few such functions known but the exploit is not publicly available for example this particular function dbms java test function in this this is the name of the package a function exist within this package which had a buffer overflow vulnerability so in your SQL you can call this function and cause a buffer overflow because that function is executable by public so out of those few known exploits the one which is fairly popular is this particular function get domain index tables this this function is vulnerable to PL SQL injection now I have the example of the exploit code in the next slide but before we go there so this function runs with the definer privileges so irrespective of what privileges do you have you can call this function and you can inject some argument within this function and whatever you inject that will run as sys so you don't really care about any privileges and you can directly query the database with sys privileges so it allows privilege escalation and os code execution from web apps public can execute this function this okay so this flaw is fairly old now this was fixed in a CPU of April 2006 and these are the vulnerable versions and sadly I mean there there are no more functions known as I said there have been advisories published which says these functions are vulnerable but the exploit codes are not known and this is one particular exploit which is which is very popular and all oracle exploitation tools actually rely on this exploit so this is how the exploit looks like essentially if you look at this then our injection string which is which mainly is I mean we've injected quite a lot in it but mainly that that statement grant dba to public will run as will run as sys permissions so this will just grant the dba role onto the public user and then you can carry out exploitation with dba privileges right next we move on to the os code execution again we can have a sequel injection which is unprivileged or privileged and again if your sequel injection is unprivileged you can use this particular function to execute os code via PL SQL again this is the only function which is known by which with absolutely no privileges you can do privilege escalation and and execute os code for I mean you can still execute os code but for that you need some privileges you just can't do it with the bare minimum create session user privileges so the privileges which are required for os code execution are either a dba privileges or java io privileges I mean so for example in mssql we know that you can execute os code by calling xp underscore cmd shell but to call xp underscore cmd shell your user must be in the sysadmin role only then he can call the xp underscore cmd shell procedure so that is basically a feature so likewise in oracle if you have these two these two permissions then then you can execute code and I would not call this as a vulnerability this is essentially a feature but just a feature which is probably not very well described by oracle for obvious reasons so I mean before we move on to the privileged part this is again the same exploit which was fixed in 2006 so we execute os code by injecting PL sql within this function a number of commercial tools like pangolin and core which I've seen they actually support this exploit and that's the only exploit which the support bsql bf is one such tool which is one tool which I support which which also has this exploit and we will look at some more exploits later on right so moving on again that was quite an oral issue passed in 2006 if your connection string user or if your sql injection is such that you whatever code you are injecting that particular user has java IO permissions then you can execute os code on on oracle database you can do that in 10g r2 11g r1 and 11g r2 by calling these two functions run java and fun call both these functions they take an oracle class as an argument and a method of their class which will allow os code execution so by default this this particular oracle class Aurora utl wrapper allows os code execution within the main main method so this is how the exploit would look like all you do is basically just call this function dvmsjava test dot fun call and as an argument you pass the oracle class and whatever code you want to execute the only limitation is that you need java IO permissions and without java IO permissions you cannot call this class you cannot execute this class you have execute permissions on the function but you do not have you cannot execute that class with your without java IO permissions so you can also execute code with dba privileges now when so when we talk about dba privileges obviously dba is a higher level privilege and so the obvious question which arises that dba can grant himself java IO permissions and and ends go back to that step which we showed earlier and execute os code so so what's the point the point is that I wanted to come up with something generic so for example even if in future oracle try oracle removes this this java class or makes it difficult for you or revokes the execute permissions of the public user on that particular function then we still want to execute os code so in oracle 10g and 11g there is a function called create worker process sorry create master process this function executes arbitrary plsql this is not a flaw this is a feature you have to be careful with oracle so so because it executes plsql as a feature what we do is we as an argument we pass on a plsql which essentially is a dbms scheduler and via dbms scheduler we can execute os code so this is how it looks like it basically has a number of statements basic first of all we create a program in that program we basically tells we basically tell oracle that this program is to run this particular os code with this particular argument and then we create a job then we execute the job and drop the job so this essentially will result in whatever code you want to execute okay so you don't have to remember any of that because it has already been scripted and all you need to remember is the right switches to call bsql bf as I said is a free tool which I support and it supports advanced it supports os code execution by exploiting sequel injections against oracle database so for I mean what's new in bsql bf is the new version which I will be releasing now it's already out there supports execution of any metasploits payload on the remote oracle database so I have a small video for you right so here's a sample sql injection so we are doing a blind sql injection here so if you do one is equal to one then you see this this particular string accounts appearing in the html page if you do and one equal to two then you will see that disappears so it's a quite standard blind sql injection which we are looking at right so the new version of bsql bf actually comes with an executable so if you go to the bsql bf folder so there's a generator.exe and a Perl script what you do is you choose the metasploit payload which you want to execute on the remote oracle database so I mean this is so you in this for example in this case we choose a remote vnc shell and we choose our IP address on which we want it the database to throw us a reverse shell this will run msf payload which we will then upload via our sql injection on the remote database and we compress it for better results it supports two mode of exploitation as I said java io and dba what privileges do you have after you finished it it then tells you what to do next so you have to launch bsql bf then and what with what parameters you should launch it that's that's basically a small manual page which comes up so well it basically tells you it also has a cleanup mode so if you are doing a pen test you probably do not want to leave metasploit payload onto a remote database and things like that so hyphen cmd is equal to ref shell that that is a parameter which is new which will which will execute metasploit payload so you launch the metasploit to capture your reverse shell as you can see my video editing techniques need some improvement right so you launch bsql bf you provide the vulnerable URL you provide the match string in this case it was accounts by which it identifies the true and false response you provide the database so it is 3 for oracle type 8 stands for that we have the dba privileges and ref shell stands for execute the metasploit payload which we have already created so if we now start our metasploit listener and let bsql bf does its job then so it will first check if we have the java io permissions sorry it was java io and not dba then it will upload the corresponding metasploit payload I mean depending on what what payload you are executing this this can take some time metasploit 3.3 the payloads it creates are quite big so it could it could take some time right so when it's successful it will drop you a vnc shell like that so and oracle in windows runs a system so this is basically complete on edge this is fairly generic so even if you come across an oracle database running on a solar is or or an AIX machine then I mean we are not reinventing the wheel all you have to do is create the generate the right metasploit payload and send it on to the server so this should work in all conditions right next I wanted to talk about a class of vulnerability which I feel is is not very much discussed and that is a non interactive second order injections so what I mean by a non interactive second order injection is this so if you imagine an e-commerce website or any any website which allows a new user registration functionality so imagine an unauthenticated attack attacker attacking a functionality such as this so he tries to inject something like evil functions into into some arbitrary random fields but the query which gets executed on the server side is actually secure so if as you can see it is using bind parameters so that that particular field is not vulnerable so all his attempts are going to be in vain because this is a safe code so whatever he injects gets stored into a table and because that particular code is not vulnerable now what happens if an admin user then goes and moderates this particular user which have been created with with some crafted functionality sorry crafted strings the code which gets executed when the admin user approves this functionality is vulnerable to SQL injection in this case so so whatever the malicious user has injected what stored into a row of the table that particular value of the row of the table is then being treated as a string and then passed on as an argument to var 2 over here so the functionality which admin user executes is vulnerable to SQL injection this functionality is never seen by the by the attacker and the admin user is trusted so for an admin screen this is part this is what is possibly going to happen in the admin session but the bottom line is that the admin user is trusted so even if the malicious user injected something like which will dump the database version or any sensitive data that would be dumped on the admin user screen and not on the attacker screen so this is what I call as a non interactive second-order injection SQL there is definitely a problem there is a definitely a SQL injection but it does not occur within the attacker session so example attacker places an order via any commerce application admin logs in and approves the order the admin session is vulnerable to SQL injection and although the attacker does not see it or does not have any method to interact with it the attackers input does get passed on to the vulnerable SQL calls similar I mean another example of these vulnerability could be that so the attackers input which is stored in a row of a particular table gets acted upon by a trigger now that trigger can be called as a result of a bad job which runs every night so what I'm saying is that the attacker has no way to identify this problem and the injection does take input from the malicious user right other examples of this vulnerability is if you find a cross-site request forgery in the admin section so for example consider an admin section an admin sessions screen which is vulnerable to cross-site request forgery and it either allows execution of arbitrary SQL as a feature or because admin screen is vulnerable to SQL injection in either case whatever attack payload you inject that will be executed only once so how can we make all these scenarios of non interactive SQL injections interactive can we do something to regain control of the SQL injection which we don't actually see out there so there is a concept of one click on edge the original concept was from Faro the idea is simple we run MSF payload to create a binary and so we need we need to make sure that we upload this binary and execute this binary onto the database server so we convert that binary into hex if you convert the binary into hex the size will be double so we use some reduction functions we write a VBScript that can process this hex string and generate a valid binary file so the idea is in in one single request we can get a reverse metasploit connection back to us so shell.exe is generated by metasploit metasploit MSF payload then shell.exe is converted sorry is compressed and hex encoded with decryptor attached so we create this VBScript when this VBScript will be run it will create the metasploits executable on the target server and then we run the metasploits executable so this VBScript can be deployed using things like xp underscore cmd shell on the mssql server yeah let's just okay so this is how it will look like one long message string which will do the job for you I mean usually when we talk about getting an interactive access you will either upload via tftp or you will upload bit by bit using debug.exe so this solves that problem and most importantly you can just blindly use that as a first string and first into every field and get control of of of SQL injections which don't really happen in your session so this was the original one click on edge from pharo which will which work for mssql so we did the same for oracle so if you have java io permissions then then you can this is the attack string which you can use for oracle obviously depending on what public IP you want to throw reverse connection on this hex will change next is so when we wanted to do this with the dba privileges then things didn't quite work so the obvious question was again we can grant as a dba user we can grant ourselves java io permissions and then execute the previous step we can do that but the problem is if you grant yourself java io permissions as dba then those permissions are not available in the same session so technically you have to log out and log back in and then you will have those permissions which you have granted so technically speaking it won't quite be one click on edge it it will require more than one or two three clicks you can do something like grant javasis permissions to the public role and then the permissions will be available in the same session but if you are doing pen testing consistency like I do then granting something to public and the client will not be very happy so okay if you remember with dba permissions we were executing code by calling a dbms scheduler now the problem was that so yeah so when we passed on when we ran dbms scheduler can we not pass the entire thing as an argument to dbms scheduler well it would it would have made my life very easy had that been had that worked but it didn't work that's because dbms schedulers create program procedure which we are calling it can only take up to thousand characters as as input so that did not work so okay I think I'm sorry there are slides are the other way around so what finally worked is we created a directory within the directory we create a we create a procedure to write files on the system using by calling utl underscore file we execute the procedure this procedure to write the vbscript which we want to write we execute the vbscript to create metasploits payload or sorry metasploits executable on the target oracle database and then we run this executable all in one request and that's how that request looks like so we are doing quite a few things in one single request right so so let's see a demo of one click on edge so there is already a tool web reader we've just wrote a few plugins for web reader which will let you do stuff in oracle so we again go back to our blind SQL injection obviously I mean in this particular example we are using this technique for interactive injections for exploiting interactive SQL injections but the idea behind this is that you use this for non interactive ones as well which you don't really see so what you do is you choose your public IP address on which you want to throw the reverse connection you choose your attack what attack you want to carry out you want to carry out a SQL injection in oracle or with dba permissions or mssql whatever once you choose the once you save that then okay this will this let me just pause this for a minute okay so the idea behind this is that this will essentially give you the the payload which you will which you want to be injecting for for non interactive SQL injections so it will give you a payload which is URL encoded so if you are carrying out a SQL if you are if you are authenticated to the website and you have I don't know some CSRF token protection so we didn't want to have cookies and everything added into our tool so you can basically just inject take this string and inject into the relevant get or post parameter and carry out the job so it will give you a string which is URL encoded to carry out injection from web applications or it will give you the other one for interactive like SQL plus connections okay and then if it is a simple get request you can just click on the start button and this will give you reverse shell metasploits metasploits in one click there you go so Metaprète session open okay okay so moving on using this particular function create master process you can execute dml and DDL statements so like you can do grant dba to to any particular user if you can execute DDL and dml statements then obviously you can write SQL injection worms SQL injection worms rose to this scene almost two years ago all they do was change applications front end to inject malicious javascripts within the iframe of the front end and then distribute browser exploits. Same worms can be written for Oracle based applications. For example, if a SQL injection worm in MS SQL looks like this, then you can write a corresponding SQL injection worm in Oracle. So Oracle applications can be equally vulnerable. It's just that they have not been exploited in the wild. Right. So moving on. So is there anything that we could do to protect sensitive data in the database? So I mean, you can you can defend your applications against SQL injection, but what if you want to have some defense in depth mechanism to say that even there is a SQL injection, the data which the attacker gets should be pointless. So that's where I think compliance comes into picture. So PCI compliance mandates that the car data, the pan, must be stored encrypted. The distribution of the distribution of keys used for encryption decryption should be should be controlled and regulated. So what happens when an attacker finds a SQL injection vulnerability in such a website, which follows all this compliance, does that mean that car data which the attacker gets is all encrypted? So it will be pointless for the attacker to have this data if obviously he can't get the keys for decryption. So for example, here is a sample from a particular credit card table. As you can see, the car data is all encrypted. So even if you were to find a SQL injection, the data which you have without the keys will be pretty much useless. Right. So what I found was what happens in this regulation, it does it talk about where the encryption occurs? Does it occur or should it occur at the database level or should it occur at the application level? So what if the encryption occurs at the database layer? So in this particular case, there is an application server which is different from a database server. So you have a three tier architecture. And so for storing credit card information, we are doing an insert statement. And while inserting, we are calling a built-in oracle function, which is a DBMS of the first question toolkit dot triple desk encryption. And this triple, this desk three encrypt function takes the card number as one argument and takes the encryption key as a second argument. Okay. So this is actually quite interesting. So this makes me think that what is more important here, the data or the query, although the data which is stored in the database would be encrypted using this mechanism, but the query which will be executed on the database server will actually have the clear text pan and the clear text string in it. So at any point in time, whenever that query executes on the server, if I can get a log of that SQL query, then I'm pretty much done. If I can obtain that query, then I don't really care about the data because that query will have the clear text pan. And more importantly, it will have the clear text string. So I am not interested in data. I'm interested in the query. So the SQL queries executed on the database server, they can be forensically obtained. V dollar SQL is one table in Oracle, which lists statistics on shared SQL area. This table typically stores last 500 queries. So if you repeatedly keep querying this table, you will find out all queries which have been executed on the database server. Because it's a dynamic view, sometimes the content of this table, sorry, of this view gets written to this particular table, WRH dollar under square SQL text. And in that case, these queries are actually permanently logged within the database. Similarly, in MS SQL, you can obtain these queries forensically by calling the plan cache. So this is how the query will look like when it will be run on the server. As you can see, the clear text pan and the clear text string would be present in the SQL query when it runs on the server. So if you query SQL underscore text column from V dollar SQL, then you will find the clear text pan and the clear text string more importantly. So these are some screenshots which says these are the strings. Similarly, you can obtain plan cache in MS SQL. So if in MS SQL, here is an example of somebody MD5 hashing a credit card information within the database. So if you look at the bottom half of the screen, the data in the database is MD5 hashed and it's safe. But if you obtain the plan cache, then you will find that the plan cache contains the clear text pan number. So that to me is a fail. Right. So when we talk about SQL injections, we talk about some really complicated hacks and sometimes we miss out on some easier versions. So we were investigating a SQL injection, a breach from SQL injection and when I found this particular technique, which I thought was quite neat. So I left me actually, I've only got five minutes, so it's best to run the demo before this man throws me out of here. Okay. So stealing unencrypted card data from the database when it's not stored as clear text. So we have our e-commerce shopping application. Any resemblance to any application is purely coincidental. Right. So you click on, you choose a page, you click on buy now. It follows PCI compliance, so it goes over a secure page. You log in, supply your credentials, go to the, select the item, enter your card number, details, and basically just buy the product. Right. So what happens if in such a, such an application, you find a SQL injection? As we saw earlier that this particular application has a different application server and a different database server. So even if you compromise the database server, you will not have the key because the key is stored in the application server. You can use the attack vector, which I mentioned earlier, but to query VDOL or SQL table, you must have DBA privileges. So what if you don't, like in this example, then you cannot obtain the queries forensically. So you are pretty much struck. So we find a blind SQL injection in this application. So we do some and one equal to one and one equal to two. Right. And then we run some tools to exploit SQL injection. So we run BSQL, BF to exploit this particular vulnerability. And we find, we do some basic exploitation. So we find, we are running queries with Scott user, which is a really limited user. So we can't really query VDOL or SQL to obtain the queries forensically. We find out what the version is, maybe we can do privilege escalation. And it's actually an Oracle 11 G 1.0.6. So I mean, we don't really know of any privilege escalation vectors against this database. So it looks fairly secure. Now we find a card number table from credit card table. Sorry. And if we extract the data, then we find the data is actually encrypted. So unless we have the, the private key, sorry, the, the decryption key, this data is, is virtually useless to me. So this is how the white box side things look like. The application server connects to the database server, which is a different IP. It's using the Oracle's triple description for encrypting strings. The string is stored in the application server. I can possibly compromise the database server, but that will mean that I still don't have the, the private key, sorry, the decryption key right next to what the attacker does is he logs on to the server and he observes something. What he observes is that when he logs in on that payment page, he sees his, his, his full name displayed on the screen. So he's, so this particular data, his first name or his first name, last name is actually a session data coming from the database. And that will be true for every single user who logs on to the application. So what if he can poison this data for every single user to contain a, to contain a JavaScript key logger? So he does that. He, he runs some massive update statements to, to alter the database and contain a malicious JavaScript on that web front end. So he issues a series of three commands, one after another. Okay. The looks are changing. So I'll just rush. Okay. So once he, he does that and he, and then now the victim logs in, then you will see that the data coming from the database, the session data has now changed and it now contains a JavaScript which points to the beef server. So what we are doing over here is we are not hacking the data within the database. We are hacking the data which is about to be written to the database before it touches the database. So when an end user logs in, this JavaScript will connect back to the beef server. So if you configure your beef server, then you will find the zombies connecting back to the beef server. So here we go. The zombies are connected. And then if you go back to the victim screen, then what you will find is, okay. Yeah. And then if he enters his details again onto that page, then you will find all that is available via our JavaScript key logger and it is sent out to a beef server. So who really cares about the data in the database? If you can obtain it like that. Okay. So I've been asked to leave the stage. That pretty much is the end of the presentation.