Digital Bond

For Secure & Robust ICS

  • Home
  • Consulting
  • S4x18
    • S4x18 Call For Presentations
    • S4x18 Sponsor Packages
  • Dale Peterson
  • Hire Dale To Speak
  • Contact Us

RuggedCom Owes its Customers an Explanation

April 30, 2012 by Reid W Leave a Comment

Broken Window (image by spi516)RuggedCom was first contacted by Justin Clarke in April 2011 concerning backdoor access to their switches and serial converters.  Late on Friday, they announced that they would remove the account from their devices, and that the change would only take a few weeks.

From the press release (notably written by RuggedCom’s VP of Marketing), the backdoor sounds like code cruft left over from the development process.  I smell something fishy, though.  If the code is really just development cruft, it should be easy to remove.  RuggedCom should have removed it when Justin Clarke contacted them a year ago, or should have removed it when ICS-CERT contacted them months ago.  They did not, though.  Take another look at Justin’s reported timeline:

Apr 2011      – Vendor notified directly
Jul 2011       – Vendor verbally acknowledges knowledge of backdoor,
and ceases communication.
Feb 11 2012 – US-CERT notified
Mar 12 2012 – Vendor responds to US-CERT.
Apr 06 2012 – Due to lack of further contact by vendor, CERT sets
public disclosure for April 13 2012
Apr 10 2012 – Vendor states they need another three weeks to alert
their customers, but not fix the vulnerability.
Apr 11 2012 – Clarification requested regarding need for additional three weeks.
Apr 23 2012 – No response from vendor.
Apr 23 2012 – This disclosure.

In medical parlance, RuggedCom addresses the symptom but not the disease in their press release.  The disease, in this case, is a lack of a methodical development process that has any awareness of security.  RuggedCom clearly does not include security as a part of its development lifecycle, at least not in their switch and serial converter lines.  This ‘developer backdoor’ made it into release.  Nobody and no process at RuggedCom stopped it, and RuggedCom has no process to address security concerns in already-released products.  They were not going to fix it at all until Justin went full disclosure.

[Read more…]

Filed Under: ICS Vendors, ICS-CERT, Uncategorized, Vulnerabilities, Vulnerability Disclosure Tagged With: backdoors, ruggedcom

Ruggedcom Backdoor Revealed – Fragile

April 24, 2012 by Dale G Peterson Leave a Comment

SCADA Hacking

Maybe Not

UPDATE – The vulnerability was found by Justin W. Clarke, an independent security researcher in San Francisco, California.

We don’t cover most of the ICS vulnerabilities on this site, but the Ruggedcom Undocumented Backdoor Access is a huge risk and pathetic display of vendor response if the details on full-disclosure are correct.

Ruggedcom is the Cisco of network infrastructure equipment that is packaged and hardened for the industrial environment (Hirschmann would be the Juniper or vice versa). It is very common to have the IT staff pushing for Cisco and the operations staff demanding a ruggedized router or switch, often Ruggedcom. Increasingly Ruggedcom is being used as a perimeter security device for field sites as they have integrated security features.

According to a full disclosure post by author JC, the Ruggedcom devices have a hard coded account named ‘factory’ and a fixed password that is generated from the MAC address. So learn the MAC address and get the credentials to login to the Ruggedcom network infrastructure device.

According to JC, this is in all versions of the Rugged Operating System (ROS). The analogue would be finding a backdoor account with deterministic password in Cisco’s IOS.

It’s bad enough that Ruggedcom has allowed this shoddy security practice into the product line, but then when called on it, they failed to react. According to JC’s timeline, Ruggedcom was notified in April 2011. After no fix was forthcoming, JC notified US-CERT in February 2012. With no fixed planned, he went public today.

Why was this not fixed? It actually shouldn’t be that difficult to fix a hard coded account, deterministic password  … unless it is used for something such as management or updates. So you have the unpleasant choice of either truly embarrassing response to a serious vulnerability or a backdoor that is important and used.

[Read more…]

Filed Under: Siemens, Vulnerabilities, Vulnerability Disclosure

AppSecDC In Review

