Schneider T200 RTU vulnerabilities

A few CVEs published in a Schneider T300 RTU recently jogged my memory. I went back 8 years to 2012 to dig out a disclosure we made to Schneider via an operator.

And there it was, similar (probably identical) vulnerabilities in its predecessor, the Easergy T200. As we were working via the operator, it wasn’t our place to apply for CVEs & we had no direct contact with Schneider. It’s an interesting story, particularly as the advisory above doesn’t detail the actual vulnerabilities.

Introduction

Industrial control equipment has a long life. We often find 20-30 year old OT kit when out testing security on customer sites.

This makes vulnerability disclosure challenging; it’s one matter convincing the vendor to fix the bug, another altogether convincing operators to install the update. That’s if the update will even work on old kit, often through lack of storage / memory or I/O issues.

However, this is a story of some issues that we found in an RTU. Unusually, the operator was more keen to resolve the issue than the vendor!

Back in 2012 we were working on a Schneider Easergy T200 RTU. It’s used for controlling medium voltage substations, so opening and closing switches that control large amounts of electrical power distribution to homes and businesses. It was an interesting device to us at the time as it had an integrated cellular data modem that made remote telemetry and operation rather more straightforward. Ideally, one would put it on a private APN and could manage it easily. The cellular modem is bottom middle of the panel below, next to the rotary on/off connectivity switch:

However, if that APN wasn’t configured well, if the RTU wasn’t well segregated from the corporate network, if it was accidentally left on the public internet, or if a substation wasn’t well secured physically, one could access the embedded web server.

That’s where things went a bit wrong, first off there was no SSL on the login:

Default creds are often still in place – the default for the T200 is easergy|easergy. Always worth trying defaults on any OT device before going at it harder!

Amusingly, the password was stored in plain text in the html!

Telnet. Often still enabled by default, though usually trivial to disable. A shame that it’s not off by default though.

Nothing devastating so far…

But then things got interesting

The purpose of this RTU is to open and close power circuits in outstations. This is done through the web interface:

The intention is that one authenticates first. Unfortunately, the parameter ‘value’ doesn’t check for authorisation.

Want to close the switch and turn off power to some homes, unauthenticated?

http://XX.XX.XX.XXX/XXX/controlSend.cgi?nameVar=Switch 1 Open/Closed&typeVar=TCD&adr=0&value=1

Or want to turn on the power when it shouldn’t be?

http://XX.XX.XX.XXX/XXX/controlSend.cgi?nameVar=Switch 1 Open/Closed&typeVar=TCD&adr=0&value=0

There’s more though:

It’s possible to generate a service request ticket in the web interface. Input to that isn’t properly validated, so there’s a nice persistent XSS too:

http://XX.XX.XX.XXX/XXX /Unitmodif.cgi?N=XXXXXXX%20Demonstration%20Unit<script>alert(/xss/)</script>&dateFormat=0&StationComment=T200E%20S3%20New%20Interface%20XXXXX%20v2.0

One would need to be fairly lucky to successfully hit an operator with an XSS like this, but it should in theory be possible to create a one-click XSS that causes an operator to unintentionally open or close a switch.

Disclosure

The operator disclosed these issues to Schneider. Remember that we’re talking ~8 years ago, so approaches to vulnerability disclosure were rather less mature back then.

Surprisingly, we heard back that a fix would be offered to the operator, but wouldn’t be offered to other operators unless they requested it / paid for updated firmware as part of their support contract. Odd!

It’s a shame that Schneider didn’t take action back in 2012, as these vulnerabilities have now been present for 8 years, until another operator took action. I guess our work got lost down the cracks of an immature disclosure programme.

We don’t think that’s representative of the vendor response we would receive today, had we disclosed this recently. Many OT vendors, clearly including Schneider, have much better approaches to disclosure and remediation now.

Conclusion

Updated firmware to fix these issues is now available. It’s worth applying it.

OT equipment is increasingly becoming remotely connected for telemetry and operational efficiency. Systems that were originally designed to be on private, isolate OT-only networks are being exposed to wider IT networks.

However, their security has taken time to catch up. In the meantime, ensure that you carry out a thorough assessment of your OT environment. If there are systems that you can’t update or replace yet, build layers of segregation to assure their security.

There’s a handy primer here.