DB2 Deployment Scenarios

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".