April 11, 2012 by Reid W Leave a Comment

While there were some great talks at AppSecDC, the attendance at their Critical Infrastructure track was not very high.  Critical Infrastructure is a new topic area for the AppSec conference this year and it’s unclear if it will survive.  OWASP has a lot of web testing experience to draw upon, which could be really helpful in securing control systems.

There were a lot of presentations in AppSecDC’s Critical Infrastructure track about methodologies used in pen-testing and exploiting control systems.  We seem to be at a very ugly point in control systems security where we’re dealing with both massive numbers of backdoors and unauthenticated protocols, as well as genuine and exploitable software bugs.  Let’s not forget that basic security practices aren’t in place by a lot in the control systems space, with by some estimates a hundred thousand controllers directly connected.

Denial of Surface

Éireann Leverett gave a refreshed version of his ‘Denial of Surface’ talk that we first saw at S4 (link).  In the updated talk, Éireann showed numerous building energy management systems within a few miles of the Washington Convention Center, as well as a stunning 15,000 management systems from a single vendor.  I raised the issue of what number of vulnerable HVAC controllers would be sufficient to disrupt grid operations.  Digital Bond recently added Michael Toecker to our roster (he’s a PE), and he was able to work out some napkin math.  The short answer is, “it depends,” on how close together electrically the buildings are, but localized blackouts are not out of the question if loads are bounced simultaneously.  I do enjoy Éireann challenging the definition of ‘critical,’ as he so often does.  Seeming non-critical controllers are often critical to the right people.

Given how not seriously security is often taken by vendors in control systems that do more dangerous jobs, we’ll probably be hearing more about this one someday.

Among the more ‘curio’ online controllers Éireann showed is a series of petrol stations in Turkey.  The embedded controllers perform OCR (Optical Character Recognition) on car license plates, allowing for easy people-tracking.  The most recent purchases may be observed, as well as the underground storage tank level.  We managed to find backdoor credentials to the gas tank refueling controller in about fifteen minutes.

Pen-Testing Smartgrid

Justin Searle at Utilisec discussed pen-testing smartgrid apps.  Pen-testing live  systems is always a dicey proposition, and smartgrid applications are no different.  Web interfaces sometimes present interesting options, such as mass-disconnect commands, which is why pen-testing any kind of control app needs to be approached with extreme caution.

[Read more…]

Filed Under: Events, ICS-CERT, Vulnerability Disclosure Tagged With: appsec, Conference, ICS-CERT, ioactive, utilisec

A Case Study in Not Fixing the Problem

February 24, 2012 by Reid W 3 Comments

Shortly after Rubén’s vulnerability announcement concerning their Modicon Quantum line of controllers, Schneider Electric released updated firmware for their various controller’s Ethernet cards, as well as an advisory (I sarcastically love the combination of “we take security very seriously” and “hard-coded backdoor credentials”).  The partial fixes are incorporated into version 5.01 of their firmware for our NOE 771 01 module, which was shown in Basecamp.

The fix is rather sad.  It disables the Telnet and WindRiver debug service issues, but leaves backdoor accounts and an FTP server enabled.  The WindRiver debug port is fairly well-known (Dillon Beresford wrote up some nifty documentation on automating WDB agent attacks, including showing how to remotely alter how a controller boots by using the service to overwrite the bootline).  The WindRiver Telnet service is quite a bit less-known.

The telnet service is really a C interpreter.  Fermi National Labs has a nifty intro to it here.  Because Schneider left debugging symbols in the Quantum line of controllers, it’s incredibly easy to use the C shell: you get function names.  You can type commands like ‘strlen(“foo”)’ and the shell will return 3.  On systems which lack debugging symbols, you’re left having to reverse engineer the firmware to find the function location, and then calling the function by using the pointer.  For example, suppose that the strlen() function was found to begin at offset 0x0016fc18 in the disassembly:

-> 0x0016fc18(“foo”)
value = 3 = 0x3

It’s pretty interesting because the command line is totally type-free C.  You can treat any spot in memory as a function without having to cast it.  Even if your target lacks debugging symbols, that’s okay: you can do assignments on the command-line to make your life easier and make your code cleaner.  This works for both function names and your own declared variables:

