 And today I will talk about a new topic for me, so database DB2 security. And if you look in the internet, normally the first way is always to go to Google and search for DB2 security experts, but so far there are no real DB2 security experts available. And I think the majority of the security crowd is not looking at vulnerabilities in DB2. And today I want to show you a little bit of my research and also give you the resources with links to VMware that you can also start a little bit research if you want because I think it's a juicy target as well. Okay, I'm not sure who has experience with DB2. Okay, a few, I have difficulty to see. Okay, and when I start looking into a new topic, everyone is looking at Google. And my experience is that IBM is quite slow in releasing patches, so that's one of the first thing. Even after zero days were released, it took a few months until they released new security patches. The latest version of DB2, L-O-V, Linux UNIX Windows is version 9.7 called Cobra. And this version will be supported until 2014. And here you can see when the patch sets are coming out, the fixed packs. Then we have version 9.5 and version 9.1. And 9.1 will run out of the normal support end of 2012. So people should start slowly thinking about migrating to 9.7. One of the questions and in the IBM world, it's much more complicated to get the database software. You can get the free express edition. And this free express edition is available, thank you, for different platforms. But in some places they are quite limited. For example, the express edition does not support PLSQL and some other nice things. There are also trial versions, 90 days available from IBM, but you have to register. The biggest problem for me, if you don't have a support contract with IBM, is to get old versions. Because if you're looking for security vulnerabilities and if you want to play with exploits, you're normally more interested in older versions than in newer versions. But that's quite complicated to get. There are also some VM-based images available. One is created by a guy called DB2 Hitman. And he has Ubuntu version. So you can just download this VM and then you can start playing with it. So that's probably the fastest way to start with DB2. Because you save all the time to set up and configure the database. And there are also express edition and IBM has also a data server, but sometimes it's difficult to find. So whenever I want to download the IBM website, for me it's a nightmare. So I have always difficulties to find something there. So this is the architecture, but I don't want to spend too much time here. For me and many other people, the first time when you work with a database, probably the biggest challenge is how to connect to this damn database. So I saw it so many times that people want to connect to an Oracle database in the training and it took sometimes 30, 40 minutes before they were able to connect with their laptop to the database. So Oracle has the IBM DB2, they have a small command line utility CLP and you started DB2 CMD, then you connect to the database and then you can run statements. It's not nice, it's not ugly, it's similar to SQL plus. A little bit more convenient is SQL plus clone from IBM as well. So if you install it, it's part of the installation. It's called CLP plus and you have even a history, something SQL plus doesn't have in 20 years. Now I want to show you exploits and if you search in the internet, you will only find a few of these exploits because most of these exploits are coming from IBM itself. Because IBM is releasing a lot of exploit code. So if you go to their support pages, you find a lot of working exploits there. The problem that IBM guys are not aware that this code is exploit code. And I will show you some of them. So far there are only a few exploits available. If you come from the Oracle world, it's really a small amount of exploits available. So one problem, Oracle, I always say Oracle, I did it too long. DB2, they have problems with unsecured random numbers. This was fixed in 9.7, fixed pack one. And the majority of the exploits in the DB2 world are denial of service exploits. So whatever I saw, it's crashing the database, creating a denial of service, killing something and so on. In 9.7, it's similar, okay. So unsecured random number, if you call the random number generator two times, you're getting the same value back. So this is not always a good idea. And this was one of the few zero day exploits, Russian guy released zero day exploits and it took four or five months before IBM released fixes for it. So by running such a simple select statement, you were able to crash the database. So the load went to 100% and stayed at 100%. So this would be a candidate if you have a SQL injection in a web application, you can just use a union statement, append the select statement, and then you are able to do a denial of service. Somehow my keyboard is not working. So this guy from Ukraine, Dennis Yurichev, by sending this special package, you were able also to create a denial of service attack. And Dennis was also reporting another one, but it's too big. So by using fuzzing, I'm quite sure you will be able to find a lot of vulnerabilities there. And this is one of the exploits from IBM. And the easiest way to find these exploits is, you go whenever IBM releases a new fix pack, for example, fix pack four or fix pack three, then you go through all the security bugs and you should also go through the instance crash bugs because the majority of the database vendors, they say, if you crash a database, that's not a security problem. So if you run a select statement and the database dies, that's not a security problem. That's opinion of IBM, Microsoft, and also of DB2. And only if you release it to the press and you explicitly say that's a security vulnerability, then they are fixing it. But the majority of denial of service and database crashes are not handled from the database vendors as a security bug. And this is a good example that the entire quality of DB2, I talked also to several DB2, DBAs, is not that good comparing to Oracle. For example, here you have the problem if you have a duplicate predicate. So if you have the same condition two times, the database dies. So this was fixed few months ago. And that's really weird that if you use the same condition, a database dies. So the entire passing engine from DB2 from my experience is less stable than the engine from Oracle or SQL Server. SQL Server is the most secure for my. And then also if you use special construct, for example, a single byte partition. So you create this object and the database dies. And you get this entire code as a test case. So the database vendors say it's a test case. In the security world, it's an exploit. You can get it from the IBM pages. And I think IBM should rethink about their strategy to release this kind of code to the public. Also here, if you create such a table and run a select statement against it, then the database dies. Here we have this. Also here, if you use a keyword as a column name, you have the same problem. But it's not that bad for IBM. If you look at the Oracle side, it's quite the same. So if you use really weird SQL statements, the chances that you crash the database are quite big. So especially if you use reserved words, if you use short words, if you use special characters and so on. And here it's quite difficult to protect against these attacks because there's no privilege which could be revoked. You just have to wait until IBM is releasing a bug fix. Also here, OuterJoin is probably one of the most complicated constructs Oracle in the last few years. And also IBM and Microsoft SQL Server, they always had problems with OuterJoin. And here by using this OuterJoin, you can crash the database. Sometimes you're also getting wrong results. Also by using weird insert statements, you can also crash the instance. That's also one of my favorites. Just by using a lot of union statements, you can crash the database. So if you do a SQL injection and you append too many unions, the database will die. But it's not a security vulnerability for IBM. This was one vulnerability on the command line. So there's a small program from IBM called DB2 License Manager. And with this DB2 License Manager, you can change the ownership of a file. So normally DB2 does not run with root privileges on a unique system, but using this DB2 License Manager, you are able to change the ownership from root files and other files. So you see there are a lot of potential issues there, but comparing to, if I compare the different databases. So in the Oracle world, you have 10 times more vulnerabilities. And IBM DB2 is between Microsoft, which is the best system so far, and Oracle, so it's in the middle. And the fixed packs are normally the most interesting way to find new issues. So just go to the websites, look for everything which can crash the database. It's also a good idea to do this on the MySQL bug database. Just look for database crashes or for strange results. And then you can often create your own exploit for it because the majority of administrators does not have the time to fix, to apply all the fixed packs just in time. It often takes months or years before they apply the latest fixed packs. So that's common for all the big databases. What I also saw, and so far there's no paper about it, SQL injection in custom PLSQL code. Because a lot of database vendors, database developers are creating their own start procedure code in the database to be more performant. And since DB2 9.7, there are now two possibilities to write your own start procedure code. One is SQL PL, that's the old classic version. And the second possibility is to use PLSQL. So they license PLSQL from the Postgres guys because they hope that Oracle customers will switch from Oracle to DB2. And here is, before we look at the SQL injection vulnerabilities, two, three nice things, which are helpful if you work with security, a lot of the interesting commands cannot be executed from a select statement. Something like exporting a table or describing a table. That's not possible from a normal SQL command. And to circumvent this problem, there's a built in start procedure from IBM called admin CMD. And with this admin CMD command, you can run from SQL these DB2 commands. So for example, we can export a file or we can kill a session of another user. But it's clear that you need advanced privileges to call this start procedure. There was a few months ago, there was a problem with a start procedure called monreport.currentsql. In some fixed packs, it was granted to public. And this start procedure is revealing the entire SQL cache. So all the statements which were executed by other people are visible via this monreport function. And this is quite useful if you are doing performance tuning or if you are looking for problems and bottlenecks. But it's also a security problem because every statement also insert into a password table. This statement is visible in this current SQL function. Or if you are inserting numbers into a credit card table, it's also visible here. That's why you should be careful with this start procedure. And sometimes if you work with SQL injection, it's interesting to know how to create a semicolon separated list. So this is useful to get more out of a database. So if you're doing SQL injection, you're normally getting row by row. So if a query returns 100 rows, you're getting 100 lines. And with this statement, it's possible to get a semicolon or here a comma separated list in one row, one column. So this can be useful for SQL injection because with one SQL statement, you can get the entire table back instead of enumerating it row by row. And it's special because every database vendor has its own special dialect. It's not part of the normal syntax. So every vendor has a different approach. So in my SQL, for example, it's called GroupConnect to do this. So now we are looking at vulnerabilities in custom code. And all the code I reviewed so far in the internet and also at the customer side, both vulnerable. So I never saw database developers doing input validation. So it's difficult to understand why they are not doing it. Probably they think we are too close to the database and nobody will ever inject code, but that's not the case. So here we have a typical example. And you can see even without DB2 or database knowledge, you can find this vulnerability. We have a stored procedure, administrate our current privileges. And here we have a parameter OS user. And you see there's no input validation. So the input validation here is missing. And the developer of this code was doing the following. He's concatenating the value of OS user, which is coming from the stored procedure. And this is concatenated here. And after that it's executed. So this is one vulnerability. The second vulnerability is a second level order SQL injection. So the developer is trusting that the table names are always sanitized. But as a developer you can never guarantee what is the real table name. For example, you can create a table called exclamation mark IM, or you can use minus minus in a table name. In this case, this custom code is concatenated without doing input validation. So whenever you see such code, you should try to find the responsible developer and he should use bind variables, or if this is not possible here, for example, then he should do input validation. So he has to validate that the table name is proper and you have to validate that the OS user is in the right format. And here another example. And if you go to the internet, it's really easy to find vulnerable code because I never found people doing input validation. So the chances that you'll find something are really, really high. So here we have two parameters, V-old table schema and V-old table name. And you see here they are just concatenating the values without doing input validation. Or here it's similar, they create a string, concatenate everything together and then they call this with admin CMD. Here's one limitation. If you use admin CMD, you are not able to use command signs. So you cannot use minus minus to put something at the end or you cannot use a semicolon to expand the query. Since DB2.9.7, it's also possible to use PLSQL code. And with PLSQL, you have a bunch of new vulnerabilities coming into the system. So the way in the DB2 version of PLSQL, you have to use DBMS SQL to create dynamic SQL statements. So the problem here is we have a function, this function looks if the table is empty and we have a parameter, the table name. And this table name is concatenated to the query and the query is executed here with pass. It's passed and then executed and fetched. So if you use a union or a minus minus at the end of this parameter, you can extend this query and you can run whatever you want. And this is quite common and whenever you do a security audit for DB2 databases, you should also look at the custom code because the vendors are getting better and better, but typical database developer, they do not get money or time to develop secure code. That's why you will find a lot of these vulnerabilities. In my experience, the fastest way to do it is just extract the entire stored procedure code to a text file, to one big text file and then use the CREP statement or use a text editor and search for strings like execute immediate and DBMS SQL. And then you can search back for example here, DBMS SQL execute. Where is it coming from? From this parameter and then you can search if the parameters are validated or not. So it's not real magic. It's quite simple and easy way to find this. And for PL SQL, there's a source code analysis tool from Fortify, but for SQL PL, I'm not aware if there's source code analysis available. But I think doing it manually is also sufficient if you don't have tons of SQL PL code. What is also interesting is how to escape from the database. So the typical ways to escape is read or write files, access the network, send something to the network or escape to the operating system and then from the operating system to a different system. And accessing files, there are different possibilities available in DB2. So you can use the load data command, you can import, export, you can use a user defined function and new is UTL file and DBMS LOP from the Oracle world. And I, so in the Oracle world, UTL file and DBMS LOP are granted to public, which is not a good idea. And what do you think is the default configuration of DB2? It's also granted to public. So with load data, it's quite simple. With import, export, I played a little bit. It's by using this ADM CMD, it's quite easy to use. So you say export to and then you are creating a test file. And what I did on my test system on Windows I was able to override the boot.ini. So this export command does not protect your files. So if you override executable, this executable is overwritten by the export statement. So you can use it for a denial of service to destroy files on the database server. The third possibility is a user defined function. And for user defined function, you need a start procedure, create read file and the read file is calling a user defined function. And in the sample code from IBM, this is granted to public, which is also a bad idea. So if you play on the test system, you should not run it to public. And additionally, you need to see function and the see function is here limited. So you can read a file from the operating system. And the usage itself is quite simple. You say select start from table and then you specify the function and you see the result from the file in your statement. So it's really easy to use. Next possibility is UTL file to use PLSQL in DB2. You have to set a special environment variable. And I would recommend not to use it. So if you don't need PLSQL, you should remove it from the database. Because I think in the future, you will find a lot of vulnerabilities here. And I'm not sure if it's a good idea to use systems, to use a language from a different database vendor. And if you use it, then you should revoke all the public privileges. You should revoke the privileges from public. You can also remove files. So if you look at the documentation from the UTL file package, you can rename files, you can remove files. So whatever you need on the operating system level can be easily done with a simple PLSQL function or anonymous block. The second possibility to read files is the function dbmslop. And here we have also function. Oh, that's a copy-paste failure, okay. Accessing the network, I haven't found something from the original db2 part, but the Oracle stuff in db2 has two problematic packages. One is UTL SMTP and the second UTL mail. With UTL SMTP, you can write a small dot procedure block and then you can define the message, the date, the SMTP server, and then you send the email. If db2 is configured, so for using UTL mail, you have to configure the SMTP server in your system. And in this case, you can just use this call utlmail.send and then you specify sender, recipients, and so on. The last thing, accessing operating system, I found so far only the way via user-defined functions. And this is also quite simple. You can more or less use every language. Here I'm showing an example in C. First, we have to create an export file, library.dev. And we copy it to the sqllib directory. Then we create a function, execute the function, that's it. So similar to this read function, we have here a function system call. And this system call is calling the external file OS call system call. And you grant this to public. Also here, it's a bad idea to do this. And this is the C code. And you see here the system call, system command. And here you are executing the statement. And once you installed it in the database, you can just run the system call and can do whatever you want. Hardening DB2 is much more easier in my experience than hardening Oracle because you have less public privileges. And the big difference is you are hardening more on the operating system level. So you are running special commands and then you are changing the configuration. And the DB2 CIS benchmark is quite good. So if you compare the CIS benchmark for my SQL or Oracle, the DB2 benchmark is quite good. And I would recommend to use this as a starting point. So they have a lot of good recommendations. And from my experience, from security audits, I normally recommend disable everything which is not necessary. In DB2, it's much easier because for a lot of additional functionality you need a license file and you have to pay for functionality. In Oracle, everything can be installed without additional license. That's why people often install everything. And in DB2, they normally install only what is necessary. Do not install the PLSQL if it's not needed and check the OS credentials. So in most of the cases, the biggest problem in other databases are the user credentials. So developers are lazy guys and if you have a username, they often use the same string as a password. And this is also the case in the DB2 world, but it's not a DB2 problem. It's an operating system problem. So finding credentials like DB2 Inst or DB2 Admin, DB2 Admin is not uncommon. So it really depends from the configuration of the underlying operating system. But in general, the situation is better than other systems. Okay. What are the typical steps to harden the DB2 database? You should have a look at OS credentials. You should, in the real world, you find weak OS credentials. You find that the discovery mode is enabled. The discovery mode is announcing in the network what databases are available. And just by disabling this discovery mode, you will be much more secure because it's much more difficult to find the database. What I heard in DB2.10, this discovery mode will be removed in DB2.10, version 10. Then we have too many privileges, weak default configuration, missing patches and unsecured program code. So this is more or less normal like every other database vendor. So the hardening, disable the discovery mode, change default port. So this discovery mode is disabled by using these two DB2 commands. And after doing this, it's disabled. Then you can change the port. It's also recommended in the CIS benchmark. I was never a big fan of changing the port, but if you live better with it, it's okay. Normally with a port scanner, you will find the port even if it's running on a quite strange port. Then here are some of the privileges which should be removed from public. So you can just put it into a script and run it. There are quite a few of them. Then here are some other useful parameters and you should check that you have these strong settings available. Also discovery authentication that the authentication is encrypted and so on. That's something I'm a big fan of log on trigger because the majority of database administrator doesn't matter what vendor. They have no idea who is connecting to their database. And that's why it's really important to know who is connecting from what machine with what account. Only in this case, you can limit access to the database. So you can say, okay, only from this machine, the agent account is enabled to do this. And there's a new functionality called connect proc. And with this connect proc, it's quite easy to implement a log on trigger functionality. So what we do first is to create a table and this table is storing the information about the user ID, the event and the timestamp. So you know at least who's connecting to the system. If you play with this, you should probably extend it to a few additional values. But I think for the beginning, it's quite a good idea. Then you create a start procedure and it's important that this start procedure doesn't have a parameter. So only if this start procedure runs without parameter, it works. And here we are inserting this, we are inserting in this audit table we created before the connect and the timestamp and the username. Then we update the configuration. And here it's important that we first set it to null and after it we specify the function. So the next time when we connect, we can see this connect string here in the select state in this table. And I would recommend in the beginning, look after a few hours into this table to avoid that it's filled up quite fast. And if you have a process which is connecting every few seconds to the system, you should probably add an extension and think, okay, if this special user from this IP address is connecting to the system, do not record this activity. So I see I was quite fast, faster than in my trainings, in my preparation. So at the moment, there is nearly no DB2 security resources. So if you look in the web, there are a few outdated books and there are no modules in Metasploit as far as I remember. And the majority of the security crowd is not looking at DB2. But I'm quite sure if you look at it, you will find a lot of interesting stuff. And the most interesting security bugs are at the moment published by IBM. But sooner or later, they will also realize that it's a bad idea to publish exploit code. And concerning the password problem, which is the biggest problem in other databases, like Oracle, it's not existing because DB2 delegated this problem to the operating system. But I'm aware there are also plugins where you can use a table for connecting to the database. So people migrated to Oracle concept of a username table to the DB2 world. But it's quite rare that you find this. Okay, thank you for the time. So it was quite fast. And I updated this slide a little bit, this slide deck, and you will get the updated version as PDF.