Hacking and Securing DB2 LUW
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 122 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/40534 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
Inhalt <Mathematik>TabelleInformationVersionsverwaltungGesetz <Physik>TopologieSpezialrechnerComputersicherheitDatenbankExpertensystemSoftwareschwachstelleReelle ZahlInternetworkingVersionsverwaltungVerschlingungBildgebendes VerfahrenPatch <Software>MultiplikationsoperatorBitDesign by ContractWellenpaketSchnittmengeNormalvektorDifferenteNotebook-ComputerSoftwareSystemplattformArithmetischer AusdruckBefehl <Informatik>FreewareServerSystemprogrammBildschirmfensterWeb SiteExploitComputerarchitekturTransaktionComputeranimationVorlesung/Konferenz
04:33
TopologieExploitDienst <Informatik>SystemzusammenbruchInstantiierungZufallszahlenPufferüberlaufSpeicherverwaltungDatenstromKnotenmengeOrdnung <Mathematik>Prädikat <Logik>Einfache GenauigkeitPartitionsfunktionTabelleInnerer PunktVariableZahlenbereichMathematikSCI <Informatik>CodeVIC 20InjektivitätQuellcodeAnalysisMaskierung <Informatik>Elektronische PublikationBenutzerdefinierte FunktionFunktion <Mathematik>StichprobeIRIS-TRechenwerkTopologischer VektorraumUnendlichkeitATMParametersystemVerschlingungFortsetzung <Mathematik>DatenbankAlgorithmische ProgrammierspracheTabelleFunktionalLoginPortscannerComputersicherheitNormalvektorNetzbetriebssystemWeb-SeiteInstantiierungSystemzusammenbruchSoftwareSystemverwaltungMereologieCASE <Informatik>VariableSoftwaretestElektronische PublikationEinfache GenauigkeitWeb SiteDoS-AttackePhysikalisches SystemVektorpotenzialGanze FunktionMultiplikationsoperatorSoftwareschwachstelleSyntaktische AnalyseOrdnung <Mathematik>PartitionsfunktionParametersystemResultanteServerObjekt <Kategorie>Befehl <Informatik>ÄhnlichkeitsgeometrieLastCachingPunktTrennschärfe <Statistik>Prozess <Informatik>EinfügungsdämpfungZweiStrömungsrichtungStrategisches SpielVersionsverwaltungVerkehrsinformationWort <Informatik>Klon <Mathematik>Konstruktor <Informatik>InternetworkingEin-AusgabeValiditätStichprobenumfangDatenverwaltungQuaderWurzel <Mathematik>KonditionszahlProgrammfehlerAnalysisOrakel <Informatik>Lesezeichen <Internet>BildschirmfensterProgrammierungBitATMMathematikCodeDateiformatPlastikkarteSchnelltasteZahlenbereichInjektivitätDatensatzMailing-ListeImplementierungDifferenteSoftwareentwicklerMAPZeitstempelReelle ZahlBenchmarkEreignishorizontVirtuelle MaschineLesen <Datenverarbeitung>Güte der AnpassungQuellcodeAdditionZeichenketteTUNIS <Programm>AbfrageKonfigurationsraumDialektInverser LimesExploitVorzeichen <Mathematik>ProgrammierspracheDynamisches Systemp-BlockAbzählensinc-FunktionRechenschieberDichte <Stochastik>Message-PassingSystemaufrufE-MailMomentenproblemDateiverwaltungTexteditorMaßerweiterungAdressraumWellenpaketPlug inInformationBenutzerdefinierte FunktionBenutzerbeteiligungDefaultHoaxBimodulPasswortSchnittmengeProgrammbibliothekAuthentifikationPatch <Software>Maskierung <Informatik>Fächer <Mathematik>BootenVerzeichnisdienstWeb-ApplikationZufallsgeneratorSchreiben <Datenverarbeitung>ProgrammcodeProgrammierumgebungGrenzschichtablösungStabAggregatzustandInnerer PunktNetzadresseVollständiger VerbandVorlesung/Konferenz
Transkript: Englisch(automatisch erzeugt)
00:00
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.
00:22
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
00:41
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.
01:06
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.
01:32
The latest version of DB2 LUV, Linux Unix Windows, is version 9.7 called Cobra. And this version will be supported until 2014.
01:45
And here you can see when the patch sets are coming out, the fix packs. Then we have version 9.5 and version 9.1. And 9.1 will run out of the normal support end of 2012.
02:02
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.
02:21
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 PL-SQL and some other nice things. There are also trial versions, 90 days, available from IBM, but you have to register.
02:41
The biggest problem for me, if you don't have a support contract with IBM, is to get old versions. Because if you are looking for security vulnerabilities, and if you want to play with exploits, you are normally more interested in older versions than in newer versions. But that's quite complicated to get.
03:01
There are also some VMware images available. One is created by a guy called DB2Hitman, and he has an Ubuntu version. So you can just download this VM and then you can start playing with it.
03:22
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 editions, and IBM has also a data server, but sometimes it's difficult to find.
03:40
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.
04:04
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.
04:26
And you start at DB2 CMD, then you connect to the database and then you can run statements. It's not nice, it's not actually similar to SQL Plus. A little bit more convenient is the SQL Plus clone from IBM as well.
04:43
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.
05:09
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.
05:20
The problem, the 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, I always say Oracle, I did it too long.
05:45
DB2 may have problems with unsecure random numbers. This was fixed in 9.7 fix pack 1. And the majority of the exploits in the DB2 world are denial of service exploits.
06:00
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. So unsecure random number, if you call the random number generator two times, you're getting the same value back.
06:22
So this is not always a good idea. And this was one of the few zero day exploits. A 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.
06:44
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.
07:09
Somehow my keyboard is not working. So this is from a guy from Ukraine, Dennis Yuryshev.
07:22
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.
07:41
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 4 or fix pack 3, then you go through all the security bugs and you should also go through the instance crash bugs.
08:06
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 the opinion of IBM, Microsoft, and also of DB2.
08:22
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.
08:43
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.
09:03
So this was fixed a few months ago. And that's really weird that if you use the same condition, the database dies. So the entire parsing engine from DB2, from my experience, is less stable than the engine from Oracle or SQL Server.
09:22
SQL Server is the most secure from my experience. And then also if you use special constructs, 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 vendor says it's a test case.
09:42
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.
10:09
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 site, it's quite the same.
10:22
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.
10:40
Because there's no privilege which could be revoked. You just have to wait until IBM is releasing a bug fix. Also here outer join 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 outer joins.
11:08
And here by using this outer join, you can crash the database. Sometimes you're also getting wrong results. Also by using weird insert statements, you can also crash the instance.
11:23
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.
11:41
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 Unix system.
12:04
But using this DB2 License Manager, you're able to change the ownership from root files and other files. So you see there are a lot of potential issues there.
12:25
But comparing to, if I compare the different databases. So in the Oracle world, you have ten times more vulnerabilities. And IBM DB2 is between Microsoft, which is the best system so far, and Oracle.
12:44
So it's in the middle. And the fixpacks 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.
13:04
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 apply all the fixpacks just in time.
13:22
It often takes months or years before they apply the latest fixpacks. So that's common for all the big databases. What I also saw, and so far there's no paper about it. It's SQL injection in custom PLSQL code.
13:42
Because a lot of database vendors, database developers are creating their own stored procedure code in the database to be more performant. And since DB2 9.7, there are now two possibilities to write your own stored procedure code.
14:05
One is SQLPL, that's the old classic version. And two, 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.
14:26
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.
14:43
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 stored procedure from IBM called admin CMD. And with this admin CMD command, you can run from SQL these DB2 commands.
15:09
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 stored procedure.
15:23
A few months ago, there was a problem with a stored procedure called monreport.currentSQL. In some fixpacks, it was granted to public. And this stored procedure is revealing the entire SQL cache.
15:44
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.
16:02
But it's also a security problem because every statement also inserts 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.
16:22
That's why you should be careful with this stored 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.
16:43
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.
17:04
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.
17:22
So every vendor has a different approach. So in MySQL, for example, it's called GroupConcat 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 was vulnerable.
17:42
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.
18:02
So here we have a typical example. And you can see even without deep DB2 or database knowledge, you can find this vulnerability. We have a stored procedure, administrator grant privileges, and here we have a parameter OS user.
18:23
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.
18:40
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.
19:02
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.
19:20
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.
19:43
Here's another example. And if you go to the internet, it's really easy to find volume-level 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, vold table schema and vold table name.
20:06
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.
20:24
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.
20:41
Since DB2 9.7, it's also possible to use PL-SQL code. And with PL-SQL, you have a bunch of new vulnerabilities coming into the system. So the way in DB2 version of PL-SQL, you have to use DBMS SQL to create dynamic SQL statements.
21:07
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.
21:23
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.
21:46
Because the vendors are getting better and better, but the 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.
22:15
And then use the crap statement or use a text editor and search for strings like execute immediate and DBMS SQL.
22:23
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.
22:45
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.
23:08
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.
23:26
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 the new is utlfile and dbmslob from the Oracle world.
23:46
So in the Oracle world utlfile and dbmslob 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.
24:02
So with load data, it's quite simple. With import, export, I played a little bit. By using this ADM CMD, it's quite easy to use. So you say export to and then you are creating a test file.
24:21
And what I did on my test system on Windows, I was able to overwrite the boot.ini. So this export command does not protect your files. So if you overwrite the executable, this executable is overwritten by the export statement.
24:44
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.
25:01
And for a 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.
25:22
And additionally, you need a C function. And the C function is here limited, so you can read a file from the operating system. And the usage itself is quite simple. You say select staff from table and then you specify the function and you see the result from the file in your statement.
25:44
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.
26:02
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,
26:24
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.
26:41
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. Whatever you need on the operating system level can be easily done with a simple PLSQL function or an anonymous block.
27:02
The second possibility to read files is the function dbmslob. And here we have also a function. Or that's a copy-paste failure. Accessing the network, I haven't found something
27:20
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 start procedure block.
27:43
And then you can define the message, the dates, 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.
28:02
And in this case you can just use this call-util-mail.send and then you specify sender, recipients and so on. The last thing, accessing operating system, I found so far only the way why I user-defined functions.
28:20
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 SQL lib directory. Then we create a function, execute the function, that's it.
28:45
So similar to this read function, we have here a function system call. And this system call is calling the external file oscall system call. And you grant this to public. Also here it's a bad idea to do this.
29:00
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.
29:21
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
29:43
and then you are changing the configuration. And the db2 CIS benchmark is quite good. So if you compare the CIS benchmark for MySQL or Oracle, the db2 benchmark is quite good. And I would recommend to use this as a starting point.
30:01
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.
30:21
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 PL-SQL if it's not needed and check the OS credentials.
30:43
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.
31:01
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.
31:26
What are the typical steps to harden the db2 database? You should have a look at the OS credentials. In the real world you find weak OS credentials.
31:42
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.
32:02
What I heard in db2-10, this discovery mode will be removed in db2-10, version 10. And we have too many privileges, weak default configuration, missing patches and unsecure program code. So this is more or less normal like every other database vendor.
32:25
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.
32:43
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.
33:02
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.
33:26
Also discovery, authentication, that the authentication is encrypted and so on. That's something I'm a big fan of logon trigger because the majority of database administrator, doesn't matter what vendor,
33:43
they have no idea who's connecting to their database. And that's why it's really important to know who's connecting from what machine with what account. Only in this case you can limit access to the database.
34:02
So you can say, okay, only from this machine the agent account is enabled to do this. And so there's a new functionality called ConnectProc and with this ConnectProc it's quite easy to implement logon trigger functionality.
34:22
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
34:43
but I think for the beginning it's quite a good idea. Then you create a stored procedure and it's important that the stored procedure doesn't have a parameter. So only if this stored procedure runs without parameter it works. And here we are inserting this, we are inserting in this audit table we created before
35:06
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.
35:30
So the next time when we connect we can see this connect string here in the select state in this table.
35:41
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
36:02
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.
36:26
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.
36:41
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
37:02
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.
37:20
But I'm aware there are also plugins where you can use a table for connecting to the database. So people migrated the 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.
37:46
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.