-> foolen = 0x0016fc18(“foo”)
foolen = 0xa0c6b8: value = 3 = 0x3
-> foolen
foolen = 0xa0c6b8: value = 3 = 0x3
-> d 0xa0c6b8
00a0c6b0:                      0000 0003 eeee eeee   *          ……*

You can use the Telnet console for a lot more evil things, too, of course.  vxWorks includes a full bsd sockets library, meaning that you can write a C program to run as a port scanner from the telnet console.  Kinda cool.  The syntax is quite clunky on the Schneider…while the device has debugging symbols, you lack the ability to use C data structures by name.  You have to do things the old-fashioned and painful way: make a socket structure in memory by malloc()’ing bytes, filling in the socket structure by hand, and then calling the C connect() function.

The upgraded firmware does remove the Telnet service.  In my opinion, it’s not even worth upgrading the firmware yet though.  While it does lower your risk ever-so-slightly, all that it really succeeds in doing is providing a false sense of security.  An attacker that spends 20 minutes with the controller will learn that the firmware may be downgraded using the still-present FTP server and backdoors.  The firmware image is simply a file that can be overwritten using FTP access.  It also doesn’t fix the issues that our Metasploit module exploits, which just uses these two issues to grab user accounts for the system’s other services.

There are plenty of nice projects surrounding vxWorks now, including a vxWorks rootkit complete with a portscanner and other fun network penetrating tools.  The HP rootkit was hand-coded in ARM assembler, but a port to PowerPC would be trivial.  Schneider would be such an easy target because of their inclusion of debugging symbols with the firmware image.  Very little reverse-engineering is needed to find the functions for changing a Quantum into a weapon.

Image by fireflythegreat

Filed Under: Basecamp, Group Schneider, ICS-CERT, Uncategorized, Vulnerabilities, Vulnerability Disclosure Tagged With: Basecamp, schneider, VxWorks

Valentine’s Day SCADA Tools Release

February 14, 2012 by Reid W 8 Comments

Vendors are red
SCADA is blue
Now everybody
can demonstrate vulnerabilities in controllers

As promised, we have more PLC exploits ready to roll in time for Valentine’s Day.

First, I can’t stress enough how much the other Basecamp researchers have done as volunteers. I was lucky enough to be paid to do this work, but I feel a bit outgunned by the accomplishments of the other researchers. I especially wish that our anonymous researchers could take credit for their hard work.

The tools may be downloaded from our site’s newly created Basecamp section, which includes individual pages for the Basecamp devices. Note that the Metasploit modules provided today are ‘proof-of-concept,’ and have not yet been blessed by Rapid7. They go through a QA process and typically make the modules a bit more elegant. These proof-of-concept modules may be buggy. Please pester Reid for support until they are officially released by Rapid7.

All three devices tested against today’s releases can be found online using Shodan or other methods. The exploit modules will do nasty things such as stop the CPU or provide the credentials to control the device. Please be responsible and don’t attack any systems that you find.

Allen-Bradley/Rockwell Automation (plus Schneider, WAGO, Omron, and many, many, many, many others)

Rubén went so far as to write C code demonstrating issues with the EtherNet/IP protocol. I ported a small part of the tool to be a Metasploit module. Note two of the payloads in this module (ethernetip_multi) should work against any PLC which speaks the EtherNet/IP protocol.   The ‘vulnerability’ is in the protocol specification: no authentication is required per the standard for many commands. About 300 vendors belong to the organization responsible for the EtherNet/IP CIP specification, so the list of affected devices is going to be…large.  This vulnerability should include some systems by Schneider Electric, WAGO, Omron, Opto 22, Phoenix Contact, and ABB, just as examples.

There are multiple payloads for this module.  Currently you can issue a STOP command (should affect all manufacturers), crash the PLC CPU (probably Allen-Bradley specific, unless other vendors purchased their stack), crash the Ethernet controller (probably Allen-Bradley specific), and reboot the Ethernet controller (should affect all manufacturers). Note that Quickdraw already includes EtherNet/IP IDS signatures for a remote STOP (and many other attacks), and you can have those snort rules for free.

