The Internet is now the world's most popular network and it is full of potential vulnerabilities. In this series of articles, we explore the vulnerabilities of the Internet and what you can do to mitigate them.
In May (or so) of 1995, I was discussing potential attacks against the key generation processes used in PGP, and the issue came up of how good the pseudo-random number generator (PRNG) was and whether it could be exploited to break PGP encrypted or signed documents. I got a lot of Email abuse and was called many names for bringing this issue up, but as a side effect, people in the cypherpunks Internet mailing list started to look into this class of attacks. By September, it was discovered that Netscape's SSL protocol implementation was based on a poor PRNG, and that Netscape's so-called secure messages could be broken in a minute or two on a PC.
In September or October of 1995, in that same list, I was engaged in a heated debate about the dangers of Sun's new Java system for permitting Web browsers to automatically run programs provided to them by untrusted servers. I have serious concerns about systems that allow users, at the push of a button that's not even differentiable from any other button, to run programs specified by unknown third parties. As the debate heated up, I posted a half-humorous article titled something like 50 ways to attack your Java. The name was a take-off on Paul Simon's song 50 Ways to Leave Your Lover. The content had some serious scenarios, most with results I though to be somewhat humorous (e.g., displaying a Mickey Mouse watch on the screen with the wrong time).
As a result of this posting, I got a lot of electronic abuse. List members cast aspersions on everything from my character to my sex life, including but not limited to claiming that I knew nothing about security, that my doctorate came from a mail order house, and probably that my mother wore army boots. I recalled a line from a movie (I think it was from Heaven Can Wait) that went something like:
It was several weeks later that I was contacted by the Computer Security Institute and asked to give a presentation on Web security in a plenary session at their semi-annual conference in Washington, D.C. It seems that they had a lot of interest in Web security, that one of their editors had seem my 50 Ways posting, and that they wanted me to give a presentation on 50 ways to attack the Web. With only a week before the conference and other work to do, I was now faced with coming up with 50 real attacks that could be used against the Web.
Having accepted the invitation and just having finished my draft version of slides late last night, I awakened this morning to the realization that the conference will make it impossible to finish my Internet Holes article at my regularly scheduled time (which should be next week). So I decided to move the other article I was working on to January and make this month's article coincide with the 50 Ways talk. Here we go:
The World Wide Web (a.k.a. the Web, WWW, or W3) may be the most widely used information system ever. There are claims of about ten million regular users, and many sites now claim to process more than 100,000 requests per day. The Web is comprised of a highly distributed set of tens of thousands of information servers, an unknown number of freely available browsers, and the Internet which facilitates its operation.
Nobody owns the Web. Individual servers and browsers are owned by anyone who wants to make them available or use them. There is no central coordinating body, but there are some standards committees that try to augment existing protocols with highly flexible protocols to enhance function (usually at the cost of everything else). Information in the Web comes in many forms, but it is primarily in the form of Hyper-Text Markup Language (HTML) documents. The way it all works is:
If this seems overly simple, it's not. We implemented a secure Get-only server in a few hours, and an insecure one can be implemented in a minute or two. Here's an example Unix shell script that (sort of) works (but it's VERY insecure):
read a b c cat $bTo use it, you have to make this the listener on port 80 (via the inetd program under Unix). It takes a few minutes - but don't do it. It's really very risky.
To make a minimal browser, the following Unix shell script will get the information if you provide the URL, HOST, and PORT:
(echo "get URL http";sleep 10) | telnet HOST PORTTry "/" for the URL, "all.net" for the HOST, and "80" for the PORT as an example.
Vulnerabilities of the Web, as a system, can be considered in terms of three different classes of attacks:
Another perspective on vulnerabilities of the Web considers four different sorts of harm, several of which may be active in any particular attack:
Yet a third perspective looks at the fundamental issues of the design of the Web:
In summary, the Web is a system that was never designed for protection and that is being implemented in the most hostile of environments with a completely untrained and unaware user base as a basis for a global system for distributed computation and electronic commerce. It has inadequate protection for integrity, availability, and confidentiality, it may introduce large liabilities to both providers and users, it is vulnerable in each of the three aspects of its operation (browsers, servers, and networks), it has fundamental design flaws that make it inherently difficult to protect, and it is being implemented on an unprecedented scale in a very short time frame almost entirely by people who do not understand the protection issues.
These example attacks come in three types. Attacks marked with a * have been demonstrated. Attacks marked with a *+ have caused real-world incidents. Unmarked attacks are theoretical but are very likely to work. Since the goal is 50 attacks and some of the theoretical attacks may not be active today, we have provided 60 attacks under the assumption that this redundancy will cover any attacks that are never demonstrated.
These attacks work against browsers, the user programs that present information and allow the selection of new URLs.
Postscript is an interpreted language originally designed to provide a printer-independent language for printing complex documents. Because it is a general purpose programming language with input and output, any Postscript document acts like a program when interpreted. This leads to any number of possibilities, a few of which are listed here.
1) Postscript file overwrites key files*: Postscript files can contain commands to open, create, copy, delete, or rename files. If you are using a browser that displays Postscript files and you view a postscript file, it could overwrite any files on your system, including configuration files used to open your system to other attacks.
2) Postscript file introduces Trojan*: A more advanced form of a Postscript-based attack could be used to introduce a Trojan horse or virus into the computer running the browser.
3) Postscript file transmits secrets over port 80*: A still more advanced Postscript-based attack would use port 80 (the HTTP port) to transmit internal information to the attacker. This can be done even through a firewall because firewalls that allow HTTP to pass have no secure way to determine the difference between a legitimate HTTP message and an illegitimate one.
Dirty pictures aren't a very important threat against most businesses from a standpoint of lost revenue or competitive advantage, but they are a potential source of liability, they are potentially demeaning to the group to which the pictured persons belong, and they are usually not part of a legitimate business function. In cases where underaged recipients are involved, they are often also illegal.
4) Postscript file has dirty pictures*+: Since Postscript is a general purpose language, it can be used to display dirty pictures.
5) GIF file has dirty pictures.*+: A far more direct route is to use the GIF format which almost all Web browsers support. Since, in many browsers, GIF files are simply displayed by default as they show up, you never know what the next button-push might produce.
A common complaint of clients is that users use the Web in many ways that are counterproductive. Some examples may help to clarify this.
6) HTML file describes how to make money by leaking secrets.: Many people offer money in exchange for trade secrets, but unless you are looking for ways to sell trade secrets, you are unlikely to come across them - except on the Web. Either as jokes or as real solicitations, several Web sites have openly stated that they provide cash for confidential information.
7) Inbound information is false and misleading.*+: Many users trust information retrieved from the Web in the same way as they trust information on the evening news or in the library. It is quite common to find false and misleading information throughout the Internet, and the Web is no exception.
8) Users waste all day looking at Web stuff*+: A common event in many organizations that have recently introduced the Web is its extensive use at the expense of employees fulfilling other job functions.
9) New executables loaded via the browser*: Programs loaded from over the Web are no more safe than programs loaded from the local bulletin board. In fact, they may be far more dangerous, and in some cases, have been specially designed to compromise security.
Aplets are the names for Java programs that can be automatically loaded onto your computer and run at the push of a button when you use a Java-based application. Since selections that run aplets look like any other Browser selection, you cannot tell whether any particular button push will run an aplet or not. Since Java is a general purpose language, aplets can potentially do almost anything. There are some security features in the language meant to prevent certain types of threats, but they have not been demonstrated to be effective in any current implementations and, perhaps more importantly, they only address a small portion of the threats we consider.
10) Introduce Trojan Horses*: A Java aplet may be advertised as one thing but actually be something else. For example, an aplet that claims to be a search engine for electronics products from the whole Internet may only provide products distributed through one distributor.
11) Introduce viruses: A Java aplet is capable of reproducing itself and sending itself back out over the network. This makes network-based viruses with Java a real possibility.
12) Send your information out: Since aplets are general purpose and linked into standard libraries, they may fool your users into selecting filenames which are then transmitted out of the company.
13) Redirect request through attacker*: Aplets can also be used to redirect requests so that they go through the attacker rather than to normal locations they appear to point to. The allows the attacker to watch and modify all traffic in both directions as long as the user is pressing buttons within the display area of the screen.
14) Consume bandwidth with big downloads*+: While the user is looking at the screen, an aplet can be silently sending large amounts of information between the server and the browser. This can be done without interfering with the display, and can result in a lot of bandwidth being consumed.
15) Trick the browser into routing into your network: If you can get the user or the browser to output to a file on the browsers computer, you could overwrite a configuration file that would route all traffic through the attacker's computer. This would give the attacker unlimited control over access and content.
16) Forge look and feel of internal machines and gather information*: By making an external server appear to the an internal server, a user could be fooled into doing internal work (such as entering information into confidential databases) through an external system. One of the attacks listed above was to cause HTML information to be redirected through attacker's computer.* This could have many implications:
17) Get usage statistics*: It would be simple to gather usage statistics to see how much you use the Web, which sites you tend to visit, and what you usage pattern is like.
18) See what you are investigating today*: A more detailed investigation attacking many browsers could be used to get intelligence on what your company is researching using the Web. A more active attacker could modify information provided to you in order to manipulate your actions.
19) Take credit card numbers: If you use credit card or charge numbers through a Web server, redirected requests could give away this information to an attacker who could exploit it for financial advantage.
The rest of these attacks are selected from my archives of nasty things people have done to each other with computers and adapted to the Web environment.
20) Forge Netscape-like E-mail from the boss.: If you use Netscape for your Email services (or any other Web-based mail system), an attacker can easily forge electronic mail, making it seem like it is from the boss. Similar email attacks have been used successfully before, but I'm not aware of any through a browser-based Email interface yet.
21) Crash the browser/PC with a big URL.*+: We have a test for this on our Web site. At the press of a button, your browser crashes. It works on many browsers, and in some cases, may even crash the computer the browser is running on. Do a backup first.
22) Cause flashing displays at seizure rates.*: Because Java and Postscript are general purpose languages capable of altering the video display over time, it's possible to create flashing displays at rates that can induce epileptic seizures. This could also be used to introduce subliminal messages.
23) Send personal (naked) video mail to mail list.*+: At least one case of video Email resulted in widespread distribution of naked pictures. A woman apparently pushed the wrong button and sent her Email to a large mailing list instead of her significant other.
In today's environment, there is a great deal of concern over children using the Internet where, like every other part of modern society, there are bad actors with an eye on children. The Web can be used to solicit children:
24) to buy things.*: Just like modern kiddie commercials, the Web can be used to convince children to purchase things.
25) to sell things.*: Unlike most normal television advertisements, the Web can be used for exchanges, including getting children to sell things for money. What they might sell is left to the readers' imagination.
26) mom's not at home.: A burglar or kidnapper could use the Web to find out from children about their household schedules, and exploit this information in order to reduce their risks of being caught at bad acts.
27) to be in pornographic films.: One of the things children might be solicited to sell would be the use of their bodies.
Servers have weaknesses too. We'll give some examples of weaknesses found in servers several times over the last year and augment them with the selections of how they might be exploited.
By overflowing input buffers, many programs can be caused to overwrite data and/or programs with user-supplied information. This is particularly dangerous in a networked environment because remote users may gain illicit entry, thus bypassing normal controls.
28) Crash Web services*+: It's relatively easy to cause denial of services by simply overrunning input buffers and thus placing arbitrary characters into the executable code of the server. Eventually, this will almost certainly lead to a crash.
29) Corrupt server info*+: You can almost always corrupt information being provided by the server to browsers.
30) Tunnel an IP channel*: With a substantial amount of effort, the server software can be forced to open up an unlimited set of IP services, all operating within TCP port 80, the port normally used for Web service.
31) Springboard attacks*: A completely different sort of attack modifies the server software so that it acts for the attacker as a platform for launching further attacks. These attacks can be aimed outward toward external hosts, or inward, toward internal hosts.
32) Attack firewall*: For example, a bastion host Web server can be turned into a system designed to bypass the effect of the outside router in a firewall. It can also be used to launch attacks against the next level of protection, to observe or disrupt network traffic in the firewall network, or in the case of firewalls with only a router, to bypass the firewall completely.
33) Get password file*+: If the Web server is taken over, it may be possible to send out its password file. This can be used to determine passwords that may be common to the organization or firewall, or in the case of a time-variant password, to provide the algorithm and key required to forge these codes.
34) Crash whole server*: It is often possible to deny services to the entire server or even the network it operates on by taking over the Web server.
35) Create reentry holes*+: It is commonplace to corrupt information on the server to permit subsequent reentry.
36) Destroy audit trails*+: Attackers have used the privileges gained by taking over the server to destroy audit trails that might indicate details about their activities which might be used to trace the attack.
37) Change access lists*: Some web servers use access control lists to limit usage by different remote users. This mechanism has its own weaknesses, but even the limited protection afforded by this technique can and has been bypassed by an attacker.
38) Rewrite home page*+: it is fairly commonplace for attackers to rewrite the home page of the organization under attack. Attackers seem to believe that this is an improvement, but most of the improved sites don't seem to believe the same thing.
One of the most useful capabilities provided by the Web is the ability to process inputs sent to the server using a Form. Forms are used to provide fill-in blanks that browsers allow the user to enter information in. The information is then sent to the server as part of a post request, and the server processes the request using its own programs. These programs are commonly called CGI scripts. The vulnerability is that the programs processing requests are often insecure, and thus the inputs provided can sometimes trick these programs into granting unlimited access to the attacker.
39) Get "hit" records*: The list of accesses to the server are commonly readable from the CGI programs, and attackers can send this information out so as to provide detailed logs of system use.
40) Get private keys*+: In many cases, CGI scripts implement cryptographic transforms, such as authentication used for trusted transactions processing. Attackers have used CGI script holes to transmit these keys to attackers for subsequent use in reading and/or forging messages.
41) Take credit card numbers*: In some implementations, credit information is stored on line. An attacker who bypasses protection can sometimes get credit information stored from previous transactions.
42) Have goods sent: In systems that take orders, bypassing the scripts often allows the attacker to add orders to the list of goods to be shipped.
43) Redirect shipments: An attacker can also change addresses for goods already ordered, thus causing the goods to be shipped to the wrong address.
44) Delete records*+: An attacker wishing to cover track might add new order records and delete old records. A competitor might be satisfied with merely deleting your orders.
45) Duplicate shipments: An attacker that can delete or add records, should also be able to duplicate them.
46) Change catalog: It should also be feasible to alter on-line catalog entries to remove products, change what is said about products, or otherwise alter the catalog.
47) Copy your setup: If it cost you money to create your server, others may want to get the information without paying for it. Copying a Web setup is usually quite simple once the system has been entered.
48) Get your price lists: Sometimes companies have different price lists for different clients. It could be very dangerous if an attacker found these price lists and exploited them.
49) Forward illicit mail*: Some people who want to remain anonymous use automated remailers. By installing the remailer on your computer, they use your system to conceal their identity.
50) Resend stolen info*+: In some cases, illegally obtained copies of software packages are placed on vulnerable sites to act as repositories for illegal use. This is done with illegally obtained credit card numbers as well.
The network that the Web runs on is primarily the Internet, and the Internet has ineffective protection across the board. Although I have now met the promise of 50 attacks, I'm throwing these ten in for free.
51) Overload the server with unterminated inits.*+: The Web uses TCP to transport information, but the design of TCP has a flaw. When a session is initialized, it takes a request, a confirmation, and a synchronization before things get going. If the attacker sends a request, and the server responds, there is no specified timeout for the third part of the protocol. By not sending the third message, the server waits forever for the message to proceed. Servers have limits on the number of processes that can be in this state at any given time, so by doing the same thing that number of times, all further TCP ports opens to Web services will fail until the system is rebooted.
52) Rewrite URLs on the fly to redirect requests.*+: Once a request comes through a server, that server can start to act like a gateway for further requests by rewriting URLs. For example, if it has a list of other servers and you select one, the self-declared gateway can write the address of the requested URL as a fake address in the gateway server. As it handles the request for you, it can rewrite each URL in the documents you request to continue routing all service through the gateway. Arbitrary corruption, denial, and leakage can be implemented with this technique.
53) Record all user's Web transactions for intelligence.*: If your computer is in the path between any other server and browser, you can record all transactions passing through your system and use the information to determine usage patterns indicative of strategic planning.
54) Send files that crash readers.*+: Anyone in the network can potentially introduce a packet into a TCP channel to cause a browser crash in response to a request.
55) Send files that violate the law by possession.: For example, you could send credit card numbers to be put into a server for subsequent use.
56) Send programs that create IP tunnels through firewalls on port 80.*: If people use the Internet to load programs (for example the real-audio program is loaded over the Internet), it is possible to introduce a Trojan horse that creates an IP tunnel (similar to an application gateway used in a firewall) to allow unlimited IP access between the Internet and internal networks.
57) HTTP pointer loops that cause numerous reads and crash connections.*+: Since HTTP files can cause automatic browser-side loading of other HTTP files, it's possible to create an infinite loop of files that never stop loading information.
58) Implementation inconsistencies that cause illegal URL requests.*+: Many browsers have implementation errors that request incorrect URLs (i.e. they have an illegal syntax). These can cause server crashes, fail to return the proper data, or cause denial of services.
59) Huge files with very little content over low speed communications links.*+: It is not unusual to get into conditions with some browsers where a download cannot be stopped and runs for a long time.
60) Send 40 requests in 60 seconds: 10 min denial.*+: Many servers have limits on the numbers of TCP channels that can be created per unit time. These limits cause temporary denial of service in order to prevent infinite loops from overrunning server resources. By sending 40 requests in 60 seconds to may servers, services can be denied for about 10 minutes. Do this every 10 minutes to make the server unusable.
61) Send error requests and overrun logfile space.*: Most servers keep error logs in disk areas that are critical to system operation. By sending a lot of error requests, you can sometimes overrun the available space, thus causing server crashes.
I made it!
Most of these attacks are based on the contents of messages sent to browsers or servers and not on their form. Since content is in the realm of the application program, firewalls can't realistically be used to prevent all of these attacks. No current firewall adequately protects against all content-based threats (and none likely ever will).
Many Web servers/browsers are within or inside the firewall and can act as attack springboards for other attacks. This means that attacks can often be extended from the system under attack to other systems in the same network.
According to an ASIS survey on industrial espionage, 40% of attacks come from outsiders acting alone, 20% from insiders acting in concert with outsiders, and the remaining 40% come from insiders acting on their own. Since most firewalls only protect against outsiders breaking in, most of these attacks (and many more) cannot be prevented if insiders participate.
Firewalls rarely protect against exploiting the server as a launch site. Servers are almost never properly protected against this sort of exploitation.
Firewalls rarely prevent denial of services attacks or assure integrity. When firewall vendors were asked about this in an open forum, all of those who responded declared that they did not provide and did not anticipate providing protection against denial of services attacks.
Firewalls primarily protect bastion-host servers, not browsers or the PCs they run on. This means that internal PCs can often be attacked from outside the firewall.
Firewalls primarily protect against low-level attacks. Web attacks tend to be higher-level.
The Web is a high-risk, high-potential-payoff activity. As such, it deserves proper attention from a standpoint of information protection. If you try to resolve each of these problems today, you will likely fail and run out of budget.
As a fundamental principle, I believe that an organizational approach to protection is necessary in order for protection to be effective. Detailed lists of potential defenses are simply too large to put here, and listing them would not help you understand how to use them properly. In the case of the Web, a prudent course of action requires a substantial organizational effort and understanding of the issues and possible solutions.
As a further note, protection on the Web in today's environment will ultimately involve taking risks as well as avoiding and reducing them. The real trick will be deciding which risks to take and under which circumstances.