Guardeonic Solutions AG (

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

Vendor Communication:	08/29/02 Initial Notification via email to, 
			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


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


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.

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 ( the URL

is requested by Mozilla (Webbrowser). 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 > S
266670866:266670866(0) win 5840 <mss 1460,sackOK,timestamp 1232639
0,nop,wscale 0> (DF)
17:25:13.671663 > S
279647520:279647520(0) ack 266670867 win 5792 <mss 1460,sackOK,timestamp
11683562 1232639,nop,wscale 0> (DF)
17:25:13.674917 > . ack 1 win 5840
<nop,nop,timestamp 1232639 11683562> (DF)
17:25:13.678327 > P 1:23(22) ack 1
win 5792 <nop,nop,timestamp 11683563 1232639> (DF)
17:25:13.680997 > . ack 23 win 5840
<nop,nop,timestamp 1232640 11683563> (DF)
17:25:13.684046 > P 1:961(960) ack
23 win 5840 <nop,nop,timestamp 1232640 11683563> (DF)
17:25:13.686428 > . ack 961 win 8640
<nop,nop,timestamp 11683564 1232640> (DF)
17:25:13.688520 > P 23:42(19) ack
961 win 8640 <nop,nop,timestamp 11683564 1232640> (DF)
17:25:13.690469 > 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

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

Tcpdump reports three connection attempts:
17:38:59.965559 > S
1127433463:1127433463(0) win 5840 <mss 1460,sackOK,timestamp 1314829
0,nop,wscale 0> (DF)
17:38:59.965654 > R 0:0(0) ack
1127433464 win 0 (DF)
17:39:00.991971 > S
1127433466:1127433466(0) win 5840 <mss 1460,sackOK,timestamp 1314930
0,nop,wscale 0> (DF)
17:39:00.992066 > R 0:0(0) ack
1127433467 win 0 (DF)
17:39:02.012012 > S
1127433469:1127433469(0) win 5840 <mss 1460,sackOK,timestamp 1315031
0,nop,wscale 0> (DF)
17:39:02.012107 > 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.


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


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

(more to come...)