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 01/11/2010 22:06, David Fifield a écrit :
> On Fri, Oct 01, 2010 at 08:18:28PM +0200, Gutek wrote:
> > 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.
> >
> > 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).
>
> I don't see it that way. This script does a local calculation based on
> the MAC address and prints out the result. What it says is, "If this is
> an Accton product with the backdoor, then this is what the password will
> be." If I'm an admin scanning my network for the vulnerability, all I'm
> going to see is a bunch of
>
> Host script results:
> |_accton: Computed credentials for AA:AA:AA:AA:AA:AA:>> __super:T!!R!cNI
> Host script results:
> |_accton: Computed credentials for BB:BB:BB:BB:BB:BB:>> __super:!stvnL78
> Host script results:
> |_accton: Computed credentials for CC:CC:CC:CC:CC:CC:>> __super:GXBhkVgQ
> Host script results:
> |_accton: Computed credentials for DD:DD:DD:DD:DD:DD:>> __super:eL2!It!A
>
> One for every target with a MAC address, no matter what find of target
> it is. I just don't think that's useful. The admin is still going to
> have to write a script to actually test those credentials on each host
> to see if he's vulnerable. It would be more useful if the NSE tested the
> credentials itself. In very verbose mode it could print the credentials
> even if they can't be verified.  That may result in some false
> negatives, but that's in trade for the nearly 100% false positives the
> script has now.
>
> I know this isn't a bug or design flow on your part; you made this to be
> a non-invasive offline local calculation, basically a reimplementation
> of the Accton hash algorithm. I just think it would be more useful if it
> worked differently.
>
> David Fifield
Wise works, as usual ! I agree, and I'll build a vuln testing function
so as to avoid false positives and to focus on real exposed targets.

Thanks,

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

iEYEARECAAYFAkzRkwYACgkQ3aDTTO0ha7hKsQCeMuL8pLgywaO2kClSh56yqAZY
ZyoAn0R1Nzu7BzRQqyEo+U/65c3ge0Aw
=iog5
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/