[Read more…]

Filed Under: ABB, Basecamp, Group Schneider, Host IDS/IPS, ICS-CERT, PLC Security, Quickdraw, Research, Rockwell Automation, SCADA Hacking, Vulnerabilities, Vulnerability Disclosure, Wind River Tagged With: Basecamp, disclosure, hacking, Metasploit, plcs

Koyo/Automation Direct Vulnerabilities

February 8, 2012 by Reid W 2 Comments

From Project Basecamp, we learned that the Koyo series of PLCs has some pretty fun security issues.

The first issue is with our test device’s built-in webserver. In addition to having denial-of-service vulnerabilities, the web server itself requires no authentication and allows changes to the PLC configuration, such as its IP address. To top things off, the server does not properly validate user input, and is vulnerable to cross-site scripting attacks (XSS).

There aren’t very many ECOM100 modules available on the internet, although a clever searcher could find a few dozen. Our researcher tells us that the standard ECOM module is far more popular than the ECOM100. The ECOM module lacks a built-in webserver, but should still be vulnerable to the ECOM100’s other issue: a limited password space and no lockout/timeout for authentication attempts.

Part of our Valentine’s Day tool release is going to be a module to brute-force the Koyo’s password. This should save some end users money: from Automation Direct’s FAQ, a lost password means that the end user must send the device in for a reset.

The biggest challenge in implementing the Koyo password brute-forcer was determining the DirectNet protocol’s CRC algorithm. The HAP protocol documentation (more on how we got this below) just says, “The CRC is computed using an algorithm which implements a moving exclusive-or and a translation table.” Not terribly informative.  The 16-bit CRC is placed inside of the UDP packet’s payload (I call this ‘encrapsulation’, because UDP has its own CRC-16 in its header, making this CRC somewhat redundant).

I started disassembling the .DLLs and .EXEs included with Host Engineering’s DirectNet SDK, searching them for the string ‘CRC’. I found that the NetEdit3.exe utility included some printf()’y looking messages about CRC failures. So, I figured there must be a function in that program that was computing the CRC for the HAP protocol.  Sadly, I couldn’t trace the data xrefs to these error messages back to the CRC function very quickly.

Being a lazy reverse engineer, I came upon a silly idea: instead of grasping through code xrefs to find the CRC function, why not just search the disassembly for instructions where the mnemonic is ‘xor’ and the src and target registers differ?  xor is often used in x86 assembly for clearing a register, i.e. xor eax,eax to clear the eax register, so a little IDAPython was required.

The first two search results were inside the correct function, located at 0x4246E0 in the disassembly

 

The DirectNet CRC Algorithm

So we see that it does a few xors, a right shift, and uses a lookup table to compute the CRC. I spent a while implementing the algorithm in Ruby, when a silly idea hit me: why not just google for the bytes of the lookup table? A lot of CRC algorithms have a ‘fast’ implementation using a small dictionary to speed them up, and a clever Ruby programmer may have implemented this one before, if I know what it’s called. The table starts 0x00, 0x00, 0x21, 0x10…

It turns out this is just CRC16-CCITT. There is already a one-liner Ruby implementation, making the upcoming Metasploit module far cleaner.

I’d like to give Digital Bond alumni Daniel Peck a huge amount of gratitude — he managed to find the protocol specification nugget that gave us the ability to make the module possible. I only wish that I could give our anonymous researcher some public acknowledgement (because this person is really smart and did a lot of hard work as a volunteer).

Image by erikcharlton

Filed Under: Basecamp, ICS Vendors, PLC Security, Research, SCADA Hacking, Uncategorized, Vulnerabilities, Vulnerability Disclosure

ControlLogix Design Issues

February 2, 2012 by Reid W 10 Comments

The Rockwell Automation vulnerabilities that Rubén Santamarta uncovered for Basecamp were in my opinion the most challenging and interesting in the entire project (the very close second-place device being the Koyo).  I say that because the protocol is something that a normal security researcher has never seen before.  I threw my hands up in surrender at learning GE’s LogicLinx protocol, for example, but Rubén and our anonymous researcher didn’t back down from their device’s control protocols.  Rubén reverse engineered Rockwell’s firmware, software, and read up on the configuration protocol to discover some fascinating design issues.  I highly recommend checking out his official report here.

