Embedded systems

I’ll Say it Again—Turn Off the Remote Web Management Interface!

I don’t know how many times I’ve told people that the embedded management interface on most devices is a security breach waiting to happen. I just got wind of some news, but can’t seem to find anything more than this mention. As soon as I dig up some details, I’ll let you know. This exchange is from Security Now! Episode 206 for July 23, 2009:

Steve…Stanford security lab….will also be showing some very distressing news this weekend at the Black Hat conference. They tested 21 different devices from 16 different manufacturers. These are web-enabled gizmos - webcams, printers, network switches, photo frames, VoIP phones, remote management tools, all of these things - and, like, consumer routers, all of these things that are web-enabled, meaning that like so many peripherals now, they’ve got an Internet connection and a web interface. They tested the vulnerability of 21 devices made by 16 different manufacturers. There was not one that was not vulnerable to serious web-oriented problems. For example, they were able to enter JavaScript commands into the logon prompts.

Leo: Oh, boy.

Steve: And the device logged the log-on attempts. So when the administrator brought up the log, the act of displaying the log replayed the JavaScript commands…And that allowed the commands to connect to a remote server and download malware. They said that among the worst devices were network attached storage devices. They enumerated five different classes of attacks, and they said that the NAS…were vulnerable to all five classes of attack. For example, you could rename files to JavaScript strings. There was no control over file naming in these. And of course we all have long filenames now in our state-of-the-art file systems. Well, long meaning JavaScript. And so anytime this device attempted to display the filenames on a web page, again, you were running JavaScript. So now there’s scripting running in your directory listing, which is displayed on a web page, causing your browser to do whatever the JavaScript has said. And it’s running in the local context. So even systems that have security saying don’t allow remote sites to execute script, but of course we trust our self, well, now we can’t trust our self.

Don’t tell me I didn’t say so. Turn that interface OFF!

The #1 Security Priority: Protect The Information

SANS recently reported that a Ponemon Institute survey, commissioned by Dell, found that more than 630,000 laptops are lost at airports each year, usually at security checkpoints and departure gates. A staggering 67% of them are never recovered. From SANS NewsBites Vol. 10, Num. 52:

The survey…included feedback from 864 business travelers: 53% said their laptops held confidential data; 42% said their data was not backed up; 16% said they would do nothing if they lost a laptop while traveling on business; 77% said the chance of recovering a lost laptop was less than ten percent.

Surprisingly, the SANS article made no mention that the Ponemon survey found that 65% of the travelers who have confidential or sensitive information on their laptops do nothing to attempt to protect it. The article seems to be more focused on physical security and this is indicative of a paradigm that is too heavily weighted in favor of protecting the network rather than the information traveling across it. The paradigm is shifting, but not nearly fast enough, as the survey shows.

Given the nature of operating systems and software, embedded or otherwise, there will never be a completely secure network; there will always be vulnerabilities to deal with and deal with them we must. However, the Internet is designed for sharing, not securing, a fact that’s never been more true than it is today;  with Web 2.0’s emphasis on community and collaboration, the need to protect the information is even more critical.

We can’t predict security vulnerabilities in third party software and systems, so all we can do is patch after the fact. If we make data protection the first priority and never allow a scrap of sensitive information to reside anywhere on any storage medium without it first having been encrypted or physically isolated, the severity of any newly-discovered vulnerability is greatly lessened.

What do you think?

HP’s iLO is not Vulnerable to Phlashing Attack

My May 29th post, “Phlashing Attack Can Damage Systems Beyond Repair,” generated some attention from Hewlett-Packard’s PR department. Depending on how you read it, my article could be interpreted to imply that their Integrated Lights Out (iLO) embedded remote management interface may be vulnerable to the PhlashDance attack. It wasn’t my intention to imply this and I am convinced that iLO is secure.

After having had a cordial conversation with Doug Hascall, Manager, iLO firmware, Industry Standard Servers, Hewlett-Packard, I agreed to post details about iLO’s security. Here is Doug’s email responding to my article:

Ken,

I enjoyed our conversation yesterday regarding the security of iLO and the phlash attack referenced by my colleague Richard Smith. As I mentioned on the phone, we take the security of iLO and our HP servers very seriously. This note is to share some of the information we discussed regarding iLO’s flash security.

iLO firmware employs the following flash protections:

* iLO firmware images are digitally signed with a 1024-bit RSA public/private key.
* The digital signature is checked before allowing a firmware update process to continue.
* The digital signature is checked by the iLO boot block every time iLO comes out of reset.
* The iLO boot block can only be flashed by physically changing a switch setting inside the server.
* Flashing the iLO firmware remotely requires login authentication and authorization, including optional two-factor authentication.
* The iLO firmware image to be flashed is completely uploaded into RAM before reprogramming of the flash device.

All ProLiant iLO firmware releases, from the original version that shipped with the ProLiant DL360 G2 in March 2001, have employed these protections.

I conferred with Rich Smith via e-mail to explain the iLO security architecture and to investigate the possibility of iLO being vulnerable to a Phlashing attack. Rich’s assessment was that iLO firmware and its upgradeability appear to have been designed with security in mind and he does not believe that iLO would be susceptible to a phlash attack or the methods used in the phlashdance fuzzer.

Security is a vitally important topic. I appreciate the attention that the security community brings to this topic and the associated opportunity we have to improve our products.

Respectfully,

Doug Hascall
Manager, iLO Firmware
Industry Standard Servers
Hewlett-Packard

This is security done right. Are you listening, Microsoft?