Nmap Development mailing list archives
Re: [NSE] accton.nse: OSVDB 67963, Accton products Super User Password Generation Algorithm Weakness
From: Gutek <ange.gutek () gmail com>
Date: Fri, 01 Oct 2010 20:18:28 +0200
-----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/
Current thread:
- Re: [NSE] accton.nse: OSVDB 67963, Accton products Super User Password Generation Algorithm Weakness Gutek (Oct 01)