Why waste your time scanning police radio when you can watch live video feeds from American UAVs.  Wired recently published an interesting piece (http://www.wired.com/dangerroom/2012/10/hack-proof-drone/) indicating that half of US drones broadcast their video feeds in the clear.  The strategic disadvantage of letting your opponents know what you are watching and what you can see is clear – so why does such a serious security hole exist?

We would need to know the details of the development of the drone technology to understand how they came to be developed as they were, but the very fact of the hole can give us some indications.  It seems a clear indication of the “security as an afterthought” paradigm, where systems are developed without regard to security, and then security features are patched on after the fact.  Then, of course, under the pressure of resource constraints and time, some things just have to give.  Even if serious consideration is given to security (as one would think it would be in a military environment,) the existing structures may be such that it is extremely difficult or costly to add security features without re-engineering the entire product.  Even when things succeed, there are more likely to be holes, weaknesses, and bugs where the software interfaces with the security modules.

So what is the solution?  Engineering for security from the bottom up.  The base task should be “how do we make this work securely?” not simply “how do we make this work?”  With such an approach, all interfaces and processes are developed to be secure, and the internal design of the system reflects that methodology.  All bugs can not be avoided, but with a well-engineered framework, they can, at least, be minimized and easily remedied.

Our (Kumud & Rishi) final project is to improve the implementation of control flow integrity on LLVM. You could see the project updates at http://cfi.blogs.rice.edu/

Stuxnet and Duqu are two malwares which got into the malware hall of fame in recent years. Some of us might have already read about Stuxnet in the reading list.  Duqu has been covered by a blogger last year.

To recap, Stuxnet dubbed as the “hack of the century” is a sophisticated computer worm which spreads via windows and is known to attack only Siemens industrial software and equipment. The malware with help of two stolen certificates installs itself in kernel mode and gets access to privileged execution. One of the beautiful exploits it can perform is an attack similar to man in the middle attack. It would induce a malfunction in the device but would hide the malfunction from the controller of the device. It would be too late by the time the controller realized the error. Iran’s nuclear facility centrifuges have been among the victims of this malware. The malware attacked the motor controls of the centrifuges and ran them at different speeds there by destroying them. The controller of the motors never saw the variation of the speeds on his sensors. Stuxnet spreads itself via P2P RPC methods.

Duqu came after Stuxnet and is reported to be identical to Stuxnet. Duqu unlike Stuxnet has been designed to provide services like injection tools and information retrieval to the attackers. An attacker can also send a payload via Duqu which can then be used to attack any system. Like Stuxnet, Duqu uses a zero-day-vulnerability of  Microsoft Windows. How Duqu spreads its self is still unknown. One of the key capabilities of Duqu is the ability to steal certificates and make any future payloads to appear as secure softwares.

Flame is a recent malware announced on May 28th, 2012. One of the discoverers claim that Flame is the most complex malware ever found. Flame like Duqu is primarily used for espionage and is capable of recording a wide variety of information which includes screenshots, network traffic and also skype conversations.  It heavily encrypts the data it extracts so that only the attacker can view the stolen data. One of its capabilities is that it can turn an infected computer into a bluetooth device and use it to transmit information to one of the many command centers spread across the world. Fame similar to Stuxnet and Duqu avoids security softwares via rootkit functionality. Currently Flame is  being used to deliver various payloads and is still evolving. It’s full capabilities are yet to be seen.

References:

http://en.wikipedia.org/wiki/Stuxnet

http://en.wikipedia.org/wiki/Flame_%28malware%29

http://en.wikipedia.org/wiki/Duqu

http://en.wikipedia.org/wiki/Rootkit

http://www.pcworld.com/article/2009973/flame-malware-continues-to-burn.html

Please visit our_blog to follow our COMP 527 project. We (Deepak
Majeti and myself, Karthik Murthy,) are working on a set of compiler approaches to thwart ROP.

Deepak Majeti (dm14)
Karthik Murthy(ksm2)

For my analysis of a real world security issue, I chose to cover explosive trace detection in airports. Initially, I had no idea what ‘explosive trace detection’ even was. As a college student flying home frequently for every break, though, I always wondered why TSA was swiping random passengers’ hands and what they were testing for. With some quick research, I found that these tests were part of explosive trace detection techniques, which identify potential threats by catching small residue amounts of explosive materials.

Explosive Trace Detection In Airports

ETD has been used by the TSA in airports since 2010 and is a relatively simple procedure. TSA workers quickly and painlessly swab passengers hands with a testing paper, then insert the paper into an ETD machine, which reports whether or not explosive materials have been detected on the swab. These machines, using technologies like Ion Mobility Spectrometry (IMS), detect trace particles of materials frequently used in explosives. While varying in accuracy, ETD machines are capable of detecting explosive compounds like TNT or RDX in terms of parts per million or parts per billion. ETD machines can also be used to detect other controlled substances, like narcotics, by altering which trace chemicals they attempt to detect.

TSA worker using ETD machine

Security Risks

Because of the purpose of ETD machines, their security risks have much larger consequences. Not detecting an explosive material can lead to passenger deaths, but falsely identifying a passengers as being a threats in too large a number is also unacceptable. The ETD machines can be adjusted to operate at higher or lower sensitivity ranges – at a higher sensitivity, chemicals must be very similar to known explosive materials, while at lower sensitivities, they can differ more. Because of this variance in sensitivity, the ETD machines can falsely identify innocuous substances as threats. For example, many compounds in house-hold fertilizers can also be used in home-made explosives. If a passenger had recently worked in their garden, with a less sensitive ETD test, they could be investigated and searched for bombs.  Conversely, with a too-sensitive ETD test, a passenger who actually does pose a threat could be undetected. ETD machines must also be programmed for which substances to detect and therefore miss any threating substances they are not aware of.

Conclusion

While Explosive Trace Detection technology currently in airports is at risk for false positives and false negatives, I believe that the machines take a step in the right direction for passenger scanning. The tests are non-invasive, and rely on concrete scientific evidence in identifying possible threats. By investing in ETD tests – by swabbing and testing every passenger rather than randomly selected individuals, improving the IMS detection science, and by increasing the number of substances a machine can detect – I believe that the TSA can quickly scan for threats while maintaining passenger rights.

References

http://blog.tsa.gov/2010/02/explosive-trace-detection-usage.html

http://www.fas.org/sgp/crs/homesec/RS21920.pdf

http://www.consumertraveler.com/today/consumer-travel-alliance-on-use-of-explosive-trace-detection-etd-at-airports/

http://onlinepubs.trb.org/onlinepubs/tcrp/tcrp_rpt_86v6.pdf

First off, I’m sorry for not being in class today. My daughter had a fever bad enough to keep her from school.

I just got word that our final presentations, on Tuesday, December 5, 10am-1pm, will be in DH 1075, not in our usual classroom. Thanks!

The experiment by Fu et al [1] that compromised implantable medical devices (IMDs), when published in 2008, gained considerable attention in the medical and security community. Committees were formed to assess the security  of these devices, and news articles[2][3][4][5] ensued highlighting the gravity of the situation. On the other hand, the IMD manufacturers were dismissive of the study. The Medtronic issued a statement saying, “To our knowledge there has not been a single reported incident of such an event in more than 30 years of device telemetry use, which includes millions of implants worldwide”[5]. After presenting the paper by Prof. Fu in class, I became curious about the state of IMD security today, nearly four years after this sensational paper was published. Has the whole issue been swept under the rug?

According to my research, it appears to me that the medical companies have largely continued to follow the same old tactics of providing security by obscurity, i.e. by keeping the software secret. However, the research community have continued to push for new robust technique for medical security. First, there has been several followup publications on different techniques for providing security to these devices [6][7][8][9][10]. As presented in class, the security mechanism for these devices have one challenging requirement, the security measure should in no way compromise the safety of the patient in the case of emergency or failure. Second, there has been an interesting study on incorporating patients perspective into the design of security feature[3]. I discuss below important progresses made in IMD security research that I learned about in my brief survey.

As Fu et. al noted in [6], a business challenge exists in attempting to design a security system for IMD, that is IMD manufactures are not forthcoming about the design of the device and security measures that they have employed. However progresses have been made. A USENIX 2011 paper [7] shows that the highest amount of energy is consumed in RF communication of vital medical signals instead of local calculation of these signals. Hence, they used a low-energy technique called coefficient encryption that significantly reduced the amount of RF communication without loosing vital information and making it slightly more complicated to hack these signals. Likewise, IEEE INFOCOM 2011 paper[8] presents a promising authentication mechanism for emergency situation. On top of the key based authentication during the non-emergency situation, it proposes a two level biometric pattern based authentication for an emergency situation. At the first level, it uses patients biometric information such as height, iris color and fingerprint. At the next level, it uses patients iris pattern recognition. Another technique proposed in IEEE INFOCOM 2011 [9], uses an external wearable guardian to protect the pacemaker in non-emergency situation. In case of emergency or guardian failure, health professionals can use ECG to recover the key shared between the guardian and the IMD. Fu et al [6] provide more on various threat models and list current challenges in implementing security for IMDs for people interested in further research on this topic.

Next, the HCI aspect of IMD is equally important and requires attention while implementing security measures. An important issue is what measures are acceptable to doctors and patients in terms of usability, safety and even appearance. Is a beeping speaker on one’s chest, proposed as one security technique in [1], acceptable to patient? In research conducted by Denning et al [10], they interviewed 13 individuals that had been using pacemakers. They presented various security measures to them: such as password visibly tattooed to the body, password tattooed to the body that is only visible under UV light, wristband that stops all unauthenticated communication unless it is removed, a similar wristband with added functionality such as that makes 911 call in case of emergency, and critically aware IMD that provides access to anyone during the case of emergency. Majority of the participants were opposed to the idea of body modification (tattoo) due to personal values. Behavioral modification (wristband) also received some opposition but extra feature on it made it more palatable. Finally, many individuals were skeptical about the critically aware IMD as they provided access to anyone during the case of emergency. So, all in all, wristband with extra feature emerged as a winner. Some people had problem with it as it disclosed other people and constantly reminded themselves of their condition.

I think this is an interesting design space where more efficient and amenable design is yet to emerge. Now that the FDA has acknowledged that security of IMD is a growing concern[11], I am curiously waiting to see what type of recommendation and regulation FDA would be put in place and what IMD manufacturers would finally incorporate as a security feature.

References:

[1] Daniel Halperin, Thomas S. Heydt-Benjamin, Benjamin Ransford, Shane S. Clark, Benessa Defend, Will Morgan, Kevin Fu, Tadayoshi Kohno, and William H. Maisel. 2008. Pacemakers and Implantable Cardiac Defibrillators: Software Radio Attacks and Zero-Power Defenses. In Proceedings of the 2008 IEEE Symposium on Security and Privacy (SP ’08). IEEE Computer Society, Washington, DC

[2] http://www.sciencedaily.com/releases/2008/03/080312134128.htm

[3] http://securitymanagement.com/news/implantable-medical-devices-hacks-and-countermeasures-008878

[4] http://mullingsgroup.com/the-hack-able-body-are-device-makers-doing-enough-to-shield-patients-from-hackers/

[5] http://www.nytimes.com/2008/03/12/business/12heart-web.html

[6] Wayne Burleson, Shane S. Clark, Benjamin Ransford, and Kevin Fu. 2012. Design challenges for secure implantable medical devices. In Proceedings of the 49th Annual Design Automation Conference (DAC ’12). ACM, New York

[7] Fei Hu, Qi Hao, and Marcin Lukowiak. 2011. Implantable medical device communication security: pattern vs. signal encryption. In Proceedings of the 2nd USENIX conference on Health security and privacy (HealthSec’11). USENIX Association, Berkeley, CA, USA

[8] Hei, Xiali, and Xiaojiang Du. Biometric-based two-level secure access control for implantable medical devices during emergencies. In INFOCOM, 2011 Proceedings IEEE, 2011

[9] Xu, Fengyuan, Zhengrui Qin, Chiu C. Tan, Baosheng Wang, and Qun Li. IMDGuard: Securing implantable medical devices with the external wearable guardian. In INFOCOM, 2011 Proceedings IEEE, 2011

[10] Denning, Tamara, Alan Borning, Batya Friedman, Brian T. Gill, Tadayoshi Kohno, and William H. Maisel. Patients, pacemakers, and implantable defibrillators: Human values and security for wireless implantable medical devices. In Proceedings of the 28th international conference on Human factors in computing systems, ACM, 2010.

[11] http://www.databreachtoday.com/fda-tackling-medical-device-security-a-5210

While browsing the links page to find an interesting article to write-up, I stumbled upon this piece in Threat Post by Dennis Fisher and was intrigued. In the article, Fisher talks about how medical devices, a previously relatively untapped market for hacking, have recently come under attack. Already, pacemakers and insulin pumps have been exploited to deliver lethal doses to their owners, rather than the life-saving functions they are intended for. These new hacks open up a whole new deadly area of security flaws, where a hacker could do much more than just steal your financial information, but actually harm your physical health.

Before reading this article and the presentation in class today, I had never even contemplated attacking medical devices to remotely control their functionality. As the medical industry becomes more technologically advanced, however, it is paramount that security vulnerabilities in life-saving medical devices are addressed and healed. The consequences for a gap in a medical devices security are disastrous compared to any other attack against an individual.

The medical industry as a whole needs a huge upgrade in terms of security. I question whether personal implanted medical devices, like pacemakers or insulin pumps, should even be capable, in their design, of delivering lethal volts or doses.  Out side of the realm of personal devices, other aspects of medical facilities and hospitals are far behind in their security capabilities. As the article mentions, most hospital computers still run on outdated and vulnerable operating systems, enabling hackers to access deeply confidential and potentially live-saving information. Personally, I value my medical information far more than my credit card or browsing data, and it is disturbing to learn that in many ways, my medical information is far less protected.

However, (as we touched on in the presentation today) because of the nature of these devices as being life-saving medical treatments, this causes difficulties in security protocols. A pacemaker, if and when it detects a malicious attack, cannot just stop regulating a patient’s heart, but must continue on as is. On the other hand, in an emergency situation, doctors need to be able to bypass any security measures quickly and easily to make quick calls that could save the patient’s life. More research into the design of a security system with this functionality, though complicated, is absolutely critical as medical devices become more prevalent and common.

I checked the Hacker News everyday and found this interesting post. The idea behind this post is about when you browse the web, you don’t just download the content. You also download the web browser. That sounds scary to me at first, but what this post essentially is trying to convey is that

“the code you’re executing is not important, rather, it is the system API exposed to the code that determines the safety of the system.”

Well, the first thing that popped out from my head is the principle of least privilege when I first read this. Usually in a unix-like system, we have many users and the system admin doesn’t trust them. So the system admin just minimizes the privileges of other users as long as the users can do their work successfully, but why are some bad people still able to hack a unix-like system? Is the principle of least privilege not good enough?

I think the principle is good, but traditionally what people actually missed is the definition of privilege from the perspective of the system. Think about it. It is the programs that essentially talk to the system, not the users. Of course!! That’s why every program in the system is executed on behalf of a user and every user has a unique id that specified what privileges that user has. However, what is the definition of privilege in terms of the system? I think it is the system API.

Therefore, I think the system should minimize the number of APIs each program has access to. Moreover, it should not just be limited to the web domain. It can be used in the OS world also. I’m not an OS person, so I don’t know how much effort it will take. But I can imagine that’s quite a lot. The system needs to be aware of all its APIs and it needs to track all API usages. I think it is not easy to do, because API is quite low-level.

Just some random thoughts. I don’t how how many people have read the Unix-Hater’s Handbook. It is old, but the essence of the book is about the battle between two philosophies. One is “do the right thing” and another one is “bad is better” (I don’t quite remember the name of the latter one, but it is similar to that). So, I doubt  the API privileges thing would be implemented in the short future (if there exists none).

Martha and I will be working on a survey of web servers “in the wild,” hoping to catalog various behaviors that relate to information and network security.  We are hoping that a broad survey will provide useful information about security vulnerabilities as they exist today.  You can find more information (including our proposal) on the blog at: http://comp527f12serversurvey.blogs.rice.edu/