These issues have the potential to affect every product that implements the EtherNet/IP (CIP) protocol, not just Rockwell.  Schneider, Wago, and a number of other vendors will be affected by most of these problems.  ICS-CERT is probably going to need to issue a new advisory.  For a complete list of affected vendors, check out the member list at ODVA, the organization which is responsible for defining the protocol.

Rubén even went so far as to write C code covering the design issues, which we hope to build into a Metasploit module for our mid-February release.

These requests can all be performed without authentication:

1) The PLC CPU can be placed into STOP mode, meaning that it won’t execute ladder logic any longer.

2) The PLC CPU can be crashed using a malformed request.

3) The Ethernet card can have a new firmware uploaded.

4) The Ethernet card can be crashed using a malformed request.

5) The IP address of the Ethernet card can be changed.

Combining these attacks can cause an interesting conundrum for operators: Place the CPU into STOP mode and then crash the Ethernet card (or just change its IP address), and an operator is going to have to walk up the system to even determine what the problem is — an attacker can easily cause a loss of control and loss of view scenario.  Uploading a new Ethernet firmware may even allow an attacker to bypass the password protection system completely (assuming that authentication is checked in the Ethernet module…we’re not sure at this point).

Issues 2 and 4 are less of a concern than 1, 3, and 5.  Issues 2 and 4 are just implementation mistakes that can be patched.  Issues 1, 3, and 5 are actually defined by the CIP specification as not requiring a password to perform.  Fixing them is going to require a sit-down between at least a half-dozen companies to decide on how to fix the protocol.  Fortunately the change should be easy: simply require that a CIP session is authenticated before these requests are allowed.  A future challenge is going to be that EtherNet/IP is not encrypted: I can sniff a session and, if that session is authenticated, spoof a CPU STOP message using the session identifier.

The decisions made when designing this protocol truly show the cost of “insecure by design.”  Fixing it is going to be expensive at many levels: numerous vendors will have to spend time and money just to agree on a new standard.  Those companies are then going to have to implement the new standard, and to backport the new standard to existing devices — or make the decision to leave existing systems vulnerable to attack.  Application software will have to be modified to require authentication for those operations, and the software will have to deal with legacy systems that aren’t patched.  Finally, end users are going to have to upgrade their application software.  This cost is placed on the OVDA members, the firmware and software development teams, and the end users.

A number of LogicLinx devices can be found using Shodan, making this a pressing issue for quite a few users, whether they know it or not.

Filed Under: Basecamp, Control System IT, DHS, Digital Bond, ICS Security Technologies, ICS Vendors, ICS-CERT, INL, Network IDS/IPS, PLC Security, Research, Rockwell Automation, Uncategorized, US Government, Vulnerabilities, Vulnerability Disclosure Tagged With: allen-bradley, CIP, controllogic, ethernet/ip, rockwell

The Sherpa: Basecamp Redux

February 1, 2012 by Reid W 7 Comments

I’ve experienced a lot of cognitive dissonance concerning the Basecamp disclosure and exploit tools release over the last few months.  I might as well explain some more thinking of why doing what we’ve done is a good idea in the end.

I’ll repeat Dale first: PLCs are vulnerable.  EOL.

This next bit is speculation, but I suspect that ICS-CERT caved to vendor requests when it redefined the term ‘vulnerability,‘ at Weisscon to not include designed-in issues.  The D20, for example, is configured using TFTP.  Part of the configuration process requires executing commands on the command shell, and this is implemented via TFTP in a quite interesting way (I’ll just say “the code documents itself” — read the metasploit module d20tftpbd for amusement).

