Internet Holes: 50 Ways to Attack Your Web Systems

Copyright (c), 1995, Management Analytics - All Rights Reserved

Series Introduction

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.

Some Background

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:

The likelihood of being right is directly proportional to the
vigor with which other people claim you are wrong

Figuring that I was on the right track, I pressed on.

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:

Some Web and Web Security Basics

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:

Browsers interpret HTML documents and display them on the screen
as formatted text, included graphics, included audio, included movie,
and included other-things. When HTML documents provide pointers (called
Uniform Resource Locators - URLs) to other documents, the pointers are
presented as highlighted items. If the user wants to retrieve a
document referenced by a URL, the item on the screen corresponding to
the URL is selected (usually with a mouse click) and the browser
attempts to get the new document from the Web.

Servers await requests (normally on TCP Port 80) that consist
(about 99% of the time) of Get requests naming a particular
document to be retrieved. When a request is made, the server either
provides the document or sends back an appropriate error response.

The net effect is a giant database that can be moved through by
pressing buttons. This all works because URLs identify the name of the
server (by Internet name or IP address) and the name of the document on
that server (usually by a partial pathname of the file on the server).
The trick to getting people to access your Web site is getting other Web
sites to point to your URLs and to advertise your URLs to the network
through whatever means.

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 $b

To 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 PORT

Try "/" for the URL, "all.net" for the HOST, and "80" for the PORT as an example.

General Classes of Vulnerabilities

Vulnerabilities of the Web, as a system, can be considered in
terms of three different classes of attacks:

Browsers: Attacks can be launched against the browsers used
to retrieve and view information.

Servers: Attacks can be launched against the servers that
provide information on request.

The Network: Attacks can be launched against the network
infrastructure used to communicate between browser and server.

Another perspective on vulnerabilities of the Web considers four
different sorts of harm, several of which may be active in any
particular attack:

Corruption: Neither browsers, servers, or the Internet
infrastructure are designed to provide protection against corruption.
As a result, it is fairly easy to corrupt information throughout
the Web.

Denial: Neither browsers, servers, or the Internet
infrastructure are designed to provide protection against denial of
services. As a result, it is almost always possible to deny services on
a selective basis, and often possible to deny services on a larger
scale.

Leakage: Neither browsers, servers, or the Internet
infrastructure are designed to provide protection against leakage of
information. As a result, it is often possible to capture confidential
information and usage patterns.

Liability: Because of the weaknesses in the overall
structure of the Web, it is often possible to use an attacked site as a
launch-point for other attacks. This introduces potential liability to
parties that are successfully attacked.

Yet a third perspective looks at the fundamental issues of the
design of the Web:

Distributed untrusted computation: As a basic premise, the
Web provides a means for information provided by arbitrary servers at
unknown locations operated by unknown organizations to be interpreted by
any of a large number of different browsers at unknown locations
operated by unknown organizations. The idea of interpreting unknown
information from unknown sources seems inherently risky.

Remote execution of untrusted software: Many Web extensions
are designed to provide added function making the Web more than just a
massive uncontrolled distributed database. These extensions, such as
Postscript, Java, and Mime essentially allow for remote execution of
untrusted software. For the browser, the risk is that the computer
running the browser will be taken over, while for a server, the same
risk extends to the server and any subsequent browsers that get
information from that server once it is attacked.

Remote interpretation of unstructured and unverified
content: In essence, most browsers and servers assume that the incoming
information follows the HTTP protocol, but there is inadequate
enforcement of this by servers and browsers. The result is that any
incoming information might not conform, might be interpreted using an
undefined method (corresponding to a don't care condition in the
interpreter), and might result in arbitrary undesirable side effects.

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.

The Fifty Ways

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.

Browser-Side Attacks

These attacks work against browsers, the user programs
that present information and allow the selection of new URLs.

Postscript Interpreters

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

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.

Undesired Traffic

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.

Downloaded Aplets

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.

Some Other Attacks

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.

Server-Side Attacks

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.

Buffer overflow into code space

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.

CGI script hole

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.

Network Attacks

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.

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!

Your Firewall Won't Save You

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.

Self-Defense on the Web

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.