The Database Hackers Handbook: Defending Database Servers

According to research published by the IDC in August 2003, IBM's DB2 enjoys a 33.6% share of the RDBMS market. What I find strange , though, is that in all my years working in security and performing network and application assessments I've come across DB2 only three times, whereas other RDBMS such as Oracle, Microsoft SQL Server, and mysql are ubiquitous. This suggests that either the DB2 figures from IDC are wrong, which I doubt, or that DB2 boxes are deployed so far back into the typical organization's network that I just haven't been given the jobs that look in those particular areas. In discussions with other people working in the same field, their experiences are the same. We all agree that DB2 must be out there, but where exactly "there" is we're just not quite sure. Needless to say, after people have read this I'll probably have a score of DB2 pros mail me and point me in the right direction. Of those three instances in which I have come across DB2 deployed in the wild, two were hanging off the back of an application running on IBM's WebSphere and the third was integrated with Tivoli. From this one could guess that the common deployment scenario for DB2 would be in conjunction with another, or multiple, IBM products ”but this is of course just a guess. Because I just don't have enough raw data in this area, rather than waste time with supposition and theory on DB2 deployment scenarios, let's move on to examine DB2 on a less macro level; we can be fairly safe in assuming that regardless of how and where DB2 is deployed it's going to suffer from the same core weaknesses and benefit from the same strengths. What follows will help those responsible for the integration and deployment of DB2 understand the risks that might be involved in a given scenario, particularly with regards to server location and protection with the use of firewalls and so on.

DB2 on the Network

If you've ever looked at what is sent on the wire between the client and the server, you'd be forgiven for thinking that IBM was trying to do some pokey obfuscation of the data to keep it from prying sniffers, but it's not. Let's look at a packet:

IP Header Length and version: 0x45 Type of service: 0x00 Total length: 319 Identifier: 23647 Flags: 0x4000 TTL: 64 Protocol: 6 (TCP) Checksum: 0x5b58 Source IP: 192.168.0.1 Dest IP: 192.168.0.2 TCP Header Source port: 33976 Dest port: 50000 Sequence: 1644771043 ack: 3682916353 Header length: 0x80 Flags: 0x18 (ACK PSH ) Window Size: 2920 Checksum: 0xc124 Urgent Pointer: 0 Raw Data 00 26 d0 41 00 01 00 20 10 6d 00 06 11 a2 00 03 00 16 21 10 e3 d6 d6 d3 e2 c4 c2 40 40 40 40 40 40 40 40 40 40 40 00 38 d0 41 00 02 00 32 10 6e 00 06 11 a2 00 03 00 16 21 10 e3 d6 d6 d3 e2 c4 c2 40 40 40 40 40 40 40 40 40 40 40 00 0a 11 a1 98 a4 89 82 f1 85 00 08 11 a0 99 96 96 a3 00 ad d0 01 00 03 00 a7 20 01 00 06 21 0f 24 07 00 17 21 35 c3 f0 c1 f8 f0 f0 f4 c5 4b c2 f8 f8 f4 07 5f 53 20 49 58 00 16 21 10 e3 d6 d6 d3 e2 c4 c2 40 40 40 40 40 40 40 40 40 40 40 00 0c 11 2e e2 d8 d3 f0 f8 f0 f1 f6 00 0d 00 2f d8 e3 c4 e2 d8 d3 e7 f8 f6 00 16 00 35 00 06 11 9c 03 33 00 06 11 9d 04 b0 00 06 11 9e 03 33 00 3c 21 04 37 e2 d8 d3 f0 f8 f0 f1 f6 d3 89 95 a4 a7 40 40 40 40 40 40 40 40 40 40 40 40 40 84 82 f2 82 97 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 99 96 96 a3 40 40 40 40 00 00 05 21 3b f1

This is the authentication packet from a client sent to a server. In this packet we have, among other things, the username and password, so you begin to see what I mean about perhaps obfuscation being used; there doesn't seem to be a plaintext username or password present at all. The reason for this is that EBCDIC is being used and not ASCII. EBCDIC stands for Extended Binary Coded Decimal Interchange Code and is an IBM invention. You can find a good table of EBCDIC characters at http://www.dynamoo.com/technical/ebcdic.htm . Essentially to make any sense from this packet, and to extract the clear text username and password, you'll need to translate from EBCDIC to ASCII. Before doing this let's talk about the protocol itself. The most recent versions of DB2 use DRDA, or Distributed Relational Database Architecture, for its protocol. (Earlier versions used db2ra but we'll focus on DRDA). DRDA is supposed to be an open standard but its use hasn't really gained much traction. You can find an open source implementation of DRDA at http://opendrda. sourceforge .net/ . Note that this is still a work in progress. DRDA runs over a protocol like TCP/IP, and wrapped inside DRDA is one or more Data Stream Structures (DSS). Each DSS request contains a command and any command parameters. Distributed Data Management, or DDM, describes the syntax of these commands sent between the client and the server. Various commands are available but the first command sent when a new connection is set up is the EXCSAT DDM command or Exchange Server Attributes. This basically specifies what level of DRDA the client supports as to the server. Each command has a 2-byte numeric code. The preceding packet contains three DSS and three commands, ACCSEC, SECCHK, and ACCRDB. Let's break this packet down:

