Improper Builds (image by foto3116)

Last week I hinted at a vendor which included internal source code repository information in their firmware.  I contacted the vendor and am told that the secret password has been changed, so it’s time to talk about it.

When I went hunting for NTP appliances to check, one of the vendors I came across frequently was Spectracom.

Spectracom’s TimeServer 9400 series particularly caught my eye.  They’re a newer appliance, still sold today.  I grabbed a firmware image and did a quick analysis.  Like many embedded boxen, they run Linux.  The “firmware update” was just a ext2 filesystem with an update script to copy new files over the old.

I mounted it the update image and dug in.  Surprisingly, all of the system accounts are documented (this is not the case on their TimeServer 9200 series devices).  Then something caught my eye in /etc/profile:

export CVSROOT=”:pserver:mgoodlein:mark1234@10.10.10.1/CVS”

A quick google search recovered info about the poor engineer that left his logon credentials for a source control server in the build package.  Access to a source code repository would be a very juicy target for an attacker.  With it, a bad guy or gal could insert their own code into the device build tree, ala the Horde server.  It would probably take a lot longer than 4 months to be noticed in an embedded product.

The lesson here is one of development practices.  Development documentation can be a pain in the butt, but it can always save you some trouble and embarrassment down the road.  Ideally, a vendor will document every change that they make to a product’s source tree.  This includes ‘development process required,’ changes, which should be noted with an indicator.  For completeness, even compiler flags (build with debug symbols) should be included.  When the build is ready for release, jettison all of the ‘development process required,’ changes prior to final testing.

We have seen ‘developer cruft’ (or at least what vendors claim to be developer cruft) in network switches, RTUs, PLCs, and tons of other embedded products.  Again, it’s a poor assumption to make that, ‘nobody will notice,’ — this sector is becoming flooded with researchers looking for a quick kill.

It’s worth noting that Spectracom responded to my query within hours of contacting them.  They don’t have a security-specific email address, so it went from tech support to engineer and back very quickly, which is impressive.

Spectracom’s customer list includes the US Department of Defense, financial, and industrial sectors.

Image by foto3116