SCADA environments are a big interest for me. As responsible of the information security of an utility company, I need to ensure that risks inside those platforms are minimized in a way thay any control I place does not interfiere at all with the protocol and system function. That is why running things like metasploit or nexpose could be really dangerous if they are not well parameterized, as it could block the control to the RTU and IED and potentially cause a disaster if a system variable goes beyond control. There is an alternative to perform vulnerability asessments to SCADA devices less risky and with good result information. You can use nmap scripting engine to add vulnerability scanning functionality. The software can be downloaded from http://www.computec.ch/mruef/software/nmap_nse_vulscan-1.0.tar.gz. The csv files are vulnerability databases and you need to place them into a directory named vulscan in the same directory as all other .nse scripts. The vulscan.nse script needs to be with all the other nse scripts. Once installed into the nmap scripts directory, you are all set. Let's how it works. First step to perform vulnerability asessment is to check open ports and versions of all servers running there:
The vulscan script will get the service scan information as input to gather vulnerabilities inside the vulnerability databases. Now you need to use at least the following arguments:
You can also use any other optional arguments used normally with nmap, as well as arguments to the vulscan script, like:
In the following example, nmap will perform a SYN scan, service scan and get the information as input to correlate with the Security Consulting Information Process Database. The command being run is nmap -sS -sV --script=vulscan.nse --script-args vulscandb=scipvuldb.csv 192.168.0.110:
In future diaries I will show other nmap scripts I like to perform vulnerability asessment and pentest.
Manuel Humberto Santander Peláez |
Manuel Humberto Santander Pelaacuteez 195 Posts ISC Handler Jul 1st 2013 |
Thread locked Subscribe |
Jul 1st 2013 8 years ago |
Thanks for this info. SCADA environments are definitely sensitive and have to be treated with care. In one of my previous positions, I also worked with SCADA systems. In the utility industry (just like in any industry) there are many legacy SCADA systems that can't be upgraded without a major capital investment. I've seen a good number of NT 4.0 and even DOS (yes, Microsoft Disk Operating System) running SCADA at certain sites. An upgrade isn't simple and isn't cheap... many times an upgrade would involve upgrading many (1,000+) PLC controllers and literally replacing the entire communications infrastructure to run the latest version of the "vendor approved" SCADA system at the site. $1,000,000 to upgrade SCADA? Never happens and usually the entity will simply accept the risk and that's how and why we still have DOS systems running SCADA software that controls certain power plants.
|
da1212 69 Posts |
Quote |
Jul 3rd 2013 8 years ago |
It doesn't make sense to spend the millions on upgrades when these systems could simply be made NOT REMOTELY ACCESSIBLE.
|
geos73 3 Posts |
Quote |
Jul 3rd 2013 8 years ago |
You also have to be very careful with very old propriety systems like this that nmaping them won't take them down.
Do not attempt this when the plant is running. |
Alex 19 Posts |
Quote |
Jul 5th 2013 8 years ago |
> these systems could simply be made NOT REMOTELY ACCESSIBLE.
Then, make them NOT LOCALLY ACCESSIBLE, so that a compromised computer inside your network cannot "reach-out-and-touch" the SCADA system. (Alas, but this was the vector that already has been used.) |
Anonymous |
Quote |
Jul 5th 2013 8 years ago |
Sign Up for Free or Log In to start participating in the conversation!