From: Digital Bond’s SCADA Security Portal – C3-ILEX Coordinated Disclosure

Posted on 2012/11/05


a quick re-post from Digital Bond's SCADA Security Portal http://www.digitalbond.com/2012/11/02/c3-ilex-coordinated-disclosure/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+digitalbond%2FoLPM+%28Digital+Bond%29

C3-ILEX Coordinated Disclosure by Dale Peterson

SCADA HackingICS-CERT issued an advisory today, C3-ILEX EOSCADA Multiple Vulnerabilities, based on a Digital Bond information. I’ll tell you a bit more of the interesting story and technical details.

We found these vulnerabilities on a client assessment in October 2010. They were submitted to the vendor and ICS-CERT in November 2010. Yes, 2010 — two years ago.

At that time we recommended our client involve ICS-CERT to increase pressure on the vendor to respond, and we recommended they work with other customers through the user group for two reasons. First to increase the pressure on the vendor to fix the security issues, and second so that other customers will know the problem and get the fix. Eventually another customer will find a problem and hopefully reciprocate by notifying the user group.

The security patches have been available for some time now for our customer and I assume others as well. I have no idea why the public disclosure took so long.

While I often find fault with ICS-CERT, they are nothing if not tenacious on follow up. Once something gets in their system they chase it down to the end regardless of the time or number of contacts it takes. We would get periodic updates and be asked if the timetable was acceptable. (Note – that once we turn things over to ICS-CERT we generally walk away from the disclosure issue. We either handle coordination and disclosure ourselves or turn the whole thing over to ICS-CERT) ICS-CERT is great for researchers who don’t want to be bothered with the disclosure issue but want to make sure the vulnerability is not dropped.

The vulnerabilities were typical and easily identified:

  • Send anything unexpected to TCP/5050 and it crashed. Our poc script sent “A”. It took a few minutes to restart the EOSdataserver.exe app fully and there was SCADA denial of service until then. Obviously easy batch to repeat this denial of service attack.
  • The denial of service on TCP/24006 was not as bad. An adversary needs to send large amounts of data to cause a few apps to hang. The tricky part is recovery required two CoreScada applications to be manually closed or system reboot.
  • The information leakage was interesting. Connect to TCP/12000 and you are fed with a stream of data. It was definitely SCADA related and of some value, but it would have taken an effort to make any sense of it.

From press accounts and folklore many in the ICS community wrongly assume that we fully disclose everything we find. This is far from the truth, although I’m not casting aspersions on immediate and full disclosure. I’d estimate we disclose less than 10%. A large percentage is covered by NDA with our clients so they determine what is done with the information. Another chunk we choose to keep in house as IP for future use. We typically only publicly disclose the most obvious, insecure by design problems with a focus on PLC issues. You can read the Digital Bond disclosure policy here, but it basically says we will honor commitments first and then do whatever we want on a case by case basis if it is our decision.

Image by timparkinson (Digital Bond is the rooster in the photo)

Posted in: reading