Embedded device security assessment

Published: 2009-01-28
Last Updated: 2009-01-29 01:45:07 UTC
by Robert Danford (Version: 1)
0 comment(s)

Following on the theme from Pat's last diary on Conficker and embedded systems,
we had a reader submit a question about policies and controls related to devices such as
network connected freezers.

This area raises interesting security questions as embedded devices become more powerful.
Embedded devices may be less likely to be patched, properly monitored, or contain the same security features
of a full system such as strong passwords, account lockout controls, privilege levels, host firewalls, support for crypto such as SSL/SSH.

What security policies should be applied to these devices? How should they be audited much less inventoried.
What information should a vendor provide and disclose in regards to network connected embedded systems?
How are the risks of system failure quantified? What access is appropriate to give a vendor to a device over a network?
In the freezer example the vendor requires direct access from a remote location for inventory management.

Many breaches are a result of unscrupulous employees at partner/vendor companies or security breaches at the vendor site.

Would you let another company put a device on your internal network they have direct access to?
What about a DMZ? It isn't common practice to put multi-function network printers, etc within a DMZ.
How are these questions different if the device in question may affect human life or public safety?
Network connected medical equipment has brought great advances and automation, but resulted in spectacular failures which
only become more severe with increased reliance on the technology.

Network printers have long been used as jump off points in exploiting networks and for storage of hacking tools and data.

Many of us have also accidentally tipped over machines through routine network scanning with tools such as Nmap (remember OS detection
scans against Sun Solaris 2.6?) or tools such as nessus (even in safe mode) have been known to cause inadvertent crashes.

These issues are compounded in inconceivable ways as the forecast of every object on the planet being IPv6 addressed and network connected.
We'll be raising alerts about bot armies of Chinese toasters DoS'ing our refrigerators.

There are a lot of great resources out there on this topic and many people have been warning about the security risks
posed by embedded devices for a long time. I am definitely not an expert in this area, but have performed security
assessments of embedded devices and management subsystems (such as the management interface for blade server frames).

I will include a more recent link to a presentation that I think covers many of this issues well including discussing
the ever increasing storage and processing capacity of embedded devices.

http://www.blackhat.com/html/bh-usa-06/bh-usa-06-speakers.html#O'Connor
Presentation (http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-OConnor.pdf)

Other worthwhile resources
Adrian "Irongeek" Crenshaw,  Hacking Network Printers, 09/11/2005 (last update 2007)
Dennis Mattison, Network Printers and Other Peripherals -- Vulnerabilities and Fixes 04/27/2002
Slobotron, Understanding, Reversing, and Hacking HP Printers, 04/2002
"The Embedded Internet" (Wired 4.10) 1997
http://unix.derkeiler.com/pdf/Newsgroups/comp.os.vms/2007-02/msg01175.pdf (Rinbot's impacts on a large hospital network)

Share with us any interesting experiences you've had securing, assessing, or doing forensics with these newer systems.
The SCADA and control systems area has been given lots of attention. But what about those freezers. Not to mention embedded systems
with WiFi support. Many sites have a hard enough time implementing best practices for wireless security on corporate laptops.
How many sites are insuring their coffee maker is using WPA2? Now what about a dialysis machine?
Final link for thought: http://www.fda.gov/cdrh/osel/guidance/1618.html

Robert
ISC Handler on Duty







 

Keywords: embedded devices
0 comment(s)

Comments


Diary Archives