Vendor Response follows...
------------------------------------------------------------------
- EXPL-A-2003-025 exploitlabs.com Advisory 025
------------------------------------------------------------------
-= Visualroute Server =-

Donnie Werner
Oct 1, 2003

Vunerability(s):
----------------
1. reverse tracerouting

fingerprinting / discovery vunerability
allowing intranet ( LAN ) mapping by way
of Visualroute servers being
accessed from the internet ( WAN )

Product:
--------
http://www.visualware.com/personal/demo/index.html

Reviews:
-------- http://www.visualware.com/company/pressroom/coverage.html

Description of product:
-----------------------
VisualRoute Server adds Web server functionality so that multiple users
can easily access the server via a Web browser, regardless of their
location.
Traces originate from the VisualRoute Server system
and may be run back to the end-user location or to
any other IP address or Web server.

VUNERABILITY / EXPLOIT
======================
the core issue here is that by specififying an internal ip
such as 192.168.0.*, 10.*.*.*, or 172.18.18.*
or any other reserved ( private ) address you are
able to map the internal lan structure via an external
( WAN ) address from the internet.

standard trace route example:
------------------------------

standard traceroute server request

requesting a trace to from exploitlabs.com
to a Visualroute Server we may see..

output..

12.230.0.205 ( exploitlabs.com )
12.244.x.5 - isp router
24.x.200.x - target isp router
24.x.240.2 - target

destination reached in bla seconds - complete
packet loss 0%

now on a Visualroute Server the originating
trace begins at the target server, traces through
routers to dest.

so for example asking a server running Visualroute Server
the same request we get

24.x.240.2 - target ip
24.x.200.x - target isp router
12.244.x.5 - isp router
12.230.0.205 ( exploitlabs.com )

let us now assume the same target/Visualroute Server
is behind a router/switch with port forwarding to the Visualroute
Server daemon

192.168.0.2 - target originating system
192.168.0.1 - target router / switch
24.x.200.x - target ip
24.x.240.2 - target isp router
12.244.x.5 - isp router
12.230.0.205 ( exploitlabs.com )

now we can discover the lan topology
the traceroure was initiated from,
as the origin of the trace is internal
to the originating Visualroute Server

Local:
------
possibly

Remote:
-------
yes

Vendor Fix:
-----------
No fix on 0day

Vendor Contact:
---------------
Concurrent with this advisory
sales (at) visualware (dot) com [email concealed]
see below in this post

Credits:
--------
Donnie Werner
CTO E2 Labs
morning_wood (at) e2-labs (dot) com [email concealed]
http://www.e2-labs.com
http://nothackers.org - home of the 0day Security List

VENDOR RESPONSE
------------------------

> ----- Original Message -----
> From: "Julie Lancaster" <julie.lancaster (at) visualware (dot) com [email concealed]>
> To: "'morning_wood'" <se_cur_ity (at) hotmail (dot) com [email concealed]>
> Sent: Wednesday, October 01, 2003 8:42 PM
> Subject: RE: Visualroute Server - reverse tracerouting
>
>
> Hello,
>
> VisualRoute Server has a security option to prevent traces to secure IP
> addresses:
>
> Preventing traces to Secure IP Addresses: To prevent a VisualRoute trace
> to a particular IP address (or range of IP addresses), edit the
> .\data\user\secure.txt text file (a file you must create). Each line in
> this file is "cidr-address,x". For example, here is an example
> secure.txt file that secures two IP ranges:
>
> 198.242.57/24,x
> 201.109/16,x
>
> If there is an attempt to trace directly to any secure IP in this list,
> it will be treated like a DNS error (does not exist). If the IP address
> shows up in a trace, it will be replaced by the 'x' in the line
> definition.
>
> Regards,
> Julie Lancaster
>
> Visualware Inc. - Internet Security and Performance Tools
> www.visualware.com
>

> -----Original Message-----
> From: morning_wood [mailto:se_cur_ity (at) hotmail (dot) com [email concealed]]
> Sent: Wednesday, October 01, 2003 12:47 PM
> To: julie.lancaster (at) visualware (dot) com [email concealed]
> Subject: Re: Visualroute Server - reverse tracerouting
>
>
> Julie, thank you very much for the info
> and the timely response, did i miss it in the readme ?
>
> Donnie Werner
> CTO e2 labs
> http://e2-labs.com/about.htm
>
> ----- Original Message -----
> From: "Julie Lancaster" <julie.lancaster (at) visualware (dot) com [email concealed]>
> To: "'morning_wood'" <se_cur_ity (at) hotmail (dot) com [email concealed]>
> Sent: Wednesday, October 01, 2003 10:25 PM
> Subject: RE: Visualroute Server - reverse tracerouting
>
>
> Hello,
>
> The information is in the on-line manual, not the readme. You may find
> it right above the Host/Port section at this link,
> http://www.visualware.com/manuals/visualroute/manual.html#hostport.
>
> We provide the security option, but it is the responsibility of the
> administrator to set the security for their requirements.
>
> Regards,
> Julie Lancaster
>
> Visualware Inc. - Internet Security and Performance Tools
> www.visualware.com
>

----- Original Message -----
From: "morning_wood" <se_cur_ity (at) hotmail (dot) com [email concealed]>
To: <julie.lancaster (at) visualware (dot) com [email concealed]>
Sent: Wednesday, October 01, 2003 11:02 PM
Subject: Re: Visualroute Server - reverse tracerouting

> my apology, but this...
>
> -------------- snip ----------------
> Preventing traces to Secure IP Addresses: To prevent a VisualRoute trace
to
> a particular IP address (or range of IP addresses), edit the
> .\data\user\secure.txt text file (a file you must create). Each line in
this
> file is "cidr-address,x". For example, here is an example secure.txt file
> that secures two IP ranges
> ------------- snip ------------------
>
> should possibly suggest LAN ip address ranges as the info
> provided is quite cluless as to even a seasoned admin
> i can bet in 99% of users they are just as cluless as the description
> itself is. i point out that even your list of servers at
> http://www.visualware.com/personal/demo/index.html
> *most* are vunerable to this exact attack.
>
> Donnie Werner
> CTO e2-labs.com

[ reply ]