The ‘Shellshock’ bug in the widely used Bash command interpreter has underlined just how exposed a large number of embedded systems are remote exploits. The bad news for developers is that because of the byzantine web of dependencies in popular software products, it’s not entirely clear even to the creators of those systems exactly which ones are vulnerable.
At first sight, a bug that lets a hacker insert a small piece of code into an environment variable used by Bash does not seem to be that big deal. Surely the hacker has to have command-line access to the system in the place? Unfortunately, no. Because these products may use Bash as the interpreter for Common Gateway Interface (CGI) scripts that provide forms and interactive web pages for remote users.
Exploits have been developed for some versions of the DHCP software that many devices use to obtain a usable IP address on their local networks. If the attacker can find a way to get code into the exposed network interface and the product does not sanitize that data before passing it onto Bash, then unpatched systems are vulnerable. Some systems are luckier than others in how they call out to a command interpreter. They don’t make Bash available but use alternatives such as BusyBox, which does not suffer from the same vulnerability. But, latent vulnerabilities in other parts of software are simply waiting to be uncovered.
Updates or protection
Hugo Fiennes, CEO of Electric Imp, said in his security session system designers need to design networked systems with the idea they will be updated as needed and with little to no involvement from the user. However, this is still about reacting to problems rather than heading them off. Another way, demonstrated by Green Hills Software on the Freescale IoT trailer on the ARM TechCon exhibit floor, is to enforce a clear separation between enticing targets for hacks and the parts of the system placed there primarily for user convenience.
The demonstration put two Freescale i.MX6 boards side-by-side running a point-of-sale and credit-card transaction applications. Both ran the application under Linux and both were infected with a form of “RAM scraper” malware implicated in massive attacks on Home Depot and Target.
Dan Mender, vice president of business development at Green Hills, explained: “The RAM scraper gets into the system and monitors the RAM. On a conventional system, when you scan a credit card the information goes into a RAM buffer where it gets tokenized and sent off for transaction. The scraper knows the patterns to look for and when it sees them grabs and sends them across the internet. Millions of credit cards have been compromised that way.
“On the second system, Linux runs on top of Integrity. Before it goes into RAM the card gets tokenized by [a task running under] Integrity and sent off for the transaction.”
The RAM scraper keeps checking for the patterns it is looking for by but does not find anything useful because the data has already been tokenized once it hits the monitored area of memory.
“It’s been the most popular application in the trailer,” Mender claimed.
“As more and more compromises are happening, there are solutions that can provide security to thwart these types of malware attacks. There are different things that you need to do but the most important is to take account of the software architecture of the system and the hardware you are running on and plan around that,” said Mender.