Onderwerp: Cross-site scripting vulnerability in SARA v<=4.2.7

XSS Vulnerability in Security Auditor's Research Assistant (SARA) versions
before 5.0.0

Affects:
SARA versions 4.2.6 and 4.2.7. Older versions not tested, presumably affected.

Related software (sharing common ancestry):
SATAN 1.1.1 would not run properly on my test platform, but checking the code
it did not look like it was affected.

SAINT does not appear to be affected. Because of licensing constraints,
I was only able to test a rather old verion (3.1.2), but Saint Corporation
was contacted and indicated version 5.1.2 is not affected, and state that
earlier versions should also be unaffected.


Description:
SARA, a descendent of SATAN, is a tool for probing networks for vulnerabilities
(ideally to fix them). It creates its own mini-http server to enable the
user to interact with the main process through a standard web browser. If
scanning in interactive mode, information about target hosts and services
running on them is displayed, and in some cases this includes banners from
the service. In SARA version 4.2.7 and before, the service banners were not
properly sanitized, allowing HTML content in the banner to be processed by
the administrative web browser.

This allows standard cross site scripting issues, which might be seriously
exascerbated by the facts that:
i) the normal mode of operation is for the web browser to be started
by sara, and as sara must be run as root for scanning operations, the web
browser is typically a root owned process.
ii) The simplified http server automatically assigns the values of html
form variables to global variables in the Perl script with the same name.

Solution:
Advanced Research Corporation was contacted about the issue 20 Nov, and has
included code in version 5.0.0 of the package to deal with the problem.
Upgrading is recommended (see http://www-arc.com/sara/ for download
information.)

I would also recommend against performing scans in interactive mode in any
these packages. Instead, I recommend that scans be run from the command line
(or a script), thereby avoiding the invocation of the interactive http
interface as root. Data analysis does not require root privileges, and it
would be safer to only use the interactive interface with less privileged
accounts (though access to the results files still required).


Tom Payerle
Dept of Physics payerle@physics.umd.edu
University of Maryland (301) 405-6973
College Park, MD 20742-4111 Fax: (301) 314-9525

In-Reply-To: <Pine.OSF.4.44.0312171328080.17165-100000@oppie.physics.umd.edu>

Hi there,

Bob Todd from Advanced Research Corporation, the developer of SARA. I have been talking to Tom and I am somewhat surprised by his email. Let me
explain:

1. CSS: Tom indicates that SATAN and older versions of SAINT are not
vulnerable to CSS. Tom is incorrect as all used the SATAN engine
which did not tranlate "<" and ">" to their html codes "&lt;" and
"&gt; I suspect that SAINT has fixed it, SARA has, but SATAN has
not.

2. SARA Web Server: Tom implies that the SARA server is not secure. The
SARA server is based on the SATAN engine with additional IP protection.
We have received no complaints of this interface in nearly 5 years of
service.

3. Tom suggests against using the intractive interface to SARA. We
believe that this is unfounded as there has been no basis in over five
years of use. We have always professed that the SARA computer be
secured so as operations and data could not be compromised.

In summary, I wish that Tom had done more research on SATAN and SAINT and had not indicted only SARA. SARA is the only open source SATAN derivitive.
It can be better, but erroreous charges against it are not beneficial.
Maybe Tom should join our list server and contribute rather than complain!

Bob Todd
Advanced Research Corporation
www-arc.com
www.jule-iii.com
---------------------------------------------------------------------



>XSS Vulnerability in Security Auditor's Research Assistant (SARA) versions
>before 5.0.0
>
>Affects:
>SARA versions 4.2.6 and 4.2.7. Older versions not tested, presumably affected.
>
>Related software (sharing common ancestry):
>SATAN 1.1.1 would not run properly on my test platform, but checking the code
>it did not look like it was affected.
>
>SAINT does not appear to be affected. Because of licensing constraints,
>I was only able to test a rather old verion (3.1.2), but Saint Corporation
>was contacted and indicated version 5.1.2 is not affected, and state that
>earlier versions should also be unaffected.
>
>
>Description:
>SARA, a descendent of SATAN, is a tool for probing networks for vulnerabilities
>(ideally to fix them). It creates its own mini-http server to enable the
>user to interact with the main process through a standard web browser. If
>scanning in interactive mode, information about target hosts and services
>running on them is displayed, and in some cases this includes banners from
>the service. In SARA version 4.2.7 and before, the service banners were not
>properly sanitized, allowing HTML content in the banner to be processed by
>the administrative web browser.
>
>This allows standard cross site scripting issues, which might be seriously
>exascerbated by the facts that:
> i) the normal mode of operation is for the web browser to be started
>by sara, and as sara must be run as root for scanning operations, the web
>browser is typically a root owned process.
> ii) The simplified http server automatically assigns the values of html
>form variables to global variables in the Perl script with the same name.
>
>Solution:
>Advanced Research Corporation was contacted about the issue 20 Nov, and has
>included code in version 5.0.0 of the package to deal with the problem.
>Upgrading is recommended (see http://www-arc.com/sara/ for download
>information.)
>
>I would also recommend against performing scans in interactive mode in any
>these packages. Instead, I recommend that scans be run from the command line
>(or a script), thereby avoiding the invocation of the interactive http
>interface as root. Data analysis does not require root privileges, and it
>would be safer to only use the interactive interface with less privileged
>accounts (though access to the results files still required).
>
>
>Tom Payerle
>Dept of Physics payerle@physics.umd.edu
>University of Maryland (301) 405-6973
>College Park, MD 20742-4111 Fax: (301) 314-9525
>
>