Guardeonic Solutions AG (www.guardeonic.com)

Security Advisory #02-2002

Advisory Name:        DB4Web (R) TCP Connects to Arbitrary IP and Port
Release Date:         09/17/02
Affected Product:     DB4Web (R) Application Server
Platform:             Linux for sure, *nix and MS Windows unknown
Version:              Unknown

Severity:             A DB4Web component sends TCP SYN packets to 
                      arbitrary IP and Port determined by the client

Author:               Stefan Bagdohn <stefan.bagdohn@guardeonic.com>
                                     <buggy@segmentationfault.de> 

Vendor Communication: 08/29/02 Initial Notification via email to 
                               support@db4web.de, 
                               cc: Juergen.Kettlitz@siemens.com
                      08/30/02 Got vendor receipt via phone
                      09/02/02 Phone call by vendor regarding details
                      09/09/02 Second email to vendor asking for patch
                               status information
                      09/16/02 Phone call and email from vendor,
                               No classification as security flaw

Overview:

(From vendors website): "DB4Web, Your Application Server for high performance
and secure Web-Applications with access to various data sources"
...
"DB4Web (R) is a high-performance application server that makes available a
multitude of data sources on the Web. This means that you can simultaneously
read from and write to relational databases and a multitude of other
information sources and applications through Intranet or the Internet."
(end of vendor citation)

The DB4Web (R) application can be misused to send TCP SYN packets
(initiate TCP connections) to arbitrary IP Adresses and TCP Ports by
sending special http requests.

Decription:

A DB4Web (R) server accessed with a webbrowser usually requests local or remote
databases to generate dynamic html pages. By requesting malicious URLs one can
manipulate the server to query an arbitrary IP with a freely definable port.
The application will send TCP SYN packets to establish a connection.
The error messages of successful and unsuccessful tcp connections are
different. Thus it is possible to portscan/fingerprint IPs accessible
for the DB4Web (R) server.
 
Example:

The scenario was tested with a system running SuSE Linux 7.3 which 
includes a trial version of DB4Web (R) and a linux system 
running tcpdump.

On the DB4Web (R) server (172.31.93.158) the URL

http://127.0.0.1/DB4Web/172.31.93.30:22/foo

is requested by Mozilla (Webbrowser). 172.31.93.30 is the IP of
the system running tcpdump with port 22 open (sshd).
Tcpdump reports the 3-way handshake and the reset due to wrong
protocol used by the server (the listener runs sshd on port 22).

Tcpdump's output looks:
17:25:13.671550 172.31.93.158.1449 > 172.31.93.30.22: S
266670866:266670866(0) win 5840 <mss 1460,sackOK,timestamp 1232639
0,nop,wscale 0> (DF)
17:25:13.671663 172.31.93.30.22 > 172.31.93.158.1449: S
279647520:279647520(0) ack 266670867 win 5792 <mss 1460,sackOK,timestamp
11683562 1232639,nop,wscale 0> (DF)
17:25:13.674917 172.31.93.158.1449 > 172.31.93.30.22: . ack 1 win 5840
<nop,nop,timestamp 1232639 11683562> (DF)
17:25:13.678327 172.31.93.30.22 > 172.31.93.158.1449: P 1:23(22) ack 1
win 5792 <nop,nop,timestamp 11683563 1232639> (DF)
17:25:13.680997 172.31.93.158.1449 > 172.31.93.30.22: . ack 23 win 5840
<nop,nop,timestamp 1232640 11683563> (DF)
17:25:13.684046 172.31.93.158.1449 > 172.31.93.30.22: P 1:961(960) ack
23 win 5840 <nop,nop,timestamp 1232640 11683563> (DF)
17:25:13.686428 172.31.93.30.22 > 172.31.93.158.1449: . ack 961 win 8640
<nop,nop,timestamp 11683564 1232640> (DF)
17:25:13.688520 172.31.93.30.22 > 172.31.93.158.1449: P 23:42(19) ack
961 win 8640 <nop,nop,timestamp 11683564 1232640> (DF)
17:25:13.690469 172.31.93.30.22 > 172.31.93.158.1449: R 42:42(0) ack 961
win 8640 <nop,nop,timestamp 11683564 1232640> (DF)

The browser shows a lot of debug stuff reported by DB4Web (R), 
especially the line:
connect() ok
And a few lines later:
callmethodbinary_2 failed

An URL like

http://127.0.0.1/DB4Web/172.31.93.30:555/foo

requests TCP port 555 which is closed on the listening system.

Tcpdump reports three connection attempts:
17:38:59.965559 172.31.93.158.1451 > 172.31.93.30.555: S
1127433463:1127433463(0) win 5840 <mss 1460,sackOK,timestamp 1314829
0,nop,wscale 0> (DF)
17:38:59.965654 172.31.93.30.555 > 172.31.93.158.1451: R 0:0(0) ack
1127433464 win 0 (DF)
17:39:00.991971 172.31.93.158.1452 > 172.31.93.30.555: S
1127433466:1127433466(0) win 5840 <mss 1460,sackOK,timestamp 1314930
0,nop,wscale 0> (DF)
17:39:00.992066 172.31.93.30.555 > 172.31.93.158.1452: R 0:0(0) ack
1127433467 win 0 (DF)
17:39:02.012012 172.31.93.158.1453 > 172.31.93.30.555: S
1127433469:1127433469(0) win 5840 <mss 1460,sackOK,timestamp 1315031
0,nop,wscale 0> (DF)
17:39:02.012107 172.31.93.30.555 > 172.31.93.158.1453: R 0:0(0) ack
1127433470 win 0 (DF)

The debug message is different now and contains:
connect() failed: Connection refused

Vendor Response:

The DB4Web teams does not classify this behavior as a security
related bug. They define the verbose debug messages as a 
feature useful for developers. The DB4Web teams states, that it
is the customers responsibility to substitute the debug page
with a custom error page.

Solution:

Replace the debug page with a non-verbose error page.

Credit:

Thanks to the DB4Web team for good cooperation and fast response!

(more to come...)
EOF