ICS-CERT Publishes another S4 Alert and an Advisory

I should have waited a little longer before posting yesterday since just before 5 pm EST ICS-CERT published another S4 related alert (Siemens) along with a Schneider advisory. Arguably the Schneider advisory is of more concern.

Siemens Alert

This alert addresses a brute force password tool that could allow an attacker to the challenge-response data extracted from TCP/IP traffic file off-line to expose credentials used for communications with Siemens S7 PLCs. The tool was introduced at the S4 conference by Alexander Timorin and Dmitry Sklyarov of SCADA Strangelove.

The ICS-CERT advisory notes that an attacker using the tool must have access to an ‘adjacent network’ to acquire the information necessary to use the tool. They also note that the “possibility exists that this code may be modified to be used against other vendor products” (page 1).

NOTE: This was an extremely fast response from ICS-CERT as Dale tweeted about this presentation at about 2:00 pm EST yesterday. Okay the SCADA Strangelove blog post came a bit earlier than that, but it was still a pretty impressive response.

Schneider Advisory

This advisory outlines an authentication communication risk vulnerability in the Schneider Electric software update (SESU) utility used by a number of Schneider products. According to the advisory a moderately skilled attacker could exploit the lack of authentication of update messages to execute arbitrary code on the system.

Schneider has updated their SESU server to support both HTTP and HTTPS communications (HTTPS does ensure signed communications). The SESU client will be updated this month using the existing HTTP protocol. Schneider will not completely switch to using the HTTPS protocol until May 2013. (NOTE: There is an interesting typo – I think – in the advisory that notes that this “means that only HTTP [emphasis added] will be supported during SESU client updates from that time forward” I think that should read “only HTTPS”.

Product updates are an important part of any software support system and there must be a method to verify that the updates are coming from the actual vendor. It is very disturbing that this very basic security procedure has not already been in place.

I do understand that the delay until May to completely implement this change on the client side of the SESU system is driven by an effort to ensure that all systems in place are updated with the changed communications protocol before eliminating the HTTP-based updates, but that is a very big window of opportunity for the exploitation of this vulnerability. At the very least, I would expect that many systems could have backdoor access installed via this mode to allow future access to the systems.