mailing list archives
Re: Another SCADA/ICS NMAP NSE script - Rockwell MicroLogix Series 1400 enumeration script
From: Bob Radvanovsky <rsradvan () unixworks net>
Date: Wed, 02 Feb 2011 00:44:36 -0600
Your points are very much well taken. This was an initial step at enumerating SCADA/industrial control systems
(automation) devices. As these devices are becoming more and more interconnected to regular, more traditional IT
protocols (such as SNMP, HTTP, TELNET, etc.), I took some time to enumerate some devices that were available (openly,
freely, with no protection mechanisms whatsoever) and proceeded to comprehend and understand the meaning behind writing
What I can say (between you and Fyodor) is that both of you are right. This is *way* to big, and is like trying to
swat an infestation of ... (take yer pick of whatever insect ails you) with a toothpick. It will have little or no
However, I wanted to provide the NMAP and SCADA/ICS / IT security communities with something tangible that, 'yes,
Virgina, it can be done'.
I am all about simplicity, and the fact is that (although I have tried and write as thorough of LUA code as I can) I
still don't fully understand all of its aspects and intricacies. This (and a few other select scripts) were a feeble
attempt at defining something useful to the SCADA/ICS and/or IT security communities.
Now that the 'honeymoon is over', I know what needs to be done:
(1) either make modifications to the existing enum scripts which are currently available out there (and hopefully,
their authors will cooperate with me).
(2) write a specific library set that will define *all* of Rockwell, *all* of Allen-Bradley, *all* of ..., and try and
enum based on manufacturer (which again, is back to swatting an infestation with a toothpick).
(3) just simply quit, because there is just *too much* stuff out there.
Based on the latter, I've tried to get others from the SCADA/ICS and/or IT security communities to 'pitch in'. Outside
of the 'me too' or the 'what's in it for me' questions, not too many people stepped up to offer assistance. Maybe some
of the SCADA/ICS and/or IT security hackers know something that I don't? Again...swatting bugs with a toothpick....not
Back to the code...
To be honest with you...it was late at night (knowing me...probably around 1-2 AM something-ish), so I might've missed
or skipped a step here and there - don't shoot me. Although I've come up the ranks from a software engineering
background (degrees and certifications on several languages - 'pick a card....any card'), I don't consider myself a
master of anything. I am a 'generalist', so it may very well be that I might've missed something. Point taken...
As far as making a more broader-stroked script, yeah....I can see that. Again, make one for *all* of Rockwell (and
cover as many of the devices as possible, making modifications as I/we encounter new devices, etc.); then make one for
*all* of Allen-Bradley (different from Rockwell, even though Rockwell now owns Allen-Bradley), etc., etc.
Is this how you imagined that this would turn out?
The fact is, quite honestly, *ALOT* of parties *are* interested in what I am trying to do, including several U.S. (and
other 'friend foreign') government departments and/or agencies (I won't name names, but you know who you are,
dah'lings) because of the recent 'Stuxnet' malware incident which is still being discussed today (no need to get into
details....again, 'pick a card....any card', and look up the key word 'stuxnet' for more info). The fact is, I haven't
seen something as simple and eloquent as 'Stuxnet' to cause as much of a ruckus as this, but it has. Enumeration of
devices on any given network is always welcomed, esp. by plant/operations engineers who don't know much about "IT", but
know that they have to be compliant for regulation "XXX". Making such scripts helps those engineers do their jobs.
OK...enough rambling (been up since 4 AM local time, so bear with me...) - I know what needs to be done. Give me a
month (or two) to get a "generic Rockwell" version of the script. Then, I'll start targeting other manufacturers. By
then, we'll have a whole mess of Messerschmidts (to quote Looney Tunes)...
Is this fair, Mr. Fifield?
----- 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 - Rockwell MicroLogix Series 1400 enumeration script
On Mon, Dec 06, 2010 at 09:28:38PM -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
SNMP traffic for the Allen-Bradley/Rockwell MicroLogix Series 1400 PLC
The same script is shown below; if you wish to download the script,
the script may be accessed here:
PORT STATE SERVICE
161/udp open snmp
| micrologix1400: CONFIRM DEVICE AS ALLEN-BRADLEY/ROCKWELL MICROLOGIX
| ** PHASE 1: SNMP verification
| ....Step 1: MicroLogix device info : CONFIRMED
| ............Version S/W : A/5.00
| ....Step 2: SNMP device detailed information
| ............Manufacturer name : Allen-Bradley
| ............Model number : 1766-L32AWAA
| ............Type/model type : MicroLogix 1400
| ............Series type : A
| ............Revision number : 5.0
| ** PHASE 2: Documentation
| ....Step 1: Documentation exist? : YES
I'm looking over your SCADA scripts now, Bob. Thanks for taking the time
to write and submit them. I think that what you have created has value.
In general, though, I think the special-purpose detection mechanisms
would be better built into general-purpose mechanisms that can classify
a larger number of devices.
As an example of what I mean, look at http-enum and the
nselib/data/http-fingerprints.lua file. That has fingerprints like
"/images/rails.png" => "Ruby on Rails" and "/gfx/logout_24.png" =>
"Secunia NSI". One could imaging ruby-on-rails.nse and secunia-nsi.nse
scripts that did these checks individually, but it's better to use a
common detection mechanism that is extended through a database of
Back to micrologix1400.nse. As I understand it, this script does a
sysDescr query and then parses some details out of it. The documenation
-- 1. PHASE I - SNMP verification.
-- a. STEP 1: Performs verification through 'snmpwalk'.
-- b. STEP 2: Acquires specific details from SNMP 'sysDescr.0'.
-- 2. PHASE II - Documentation.
However I don't see the (a. STEP 1) part in the code, and phase II just
seems to print a constant string.
What is the output of snmp-sysdescr against this device? In line with my
comments above, if snmp-sysdescr is missing information that this script
can provide, I would rather see effort put into improving snmp-sysdescr
than into a new script.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/