Mailing List Archive

Default passwords test
I was wondering if somebody was improving the default passwords test
plugins. Currently Nessus has a SNMP plugin test (which does not include
some common SNMP communities or undocumented ones, such as cable-docsis)
[1] and an 'accounts' plugin which includes a limited text file with
username/passwords [2] for telnet connections. The 'accounts' plugin can
use a user-provided file, whileas the SNMP tests cannot.

I was wondering if it would be worth improving the current code base
with some common passwords lists [0] (I carry these around in my PDA
just in case :) Also, I am not aware for a plugin for common
username/passwords for HTTP authentication, si there any? Since some
tools/appliances are starting to use HTTP/HTTPS frontends it might
probable be worth having one.

If nobody disagrees I will (try to) send patches for both plugins: 10328
and 10264. Since the Bug Tracker (http://www.nessus.com/bugs/nessus)
seems to not be available yet I will probably send the patches to the
list (and hopefully somebody with write access to the CVS will commit
them :)

Regards

Javi



[0] Some passwords lists are available at:
http://www.phenoelit.de/dpl/dpl.html
http://www.cirt.net/cgi-bin/passwd.pl
http://security.nerdnet.com/rawdump.php is no longer available(was quite
popular)
[1]
http://cvs.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-plugins/scripts/snmp_default_communities.nasl
[2]
http://cvs.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-plugins/plugins/accounts/accounts.txt
Re: Default passwords test [ In reply to ]
On Mon, Sep 16, 2002 at 01:01:24PM +0200, Javier Fernández-Sanguino Peña wrote:
> I was wondering if somebody was improving the default passwords test
> plugins. Currently Nessus has a SNMP plugin test (which does not include
> some common SNMP communities or undocumented ones, such as cable-docsis)
> [1] and an 'accounts' plugin which includes a limited text file with
> username/passwords [2] for telnet connections. The 'accounts' plugin can
> use a user-provided file, whileas the SNMP tests cannot.

Hydra.nes does that. It can do cisco ftp, http, icq, imap, nntp,
pcnfs, pop3, rexec, smb, socks5 and telnet password bruteforcing using a
list of usernames and passes.
Re: Default passwords test [ In reply to ]
Renaud Deraison wrote:

>On Mon, Sep 16, 2002 at 01:01:24PM +0200, Javier Fernández-Sanguino Peña wrote:
>
>>I was wondering if somebody was improving the default passwords test
>>plugins. Currently Nessus has a SNMP plugin test (which does not include
>>some common SNMP communities or undocumented ones, such as cable-docsis)
>>[1] and an 'accounts' plugin which includes a limited text file with
>>username/passwords [2] for telnet connections. The 'accounts' plugin can
>>use a user-provided file, whileas the SNMP tests cannot.
>>
>
>Hydra.nes does that. It can do cisco ftp, http, icq, imap, nntp,
>pcnfs, pop3, rexec, smb, socks5 and telnet password bruteforcing using a
>list of usernames and passes.
>
Quite nice. Doesn't it, however, lack Nessus feature to be able to
analyse a service which is not on a standard port?
In any case, one of the improvements I was thinking of, though, would be
the use of such default passwords to determine which equipment is being
assessed. For example, 'ilmi' community most probably belongs to a CISCO
router. What information could such a plugin place in the Knowledge
database (if any) for OS/device identification?

Regards

Javi
Re: Default passwords test [ In reply to ]
On Mon, Sep 16, 2002 at 03:10:39PM +0200, Javier Fernández-Sanguino Peña wrote:
> >Hydra.nes does that. It can do cisco ftp, http, icq, imap, nntp,
> >pcnfs, pop3, rexec, smb, socks5 and telnet password bruteforcing using a
> >list of usernames and passes.
> >
> Quite nice. Doesn't it, however, lack Nessus feature to be able to
> analyse a service which is not on a standard port?

No, it uses Nessus's port recognition.

> In any case, one of the improvements I was thinking of, though, would be
> the use of such default passwords to determine which equipment is being
> assessed. For example, 'ilmi' community most probably belongs to a CISCO
> router. What information could such a plugin place in the Knowledge
> database (if any) for OS/device identification?

You have the remote host OS stored as Host/OS, although I really don't
like to use OS recognition for a check (I've seen many hosts with port
forwarding & stuff).

-- Renaud