Mailing List Archive

Hi Michel,

I dunno how this fits with your design, but how about a function to do
regular DNS lookups (i.e. through the nessus host's configured
resolver). That would enable the following:

1) a plugin that determines if the domain name resolves uniquely to the
ip address and sets a kb flag
2) plugins that have URLs in their output decide whether to use domain
name or ip address based on the kb flag

Also, I think someone mentioned some time of day function would be
helpful. Perhaps you have already addresses that.

Regards.

Paul



Michel Arboi wrote:

>Nessus 2.2 shall be released soon.
>Does anybody need new functions in libnasl or in the few remaining C
>plugins (mainly find_service.nes)?
>
>NASL functions can be implemented later in .inc files, but as most
>users do not upgrade their nessus core between major releases, it is
>better to implement C functions as soon as possible.
>
>
>

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul@westpoint.ltd.uk
web: www.westpoint.ltd.uk

On Tue, Sep 14, 2004 at 02:21:11PM +0100, Paul Johnston wrote:
> Also, I think someone mentioned some time of day function would be
> helpful. Perhaps you have already addresses that.

A strftime() equivalent might indeed be useful.


-- Renaud

So would a mktime() function. Converting timestamps located within
the HTTP headers would give an accurate read of the system time
of any system supporting HTTP.

Further, correlating to (if available) ICMP timestamps would possibly
indicate existence of different equipment on the same IP if the
delta of the timestamp to the auditing system's time varied.

Thomas

Renaud Deraison wrote:
> On Tue, Sep 14, 2004 at 02:21:11PM +0100, Paul Johnston wrote:
>
>>Also, I think someone mentioned some time of day function would be
>>helpful. Perhaps you have already addresses that.
>
>
> A strftime() equivalent might indeed be useful.
>
>
> -- Renaud
> _______________________________________________
> Nessus-devel mailing list
> Nessus-devel@list.nessus.org
> http://mail.nessus.org/mailman/listinfo/nessus-devel
>

On Tue Sep 14 2004 at 15:21, Paul Johnston wrote:

> Also, I think someone mentioned some time of day function would be
> helpful. Perhaps you have already addresses that.

We have unixtime & gettimeofday.
They give:
unixtime=1095197080 (integer)
gettimeofday=1095197080.840630 (string)

Hi,

>We have unixtime & gettimeofday.
>They give:
>unixtime=1095197080 (integer)
>gettimeofday=1095197080.840630 (string)
>
Ok... did you have any thoughts on the DNS function?

Paul

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul@westpoint.ltd.uk
web: www.westpoint.ltd.uk

On Tue Sep 14 2004 at 22:50, Thomas Reinke wrote:

> So would a mktime() function.

Shall we keep the month "number" between 0 & 11 (like the C function)
or between 1 & 12 (I prefer)?
Any reasonable defaults for the missing values?

On Tue Sep 14 2004 at 22:50, Thomas Reinke wrote:

> So would a mktime() function.

It could be written in NASL, no?

On Tue Sep 14 2004 at 22:50, Thomas Reinke wrote:

> So would a mktime() function. Converting timestamps located within
> the HTTP headers would give an accurate read of the system time
> of any system supporting HTTP.

Why should be convert them with mktime??

By the way, I wrote strftime yesterday but I just removed it:
- it might be dangerous
- there are too many portability issues. The behaviour could be
different on two Nessus servers. Not great.

I replaced it with localtime. Much more useful IMHO. We can write a
portable NASL strftime with information from localtime.

On Wed Sep 15 2004 at 12:28, Paul Johnston wrote:

> Ok... did you have any thoughts on the DNS function?

Sending data to an external server is not great (although we could do
it already if the target runs a SMTP, NNTP or DNS relay, or an HTTP
proxy)

I wrote same_host, which compares two addresses / host names. But it
is a "privileged" function for now.

Hi Michel,

That sounds ok... only one script actually needs to call it, so trusted
is fine. Just checking the semantics:

same_host(hostname, ipaddress)
returns true if the hostname resolves to the ipaddress (and resolves
uniquely)
returns false otherwise

Given that, I'd propose adding something like this (not tested) to
http_func.inc:

