Re: [NSE] eap-info

[David Fifield <david () bamsoftware com>]

On Fri, Mar 02, 2012 at 12:59:20PM +0100, Patrik Karlsson wrote:
> On Tue, Feb 28, 2012 at 10:32 PM, Riccardo Cecolin <nmap () rikiji de> wrote:
>
> > I'm working on a NSE script that implements a subset of the 802.1x
> > (EAP) protocol, i have a question about which is the correct way to
> > get an interface in a "prerule" script.
> > I'm forging directly the 802.1x packets and sending them with the dnet
> > library through a not yet configured network interface, but when I
> > open such interface with dnet:ethernet_open(), this function will
> > always fail unless the interface has an ip address configured, even if
> > it is up and cable-connected.
> > I'm trying to do that because I think it could be the standard
> > scenario of eap scanning. Is there a better way to access it from NSE
> > (without giving it a bogus ip)?
> >
> > Attached there's a version of the mentioned library + script that
> > successfully enumerates all the available authentication methods when
> > tested against hostapd v0.6.10.
> > I found that some other authentication systems have different
> > behaviors (e.g. they do not respond to eap start packets) so the
> > script needs some more development and testing in different
> > environments, but it's a starting point.
> >
> > Riccardo
> >
> > nmap -dd -e eth2 -sn --script-trace --script=eap-info --datadir=. localhost
> > Pre-scan script results:
> > | eap-info:
> > | Available authentication methods with identity="anonymous" on interface
> > eth2
> > |   true     PEAP
> > |   true     EAP-TTLS
> > |   false    EAP-TLS
> > |_  false    EAP-MSCHAP-V2
> >
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
>
> Hi Riccardo,
>
> Nice work. I looked into the dnet problem for you. As far as I can tell,
> the problem is not in dnet, but rather occurs due to the way that the
> function get_interface_info works. This function calls another function
> (getInterfaceByName) passing the address family type along so that the
> correct interface can be fetched. If there is no ip set this operation will
> therefore fail. My preliminary tests show that if I remove the code that
> checks for the address family and call the function for an interface having
> no ip, the script will work. So, technically it could work without having
> to set that dummy address. I'm not sure of the effort and how this is best
> fixed though? Also, I just realized that the PPPoE script I implemented
> recently would most likely suffer from the same problem.

The af check was added in r25760.

http://seclists.org/nmap-dev/2011/q3/473

It was intended to solve this problem here:

http://seclists.org/nmap-dev/2011/q3/311

I don't recall exactly what the original problem was. It may have been
that some interfaces are split up into different entries in the
interface table, some with IPv4 addresses and some with IPv6.

So I suppose we want an address family–agnostic version of
getInterfaceByName, or make it accept an interface with no address
configured, if it can't find one of the requested address family.

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