The D20ME is therefore insecure by design, and their desktop configuration software uses this protocol to set up the device.  ‘Fixing,’ it means breaking their software.  According to the Weisscon version of ICS-CERT (we’ll call it ICS-CERT 2.0), they don’t treat this as a vulnerability.  In a sense, my tools can’t even be defined as ‘exploits,’ under the DHS definition — an exploit can’t exist unless there is a vulnerability.  My ‘tools’ are just using designed-in ‘features’ of the D20 to let a user retrieve accounts.  They can even be used for positive purposes (for example, emergency access if an operator doesn’t know the password).

DHS was completely wrong on this issue, whatever the motivation.  I like the DHS guys, they’re a good group and I hope to work with them in the future some day.  I think that they’re stuck in a hard spot, paid by vendors to test their products, unable to release results of those tests.  So they’re in the best position to do anything about crappy security in control systems because they have access to this expensive equipment and software, but they can’t help put pressure on vendors.  They have us researchers beating on them from the north, vendors beating them on from the south, Congress beating on them from the east, and utilities beating on them from the west.  This analogy lacks the 3rd dimension — airstrikes — I’m not sure who that is, but I’ll bet that there is someone else.  Still, they’re dead wrong on this issue.  I feel a bit like Rorschach here, but it’s a view on which there is no compromise.  Using these vulnerabilities, I can cause misoperation of a control system.  I can’t hammer this issue any longer, so I’ll stop.  ICS-CERT appears to have backpedaled, at least: their announcements clearly call the design issues we uncovered in Basecamp ‘vulnerabilities.’

Basecamp was, to me, partly about calling ICS-CERT on this.  So that appears to have worked, although there’s still no explicit mention from them that they were wrong.  So we keep up pressure.

Publishing tools is kind of mean.  I totally agree.  We didn’t inform the affected vendors that this was coming.  No doubt I’ve lost a few friends at my former employer over the disclosure method.  But it’s time to move on.

There is zero doubt in my mind that attackers have been looking at PLCs and RTUs for years, if not a decade.  There is zero doubt in my mind that various world governments have research projects identifying these vulnerabilities.  I don’t think that any .gov security researcher who has looked at any of these devices would think that the Basecamp disclosures were even interesting.  They’d probably say, “Yeah, we figured that out in one hour instead of the 16 that it took these jokers.  Go check the file server for PoC,” or something.

The trouble is, utilities and industrial control facilities have no idea how bad the equipment that they buy is.  Even the best pieces of equipment — imnsho things that I beat to death while employed by SEL — have some terrible security practices — plaintext protocols, inconsistent documentation, and the like.  In 2012, my smartphone is more featureful and far more secure than the equipment that controls the grid.  Sure smartphones are produced in far greater quantities to pad their profit margin, but they’re also 10-100x less costly than a typical PLC.  Oh, and I don’t pay for a support contract for my smartphone — a few years after I bought it, I can still get firmware updates.

Personally?  I think that these tools are going to be used for bad at some point soon.  Does it suck?  Yes.  I’m sure I’ll lose sleep over it.  Seriously.  Actually, I already do lose sleep over it.  Breaking stuff in my basement is a lot of fun.  The idea of someone else breaking stuff in a brewery is not a lot of fun to me.

But you know what?  If the tools are used for bad now, the attacks will be quite lame.  The big, bad, dangerous skr1pt k1dd1ez won’t know what the heck they’re doing.  Stuxnet taught us a very important lesson here — that intelligence gathering portion of a control system attack is as important, if not more important, than the exploit itself, where control systems are concerned.

If we don’t release the tools now, vendors have no incentive to change their ways.  Attacks will be way more effective in ten years if the controllers operate the same way that they do now.  The Stuxnet cat has been out of the bag for a while, and hacker groups and foreign governments are stepping up their games looking at control systems.  In another five or ten years they may have the intelligence required to cause actual harm.  The exploits are trivial, so basically attackers will have no impediment to causing real harm.  Full stop.

If we suffer another lost decade, we’re screwed.  This isn’t a, “the sky is falling,” street-preacher exercise.  It’s just reality.  Better to put tools in the hands of script kiddies now, when the tools are less effective, than to only let really bad guys be the only ones that have them, waiting for the right time.  If an incident happens, a metric boat-ton of press will result, and something will have to give.  That something will be fixing basic security problems.