# Generate a URL suitible for display in the report
function build_url(port, path)
{
local url;

if(get_port_transport(port) == ENCAPS_IP)
url = 'http://';
else
url = 'https://';

# if kb key missing, default to using domainname
if(get_kb_item("dns/badhostname"))
url += get_host_ip();
else
url += get_host_name();

return url + ":" + port + path;
}

Web plugins can call this to generate proper URLs for display. This
would be good for us here as it would save time tidying up the reports.

Regards,

Paul




Michel Arboi wrote:

>On Wed Sep 15 2004 at 12:28, Paul Johnston wrote:
>
>
>
>>Ok... did you have any thoughts on the DNS function?
>>
>>
>
>Sending data to an external server is not great (although we could do
>it already if the target runs a SMTP, NNTP or DNS relay, or an HTTP
>proxy)
>
>I wrote same_host, which compares two addresses / host names. But it
>is a "privileged" function for now.
>
>
>
>

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul@westpoint.ltd.uk
web: www.westpoint.ltd.uk

On Thu Sep 16 2004 at 11:26, Paul Johnston wrote:

> same_host(hostname, ipaddress)
> returns true if the hostname resolves to the ipaddress (and resolves
> uniquely)
> returns false otherwise

No. For example :
same_host("207.46.245.156", "www.microsoft.com") = TRUE

> function build_url(port, path)

We already have http_requests functions. Maybe we should change their
behaviour if needed.

> if(get_kb_item("dns/badhostname"))

I don't understand: if the host name does not resolve, how are we
supposed to contact the machine??

Hi Michel,

The purpose of the build_url function is not to build a URL for an
attack, but to prepare it for display. Perhaps I should have called it
build_display_url or something. Currently the URLs output from plugins
tend to be fairly shoddy, e.g. http://server:443/path (should be https).
This costs us time fixing these up on reports. Having such a function
means plugins could be fairly easily updated to produce nice URLs.

The hostname issue is harder. Nessus treats scans against a (host name,
IP address) tuple. This is a good approach. For example, it allows a
proper scan that hits the correct virtual server, against a host that
has not yet had its DNS entry created. However, URLs can only contain
either a hostname or an IP address. It would be great if there was a URL
format that allowed a tuple, but I don't believe there is. So the best
we can do is "if hostname uniquely resolves to IP address, use hostname.
otherwise, use IP address". This means the URL always goes to the
correct IP address, and whereever possible it will hit the correct
virtual server.

That was the reason for my initial request. The same_host function you
have implemented does not help with this. Maybe you will consider adding
a different function. If not, I'll probably write a .nes plugin to do
this. It's on my agenda and ideally I'd like to share the work with the
community.

Regards,

Paul



Michel Arboi wrote:

>On Thu Sep 16 2004 at 11:26, Paul Johnston wrote:
>
>
>
>>same_host(hostname, ipaddress)
>>returns true if the hostname resolves to the ipaddress (and resolves
>>uniquely)
>>returns false otherwise
>>
>>
>
>No. For example :
>same_host("207.46.245.156", "www.microsoft.com") = TRUE
>
>
>
>>function build_url(port, path)
>>
>>
>
>We already have http_requests functions. Maybe we should change their
>behaviour if needed.
>
>
>
>> if(get_kb_item("dns/badhostname"))
>>
>>
>
>I don't understand: if the host name does not resolve, how are we
>supposed to contact the machine??
>
>
>
>

--
Paul Johnston
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul@westpoint.ltd.uk
web: www.westpoint.ltd.uk

Michel Arboi wrote:
> On Tue Sep 14 2004 at 22:50, Thomas Reinke wrote:
>
>
>>So would a mktime() function. Converting timestamps located within
>>the HTTP headers would give an accurate read of the system time
>>of any system supporting HTTP.
>
>
> Why should be convert them with mktime??

