Re: [SC-L] embedded systems security analysis
A colleague and I have been looking at the problem a bit, in the context of need for survivability in safety-critical systems. Below is an extract of the paper Software Survivability: Where Safety and Security Converge authored by Larry Feldman, Ph.D., and myself, and presented by our colleague Theodore Winograd at the American Institute of Aeronautics and Astronautics' infot...@aerospace Conference in Seattle last spring. There's also a brief discussion of security issues associated with embedded software in the DHS/DACS Enhancing the Development Life Cycle to Produce Secure Software - specifically pages 272-275. The document is freely downloadable after quick registration on the DACS (DTIC's Data and Analysis Center for Software) Web site: https://www.dacs.dtic.mil/techs/enhanced_life_cycles/ Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com -- B. Embedded No Longer Means Isolated Before discounting a comparable threat to embedded systems, consider the following excerpt from Chapter seven of Exploiting Software [8] by Greg Hoglund and Gary McGraw: For no valid technical reasons, people seem to believe that embedded systems are invulnerable to remote software-based attacks. One common misconception runs that because a device does not include an interactive shell out of the box, then accessing or using ‘shell code’ is not possible. This is probably why some people (wrongly) explain that the worst thing that an attacker can do to most embedded systems is merely to crash the device. The problem with this line of reasoning is that injected code is, in fact, capable of executing any set of instructions, including an entire shell program that encompasses and packages up for convenient use standard, supporting [operating system]-level functions. It does not matter that such code does not ship with the device. Clearly, this kind of code can simply be placed into the target during an attack. Just for the record, an attack of this sort may not need to insert a complete interactive TCP/IP shell. Instead, the attack might simply wipe out a configuration file or alter a password. There are any numbers of complex programs that can be inserted via a remote attack on an embedded system. Shell code is only one of them. Even the most esoteric of equipment can be reverse engineered, debugged, and played with. It does not really matter what processor or addressing scheme is being used, because all an attacker needs to do is to craft operational code for the target hardware. Common embedded hardware is (for the most part) well documented, and such documents are widely available. One of the most widely publicized successful attacks on an embedded system was the 2002 hack of the flash memory of the Microsoft XBox game cube in order to access the algorithm used by the game cube’s cryptosystem to decrypt and verify its bootloader. [9] Now consider how safety-critical embedded systems—from temperature controls to medical devices to on-board airplane and automotive computers and sensors—are increasingly becoming network-accessible. For example, embedded software in implanted medical devices is now accessible via radio frequency identification (RFID) interfaces. [10] And telemedicine applications in use by DoD enable software-controlled surgical robots located in U.S. military facilities in Iraq to be operated via satellite uplinks by doctors at the U.S. Navy Hospital in Bethesda, Maryland. [11] Consider General Motors’ OnStar and its less familiar rivals (Ford’s RESCU and VEMS, Volvo’s OnCall, BMW’s Assist, Mercedes-Benz’s TeleAid and COMAND). These services all include the ability of call center representatives to perform remote telematic diagnostics of the onboard computers in their subscribers’ vehicles. The data they collect via transmissions from the cars’ computers are returned to the remote call centers via cellular or satellite phone links. Remote monitoring and diagnosis of automotive computers sounds benign enough (though there are significant privacy concerns associated with some of the data being gathered by these services), but OnStar has gone a step beyond simple observation to actual remote control of at least one of the automobile’s safety-critical onboard computers: the one that controls its ignition. As USA Today reported in October 2007, [12] the 1.7 million General Motors 2009 vehicles equipped with OnStar now allow their owners to grant permission for OnStar to cooperate with the police if their vehicles are stolen; specifically, if a police car is involved in a high-speed car chase with a stolen OnStar-enabled vehicle, the police can request that the stolen vehicle’s engine “be remotely switched off through the OnStar mobile communications system”. The objective of this police/OnStar cooperation is laudable: it allows the police to terminate car chases
Re: [SC-L] embedded systems security analysis
I spent a fair bit of time doing stuff relating to voting systems, which all have embedded systems. (I am not one of the experts who pulls them apart, lest anyone think I'm claiming credit for them.) They are supposedly closed systems, but every time someone competent has tried to attack them, they've been successful - even if there are no published APIs or documents, all of them have attack surfaces. It might be something like the ability to insert a card in a PC slot (as in the Princeton attack on Diebold touchscreen systems), a USB stick (some of the UC Santa Barbara attacks - I think that was ESS touchscreen machines), Harri Hursti's attacks via a memory card on Diebold optical scanners, Princeton's attacks via a proprietary memory card on Sequoia systems, etc. (There are others too - the machines in my county use USB sticks and run Windows CE, so I believe they're susceptible to even trivial attacks via an autorun.) I also worked with a team that did some attacks on another embedded system in a voting machine, although we didn't get far enough to publish results before we ran out of students to do the grunt work. So I'd 1000% agree with Arian - not only is assuming you're safe dangerous, but it's also wrong. There's lots of attacks on other types of embedded systems - there have been a few against electric power control systems, water control systems, etc. And there are more that haven't seen the light of day I just heard about a very serious attack the other day that hasn't ever made it into the news. --Jeremy On Thu, Aug 20, 2009 at 2:09 PM, Arian J. Evansarian.ev...@anachronic.com wrote: Rafael -- to clarify concretely: There are quite a few researchers that attack/exploit embedded systems. Some google searches will probably provide you with names. None of the folks I know of that actively work on exploiting embedded systems are on this listbut I figure if I know a handful of them in my small circle of software security folks - there have to be many more out there. Assuming you are safe is not just a dangerous assumption: but wrong. Specifically - One researcher I know pulls boards system components apart and finds out who the source IC and component makers are. Then they contact the component and IC makers and pretends to be the board or system vendor who purchased the components, and asks for documentation, debuggers, magic access codes hidden in firmware (if he cannot reverse them). If this fails, the researcher has also befriended people at companies who do work with the IC or board maker, traded them information, in exchange for debuggers and the like. This particular researcher does not publish any of their research in this area. They do it mainly (I think) to help build better tools and as a hobby. (Several of you on this list probably know exactly whom I'm talking about. This person would prefer privacy, and I think the person's employer demands it, unless you get him in person and feed him enough beer.) If I were a bettin' man I'd figure if I know a few person doing this type of thing for quite a few years now -- there are bound to be many, many more Not sure what list to go to for talks on that type of thing. Blackhat.com has some older presentations on this subject. -- Arian Evans On Wed, Aug 19, 2009 at 8:36 AM, Rafael Ruizrafael.r...@navico.com wrote: Hi people, I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. Or maybe I am wrong, is there a way to grab the source code from an electronic equipment? That would be the only concern for embedded programmers like me, but I just like to learn about the thinks you talk. Thank you. Greetings from Mexico. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at -
Re: [SC-L] embedded systems security analysis
Thank you for all the info you guys have sent, it has been very informative... :) It is harder to steal the source (you need more electronical knowledge and expensive debuggers and stuff) but it is possible... Do you guys know some pages with security tips for embedded systems? ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] embedded systems security analysis
We looked at the problem of voting system security specifically in the context of insider threat for last year's IATAC State of the Art Report on the Insider Threat to Information Systems - some of which involved rogue developers engineering backdoors into such systems. Unfortunately the document is limited distribution and FOUO, so I can't excerpt here. But if you're interested and a government employee or contractor, let me know and I'll get you instructions on how to register with DTIC to obtain a copy. Karen Mercedes Goertzel, CISSP Associate 703.698.7454 goertzel_ka...@bah.com From: sc-l-boun...@securecoding.org [sc-l-boun...@securecoding.org] On Behalf Of Jeremy Epstein [jeremy.j.epst...@gmail.com] Sent: Thursday, August 20, 2009 5:39 PM To: Arian J. Evans Cc: Secure Coding List Subject: Re: [SC-L] embedded systems security analysis I spent a fair bit of time doing stuff relating to voting systems, which all have embedded systems. (I am not one of the experts who pulls them apart, lest anyone think I'm claiming credit for them.) They are supposedly closed systems, but every time someone competent has tried to attack them, they've been successful - even if there are no published APIs or documents, all of them have attack surfaces. It... ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
[SC-L] embedded systems security analysis
Rafael -- to clarify concretely: There are quite a few researchers that attack/exploit embedded systems. Some google searches will probably provide you with names. None of the folks I know of that actively work on exploiting embedded systems are on this listbut I figure if I know a handful of them in my small circle of software security folks - there have to be many more out there. Assuming you are safe is not just a dangerous assumption: but wrong. Specifically - One researcher I know pulls boards system components apart and finds out who the source IC and component makers are. Then they contact the component and IC makers and pretends to be the board or system vendor who purchased the components, and asks for documentation, debuggers, magic access codes hidden in firmware (if he cannot reverse them). If this fails, the researcher has also befriended people at companies who do work with the IC or board maker, traded them information, in exchange for debuggers and the like. This particular researcher does not publish any of their research in this area. They do it mainly (I think) to help build better tools and as a hobby. (Several of you on this list probably know exactly whom I'm talking about. This person would prefer privacy, and I think the person's employer demands it, unless you get him in person and feed him enough beer.) If I were a bettin' man I'd figure if I know a few person doing this type of thing for quite a few years now -- there are bound to be many, many more Not sure what list to go to for talks on that type of thing. Blackhat.com has some older presentations on this subject. -- Arian Evans On Wed, Aug 19, 2009 at 8:36 AM, Rafael Ruizrafael.r...@navico.com wrote: Hi people, I am a lurker (I think), I am an embedded programmer and work at Lowrance (a brand of the Navico company), and I don't think I can't provide too much to security because embedded software is closed per se. Or maybe I am wrong, is there a way to grab the source code from an electronic equipment? That would be the only concern for embedded programmers like me, but I just like to learn about the thinks you talk. Thank you. Greetings from Mexico. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___ ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