It’s weird, but I think that we’re at the right moment defensively — we have the right combination of control systems fragility and public awareness.  Hopefully this disclosure will make the impact that is needed.  I don’t know if the outcome is going to be better controllers via media pressure, client pressure, or public policy shift.  I do get the feeling that this is going to spark a trend in more secure controllers, though, whatever the secondary catalyst is.  More secure controllers exist, that much is for sure — Basecamp only touched upon the controllers that we had on hand.  Some really great products exist from my old company, and from talking to other big companies at S-4 I can tell that they have secure controllers out now, and some way better products in the works.

Personally I hope that pressures comes from end users, and that vendors start being more honest about their product spectrum.  Vendors often say that security costs money, and end users won’t pay for it.  End users are paying for it already, though, via firewalls, data diodes, and a boatload of work, nail-biting, and ulcers to separate their control networks from their corporate as best as they can.  If a controller costs more money but means that inter-network security can be a little more relaxed and carry less risk, end users save money in the end.

This is also good practice for vendors.  I agree, the Basecamp vulnerability disclosure was not ideal to vendors.  It’s not the worst that could happen, though.  The worst that could happen is a forensics call for incident response (sidenote: many Basecamp systems don’t log the attacks that were discovered).  I view Basecamp as a nice wakeup call to vendors — even the good vendors — that there are going to be security incidents and that they had better be prepared to deal with them responsibly and openly.  Frankly, I’ll be happy if a vendor takes a more mature face to the disclosure than Digital Bond has.  A vendor could do this by simply testing the issue, acknowledging it, and then providing their customers with information about the vulnerabilities (all of them), temporary mitigation, and a timeline for future patches and security features.  Having the discoverer run a validation would be pretty swell, too.

Image by papalars

Filed Under: Basecamp, Control System IT, ICS Security Technologies, ICS Vendors, ICS-CERT, PLC Security, Research, SCADA Hacking, Vulnerabilities, Vulnerability Disclosure Tagged With: Basecamp, disclosure, lost decade, the future, vulnerabilities

Anatomy of a Vulnerability: Modicon Quantum

January 31, 2012 by Reid W Leave a Comment

Rubén Santamarta did a fantastic static analysis of this device’s firmware here, and I won’t repeat his findings here (I did that once already).

In addition to having a slew of backdoor accounts, an open telnet service, and an open WindRiver RPC-Debug service open on this device, it has an unsigned firmware, managed accounts that are stored with usernames and passwords in plaintext, and buffer overflows galore.

Backdoor Access

This device is another case where the ICS-CERT defined vulnerabilities are difficult to exploit unless your goal is Denial of Service. The designed-in insecurities are far easier to use, giving superuser privileges for both Telnet and FTP.   User-definable account names and passwords for the HTTP service stored in plaintext files.  The user-definable accounts can thus be retrieved using the backdoor access, giving an attacker access to a easier-to-use graphical interface to the process via the web GUI.

We’ll be putting out a Metasploit module for this device on February 14th:

modiconpass – This will retrieve the HTTP and other plaintext-stored passwords from the Modicon and print them, as well as store them in Metasploit’s loot system. The passwords are retrieved using backdoor FTP access.

Note that, like the GE D20ME modules, this isn’t really an exploit.  We’re just using the backdoor access that Modicon gives us (they use it themselves) to provide access.

Denial of Service

The ethernet module can be crashed in many ways, all of which are untraceable unless the victim has an external intrusion detection system or packet logging system installed.  These don’t stop the PLC from operating autonomously, but they do cause a loss of view and loss of control for the operator of the system.

The first crash is the vulnerable TFTP server. The TFTP server allows an attacker to write arbitrary files to the /RAM0 filesystem, which is a blank ramdisk. If the filesystem is filled, the device crashes. I haven’t determined the size of the filesystem, but uploading for example /dev/zeroes from a Linux box will definitely do the trick.  There is now a check for this issue in Nessus, plugin #57600.

The next crash is in the HTTP server. Simply issuing a GET request with a long filename is enough. The request that caused the crash was a filename consisting of 1086 ‘A’s. It’s possible that this could be turned into a remote code execution exploit. I’ll look into this over the next week or two and update this post accordingly.

