Nmap Development mailing list archives
Re: [NSE] accton.nse: OSVDB 67963, Accton products Super User Password Generation Algorithm Weakness
From: David Fifield <david () bamsoftware com>
Date: Mon, 1 Nov 2010 15:06:30 -0600
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 _______________________________________________ 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)
- Re: [NSE] accton.nse: OSVDB 67963, Accton products Super User Password Generation Algorithm Weakness David Fifield (Nov 01)