Re: Another SCADA/ICS NMAP NSE script - Electro Industries / Guagetech 'Nexus' smart meter enumeration script

[Bob Radvanovsky <rsradvan () unixworks net>]

OK...some truths?  Ever heard of "SHODAN"?  Look it up...

I am doing 'testing' on live systems that aren't password-protected, are considered 'open', and connected (most likely) 
*directly* to the Internet.  I am delving into some dangerous waters here, and do not wish to make any further 
statements at this time...

-rad


----- Original Message -----
From: David Fifield [mailto:david () bamsoftware com]
To: Bob Radvanovsky [mailto:rsradvan () unixworks net]
Cc: nmap-dev () insecure org
Subject: Re: Another SCADA/ICS NMAP NSE script - Electro Industries / Guagetech 'Nexus' smart meter enumeration script


> On Tue, Dec 07, 2010 at 03:19:47PM -0600, Bob Radvanovsky wrote:
> > This is one of several enumeration scripts that I have written for the
> > SCADA/industrial control systems community.  This checks/validates the
> > web-based traffic for the Electro Industries / Guagetech 'Nexus' smart
> > meter device.  NOTE: This has been ONLY tested with a limited number
> > of models from the 'Nexus' series, and I am still adding more models
> > (such as the Shark 100S).  
> >
> > All of these devices utilize an Ethernet connection to 'talk back' to
> > a (probably) centralized controller.  All devices are capable of
> > running both Modbus TCP and DNP3.  The Shark 100S and Shark 200S
> > provide wireless (via WiFi) capabilities to poll these devices.  All
> > devices that have web server capabilities DO NOT utilize any "secured
> > web servers" (port 443), ONLY UN-secured web servers (port 80).  If I
> > encounter any 'Nexus' devices that do provide/offer "secured web
> > servers", that will be incorporated into the NSE enumeration script.
> >
> > The same script is shown below; if you wish to download the script,
> > the script may be accessed here:
> > http://www.infracritical.com/enum-scripts/eig.nse
> >
> > PORT   STATE SERVICE
> > 80/tcp open  http
> > | eig: CONFIRM DEVICE AS ELECTRO INDUSTRIES GAUGETECH
> > | ** PHASE 1: HTML verification
> > | ....Step 1: EIG device info        : CONFIRMED
> > | ............Version S/W            : 1.0 (Build 34)
> > | ............Boot Version S/W       : 1.0 (Build 50)
> > | ....Step 2: HTML device detailed information
> > | ............Manufacturer name      : Electro Industries/GaugeTech
> > | ............Boot ID model number   : Boot 100 Base-T
> > | ............Run ID model number    : Run 100 Base-T
> > | ............Device type            : 0107 Nexus 1252
> > | ............Serial number          : 00000000
> > | ............Network MAC Address    : 00-00-00-00-00-00
> > | ............Modbus TCP server      : ENABLED
> > | ............DNP TCP Server         : DISABLED
> > | ** PHASE 2: Documentation
> > | ....Step 1: Documentation exist?   : YES
> > |_............ninja.infracritical.com/dox/gaugetech/nexus1252.pdf
>
> As I read it, this script makes several HTTP requests:
>
> /
> /diag_firmware.htm
> /meter_information.htm
> /diag_modbus_tcp_server.htm
> /diag_dnp_lan_wan.htm
>
> It then runs pattern matching against the HTML to get the device
> configuration.
>
> Bob, I'm curious about how you use these scripts. I think it will help
> me understand your perspective. Do you run them against large netblocks
> to enumerate devices of a certain type? Do you only run them when you
> think you have a certain type of device on your hands? If so, how do you
> get that knowledge, from Nmap or otherwise?
>
> It's pretty easy for me to imagine someone scanning an address and
> saying "Oh, version detection / NSE says that I have a Nexus smart meter
> here." It's hard to imagine someone saying, "A Nexus smart meter? I have
> a script to run to get lots of details from that particular device." Do
> you see what I mean? If this knowledge can be had from version detection
> or a general-purpose script, that is preferable to isolating the
> knowledge where it is less likely to be used.
>
> I think you have some good ideas here and I hope I'm not being too
> brusque. I think the checks implemented by this script are good
> candidates to be moved to http-enum. The large number of data fields
> you're able to retrieve may strain the pattern replacement (I don't know
> if you can have a replacement higher than \9), but that's a worthwhile
> thing to test too.
>
> David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/