The next crash is in the FTP server. Issuing a FTP CEL request (anonymously) with a long argument crashes the device. This appears to be an old bug in vxWorks 5.4 which was fixed in 2002. It’s possible that this could be turned into a remote code execution exploit too. I’ll update in Mid-February after trying it with a debugger attached.

The HTTP and FTP server crashes are easily accomplished using the BED fuzzer, included with BackTrack 5 in /pentest/fuzzers/bed — just point the tool to the appropriate host, and fuzz the protocols.

Image by blackwing_de

Filed Under: Basecamp, Control System IT, Group Schneider, PLC Security, Research, SCADA Hacking, Vulnerabilities, Vulnerability Disclosure, Wind River Tagged With: backdoor, Basecamp, dos, modicon, Project Basecamp, schneider

Documenting The Lost Decade – ICS Vuln Analysis

January 30, 2012 by Dale G Peterson Leave a Comment

Sean McBride of Critical Intelligence presented  Documenting the “Lost Decade:” An Analysis of Publicly-Disclosed ICS-Specific Vulnerabilities since 2001. It’s by far the most comprehensive analysis of ICS vulns with a lot of interesting stats.

[vimeo http://vimeo.com/35801119]

It’s high quality video so expand to full screen to see the detailed slides.

Sean has some very interesting examples of hardware and software components with vulns that are never updated. We saw this with the LiveData ICCP server vuln that Matt Franz found while he was at Digital Bond. Sean covers this in his presentation.

The presentation includes a large number of data, charts and specific examples. There are break downs of vendors, researchers, where they came from, what they exploited and a lot more. For example:

  • ICS specific disclosed vulnerabilities doubled in 2010 from 2009
  • ICS specific disclosed vulnerabilities in 2011 were twice as much as all previously disclosed vulnerabilities
  • Sean believes 2012 will actually see a decrease in disclosed vulnerabilities
  • Iconics “led” with 29 disclosed vulns with Siemens a close second with 28
  • The bad news is those vendors and many others have only patched half of the vulns
  • ICS-CERT stated 60% of the ICS patches did not fix the problem

[Read more…]

Filed Under: ICS-CERT, S4, Vulnerabilities, Vulnerability Disclosure Tagged With: Critical Intelligence, S4, SCADA Vulnerabilities

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • …
  • 9
  • Next Page »

Subscribe to the S4 Events YouTube Channel

S4x18 Stats: 447 people from 25 countries
Thanks to all Attendees, Speakers & Sponsors

Follow S4 Events on Facebook

Tools & Talks

DNS Squatting and You

DNS Squatting and You

February 24, 2016 By Reid W 3 Comments

Basecamp for Serial Converters

Basecamp for Serial Converters

October 30, 2015 By Reid W 3 Comments

escar Asia

escar Asia

September 9, 2015 By Dale Peterson 1 Comment

Unsolicited Response Podcast: Cyber Insurance

Unsolicited Response Podcast: Cyber Insurance

August 27, 2015 By Dale Peterson 3 Comments

S4 Events Newsletter

Subscribe to our newsletter on leading / bleeding edge ICS cyber security information and S4 Events.

* indicates required
Email Format

Dale's Tweets

About Us

Digital Bond was founded in 1998 and performed our first control system security assessment in the year 2000. Over the last sixteen years we have helped many asset owners and vendors improve the security and reliability of their ICS, and our S4 events are an opportunity for technical experts and thought leaders to connect and move the ICS community forward.

Recent Comments

  • Chris on Koyo/Automation Direct Vulnerabilities
  • Brandon Workentin on The ICS Security Stories We Tell And Love
  • Joe Weiss on Insanely Crowded ICS Anomaly Detection Market
  • Stuart Bailey on Unsolicited Response Podcast Is Back … With John Matherly of Shodan
  • Chris Orr on Insanely Crowded ICS Anomaly Detection Market

Search….

Follow @digitalbond

Copyright © 2018 Digital Bond. - All Rights Reserved ·