Key: S = Size, H = Header, Q = Correlation Identifier, D = Datatype, V = Value S: 00 26 H: d0 41 Q: 00 01 S: 00 20 C: 10 6d ; ACCSEC Command S: 00 06 D: 11 a2 V: 00 03 S: 00 16 D: 21 10 ; Relational Database Name V: e3 d6 d6 d3 e2 c4 c2 40 40 40 40 40 40 40 40 40 40 40 --------------------------------- S: 00 38 H: d0 41 Q: 00 02 S: 00 32 C: 10 6e ; SECCHK Command S: 00 06 D: 11 a2 ; Security Mechanism V: 00 03 S: 00 16 D: 21 10 ; Relational Database Name V: e3 d6 d6 d3 e2 c4 c2 40 40 40 40 40 40 40 40 40 40 40 S: 00 0a D: 11 a1 ; Password V: 98 a4 89 82 f1 85 S: 00 08 D: 11 a0 ; User ID V: 99 96 96 a3 ---------------------------------- S: 00 ad H: d0 01 Q: 00 03 ?: 00 a7 C: 20 01 ; ACCRDB Command S: 00 06 D: 21 0f ; RDB Access Manager Class V: 24 07 S: 00 17 D: 21 35 ; Correlation Token V: c3 f0 c1 f8 f0 f0 f4 c5 4b c2 f8 f8 f4 07 5f 53 20 49 58 S: 00 16 D: 21 10 ; Relational Database Name V: e3 d6 d6 d3 e2 c4 c2 40 40 40 40 40 40 40 40 40 40 40 S: 00 0c D: 11 2e ; Product-Specific Identifier V: e2 d8 d3 f0 f8 f0 f1 f6 S: 00 0d D: 00 2f ; Data Type Definition Name V: d8 e3 c4 e2 d8 d3 e7 f8 f6 S: 00 16 D: 00 35 ; TYPDEF Overrides V: 00 06 11 9c 03 33 00 06 11 9d 04 b0 00 06 11 9e 03 33 S: 00 3c D: 21 04 ; Product Specific Data V: 37 e2 d8 d3 f0 f8 f0 f1 f6 d3 89 95 a4 a7 40 40 40 40 40 40 40 40 40 40 40 40 40 84 82 f2 82 97 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 99 96 96 a3 40 40 40 40 00 S: 00 05 D: 21 3b V: f1

Header

Each DSS has a header with the DDMID, which is always 0xD0 and a byte that describes the format. The format describes whether the DSS is part of a chain or a single DSS and so on. Some common formats are as follows:

0x01: A single DSS request.

0x41: Chained/multiple DSS requests . Next DSS has a different correlation identifier. If an error occurs while processing a DSS, don't continue.

0x51: Chained/multiple DSS requests. Next DSS has the same correlation identifier. If an error occurs while processing a DSS, continue.

0x61: Chained/multiple DSS requests. Next DSS has a different correlation identifier. If an error occurs while processing a DSS, continue.

0x05: A single DSS but no reply is expected.

Commands

0x106D: ACCSEC: Access Security. Indicates that access to the database is required.

0x106E: SECCHK: Security Check. Indicates that client wishes to be authenticated.

0x2001: ACCRDB: Access Relational Database. Indicates the client wants access to the named database.

Datatypes

0x11A2: Security Mechanism. Describes the authentication method being used, in this case 3. 3 is userID and password. The DDM specification describes 15 different mechanisms. (See http://www.opengroup.org/ publications /catalog/c045.htm for more details.)

0x11A1: Password. The password of the user.

0x11A0: UserID. The username.

0x210F: RDB Access Manager Class. Indicates access to the database.

0x2135: Correlation Token. Used to keep track of communication.

0x2110: Relational Database Name. The name of the database, in this case TOOLSDB.

0x002F: Data Type Definition Name. Describes the datatype definition, in this case QTDSQLX86.

0x112E: Product-Specific Identifier. Describes the product release level of the DDM server/client, in this case SQL08016.

0x0035: TYPDEF Overrides. Describes character sets.

0x2104: Product-Specific Data. Describes information about the client/server.

Going back to EBCDIC, let's extract our username and password. There's no real mapping between ASCII and EBCDIC so it's almost like a simple substitution scenario. This simple program can be used to translate from EBCDIC to ASCII:

#include <stdio.h> unsigned char trans(unsigned char ch); unsigned char ebdic[]= "\x40\x4F\x40\x7B\x5b\x6c\x50\x7d\x4d\x5d\x5c\x4e\x6b\x60\x4b\x61" "\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\x7a\x5e\x4c\x7e\x6e\x6f" "\x7c\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xd1\xd2\xd3\xd4\xd5\xd6" "\xd7\xd8\xd9\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\x4A\xe0\x5a\x5f\x6d" "\x79\x81\x82\x83\x84\x85\x86\x87\x88\x89\x91\x92\x93\x94\x95\x96" "\x97\x98\x99\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xc0\x6a\xd0\x00"; int main() { int len = 0,cnt=0; unsigned char password[]="\x98\xa4\x89\x82\xf1\x85"; unsigned char username[]="\x99\x96\x96\xa3"; while(cnt < 6) { printf("%c",trans(password[cnt])); cnt ++; } cnt = 0; printf("\n"); while(cnt < 4) { printf("%c",trans(username[cnt])); cnt ++; } return 0; } unsigned char trans(unsigned char ch) { unsigned char cnt=0; while(cnt < 95) { if(ch == ebdic[cnt]) return cnt+0x20; cnt ++; } return 0x20; }

When run it shows the username to be "root" and the password to be "quib1e".