Re: [NSE] accton.nse: OSVDB 67963, Accton products Super User Password Generation Algorithm Weakness

[Gutek <ange.gutek () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 29/09/2010 07:53, David Fifield a écrit :
> On Sun, Sep 19, 2010 at 01:24:01PM +0200, Gutek wrote:
> > This script aims a one-year unpatched vulnerability hidded in many
> > Accton-embedded products, as described by Edwin Eefting, Erik Smit and
> > Erwin Drent @HAR2009.
> >
> > Many switches manufacturers embed Accton products (3Com, Dell, SMC,
> > Foundry, EdgeCore and maybe others).
> > In august 2009 at the HAR2009 Edwin Eefting, Erik Smit and Erwin Drent
> > revealed that Accton
> > has left a management backdoor behind (telnet, SSH and HTTP).
> > Researchers have released a paper explaining their work:
> > http://www.vettebak.nl/hak/accton.pdf
> >
> > While __super is the login, the password can be guessed (computed) from
> > the switches' MAC address.
> > This is what this script does. Be advised that it does not check if the
> > target is an Accton embedded
> > product, neither if the target is actually a vulnerable one: it's
> > non-intrusive.
>
> I think this script would be much more useful if it could detect the
> backdoor. Is there some pattern of open ports, some unique SSH
> signature?
>
> > It would be nicer if the script could retrieve the target's MAC address
> > by itself but I didn't find such a function in the NSE libraries.
> > Please also note that I did not actually test this script against real
> > vulnerable targets: I don't have any at hand. Hence, this script was
> > tested against known vulnerable MAC addresses and its results were
> > compared with the publishers' ones.
>
> To get a MAC address use host.mac_addr. That only works if Nmap knows it
> of course.
>
> http://nmap.org/book/nse-api.html#nse-api-arguments
>
> David Fifield
Well, there are no detection rule because I wanted this script to be as
flexible as possible so that it could be run against any "possibly
accton-embedded product" (as of today, a definitive list of vendor using
accton products is not clear) in any network conditions: for example, if
the script would be based on a port pattern I'm afraid that a filtering
rule in front of the target could fool it. And same fear with other
detection technics I was thinking of (vendors matching mac prefixes, for
example).
My point of vue is that this script is launched by an admin who could
have heard about this vulnerability and, suspicious about the fact that
he may have accton-based switches in his pool, explicitely uses this
script against a (or some suspected) specific target(s).
Imho, adding a detection mechanism would be the opposite: this script
would have been built not for an admin (aware of the products he is in
charge of) but clearly for an attacker (ie _not_ aware of the products,
looking for potential targets with at first the need to distinguish the
'good' candidates).

Of course that's not a "i don't want to", but just my point of vue: I'm
serving the crowd :)

Here is an update. Now, the script works on the target's MAC by default
if (nmap)provided, or against any (user)given MAC as an argument.

'to protect and to serve',
A.G.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkymJfQACgkQ3aDTTO0ha7jZUACeOJ9qOgpp0Og9aZdPBmYx6+Eq
mMQAn1w6gCZO3pECnJpuBwjGit0jAfDn
=VP/Y
-----END PGP SIGNATURE-----

Attachment: accton.nse
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/