Mailing List Archive: Nessus & thttpd

There is a couple of attacks against WWW proxies & servers that need a
hostile web server.
I thought that we might implement them. But we need a web server.

Solutions :
1. the administrator sets up a web server and the hostile URL must be
entered as "Prefs". The plugin checks at startup and before run that
the URL is correct.

2. Implement a web server into Nessusd. The server is run when the
plugin starts and is shut down at the end.
Option : starts it when nessusd is first run. The port of the server
could be put into the KB.

3. Launch a simple web server like thttpd when the script starts, and
kill it at the end.
Option : starts it when nessusd is first run...

(1) is ugly: Nessus would depend upon something else.
(2) is complicated but clean. (3) is simpler.

Problem with (2) and (3) : The Nessus server should not be hacked
through the web server. "thttpd -r" (chroot) should be secure enough.

Michel Arboi wrote:
> There is a couple of attacks against WWW proxies & servers that need a
> hostile web server.
> I thought that we might implement them. But we need a web server.
>
> Solutions :
> 1. the administrator sets up a web server and the hostile URL must be
> entered as "Prefs". The plugin checks at startup and before run that
> the URL is correct.
>
> 2. Implement a web server into Nessusd. The server is run when the
> plugin starts and is shut down at the end.
> Option : starts it when nessusd is first run. The port of the server
> could be put into the KB.
>
> 3. Launch a simple web server like thttpd when the script starts, and
> kill it at the end.
> Option : starts it when nessusd is first run...
>
> (1) is ugly: Nessus would depend upon something else.
> (2) is complicated but clean. (3) is simpler.
>
> Problem with (2) and (3) : The Nessus server should not be hacked
> through the web server. "thttpd -r" (chroot) should be secure enough.
>

For a number of reasons, I really don't
think Nessus should mandate the starting of another server.
Optional, maybe - mandated - no. I'd rather see a "directory"
on an existing server be pointed at in a pref section, and if it
doesn't exist, then those few tests can't be run.

The directory preference approach has a LOT of things going
for it:

a) It avoids opening up a potential security issue, as you mention.
b) It allows for Nessus to be behind a firewall and testing
non-firewalled hosts (not recommended, but I'll bet its being
done).
c) It allows for Nessus to be running on a system where a webserver
is already running (ugh, but again, bet its being done).

If you _must_ have a thttpd -r option, then provide a couple of prefs,
such as
Pref #1: Start up internal web server? [y/n] y
Pref #2: Base URL on external web server? [] http://yourserver/base/

I suspect you'll want a base directory specified only, since the
type of attacks your talking about will often have a variety of URLs
involved, often times mandated by the vulnerable package being tested.

I'd also take a careful look at whether or not one _really_ needs
the external server. I've been surprised at least once by seeing
Renaud put a test together for something that I thought would need
an external server to accomplish, by doing something as simple as
specifying an invalid http reference and catching the error that
comes back.

Thomas

Thomas