 Bien, mi nombre es Esteban y hoy vamos a hablar de hackear y proteger la base de Oracle Database Vault. Esta es la línea de visión de esta presentación. Primero vamos a ver una introducción a la base de Oracle Database Vault. Esta es un nuevo tema para este tipo de conferencias, así que vamos a hacer una introducción de lo que es la base de Oracle Database Vault, lo que cambia, lo introduzca y lo que son sus elementos. Luego vamos a mover a la parte más importante de esta presentación que son los ataques contra la base de Oracle Database Vault. Vamos a ver ataques que verán el sistema operativo para poder comprometer la base de Oracle Database Vault y la base de Oracle Database. Vamos a ver cómo impersonar al usuario de Maxxis, que es el usuario más importante en la base de Oracle Database Vault, es el usuario de la base de Oracle Database Vault. Luego vamos a ver algunas consideraciones especiales para el usuario de CIS y cómo podemos comprometir la base de Oracle Database Vault usando SQL Injection vulnerabilidades en el esquema de CIS. Luego vamos a ver algunas cuestiones con audiciones de database nativos con el usuario de CIS. Finalmente vamos a ver algunas protecciones adicionales y algunas conclusiones. Bueno, ¿qué es la base de Oracle Database Vault? Es importante saber que es un adón a la base de Oracle, no es instalado por default, es instalado principalmente para añadir features de seguridad que no tienen el database y que están necesarias, por ejemplo, para las regulaciones de la base de CIS, como Serbán Oxley o PCI, que se llama para la separación de la fecha, la separación de la fecha dentro de la base de database. Entonces, la base de Oracle Database Vault lo permite separar en actividades como el manejo de acción, el manejo de la base de database y la seguridad de datos. Este adón de productos protege contra ataques que pueden ser realizados por un usuario muy privilegiado, como la administración de database. Así que ahora el DBA no tiene acceso a datos de database limitados. Después de instalar este adón de productos, hay algunas cambios en la configuración del instante de database. La primera cosa que puedes ver es que los parámetros de inicialización están cambiados para más valores seguros. Esto es documentado en la documentación de la base de database de Oracle. El feature de Recycle Bean está disablado. Algunas prioridades están removidas desde los roles de Oracle default, como el DBA Role, porque algunos de estos prioridades pueden lead a el compromiso de las features de la base de database de vault de seguridad. También, la audiencia neta de database está confundida para incluir más acciones, pero actualmente la audiencia no está en riesgo. También hay algunos cambios arquitecturales como la tabla de $SIS Out $ is moved to the system schema and instead of the SIS schema. Bueno, pero todos estos cambios no tienen ningún feature de seguridad. Puede ser hecho solo por algún administrador de database a algún instante de database. Y lo que es importante es que hay algunas protecciones que están adecuadas. Por ejemplo, hay algunas esquemas que están protegidas por default con Realm. Vamos a ver más tarde lo que es Realm. Entonces, la SIS y el SIS schema están protegidas como well as some sensitive commands like the commands that are related to account management. For example, create user, alter user, etc. All these changes are incompatible with the some operations of the database like installing patches. So it is required to disable database vault when we want to install patches. Oracle documentations state how to disable Oracle database vault in order to install the patches. And that is what is found in the documentation for Windows. We can rename a DLL file. And on Linux and Unix systems we should execute a couple of commands to disable database vault. There are some other changes that all the releases that were in place in all the releases like the operating system authentication to the database disabled. And that login with CCDBA privileges were blocked. This of course had a lot of problems and incompatibilities with some of the tools like Arman and some other Oracle command line utilities. But there is a parameter in order pwd tool to enable the CCDBA access as well as overwrite the SIS password. So as you can see if we have operating system access as the Oracle user we are able to first we are able to disable database vault and also we can overwrite and enable the CCDBA access. Well now let's see what are the elements that are provided by database vault to that one can use to secure further the database. The most important concept probably are the realms that are functional grouping of database schemas and roles that we want to secure for example when they are related to accounting or employees. So you can use a realm to control the use of the system privileges to a specific account or role that are a part of this realm. So we even if we have for example a select any table privilege or update any table privilege we want to be able to access an object that is protected by a realm. Then we also have the factors that are named variables or attributes such as IP addresses, user locations or session usernames. These factors can be used to control the access to the database. These can be used to provide protections against application bypass or ad hoc database access. Then we also have some other concepts that we can use to further protect the database. Also there are some schemas that are installed when we apply this when we install this add-on database vault product. The most important one is DVC's that contains all the database vault objects such as the tables views and PLC equal packages that we can use to administer and configure the database vault installation. This schema of course is protected by a realm so that administrators can't access it. The DVF schema that is also part of database vault is used to retrieve factor identities. It has functions to retrieve IP address, session username etc. There are some roles that are provided by Oracle database vault that we can use to give the necessary authorization to administer or to use database vault. The most important role of the most full privileged role is DV owner and we also have a DV realm owner that is an owner of a realm but DV owner is the owner of all the database vault. So it's the most privileged user. Then we have a DV account manager that is used for account managing. It can create users or alter user passwords. Then we have DV second analyst that is a role that allows to run reports of database vault. There are some users that are created when we install the database vault. This is asking that the user is asked for the user names and password when one is installing database vault. So actually the user names in a installation can be different than the ones that are used here in the presentation but these names are the ones that are used through the documentation. So we have an account for the MAC account that is the account responsible for the administration of database account. We must use this account to create or manage users. Then another important user is the maxis user that is the, as I said before, is the database vault owner. So it has permissions over the database vault realm that is the one that protects the DVC schema that contains all the database objects of database vault. Well, there are some security considerations that are documented. Here I enumerate a few. This presentation is not going to focus on these documented considerations. There are some considerations with PLCQL packages such as UTO file. One can imagine that this is because this can provide file system access to anyone that has access to these PLCQL packages. Also it is documented that there are some privileges that can lead to the compromise of database vault, such as the one that are related to shop management, the recycle bin, and the external procedures. And there are also some trusted accounts that must be secured. The documentation said that the Oracle software owner and the cdba users are accounts that must be trusted. Well, now let's see what are the attacks that we are going, that we can do to compromise the database vault. First, there are the operating systems attacks, the attacks that will look for operating system access being a user connected to the database. So, we are going to see some examples of this. Also, we are going to see that it is possible with a couple of system privileges to create and execute a procedure in the maxis schema and impersonate the maxis user. We are going to see that the sys user can bypass the database vault, and we are going to see that impersonating the sys user through sequence injection we can compromise the database vault. Also, we are going to see some vulnerabilities that are specific to the database vault. Well, let's see some ways to get operating system access through the database. This operating system access, as the Oracle software owner or as root or administrator user in Windows, allows an attacker to disable database vault, and additionally to override the sys password and enable the cdba connections if they are disabled. There are many ways in which an attacker could get operating system access. There is the external procedure call method. The following example is about this method. We are going to see also that exploiting a buffer overflow vulnerability can allow for operating system access and the disable of database vault. Also, it is possible to use Java store procedures to get operating system access and also through external shops and creating a directory object could also lead to file system access and the compromise of database vault. In addition, if we don't have the required privileges to perform these kinds of attacks, we can use sequence injection vulnerabilities and use one of these attacks. Well, let's see now the first example with a demonstration, the method using an external procedure call. An external procedure is a procedure that is stored in a dynamic link library, a function in a dynamic link library. So, we first need to create a library of objects on the database that points to an external gll file and then we create a procedure that points to a function in that library. So, there are some restrictions. In Oracle, we can't load libraries that are outside the Oracle Home Live directory in Linux and Oracle Home Beam directory in Windows, but I found that there are interesting libraries in those directories that can lead to execute operating system commands. So, for Windows, we have the VisualSea runtime library that has the system function to execute operating system commands and also there is another library in Linux, the LiveOS Utils library that has an exec function to execute operating system commands. So, to perform this attack, we need to privileges that create library and create procedure privileges. We just need first to create the library object inside the database. This is done with the create library statement. There are the examples for Linux and Windows. After we create the library object, we have to create the procedure that points to an exported function in that library. So, here I create a procedure that points to the system function. And now I can use this OS exec to store procedure inside a PLCquad program to execute the operating system command I pass as a parameter. So, after I execute this to create library and create procedure statement, I can execute operating system commands as the Oracle user or system authority in Windows. So, to disable database vault, we can execute these two statements that are the ones that you execute to disable database vault. And for Windows, we can execute these any of these two statements. It is different if we are talking about Oracle 10G or Oracle 11G, because the name has the name, the DLL file name has the release version in its name. So, let's see an example. Let's see the demonstration. This SQL script contains the statements that I just show you. So, we create a test user and grant create session, create procedure and create library privileges. So, this user doesn't have any database vault role granted, so, it shouldn't be able to disable database vault or compromise database vault in any way. After I create the user, I create the library, the store procedure, and then call the store procedure that I just created to rename the DLL file. Look that we can use the environments variables, so, we even didn't need to know where the Oracle home is located. So, let's see. Let's execute this. This VM has Oracle 11G installed with DB Vault. Let's see first how the protections works. Let's suppose we want to protect the HR schema. I will connect a system that is a DBA user and select from that schema and I will get all the results because the HR schema is not protected yet. But I will create now a realm to protect this schema with these statements. I connect as the database vault owner user and then create a realm. I give it a name. Then, I authorize a user for this realm, the HR user. Then, I will say that it must protect the HR schema and all its objects in this schema and gives a description of the realm. So, after I create this realm, I will no longer be able to select from any table. Even if I am a database administrator, I will get insufficient privileges error. But let's now disable database vault using this exploit. We are going to see here is the DLL. It just got renamed with an underscore. So, the next time the Oracle instant is started, Oracle database vault will be disabled. I will restart the instance and check again if now I can access the HR schema. Let's continue. It will take a bit to restart the instance. So, there are a couple of things that we can do to protect against this attack. First, we can avoid granting the create library and create procedure privileges to user, especially the create library privileges that is the one that allows to associate a database library to an external dynamic link library. Or, at least, enable these privileges just for the period of time that is needed. Also, there is an interesting setting in listenerora file. The exprock DLLs setting can be used to restrict what libraries can be loaded. So, we can just name there the DLL files that we know are secure and that our applications need. No other DLL files will be able to be loaded. Let's see. It is still restarting the database. So, we are next attack example that will get operating system access is the Java attack. There are two approaches that I will be showing today. One that doesn't require special privileges and it uses the vulnerabilities discovered by David Litchfield this year and that are fixed in April 2010 CPU. Or, another way to do it is that using the functionality that is available to privileged users. The privileged users that database vault is supposed to protect from. While the database was restarted, let's see now if the protections are still in place. I will connect a system and try to select from the HR. And as you can see now, I can select from the HR schema. So, Oracle database vault was disabled. Let's enable it again so we can continue our demonstrations. So, there are basically two steps for this attack. For this attack that will use the Oracle Java functionality in Oracle to get operating system access. First, we need to grant the Java privileges that are required to access operating system resources. This can be done in two ways. One is using the grant permissions store procedure. But this one requires the Java admin role. This is the official or documented way to do it. Or, we can use the import JVM PRAMS store procedure that are the ones that are with the Oracle Java vulnerabilities fixed in April 2010 CPU. So, this method doesn't require any privileges because this store procedure can be called by any user. Then, after we have the required Java privileges, we should create the Java store procedure that will contain the Java instructions to execute an operating system commands. These Java instructions are the standard Java for execute an operating system commands that will use the Java functionality to do that. Or, we can use, instead of creating this Java store procedure, we can call an existing Java class that Oracle had the Oracle Aurora utility wrapper class that contained a function to execute operating system commands. This one are not available if we have April 2010 CPU applied. So, let's first see an example of using the, if we want the Java admin role so we can use these statements to grant the necessary Java privileges. With these statements, here I grant the necessary permissions to the one DBA user. After that, I create a Java source that will take one argument that is the command that we want to execute. And then create a Java store procedure that will call this Java method. So, we can use it in a PLCQL standard program. So, we can, we could execute this statement to overwrite the CIS password as any pass and to enable CIS DBA access or we can use this other statement to rename the DLL file to disable database vault. Let's see how it works. Well, this script contains the same instructions we just seen in the slides. So, we have the DLL file with the correct name. We are going to execute exploit and we will see that the DLL file will be renamed. Well, the way to defend from this attack is to restrict the Java admin role that is the role that is needed to grant the Java permissions needed to access operating system resources or to remove the Java support from Oracle Database if we don't need it. Let's see if, well, as we can see now the DLL files has an underscore. So, the database vault will be disabled. So, we were able to disable the database vault having the Java admin role. Let's see now a way to do this with no privileges. It is needed just these two statements. The first one gives the necessary permissions, grant the necessary permissions to the user that is exploiting this vulnerability. And then we just use this function to call the Oracle Aurora UtilRapper class, the main method in that class, and we just execute the operating system, pass as argument the operating system command we want to execute. Yeah, no, no, I will just show that it gets renamed. I won't restart and start it again. So, the DLL now has the correct name. After I execute this exploit, we can see that the DLL file got renamed. So, to defend from this attack, the one that doesn't use any privileges, we should apply the April 2010 CPU that fixes the Java vulnerabilities that allow to grant the Java permissions even if we don't have the Java admin role granted. Or we could revoke the privileges from this dbms.jvm.experms package that is the one that is used to grant the Java privileges. Well, let's see now an example how we can get operating system access and disable the database vault with a buffer overflow attack. This buffer overflow is in a store procedure. So, we need execute permissions on a vulnerable store procedure. Well, this is the exploit. I won't enter matching into detail. The vulnerable parameter is the dirpath parameter. So, when the buffer overflow, the evx register points to the start of this dirpath buffer. So, here I enter the instructions that I want to execute that basically are the equal to the system function of C runtime library and then the function so that the threads end and there are no exceptions thrown after it continues with the execution. Let's see how it works. I will use a 10.0.0.0 release to Oracle because this vulnerability is in that release. So, we have the DLL file with the correct name and as we can see the file could rename it with an underscore. So, now the database vault is disabled. Well, to defend from these buffer overflow attacks Oracle fixes these buffer overflow attacks, the one that researchers report to them or the one that they found internally with critical patch updates. So, we can apply CPUs to be protected from known buffer overflow vulnerabilities. Also, it's important to reduce the attack surface. So, we should restrict the execute permissions on packages because there are a lot of packages with buffer overflow vulnerabilities. Let's move now to the impersonating maxis attack. This one requires create any procedure and execute any procedure privileges. So, it basically has two steps. First one is to create a procedure in the maxis schema and then we just execute this procedure which we just created. As we know, Oracle by default executes the store procedures with the privileges of the owner of the schema. So, if we are able to create a store procedure in the maxis schema, we can execute statements as this maxis user. Here is the example. We just prefix the store procedure with the maxis schema name. So, this procedure takes a statement as an argument and execute it. After we have this statement, this procedure created, we can call it with a SQL statement as its parameter and it will be executed as the maxis user. Let's see. So, here the script first create a test user and grant the required privileges to exploit this problem. We then connect as this user and create the store procedure in the maxis schema and then call it to change the password of the maxis user. As we are impersonating the maxis user, we are able to do this. If we are not a maxis user, even if we are DBAs, we can't change its password. And then, I'm going to show that you can now connect as maxis with this new password. Well, as we can see, here first I connect here. Here I can connect now with the maxis any password use, any psw password. Well, there are a couple of things we can do to protect from these attacks. First, we can restrict the privileges that are needed to perform this attack that are the create any procedure and execute any procedure privileges. We should consider also to protect the maxis schema with a realm. We can do that by executing those SQL statements. If we have the maxis schema protected, then even if we have the create any procedure privileges, we can compromise the maxis schema because it is protected with a realm. Well, there are some considerations that are documented for the CIS user, but it's actually the documentation doesn't say much about how the CIS user can compromise. So I researched a bit and found that it can compromise using this pass as user store procedure that can impersonate the maxis user. So we can alter the maxis password and also in other releases, the maxis user can do some other things like directly update all the data dictionary tables. So for example, if we are the CIS user, we could update the maxis password using this statement or we can grant the DV owner role in adding a role in the CIS of dollar table. So what about a SQL injection in CIS schema? If we can impersonate the CIS user using SQL injection, we can use some of the techniques I just mentioned to compromise database vault. Here is, for example, how we can do it with this vulnerability that allows to execute statements as the CIS user. So we impersonate the maxis user with this pass as user function, and then after we have impersonated the maxis user, we grant the DV owner to any user. This is another example here. This SQL injection vulnerability allows to inject a function call, so I will need to create an auxiliary function that will contain all the statements that I want to execute as the CIS user. Here I use another of the ways to impersonate the maxis user and after impersonating it, changing its password. Well, a CIS can be used in this case. This one is another example using a SQL injection vulnerability, but this time I will insert directly a row in the data dictionary internal table. This one is the same as doing a grant DV owner statement, but I just update directly the data dictionary table. Of course, if I execute here a grant DV owner statement, it won't work because the database vault protections are in place. Even if you are the CIS user, you can't issue a grant statement. But doing this direct update of tables, you are able to grant the DV owner role. Well, this is a further analysis of the SQL injection vulnerability that I just saw to see if we can exploit it without the need of an auxiliary function. We don't have too much time to enter into detail, but here I select from the V$ SQL text table to see what are the SQL statements that have been executed from the SGA Oracle memory. So, I see where exactly the vulnerability is here in green. I can see that the parameter I insert is used here. So, as we can see, there is a begin and an end. So, we can just close this top procedure call with a parenthesis and with a semicolon, we could add other statements without the need of calling an auxiliary function. So, here is how we could exploit this in a more simple way. And this is the statement that gets executed as CIS. I wrote a white paper, so if you want to see more how this works, probably you could read it as we don't have too much time. Also, there are some vulnerabilities more specific to the database vault implementation, because actually the ones we've just saw take advantage of the functionality that the Oracle database provides to be able to compromise database vault, but there are also some vulnerabilities specific to database vault one that was fixed some time ago that when we changed the language session parameter to anything different than American, the database vault real protections for DDL statements didn't work. And there are also some pending fixes that I reported to them and they are going to fix. Well, this is like a similar subject, but not directly related to database vault. There are some issues with the CIS user auditing. As it is documented, the CIS user is audited in a different way than regular users. They are all the statements that we execute as the CIS user are audited in the SQL text as we enter them. So, for example, if we call a store procedure as CIS, we just see the exact store procedure and we don't see all the things that the store procedure executes. So, what about SQL injection ruining as CIS? If we can exploit a SQL injection that is in the CIS schema, we could execute statements without paying audited. Well, there are some additional protection measures that we can take, first restrict the system privileges that can lead to full database compromise and the compromise of database vault. They become users and those other privileges mentioned there. This SQL statement can be used to retrieve all the users and roles that have these dangerous system privileges granted. We should take into consideration that we should never use the default oracle users or roles. It generally contains a lot of system privileges and they may change over time. We should create our own roles and grant the roles that the privileges that we know that are needed for the job. But there is also a way to change the external job operating system user if we change it to a low-privileged user and not the oracle or system user, we can protect that. If we create a job operating system in an external job, we can't access this DLL file or execute the commands to disable the database vault. Well, some conclusions. We just saw the separation of duty that is provided by oracle database vault. It can be bypassed. There are some system privileges that can lead to full compromise of the database vault installation. As we have seen, if we find an exploit vulnerability, a SQL injection vulnerability in the CIS schema, we are able to execute as SQL statements as CIS and we can compromise database vault o even execute SQL statements without being audited. So, I think that oracle should move out of the schema much of the functionality and use only the CIS schema for the core and most important part of the database. Also, I have been studying oracle database vault for a while and I have seen that its security is improving. It's also easier to use. It has more restrictions for the CIS user. There are more tools that are compatible with database vault. So, these are positive things. Well, in the white paper, you can find some more references and information. So, that's it. If we want to...