Short of re-inventing the wheel, how else would you convert
a readable date into a julian timestamp? It's not that
difficult to do through a .inc file, but if mktime is already
there to do it (unless there's a better alternative that
I'm not thinking of).

On Thu Sep 16 2004 at 20:26, Thomas Reinke wrote:

> Short of re-inventing the wheel, how else would you convert
> a readable date into a julian timestamp?

mktime does not parse a readable date: it converts a struct tm into a time_t

Michel Arboi wrote:
> On Thu Sep 16 2004 at 20:26, Thomas Reinke wrote:
>
>
>>Short of re-inventing the wheel, how else would you convert
>>a readable date into a julian timestamp?
>
>
> mktime does not parse a readable date: it converts a struct tm into a time_t
>

Ok...let's reset here.

You have a readable date which you know to be of a
particular format, e.g. consider the date returned
by Apache in all headers: "Thu, 16 Sep 2004 21:00:36 GMT".
You want to convert this to a julian time. The only
way I know of doing this reliably is to parse the field,
convert strings such as "Sep" to the appropriate integer
value, and then call mktime with the appropriately
populated time structure.

Is there another, reliable, secure way of doing the above
that I'm not aware of?

As I repeated earlier, if you can then do this, one can
do things such as compare this against the local system
time, which if you know is accurate, will tell you
whether or not the remote system is time synced. If you
then compare against returned results from icmp timestamp
messages, you can compare the accuracy of the remote
clock. If the accuracies vary, you know you are talking
to two different devices.

Not to mention simply the fact that good sysadmins should
keep their clocks synced to make it easier to troubleshoot
problems across a network.

Thomas

On Thu Sep 16 2004 at 23:05, Thomas Reinke wrote:

> by Apache in all headers: "Thu, 16 Sep 2004 21:00:36 GMT".
> You want to convert this to a julian time. The only
> way I know of doing this reliably is to parse the field,
> convert strings such as "Sep" to the appropriate integer
> value, and then call mktime with the appropriately
> populated time structure.

> Is there another, reliable, secure way of doing the above
> that I'm not aware of?

Probably not, but the most difficult part is the parser, if we want
it to handle several languages. I suggest that we keep this part in
NASL because we'll probably need to add another language.
Writing mktime in NASL is easy if we stick to UTC. Handling time zones
is harder.
OK, let's implement mktime in C -- and hope that all time zones will be
implemented on all systems so that we have the same behaviour every where.

> As I repeated earlier, if you can then do this, one can
> do things such as compare this against the local system
> time, which if you know is accurate, will tell you
> whether or not the remote system is time synced. If you
> then compare against returned results from icmp timestamp
> messages, you can compare the accuracy of the remote
> clock. If the accuracies vary, you know you are talking
> to two different devices.

Yes, this is an interesting idea.

> Not to mention simply the fact that good sysadmins should
> keep their clocks synced to make it easier to troubleshoot
> problems across a network.

Unfortunately, we cannot be sure that Nessusd's clock is accurate.
If it is not, you'll get a warning on every target.

For example, when I run an audit, my laptop is often the only
unsynchronized clock on the network!

--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
NASL2 reference manual http://michel.arboi.free.fr/nasl2ref/

Michel Arboi wrote:
> On Thu Sep 16 2004 at 23:05, Thomas Reinke wrote:
>
>
> Probably not, but the most difficult part is the parser, if we want
> it to handle several languages. I suggest that we keep this part in
> NASL because we'll probably need to add another language.

Sensible. FWIW, having just sifted through a list of over 1.5 million
"Dates" returned from distinct IP addresses in HTTP headers requests,
only 308 of them had the format laid out differently from the one
shown below:

"Thu, 16 Sep 2004 21:00:36 GMT"

Of those 308, 72 of them played around with different formats for GMT
such as -0300, GMT+0200. A bunch more left out the comma after the
weekday.

Bottom line is that the dates in HTTP headers don't seem to be
internationalized on web servers (either that, or there are
very few internationalized servers). So, if one was to rigourously
stick with the format used by Apache, you'd catch 99.98% of the
cases. The remaining, well, I'd say you just wouldn't report a
parseable date/time, that's all.


> Writing mktime in NASL is easy if we stick to UTC. Handling time zones
> is harder.

Agreed.

> OK, let's implement mktime in C -- and hope that all time zones will be
> implemented on all systems so that we have the same behaviour every where.

Great!

Thomas