Defending Against an Internet-based Attack on the Physical World - PDF

Please download to get full document.

View again

of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report
Category:

Healthcare

Published:

Views: 3 | Pages: 8

Extension: PDF | Download: 0

Share
Related documents
Description
Defending Against an Internet-based Attack on the Physical World Simon Byers AT&T Labs Research 180 Park Avenue Florham Park, New Jersey Aviel D. Rubin Johns Hopkins University Information
Transcript
Defending Against an Internet-based Attack on the Physical World Simon Byers AT&T Labs Research 180 Park Avenue Florham Park, New Jersey Aviel D. Rubin Johns Hopkins University Information Security Institute Baltimore, Maryland David Kormann AT&T Labs Research 180 Park Avenue Florham Park, New Jersey ABSTRACT We discuss the dangers that scalable Internet functionality may present to the real world, focusing on a simple yet impactful attack that we believe may occur quite soon. We offer and critique various solutions to this class of attack and hope to provide a warning to the Internet community of what is currently possible. The attack is, to some degree, a consequence of the availability of private information on the Web, and the increase in the amount of personal information that users must reveal to obtain Web services. Categories and Subject Descriptors H.4 [Information Systems Applications]: Miscellaneous General Terms Computer Security, Internet Threats, Automated attacks Keywords Comuter Security, Internet Threats, Cybercrime 1. INTRODUCTION One of the things that makes attacks on Internet services more dangerous than attacks in the physical world is the automation that is possible in the world of computers. An example of this can be seen in the resistance of many to move elections online. The worry is that in the physical world, attacks do not scale very well, but as soon as a physical world process is moved online, malicious parties can potentially exploit vulnerabilities in an automated and exhaustive fashion. All of the published studies related to online elections come to the same conclusion. Namely, that the technology is not ready for Internet voting, and that at this time, the security risks are too great [6, 14, 13, 9]. We believe that the risks of online services are not limited to electronic voting. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. WPES 02, November 21, 2002, Washington, DC, USA. Copyright 2002 ACM /02/ $5.00. Over the last several years, we have enjoyed several new Internet services that have dramatically improved our quality of life. The most obvious examples of these are search engines, whose indices cover just about any information that is known in the world, and Web portals, which provide a window to the wealth of information and services available online. In this paper, we demonstrate that we have been living in a state of bliss, spoiled by the lack of any concerted attacks that utilize these new services, search engines in particular. We demonstrate that the current Internet services offer an avenue of attack against physical world processes, and we argue that the only means to defend against these attacks is to dramatically alter the functionality of services such as search engines, to the point where they becomes much less useful. As more organizations move online, and real-world processes become automated, it is inevitable that more personal user information is stored in databases. There are companies whose business it is to harvest this information, crossindex it, and compile lists of people and information about them. This information can consist of medical history, personal buying habits, grocery purchases, as well as a history of browsing sessions. The automatic nature of data collection, as well as the ability to invoke programmable scripts against this data makes for an unfortunate environment for users concerned with their personal privacy. While we concentrate on an example involving search engines and a post office, we recognize that our discussion is but one example of a general vulnerability. As more functionality moves online, and as more services are automated, there is a greater risk that cyber attacks can cause problems that are manifested in the physical world. Defending against these new attacks often requires taking large steps backwards in the convenience offered by technology and often introduces compromises of personal privacy. 2. A WORD ON DISCLOSURE As security researchers, we often find ourselves faced with a dilemma. When we discover a serious flaw that leads to a vulnerability, do we disclose it to the world, or do we sit on it with the hope that nobody will use it to launch an attack? Our philosophy is that each case needs to be handled independently. If one conceives of an attack that is not likely to happen on its own, and for which there is no prevention, then it is irresponsible to advertise it, and even worse to provide a recipe or exploit code. However, there is also a risk in not disclosing vulnerabili- ties for which there are known solutions. By not educating people who are in a position to defend against an attack, it can be more damaging to bury knowledge of a vulnerability than to announce it. In all cases, sound judgment must be applied and a decision made as to how to minimize the likely effect of the vulnerability. We first conceived of the attack in this paper in September of 2000, but until now have chosen not to publicize our work. The recent availability of an Application Programming Interface (API) for search engines makes the attack much more likely. In addition, we have developed enough countermeasures, that we feel that the disclosure of this paper is important so that proper steps can be taken to prevent the attack from happening. Not everyone will agree with our decision to disclose the attack, but if we knew about it and did nothing, and then the attack was launched, we would be guilty of negligence. It is our judgment that the time has come to reveal this threat. 2.1 Search Engine APIs Recently search engines have launched developer APIs, as front ends to their databases. We believe that this has important effects relevant to the attack presented here: It will cause people to think more about the legitimate and nefarious uses of programmatical interfaces to Web indices. It implements a programmatical interface to search engines. It facilitates access to private information about people. It is the release of developer APIs and their facilitating of the attack that convinces us that it is time for disclosure. A press release has claimed 10,000 developers signing up for use of a particular API and release of attack in executable code form would lead to millions of people being able to run the attack as script kiddies. 3. THE ATTACK The attack involves causing large amounts of physical junk mail to be sent to a targeted individual at their physical address. We describe this attack by walking the reader through its implementation. This consists of using three simple tools that we wrote, and applying them to Web pages written in HTML, utilizing the HTTP protocol. The three tools are a URL search interface, a HTML form parser and a HTTP request constructor/submittor. In general using tools such as these leads to powerful analysis methods and can also be used to quickly build new and interesting Web services. As with all powerful tools there tends to be the capability for so called dual-use, where one of the uses is potentially damaging or subversive and the other is too good to live without. We have found uses for these tools in such diverse areas as Internet topology measurement, fraud detection, business process monitoring and infrastructure analysis, all of which can bring great gains to businesses willing to employ sufficiently skilled technical staff. The attack described here is a prime reason for wishing to restrict general use of personal address data, whether it be telephone number, snail mail addresses, or even IP addresses and addresses. 3.1 URL searching This tool is simply a programmable interface to a major search engine. It allows Web searches to be made and large amounts of results to be processed automatically by other programs. As an example, we search for the terms request+catalog+name+address+city+state+zip. This returns thousands of business catalog request forms that exist on the Web. This is a standard tool in any serious online data mining analyst s toolkit, and the versions we use generally output URLs on stdout for use in Unix pipelines. A simple yet functional instance of this tool can be written in fewer than 100 lines of Perl. We frequently use more subtle and complex versions but have not developed our tools beyond standard for this application. Figure 1 shows sample output of this search. 3.2 Form Parsing The results of the search are then processed by a standard form parser, the second tool. This takes each URL passed to it, performs a HTTP GET request to retrieve the content and then analyses the structure of the HTML to extract the URLs of any form resources, along with their advertised and hidden inputs. All such forms found are then stored in a standardized manner to be passed on for further processing. Figure 2 displays the Web page found at the url This is the highlighted URL from the list of URLs in the example in Figure 1. (We have altered the domain name for demonstration purposes.) Figure 3 shows the representation our tool constructs of the form to be found in our sample Web page. The first line lists the HTTP method and resource URL, while subsequent lines show the various inputs which are recorded showing their type, name and possible or default values. Note that this entirely typical catalog request form is easily machine parsable and even gives the option of sending more than one catalog to the victim. The form parsing program is a standard tool that we use in various legitimate applications and is also approximately 100 lines of Perl. Professional spammers employ sophisticated programs of this nature in their address gathering activities. 3.3 HTTP POST request submission Now, given each of the forms found and documented in the previous steps an attacker can submit data of his choice to each one. The attacker takes a given name, address, city and state and for each form, then builds and submits the POST request, filling in the victim s personal information into the correct boxes. Note that the construction of these Web requests does not have to be perfect. For example, not all inputs need to be filled out in the form, only those that are required for processing or proper addressing. The generated Web requests then trigger each of the respective companies to mail out a physical catalog. The use of the victim s telephone and fax machine in rich cases such as the example form above provide an additional avenue for attack. Following is some sample code, written in Perl, and using the LWP module, that constructs and issues the HTTP POST request that submits a name and address to the catalog request resource shown in Figure 2. This is a hand configured example to illustrate the method and would not Figure 1: The output of a scripted catalog request page search. The highlighted URL is used in our parsing example. be used in a mechanized attack. We have formatted it for easier reading but it is really only three lines of code. It shows us filling in only the information that we think would be needed to actually get the catalog sent. It is probable that many forms on the Web are filled out to this level of incorrectness during real human submissions. $url = ; $req = POST $url, [ FNAME = $victims_name, company = $victims_name, Address1 = $victims_address, City = $victims_city, State = $victims_state, Zip = $victims_zip ]; $webdoc = $browser- request($req); The ability to construct arbitrary POST and GET requests is a commonly used functionality for data gathering and analysis on the Web. It can be done in just a few lines of Perl using standard modules and can yield many useful functionalities, including spoofing browsers, circumventing Javascript checks and impersonating an individual through cookie manipulation. These techniques are commonly used in streamlining power usage of the Web and also allow greater freedom for individuals who wish to avoid the arbitrary privacy invasion practiced by many Web sites such as third party ad providers. 3.4 Variations The attack presented above targets an individual by causing a large volume of junk mail to arrive at a particular address. A more sophisticated attack targets the post office infrastructure itself. Such an attack could utilize an online telephone directory service to target many individuals who live in the same area and share the same post office. Such an attack could severely interfere with the ability of the post office to handle regular mail. A scenario could be imagined where an attacker would do this to delay the arrival of an important letter, to wreak havoc on the postal system for political reasons, or even worse, to serve as a diversion for a terrorist act, such as the mailing of a contaminated letter. Another variation on the attack has the potential to cause specific emotional distress to targeted individuals. In this scenario, the attacker picks a victim with a particular belief, or of a particular group such as a race or religion, and performs the attack where the mail that is sent is material that is known to be offensive to the particular group. For example, one could imagine a scenario where a malicious attacker with personal knowledge of the victim causes colorful literature on gourmet chocolates to be sent to the house of Figure 2: A catalog request form shown in the Netscape browser an obese person on a weight loss program. The reader can imagine more serious scenarios. Such attacks could be very damaging and cause unimaginable distress to the victim. A more whimsical use of this for an unspecified victim might be to send a wave of gardening catalogs, followed by cookery and finally by weight loss, each spread out over several weeks. Variations in implementing the fundamental search also exist. We note that spidering a business directory or Web portal such as Yahoo! and parsing the listed business home pages for links to catalog request pages can also be quite fruitful. Many tools exist for dissecting HTML to the desired granularity. Launching the attack with a subtle crescendo rather than a sudden impact may also have serve to hide the attack. The victim may never even realize that they are the target of an attack, but may occasionally remark on how much junk mail they seem to be getting recently. The basic problem is that the convenience and rich functionality of the Web and its applications have the potential to seriously disrupt our world and our way of life in ways that are becoming easier and easier to implement. In particular, as discussed in Section 4.1, the attacks can be carried out so that the initiator is virtually undetectable. 3.5 Detecting an Attack Early detection of the attack is non-trivial. Sophisticated traffic analysis running at or near the launch point could sound an alarm, but may not be able to prevent it. To combat this, subtle timing and proxy usage variations could be easily employed by the attacker, we have developed and tested such technology already. It is likely that the postal delivery worker responsible for final delivery would be the first person to notice what is happening, by which time it is far too late to employ much prevention. We anticipate that the recipient would receive catalogs according to some form of dispersed time transfer function, rather than all on a given day. This is because of variations POST select State WI MS OR MT KY DC UT DE WV LA WY PA NC ND FL NE NH VA NJ \\ RI NM TN CA NV NY GA VT IA TX AL ID MA 0 MD CO ME AR IL SC MI SD IN CT\\ OH WA OK AZ MN MO KS TEXT TITLE TEXT FNAME RADIO associatecontact Yes No TEXT TEXT phonepfx select qtycatalogs TEXT FaxPfx TEXT phone3 TEXT LNAME TEXT phone4 select WhereShopped Store Catalog\Delivery Service Both n/a TEXT Fax3 TEXT Fax4 select employees TEXT Zip select Country USA select Aboutwhitehat PC SR BC SS V F EC Y CF VS IR N/A O TEXT company TEXT Address1 TEXT City select SicCode a 91 72b n/a \\ a b 49a 86 49b 87a 87b 87c 87d select CatalogType BSELL FURN BGUID N/A Figure 3: The representation of our tool on a form found on a sample Web page. in the processing of the mailout requests and also the distance they have to travel. It is, though, quite conceivable that a massive number of large pieces of mail could arrive on a given day, dependent on the size of the initial attack. Physical disposal of the mail may prove to be a problem depending on the nature of local recycling facilities. We also note that due to mailing list resale there would be a secondary wave of mailings that would continue for quite some time and that once the name and address combination is tarnished by this attack it might never again be free from junk mailings. 4. ANALYSIS OF THE ATTACK We conducted some simple tests to gage how well the attack would proceed if launched. A key step where the attack could fail is HTML parsing for form structures. The reasons for this are twofold. First the form might not have fields that an attacker can automatically recognize and use, and second, HTML can be written in various ways that defy some parsers. In tests, our stock form extractor yields actionable results for around 78 percent of candidate Web pages from a relevant search. For these tests we define a form as actionable if we can extract all of the apparent address, city, state and zip code fields via a simple regular expression match on the stored form schema. We did not tune our form extractor for these types of forms in this case although we have done so, with good results, for legitimate applications. 4.1 Tracing the Attacker This attack can be launched in a way that makes it hard to trace by loading the required software onto a floppy disk thousands of different places distributed in space, through jurisdictions, and across the Internet. Prevention would be very difficult even given the URLs of all the catalog request forms hit. Traceback of the attack once detected at the endpoint is simple enough given merging of Internet server logs, but that only gets the launch point. Another possible sanitized launch point is a drive-by launch that uses various open b networks. Some major cities have several hundred or even thousands of open access points which one might distribute traffic amongst. If the launch access method is anonymous then the perpetrator can only be traced through any existing connection with the victim, i.e. the motive for the attack. If the attack is random, as many Internet DOS attacks may be, then the perpetrator stands a good chance of remaining unidentified. Another way that the attack could be hidden is if the Web requests are launch using a Web anonymizing tool such as Crowds [12] or Onion Routing [10]. These tools provide a layer of anonymity for Web requests, in effect shielding the identity and location of the requester from observers on the network and end servers. 4.2 Recovery from the Attack and paying cash for a few minutes on a machine in a cybercafe. It can be instantiated with multiplicities of tens of thousands quite easily. Once launched it is very difficult to stop as the attack invokes semi-automated processes in A primary goal of the victim after attack detection and initiation of traceback is prevention of further mail. This should prevent repeat mailing by the primary attack points and also help stem the secondary mailing lists those who purchased the name and address from the first wave. Informal research we have conducted into systematic mailing list name removal suggests that removing one s name from a large number of lists is an extremely frustrating and time consuming task. Frequently the removal mechanisms are obscure or inaccurately documented.
Recommended
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks