I thought it would be worthwhile to explore the Beresford backdoor. I recently picked up an old S7 Ethernet module and wanted to see if it contained anything similar.
To do this analysis, I grabbed a few firmwares from Siemens’ download site. It’s easy enough to do. Searching for any of their CPU names on Google will give you their product home page, which includes links to firmware downloads. For example, the CPU 317 with Ethernet the Dillon worked on is here. Note that their firmware update page never even mentions the word, “Security,” it simply says “Addressing the Web server after a firmware update no longer causes Defect Z1:8000.,” Wow. Informative.
Anyway, I ripped the ROM out of my own Ethernet card for comparison. No special tools are required to get Siemens’ downloaded firmware, but reading the ROM from my Ethernet card requires a Flash programmer with a socket adapter (roughly $150 in parts), as well as the Ethernet module itself ($200 on eBay).
What Dillon Beresford found looks an awful lot like a debugger. It is unclear whether Siemens built their own command-line debugger for the processor, or used one that was already built.
The CPU-317 that Beresford demo’d is running an Infineon Tricore processor. Infineon was Siemens’ chip fabrication facility before it was spun off to be its own company. For comparison, my Ethernet module has a Hitachi Super-H processor (SH-3). Siemens was nice enough to put the EEPROM in my Ethernet module on a PLCC32 removable socket ROM, and I happened to have a reader for that in my parts drawer.
The Tricore processor is little-endian. Many news reports said that the backdoor password, ‘basisk’ was scrambled. This isn’t really correct, at least for the version I have. I endian-swapped the binary download from Siemens. I’m still not sure if its reverse-endian nature has to do with memory layout in the CPU 317 itself, or if it is some artifact of how the firmware is uploaded. Anyway, some screenshots of where the password is stored in this downloaded binary are shown. These are just outputs of the unix hexdump:
hexdump -Cv <filename>.
I then searched for the words ‘login’ and ‘password,’ in the output. I didn’t manipulate the firmware at all, besides changing the byte order of the file from little-endian so that the strings were readable. The password isn’t scrambled at all, it’s just stored in the processor’s native byte ordering, and the super-secret backdoor password string is stored immediately following the “Password” prompt string in the firmware.
If I had access to a disassembler right now, I would probably see the authentication function load the pointer to the “Password” string, call
printf(), call a
getinput() function, and then string compare the input to the backdoor string pointer. This is probably why they are right next to each other in the binary. Go-go gadget compiler.
A takeaway from this is that concerned members of the ICS security community can easily download all of Siemens’ firmwares and verify if the backdoor is present in other products without the need to buy any hardware and without the need to rely on Siemens pronouncements. Of course the “bad guys” can just as easily do this and likely already are on this.
For what it’s worth, my old S7 Ethernet module appears to have similar debugging features (a complete disassembler baked into the firmware, which probably means a debugger…I’ll supply a little more info on this later), but it isn’t obvious how to access them yet.
It’s kind of sad. I mean, really, Siemens? You put a backdoor in your product and didn’t even try to cover up the password. My guess is that many other vendors do this sort of thing. Don’t worry, other vendors, the research community will find your secrets, too. Now would be a wise time to revisit your development and release process to stop this sort of thing from happening.
Photo by wbfary