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