Attack and Defense: Improving Cybersecurity by 2014: Introduction 12/3/04
An Attack in 2014: A Walk Through
The date is October 23, 2014. Rep. Sandra Hill is running for U.S. Senate. The race is tight and could turn on the tiniest misstep. Rep. Hill has a secret: She has been diagnosed with the early signs of Alzheimer’s disease the past summer. Based on her doctor’s diagnosis of slow progression that could also be treated with experimental drugs, Rep. Hill had decided to stay in the race.
Joe Cracker has an agenda: he does not want Rep. Hill elected to the Senate. He feels strongly opposed to most issues Rep. Hill has promoted, especially increased control over rogue elements on the internet. Joe Cracker knows a little about software security and vulnerabilities, and has had plenty of time on his hands. Months earlier Joe, had decided to find embarrassing information about Rep. Hill and publicize it in order to derail her campaign.
On a visit to his doctor, a week earlier, Joe pocketed a small computer memory device that someone had left on the counter. Joe did not expect it to be of much use other than as more portable memory, but upon examining it at home he soon realized that it contained access code to the Central Medical Record Service (CMERECS). CMERECS was created 8 years earlier to allow authorized individuals access to the records of any patient under their care. Joe knew that although his doctor’s office used the latest and greatest patient management application, the application vendor had not updated the encryption mechanism for nearly 10 years. The encryption algorithm was still on the list of approved algorithms for store CMERECS access codes, but Joe knew it could be cracked. Joe set his two brand new high end computers to work cracking the encryption by doing nothing more clever than just attempting every possible combination. Four days later Joe had the access codes. These access codes allowed him to connect to CMERECS and request the medical records for anyone in the nation in a way that the requests would appear to have originated from his doctor’s office. Under normal conditions the patient’s approval would be required before the records could be released to a doctor, but the system had a loophole. For emergency services no approval was required. Joe requested the records for Rep. Hill using the emergency request procedure.
With the medical records in hand, Joe embarks on a plan he spent the last several months preparing; he will distribute Rep. Hill’s medical records using a worm that attacks cell phones. Joe has a built a network of vulnerable cell phones with the help of a “surreptitious worm” [XVIII] that spreads slowly from cell phone to cell phone by keeping a low profile and piggy backing on the phone users regular phone usage. Thanks to this behavior, the worm has thus far been able to avoid discovery, but that will change once Joe triggers it into high gear.
This initial worm, which Joe named PrepBoy, takes advantage of an unpublicized vulnerability in the operating system used in several data capable cell phones. As the worm spreads it sends other cell phones a message saying an update for the cell phone is available. Included in this message is a malformed value for the expected size of the update. This malformed value causes the cell phone software to attempt to contact a backup site listed in the original message. Joe included an address to an anonymous website on which he had previously placed his payload (a copy of PrepBoy). When the cell phone downloads PrepBoy, assuming it is the official update, the second vulnerability, a buffer overflow, is encountered and allows PrepBoy to take over the cell phone. Once on the phone, PrepBoy attempts to spread itself by sending a copy of the update message to other cell phone numbers that it has gathered from the cell phone’s address book or numbers within the same telephone exchange. In order to avoid detection it only sends a few of these messages at a time, and only when the cell phone is connected to the data network as part of the user’s regular activities.
With this network in place, Joe sends a message exposing Rep. Hill’s Alzheimer’s diagnosis and a copy of the medical records to the set of infected cell phones to which he initially sent PrepBoy. Upon receiving this message, PrepBoy notices a key word and kicks into high gear. It begins to blast the received message to all the other cell phones it has infected which in turn forward it to all the phones they have infected. This blast quickly grows into a tidal wave reaching all infected cell phones within minutes. The message also triggers another change in PrepBoy: PrepBoy starts to forward the message not only to other cell phones, but to any email address it finds on the cell phone.
Within a couple hours, not only the most vulnerable cell phones in the state, but also within the whole country have received the message. There is public outcry not only about the massive traffic generated by the worm, but also about Rep. Hill’s decision to run for office even after she was diagnosed with Alzheimer’s. With less than a week left before the elections, Rep. Hill’s support drops dramatically and her opponent wins by a landslide. Joe’s plan has succeeded; he has effectively ended Rep. Hill’s career.
The ease of exploits like this one will encourage more and more Joes to test the ability of software makers to provide secure software in the coming decade. Policy-makers must understand the limitations in our ability to make secure software and what we can do to change this situation.
In this paper, we explain to policy-makers what forces could be brought into play to improve computer security. We begin by evaluating the problems we're facing when it comes to computer security: we look at past, present and future threats. From there we offer the policy-maker a range of possible solutions for improving security, from technical, to policy to economic so the policy-maker is well-briefed in the various ways security can be improved. Our first solution is a technical one: we survey promising areas of research in designing secure systems and assess costs and benefits of these approaches. We then consider a policy solution, namely whether software engineering should be licensed as civil engineering is licensed. From there we look at liability: can you hold software vendors liable for their products? Finally, we conclude with a look at how we can design an independent lab to certify software. This lab would be useful because if the consumer could understand security via common, easily-understood ratings of how secure the software they buy is, this would encourage consumer demand for security. In concluding, we offer thoughts on how policy-makers might direct their dollars and law-making ability toward improving software security.
