Chapter 2

Transcription

Chapter 2

A Brief Review of Internet Security: Evolution,
Methodologies and Defense Strategies
Master’s Thesis by
Kulikov Alexey
Department of Computer Science, University of Warwick, CV4 7AL, Coventry, UK
Fourth Edition, 16 July 2005
Internet Security // Kulikov Alexey @ University of Warwick
-2-
Table of Contents
ABSTRACT....................................................................................................................................5
CHAPTER 1 — OVERVIEW OF INTERNET SECURITY....................................................7
HOW THE WEB WAS SPUN .............................................................................................................8
The Beginning ..........................................................................................................................8
HTTP........................................................................................................................................9
Server-Side Scripts.................................................................................................................10
Client-Side Scripts .................................................................................................................10
INTERNET S ECURITY...................................................................................................................12
The Five Fronts of Internet Security......................................................................................14
CHAPTER 2 — ATTACKING UNIX .......................................................................................20
MAIN REASONS FOR EXPLOITABILITY OF UNIX S YSTEMS............................................................20
Daemons ................................................................................................................................22
SUID/SGID Processes ...........................................................................................................22
Human Factor........................................................................................................................23
Trust .......................................................................................................................................23
TIMES BEFORE NET WORMS.........................................................................................................24
NET WORMS................................................................................................................................24
Strategies used by the worm ..................................................................................................26
Disguise Strategies ................................................................................................................26
TIMES AFTER NET WORMS...........................................................................................................27
CONCLUSION ..............................................................................................................................29
CHAPTER 3 — ATTACKS ON THE TRANSPORT CHANNEL ........................................32
FAKE ARP S ERVERS ...................................................................................................................33
DOMAIN NAME SERVERS ............................................................................................................36
Faking DNS replies................................................................................................................37
EARLY C RYPTOGRAPHY .............................................................................................................39
PRETTY GOOD PRIVACY .............................................................................................................41
SECURE SOCKET LAYER .............................................................................................................43
How safe is SSL? ...................................................................................................................44
CONCLUSION ..............................................................................................................................44
APPENDIX 1 ................................................................................................................................46
APPENDIX 2 ................................................................................................................................48
APPENDIX 3 ................................................................................................................................49
APPENDIX 5 ................................................................................................................................51
-3-
CHAPTER 4 — ATTACKING THE PEOPLE // HUMAN FACTOR ..................................53
WHAT IS SOCIAL ENGINEERING? ................................................................................................53
CLASSIFICATION OF VARIOUS SE M ETHODOLOGIES ..................................................................55
Using the Phone.....................................................................................................................55
The Internet............................................................................................................................55
E-mail ....................................................................................................................................55
Example of System Penetration .............................................................................................57
Evolution of SE in relation to Internet Security.....................................................................59
Short Story of Kevin Mitnick..................................................................................................59
SOCIAL ENGINEERING IN THE RECENT PAST ................................................................................59
COMBAT STRATEGIES AGA INST SE .............................................................................................62
CONCLUSION ..............................................................................................................................64
CHAPTER 5 — ATTACKING THE CLIENT ........................................................................66
VIRUSES AND WORMS ................................................................................................................67
HOW DO VIRUSES AND WORMS WORK? .......................................................................................69
TROJANS ....................................................................... ? ? ? ? ? ? ! ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .
ANTI- VIRUS SOFTWARE ..............................................................................................................72
RECENT HISTORY – MACRO VIRUSES .........................................................................................73
WHY WINDOWS? ........................................................................................................................74
CONCLUSION ..............................................................................................................................75
APPENDIX A – MELISSA .............................................................................................................78
CHAPTER 6 — ATTACKING THE WEB SERVER .............................................................80
WEB S ERVERS ............................................................................................................................81
Basics of Web Server Operation ............................................................................................81
Common Web Server Weaknesses .........................................................................................82
Server Misconfiguration ........................................................................................................82
Bugs in Web Applications ......................................................................................................82
DENIAL OF S ERVICE (DOS) .........................................................................................................84
Defense problems...................................................................................................................87
CONCLUSION ..............................................................................................................................89
CHAPTER 7 — BUILDING A SECURE LAN ........................................................................93
Server OS ...............................................................................................................................93
Web Server.............................................................................................................................95
Transport Channel.................................................................................................................96
Client (OS and Browser) .......................................................................................................98
People ....................................................................................................................................99
To Sum Up ...........................................................................................................................103
BIBLIOGRAPHY......................................................................................................................106
-4-
Abstract
Along the pages of this thesis I will try to show, that most of security problems we see on the net
today are inherent to architectural mistakes made by the creators of the Internet more than thirty
years ago. We are left in a position to build secure systems using initially insecure technologies,
in other words “security through obscurity”. First the reader is introduced to a new model, which
shall be referred to as the “Pentagon of Internet Security”, which incorporates in it the base
layers of the well-known OSI model alongside with a separate “front” for the people, responsible
for the operation of other security “fronts”. My model features the following fronts in need for
protection in reference to the World Wide Web: Server Operating System, Web Server Software,
Transport Channel, Client Machine and all the people operating the system. The evolution of
every front of the Pentagon is described over the course of this thesis slowly leading to the
conclusion, that the Internet is generally unsafe due to a set of historical architectural mistakes
and the prevalence of the “human factor / human mistake” on all sides of the Pentagon. The
thesis develops towards a recommendation of a scalable and accessible (in monetary terms)
security policy, which a LAN administrator/owner may adhere to. The Pentagon model is argued
to be a good replacement for the less-practical OSI model closer to the end of the thesis. To
support this claim I have based my Security Policy recommendation on the five sides of the
Pentagon.
-5-
Chapter 1
-6-
Chapter 1 — Overview of Internet Security
Incidents of attacks against computers have been reported since the earliest days of electronic
computing. Since those days, data security mechanisms have been an integral part of computer
operating systems. Until the mid 1980s, however, most such attacks were the work of those who
already had an account on a computer or knew someone who did. By that time, the cheap modem
had transformed every personal computer into a potential terminal for any other computer with
dial- in phone lines and the growing research project called the Internet connected tens of
thousands of computers by a high-speed data network. New opportunities for breakins became
available to anonymous people in any part of the world. I will illustrate this with a few examples.
In early September 1986 an intruder broke into a large number of computer systems in the San
Francisco area, including nine universities, sixteen Silicon Valley companies and three
government laboratories. The intruder left behind recompiled login programs to ease his return.
His goal was apparently to enter as many computers as possible, hence, no damage was done 1 . In
the same year, another intruder secretly broke into thirty supposedly well- secured computers in
the US Defense Department’s MILNET and attempted breaking into several hundred others,
apparently looking for military sensitive information that could be copied and sold. After nearly
a year of detective work, Cliff Stoll of the Lawrence Berkeley Laboratory collected enough
evidence to identify the German hacker 2 . In November 1988 Robert Morris, a graduate student at
Cornell University, released a worm program into the Internet. Within five hours this program
replicated itself in approximately 3000 computers. Network experts spent the next several days
isolating it. Although the worm damaged nothing, it produced massive scare, the potential for
loss of valuable information was enormous and an actual loss would have been devastating to
many people who used computers. In July 1989 Morris was faced with legal charges under the
federal computer crime law, charged with unauthorized entry to federal computers that caused
more than 1000$ damage. His trial was held in January 1990 and the jury found him guilty. He
was given a suspended jail sentence, fined 10 000$ and ordered to perform 400 hours of
community service.
Since 1986, the media have run various stories about computer breakins, worms and viruses.
The number of incidents is on the rise. There is a growing concern among computer network
managers, software dealers and users of the Internet about these forms of vandalism. The attacks
have drawn everyone’s attention to the general problem of computer security. In March 1985
Computer Recreations column in Scientific American written by A. K. Dewdney documented a
whole set of possible threats to information stored on personal computers3 . It is very difficult to
estimate the amount of damage caused by security incidents since then. The Computer Security
Institute published a study called “Issues and Trends: 2000 CSI/FBI Computer Crime and
Security Survey”4 . Of the companies surveyed, 42 percent were willing to quantify their
financial losses. No standard was used to figure out how much money was actually lost. The
companies simply reported what they wanted to. The cumulative total of these 273 reporting
organizations was $265 589 940. The most serious causes were theft of proprietary information
(66 respondents reported $ 66 708 000) and financial fraud (53 respondents reported $55 996
000). Seventy one percent of the respondents to the survey reported successful attacks by
insiders. However, more Internet-based attacks were reported than internal attacks. While $265
million may not seem like a big figure compared to the US gross national product, this number,
1
B. Reid. “Reflections on some recent widespread computer break-ins”, Communication of the ACM, Volume 30,
February 1987, pp. 103-105.
2
C. Stoll. The Cuckoo’s Egg: tracking a spy through the maze of computer espionage, Pocket Books, October 2000
3
A. K. Dewdney, “A Core War Bestiary of Viruses, Worms and Other Threats to Computer Memories”, Scientific
American 252, 5, March 1985, pp 14-23, can be seen here — http://vx.netlux.org/lib/mad02.html
4
Can be seen at http://www.landfield.com/isn/mail-archive/2000/Jun/0038.html
-7-
however, only represents the estimates of 273 organizations that responded to the survey. It is
therefore probably reasonable to assume that the companies that were hit the worst were not
interested in disclosing their misfortune. Yet, the problem of Internet Security is still in its
infantile stage and I guess there will be more incidents to come in the future.
How the Web was spun
The Internet is the single largest and most dispersed source of information in the world, and it
has grown spontaneously. Today, people use the net to obtain stock quotes, buy clothing, books
and CDs, communicate with friends and colleagues all over the world, obtain formal
qualifications and even conduct election polls. The communication between merchants and
buyers has never been easier before, and this fact is proven daily by the blistering success of
eBay. No wonder that companies are worried about being left behind if they don’t provide their
custome rs with usable and informative Web pages and the ability to shop electronically. What
many people don’t realize, however, is that the Web, as it evolved, has serious security issues.
Any successful project is a result of a lot of planning, followed by hard work, however, the Web
expanded on its own with little control from the very beginning. The situation quickly went out
of control leaving the Web to grow exponentially while it invaded almost every household in
developed countries. However, the initial purpose of the Internet was to share information, thus
little was done in order to protect it. However, the mass acceptance of the Web as we see it today
had an urgent need to protect information, as a result, security was added as an afterthought,
trying to make a secure system based on initially insecure technologies. New capabilities were
added as soon as they were demanded by the growing market without carefully considering the
impact on security. As the Web became the primary commercial medium for many businesses, it
did not take long for security threats to become much more serious: banks and large corporations
became common targets for attackers striving to make financial profits. Today we are at a point,
where Internet Security is of uttermost importance, yet the technological lock- in leaves little
chance to change the underlying technology.
It is important to understand the evolution of the Web for several reasons. New security threats
were introduced at each stage of the Web’s growth, and previous threats were not always
addressed. For example, the Web uses the Internet as its main mechanism of data transport,
hence it automatically inherits all of the Internet’s security vulnerabilities. Such as the TCP/IP5
protocol used as the main data transfer protocol on the Internet has been initially developed with
reliability of connection and not security in mind, therefore all the data transferred over the net
with the aid of that protocol travels in form of plain text and can be intercepted. It is worth
noting that many of the threats from the early days of the Web not only still exist, but also the
complex interaction between many of the early and modern features of the Web increase the
possible dangers.
The Beginning
In the late 1970s, the Internet, a collection of TCP/IP networks, was used only by a rather small
number of scientists and researchers. The main services were e- mail, file transfer and remote
access. For those who used it, the Internet was invaluable, but the general public had little
knowledge of it. Services such as netfind 6 soon followed. These services sat on top of existing
protocols and provided a level of abstraction between the user and the underlying protocols. That
is, the user no longer had to understand the details of the ftp and telnet technologies.
5
Abbreviation of Transmission Control Protocol, and pronounced as separate letters. TCP is one of the main
protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish
a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that packets will be
delivered in the same order in which they were sent.
6
One of the very first search services on the Internet, currently owned by AOL and can be seen under
http://netfind.aol.com/
-8-
Application-level programs separated the user from these details. However, already at that time
several security concerns arose. For the most part, they were application-specific. For example,
e-mail could be easily forged (it can still be forged today) by anyone who understood the SMTP 7
protocol. Many Internet users, however, understood the technology they were using, and mail
forgery was more often performed for fun rather than as a malicious deed. FTP 8 server
misconfiguration could leave a file system completely vulnerable. Telnet presented a serious
security problem because passwords were transmitted in clear text, thereby allowing anybody
with access to any network on the path between the client and the server to read them. This is
still one of the problems of the Internet today.
Other security concerns dealt with the protocols themselves. Steve Bellovin, for example,
pointed out 9 flaws in the TCP/IP protocol suite. One such flaw allowed attackers to spoof their IP
address in the data packets. That is, users could create IP data packets (explained in chapter 3)
with bogus addresses. Since many applications used this information for authentication purposes,
this simple attack could prove very successful. Another failure of the Internet is the poor design
of the DNS10 service. In case an attacker can alter the binding between an IP address and a
domain name, then he/she can easily impersonate any type of server. Although these threats were
known for years, they still represent a great vulnerability to modern attacks. In fact many of the
security holes mentioned in this thesis are still open for attack on many machines on the Internet
today.
By far the greatest security threat to the Internet was and remains the homogenous nature 11 of
client and server applications. The very thing that makes the Internet possible is at the same time
its greatest weakness. This was never given enough attention until the Morris worm of 1988
spread across the net in hours. This worm was possible because many versions of the bogus
program were running all over the world. It is, at the same time, nearly impossible to eliminate
all bugs in large applications. For example, sendmail, a large program that runs with system
privileges, has, over the past 10 years, been found to have many security flaws. As the identified
bugs were fixed, new ones were found. The cycle has repeated many times.
HTTP
The second stage in the evolution of the World Wide Web came with the introduction of the
HTTP 12 protocol and the HTML format. In the early 1990s, the Mosaic browser was introduced,
which gave users a friendly interface to the Internet. Users could then create their own Web
pages using HTML, hence the number of Internet users increased dramatically. Next, Netscape
Navigator was introduced. This browser launched helper applications, defined by the user, to
process various kinds of data. PostScript viewers could automatically display PostScript files on
the users’ computer screen when such a file was accessed over the network. The helper
applications could even launch an image viewer or a video or audio player. The security threats
7
Simple Mail Transfer Protocol
Short for File Transfer Protocol, the protocol for exchanging files overt the Internet. FTP works in the same way
as HTTP for transferring Web pages from a server to a user's browser and SMTP for transferring electronic mail
across the Internet in that, like these technologies, FTP uses the Internet's TCP/IP protocols to enable data transfer.
9
S. Bellovin, “Security Problems in the TCP/IP Protocol Suite”, Computer Communication Review 19(2), April
1989, pp 32-48, can be seen under http://www.research.att.com/~smb/papers/ipext.pdf
10
Short for Domain Name System (or Service or Server), an Internet service that translates domain names into IP
addresses. Because domain names are alphabetic, they're easier to remember. The Internet however, is really based
on IP addresses. Every time you use a domain name, therefore, a DNS service must translate the name into the
corresponding IP address. For example, the domain name www.example.com might translate to 198.105.232.4
11
Meaning that the client and the servers are running the same programs and are using the same protocols.
12
Short for HyperText Transfer Protocol, the underlying protocol used by the World Wide Web. HTTP defines how
messages are formatted and transmitted, and what actions Web Servers and browsers should take in response to
various commands. For example, when you enter a URL in your browser, this actually sends an HTTP command to
the Web Server directing it to fetch and transmit the requested Web page.
8
-9-
introduced by this new technology were not very different from previous threats, with one major
exception. Never before had so many computers in the world run the same Internet application.
A bug in the Netscape browser could potentially affect more computers than very likely existed
at the time of the Morris worm in 1988. In fact a bug was found in Netscape Navigator in late
1995 which allowed technologically savvy users to decrypt though-to-be-secure Web pages sent
via SSL between a browser and a server (see Chapter 3 for details). By far not all software bugs
are security threats, but there is no way to be sure that such bugs do not exist.
Server-Side Scripts
It did not take long for Web developers to enhance the HTTP protocol and HTML to allow for
two-way communication between Web Servers and Web clients. The introduction of CGI13
scripts on Web Servers allowed users to type into forms on their Web pages. By clicking a
button, the user sends information back to the server, where it is fed as input to a program called
a CGI script. Scripts can be written in any language, the most common being C, Perl, Shell or
lately PHP, JPS and ASP.NET. This enhancement made the World Wide Web a very widespread
term. Many non-technical users began to see a need for the Web. Offline magazines began
including Web references in their pages. Large companies began offering Web sites for their
customers, and soon even the smallest of companies couldn’t live without a home page. At the
same time, Web developers were building search engines and data catalogues that made finding
information easy. Complex shopping systems followed. The variety of CGI application we see
on the Web nowadays is practically impossible to list.
CGI scripts introduced new and more serious security concerns, especially to the machines that
were running Web Servers. In the past the danger was that a large program such as the Netscape
browser had an exploitable bug in it, however, the introduction of CGI gave users the tools to
create their own bugs for people to exploit. Sharing useful CGI scripts over electronic bulletin
boards and mailing lists quickly became common practice. These scripts found their way into
servers all over the world. Some of the more popular ones 14 replicated many thousand times.
There is absolutely no way to measure how quickly these scripts spread.
CGI scripts often run with privileges that give them almost complete control of the server.
Unfortunately, many of these scripts have flaws so serious that they can be exploited by any
client to compromise the server machine completely. For example, many scripts take user input
and feed it directly to a command interpreter. By using a pipe symbol “|” the user can cause other
unpredicted commands to execute on the server. The results can be serious if the machine where
the Web Server is run is used for other purposes, such as storing accounting information or
hosting a database. Attacks might mail private information found on the server back to a
malicious user, change data on the machine, lock up the server so that it has to be reinstalled, fill
the screen with annoying pictures, and so on.
Client-Side Scripts
Once CGI programs made executing programs on the server possible the next logical step was to
execute scripts on the client machine. This development has several implications in terms of both
functionality and security. The load on the server can be greatly reduced if it can send scripts to
13
Abbreviation of Common Gateway Interface, a specification for transferring information between a World Wide
Web Server and a CGI program. A CGI program is any program designed to accept and return data that conforms to
the CGI specification. The program could be written in any programming language, including C, Perl, Java, or
Visual Basic
14
Quite a few Open Source projects, which were started “for fun” by lone programmers are used all over the web
today, for example http://www.phpbb.com/
- 10 -
all clients instead of processing them locally 15 . The parallelism that can be achieved allows Web
applications to scale immensely. The most widespread language that is used for client-side script
processing is Java (in Web Browsers it is more common to see JavaScript, a much simpler
scripting language), which allows users to enhance Web pages with animations and interactive
programs. The use of Java has spread quickly, and it became the language of choice at many
universities and institutions. Its object-oriented features combined with its platform
independence made Java a very attractive choice. The security aware reader, however, should
immediately recognize many dangers that come with the very concept of running code from a
remote location on a client machine. Although Java’s designers have attempted to make it safe,
flaws were uncovered that break the established security mechanisms. For example, Ed Felten
and his students at the Princeton University have broken the type checking mechanism of the
Java bytecode verifier to enable arbitrary native code to run on the machine 16 . David Hopwood
at Oxford also had some success causing applets to interact in ways they shouldn’t 17 , thus
breaking system security.
Even though some skeptics were horrified by the introduction of something so dangerous as
client-side scripts, it was inevitable due to the high demand for function rich browser based
interfaces 18 . Given the popularity of the Web, and the giant leaps in functionality, the next
logical step was bound to happen. In fact, one should be grateful that the creators of Java at Sun
Microsystems at least tried to get it right. They were concerned with security from the very
beginning, and they realized that security would play an important role in Java’s acceptance 19 .
Unfortunately, the problem was harder than they thought at first 20 21 . Therefore, Web clients that
run with Java enabled are potentially vulnerable to attack. Surprisingly, the default security
setting for Java in the Internet Explorer browser is “enabled”, whereas Mozilla, for example, is
shipped with no Java Virtual Machine included at all, and it takes some expertise to install it.
Other scripting languages can run within browsers as well. JavaScript, for example, can be
distributed in- line with HTML docume nts. This feature makes it harder to identify such scripts at
firewalls, which, consequently, makes them rather hard to block. JavaScript’s security, however,
has not been studied as thoroughly as Java’s, but we have no reason to believe that it is failsafe 22 .
The current state of things appears to be quite clear. As infrastructure for mobile objects is
developed (PDAs, Mobile Phones, et cetera), it is only natural that it will be integrated with the
Web. General-purpose objects along with their data structures and access control rules may
further enhance the Web’s capabilities. We already see this in Java, ActiveX and other scripting
languages. As we reach each new stage of the Web’s development, new security problems will
inevitably arise with the introduction of new concepts and new technologies 23 .
15
In fact, even nowadays, when processing power is rather cheap, high load application prefer to pass most of the
data processing to the client. For example, the soon to launch Google service “gmail” consists mostly of JavaScript
that is executed on the client machine.
16
See the CERT advisory -- http://www.cert.org/advisories/CA-1996-07.html
17
See the SUN announcement -- http://Java.sun.com/sfaq/960327.html
18
The evolution of Web Interfaces is out of the scope of this thesis, yet I would like to point out, that Google’s
“gmail” has one of the most sophisticated Client-Code-Based user interface available on the net today.
19
The sole concept of Java’s “Virtual Machine” is based around creating a safe and secure environment for the
execution of a program.
20
See the CERT advisory -- http://www.cert.org/advisories/CA-1996-07.html
21
See the SUN announcement -- http://Java.sun.com/sfaq/960327.html
22
There are numerous ways in which Java Script scripts can affect the user’s execution environment without
violating any security policies. A discussion on the security of Java Script can be found in JavaScript: The Complete
Reference, second edition, by Thomas Powell and Fritz Schneider McGraw-Hill/Osborne
23
One of the recent examples being Wi-Fi networks.
- 11 -
Internet Security
Internet Security is different things to different people. The concept of Web Security has evolved
alongside with the mass popularization of the Internet. In the early days of the net it was mostly
about keeping unwanted eyes away from proprietary networks 24 . After the Morris Worm a new
hype has struck the net with System Administrators trying to close all possible points of entry on
their LANs. Internet Security was no more only about protecting information, it was also about
protecting computer resources. With the introduction and popularization of the www, Internet
Security gained new perspectives. People surfing the Web, wanted to do this in peace, knowing
that no one is looking over their shoulder. Banks wanted to make sure, that they could conduct
financial transactions safely keeping the integrity of the data intact. Moreover, as the web
became a commercial medium, people shopping online wanted to be sure, that their actions will
not lead to negative consequences. As the web grew, Web Site operators wanted to be sure, that
their sites would not be broken into and vandalized or used as a gateway to enter the LAN.
Moreover, more and more people are concerned about their privacy, thus secure communication
is also a part of Internet Security. A common problem these days is that the topic of Internet
Security has been distorted by software vendors and the press. Common users are mislead into
believing that Internet Security is all about antiviral software, or all about installing some sort of
home firewall system. Actually Internet Security is both more simple and more complex than the
media and software vendors make us believe. More simple because it is easy to break the
Internet down into smaller components and see where the problem lies. More complex, because
there are no simple solutions and no magic formulas for making the Web 100% safe. Internet
Security is about understanding the whole scope of the problem at hand and about attempting to
protect oneself at all fronts.
Today, an Internet Security professional will typically work according to the seven layer OSI25
model (fig. 1), which is, however, not World Wide Web specific, but is more abstract as it was
designed in the early seventies to represent a network connection between two hosts. This model
was adopted as a guideline for securing every layer, which could be seen as a potential
weakness, while transporting data from point A to point B.
Fig 1. This graphic is taken from The Abdus Salam International Centre for Theoretical Physics.
24
C. Stoll, The Cuckoo’s Egg: tracking a spy through the maze of computer espionage, Pocket Books, October 2000
The OSI, or Open System Interconnection, model defines a networking framework for implementing protocols in
seven layers. Control is passed from one layer to the next, starting at the application layer in one station, proceeding
to the bottom layer, over the channel to the next station and back up the hierarchy. Real-world protocol suites often
do not strictly match the seven-layer model. There can be some argument as to where the distinctions between layers
are drawn; there is no correct answer. The DoD model, developed in the 1970s for DARPA, is a 4-layer model that
maps closely to current common Internet protocols. It is based on a more “pragmatic” approach to networking than
OSI. See http://en.wikipedia.org/wiki/DoD_model for a thorough description of the DoD model.
25
- 12 -
Application
(Layer 7)
Presentation
(Layer 6)
Session
(Layer 5)
Transport
(Layer 4)
Network
(Layer 3)
Data Link
(Layer 2)
Physical
(Layer 1)
This layer supports application and end-user processes. Communication
partners are identified, quality of service is identified, user authentication
and privacy are considered, and any constraints on data syntax are
identified. Everything at this layer is application-specific. This layer
provides application services for file transfers, e- mail, and other network
software services. Telnet and FTP are applications that exist entirely in
the application level. Tiered application architectures are part of this
layer.
This layer provides independence from differences in data representation
(e.g., encryption) by translating from application to network format, and
vice versa. The presentation layer works to transform data into the form
that the application layer can accept. This layer formats and encrypts data
to be sent across a network, providing freedom from compatibility
problems. It is sometimes called the syntax layer.
This layer establishes, manages and terminates connections between
applications. The session layer sets up, coordinates, and terminates
conversations, exchanges, and dialogues between the applications at each
end. It deals with session and connection coordination.
This layer provides transparent transfer of data between end systems, or
hosts, and is responsible for end-to-end error recovery and flow control.
It ensures complete data transfer.
This layer provides switching and routing technologies, creating logical
paths, known as virtual circuits, for transmitting data from node to node.
Routing and forwarding are functions of this layer, as well as addressing,
Internetworking, error handling, congestion control and packet
sequencing.
At this layer, data packets are encoded and decoded into bits. It furnishes
transmission protocol knowledge and management and handles errors in
the physical layer, flow control and frame synchronization. The data link
layer is divided into two sublayers: The Media Access Control (MAC)
layer and the Logical Link Control (LLC) layer. The MAC sublayer
controls how a computer on the network gains access to the data and
permission to transmit it. The LLC layer controls frame synchronization,
flow control and error checking.
This layer conveys the bit stream - electrical impulse, light or radio signal
-- through the network at the electrical and mechanical level. It provides
the hardware means of sending and receiving data on a carrier, including
defining cables, cards and physical aspects. Fast Ethernet, RS232, and
ATM are protocols with physical layer components.
Table 1: Explanation of seven OSI layers 26 .
The OSI model defines a complete data transport framework, yet, I find it inappropriate to use as
a guideline for securing web-based applications. Firstly, one cannot look at Internet Security as a
set of various abstraction layers, investing into their evolution and protection, since web
applications are far more abstract than the initial communication architecture. Some layers can
be grouped together to represent a more accessible and understandable methodology. Besides,
the representation of the two hosts in the OSI model fits rather well with two servers
communicating with each other, however it does not fit a nowadays more common scenario of a
web browser requesting web pages from a server. Last, but not least, the OSI model takes into
account only IT based layers, and fully ignores the human factor – people operating every layer
of the model. Thus I am suggesting an alternate approach, which I will refer to as “The Pentagon
26
Source: http://www.webopedia.com/quick_ref/OSI_Layers.asp
- 13 -
of Internet Security”, as it covers five different fronts of possible points of access to a protected
system or network. It is a model I have designed in order to represent various areas of a system
or a whole LAN in need for protection. These five fronts are illustrated below (fig. 2) and are the
ground stones of this thesis.
Fig 2: Five fronts of Internet Security
The Five Fronts of Internet Security
When one gets down to the problem, then a Web connection is actually a very simple thing, as
there are only three parts to it:
1. The client (typically a Web browser)
2. A Web Server running on some computer most probably operated by some breed of Unix
3. The connection between the two
The user connects to a remote Web Server via his/her browser and requests a document, the
server returns the document and the browser displays it. What could go wrong? If one takes a
closer look at the transaction then is becomes clear that the integrity of the system rests on a
whole set of assumptions.
From the user’s point of view:
•
•
•
The remote server is owned and operated by the organization that it seems to be owned
by.
The documents that the server returns are free from viruses and malicious intent.
The remote server will not record or distribute information that the user considers private,
such as his/her browsing habits.
From the Webmaster’s point of view:
•
•
•
•
The user will not attempt to break into the Web Server’s computer system or alter the
contents of the Web site.
The user will not try to gain access to documents that he/she is not supposed to see.
The user will not try to crash the server, making it unavailable for others to use.
If the user has identified himself, he is who he claims to be.
- 14 -
From both parties’ views:
•
•
The network connection is free from third-party eavesdroppers listening in on the
communication line.
The information sent between the browser and the server is delivered intact, free from
tampering by third parties.
The whole purpose of Internet Security is to ensure that these assumptions remain valid. Web
connections have three parts, however, Internet Security has five fronts to defend.
•
Server-side Security comprising of
a. Server Operating System (first Front)
b. Web Server Software (second Front).
These are measures that protect the Web Server and the machine it runs on from breakins, site vandalism and denial-of-service attacks (attacks that make the Web site
unavailable for normal use). Technological solutions run the scope from firewall systems
to operating system security measures.
•
Transport Channel (third Front). These are measures that protect private information
from being disclosed to third parties. One risk to document confidentiality is
eavesdroppers who intercept documents as they cross the network. Another risk is
fraudulent identities – for instance, a user who misrepresents himself to a Web Server as
someone authorized to download a document, or a Web Server that tricks a user into
sending it confidential information by pretending to be a trusted site. The main
technological fix in this category is cryptography, although simpler measures, such as the
use of strong passwords to identify users also play an important role.
•
Client-side Security (fourth Front). These are security measures that protect the user’s
privacy and integrity of his computer. Technological solutions include safeguards to
protect users against computer viruses and other malicious software, as well as measures
that limit the amount of personal information that browsers can transmit without the
user’s consent. Also in this category are steps that organizations can take to prevent
employees’ Web browsing activities from compromising the secrecy of the company’s
confidential information or the integrity of its local area network.
•
The Human Factor (fifth Front). None of the above security fronts are safe in case the
people responsible for their integrity use “12345” as password or carelessly provide
confidential data to strangers over e- mail or phone. A company may invest thousands
into the latest security equipment, but in case the system administrator fails to apply the
latest software patches, the system may very well be broken into.
None of these aspects of Internet Security is independent of the other. The strongest
cryptography in the world (read Chapter 3 for details) will not keep a Web page secret if the
computer that it is stored on is broken into. An invulnerable Web Server (read Chapter 6 for
details) still won’t protect an organization from public humiliation if a hacker can manage to
hijack its domain name (read Chapter 3 for details) for a long enough period to convince the
world that the site was really vandalized. The threats we face come in different forms. Some
people are worried about their privacy. They don’t want anybody to know what Web pages they
visit, what e-mails they write, what products they buy and what people they are communicating
with while being online. Others are concerned with confidentiality of secret information on their
computers, they don’t want sensitive information to get into the wrong hands while it is being
transmitted over the Internet. Some people are worried that somebody will be able to
- 15 -
impersonate them on the Internet, or steal their access details to some public resource and do
various actions in their name (for example post messages in commonly-visited bulletin boards).
The Web has grown around us. On one hand, it offers new functionality that never existed
before. On the other many of us, however, are now vulnerable to threats that we didn’t even
imagine existed.
Along the pages of this thesis I will try to show, that most of security problems we see on the net
today are inherent to architectural mistakes made by the creators of the Internet more than thirty
years ago. We are left in a position to build secure systems using initially insecure technologies
and this situation is not likely to change in the near future as all present systems are
interdependent. Most of the technology that the Internet is based upon was there long-before the
World Wide Web, and it was designed with stability and not security in mind. For example, the
TCP/IP communication protocol (discussed in detail in Chapter 3) has absolutely no encryption
whatsoever built into it, resulting in all data being transmitted in form of clear text. Upgrading
the World Wide Web to another more sophisticated protocol is an almost impossible task, yet
slow migration of newer systems is an emerging trend. Moreover, the Internet’s initial purpose
was to share information, thus little thought was invested into information protection from the
very beginning. Therefore many of today’s applications remain in some sort of a technological
lock-in, struggling to protect information from being lost due to technological limitations of
systems in use. For example, most server operating systems (discussed in more detail in Chapter
2) being some breed of linux or Unix employ design paradigms that were first incorporated at the
dawn of the Unix epoch in the early seventies, such as: daemons, trust and guid/suid processes.
These design concepts are still present today, yet they are all a potential threat to the security of
the machine hooked up to the network. This and other concepts will be illustrated in greater
detail while I will be investigating the evolution of security on every of the five fronts of the
“Pentagon” introduced earlier in this chapter.
My secondary objective is to design an accessible (that is cheap in monetary terms) and scalable
security policy, which a commercial local area network administrator/manager could implement
in order to stay protected from common attack scenarios. The proposed security policy will be
based on the “Pentagon” security model, which I suggest to be used instead of the outdated OSI
security model. Moreover, after all sides of the Pentagon have been analyzed in consecutive
chapters, I will try and show, that the y are all interdependent, and that a security policy needs to
be build around all sides simultaneously. Failing to secure any side of the Pentagon may result in
the failure of the system as a whole. Add to that, the domination of the “Human Factor” in all
aspects of Internet Security, and the need for a scalable policy based on my model increases. In
the concluding chapter I will try to illustrate that no matter how advanced the technology on any
side of the Pentagon model is, it still remains very fragile in terms of security in case it is not
operated with the necessary care. Human mistakes are unintentional most of the time, yet in the
course of this thesis I will show, that they are the primary source of problems for the security of
any given LAN or machine. On one side, the security of some LAN may be affected by poor or
sloppy administration i.e. the System Administrator failing to install a fresh patch in time, or the
overall architecture having backdoors, which could be located by the parties having some sort of
malicious intentions in mind. On the other hand, all users of some LAN place it under risk, as
they may unintentionally provide access to their machine to third parties. For example, the use of
weak passwords (discussed in Chapter 2) is a common mistake that is employed by someone
willing to gain unauthorized access. Moreover, the sole concept of Social Engineering is one of
the most dangerous threats to any system in question. This is analyzed and discussed in detail in
Chapter 4. Add to that the possibility that the end user of some LAN can be tricked into
installing some sort of malicious application, which may very well paralyze the whole local
network and not only the client machine (see Chapter 5 for more detail), then this makes the
“Human Factor” one of the most important issues in the security of any LAN, moving out
- 16 -
technological solutions to a secondary position of importance. I hope that the “Pentagon” will
provide grounds for better understanding of the concept of Internet Security as a whole.
Unfortunately the area of Internet Security is a very broad topic and it is impossible to get hold
of all its aspects within a Master’s Thesis. Thus some concepts are left out intentionally, such as
the issue of physical security i.e. network components such as servers, hubs, and routers should
be located in a secure equipment room; access to work stations should be guarded by electronic
locks and the building should have guards protecting every entry. Moreover, concepts of security
based on hardware are also out of the scope of this thesis. Thus one must not be left wondering
why no attention is given to Firewalls, Switches, Routers and Hubs: these topics have been left
out intentionally. Add to that the fact, that this work does not pay any attention to recent
technological developments on the field of Internet Security such as the concept of Honeypots or
Virtual Private Networks. The site http://www.securitydocs.com offers a very wide selection of
articles on these topics and they are regarded as common solutions for corporate users.
Moreover, this thesis is, in many aspects, a historical study of evolution of the five fronts
defined earlier in this chapter, thus little or no attention is paid to the future of the area of
Internet Security.
The next five chapters focus on the five fronts of Internet Security listed earlier in this chapter. I
take a brief tour through their evolution and the level of risks they create for modern security
systems. Chapter two is an overview of the Unix epoch and the technological lock- in we have
ended up in, due to architectural mistakes made over thirty years ago by the designers of Unix.
Chapter three is a study of the most common Internet communication protocols, their evolution
and applications. In this chapter, as well as in chapter two, I emphasize the fact, that many of
modern problems with Internet Security are inherited from systems that were designed and build
in the early seventies. Chapter four is a brief study of Social Engineering and one of its pioneers
– Kevin Mitnick. There I discuss the importance of the “human factor” inherent to every
computer system and, in many cases, being the weakest link in the security of that system.
Chapter five looks at the importance of client machines, mainly focusing on the evolution of
malware (viruses and trojan horses). Computer viruses and worms are one of the commonest
problems encountered by Internet users nowadays, since they are easily spread throughout the
world via e- mail. Chapter six is a study of Web Servers, which are special programs that serve
client machines with HTML pages. It is vital to make sure that these programs are bug free and
safe as they are the primary foundation under any Website. Chapter seven brings together all the
sides of the Pentagon proposing an accessible and scalable security policy for any LAN.
Moreover it clearly illustrates that the sides of the Pentagon are operated by human beings, and
thus all are under potential threat from human error. There I am suggesting some improvement
strategies that may minimize the number of unintentional errors compromising the security of the
LAN in question.
- 17 -
Chapter Summary
•
•
•
•
•
•
Actual Internet Security did not exist until the Morris Worm incident in 1988
The Internet was designed with little security in mind, all that mattered was reliability of
the system.
Security professional use the OSI model to represent connections between two hosts on
the network and try to protect every layer of this model as a separate entity
The World Wide Web is more abstract than the OSI model, as it is, in most cases, a
connection between a client machine and a server, hence it needs to be secured using a
different methodology.
The OSI model does not take into account the Human Factor, which, in many cases, is
the weakest link in any security application
I am suggesting a simpler model of Internet Security consisting of five parts, which are:
the Unix Operating System, the Web Server, the Transport Channel, the Client Machine
and the People operating the whole system.
- 18 -
Chapter 2
- 19 -
Chapter 2 — Attacking UNIX
The Internet is a network of Unix based 27 machines. This statement may be misleading in
modern times, however, the Internet and its ancestor – ARPANET28 were invented in order to
connect computers running the Unix operating system. Hence, the Unix ideology has laid a
footprint on major network protocols, which, ideally, should have been system independent. A
recent Netcraft survey (state at October 2003) reports only 11% of all hosts running alternative
systems 29 . For that reason the majority of Web Server exploits are based around Unix based
servers, however Windows and Novell based systems are not uncommon attack targets30 .
This chapter is a short study of main Unix weaknesses and the reasons for their evolution. These
weak points have been found out the hard way, when the Morris worm hit the Internet in 1988
and forced over 10% of all hosts to shut down. Interestingly enough, little thought was given to
security of Unix-based systems before the incident with the worm. I will give a brief overview of
Unix security before the worm. After that, the incident of 1988 will be looked at in thorough
detail. The final part of the chapter analyzes more recent and mostly-employed attack
methodology – password picking, which evolved alongside the Unix operating system.
Main reasons for exploitability of Unix Systems
Unix based systems are known for their stability, but unfortunately not for security. Many
breaches are/were possible mostly due to human error. Either the developers leaving
undocumented backdoors, or system administrators not configuring the system to lock out
unwanted guests. However, back in the early 70s, Unix was not designed with a lot of security
measures in mind. After all, its main characteristics were portability, multi- tasking and multiuser operation. Thanks to AT&T and Bell Labs, and the eventual reproduction on Unix in the C
programming language it became rather wide-spread in universities and commercial firms, as
well as the United States government under licenses 31 . Therefore we still see thirty year old
software design concepts, such as “system daemons” or “SUID/SGID processes” (both explained
later) in recent Unix releases. Another known problem is trust: a typical Unix server will have a
trusted set of external machines, which are allowed to use the system’s resources without
authorization (user/password). This classification of weaknesses does not apply for novelty or
completeness, however it covers the major security problems of systems operating the Internet –
parties interested in less significant structures are suggested to address other detailed sources 32 .
Figure 1 shows a topology33 of main Unix weaknesses since the beginning of the “Unix Epoch”
(January 1st , 1971), these are addressed in more detail later on in this chapter.
27
Any operating system stemming from the original Unix operating system. These include all existing Linux
distributions, Solaris OS and others.
28
The precursor to the Internet, ARPANET was a large wide-area network created by the United States Defence
Advanced Research Project Agency (ARPA). Established in 1969, ARPANET served as a test bed for new
networking technologies, linking many universities and research centres. The first two nodes that formed the
ARPANET were UCLA and the Stanford Research Institute, followed shortly thereafter by the University of Utah.
29
See http://www.netcraft.com/
30
Larry Lange, “Hack punches hole in Microsoft NT security”, EE Times, 31.03.97, can be seen under
http://www.eetimes.com/news/97/947news/hack.html
31
The WikiPedia project, see http://en.wikipedia.org/wiki/Unix
32
Carl E. Landwehr, Alan R. Bull, John P. McDermott, and William S.Choi. A Taxonomy of Computer Security
Flaws, with Examples. Information Technology Division, Code 5542, Naval Research Laboratory, Washington,
D.C. 20375-5337, can be seen under http://www.cs.mdx.ac.uk/research/SFC/Papers/1994landwehr-acmcs.pdf
33
This diagram has been developed based on a brief study of Unix exploits over the past thirty years. Interestingly
enough, in many cases security breaches were possible due to human error only.
- 20 -
Fig 3: Main Unix Weaknesses since the beginning of the Unix Epoch (January 1st , 1971) A graphical representation
of this chapter’s content.
The Unix operating system has two distinct user types: a standard user and a super user. A
standard user will typically be granted access to his/her data and/or data belonging to his/her user
group. Obviously no standard user is allowed to modify or view any system data. However, a
super user (typically referred to as “root”) is allowed to access any file or process on the system.
With the evolution of Unix and the Internet a new breed of special users has stemmed from the
pool of standard users. These usually have reserved system names (such as guest, bin, uucp).
Although there is no special mechanism in Unix security differentiating between the two, it is
taken for granted that special users usually have less privileges than standard users. In particular,
special users cannot login into the system through a command shell. An interesting example
could be the “anonymous” user used to access open FTP 34 folders through the Internet. Finally,
all the people attempting to connect to a machine remotely can be classified as “virtual users”.
This type of user usually bears no system account but interacts with system daemons directly
(such as the login screen, or talking to the HTTP 35 server, which delivers Web pages per user
request). In terms of security, the virtual user is the biggest threat for any system connected to
the Internet. He/She has the minimal set of privileges on the system but at the same time
interacts with system daemons which usually have super user rights. Thus the Unix user
hierarchy is as follows:
1. Super User – unlimited access rights.
2. Standard User – access rights limited by the super user.
3. Special User – access rights are limited by the super user to work with a discrete set of
applications.
4. Virtual User – no access rights. Usually not identified by the system.
34
Short for File Transfer Protocol, the protocol used on the Internet for exchanging files.
Short for HyperText Transfer Protocol, the underlying protocol used by the World Wide Web. HTTP defines how
messages are formatted and transmitted, and what actions Web Servers and browsers should take in response to
the Web Server directing it to fetch and transmit the requested Web page.
35
- 21 -
Apparently, any person surfing the Internet will belong to access category 4 on any networked
server. Therefore the hacker’s main objective is to gain unauthorized access of a higher category.
Not in all cases does the hacker aim to get super user rights – the Morris worm (explained later
in this chapter) for example, has not even attempted to do so. In order to understand how Unix
system were exploited in the past, one must understand the concepts that make Unix vulnerable
to outside attacks.
Daemons
There is a potential danger of any level four user ga ining super user privileges by misusing one
of the system daemons (daemons are small programs which interact with the outside world, for
example a Web Server forming HTML pages and passing them to the requesting Web browser).
In almost all cases daemons are executed with super user privileges, hence they are the primary
point of attack. A hacker may be aware of potential faults in the daemon which will allow
him/her to pass commands to the operating systems in the name of the exploited daemon. An
easier alternative may be to exploit code weaknesses to crash the daemon. In many cases it will
then output a memory dump to the screen, which may contain cashed passwords. Unix systems
have always been equipped with a standard set of daemons for sending and receiving e-mail and
for working with network file transfers. These are known for being exploited massively in the
past (for example by the Morris Worm), but have grown immensely secure over the past thirty
years, whereas new daemons, such as the one serving Web pages to requesting clients, are
assumed to be prospective targets for malicious attacks. In general, any host, which is NOT
updating its system daemons on a regular basis should be considered extremely insecure.
SUID/SGID Processes
SUID/SGID (Set User ID/Set Group ID) processes have always been an integral part of the Unix
ideology. They were, are and will be an attractive target for hackers as the user interacts directly
with a system process, which has more privileges than the user. Therefore any bug in the process
code leads to a potential exploit of these privileges. These attacks can be carried out thanks to
another drawback in Unix security, which is called “the SUID/SGID process mechanism”. The
primary intention of this chapter does not include the inspection of reasons for the development
of this ideology, however, one reason is worth pointing out: many programs, that are executed by
users, require more privileges to run, than the current user has to offer. A trite example is a user
wishing to change his/her system access password. There is absolutely no doubt that the user has
to be able to carry out such an operation, however, following the Unix system ideology this will
mean that a standard user will have to modify the central system password storage file, which, of
course, should never be allowed. Therefore the program, that is responsible for changing the
password, is run not in the name of the user, who called its execution, but in the name of the
super user (which has full system access privileges). In order to do so it is assigned a special
SUID/SGID attribute, pointing to a change of owning user identification when the process is
executed.
This access model, which undoubtedly violates the basics of Unix security, could have been “ok”
in case it were used only by the password changing utility. However, surprisingly many
programs of various levels of importance and complexity require this feature. From this follows
that in case a hacker finds a bug or a backdoor in one of these programs he/she will be able to
carry out commands in the name of the super user. Typically the attacker will simply set a
SUID/SGID equal to root on the command shell interpreter and therefore gain full super user
rights on the system. Bugs are found in SUID/SGID programs on a regular basis, typically at a
rate of one critical fault per month36 . Thus, following one of the main software development
axioms we can assume that bugs will be found at this rate for the rest of the Unix epoch.
36
According to CERT’s accident report database, see http://www.cert.org/
- 22 -
Conformably, recent Unix-based kernels are aiming to secure themselves by either modifying the
SUID/SGID mechanism or not using it at all.
Attentive readers may have noticed that the above scenario is actually not a remote attack;
however it must be looked at as one of fundamental security breach factors of any Internet
system in the past. Systems, using this mechanism, will be referred to as potentially insecure.
Human Factor
Human factor was always one of the major reasons for security breaches in the computer world
in the past and unfortunately will remain so in the near future. A security system is only as strong
as its weakest link, whereas this link, in many cases, is the system administrator or a group of
trusted users working with the system. Typically a hacker will exploit the human factor to gain
some kind of trusted access to the system, this can be done either by guessing weak passwords37
or due to unskilled system administration. However, account holders can be deceived into
revealing their access data to third parties, who, in turn, will use their accounts to try and execute
one of the scenarios described above. The deception techniques are discussed in detail in chapter
four.
Trust
An attack is usually carried out by a level four user (anyone on the Internet), who’s primary
objective is to get some kind of limited access to the system (typically level three access). This
can be done by exploiting the “trust” mechanism of networked machines. The term “trust” comes
from the beginning of the Unix epoch when interconnected computer systems wanted to “trust”
each other. Later this paradigm has developed into closed “trusted zones”, where a system on a
network will have a set of external machines that are trusted to use local resources without any
kind of authentication other than the network address. It is common to split heavy load tasks on
several machines. For example e- mail processing, the database management system and Web
Server requests will be dealt with on three different servers, which, however will transparently
work together as one with no authentication mechanisms between them. This makes the internal
network potentially insecure, as Wietse Venema at the Eindhoven University of Technology
illustrates: “any form of trust can be substituted, deceived or destroyed, especially when the
service, receiving client requests, is located on any system other than the server, or when the
trust mechanism is based around weak authentication”38 . Usually access to a remote system by
exploiting the above scenario is possible only in case of fault y configuration (one must
understand, that the initial system can be misconfigured on purpose, read Chapter Four for more
details). Hence, hosts that are vulnerable to this type of attacks will be referred to as “credulous”
or “lamely administrated”.
Thus, to sum up, the set of distinctive features that makes Unix based machines particularly
vulnerable to remote attacks are: daemons and SUID/SGID processes. They create a potential
possibility for a hacker to gain super user rights. Moreover, the people administrating the server
are themselves a hazard to the system’s security. Finally “trusted zones” in any networked
environment may be misused by savvy technologists from remote servers to break into the
system. The existence of these “features” has inevitably led to serious breaches in the past, which
are inspected in more detail later in this chapter.
37
Generally a password is assumed to be weak if it is a word which can be found in a dictionary.
Dan Farmer, Wietse Venema. Improving the Security of Your Site by Breaking Into it. Eindhoven University of
Technology. Can be seen under http://www.fish.com/security/admin-guide-to-cracking.html
38
- 23 -
Times before net worms
At first there was organized chaos: the Internet being at its infantile stage resulted in a lack of
global networks; basic TCP/IP communication has just appeared and was not yet standardized;
Unix systems have already defined a set of base service programs, which we see in modern
servers nowadays, however the code was fresh and little tested. This process was developing
spontaneously following different evolution patterns in various regions of the USA. Later, the
most successful undertakings have evolved into regional standards and had to face competing
systems. This standardization process was accompanied by inevitable compromises, especially in
the security system, as the main principles behind Unix always were simplicity, scalability and
portability – these often contradicting security.
“Modern” hackers probably regret that they were not born a decade earlier. After all, in the late
seventies anyone being able to methodically access various hosts and try to login as user “guest”
with password “guest” would have been called a hacker 39 . Apparently the majority of hosts
(including government systems) could have been breached by using default system login
accounts which have not been removed by sysadmins after installation (see table 1 for
examples). It is worth pointing out that most of modern security measures were built to protect
against primitive attacks as the one described above. For example, what we see nowadays is
systems taking three to five seconds to process each login request, thus making it virtually
impossible for an attacker to simply guess the password in real time. Naturally a hacker will
never attempt to pick a password in real time, but, apparently even these simple security
measures did not exist in the early days of the Internet.
Operating System
Login
Password
AIX
guest
guest
AS/400
qsecofr
qsecofr
qsysopr
qsysopr
bcim
bcimpw
blue
bluepw
tech
field
field
service
systest
utep
System 75
VMS
Table 1: Early Unix Operating Systems and their default system accounts.
Net worms
I made references to the Morris worm in the previous chapters and will be paying attention to
this incident later, thus some light needs to be shed on this event. The Morris Internet Worm
(1988), which, apart from being the most prominent case in global network security breaches,
was also the greatest security breach in the history of the Internet as a whole. Moreover, it has
not simply infiltrated a set of networked machines but provided an answer to a long-standing
question: “can a self-reproducing computer program exist in a non-abstract environment?” The
Morris Worm has proven that such a program can be written, moreover it acted as a catalyst in
39
Clifford Stoll, The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage, Pocket Books,
October 2000
- 24 -
the emergence of a whole new field of research in computer security – network virology (see
chapter 5).
In 1988 the Internet as a global network was already formed and offered almost all services that
we use it for nowadays (except WWW). On the other hand, there already existed enough
information about possible security weaknesses of popular Unix systems. The critical point was
reached when the net was attacked by the first, and the worst of all, net worm created by a
doctoral student at the University of Cornell – Robert Morris Jr. Half a year after the incident
Robert was convicted for ten years in jail and the Chairman of the United States General
Accounting Office received a report which started with the words: “In November 1988, a
computer program caused thousands of computers on the Internet – a multi- network system
connecting over 60,000 computers nationwide and overseas – to shut down. This program,
commonly referred to as a computer virus or worm, entered computers and continuously
recopied itself, consuming resources and hampering network operations”40 . The primary effects
of the worm were lost computer processing and staff time. However, while apparently no
permanent damage was done, a few changes to the virus program could have resulted in
widespread damage and leakage of sensitive or private information.
Covering a subject as dynamic as Internet Worms is impossible in a short research thesis, hence I
recommend all interested parties to read “Defence and Detection Strategies against Net Worms”
written by Jose Nazario 41 , it is one of the most complete works I have ever seen on the topic of
Internet Worms. The book begins with a discussion of the departure worms take from traditional
computer viruses. An outline of the benefits for the black-hat (viral) attack toward a worm-based
attack, as well as a brief analysis of the threat model posed by worms, provide ample reason for
the computer security professional to take the study of Internet worms very seriously. Beyond
this introduction, the book is laid out in four major sections. The first section introduces to the
reader some background information crucial to the study of worms. The author discusses the
history and taxonomy of past worm outbreaks, from their science fiction origins (eg. John
Brunner's “Shockwave Rider”) through to modern-day outbreaks. A thorough analysis of various
worms' traffic patterns is presented, with data broken down by infection rates, number of
infected hosts, and number of sources probing specific subnets. Finally, the construction and
lifecycle of worms are presented, with particular attention paid to the interaction between the
worms' propagation techniques and the progression of their lifecycles.
Generally, a “net worm” is a virus which has the ability to reproduce itself in the local and the
global networks. To do so the worm must be equipped with the following characteristics 42 :
•
•
•
•
•
The ability to autonomously find new attack targets
Attacking the defined target
Passing a copy of oneself to the remote system
Executing the code on the remote system
Checking if the remote system has already been infected
Whereas a computer virus is different (see chapter five for details). A virus is a piece of code that
adds itself to other programs, including operating systems. It cannot run independently, but
rather requires that its "host" program be run to activate it. As such, it has a clear analogue to
40
Jack L. Brock, Glen Trochelman, Jerilynn B. Hoy, Mary T. Brewer, Beverly A. Peterson, Gwendolyn Dittmer.
GAO Report – Morris Worm. INFORMATION MANAGEMENT AND TECHNOLOGY DIVISION,
WASHINGTON, D.C. June 1999
41
Jose Nazario, Defence and Detection Strategies against Net Worms, Artech House Publishers, 2003
42
Nazario, Defence and Detection Strategies against Net Worms, pp 121-123
- 25 -
biologic viruses – those viruses are not considered live, but they invade host cells and take them
over, making them produce new viruses.
Strategies used by the worm
For intrusion of remote systems the Morris Worm mainly used two approaches: password
guessing (discussed later in this chapter) and a “backdoor” in mail software. This backdoor
allowed the worm to execute code on remote machines via simple e- mail commands. The virus
made extensive use of the SendMail debugger. The debug mode in SendMail in 1988 has had
extended functionality, such as the ability to execute parts of C code received in e- mail
messages. This capability was never documented by sendmail developers and was used only at
development stages. Unfortunately this “feature” was left in the released software by accident.
This vulnerability is a good example of a combination of two weaknesses of Unix systems:
daemons and human factor. The worm basically sent a piece of code to the attacked host via email, this code opened a channel to the attacking host, which allowed for seamless file transfer
and its execution at the remote host. At the time only two types of Unix systems could be
infected – VAX and Sun, hence the virus always sent over two different code sets, where only
one could be executed. Other systems remained safe, but, it is known, that over ten percent of all
hosts on the Internet were affected by the worm43 .
The worm, when spreading by other means than e- mail, made extensive use of a remote control
protocol “rexec”, which allowed a host to compile and execute code on other systems on the
network. All that was essential to start this procedure was a valid login name and a password to
the remote machine. The strategy used by the virus for picking these values was extremely
simple. It based itself on the assumption, that in a local area network the set of users on various
hosts will not differ much, hence it just tried to login remotely under the names of all the locally
listed users44 . Simple password matching from a local dictionary was used (technique is
discussed later in this chapter). This attack was partially successful, since it based itself around
the “human factor” weakness, which, in this case, incorporated the use of weak passwords and
the same login names on different machines. Moreover, in case a host had access to a set of
trusted machines on the local network, then all these hosts got infected straight away, since
access was granted by default.
Disguise Strategies
The worm was difficult to notice on an infected host, since it made extensive use of the
following set of disguise strategies 45 .
•
•
•
The initial binary files, which have launched the worm process on an infected host, were
deleted straight away, therefore the sysadmins never knew where the process has started
from. Moreover, in case the infected host was rebooted, then a special script would be
executed at startup, which loaded the worm from the nearest infected host.
The worm produced no output whatsoever, hence, even if it malfunctioned there were
never trails left in the system of its presence.
The worm was compiled under the name “sh”, which is also the name of the command
line interpreted under many Unix systems. Hence, whenever the sysadmins watched over
the list of currently active system processes, he would have inevitably mistaken the worm
for a local command shell process.
43
Jack L. Brock, Glen Trochelman, Jerilynn B. Hoy, Mary T. Brewe r, Beverly A. Peterson, Gwendolyn Dittmer.
GAO Report – Morris Worm.
44
Mark W. Eichin, Jon A. Rochils. With Microscope and Tweezers: An Analysis of the Internet Virus of November
1988. Purdue CS Technical Report TR-CSD-749
45
Eugene H. Spafford. The Internet Worm Program: An Analysis. Purdue CS Technical Report TR-CSD-823
- 26 -
•
Theoretically, the worm made no harm to any system on the Internet, except that it used a
lot of the systems’ processing time. However, it was not noticed by sysadmins at first,
since it has restarted itself every three minutes, thus setting the “processing time used”
counter to zero.
Times after net worms
The Morris worm forced the government and various authoritative figures in the IT world to take
a look at Internet Security from a different perspective. Various steps were taken to identify and
block all the holes, used by the worm46 . Moreover experts have tried to classify various reasons
for the existence of these Unix weaknesses (discussed in the beginning of this chapter). It was
clear that some governmental authoritative structure had to be formed, where Internet Security
information could be gathered and investigated. Shortly after the Morris worm incident such an
authority was formed in the USA – CERT (Computer Emergency Response Team). The first
CERT bulletin in December 1988 was a thorough investigation of the Morris worm and a
strategy such that an infection of suc h scale will never take place again. However computer
hackers have improved their attack methodologies. One of the most popular approaches (still in
heavy use nowadays) was guessing some user’s password. This technique was partly used by the
Morris Worm, it has dramatically evolved since then. It is still common that newspapers write
about “server breakins”, where what is meant is that an access password was picked.
As is well known, under Unix systems all the user’s access data (password, login name, full
name, et cetera) is stored in a separate file. Even at the dawn of the Unix epoch in the early
seventies it was rather clear that passwords could not be stored as clear text. We’ve got to hand it
to the first Unix developers, they’ve found a cryptographic scheme, which was first attempted to
hack only fifteen years later. The scheme is not a cryptographic algorithm, since sooner or later a
more or less able programmer would have figured out the algorithm and reverse engineered the
data. Instead a one-way coding procedure was chosen, where the original data is fed through a
special scrambling program which outputs a set of characters. From this it is absolutely
impossible to produce the initial data, since parts of it are lost (dropped)47 . It is worth pointing
out, that this data scrambling methodology was initially suggested and implemented by Robert
Morris Sr..
The program takes the first eight bytes of the incoming data and some random twelve bit number
(salt), which will be used to create a “data hash”. This extra random number is essential such that
users having identical passwords will not end up with identical data hashes. After that, the first
eight bytes of the data and the random number are parsed through a scrambling function, which
will
output
an
absolutely
unreadable
string,
for
example:
“d5aa1729c8c253e5d917a5264855eab8”. This string and the “salt” number are stored in the
password file alongside with the user name. Every time someone tries to login into the system,
their data will be parsed through the password creation function and compared to the values
stored in the password file. So in practice, no Unix system actually knows the password of any
user, ever.
After a brief analysis of the above framework, the first idea that invades the hacker’s mind is
simple password matching. One simply takes a set of symbols (for example all the letters of the
alphabet in upper and lower cases, numbers and special symbols – 94 symbols altogether) and
tries all the possible combinations of those until one of the resulting sets matches the original
password. Truncating passwords to eight characters, of course, greatly reduces the overall set of
possible combinations, but at the time this methodology was developed it was considered more
46
47
Eugene H. Spafford. The Internet Worm Incident, Purdue CS Technical Report TR-CSD-933
Such functions are known as “hash” functions.
- 27 -
than secure. The crypting program was made inefficient on purpose; this resulted in an average
processing time of one second per password. Hence, on average it would have taken
seconds or around hundred million years to pick a password. One could, of course, only use
lower-case letters of the alphabet, based on the assumption, that most of the time passwords
consist of lower-case letter only. Hence, on average it would have taken
seconds, or anywhere around 3440 years. However, nowadays an average Pentium machine at 2
GHz can easily try up to 20 000 password combinations per second 48 , i.e. in thirty years the
processing speed rose 20 000 times! Therefore, an eight character password from the example
above can be “guessed” in “only” 58 days. Moreover, firstly, this process can be carried out on
several machines, and secondly there is special hardware which can significantly speed this
process up.
Let’s take a closer look at times, when there was not enough computing power to simply pick a
password within a realistic timeframe. Hackers have come up with a smart (and pretty obvious)
method, which is based on human psychology. The main assumption is that human beings find it
hard to remember senseless combinations of symbols (which are ideal as passwords), therefore
people tend to use common sense words as password. Most often it is a noun found in a
dictionary or some kind of personal information (relative’s name, birth date, et cetera).
Assuming that a language on average has around 150 000 words, checking them as passwords
will take reasonably less time than blindly guessing various character combinations. This type of
attack is usually referred to as a “dictionary attack”. It was pointed out in this chapter, that even
the Morris worm made use of a small dictionary and it was successful on many occasions.
However, nowadays users tend to be more aware about using weak passwords, as Web-sites do
not allow them to choose any combination of symbols that can be found in a dictionary. Yet, the
psychological factor will remain intact as long as computers are operated by humans and,
probably, security experts will never deal will “safe” passwords such as “34jXs5U@bTa!6.”.
Therefore even aware users are using quite simple passwords such as “hope1”, “user1997”,
“pAsSwOrD”, “t00r”, “rootToor”, “mnmnkl”. It is clear that they are, usually, based around a
sensible word and some transformation rule: add a number, add a year, shift a letter, spell the
word backwards, et cetera. Therefore one must not be surprised if these passwords can be picked
in a reasonable amount of time. There are many programs available fo r download on the
Internet49 that will apply these rules to all the words listed in the local dictionary and in many
cases a password will not be secure enough against a dictionary attack.
Let’s check on the efficiency of the strategy described above. Comp uter security literature50
suggests to use two sensible words separated by some symbol as a password, for example:
good!password. Assuming that the program picking the password will be aware of this
48
Anyone with moderate programming skills can test using a simple straight-forward C programme. I ran a couple
of tests on my P4 2.4 GHz machine and could reach top speeds of 24 000 combinations per second.
49
Such as “Crack”, “John The Ripper”
50
Ross Anderson, Secrets Security Engineering: A Guide to Building Dependable Distributed Systems, John Wiley
& Sons Inc. (9 April, 2001)
- 28 -
transformation rule and have a ten thousand word dictionary at its service; the separating
character can be a number or any of the 32 special characters. Then a Pentium class machine at 2
GHz being able to process 20 000 password combinations per second will need
seconds or 1.2 days! This example illustrates rather clearly that users must be more careful when
selecting passwords, such that their security is not violated by a simple dictionary attack.
Conclusion
The overall situation with server OS security has not changed much since the beginning of the
Unix epoch in 1971. Older versions of Unix seem to have reasonably less bugs, however, new
versions have been released, and, what is more important, other operating systems are slowly
entering the Web Server market. Users are generally more aware when selecting their passwords,
but computing power doubles every eighteen month, hence making password guessing programs
more efficient. Apparently a hacker will no longer try and find a bug in any of the older Unix
daemons, but will test recent developments for weaknesses. After one has analyzed all the
typical Unix weaknesses it becomes clear, that absolute security is a myth. Yet, the primary
objective of any systems administrator is to do everything in his/her power to decrease the
probability of system penetration. Ho wever, one must be clear if there is anything to protect:
uninteresting hosts will never be a primary target of any experienced attacker. Therefore it is
recommended to follow two rules, when thinking about server security:
•
Actuality – the server must be protected from realistic attacks, and not from anything that
is virtually impossible, or anything that is old and outdated, like the Morris Worm.
•
Rationality of effort – one cannot create a system that is 100% secure from a remote
attack, hence it is essential to define the maximum effort one wishes to undertake when
securing a system. In general, one must never invest more resources than the value of
information being protected.
Chapter Summary
•
•
•
•
•
•
•
The Internet is a connection of Unix machines
The Unix operating system has four architectural failures which can compromise the
security of all the services hosted under that operating system. They are: Daemons, SUID
Processes, Trust Zones and, of course, direct acceptability of commands without
questioning of their origin i.e. human factor mistakes.
Daemons are background processes which have root access, thus if a daemon has a bug,
the whole system can be compromised.
SUID Processes are programs that need root access to a system, like the password
changing program. Hence, if there is a bug in any of the processes, the whole system can
be compromised.
Some systems trust other systems in order to share computing resources and do not
require a login. Thus, if the trusted system is compromised, then all the systems trusting
this system will be compromised as well.
Humans tend to select weak passwords, this enables hackers to guess the login password
to remote systems.
The Unix epoch can be divided into two parts: before the Morris Worm incident and
after.
- 29 -
•
•
•
•
•
The Morris Worm stroke the Internet in late 1988 and infected over half of all available
hosts.
The actual notion of Internet Security appeared shortly after the Morris Worm incident.
Before the Worm, there was little sense of danger on the net, many Unix systems had
default pre-set passwords, the abuse of which was clearly documented by Clifford Stoll
in 1986.
After the Worm incident the CERT was established. Internet Security became top
priority.
Nonetheless, main architectural mistakes of Unix are still inherent to almost any *nix
machine in the world today. Moreover, the human factor still plays an important role in
system security as computers became much more powerful and are able to guess millions
of passwords per second. Yet, many people are still using weak access passwords.
- 30 -
Chapter 3
- 31 -
Chapter 3 — Attacks on the Transport Channel
The basic remote access protocols on the Internet are TELNET and FTP (File Transfer Protocol).
TELNET is a terminal emulation program for TCP/IP 51 networks such as the Internet. The Telnet
program runs on a computer and connects it to some server on the network. One can then enter
commands through the Telnet program and they will be executed as if they were entered directly
on the server. FTP is a communication protocol designed to transfer files between remote hosts.
In order to gain access to a remote server any user must go through an identification and
authentication procedure. These procedures are comprised of a unique user name and a
password. The FTP and TELNET remote access protocols both have a peculiar property of
passing user names and passwords as clear text through the network. Hence an effective way of
gaining unauthorized access to a remote system is based upon analysing data passed through the
network (traffic). This analysis can be carried out with the aid of a special program52 scanning all
data packets flowing through some network segment. For example, TELNET is packing every
character typed into a separate data packet, whereas FTP will send the username and password in
one packet. Thus this traffic can be intercepted and analysed in order to retrieve access data (Fig
1).53
Fig 4: Typical Traffic Analysis Scenario
It is rather unclear why initial protocol developers did not think about traffic interception at the
time the first networks were implemented. They could have developed simple encryption
algorithms, but instead most access data, even nowadays, is passed as clear text over the net.
Probably, this problem comes from the fact that basic communication protocols from the TCP/IP
family (see chapter 1) were developed in the early seventies. Moreover, they have not changed
since the beginning of the Unix epoch (1st January 1971). However the set of priorities in
network communication has changed. The original Internet infrastructure and its protocols were
developed primarily with reliability of communication in mind, little thoughts was given to
51
Abbreviation for Transmission Control Protocol/Internet Protocol, the suite of communications protocols used to
connect hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP and IP. TCP/IP is built
into the UNIX operating system and is used by the Internet, making it the de facto standard for transmitting data
over networks. Even network operating systems that have their own protocols, such as Netware, als o support
TCP/IP.
52
Explanation of manual interception methods follows later in this Chapter. Yet I would like to point the reader to
http://www.softpedia.com/get/Network-Tools/Protocol-Analyzers-Sniffers/LinkFerret-Network-Monitor.shtml -which is an exc ellent tool to monitor traffic in almost all types of networks. Moreover, this package even allows the
sniffing of encrypted wireless traffic in case a key is defined, or the key is picked by brute-force. The concept of
encryption keys is described later in this chapter.
53
Although there has been a lot of hype around the shift of LANs towards Switches from Hubs (the difference is
explained here: http://www.duxcw.com/faq/network/hubsw.htm), traffic is still possible to intercept using one of the
methodologies explained later in this chapter (ARP Spoofing). Moreover, currently we are witnessing a new shift
towards wireless networks, where public access points rarely use any form of encryption, thus allowing even script
kiddies to intercept sensitive information “in thin air”.
- 32 -
security. Internet users nowadays are forced to think of ways to compensate for these mistakes of
the past. It is clear that network communication has changed over the past decades, moreover
secure communication between two remote machines has, in many cases, become the highest
priority in areas such as Internet Banking. Thus various secure communication protocols were
developed in the recent past such as Secure Socket Layer (explained later). However, these new
protocols did not substituted older communication mechanisms; hence they cannot provide
absolute security of transmitted data. Nevertheless the majority of Internet users are still
employing a set of standard communication protocols from the TCP/IP family, which were
developed more than two decades ago. As a result, CERT (Computer Emergency Response
Team) reports that more than a million access passwords were stolen in 1993-1994 due to simple
Internet traffic analysis 54 . However, the situation is slowly improving with SSL becoming a
standard mechanism for securely transmitting data between two machines. Many Internet
platforms are indicating that their data channels are secure, thus making an average user more
aware of other non-secure sites.
There are two popular ways for intercepting data flowing through networks: faking ARP
(Address Resolution Protocol) and faking DNS (Domain Name Server), both of which will be
explained later in this chapter. After that I will focus on SSL and PGP (Pretty Good Privacy),
which are publicly available standards for network traffic encryption.
Fake ARP Servers
Computer networks exchange data compressed into small packets. Usually data, that is to be
transmitted over the Internet is split up into a lot of small pieces and every one of these is sent
separately. Bruce Schneider illustrates this with a brilliant example:
Think of a ten-page letter being divided up and mailed in ten different envelopes. At the
recipient’s end, someone opens all the envelopes and reassembles the letter in its proper order.
The packets don’t have to arrive in order, and they don’t have to travel along the same route to
the destination55 .
In absolutely every case the data packet, traveling through the net, will be equipped with a
header and a body. The header will usually carry information such as source and destination
addresses and packet identification information. The body consists of the actual data or another
packet; extending Schneider’s analogy, one can imagine letters being packed into several
envelopes. The primary reason for data packets being placed into each other is the variety of
various network protocols used over the Internet. For example, network traffic exchanged
between two machines in a closed network will work without an indication of each other’s net
addresses (IPs), a hardware “fingerprint”56 is enough. For example, a data packet traveling
through the Internet based on the TCP/IP protocol will have three sets of headers: ethernet
header, IP header and a TCP header (fig 2) 57 .
54
CERT Coordination Centre, “Ongoing Network Monitoring Attacks”, Annual Report 1994, Appendix A, CA94:01
55
Bruce Schneider, Secrets and Lies, (2000) John Wiley & Sons, Inc. p. 177
56
Every Ethernet card has a MAC (Media Access Control) address, which uniquely identifies it in a closed network.
These can be (are) used for data exchange in Intranets.
57
I assume the use of Ethernet for the majority of LANs in question as it has become the most widespread LAN
technology in use during the 1990s to the present, and has largely replaced all other LAN standards such as token
ring, FDDI, and ARCNET. However, nowadays the popularity of wireless access via the Wi-Fi protocol is growing,
thus we could see Ethernet slowly replaced by the Wireless Fidelity communication protocol. For more information
on the concept of Ethernet read http://en.wikipedia.org/wiki/Ethernet — information in Wi-Fi can be found here
http://en.wikipedia.org/wiki/Wi-Fi.
- 33 -
Ethernet- header
IP-header
TCP-header
Data
Fig 2. Structure of a Data Packet traveling through the Internet
Since the early days of the Internet, the primary protocol used for data exchange was the Internet
Protocol (IP), which allows hosts to exchange data all over the world. Every host 58 on the global
network is assigned a unique 32 bit IP address. Thus a packet traveling from host A to host B
will have two IP addresses in its header: the sender (A) and the recipient (B). However, as
illustrated by Fig. 2 (above), the IP packet is placed inside the Ethernet packet. Therefore, any
data packet in any network transmitted with the aid of any protocol will in the end be sent to the
MAC address of the network adapter. Hence, besides the IP addresses it is essential to have the
ethernet addresses of the hosts involved (in Intranets) or the ethernet addresses of data routers59
involved (in the Internet). Initially the data sender may not have this information (ethernet
addresses of other hosts on the Intranet or the ethernet address of the data router). Therefore, a
typical problem arises, which is usually solved by a search algorithm.
On the Internet, this problem is tackled with the aid of an Address Resolution Protocol (ARP),
which allows hosts to obtain data pairs matching ethernet and IP addresses in a local area
network 60 (LAN). Typically a host will send a call to all possible ethernet addresses on the LAN,
asking for the ethernet address of the data router. This call will be recognized by all systems on
the network, including the router. It will then create a record in its ARP table, where the ethernet
address of the caller will be stored. At the same time, the caller will be notified by the router of
its ethernet address, which will be temporarily cached by the operating system. This architecture
implies that an intruder may place a host on the network, which will act as a data router, giving
the hacker a transparent way to monitor all network traffic. An interception scenario may look
like this (Fig 3.1, 3.2, 3.3):
•
•
•
The attacking host waits for an ARP request61 .
Once the call is received, the attacking host replies62 to the call with its own Ethernet address.
The attacking host now acts as a transparent link between other hosts and the original data router.
58
A computer that is connected to a TCP/IP network, including the Internet. Each host has a unique IP address.
A device that forwards data packets along networks, typically a router will also act as a firewall between a Local
Area Network and the Internet. All the traffic coming in from the LAN will eventually go through the router and end
on one single connection to the Internet. The Router, in turn, will mark all incoming and outgoing data packets with
corresponding internal IP and ethernet addresses.
60
A computer network that spans a relatively small area. Most LANs are confined to a single building or group of
buildings. However, one LAN can be connected to other LANs over any distance via telephone lines and radio
waves. Most LANs connect workstations and personal computers. Each node (individual computer) in a LAN has its
own CPU with which it executes programs, but it also is able to access data and devices anywhere on the LAN. This
means that many users can share devices, such as laser printers, as well as data. Users can also use the LAN to
communicate with each other, by sending e-mail or engaging in chat sessions
61
See appendix 2 for a typical ARP call packet
62
See appendix 3 for a typical ARP call reply
59
- 34 -
Fig 3.1 Attacking Host waiting for an ARP call
Fig 3.2 An ARP call is placed on the network and replied to by the attacking host
- 35 -
Fig 3.3 Attacking host now monitors all traffic between the host that placed an ARP call and the traffic
router.
The above scheme can still be exploited nowadays, due to technological lock-in. Moreover, few
system administrators are aware of the existence of ARP calls in their LANs, since this is a
transparent process not needing any human interaction. However it must be pointed out that this
type of attack will be successful only in a LAN, thus must only be considered as an “internal
threat”. On the other hand, CERT reports that more than half of all recorded attacks on
distributed systems were undertaken from Intranets by company’s employees. This is a logical
fact, since employees/staff will always have a broader knowledge of the overall network
architecture and its possible weaknesses. Good system administrators do not disregard the
existence of this threat, even though it can be harmful only in a local area network.
Domain Name Servers
Hosts on the Internet can be accessed via a 32 bit IP address such as 192.121.083.012, which
uniquely identifies every computer on the global network. However, human beings find it hard to
remember these numbers, therefore they are rarely used directly. Back in the early seventies a
naming scheme was introduced, which associated easy to remember names with IP addresses. It
is clear that a name such as «warwick.ac.uk » is easier to use and remember than 137.205.192.13.
The use of such names spawned a problem in associating names with IP addresses. This
relationship is necessary, since data travels through the net based on IP addresses, rather than
direct host names. In the mid seventies, when the Internet consisted of less than two hundred
hosts the Network Information Center (NIC) introduced the use of a simple text file, where all
associations could be found. This file was updated daily and sent to all hosts on the network.
However, as the Internet grew, so has the overall number of connected hosts, thus the above
scheme slowly became rather unpractical. Therefore a new scheme was developed, allowing a
host, which did not have the relevant information about a name-to-IP association, to get it from
the nearest Domain Name System (DNS).
The DNS was equipped with its own communication protocol, the effectiveness of which is
supported by the existence of a number of dedicated servers 63 serving as a search index to
63
A computer or device on a network that manages network resources. For example, a file server is a computer and
storage device dedicated to storing files. Any user on the network can store files on the server. A print server is a
computer that manages one or more printers, and a network server is a computer that manages network traffic . A
database server is a computer system that processes database queries. Servers are often dedicated, meaning that they
- 36 -
requesting hosts. On the Internet when a host is requesting some kind of response, such as a Web
page from a remote server, usually it only has information about its name and not it s IP address.
Therefore the host must search for the remote server’s IP address, this search is carried out by
the nearest DNS server. The basic search algorithm is as follows:
•
•
A host sends a request 64 to the nearest DNS server (either assigned automatically to the
host by the network router or defined manually) with the name of the remote server for
which an IP address needs to be found.
The DNS server looks the IP up in its database. If it is found, it is sent to the requesting
host as a DNS-reply65 . If not, then the DNS server sends a request to one of the root DNS
servers, which are defined manually by the DNS server’s sysadmins. This procedure is
repeated until the desired IP is found.
It is quite obvious that DNS replies can be falsified, hence all the traffic will be routed to other
destinations. On the other hand, one may question himself if it is possible to put a fake DNS
server on the network. The possibility exists, however, in most cases DNS addresses are defined
manually by the system’s administrators, therefore this scheme will be very ineffective. Let’s
take a closer look at a scheme, which has been employed over the past years for traffic rerouting.
Faking DNS replies.
The basic idea behind this attack is sending a set of DNS replies as often as possible to the
attacked host. Once the host requests some location, it will immediately receive as reply the IP of
the attacking host, which will then act as a communication channel between the attacked host
and the server requested in the first place. There are several criteria which have to be fulfilled by
the DNS-reply such that it is accepted by the operating system at the attacked host. Firstly, the IP
of the DNS must match the IP defined at the host (manageable). Secondly, the DNS-reply must
be for the requested Internet location (also manageable). The set of diagrams below illustrates
how this scheme operates.
perform no other tasks besides their server tasks. On multiprocessing operating systems , however, a single computer
can execute several programs at once. A server in this case could refer to the program that is managing resources
rather than the entire computer. Every computer, acting as a server, is at the same time an Internet host, since it is
allocated a unique IP address for remote access.
64
See Appendix 4 for a typical DNS request packet
65
See Appendix 5 for a typical DNS reply packet
- 37 -
Fig 4.1 The attacking host is sending fake DNS-replies to HOST A at minimal intervals.
Fig 4.2 Host A sends a DNS request for top.secret.com and immediately receives a fake DNS reply from the
attacking host.
Fig 4.3 Host A connects to the IP received in the fake DNS-reply. Clearly this will be the attacking host, which
will pass all the traffic on to the original top.secret.com serve r. However all traffic will be monitored.
This type of attack is possible thanks to weak implementation of the DNS mechanism in the
early days of the Internet. Moreover, it is very effective and hardly traceable, since one can
attack almost any host on the Internet with little possibility of being spotted. As Bell Labs
researcher Steve M. Bellovin puts it is his almost classic paper 66 : “A combined attack on the
domain system and the routing mechanisms can be catastrophic ”.
66
S. M. Bellovin. “Security Problems in the TCP/IP Suite”, ACM Computer Communications Review, 19(2), March
1989, Section 5.3, paragraph 3.
- 38 -
Early Cryptography
The story of cryptography goes back many ages, back as early as 5000 BC, when simple letter
transposition was first applied in order to scramble basic messages passed between generals over
the course of a battle. Simon Singh gives a rather clear overview of the early years of
cryptography in his best selling book “The Code Book”, where he examines the intricate details
of various ciphers invented over time, and provides a broad overview of decipherment
techniques. In this book he reveals though thrilling stories of espiona ge, intrigue, intellectual
brilliance and military cunning, the gripping history of cryptography.
The real cryptographic challenge, however, only came along with the burst of the Internet, as
vicious quantities of sensitive information started flowing over the network in the commercial
world 67 . The information at that time was mostly financial data such as bank transactions. As it
was made clear in the beginning of this chapter, network traffic is rather easy to intercept, hence
a way for secure communication between two hosts needed to be established. Large companies
developed “in-house” solutions, but, as a drawback they were then unable to communicate
securely with the outside world, hence some kind of standard data encryption mechanism needed
to be established. The International Business Machines (IBM) undertook its own research in the
field of network data security and cryptography. Various universities in the USA, including MIT
and Stanford, showed a lot of interest in this area of research, thus IBM recruited specialists from
them. One of the reasons for IBM turning to university based research was the broad network of
contacts between higher education institutions and the military, who, in turn, were the first
consumers of these developments. Therefo re, university based specialists always had more
practical experience with electronic cryptography in the real world, rather than professional
mathematicians.
The initial research team was lead by Horst Feistel, a german immigrant who had arrived in the
States in 1934. He was a well known cryptography specialist 68 . Before being appointed to lead
the research team at IBM, Feistel undertook research at Bell Labs in the field of data
cryptography alongside with Claude Elwood Shannon, the mathematician who laid the
foundation of modern information theory69 . IBM was not greedy on resources, even though it
was clear from the very beginning, that it will take a reasonable amount of time before profits
could be made. The research team was faced with a very tough cha llenge: to develop a standard
secure cryptographic scheme to protect electronic information in storage systems and on
computer networks. It must be admitted, that the results were way better than expected: it was in
the IBM’s Thomas J. Watson Laboratory near New York where during the early 1970s the
Lucifer 70 cipher was developed, which is one of the ground stones of modern cryptographic
solutions. The details of Lucifer’s operation can be found in Singh’s book where he carefully
analyses various approaches researched by Feistel and describes the Lucifer algorithm in detail.
Lucifer was generally accepted as one of the strongest publicly available encryption mechanisms
and consequently it was used by a variety of organizations. Hence it seemed inevitable for this
system to be adopted as the American standard, but NSA interfered with Feistel’s work, as
Lucifer was so strong that it offered virtually unbreakable protection, thus the NSA did not want
to see such a product as a widely accepted encryption standard. If Lucifer were to become the
encryption standard, then the NSA wanted to ensure that it would be able to break this
67
Before, cryptography was mostly employed by the military.
Horst Feistel. “Cryptography and Computer Privacy”, Scientific American, May 1973, Vol. 228, No. 5, p. 15-23.
69
C. E. Shannon, “A mathematical theory of communication”, Bell System Technical Journal, vol. 27, p. 379-423
and 623-656, July and October, 1948.
70
Algorithm explanation can be found here: Simon Singh, The Code Book, The Science of Secrecy from Ancient
Egypt to Quantum Cryptography, Fourth Estate Ltd. 1999, p 249
68
- 39 -
encryption via trying all possible keys 71 . Thus, the overall number of possible encryption keys
should be limited to some practical figure. The NSA argued in favor of limiting the number of
possible keys to roughly 100 000 000 000 000 000 (referred to as 56 bits). The NSA believed
that such a scope of possible encryption keys would provide a good enough level of security in
the commercial sector, whereas the NSA, having access to the greatest computing power in the
world would be able to bruteforce a key to decipher data in reasonable amount of time. On 23rd
of November, 1976 Feinstel’s Lucifer was adopted by the NSA and was renamed to the Data
Encryption Standard (DES).
Later many more algorithms such as RC4 and Blowfish were developed based on this scheme
and are generally referred to as “symmetric” because the sender and the receiver of data must
share the same key. However this approach is not perfect. The problem lies in distributing the
keys. For this system to work well, the sender and the receiver of data have to agree on a secret
key before exchanging any secret messages. Assuming one needs pair wise security, the number
of keys ne eded grows with the square of the number of users. Two people need one key, a ten
user network will need 45 keys to allow every pair of users to communicate securely. Whereas a
100 user network will need 4950 different keys.
Revolutionary changes took place in 1976 when Whitfield Diffie and Martin Hellman developed
the first asymmetric public key cryptography algorithm, consequently they named this scheme
DH (Diffie-Hellman) 72 . The main principle behind their algorithm was based on the usage of two
different mathematically linked access keys. The scheme used one key to code the data, however
the data could only be decoded with the second key (derived from the first key at creation time).
Hence these two keys produced a “key pair”, where one would be used to lock the data, thus
made publicly accessible (public key), and a second to read the data, therefore kept in a secure
place (private key). This allowed any two people to communicate securely over the Internet.
While this was a fundamental breakthrough in conceptual terms, it did not offer a ‘real world’
solution to the problem of key exchange, as no specific one-way function was selected /
developed to fulfil the above strategy73 . However, in the August, 1977 issue of The Scientific
American, Ronald L. Rivest, Adi Shamir and Leonard M. Adleman introduced to the world their
RSA cipher, based on the original work of Diffe and Hellman. The basic idea behind this system
is the fact, that two prime numbers are rather easy to multiply, yet factoring the result is a major
computational task 74 . Consider a simple example of multiplying 71 and 5, this will yield a result
of 355. Factoring out 355 will need at least 71 iterations in order to recover the two initial
multipliers. Imagine factoring out numbers, which are 300-400 digits long, in fact, we could
always use longer primes, as the largest known prime number is 225964951 - 1 (7,816,230) digits
long. Alone the multiplication of such a large number with the nearest prime will stall any
modern personal computer, as it will inevitably not have enough memory to handle such an
advanced operation. Thus the recovery of plain text from the public key is believed to be beyond
the capacity of any existing technique/computer combination.
Based on the public key approach, a signature scheme was suggested. Digital signatures provide
a level of authentication for messages, and in modern business, authentication is sometimes far
more important than secrecy. In simple terms, a digital signature for some message will be the
message itself encrypted with the sender’s private key. Therefore the receiver of the message can
71
In cryptography a key is a relatively small amount of information that is used by an algorithm (typically a phrase,
a collection of characters or a number) to customize the transformation of plaintext into ciphertext (during
encryption) or vice versa (during). Enciphering using the same algorithm and plaintext, but with a different key, will
produce a quite different ciphertext, and similarly for decryption as well. If the decryption key is lost, encrypted data
will not in practice be recoverable — at least for high quality encryption algorithms and large enough key sizes.
72
S. Singh, The Code Book , pp 252 - 268
73
S. Singh, The Code Book , pp 267, 271
74
Full algorithm explanation can be found in S. Singh, The Code Book , Appendix J.
- 40 -
use the sender’s pub lic key to check whether the message signature is valid and whether the
message was not altered while travelling over the net. Several digital signature algorithms are
currently in use such as RSA and The United States government’s Digital Signature Standard
(DSS).
The public key scheme seemed to have solved the key sharing problem, however, people could
still be tricked into revealing sensitive information by a scheme such as “the man in the middle”.
Suppose that two individuals Alice and Bob wish to exc hange sensitive information. However,
an eavesdropper (Eve) wants to get hold of that information. Hence Eve sends Bob a message,
asking for his public key and pretending to be Alice. At the same time, Eve sends Alice her
public key and pretends that it came from Bob. Simple, but effective. Now Alice will encrypt a
message with Eve’s public key, thinking that Eve is Bob. Eve will receive the message, open it
with her private key, read it, maybe modify it, encrypt it with Bob’s public key and send it to
Bob. This scenario demonstrates that a security system, even as strong as public key encryption,
can be manipulated to serve the needs of an attacker. After all, security is still about trust, and
trust can be manipulated.
Pretty Good Privacy
From the two attack concepts described in the beginning of this chapter it is rather clear, that
network traffic can be intercepted. Interestingly enough first public attempts to secure data
traveling through the net were undertaken only in the early nineties. The primary objectives of
such research were to produce a scheme for encrypting e- mail messages, which have represented
a large proportion of network traffic. Eventually Philip R. Zimmermann, a cryptography
engineer, proposed a public key based solution which was released as freeware in 1991 – Pretty
Good Privacy (PGP) 75 . On the Internet, PGP uses a hybrid approach that employs both kinds of
cryptography methodologies explained above. The main reason is performance76 . What the data
sender really does, when he wants to send a message to someone, is to use a symmetric
algorithm to encrypt the message with a random key that is created from thin air (called a session
key). Then this random key is encrypted with the recipient’s public key and both the encrypted
key and the encrypted message are sent to the recipient. The recipient uses his private key to
decrypt the session key, which is then used to decrypt the message. This procedure is illustrated
below (fig. 5.1, 5.2, 5.3).
Fig 5.1 The data sender generates a random session key and uses it to encrypt data. This step uses the
symmetric cryptography approach.
75
76
S. Singh, The Code Book, p 301
S. Singh. The Code Book . pp 298-300
- 41 -
Fig 5.2 The data sender downloads the public key from the data receiver. This public key is then used to
encrypt the session key generated in previous step.
Fig 5.3 Both the encrypted session key and the encrypted message are sent to the data receiver. The receiver
will then use its private key to decrypt the session key. It will then use the session key to decrypt the data.
This method is secure, since the private keys are never transmitted from host to host. Moreover,
public keys on their own are rather useless to the attacker, since it is virtually impossible to
derive the private key from the public key.
The history of PGP is rather interesting. In 1991 there was a potential threat in the USA, that the
congress would pass a law, forbidding common citizens to use cryptographic software. Hence,
Philip R. Zimmermann made his own cryptographic suite (based on the RSA algorithm) publicly
available as freeware 77 . This software product was the first professional release that incorporated
one of the most stable cryptographic algorithms available at that time. From the very beginning
PGP has fulfilled all prerequisites for a commercial security suite 78 :
•
•
•
•
Usage of a trusted algorithm
Usage of a long enough encryption/decryption key to eliminate the possibility of bruteforce attack succeeding in the near future
Local generation and control of encryption/decryption keys, which eliminated the
possibility of third parties intercepting the while transferred over the net
“Open Source”79 code
77
S. Singh. The Code Book . P 302
B. Schneider, Secrets and Lies, pp 115 - 119
79
A certification standard issued by the Open Source Initiative (OSI) that indicates that the source code of a
computer program is made available free of charge to the general public. The rationale for this movement is that a
larger group of programmers not concerned with proprietary ownership or financial gain will produce a more useful
and bug-free product for everyone to use. The concept relies on peer review to find and eliminate bugs in the
program code, a process which commercially developed and packaged programs do not utilize. Programmers on the
Internet read, redistribute and modify the source code, forcing an expedient evolution of the product. The process of
eliminating bugs and improving the software happens at a much quicker rate than through the traditional
development channels of commercial software as the information is shared throughout the open source community
and does not originate and channel through a corporation's research and development cogs.
78
- 42 -
PGP was disseminated not only in the United States, but all over the world. Rumours about FBI
interpreting publication of cryptographic software on the net as unauthorized export of weapons
has created an aura of “illegality”, which in turn has acted as a catalyst for PGP’s popularity.
Later Philip R. Zimmerman wrote:
“In 1991, Senate Bill 266 included a non-binding resolution, which if it had become real
law, would have forced manufacturers of secure communications equipment to insert
special "trap doors" in their products, so that the government could read anyone's
encrypted messages. Before that measure was defeated, I wrote and released Pretty Good
Privacy. I did it because I wanted cryptography to be made available to the American
public before it became illegal to use it. I gave it away for free so that it would achieve
wide dispersal, to inoculate the body politic”80
The PGP software package was immediately adopted by most e- mail programs which made
public key based communication a standard. Unexpectedly, at the end 1991, Philip R.
Zimmermann was accused of illegal export of PGP to countries outside of the states. The
criminal investigation lasted for over three years, after which all Zimmermann’s actions were
justified. The creator of PGP went on and founded a company “PGP Inc.”, which later was
acquired by Network Associates. During the investigation, Zimmermann came up with a
floutingly law abiding solution for exporting PGP updates to Europe. He simply published all
source code in books, which, in any form, are open for export to any country in the world. Of
course there were many volunteers, many lead by Stale Schumacher from the University of Oslo,
wishing to help compile and spread new version of PGP. Such publicity prove PGP’s stability
and increased the overall trust for the product. The appearance of PGP in the first half of the
nineties was a public saviour not only for private Internet users, but also for commercial players
and financ ial institutions. Moreover, as PGP source codes were freely available for inspection it
became some sort of manual in modern cryptography. Openness always was an essential
component of any cryptographic solution, since it allowed people world-wide to test and
experiment with the quality of the code. This is the main reason why new solutions are usually
rarely trusted 81 , it takes years before a scheme is accepted, and PGP uses an almost twenty year
old algorithm.
Secure Socket Layer
Monitoring Web traffic is not a challenging task, hence, someone entering credit card details in a
Web shop or someone submitting a PIN to access online banking is at risk. As a result, one of the
more recent security mechanisms on the Internet is Secure Socket Layer (SSL), developed by
Netscape for the first version of its commercial Web browser Netscape Navigator back in
December of 1994. The idea behind SSL is based around public key security, where the Web
browser and the server use public-key cryptography to exchange a key and then symmetric
cryptography to encrypt the data going back and forth. The first version of the Netscape browser
in the United States used a 128 bit key, yet all copies of the browser shipped abroad were only
capable of handling 40 bit keys due to restrictions placed by the American government.
80
Testimony of Philip R. Zimmermann to the Subcommittee on Science, Technology, and Space of the US Senate
Committee on Commerce, Science, and Transportation, 26 June 1996 -http://www.philzimmermann.com/testimony.shtml
81
B. Schneider, Secrets And Lies, pp. 115-119
- 43 -
How safe is SSL?
There is an old saying, that a chain is only as strong as its weakest link. There were various
attempts in decrypting SSL messages via a brute force attack 82 , however none of the initial
developers of SSL at Netscape thought of using alternative approaches. On September the 17th
1995 Ian Goldberg and David Wagner, graduates of the University of California in Berkeley,
published their SSL decryption procedure, which could open any message in less than a
minute 83 . This was a big breakthrough in code cracking, after all, it was no brute force attack but
a real exploit of a weakness found in SSL. So how did they do it? On one side, a 128-bit key is a
an immense set of values, which, even if using a super-computer, one will not be able to bruteforce in a reasonable amount of time. Even if one could try up to ten million key combinations
per second it will take hundreds of years before a valid key is found. However, this calculation is
based on the assumption, that the key has maximum entropy84 . The effectiveness of the 128-bit
key is far less than 128 bits in case it has low entropy. Imagine someone selecting a 128-bit key
from a set of two characters. This will make the overall number of possible key values quite
limited, and for sure way less than 128 bits. The problem with Netscape’s SSL algorithm was
that it selected random keys, which, in practice were by far not random85 . Actually it must be
pointed out, that computers are incapable of generating random number 86 , thus programmers
have always found elegant solutions to simulate randomness – some more secure than the others.
Netscape has picked a very insecure method, where “random” keys were generated based on
predictable values such as the internal clock and the process id. Goldberg and Wagner have
thoroughly analyzed this procedure and managed to reduce the overall set of possible 40 bit keys
to the bare minimum, which could be applied “in little less than 25 seconds”87 to break the
encoded message. Shortly after the publication of this exploit, Netscape released the second
version of its browser with SSL 2, which had a more “random” key generator.
Conclusion
Secrecy does not imply protection. The fact that data traveling over the net is encrypted does not
mean it is 100% safe. Whenever one sends encrypted data to someone over the net, this implies
that he/she trusts the recipient. Security is all about trust. Even with SSL, whenever one submits
data to a secure Website, this implies that one trusts the Website to store his/her data efficiently.
Moreover, the receiver may be someone one does not want to trust, and establishing a secure
communication channel does not raise the level of protection of information. Public keys are best
verified over the phone or in person, in order to avoid the problem of “the man in the middle”,
however, nothing is more secure than passing the data to someone in person. I doubt that all
Internet traffic will be encrypted in the future, since this action will make a lot of existing
connections obsolete: routers will not be able to direct packets efficiently; firewalls will not
know if traffic entering a secure LAN is harmful or not. The Internet has to be rebuild from the
ground- up in order to escape from this technological lock- in, otherwise we will always have
security through obscurity i.e. using insecure technology to build secure communication.
82
Basically trying every possible key one after the other. Assuming a long enough key is used such as a 128 bit key,
this process, if done on a single machine, will take decades to accomplish. However, the computing effort can be
distributed over several systems. The CERT reports 40 bit keys being “brocken” in less than a couple of hours.
83
Find the original e-mail posted by Ian Goldberg to the “cypherpunks” mailing list in the appendix.
Source: http://seclists.org/lists/bugtraq/1995/Sep/0064.html.
84
Entropy is a measure of disorder – the more uncertain something is, the more entropy in that thing. For example, a
human being is either male or female, this makes the variable gender have an entropy of 2.
85
Ian Goldberg, David Wagner, “Randomness and the Netscape Browser”, Dr. Dobb’s Journal, January 1996 -http://www.ddj.com/documents/s=965/ddj9601h/9601h.htm
86
B. Schneider, Secrets And Lies, pp. 98-99; In fact PGP, for example, asks the user to produce random inputs when
generating a new key-pair. These include movements of the mouse and pressing of keys on the keyboard. These, in
turn, are combined with various parameters read from the system’s hardware.
87
Original e-mail posted by Ian Goldberg to the “cypherpunks” mailing list
- 44 -
Chapter Summary
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The communication channel between two hosts is a potential security weakness, as one
can intercept the dataflow.
Communication protocols between hosts were designed with no security in mind. We are
still using thirty year old technology nowadays, as these protocols are the ground stones
of the modern World Wide Web.
Intranets are particularly vulnerable to data sniffing, as any machine on some LAN can
pretend to be a local ARP server, and hence, hijack all the traffic between a selected
machine and the rest of the world.
The WWW is based around Domain Name Servers which map domain names to IP
addresses.
One can easily pretend to be a valid DNS server and return fake IP destinations for some
host’s traffic.
These weaknesses were implemented into the Internet over thirty years ago and cannot be
eliminated.
A viable solution is data encryption.
Cryptography goes back many thousands of years.
More recent solutions were introduced by Hoerst Feistel. His research gave birth to the
currently world-accepted encryption standard “DES”.
DES still does not solve the problem of secure data communication over the Internet, as
one needs to distribute the encryption key without interference.
Public key cryptography was discovered in 1976 and later patented as the RSA
encryption standard. It seemed to solve the problem of key distribution.
In the early nineties, Phil Zimmerman released an OpenSource implementation of RSA’s
algorithm, known today as PGP, which is de facto standard in communication today.
Web browsers implemented public key cryptography since 1995, known as SSL today.
Today, data channels can be safe, however, there still remains the problem of trust, as one
does not know for sure, with whom a secure connection is being established.
- 45 -
Appendix 1
Original e- mail posted by Ian Goldberg to the “cypherpunks” mailing list explaining how to
crack SSL.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
From owner-cypherpunks_at_toad.com Sun Sep 17 21:38:21 1995
From: Ian Goldberg <iang_at_CS.Berkeley.EDU>
Message-Id: <199509180441.VAA16683_at_lagos.CS.Berkeley.EDU>
Subject: Netscape SSL implementation cracked!
To: cypherpunks_at_toad.com
Date: Sun, 17 Sep 1995 21:41:01 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4098
Sender: owner-cypherpunks_at_toad.com
Precedence: bulk
As some of you may recall, a few weeks ago I posted a
reverse-compilation of the random number generation routine used by
netscape to choose challenge data and encryption keys.
Recently, one of my officemates (David Wagner <daw_at_cs.berkeley.edu>)
and I (Ian Goldberg <iang_at_cs.berkeley.edu>) finished the job
of seeing exactly how the encryption keys are picked.
What we discovered is that, at least on the systems we checked (Solaris
and HP-UX), the seed value for the RNG was fairly trivial to guess by
someone with an account on the machine running netscape (so much so
that in this situation, it usually takes less than 1 minute to find
the key), and not too hard for people without accounts, either.
See below for details.
I've included the header to a program we wrote to do this key-cracking
below. I would like to get some information, though:
o Where should I put the full source (1 file, ~12k) so that ITAR lovers
don't get mad at me?
o Where can I find a version of netscape that does RC4-128? It is
likely that it suffers from the same problem, and even a brute-force
search of the entire seed space is _much_ less than 128 bits.
Happy hacking,
- Ian "who just saw _Hackers_ today with some other Bay Area cypherpunks,
and it put me in the mood"
/* unssl.c - Last update: 950917
Break netscape's shoddy implementation of SSL on some platforms
(tested for netscape running RC4-40 on Solaris and HP-UX; other
Unices are probably similar; other crypt methods are unknown, but
it is likely that RC4-128 will have the same problems).
The idea is this: netscape seeds the random number generator it uses
to produce challenge-data and master keys with a combination of the
time in seconds and microseconds, the pid and the ppid. Of these,
only the microseconds is hard to determine by someone who
(a) can watch your packets on the network and
(b) has access to any account on the system running netscape.
Even if (b) is not satisfied, the time can often be obtained from
the time or daytime network daemons; an approximation to the pid can
sometimes be obtained from a mail daemon (the pid is part of most
Message-ID's); the ppid will usually be not much smaller than the pid,
- 46 -
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
and has an higher than average chance of being 1. Clever guessing
of these values will in all likelihood cut the expected search space
down to less than brute-forcing a 40-bit key, and certainly is less
than brute-forcing a 128-bit key.
Subsequent https: connections after the first (even to different hosts)
seem to _not_ reseed the RNG. This makes things much easier, once
you've broken the first message. Just keep generating 16 bytes of
random numbers until you get the challenge-data for the next message.
The next key will then be the 16 random bytes after that.
main() and bits of MD5Transform1 by Ian Goldberg <iang_at_cs.berkeley.edu>
and David Wagner <daw_at_cs.berkeley.edu>. The rest is taken from the
standard MD5 code; see below.
This code seems to want to run on a big-endian machine. There may be
other problems as well. This code is provided as-is; if it causes you
to lose your data, sleep, civil liberties, or SO, that's your problem.
#include <std/disclaimer.h>
On the command line, give the time in seconds, the pid, the ppid and
the SSL challenge data (each byte in hex, separated by some non-hex
character like a colon) of the _first_ SSL message generated by
the instance of netscape. This program will search through the
microsecond values. You may need to run it again with a slightly
different value for the seconds, depending on how accurately you know
the time on the system running netscape. The output will be the
master key (all 16 bytes; note you never even told the program the
11 bytes you knew) and the value for the microseconds that produced it.
As a benchmark, this code runs in just under 25 seconds real time
(for an unsuccessful search through 1<<20 values for the microseconds)
on an unloaded HP 712/80.
*/
- 47 -
Appendix 2
A typical ARP request packet. This packet has been captures in the Department of Computer
Science at the University of Warwick with the aid of a simple network traffic analyzer.
- 48 -
Appendix 3
A typical ARP reply packet, as sent by the router to the requesting host. However, as one can see
from the listing below, all the hosts on the LAN could monitor this reply.
- 49 -
Appendix 4
This is a typical DNS request packet, as composed as sent by a local machine for the domain
www.essentialmind.com
- 50 -
Appendix 5
And this is a typical DNS reply, as received by the local machine for its query from the DNS
server.
- 51 -
Chapter 4
- 52 -
Chapter 4 — Attacking the People // Human Factor
IT specialists have developed information-security solutions to minimize the risks connected
with the use of computers, yet left unaddressed was the most significant vulnerability —
the human factor. Humans remain the most serious threat to each other’s security. There is a
popular computer saying that a secure computer is one that is switched off, but this is
misleading. A “Social Engineer” can simply talk someone into going into the office
and switching the computer on. A company may be able to purchase the best security technology
available, it can hire door guards from the best firm in the business, or establish unique security
schemes based around employees’ biorhythmic data or time based tokens. Yet information —
the main asset of this company, is still totally vulnerable. The weakest link in the company’s
security chain remain the people, who operate the electronic systems 88 . It is in many cases much
easier to simply ask someone for their access details, rather than undertake a “low level”
hardware attack. This technique of convincing people into giving away their passwords and other
sensitive data is what is known as Social Engineering (SE).
The first part of this chapter will define various SE methodologies and examine the reasons for
their effectiveness. Next, it will focus on the evolution of SE in relevance to Internet Security.
This will be illustrated with a short story of the world’s most famous Social Engineer – Kevin
Mitnick, who managed to break into virtually every US network. Finally, this chapter will
conclude with various approaches to combating SE. Please note, that other aspects of people
related security problems are investigated in chapter 2 (section on weak passwords) and in
chapter 7. Yet in my perspective SE remains the most powerful tool to compromise the security
of some LAN/Server with other human-related mistakes only aiding successful Social Engineers
in carrying out successful attacks.
What is Social Engineering?
Social Engineering (SE) was in existence for centuries, yet only recently was it applied to gain
unauthorized access to network servers. Security experts working in this field ended up with a
general definition: “the art and science of getting people to comply to your wishes”89 . Whereas
Ryburn Paul at the University of Memphis defines SE as: “an outside hacker’s
use of psychological tricks on legitimate users of a computer system, in order to obtain
information he needs to gain access to the system ”90 ; While the hacker's91 jargon dictionary92
defines Social Engineering as: “Term used among crackers and samurai for cracking techniques
that rely on weaknesses in wetware93 rather than software; the aim is to trick people into
revealing passwords or other information that compromises a target system's security[…].”
Social engineering can be any of these definitions, depending on the situation. Generally it can
be defined as the process by which a hacker deceives others into disclosing valuable data that
88
Mitnick Kevin: “The Art of Deception”, Wiley Publishing Inc. 2002, page 4
http://packetstormsecurity.nl/docs/social-engineering/socialen.txt
90
Ryburn, Paul. COMP 1200, University of Memphis, January 1997.
http://www.msci.memphis.edu/%7Eryburnp/cl/glossary.html#social_engineering (26 July, 2000).
91
The term “hacker” has many definitions. Originally it meant any type of computer expert. The meaning of the
term, when used in a computer context, has changed somewhat over the decades since it first came into use, as it has
been given additional and clashing meanings by new users of the word. Currently, "hacker" is used in two main
ways, one complimentary and one pejorative. In popular usage and in the media, it generally describes computer
intruders or criminals. The term “hacker” can also be used in the computing community to describe a particularly
brilliant programmer or technical expert (for example: “Linus Torvalds, the creator of Linux, is a genius hacker.”).
Over the course of this thesis, the term “hacker” is used in its more popular form, referring to computer intruders or
criminals.
92
The hacker's jargon dictionary @ http://info.astrian.net/jargon/
93
Human beings (programmers, operators, administrators) attached to a computer system, as opposed to the system's
hardware or software
89
- 53 -
will benefit him/her in some way. Hackers have originally used SE to obtain codes or e- mail
passwords for access to long-distance telephone lines or computers 94 95 , more recent reports
indicate that SE attacks can be, and are, used, to acquire credit card numbers and other sensitive
data.
For instance, in the Autumn of 2001 some CompuServe subscribers, who had just recently set up
trial accounts with CompuServe after providing credit card or bank account information, were
contacted a few days later by e- mail. The e- mail, which purported to be from a CompuServe
account manager, stated that there were unspecified “problems with your account” and asked the
subscriber to resubmit his log-on password and bank or credit card data. What was noteworthy
about this attempt was the fact that it was directed only at new subscribers, who would be less
likely to know that they should not respond to the e- mail 96 .
Another situation involved Yahoo e- mail users who reportedly received e- mails from a person
who falsely identified himself as a Yahoo employee. The “employee” told each recipient that he
had won a 56K modem from Yahoo, but that he would have to supply his name, address,
telephone number, and credit card number to pay for shipping. A number of recipients did so
before Yahoo learned of the falsified e- mail and contacted everyone who had responded to it 97 .
Smart crackers prefer not to break into computer systems. According to a speech given by an
experienced hacker, Susan Thunder's – “Social Engineering and Psychological Subversion” at
DEFCON III 98 in Las Vegas in August 1999, these hackers prefer to use social engineering to get
users to open the door for them. Thunder made an observation, which all LAN managers should
take very seriously: “Increased security measures make psychological attacks easier because
users think that their data is safe.” All the locks in the world will not save you from the thief you
invite in.
“The basic goals of social engineering are the same as hacking in general: to gain unauthorized
access to systems or information in order to commit fraud, network intrusion, industrial
espionage, identity theft, or simply to disrupt the system or network. Typical targets include
telephone companies and answering services, big-name corporations, financial institutions,
military and government agencies”99 . SE is a very powerful, simple and in many cases legal
technique for obtaining classified information. In Kevin Mitnik’s milestone work ‘The Art of
Deception, he explains: “As developers invent continually better security technologies, making it
increasingly difficult to exploit technical vulnerabilities, attackers will turn more and more to
exploiting the human element. Cracking the human firewall is often easy, requires no investment
beyond the cost of a phone call [an e-mail or an IRC chat], and involves minimal risk”100 . In
fact, Mitnick could not be put to jail for over a year, since the US legal system did not foresee
the use of Social Engineering as anything illegal, after all, the employees simply gave out access
data to Kevin. Finding revealing, real- life examples of social engineering attacks is difficult.
Target organizations often do not want to admit that they have been victimized. After all,
to admit a fundamental security breach is not only embarrassing, it may be damaging to the
94
Computer Incident Advisory Capability, U.S. Dept of Energy, CIAC Note 94-03a, July 6, 1994,
http://www.ciac.org/ciac/notes/Notes03a.shtml#Engineering
95
Carnegie-Mellon Software Engineering Institute, CERT Coordination Center, "Social Engineering," CERT
Advisory CA-90.04, revised Sept. 18, 1997, http://www.cert.org/advisories/CA-91.04.social.engineering.html
96
“Spam scam nets newbies” New Scientist, October 31, 1998, http://www.newscientist.com/ns/981031/nspam.html
97
Janet Kornblum, “Yahoo recovers from scam, hack” CNET News, Dec. 12, 1997,
http://www.news.com/News/Item/Textonly/0,25,17318,00.html
98
http://www.defcon.org/
99
S. Granger, “Social Engineering Fundamentals, Part I: Hacker Tactics”, can be seen at
http://www.securityfocus.com/infocus/1527/
100
Mitnick Kevin: “The Art of Deception”, page 4. Wiley Publishing Inc. 2002
- 54 -
organization’s reputation. It is common for such attacks to be badly documented, so that no one
is really sure whether an attack has taken place or not.
Classification of Various SE Methodologies
Social Engineering existed since the beginning of time, primarily because most of us are helpful
and trusting people. As an example we can site the “Love Bug” virus, since it poignantly
illustrates how the psychological need and/or want of human beings to be loved could be
exploited. Only after the person opened the e-mail did they discover that they were loved in a
way they would hopefully never be loved again. Commonly Social Engineering methods will
include using the telephone, talking people into giving away access data. A much less popular
method is e-mail – eg. the “I Love You” virus, or in person – walking into a building and
checking out all the post- it- notes with passwords on them that are stuck to monitors, and last but
not least “snail mail” 101 – dropping a bogus survey in the mail offering a cash award for
completion and asking some delicate questions, whereas answer forms are to be filled out online
for convenience. In many cases a social engineer will use a combination of several attack
methods (see table 1) in order to reach his objective.
The most popular methodologies (Using the Phone and Using the Int ernet) are described in more
detail below, this digest of methodologies is based on Sarah Granger’s “Hacker’s Tactics”
lineout 102 .
Using the Phone
Classical Social Engineering (times before personal computers became available) emerged from
the use of the phone as a medium of conning one’s way towards granted access to sensitive
information. Inevitably it has evolved into a science of its own and is still remaining a prevailing
type of SE today. Particularly vulnerable are large organizations, where employees rarely know
everyone working for the company in person, thus voices are hard to correlate with real people
while talking to someone on the phone – one simply takes for granted that the person on the
other end of the line is who he or she is claiming to be. Impersonation becomes an easy job.
Many people inside the organization are rarely aware of the value of information they may give
up to someone over the phone, who, for example, may pretend to be a company computer
systems security consultant, simply checking up on the state of thing at some specific location in
the company. Particularly vulnerable are newly hired employees, as they will be especially
motivated to correspond with internal company procedures (which may be misleading) in order
to gain an overall positive image in the organization. Moreover, they may not yet be aware of
company policies and thus will not be able to spot any anomalies, when requested to hand over
sensitive data over the phone line. Most of the roles fall under the category of someone with
authority, which leads us to ingratiation. Sensitive information may be revealed without
hesitation. Thus a rather effective company security policy may be to instruct its employees to
never reveal any kind of information over the phone, and instead only pass it over in person to
someone, who can authenticate himself.
The Internet
With the emergence of the Internet as a primary medium for information sharing, so has emerged
a new fertile ground for social engineers. It is known, that most people prefer to use the same
password to access various Internet Services, such as e- mail, eBay account data or a corporate
Intranet. Thus, in case someone manages to get hold of the user’s password once, he/she may
very well use it to access user’s sensitive information everywhere. There are various prevailing
101
Usual paper mail.
S. Granger, “Social Engineering Fundamentals, Part I: Hacker Tactics”, can be seen at
http://www.securityfocus.com/infocus/1527/
102
- 55 -
scenarios, all in need for impersonation. For example, one may set-up a web-site offering some
sort of service that the person under attack may be interested in. In order to gain access to this
service, the person will have to register, that is he/she will have to choose a user’s name and a
password, the e- mail address will have to be indicated as well. The Social Engineer will
immediately be notified of the user’s registration alongside with the provided data. In many
cases the access password will match the one, from the corporate e- mail account or the
organization’s intranet. Information will be lost. Another common attack is to impersonate some
service, that the user is already registered at. An e- mail is sent to the user’s account from a fake
e-mail address, corresponding to some address at the service in question. In that mail, the user
will be asked to follow some link, which will lead to a site, that will be made to look just like the
original site. There, the user will be asked to login – access data will be emailed to the social
engineer immediately. Information will be lost.
E- mail can be used for more direct means of gaining access to a system. For instance, mail
attachments sent from someone who appears to be legitimate can carry viruses, worms
and Trojan103 horses. A good example of this was a recent AOL hack, documented
by VIGILANTe 104 : “In that case, the hacker called AOL’s tech support and spoke with
the support person for an hour. During the conversation, the hacker mentioned that his car
was for sale cheaply. The tech supporter was interested, so the hacker sent an e-mail attachment
‘with a picture of the car’. Instead of a car photo, the mail executed a backdoor exploit that
opened a connection out from AOL through the firewall. Through this combination of social
engineering and technical exploitation, the hacker gained access to the internal network.”
Moreover, one can easily fake e- mail reply- to addresses, hence creating an impression of trust; it
is then just a matter of knowing from whom the e- mail must originate in order to gain access to
sensitive data.
Common Social Engineering Methods
Posing as a fellow employee
Posing as an employee of a vendor, partner company, or law enforcement
Posing as someone in authority
Posing as a new employee requesting help
Posing as a vendor or systems manufacturer calling to offer a system patch or update
Offering help if a problem occurs, then making the problem occur, thereby manipulating the victim to call
them for help
Sending free software or patch for victim to install
Sending a virus or Trojan Horse as an email attachment
Using a false pop-up window asking user to log in again or sign with a password
Capturing victim keystrokes with expendable computer system or program
Using insider lingo and terminology to gain trust
Offering a prize for registering a Web site with username and password
Dropping a document or file at company mail room for interoffice delivery
Modifying fax machine heading to appear to come from an internal location
Asking receptionist to receive then forward a fax
Asking for a file to be transferred to an apparently internal location
Getting a voice mailbox setup so call-backs perceive attacker as internal
Pretending to be from remote office and asking for email access locally
Table 1. Common SE Methods. Attackers will typically use one or more methods from this table
in order to gain access to locked systems.
103
A destructive program that masquerades as a benign application. Unlike viruses, Trojan horses do not replicate
themselves but they can be just as destructive. One of the most insidious types of Trojan horse is a program that
claims to rid your computer of viruses but instead introduces viruses onto your computer.
104
Independent Documentation: http://www.vigilante.com/inetsecurity/socialengineering.htm; News.com review:
http://news.com.com/2100-1023-242092.html?legacy=cnet&tag=st.ne.1002.thed.ni
- 56 -
Example of System Penetration
The following example of multiple-point attacks on the same firm is described in Kevin Mitnik’s
“The Art of Deception” on pages 92-94.
New employees are a ripe target for attackers. They don’t know many people yet, they don’t
know the procedures or the dos and don’ts of the company. And, in the name of making good
first impression, they’re eager to show how cooperative and quick to respond they can be.
Helpful Andrea
“Human Resources, Andrea Canhoun”
“Andrea, hi, this is Alex, with Corporate Security”
“Yes?”
“How’re you doing today?”
“Okay. What can I help you with?”
“Listen, we’re developing a security seminar for new employees and we need to round up
some people to try it out on. I want to get the name and phone number of all the new hires
in the past month. Can you help me with that?”
“I won’t be able to get to it ‘til this afternoon. Is that okay? What’s your extension?”
“Sure, okay, it’s 52… oh, uh, but I’ll be in meeting most of today. I’ll call you when I’m
back in my office, probably after hour.”
When Alex called about 4:30, Andrea had the list ready, and read him the names and
extensions.
A Message for Rosemary
Rosemary Morgan was delighted with her new job. She had never worked for a magazine before
and was finding the people much friendlier that she expected, a surprise because of the neverending pressure most of the staff was always under to get yet another issue finished by the
monthly deadline. The call she received one Thursday morning reconfirmed that impressions of
friendliness.
“Is that Rosemary Morgan?”
“Yes.”
“Hi, Rosemary. This is Bill Jorday, with the Information Security group.”
“Yes?”
“Has anyone from our department discussed best security practices with you?”
“I don’t think so.”
“Well, let’s see. For starters, we don’t allow anybody to install software brought in from
outside the company. That’s because we don’t want any liability for unlicensed use of
software. And to avoid any problems with software that might have a worm or a virus”
“Okay.”
“Are you aware of our e-mail policies?”
“No.”
“What’s your current e-mail address?”
“[email protected]”
“Do you sign in under the name Rosemary?”
“No, it’s R-underscore-Morgan”
“Right. We like to make all our new employees ware that it can be dangerous to open any
email attachment you aren’t expecting. Lots of viruses and worms get sent around and
they come in e-mails that seem to be from people you know. So of you get and e-mail with
an attachment you weren’t expecting you should always check to be sure the person listed
as sender really did send you the message. You understand?
“Yes, I’ve heard about that.”
- 57 -
“Good. And out policy is that you change your password every ninety days. When did you
last change your password?”
“I’ve only been here three weeks; I’m still using the one I first set.”
“Okay, that’s fine. You can wait the rest of the ninety days. But we need to be sure people
are using passwords that aren’t too easy to guess. Are you using a password that consists
of both letters and numbers?”
“No.”
“We need to fix that. What password are you using now?”
“It’s my daughter’s name – Annette.” [SE logs in]
“That’s really not a secure password. You should never choose a password that’s based
on family information. Well, let’s see… you could do the same thing as I do. It’s okay to
use what you’re using now as the first part of the password, but then each time you
change it, add a number for the current month.”
“So of I did that now, for March, would I use three, or oh-three?”
“That’s up to you. Which would you be more comfortable with?”
“I guess Annette-three”
“Fine. Do you want me to walk you through how to make the change?”
“No, I know how”
“Good. And one more thing we need to talk about. You have antivirus software on your
computer and it’s important to keep it up to date. You should never disable the automatic
update even if your computer slows down every once in a while. Okay?”
“Sure”
“Very good. And do you have our phone number over here, so you can call us of you
have any computer problems?”
She didn’t. He gave her the number, she wrote it down carefully, and went back to work, once
again, pleased at how well taken care of she felt.
- 58 -
Evolution of SE in relation to Internet Security
Social Engineering is far from a novel concept. It has probably existed for centuries. In the book
of Genesis we find the story of Jacob, who tried to gain patrimony from his father at the expense
of his older brother. Jacob used an early form of Social Engineering to disguise himself as his
brother, and fool his father. This example could be used to name Jacob an early hacker. Without
complicating his conquest by technology, which would be available to modern-day hackers, he
employed an effective tool: SE. More recently, the first telegraph interceptors also conned their
way through using social engineering. This ‘science’ has gained significantly more attention with
the emergence of the Internet, despite the fact, that little information connected to real life cases
is available.
One of the first documented SE attacks on network security took place in 1978, when Stanley
Mark Rifkin talked an employee of the Security Pacific National Bank into transferring 10 200
000$ to an offshore account. Unfortunately accounts of this “attack” vary, since Rifkin has never
told the story in full. From some accounts, he was working for a company under a contract to
develop a backup system for the wire room’s data in case the bank’s main computer ever went
down. This gave Rifkin a unique opportunity to learn how the bank handled its financial
operations. He had learned that bank employees were given a special security code every day to
order wire transfers over the phone. In the wire room, the clerks saved themselves the trouble of
memorizing a new code everyday by simply writing the code on a slip of paper and posting it
somewhere where they could see it easily. Once Stanley arrived in the transfer room in order to
check the wiring from the main computer, he has memorized the current code. The very same
day, Rifkin placed a phone call to the transfer room in the name of another branch of the bank
and instructed the clerk to wire “Ten Million, two hundred thousand dollars exactly” to the
Irving Trust Company in New York, for credit of the Wozchod Handels Bank of Zurich,
Switzerland, where he had already established an account. The next day, Rifkin left the country.
He robbed a bank without guns and almost no technical knowledge, using solely information
manipulation.
The IT world became much more aware of Social Engineering as Kevin Mitnick started hacking
US corporate networks in the early 80s, most of the time simply to satisfy his own curiosities.
Short Story of Kevin Mitnick
“You could spend a fortune purchasing technology and services from every exhibitor, speaker
and sponsor at the RSA Conference and your network infrastructure could still remain vulnerable
to old- fashioned manipulation.”105
Kevin David Mitnick, born August 6th , 1963, was once labeled “the most wanted computer
criminal in U.S. history” and is, in fact, one of the most famous criminal hackers to be jailed and
convicted. Mitnick’s last arrest was by the FBI on February 15th , 1995, when he was charged
with breaking into some of the United States’ most “secure” computer systems. He was released
from prison in January 2002, but banned from using the Internet until the midnight of January
21st 2003. On the live television show The Screen Savers on TechTV, Kevin Mitnick visited the
first website since his release, Labmistress.com, the weblog of his girlfriend, TechTV producer
Darci Wood. Mitnick is now working in consulting and is CEO of the security company Mitnick
Security Consulting, LLC (formerly known as Defensive Thinking).
His arrest is detailed in the book Takedown: The Pursuit and Capture of Kevin Mitnick,
America's Most Wanted Computer Outlaw-By the Man Who Did It 106 . Other media inspired by
105
Mitnick, Kevin: “My first RSA Conference” Security Focus, April 30, 2001
- 59 -
Mitnick's story include the movie, also with the name Takedown, released in the U.S. as Track
Down, sometimes mistitled as Hackers 2: Takedown. A counterpoint view to the events
surrounding Mitnick was written by journalist Jonathan Littman, in The Fugitive Game: Online
with Kevin Mitnick 107 .
Below is a short chronology of Mitnick’s “evolution”:
Late seventies: As personal computers have not yet emerged, a prevailing form of “hacking” was
phone phreaking, which is closely related to hacking, yet the target is a phone system. Typically
phone phreaking was used to make free calls or to make calls charged to a different account.
While trying to trick phone systems, Mitnick first encountered what he would eventually call
Social Engineering. He realized, that tricking (deceiving) a company employee into manipulating
the phone system or revealing some sensitive information was easier, than trying to exploit the
system on the technical front.
1980s: Mitnick successfully breached into the central database of the school he was studying at.
Although he has had full access to the system, he left the data unchanged, as his main goal was
to gain access to the system. However, the school’s computer manager realized that the system
has been compromised by Mitnick, yet he was not expelled, but instead offered to do a project to
enhance the school’s computer security system. Later, in 1982 Mitnick got caught while stealing
for stealing phone system manuals from the Pacific Bell company. Three month in jail. A couple
of days after his release, he was arrested again for unauthorized access into the ARPANET. The
next five years, it seemed to be that Mitnick did not have any disputes with the law. Yet in 1988
Kevin is sentenced to one year in jail for stealing the source codes to the then proprietary VMS
Operating System.
1990s: After his release in 1990, he seemed to be attempting to reform. He had trouble finding a
computer related job, due to his past reputation, but he finally found work with a private
investigation firm called Tel Tec Investigations, where he inevitably mastered and sharpened his
Social Engineering skills 108 . Rumours said, that Mitnick stopped using computers to hack into
corporate networks and fully switched to Social Engineering, as he thought that lying to people
on the phone could not be considered as anti- lawful behaviour. It is known, that Mitnick is held
responsible for breakins into the FBI network in the late 1992, however, this has never been
proved, yet a warrant for Mitnick’s arrest is issued (see fig. 1 on next page).
106
Shimomura T., Markoff J., Takedown: The Pursuit and Capture of Kevin Mitnick, America's Most Wanted
Computer Outlaw-By the Man Who Did It, Warner Books Inc, 1998
107
Littman J., The Fugitive Game: Online with Kevin Mitnick , Little Brown; 1st Pbk edition, 1997
108
Hafner K., “Kevin Mitnick, Unplugged”, Esquire, 1995, August, p.81-88
- 60 -
Fig 5. Warrant on Mitnick
From that time onward, Mitnick was on the run from the FBI. Some of the computer systems that
he is suspected of invading include: California Dept. of Motor Vehicles, an Army computer
system, Motororla's Cellular Division, Nokia, SUN Microsystems, the Pentagon and “The
Well”109 . Then on December 25, 1994, Mitnick hacked into the home computer of Tsutomu
Shimomura, a well known security expert. Shimomura became affected with Mitnick’s capture,
and created trap, which Mitnick inevitably fell into. On February the 15th , 1995, Mitnick was
arrested by caught, while navigating through Tsutomu’s computer.
As a cracker, Mitnick is best known for his use of social engineering. He wrote a book on this
subject after leaving prison but before returning to the Internet: The Art of Deception:
Controlling the Human Element of Security. It was published in October 2002. The first chapter
of the book was omitted by the publisher. It gives some details of his own “career” and his
grievances against journalist John Markoff (a co-author of the book Takedown: The Pursuit and
Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw-By the Man Who Did It).
The chapter has since been made available elsewhere. Its sequel, The Art Of Intrusion: The Real
Stories Behind The Exploits Of Hackers, Intruders, And Deceivers 110 was published on February
11, 2005.
109
Sussman V., “Gotcha! A Hard-Core Hacker Is Nabbed”, U.S. News & World Report, 1995, February, p.66.
Mitnick K., The Art Of Intrusion: The Real Stories Behind The Exploits Of Hackers, Intruders, And Deceivers,
John Wiley & Sons, 2005
110
- 61 -
Social Engineering in the recent past
No matter how effective Social Engineering is, it is paid little attention by IT managers and
system administrators. People tend to ignore the fact, that a security system is only as strong as
its weakest link, this being the employees operating this system. For example, there were over
15 000 registered attendees at the annual RSA conference 2003 (the world’s leading information
security conference and expo 111 ), yet not a single exhibitor concerned themselves with Social
Engineering, neither were any presentations made in this field. It has not been made clear that in
cases when the goal of the company is to protect its network, it cannot rely on computer
technology alone. The reason SE was so unpopular amongst IT professionals is because this
particular “science” is perceived as a soft-skill, studied by psychiatrists. The technique was
studied by Dr. Robert B. Cialdini (Regent's Professor of Psychology at Arizona State University
referenced many times by Mitnick) described in his book “Influence (rev): The Psychology of
Persuasion”, where he emphasized the “six tendencies of human nature” (see table 2) that can be
exploited in order to obtain compliance to a request. These six tendencies are those, that social
engineers will mainly rely on, when trying to misdirect another person. However the author has
not though of manipulative skills being of any danger to IT systems. SE must be given as much
attention as installation of network firewalls and usage of hard-to-guess passwords.
Human Tendency
Authority
Explanation
Usually people will comply to requests
stemming from someone in authority without
further questioning.
Liking
People have a tendency to comply when the
person making the request was able to establish
some sort of sympathy or liking towards
him/her.
Reciprocation
It is common amongst humans that we feel like
owing someone a favor, once he/she has
helped us out or solved one of our problems.
Consistency
Once we have promised something, we do not
want to appear untrustworthy, hence we
usually will stick to our promises, even if they
were made to complete strangers.
Social Validation
Group think may be misleading, as we tend to
take decisions more easily when it appears that
everyone else has taken the very same
decision.
Scarcity
How many times have you fallen for a
“bargain”? People have a tendency to take
unthought-of decisions when the object sought
is in short supply and others are competing for
it.
Table 2: Six tendencies of human nature. Hackers will mainly rely on these tendencies when
trying to misdirect another person into disclosing sensitive information.
Combat strategies against SE
Ensuring corporate security is a question of obtaining the right balance. Having too little security
puts the company’s main asset – information at great risk, whereas too much security makes it
difficult for the business to function. Company managers must aim to achieve the optimal
111
http://www.rsaconference.com
- 62 -
security balance, by establishing a smart security policy, which will do no harm to the business,
at the same time keeping off attacks. Combat strategies require both action and resources,
stressing employee training. The mistake many corporations make is only planning for attacks
on the physical side. That leaves them wide open for the social-psychological attack. To begin,
management must understand the importance of developing and implementing security policies
and procedures. Management must understand that all of the money they spend on software
patches, security hardware and audits will be a waste of resources without adequate prevention
of social engineering attacks 112 . One of the main advantages of such policies is that the y remove
the responsibility of employees to make judgement calls regarding a hacker's requests. If the
requested action is prohibited by policy, the employee has no choice but to deny the hacker's
request.
Strong policies can be general or specific, but again a balanced approach is to be recommended.
This gives the policy enforcers some flexibility in how procedures will develop in the future,
but limits staff from becoming too relaxed in their daily practices. The security policy should
address issues suc h as information access controls, the setting up of accounts, access approval,
and password changes. Modems should, where possible, be avoided in a company intranet.
Locks, IDs, and shredding should be required. Violations should be posted and enforced. As
mentioned at the start of this chapter, the Help Desk is a major target for social engineering
attacks, primarily because their job is to disclose information that will be helpful to users.
The best way to protect the Help Desk against social engineering attacks is through training.
The employees should absolutely refuse to give out passwords without authorization. (In fact,
it should be organizational policy that passwords should never be disclosed over the phone or by
e-mail; rather, they should only be disclosed in person to trusted, authorized personnel.)
Callbacks, PINs, and passwords are a few recommended ways to increase security.
The importance of training employees extends beyond the Help Desk across the entire
organization. According to Naomi Fine, expert in corporate confidentiality and President
and CEO of Pro-Tec Data113 , employees must be trained on “how to identify information which
should be considered confidential, and have a clear understanding of their responsibilities
to protect it”. In order to be successful, organizations must make computer security an integral
part of every job, regardless of whether the employees engages with computers 114 . Everyone
in the organization needs to understand exactly why it is so crucial for the confidential
information to be designated as such, which is why it benefits organizations to give each
employee a sense of responsibility for the security of the entire network.
In general, Kevin Mitnick provides a set of strategies and policies a company may want to
implement against Social Engineering attacks in his book – “The Art of Deception”.
112
Nelson, Rick: “Methods of Hacking: Social Engineering,” the Institute for Systems Research, University
of Maryland
113
http://www.protecdata.com/
114
Harl: “People Hacking: The Psychology of Social Engineering” Text of Harl’s Talk at Access All Areas III,
March 7, 1997.
- 63 -
Conclusion
A widespread thought is that hackers of the past got all their information by hacking corporate
network servers and accessing their databases. The belief is usually that they use superb hacking
skills to get into locked out networks, however this common stereotype is misleading. Indeed,
one needs to have a set of technical skills to navigate through foreign systems, nevertheless the
story of Kevin Mitnick clearly illustrates that one also needs to possess a set of soft skills to
break the human firewall. Although technology has evolved dramatically since Troy, the
underlying principles in obtaining access to locked out systems have remained the same.
However, there is still no clear solution on how to protect oneself from old- fashioned
manipulation. Most IT managers are not fully aware of the potential danger stemming from the
people, who operate the security of the network. Making intense use of the technology alone will
not solve the problem. Protection against SE is actually more about psychological solutions
paired with electronic possibilities and new technologies, simply because it deals with people. As
long as employees are not aware that they are committing to the overall security of the
company’s network, it will remain open to the outside world. Once SE concepts are no more
obscure to an average system administrator, the overall level of awareness will be raised and less
systems will be compromised. A good start may be to run SE sessions during the annual RSA
conference, however, it may be a rough start, as many IT professionals will fail to see a
connection between psychology and technology. Nonetheless, it is not the technology that
guarantees security, it is the people, who operate that technology.
Chapter Summary
•
•
•
•
•
•
•
•
•
•
•
IT specialists have developed information-security solutions to minimize the risks
connected with the use of computers, yet left unaddressed was the most significant
vulnerability, the human factor. Humans remain the most serious threat to each other’s
security.
No security system can stop an intruder if he/she can deceive someone, who is in charge
of operating the system, into letting him into the system.
Most Social Engineering attacks are conducted over the phone, where the attacker
pretends to be someone inside the company and collects small pieces of information to
gain access to the system. Other well known methodologies include fake web-pages that
are used to collect passwords and e- mail, where users are tricked into revealing personal
information.
First documented SE attack was conducted in 1978 by Stanley Rifkin. He talked a bank
manager into transferring 10 million dollars into Stanley’s account.
Most popular SE, however, is Kevin Mitnick, who managed to break into virtually every
corporate network in the USA using SE techniques.
Kevin Mitnick, was once labelled “the most wanted computer criminal in U.S. history”.
Mitnick began his “career” as social engineer in the late seventies, however he was
caught in 1989 and convicted to one and a half years imprisonment.
Mitnick did not quit his “job” after release, he was hunted down by FBI in 1995. Today
he runs a successful US company “Defensive Thinking Inc.”
Social Engineering was studied by psychologists in the late nineties, and six tendencies
of human nature were discovered that make SE possible: Authority, Liking,
Reciprocation, Consistency, Social Validation and Scarcity.
SE is extremely hard to combat; however, well-designed policies can prevent most of SE
attacks. Yet human nature cannot be changed.
In general, Kevin Mitnick provides a set of strategies and policies a company may want
to implement against Social Engineering attacks in his book – “The Art of Deception”.
- 64 -
Chapter 5
- 65 -
Chapter 5 — Attacking the Client
As already outlined in chapter one, there are five main parts to Internet Security, which can be
attacked. These are: the Web Server, the server operating system, the transport channel, the
client machine and the people operating all the parts of this system. A company may install the
latest Unix patches on its servers and force employees to use cryptography, when passing
sensitive data over the net. A company may have excellent security policies, preventing 99% of
all possible security breaches. However, the clients 115 , which are exchanging information with
servers, have a high potential of being misused by attackers, as they are usually used by nontechnical users. Typically an attacker will trick the user into installing a malicious application
such as a trojan (explained later), that will aid the attacker in misusing the system, or even
breaking into the corporate network. Computer Security experts have long been aware of the
threat from malicious code, or malware, the term itself goes back many years 116 . Before touching
on evolution of common client side attacks, there is a need for some basic definitions to be made.
There is much confusion about what a virus is versus what a worm or a trojan is. I hope the
definitions below will shed some light on common misinterpretations; Denning117 provides a
general discussion of these terms.
A virus is a program, which a lot like biological viruses, hides itself in files of other programs.
When the host program is run, the virus is also executed, it then looks for other files that are not
infected on the system and copies itself into them. Therefore, if any of the infected files are
moved to another computer the virus will spread itself in the new environment. Computer viruses
are not inhe rently malicious, but they can be programmed to wake up at a certain time and cause
damage to the infected machine, that is they can contain a logic bomb or a time bomb 118 .
A trojan is a program that appears to be doing something interesting or useful. However, while
the innocent looking program is running, it is actually doing something malicious in the
background. The name itself comes from the well known trojan horse the Greeks left as a present
for the Trojans, which hid soldiers, who opened the gates to Troy for the Greek army. Typically
trojans are spread over e-mail in form of simple applications such as screensavers. Unaware
users install them, and while the screensaver shows pretty pictures, the program may be scanning
or erasing files in the background. A common feature amongst trojans is the introduction of a
backdoor, which allows someone to control the infected computer from a remote location.
A worm is a program that copies itself over networks without explicit interaction of the user.
Usually the growth rate of infection is exponential, as the number of infected hosts doubles with
every infection cycle. Worms can spread over e-mail in form of macro-commands (discussed
115
The client part of a client-server architecture. Typically, a client is an application that runs on a personal
computer or workstation and relies on a server to perform some operations. For example, an e-mail client is an
application that enables you to send and receive e-mail. Client-Server Architecture is a network architecture in
which each computer or process on the network is either a client or a server. Servers are powerful computers or
processes dedicated to managing disk drives (file servers), printers (print servers), or network traffic (network
servers). Clients are PCs or workstations on which users run applications. Clients rely on servers for resources, such
as files, devices, and even processing power. Another type of network architecture is known as a peer-to-peer
architecture because each node has equivalent responsibilities. Both client/server and peer-to-peer architectures are
widely used, and each has unique advantages and disadvantages. Client-server architectures are sometimes called
two-tier architectures
116
See the discussion in: Carl E. Landwehr, Alan R. Bull, John P. McDermott, William S. Choi, “A taxonomy of
Computer Program Security Flaws, with Examples”, US Navy Report NRL/FR/5542-93-9591, (Nov 19, 1993). p 7.
http://www.cs.mdx.ac.uk/research/sfc/Papers/1994landwehr-acmcs.pdf
117
P. J. Denning. “Computer Viruses”, American Scientist, Issue 76 (May-June) 1988, pp 236-238.
118
A time bomb or a logic bomb is a piece of code that remains dormant in the host system until a certain
“detonation” time or event occurs.
- 66 -
later) or propagate over networks on their own using common weaknesses of attacked systems
such as weak access passwords or bugs in access protocols.
Modern malware, however, may be a composite of any of the above methodologies, for example
a trojan horse may replicate itself by copying its code into other files, hence it can then be also
referred to as a virus. In fact, in case it replicates itself over networks creating new processes or
files to contain its code it can then be generally referred to as a worm.
Viruses and Worms
Early viral programming was used for beneficial purposes. One of the very earliest examples of a
computer network was implemented by Xerox PARC (Palo Alto Research Center). As well as
being useful for common functions we use LANs for today, it was a testbed for the development
of those functions and experiments with others. John Shoch and Jon Hupp, two researchers there
at the time, were interested in the concept of distributed processing119 . Interested parties can read
their publication120 in the Communication of the ACM in March 1982, which looks in detail
upon their research. In short, the specific experimental program they were testing was one that
would examine other computers on the local area network to look for activity. If a computer was
idle after normal working hours, the program would submit a copy of itself to the idle machine.
In this way the original program would spawn multiple copies of itself to idle machines in order
to make use of the CPU time which would otherwise be wasted. The primary intention was to
write programs that would be aimed at solving problems normally submitted to a supercomputer.
By breaking the problem up into small chunks and submitting each chuck to a separate machine
on the network, one would, in effect, have a large program consisting of smaller program
segments working on individual machines. Since biological worms are defined by the fact that
they have segmented bodies, they have called this new type of program a “worm”. However,
their research was not a success, since one night a programming error caused the computers to
which it was submitted to hang. Given that the program was submitted to a great number of
machines over the course of the night, the institution was found to be full of dead computers in
the morning. The program became known as the “Xerox worm”. However, the use of selfreplicating programs for parallel processing was not an entirely new concept at that time. In fact,
John von Neumann, one of the pioneers of the computer age, described 121 reliable selfreplicating programs in the 1940s.
One may be surprised, but a lot of techniques used by viruses and worms nowadays already
existed in the beginning of the eighties and were even published in computer security literature.
The first officially presented computer virus was created by Len Adleman (more famous for
being one of the initial developers of the RSA algorithm and accounting for the “A” in RSA) on
November 3rd, 1983 as an experiment to be presented at a weekly computer security seminar122 .
Adleman is responsible for introducing the term “computer virus”. During the seminar he
substituted the Unix “vd” command with an infected one on a VAX 11/750. This command is
used to display Unix file structures graphically on-screen. Several controls were put in place to
make sure that the virus was kept under control. Dur ing the five tests that were performed at the
seminar, the virus managed to gain full system access in less than an hour. Len was ready to test
119
Refers to any of a variety of computer systems that use more than one computer, or processor, to run an
application. This includes parallel processing, in which a single computer uses more than one CPU to execute
programs. More often, however, distributed processing refers to local-area networks (LANs) des igned so that a
single program can run simultaneously at various sites. Most distributed processing systems contain sophisticated
software that detects idle CPUs on the network and parcels out programs to utilize them.
120
J. Shoch, J. Hupp, “The ‘Worm’ Programs – Early Experience with a Distributed Computation”, Communication
of the ACM, March 1982, pp 172-180. http://portal.acm.org/citation.cfm?id=358455
121
F. Cohen. Trends in Computer Virus Research. 1991, Page 10. http://all.net/books/integ/japan.html
122
F. Cohen. “Computer Viruses: Theory and Experiments.” Computers and Security, Vol. 6, pp 22-35, Elsevier
Advanced Technology Publications, 1987.
- 67 -
his programs on other types of machines such as the VMS system and computer networks.
Unfortunately he was refused permission by the systems administrators, as the term “computer
virus” was little known at that time and no one wanted to risk their system for the unknown. The
following quote 123 by Fred Cohen124 , a pioneer in malicious code research, describes the climate
after the Adleman experiment:
Once the result of the experiments were announced, administrators decided that no
further computer security experiments would be permitted on their systems. The ban
included the planned addition of traces which could track potential viruses and password
augmentation experiments which could potentially have improved security to a great
extent. This apparent fear reaction is typical: rather that try to solve technical problems
technically, inappropriate and inadequate policy solutions are often chosen.
Later, Cohen complained about the denial of further experimentation by the administrators and
the security officer at the facility where the experiments were conducted 125 .
After several months of negotiation and administrative changes, it was decided that the
experiments would not be permitted. The security officer at the facility was in constant
opposition to security experiments, and would not even read any proposals. This is
particularly interesting in light of the fact that it was offered to allow systems
programmers and security officers to observe and oversee all aspects of all experiments.
In addition, systems administrators were unwilling to allow sanitized versions of log
tapes to be used to perform offline analysis of the potential threat of viruses, and were
unwilling to have additional traces added to their systems by their programmers to help
detect viral attacks. Although there is no apparent threat posed by these activities, and
they require little time, money, and effort, administrators were unwilling to allow
investigations.
Cohen, however, was able to conduct experiments with viruses. He also developed a theory for
studying viruses and their effects on computer systems. While mostly investigating viruses in the
early eighties, Cohen also researched various protection mechanisms, most of which are
described in detail in one of his later publications 126 in 1991. It is interesting to note the negative
conclusion in his article 127 : “prevention of viruses is not possible without restricting legitimate
user activities in a drastic way”. Cohen’s conclusion was then further supported by Douglas
McIlroy in his almost classic paper, where he explained how to create a simple, yet devastating
Unix shell virus. After a short programming tutorial McIlroy is leading up to the fact that: “If
you have a programmable computer with a file system inhabited by both programs and data, you
can make viruses. It doesn’t matter what hardware or operating system you are using. Nobody
can stop you.”128 In fact, this statement has been further supported by Ken Thompson’s ACM
Turing Award lecture 129 , where he describes a procedure that uses a virus to install a trapdoor in
the Unix login program. The virus is placed in the C complier and performs two tasks. If it
detects that it is compiling a new version of the C compiler, the virus incorporates itself into the
object version of the new C compiler. If the virus determines it is compiling the login program, it
adds a trapdoor to the object version of the login program. The object version of the login
123
F. Cohen. “Computer Viruses: Theory and Experiments.” Page 31.
Dr. Fred Cohen did extensive theoretical research, as well as setting up and performing numerous practical
experiments regarding viral-type program in the early 80s. Visit his site http://all.net/ for more information.
125
126
F. Cohen. Trends in Computer Virus Research. 1991, http://all.net/books/integ/japan.html
127
128
M. D. McIlroy. “Virology 101”, Computing Systems, University of California Press: Berkeley, CA, 1989, page 4.
129
K. Thompson. “Reflections of Trusting Trust”, Communication of the ACM, Vol. 27, No. 8, Aug 1984, pp. 761763. http://www.acm.org/classics/sep95/
124
- 68 -
program that contains a trapdoor that allows a specified password to work for a specific account.
Whether this virus was ever actually installed as described has not been revealed. However, the
moral is obvious, as Ken Thompson puts it in the conclusion to his paper 130 :
You can’t trust code that you did not totally create yourself. (Especially code from
companies that employ people like me). No amount of source-level verification or
scrutiny will protect you from using untrusted code. In demonstrating the possibility of
this kind of attack, I picked on the C compiler. I could have picked on any programhandling program such as an assembler, a loader, or even hardware microcode. As the
level of program gets lower, these bugs will be harder and harder to detect. A well
installed microcode bug will be almost impossible to detect.
How do viruses and worms work?
This section describes how viruses infect files and what its main components are. In order to
replicate itself, a virus must be permitted to execute code and write to memory. For this reason,
many viruses attach themselves to executable files that may be part of legitimate programs. If a
user tries to start an infected program, the virus’ code may be executed first. However, a new
breed of viruses has appeared recently – called “Macro Viruses” which attach themselves to
documents and are run whenever a document is opened. Macro viruses are described in a little
more detail later in this chapter.
A worm or a virus will typically have two main components: the replication mechanism and the
payload. There are several types of well known replication techniques, e- mail being one of the
favorites amongst virus and worm developers nowadays. The virus, once it lands in a new
environment, will try and e-mail a copy of itself to as many recipients as possible. Usually this is
done simply via exploiting the local address book. Earlier approaches included direct infection
over networks, one of which is described in detail by Douglas McIlroy in his almost classic
paper 131 . McIlroy shows how to program a simple but extremely devastating virus using simple
Unix shell commands. The virus will automatically replicate itself over the local area network
within seconds, and, if triggered, will erase all user data from the infected system. Before
networks became widespread, floppies were the most common medium through which viruses
moved from one machine to another. A number of replication techniques are investigated in
detail in Ludwig’s book – “The Giant Black Book of Computer Viruses”132 .
The second component of a virus is the payload, which may be activated by some sort of trigger
such as a date, an external call from the Internet or some kind of system state. The payload may
do one or more of the bad things listed below:
•
•
•
•
•
•
Make selective or random changes to the user’s data
Lock the network
Steal system resources for some other networked process
Steal or even publish personal data, such as personal crypto keys
Create a backdoor through which the creator of the virus may take over the system later
Record keystrokes to a remote file, thus stealing passwords and private data
The most damaging payloads are usually those, which do their damage very slowly and
imperceptibly. It may take month to notice such a virus being present inside a computer system,
and by the time it is noticed it may be too late. It is, in many cases, even harder to notice
130
K. Thompson. “Reflections of Trusting Trust”
M. D. McIlroy. “Virology 101”
132
M. Ludwig, The Giant Black Book of Computer Viruses, American Eagle Publishers, 1995
131
- 69 -
payloads, which do not cause any harm to the system, as they will only “wake up” when the
system is idle and use free resources for a distributed Internet attack such as Denial of Service or
cracking a long key.
Typically a computer virus will have typical properties inherent to biological viruses: the virus
will need some sort of host to attach itself to. It will “feed” of the host program in terms of
computing resources allocated for that program’s execution. In case the host turns out to be a
privileged process, the virus may very well target the system’s memory system, and thus
replicate over all the files accessing the memory. On the other hand, the virus will replicate by
making copies of itself in all the files accessed by the initial host. In case the host behaves as
expected, the virus may remain unnoticed until it causes some damage to the system. A diagram
illustrating the process of a viruses’ attachment pattern to some host program is shown below
(fig. 5). It order to understand better, how a virus may “attach” itself to a host program, a
diagram133 .
Fig 6: How a virus attaches itself to an executable
Attaching the virus code to text-based executable (such as Unix shell scripts) is trivial, just put
the commands in the beginning or the end of the file 134 , however the obvious disadvantage is that
the virus can be easily detected if anybody happens to view the code 135 . Thus a more common
practice is to create viruses that attach themselves to binary executables. All the instructions
native to the virus are attached to the end of the file, whereas the program starting address
pointer 136 is changed for the one of the virus. Once the malicious code completes its set of
instructions, the execution process will be returned to the beginning of the program. However,
this process will change the file size, hence the virus may be easier to spot. Thus, Tom Duff
explained 137 how to create a very dangerous Unix virus which did not alter file sizes. The basic
idea behind his technique was that operating systems measure file sizes in terms of blocks, each
block being, for example, a length of 1024 bytes. Thus almost every program will have some
“free space” available to fill with malicious instructions, yet not altering the overall file size.
Trojans
The term trojan horse was introduced by James Anderson138 to characterize a particular security
threat. Trojans can be looked at as the oldest form of malware. Back in the early sixties,
133
P. Verma, Virus Protection, Encyclopedia of Information Security (Kluwer, to be published), can be seen under:
http://www.eecs.umich.edu/~pverma/pubs/virus.pdf
134
M. D. McIlroy. “Virology 101”
135
P. Verma, Virus Protection
136
Executable files contain a location called the starting address pointer which points to the first instruction to be
executed and is needed by the operating system to load the binary.
137
T. Duff. “Experience with Viruses on Unix systems”, Computing Systems
138
J. P. Anderson. Computer Security Technology Planning Study. ESD-TR-73-51, Hanscom Field, Bedford, MA,
October 1972
- 70 -
computers were slow and they were shared by groups of users, where every user was allocated a
limited amount of computing resources. Typically students would be at the end of the queue, so,
they wrote small games with a trojan inside, which looked whether the game was executed as a
privileged user, and if so it created additional privileged system accounts with known
passwords. 139 Later, in 1984, Ken Thompson discusses 140 the implications of a Trojan Horse
within the C compiler of a computer. The first large emergence, however, of trojan activity
occurred on AOL, where trojans that stole AOL access passwords began to be distributed.
Indeed, there was even a press release 141 from the US-based National Computer Security
Association (NCSA) 142 , appropriately titled: “NCSA and AOL warn of significant prevalence of
AOL password trojan”, which warned users about this threat. This press release also listed the
names and sizes of files, that were at the time known to be spread as other trojans on the AOL
network.
One can see that the trojan problem is nothing new. For as long as people have been assigning
trust to others, people have been ready and willing to exploit it. As I have stated above, trojans
have a long history. The problem with this, in my opinion, is that people tend to have fixed ideas
about what a trojan can and cannot do – ideas that may no longer be valid in the evolving
Internet community. The net provides new trojans with two vital abilities: the ability to become
widespread in a matter of days; the ability for remote action triggers.
Consider the trojan horse as compared to a virus. While a virus contains the ability to spread
autonomously from one file to another, the trojan relies on a victim either being sent the file
directly from an attacker or obtained the file from an innocent third party. Thus, a virus infection
may be self-sustaining, whereas a trojan is likely to remain isolated. However, as computers
became more and more networked, it has become increasingly easy to distribute a copy of a
trojan to tens of thousands of machines within minutes. Furthermore, little resources are needed
for further infection, as the Internet will aid the trojan in its automatic replication all over the
world. While it is certainly true that the Internet has given anyone the ability to distribute
malware to potentially millions of victims with one point and click operation, this effect is
secondary to the following point: the Internet provides trojan horses (and viruses) with much
more damaging triggers. For example, in The Risks Digest 143 , Fred Cohen wrote:
I just got a look at a Word file (CALIG.DOC) that contains user IDs and passwords to
pornographic sites. In addition to these pointers, it has a trojan horse that finds the
user’s private PGP key ring and ftp’s it to: 209.201.88.110 (codebreakers.org).
The standardization of the desktop platform, such that a single executable will run pretty much
anywhere within the Microsoft product range is, in terms of security, a weakness. The
compatibility makes communication and sharing of software much easier, on the other hand, one
can write a trojan designed around a single API 144 that will have an almost limitless number of
139
R. J. Anderson. Security Engineering. Wiley Computer Publishing, 2001, p. 379
K. Thompson. “Reflections of Trusting Trust”
141
http://www.trendmicro.com/en/about/news/pr/archive/1997/pr062797.htm
142
NCSA (now TruSecure® Corporation) was founded in 1989 to provide independent and objective services to a
rapidly growing and often confusing digital marketplace. NCSA is devoted to computer security issues in
corporations, associations and government agencies worldwide. NCSA is dedicated to continuously improving
commercial computer security through certification, sharing of knowledge and dissemination of information.
http://www.ncsa.com/
143
http://catless.ncl.ac.uk/Risks/20.19.html#subj3
144
Abbreviation of application program interface, a set of routines, protocols, and tools for building software
applications. A good API makes it easier to develop a program by providing all the building blocks. A programmer
puts the blocks together. Most operating environments, such as MS-Windows, provide an API so that programmers
can write applications consistent with the operating environment. Although APIs are designed for programmers,
140
- 71 -
potential hosts. The result is that a trojan does not have to concern itself with isolated damage, it
can now go about allowing intruders into the network. The ability for trojans to essentially
compromise the security of a network is a very dangerous one. While AOL Trojans simply
obtained an account password and send it back to a predetermined e- mail address, more complex
Trojans could simply and easily provide a way into a network for a hacker.
Anti-virus Software
What is anti-virus software? Better, what does one expect antivirus software to do? Initially one
would imagine antivirus software being able to stop viruses. However, this is not possible due to
a number of reasons 145 . Firstly, one wants an antiviral tool to be transparent, that is it has to
work in the background making sure that no malware lands on a protected computer, but then it
is impossible to control the process. Moreover, such a process will need a lot or resources.
Secondly, one wants anti-viral tools to detect not only known, but also unknown viruses. Thanks
to Cohen’s research146 this is now possible in a number of cases such as executable files
unexpectedly changing their size, or ‘vaccinating’ programs, so that the virus thinks that the file
is already infected. These methods have important drawbacks, as not all viruses check if their
targets were already infected, moreover there is a known technique 147 for creating viruses that do
not alter file sizes. Fred Cohen leads a very thorough discussion in his 1991 paper 148 , where he
looks at various virus prevention methodologies, including not only software, but also hardware
modification strategies. In his research, he concludes that our inability to predict systematic
behavior in complex systems is the main obstacle in developing an effective virus prevention
mechanism.
Even though the computer virus problem was first publicly described only in 1984 149 and has
caused little interest from academics, the first anti-virus company – Symantec 150 , was founded
already in early 1982. At that time, the company was mainly focusing on delivering consultancy
services for building secure networks. However, as first malicious viruses were seen in the wild
in the beginning of 1987 151 , Symantec has released its first “virus scanner”, which would search
through all local executable files looking for specific code patterns that may represent a virus.
Assuming that the user of the antiviral scanner updates his/her list of known viruses on a daily
basis, then his system is quite secure, as long as it is not one of the first systems under attack
from some new form of malware. Nonetheless, this approach was rather ineffective as victims of
new viruses had no central authority to report the incidents to. Therefore many viruses had a
good chance to spread, before a single copy could be isolated by Symantec and an antiviral
mechanism could be developed. This situation has changed with the introduction of the
Computer Emergency Response Team152 (CERT) in November 1988 after the Morris worm
incident 153 . New incid ents were immediately reported to CERT, which, in turn notified all the
interested parties of the potential problem.
they are ultimately good for users because they guarantee that all programs using a common API will have similar
interfaces. This makes it easier for users to learn new programs.
145
D. Harley, R. Slade, U. E. Gattiker, Viruses Revealed, McGraw Hill, 2001, pp 140-142
F. Cohen. Trends in Computer Virus Research
147
T. Duff. “Experience with Viruses on Unix systems”, Computing Systems
148
F. Cohen. Trends in Computer Virus Research
149
F. Cohen. “Computer Viruses: Theory and Experiments”
150
http://www.symantec.com/corporate/
151
F. Cohen. Trends in Computer Virus Research, p 1
152
The CERT Coordination Center (CERT/CC) is located at the Software Engineering Institute (SEI), a federally
funded research and development center at Carnegie Mellon University in Pittsburgh, Pennsylvania. Following the
Morris worm incident, which brought 10 percent of Internet systems to a halt in November 1988, the Defense
Advanced Research Projects Agency (DARPA) charged the SEI with setting up a center to coordinate
communication among experts during security emergencies and to help prevent future incidents.
153
http://www.cert.org/meet_cert/meetcertcc.html
146
- 72 -
The establishment of a central authoritative figure to help deal with popping up security
problems spawned a whole new set of antivirus developers, many of which are still in business
today. For example, NCSA (now TruSecure Corporation), founded in 1989, aided the foundation
of the Anti-Virus Product Developers Consortium in July 1991. It is also responsible for the
introduction of the “National Computer Virus Awareness Day” which the Clinton administration
enthusiastically supported 154 . Another blooming company of the 21st century, McAfee Security,
was founded back in 1989, primarily focusing on the development of antiviral tools. Moreover,
McAfee has established its own anti-virus research organization, McAfee AVERT, which
protects McAfee customers against the latest and most complex virus attacks 155 . One of the
other, still known and prosperous antiviral pioneers was formed in 1989 in Russia - Kaspersky
Labs 156 . This company has had a very interesting evolution path, as it was little known outside of
Russia until 1997, when its centre of activity shifted to the USA. Presently Kaspersky Labs is a
group of companies with offices in Moscow, Cambridge (England) and Pleasanton (California,
U.S.A) and a well-developed partner network actively working in the Russian and international
markets.
Recent History – Macro Viruses
By the late 80s and the early 90s PC viruses had become such a problem that the y led to a new
market for antivirus software writers and consultants. Once antivirus companies have appeared,
they have tried to outwit virus writers, thinking of methods, which could be employed to protect
files from infection. Virus writing, on the other hand, has evolved into a science of its own.
Malware used numerous techniques such as polymorphism157 and stealth158 to hide itself from
the user and antiviral tools. The constant evolution of technology and the Internet gave fertile
ground for new viruses. However, many people though that this wouldn’t last, as the move from
DOS towards a proper operating system like windows would spell an end, or at least decrease the
viral problem. Some of the antivirus pioneers even sold their companies159 . While Windows
initially made the job of writing malware harder, even DOS viruses have not lost their
functionality, as the main ideology behind Microsoft products was always backward
compatibility. Customers simply demand it. Programming for any of the Windows platform is
significantly harder than programming for DOS. For that reason, and the greater hardware
requirements, the first Windows viruses didn’t appear for years after the popular acceptance of
Microsoft’s new operating system. Initially, some believed Windows had defeated computer
viruses, but that wasn’t the case. In fact, with the release of Windows 95 alongside with the
popular Office 95, Microsoft gave birth to a whole new breed of malware – macro viruses, which
in May 2000, according to Jan Hruska at Sophos160 , accounted for 88% of all infections 161 .
A macro is a series of steps, that could be performed by hand in some application such as MS
Word, but they are stored in a command file so they can be automated. For example, one could
write a macro to close all open documents in MS Word. Initially macros were developed to
154
http://www.ncsa.com/company/milestones/
http://us.mcafee.com/root/aboutUs.asp
156
http://www.kaspersky.com/about.html?chapter=596128
157
Polymorphism is virus encryption done better. Some bright virus writers decided that the only way to defeat
antivirus companies was by randomly changing the encryption/decryption portion of a virus. How can antivirus
scanners find a signature when everything, including the encrypting subroutine, randomly changed? Potentially,
there are billions of combinations that scanners would have to try against each host file.
158
Viruses that contain special coding to elude antivirus researchers and tools are considered stealth viruses. One of
the most common routines is for a virus to remove itself from a file when a virus scanner is being run.
159
A. Solomon, “A Brief History of Computer Viruses”, Computer Fraud and Security Bulletin, Dec 1993, pp 9-19
160
http://www.sophos.com/
161
Jan Hruska, “Is the Virus Problem getting worse?”, Network Security, Volume 2001, Issue 2, 1 February 2001,
Pages 13-16
155
- 73 -
speed up common actions, however, they have evolved into a very powerful programming
environment of their own. Nowadays, some software programs are nothing but thousands of
macros built around a vendor’s application. For example, all of the available “Plug-Ins” for MS
Outlook are no more than a set of very elegant macros. In fact, allowing Outlook to use the
macro functionality of MS Office made it an ideal replication mechanism for malware. A
definite advantage of macro viruses as opposed to classic virus is the fact, that users rarely trade
applications, but very often they will exchange data- files. In fact, usual attachments in corporate
mail are MS Office documents, and since Office 95 they can all carry viruses. Macro Viruses
took over as the main source of infection in the United States in 1996, and in other countries
shortly after 162 . Interestingly enough, security analysts have predicted a splash of macro-virus
popularity, already in 1996 Charles Babcock wrote an interesting article 163 in Computerworld
where he discussed the large potential of macros being embedded within data files. Moreover, he
pointed out the immense speed with which macro viruses gained popularity compared to
classical “parasite” viruses: “It normally takes three to four years for a virus to climb in to the
top 10. Word Concept [Macro] did it in six months.” There is a good discussion on macro
viruses in V. Bontchev’s paper164 , which also points out that stopping them is harder than was
the case for DOS viruses, as the Microsoft programming environment is now much less open,
less well documented, and complex. In another paper 165 , published in early 1998 Bontchev
points out that it is a very hard, if not impossible task for antivirus vendors to produce a feasible
toolkit to stop macro viruses, as simple file scanners may produce a lot of false negatives.
Antivirus vendors knew since 1989 that macro viruses were possible 166 and it is rather interesting
that they did not take off with Lotus 1-2-3 or WordPerfect in the early nineties, as these
programs have had excellent support for built- in scripts. Perhaps because these applications did
not have a very large market share. Yet, Microsoft Word seemed to be the right application for
virus developers, with the first malicious macros appearing in 1995 167 . By the end of 1996,
Microsoft Office macro viruses have infected Windows computers all over the world. One does
not need a lot of programming skills or technological know-how to create dangerous macro
viruses. All one needs is a language that can manipulate itself and other files. Malware creators
like macro languages because they are easy to use and are potentially very powerful. Most macro
writers learned to write their first code in hours. Macro languages are written to be easy, so the
end-developer does not have to worry about all the high- tech stuff and get straight the point – do
some damage. Moreover, macros as opposed to other types of malware, are platform
independent, as all the system specific porting is done by the application that is executing the
script. Hence any system capable of running Microsoft Office is under potential threat.
Why Windows?
There were certainly quite a few virus incidents, which the media has focused its attention on168 .
However, most of the cases investigated were linked with the Windows operating system.
Therefore, an interesting question arises: why did so many viruses hit the Microsoft platform as
opposed to Unix, even though first experiments with malware were carried out under Unix?
According to Spylog169 , an independent statistical service provider in eastern and western
Europe, on average 95% of all Internet surfers are using Microsoft Windows as their operating
162
D. Aubrey-Jones, “Internet – Virusnet?”, Networking Security, Feb 1997, pp 15-19
Charles Babcock, “Beware of a macro virus epidemic”, Computerworld, July 18, 1996, p. 122
164
V. Bontchev, “Possible Macro Virus Attacks and How to Prevent Them”, Computers and Security, v 15 no 7,
1996, pp 595-626.
165
V. Bontchev, “Macro Virus Identification Problems”, Computers and Security, v 17 no 1, 1998, pp. 69-89
166
Harold Highland, “A Macro Virus”, Computers and Security, v 8, 1989, pp. 178-188
167
Paul Robinson, “Word is out on virus that attacks macros”, Computer Weekly, 31 August 1995, p. 10
168
Melissa, I LOVE YOU, and recently My.Doom
169
Spylog Global Research, http://gs.spylog.com/
163
- 74 -
system. Hence, producing malware, that has the potential to affect 95% of the Internet is a
reasonable objective. Moreover, Windows is a monoculture, meaning that applications written
for this operating system will work on any PC and produce expected output, whereas there are
different flavors of Unix, each with its own specific set of commands. Add to that, the everyday
evolving linux world. Currently there are slightly over a hundred official linux platforms 170 , for
which programs have to be specifically compiled for. Besides that, Windows and MacOS are the
only platforms capable of running Microsoft Office, which has become de facto standard for
word processing and spreadsheet production. In fact, this makes the situation even worse, since
MS Office is an ideal host for macro viruses, which are the prevalent form of malware today.
Furthermore, all windows platforms are backward compatible, they are even capable of
executing programs written over a decade ago for the DOS operating system. This leaves a
chance for infection by any of the older classic viruses. Whereas under Unix, most if not all
programs have to be compiled from scratch after every update of the kernel, making current
binaries completely obsolete. The human factor also plays an important role, as an average
windows user will not be savvy in IT171 , therefore being open for social engineering attacks.
While it takes skill to be a productive Unix user.
As a result of all the factors listed above, windows platforms are common malware targets. The
ease of use was implemented sacrificing security, yet it gave windows immense popularity on
the global IT market. Still, Unix has its own weaknesses, such as programs being able to talk to
each other in the background without any feedback to the user. Yet making up only 5% of the
total home Operating System population, Unix is not a common target for malware developers.
Conclusion
Viruses, worms and trojan horses are all security concerns for users of personal computers. This
chapter discussed several of these at length. Most of the malware we have heard of in the media
was, in fact, developed out of curiosity and tailored to hit as big population as possible.
However, the real threat comes from malware targeted on a specific organization or even a
specific host on the network. These kind of attacks canno t be stopped with the aid of an antivirus program or by following a security bulletin, instead a preventive strategy has to be
developed. Diversity of software is the safest way to protect from the virus of the day. In the
cryptographic community, it is important to use well-known, proven protocols and algorithms
with off- the-shelf implementation. The same does not always hold for system software. In the
latter case, using a self- made proprietary implementation is sometimes the safest way to go.
Moreover, preventing client side attacks takes end-user awareness. The nature of things that
users need to be trained to do, or not to do, will change over time as systems and threats evolve.
For example, in the early nineties, the main tasks were to stop infections coming from home PCs
via floppy disks. Now the issues are more diffuse, such as training people not to open e- mail
attachments unless the sender has verified actually sending an e- mail with an attachment in it, or
having procedures to deal with infected backups. However, one cannot be 100% secure against
170
http://directory.google.com/Top/Computers/Software/Operating_Systems/Linux/Platforms/
The Windows Operating System is a common OS for home use (and it has been positioned and developed to be
an excellent tool for home use). It is easy to install and inexperienced users can get hold of most computer
functionality within a few days. Yet it does not provide any background knowledge to its users as to how Operating
Systems work and does not offer a lot of information about its internal processes. A whole population of Internet
users has1 been raised on Windows based machines without knowledge of how the system works overall. Moreover,
this population has been pushed to use Internet Explorer as a default browser shipped with windows, and the
popularity of this platform just proves the fact, that on average almost every Windows user will do whatever the
system tells him/her to do. Yet the analysis of the rise of popularity of IE is out of the scope of this thesis, however,
it is a good indication of the number of www users browsing the set under MS technology. The Windows OS has
been built in order for work to be done as fast as possible, therefore corporate user’s knowledge of IT usually ends
with the know-how of MS Office and Windows.
171
- 75 -
malware, yet a well-developed preventive strategy can keep most of incoming attacks out of the
system.
Chapter Summary
•
•
•
•
•
•
•
•
•
•
•
•
•
Computer Security experts have long been aware of the threat from malicious code, or
malware, the term itself goes back many years. Malware is a common reference term for
viruses, trojans and worms.
A virus is a program, which a lot like biological viruses, hides itself in files of other
programs. When the host program is run, the virus is also executed, it then looks for other
files that are not infected on the system and copies itself into them.
A trojan is a program that appears to be doing something interesting or useful. However,
while the innocent looking program is running, it is actually doing something malicious
in the background.
A worm is a program that copies itself over networks without explicit interaction of the
user.
One of the very earliest examples of a computer network was implemented by Xerox
PARC (Palo Alto Research Cent er). John Shoch and Jon Hupp, two researchers there at
the time, were interested in the concept of distributed processing. The primary intention
was to write programs that would be aimed at solving problems normally submitted to a
supercomputer. By breaking the problem up into small chunks and submitting each chuck
to a separate machine on the network, one would, in effect, have a large program
consisting of smaller program segments working on individual machines. Since
biological worms are defined by the fact that they have segmented bodies, they have
called this new type of program a “worm”.
Their research was not a success, since one night a programming error caused the
computers to which it was submitted to hang. The program is known as the “Xerox
worm” and is the first documented example of a computer worm.
A lot of techniques used by viruses and worms nowadays already existed in the
beginning of the eighties. The first officially presented computer virus was created by
Len Adleman on November 3rd, 1983
Fred Cohen is a pioneer in malicious code research. He researched computer viruses and
various protection mechanisms and his work is used as ground stones in antiviral
industry today.
The term trojan horse was introduced by James Anderson to characterize a particular
security threat. Trojans can be looked at as the oldest form of malware.
Back in the early sixties, computers were slow and they were shared by groups of users,
where every user was allocated a limited amount of computing resources. Typically
students would be at the end of the queue, so, they wrote small games with a trojan
inside, which looked whether the game was executed as a privileged user, and if so it
created additional privileged system accounts with known passwords.
A virus contains the ability to spread autonomously from one file to another, the trojan
relies on a victim either being sent the file directly from an attacker or obtained the file
from an innocent third party.
Even though the computer virus problem was first publicly described only in 1984 and
has caused little interest from academics, the first antivirus company – Symantec, was
founded already in early 1982. Yet even nowadays there exists no 100% fail-safe antiviral mechanism.
A more recent breed of computer viruses are macro viruses. They, compared to
traditional forms of computer viruses, are stored as script inside documents. Documents
- 76 -
•
•
•
circulate the Internet much more frequently than executable files, thus the rate of
infection is exponential.
Most of computer malware in Windows orientated as it is the most widespread OS in the
world.
Worst form of malware is malware custom tailored for an attack at a specific host. These
are virtually impossible to stop.
One cannot be 100% secure against malware, yet a well-developed preventive strategy
can keep most of incoming attacks out of the system.
- 77 -
Appendix A – Melissa
The Melissa virus, a Microsoft Word macro spread over the Internet in early 1999 and caused the
first big media splash about a computer virus since the Morris Worm. There was coverage in
almost every newspaper, radio station or TV channel. It is hard to estimate the damage done by
Melissa, as it did not actually do anything malicious except make copies of itself. However, the
mere fact, that the immense spread of the virus caused a lot of additional Internet traffic can be
perceived as a Denial Of Service attack (see next chapter). Yet, the virus demonstrated the power
of macro languages and the ease with which macro based malware could propagate through the
Internet. Had the original developer David Smith intended to do any damage to the infected
systems such as erasing data, then the virus could have been a real disaster.
CERT Coordination Center states 172 that it started receiving first reports of the Melissa virus at
around 2:00 PM GMT on Friday March 26, 1999. The virus was written in only 107 lines of
Visual Basic, which were embedded into a Microsoft Word document in form of a macro. The
document itself was sent via e-mail in form of an attachment. Once the recipient opened the
document, the macro was launched. The first thing it did was to launch Outlook Express and try
and mail a copy of itself to the first 50 entries in the address book. The transport message has
most frequently been reported to contain the following Subject header: “Subject: Important
Message From <name>”, – where <name> was the full name of the user sending the message.
The body of the message was a multipart message containing two sections. The first section of
the message contained the following text: “Here is that document you asked for ... don't show
anyone else ;-)”, – the next section was initially reported to be a document called “list.doc”. This
document contained references to pornographic Web sites, which is rather logical as the first
known appearance of the Melissa virus was on the newsgroup alt.sex. Parties interested in
the evolution of the Melissa virus and all the information linked with this case can consult
http://www.melissavirus.com/ for a comprehensive list of resources.
Melissa was very effective because people received e- mail messages from someone they knew
and therefore assumed the attached document to be safe. Moreover, the messages were more or
less personalized, which resulted in additional trust to the attached file. After all, who could even
imagine a word document being of any harm? Another contributing factor was the fact that a lot
of people used Microsoft Word not as a stand-alone application, but as part of the Office
package, alongside with Outlook Express. Users who read mail with Netscape Messenger, Pine
or Eudora were completely immune to Melissa. So were Unix and Emacs users. Finally it should
be noted that Microsoft made a mistake by bundling Office applications together with Outlook.
Why did Word have enough privileges to construct and send e- mail? Overall, the Windows
environment leaves space for a lot of imagination in case someone is willing to compromise the
system. The primary lesson learned from Melissa, is that as with any other aspect of Internet
Security, the foundation always relies on implicit trust. Whereas the trust element is often, if not
always, is controlled by a human being.
172
http://www.cert.org/advisories/CA-1999-04.html
- 78 -
Chapter 6
- 79 -
Chapter 6 — Attacking the Web Server
With the increasing use of the Internet as a commercial channel, there are a growing number of
Websites deployed to share information, offer online services, sell all sorts of goods, distribute
news, articles, et cetera. On the other hand, the number of attacks is increasing in parallel: theft
of private information, defacing of homepages, denial-of-service, worm spreading, and fraud, are
a few of the most common attacks on the Internet. In the previous five chapters I have focused
on various attack channels open to hackers: the operating system of the computer connected to
the Internet, the data transportation channels, the client applications and the people operating the
whole system. Web Server 173 software, however, is presumed to be quite secure, as it is the main
driving force behind what we perceive as the Internet today. Yet this feeling of security is in
many cases misleading, as Web Servers, just as any of the previously discussed weaknesses of
Internet systems, can be misused by hackers. Web attacks, i.e. attacks exclusively using the
HTTP 174 protocol, are rapidly becoming one of the fundamental threats for information systems
connected to the Internet. When the attacks suffered by Web Servers over the last decade are
analyzed, it is observed that most of them are very similar, using a reduced number of attacking
techniques. In an effort to create a common reference language for computer security analysis, a
number of taxonomies of computer attacks have appeared in recent years175 . Yet, these
taxonomies are rather complex and presume the reader to be technically savvy in the subject.
However, by far not every user is able to understand the concepts outlined in these taxonomies
without a set of prerequisite concepts, which I am aiming to provide. This chapter is a short
study of Web Server software and the most common attack techniques employed by hackers
over the past decade in order to commit some kind of malicious act. The first part of the chapter
is a short investigation into the technical side of Web Servers and server side software
applications, where various weak points are outlined and discussed in further detail. The second
part of the chapter focuses mainly on Denial of Service attacks, which, ironically, have little to
do with the actual Web Server and its security implementations, however, they are aimed at
making the Web Server unavailable to the Internet population for a limited period of time, thus
slowing down or completely disabling public services operated by that server. A set of common
defense techniques are summarized in the final part of this paper. I hope that the basic concepts
of Web Server operation and its most common weak points will be absolutely clear to the
average Internet user after reading this chapter.
173
A computer that delivers (serves up) Web pages. Every Web Server has an IP address and possibly a domain
name. For example, if you enter the URL http://www.warwick.ac.uk/ in your browser, this sends a request to the
computer whose domain name is warwick.ac.uk. The Web Server software on that computer then fetches the default
index page and sends it to your browser. Any computer can be turned into a Web Server by installing server
software and connecting the machine to the Internet. There are many Web Server software applications, including
public domain software from NCSA and Apache, and commercial packages from Microsoft, Netscape and others. A
good resource to track the development of various Web Server software packages is http://www.serverwatch.com/
174
Short for HyperText Transfer Protocol, the underlying protocol used by the World Wide Web. HTTP defines
how messages are formatted and transmitted, and what actions Web Servers and browsers should take in response to
the Web Server directing it to fetch and transmit the requested Web page. The other main standard that controls how
the World Wide Web works is HTML, which covers how Web pages are formatted and displayed. HTTP is called a
stateless protocol because each command is executed independently, without any knowledge of the commands that
came before it. This is the main reason that it is difficult to implement Web sites that react intelligently to user input.
This shortcoming of HTTP is being addressed in a number of technologies, including Java, JavaScript and cookies.
175
Such as Cohen F., “Information System Attacks: A preliminary classification scheme”, Computers & Security,
Vol. 16, 1997, pp. 29-46, or Alvarez G., Petrovic S., “A new taxonomy of Web attacks”, Computers & Security,
Vol. 22, 2003, pp. 435-449
- 80 -
Web Servers
Installing a Web Server is really simple: download the software, adjust a few settings and in a
matter of minutes a welcome page will be on the screen. Although the mechanics of this
operation are rather straightforward, the implications are profound. In case the server is
connected to the Internet, it is automatically exposed to the whole world. Unfortunately, this
increased visibility can have some unwanted side effects. Some attackers may attempt to avoid
the server’s access restrictions in order to view confidential documents that are intended for
internal use only. Others may attempt to “Webjack” the Website and modify its content either for
fun or to deliberately embarrass the owner of the site. Webjackings are not uncommon. Sites that
have been vandalized in the past include U.S. Department of Justice, CIA, NASA, British Labor
Party, Telia, Yahoo.com, Amazon.com and many others. Although the immediate damage was
often noticed and repaired in a matter of hours, the effects of Web-site vandalism remain. In each
of the cases thousands of Web surfers noticed the vandalism before the site’s administrators got
their hands on fixing the problem. One can still witness what the CIA’a site looked like just after
they were vandalized (see http://www.onething.com/archive/ for examples). For some
organizations site vandalism may merely be embarrassing, for others, such as financial
institutions, the public knowledge of break-in may permanently damage their reputation. Website vandalism is, of course, just the tip of the iceberg. A much worse threat is if someone who
breaks into the Web Server will use it as a channel to misuse other machines on the local area
network. In this case, the Web Server provided a portal of entry to confidential information
stored on file servers, databases and accounting systems.
Basics of Web Server Operation
In order to shed some light on various weak points of Web Server software, Web applications
and common approaches in exploiting these, it is important to give a short overview of how Web
Servers operate and serve HTML pages to Web browsers. When one types in a URL like
www.warwick.ac.uk into a Web browser, a message that says ‘Connecting to site
www.warwick.ac.uk’ is displayed for a few seconds before the HTML is delivered. This seems
pretty simple, but what happens in the background can be quite complex. A Web Server works
on the client/server principle and provides a specific service of giving out Web pages to clients
called Web browsers. So for a Website like www. warwick.ac.uk, a Web Server would run on a
machine, which will have a unique IP address and will be directly connected to the Internet.
Once started, the Web Server listens for any connection request. Each time a connection is
requested by a Web browser, the Web Server serves the Web browser with content. The Web
Server then continues to listen to subsequent requests from other Web browsers. After a
connection is established, the browser issues an HTTP request in simple text, namely GET,
POST, HEAD or PUT, to the Web Server. The GET method is used to request a Web page (or
any file the Web Server can deliver like audio or video). The POST method is used when the
browser needs to send some data to the server, such as a filled out form. The PUT method is used
by the Web browser to upload data to a location (directory) on the Web Server as specified by
the URL, such as a file. Whereas the HEAD method will be employed to pass content specific
commands to the Web Server, such as document encoding information and acceptable
languages. So, in practice the Web Server does nothing more than send copie s of local files to
Web browsers, or store data received from Web browsers either in a database or in the local file
system.
There is one more dimension to Web Servers – Dynamic Content. At www.google.com, if one
types in the search keywords “Internet Security” and presses the “search” button, the browser
displays a Web page with the results of the search. Next, if one searches for “university of
warwick”, the browser again displays results, which are very different from the former. This kind
of dynamic content is delivered to the browser by the Web Server either by using Common
- 81 -
Gateway Interface (CGI) scripts or by invoking built- in “in-process” parser modules 176 . A CGI
script is usually invoked by the GET or POST method. When the Web Server receives a URL to
a CGI script, it hands over the execution of the script to an external parser, like Perl, C, PHP or
Tomcat JSP engine, along with any parameters supplied. The parser processes the script and
delivers the result, usually as a new HTML page, to the Web Server, which is in turn delivered to
the Web browser. CGI makes Web-surfing a Web-site a very dynamic process, allowing every
user to see a tailored version of the Web page. The applications of CGI are immense, starting
from simple “hacks” such as generation of random content or links, and ending with complex ecommerce platforms, such as one behind amazon.com.
Common Web Server Weaknesses
The problems that open up security holes in Web Servers are various, but most of them spring up
from either server misconfiguration, bugs in Web applications or denial of service attacks.
Server Misconfiguration
All Web Server software, regardless of platform or manufacturer, unintentionally hides a number
of vulnerabilities, which allow the application to be used in a different way than originally
intended. Misconfiguration of software was a common problem even before Web Servers. There
are good accounts of common mistakes in Clifford Stoll’s book “The Cuckoo's Egg” and in
Chapter two if this thesis. Whenever the platform and the Web Server are not correctly
configured vulnerabilities can occur. Moreover, there are Web Servers, whose default
configuration exposes a number of known directories, sample applications, user accounts, et
cetera. When vendors ship a shrink-wrapped system, their primary goal is not to make the system
secure but easy to install and use. As a result, most of the systems ship in their most permissive
mode: popular network services are turned on by default, remote configuration facilities are
enabled and the policy for accessing the file system is very liberal177 .
A widespread problem is misconfigured file permissions. Multi- user operating systems such as
UNIX and Windows NT, use account privileges as their fundamental security mechanism. Each
registered user has a different login account. Each account is associated with a different set of
privileges, granting or denying it the ability to read and write certain files, open network
connections and access network devices. This mechanism gives trusted users, such as system
administrators, the ability to set permissions for other users of the system. The Web Server
running under some operating systems will be executed with a set of privileges of a local system
user. A common mistake made in the past, is the wide set of privileges granted to that user,
therefore granting these privileges to each and every surfer of the Internet. Some sites have even
made the mistake of running the Web Server under an administrative account, effectively giving
the Web Server limitless power over the system it resided on.
Bugs in Web Applications
Many system intrusions talked about in the media were based on a simple strategy where the
attacker sent data to a program that the program couldn’t handle. The legendary Morris Worm178
176
For example, PHP (http://www.php.net/) can be run as both, a CGI executable, or as a Web Server module. As a
CGI executable it can be perceived as a stand-alone program, which parses the data passed to it my the Web Server
“out-of-process” of the actual Client-Server communication. Whereas a PHP module will be part of the Web Server
and process all the code “in-process” of the Web Server serving the page to the browser. Modules are generally
faster and are executed with the same security settings as the Web Server, whereas CGI executables can be set-up to
run with various user permissions, which, if used correctly, can be used to create a secure system, or, in case of
human error, can be an efficient entry point into the system.
177
Based on the default configuration of the Apache Web Server and the MS IIS Server.
178
Mark W. Eichin and Jon A. Rochlis, “With Microscope and Tweezers: An Analysis of the Internet Virus of
November 1988”, Proceedings of the IEEE Symposium on Research in Security and Privacy, 1989, pp 236-343, can
bee seen at http://ieeexplore.ieee.org/
- 82 -
was based on a version of this approach, so was the hole 179 in NCSA httpd version 1.3 for Unix.
Exposures of these kinds are, to some extent, out of the hands of the system administrator, but
trusting input data is a common source of trouble. For example, consider Web forms. Forms
make data gathering at the client side rather straightforward and natural. Having a master form
for, say, some kind of order and sending it to the client’s browser with some data already filled
out is common practice. The user fills out the rest and posts the form back to the Web Server.
The Web Server then, takes action based on the contents of that form, and either processes the
input or prompts the user with some sort of error message. However, once the user input is
processed to be stored in a database or written to a local file, unpredicted behavior may happen,
such as the user entering system commands into form fields. Thus Web Server security is
dependable on the Web scripts and Web applications 180 being executed on that server, regardless
of the technology in which it is implemented or the security of the server or the database on
which it is built 181 . The following vulnerabilities are common to Web Server applications:
Code Injection
Code injection vulnerabilities allow for injecting user-chosen code into a Web script. These
vulnerabilities arise from none-existed or poorly designed input validation routines on the serverside. The main categories of code injection are:
•
•
Script injection: the attack involves Web Servers that dynamically generated HTML
pages via CGI. If these servers embed browser input in the dynamic pages that they send
back to the browser, these servers can then be manipulated to include content on the
dynamic pages that will allow malicious scripts to be executed. This attack, however,
does not modify Website content, rather, it inserts new, malicious script that can execute
at the victim’s browser in the information context associated with a trusted server 182 .
SQL injection: An attacker creates or alters existing SQL commands to gain access to
unintended data or even the ability to execute system level commands on the host 183 .
Canonicalization
Canonicalization vulnerabilities occur when an application makes a security decision based on a
name (a filename, a folder name, a Web address), without having in mind the fact that the name
may be expressed in more than one way184 . The most common way of exploiting these issues is
in the form of path traversal attacks, which allow malicious user to execute commands or view
data outside of the intended target path. These vulnerabilities arise normally from unchecked
URL input parameters, cookies or HTTP requests. For example, carelessly written applications
may display image galleries based on a parameter in the URL pointing to a local file location,
such as “?image=mug”, a simple manipulation of the URL may misdirect the script into
referencing other files on the system – “?image=/etc/.passwd”.
HTML Manipulation
HTML manipulation allows a malicious user to modify data sent between the Web browser and
the Web Server, to which the user was not intended to have direct access. Parameter
manipulation, such as the one described above, is often accomplished though: URL Query
179
CERT Advisory 95-04, can be seen at http://www.cert.org/advisories/CA-1995-04.html
Such as Web-based e-mail clients.
181
D. Scott, R. Sharp, “Abstracting Application-Level Web Security”, WWW2002, May 2002, can be seen at:
http://www-lce.eng.cam.ac.uk/~djs55/swap/abstracting.pdf
182
Microsoft. Cross-site scripting security exposure executive summary. Can be seen at
http://www.microsoft.com/technet/security/topics/ExSumCS.asp
183
For examples see: C. Anley, “Advanced sql injection in sql server applications”, Technical Teport, Next
Generation Security Software, January 2002. Can be seen at
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
184
M. Howard, D. LeBlank, Writing Secure Code, Microsoft Press, 2001, Chapter 12, pp 165-182
180
- 83 -
strings, hidden form fields, cookies. Although it is neglected too often, but parameter
manipulation can be easily prevented with good input validation on the server side.
Denial of Service (DoS)
Denial of Service attacks constitute one of the major threats and are among the hardest security
problems in today’s Internet. In early February 2000, hackers used a specific type of denial of
service attacks, called Distributed Denial of Service, to bring Yahoo, Amazon, CNN.com,
ZDNet, and other well-known Internet sites to their knees185 . The media’s widespread coverage
of these attacks has made this common hacking technique a very well known phrase. A DoS
attack’s objective is to deny a user access to some type of service. In most cases, a DoS attack
uses one computer to flood another computer with network traffic, specifically traffic that
contains confusing messages that cause the victim computer to waste time and resources trying
to understand what it has received. Ultimately, this data invasion can jam the victim computer,
which ties up its communication lines and blocks legitimate visitors. Distributed Denial of
Service is a very simple, yet very effective technique to attack Internet resources. DDoS attacks
add the many-to-one dimension to the DoS problem making the prevention of such attacks more
difficult and the impact much more severe. DDoS attacks were possible from the early days of
the Internet, as they exploit the inherent weakness of the Internet’s architecture: its open resource
access model, which, ironically, also happens to be its greatest advantage. Because of the
seriousness of the problem many defence mechanisms have been proposed to combat these
attacks, however there are pros and cons to every proposed approach, which are analysed in
more detail later in this chapter. It is interesting to note, that even though denial of service
attacks were technically possible from the dawn of the Internet, they became rather popular only
in the second half of the nineties 186 . Probably this is due to the widespread use of the World
Wide Web and mass availability of various public services such as search engines, news portals,
stock quotes et cetera online.
According to the WWW Security FAQ 187 a DoS attack can be described as an attack designed to
render a computer or network incapable of providing normal services. A DoS attack is
considered to take place only when access to a computer or network resource is intentionally
blocked or degraded as a result of malicious action taken by another user. These attacks don’t
necessarily damage data directly or permanently, but they intentionally compromise the
availability of the resources. The most common DoS attacks target the computer network’s
bandwidth188 or connectivity189 . Bandwidth attacks flood the network with such a high volume of
traffic that all available network resources are consumed and legitimate user requests cannot get
through, resulting in a denial of service. Connectivity attacks flood a computer with such a high
volume of connection requests, that all available operating system resources are consumed, and
the computer can no longer process legitimate user requests. For example, a Web Server can be
out of order by a DoS attack focusing on one or more applications running on that server. It is
possible for the attacker to find points of high algorithmic complexity and exploit them in order
185
CERT Coordination Center, Denial of Service attacks, available from
http://www.cert.org/tech_tips/denial_of_service.html
186
This is illustrated by the fact, that the CERT DDoS directive was initially released only in October 1997, as seen
in http://www.cert.org/tech_tips/denial_of_service.html
187
The World Wide Web Security FAQ available from http://www.w3.org/Security/FAQ/
188
The amount of data that can be transmitted in a fixed amount of time. For digital devices, the bandwidth is
usually expressed in bits per second (bps) or bytes per second. Suppose a Web Server’s bandwidth is limited to 1
mega-bits per second (1 000 000). Suppose an average web page “weighs” around 10 000 bits, thus the Web Server
will be able to serve 100 web pages per second (assuming the Web Server has unlimited resources, apart from
bandwidth). Thus in case 200 requests are made per second, then every second request will not be satisfied with
content.
189
The maximum number of connections a computer system can handle in a given amount of time (capacity of a
Web Server’s connection request queue i.e. number of open TCP requests that can be handled).
- 84 -
to consume all available resources on a remote Web Server. I have successfully used this
technique to bring down a recent third year computer science project www.mywcs.co.uk (during
project security testing) by constantly adding high volumes of messages to the site’s discussion
forum, at first the Web application became immensely slow, after all it totally stalled once the
database was filled with over 10 000 000 messages. Another type of DoS attack simply attempts
to use the bandwidth available to the network, host or device, by sending massive quantities of
data and so causing it to process extremely large amount of network requests. An attacker could
attempt to use up the available bandwidth of a network by simply bombarding the targeted
victim with normal, but meaningless packets with spoofed source addresses. An example is flood
pinging. Simple flooding is commonly seen in the form of DDoS attacks, which are discussed
below.
Now, Distributed Denial of Service attacks are just a bit more tricky in practice than traditional
DoS. According to the WWW Security FAQ 190 : “A DDoS attack uses many computers to launch
a coordinated DoS attack against one or more targets. Using client/server technology, the
perpetrator is able to multiply the effectiveness of the DoS significantly by harnessing the
resources of multiple unwitting accomplice computers, which serve as attack platforms”. The
DDoS attack is the most advanced form of DoS attacks. It is distinguished from other attacks by
its ability to distribute its “attacking force” all over the Internet, therefore creating lethal traffic
that is capable of shutting down almost any public Internet service. DDoS attacks mainly take
advantage of Internet architecture and this is what makes them even more powerful. The Internet
was designed with functionality and reliability, not security in mind, thus, thanks to
technological lock- in, Denial of Service attacks are possible and were practiced effectively from
the first days of the net. Distributed denial of service attacks were always possible and almost
definite to succeed due to a number of factors:
•
•
•
Internet Security is highly interdependent. No matter how secure a victim’s system may
be, whether or not this system will be a DDoS victim depends on the rest of the global
Internet. 191
Internet resources are limited. No Internet host has unlimited resources that sooner or
later can be consumed by a sufficient number of users.
Many against a few. If the resources of attackers are greater that the resources of the
victims then the success of the attack is almost definite.
190
CERT Coordination Center, Trends in Denial of Service attack technology, October 2001, available from
http://www.cert.org/archive/pdf/DoS_trends.pdf
191
- 85 -
Fig. 7: Architecture of a DDoS attack
A distributed denial of service attack is composed of four elements, as shown in figure 1:
•
•
•
The real attacker
The handlers or masters, which are compromised hosts with a special program running
on them (perhaps a trojan horse, see chapter 5 for a thorough description), capable of
controlling multiple agents.
The attack daemon agents or zombie hosts, who are compromised hosts that are running a
special program and are responsible for generating a stream of packets towards the
intended victim. Those machines are commonly external to the victims’ own network, to
avoid efficient response from the victim 192 , and external to the network of the attacker, to
avoid liability if the attack is to be traced back.
The following steps take place while preparing and conducting a DDoS attack:
1. Selection of agents. The attacker chooses the agents that will perform the attack. These
machines need to have some vulnerability that the attacker can use to gain access to
them. They should also have enough resources that will enable them to generate powerful
attack streams. At the beginning this process was performed manually, but it was soon
automated by scanning tools. Nowadays, it is common to see trojan horses to be
unwittingly installed inside computers by unaware users, which help conduct the DDoS
attack. For example, agent software can be built into a typical screensaver, thus,
whenever the system is idle it will use its resources to select and control new agents or
even attack the victim’s host.
192
One can effectively block incoming network traffic based on IP address allocation.
- 86 -
2. Compromise. The attacker exploits the security holes and vulnerabilities of the agent
machines and plants the attack code. Furthermore he tries to protect the code from
discovery and deactivation. Self-propagating tools such as the Ra men worm193 and Code
Red 194 soon automated this phase. The owners and users of the agent systems typically
have no knowledge that their system was compromised and that they will be taking part
in a DDoS attack. When participating in a DDoS attack, each agent program uses only a
small amount of resources (both in memory and bandwidth), so that the users of
computers experience minimal change in performance of their systems.
3. Communication. The attacker communicates with any number of handlers to identify
which agents are up and running, when to schedule attacks, or when to upgrade agents.
Depending on how the attacker configures the DDoS attack network, agents can be
instructed to communicate with a single handler or multiple handlers.
4. Attack . At this step the attacker commands the onset of the attack. The victim, the
duration of the attack as well as special features of the attack such as the type, length,
target et cetera can be adjusted. The variety of the properties of attack packets can be
beneficial for the attacker in order to avoid detection.
The early DDoS attacks were manual. This means that the DDoS strategy included the scanning
of remote machines for vulnerabilities, breaking into them and installing the attack code. All of
these steps were later automated by the use of semi- automatic DDoS attacks and automatic
DDoS attacks. In semi-automatic attacks the attacker scans and compromises the handlers and
agents by using automated scripts (see chapter 5). In automatic attacks the communication
between the attacker and the agent machines is completely avoided. In most cases the attack
phase is limited to a single command. All the features of the attacks, for example the duration
and the victim’s address, are preprogrammed in the attack code. This way the attacker has
minimal exposure and the possibility of revealing his identity is small.
Defense problems
DDoS attacks are a hard problem to solve. First, there are no common characteristics of DDoS
streams that can be used for their detection. Moreover, their distributed nature makes it
immensely hard to trace them back to the source. Moreover, the automation tools are freely
available on the Internet and new tools are being developed daily. Attackers may also use IP
spoofing in order to hide their true identity, and this makes traceback even more difficult.
Intrusion Prevention
DDoS defense strategies may be split into three categories: intrusion prevention, intrusion
detection and intrusion response. The best strategy against any attack is, of course, to completely
prevent the attack. Meaning that one may try to stop the DDoS attack from being launched in the
first place. However, due to technological lock- in on the architecture of the Internet, it is
impossible to do so, yet a number of steps can be taken to ease the situation. The majority of
approaches in this area are simple data filters to be employed at the data routers of the network.
There are a variety of filtering paradigms, such as ingress filtering 195 , egress filtering196 , routebased distributed packet filtering 197 and others. All of which basically focus on letting some
kinds of data through to the servers and simply dumping other incoming data, thus rendering the
DDoS attack obsolete. However, filters must be able to let legitimate traffic through, therefore an
193
CIAC Information Bulletin, The Ramen Worm, available from http://www.ciac.org/ciac/bulletins/1-040.shtml
CERT Coordination Center, “Code Red worm exploiting buffer overflow in IIS indexing service DLL”, CERT
Advisory CA 2001-19, available from http://www.cert.org/advisories/CA-2001-19.html
195
Proposed by Ferguson and Senie in P. Ferguson, D. Senie, “Network ingress filtering: defeating Denial of
Service attacks which employ IP source address spoofing”, in: RFC 2827, 2001.
196
Global Incident analysis Center, Egress Filtering. Available from http://www.sans.org/y2k/egress.htm
197
K. Park, H. Lee, “The effectiveness of route-based packet filtering for Distributed DoS attack prevention in
power-law Internets”, Proceedings of the ACM SIGCOMM 2001, ACM Press, 2001, pp. 15-26
194
- 87 -
attack may succeed in case it comes from a large variety of sources. Therefore this protection
mechanism has a rather limited application scope, it may very well protect against a typical
denial of service attack, yet will completely fail in case a vast majority of traffic is initiated by
legitimate sources. Another approach to combating DDoS attacks was recently suggested by
Geng and Whinston198 , they suggest constantly changing the IP address of the attacked machine.
This is called moving target defense. Once the IP change has been completed and all Internet
routers have been informed, attacker’s traffic aiming at a non-existent destination will simply be
ignored. Although this function leaves computers vulnerable because the attacker can easily
launch the attack aiming at the new IP address. This option is practical for local DDoS attacks,
which are based on IP addresses. On the other hand, attacker can improve their approach by
adding a domain name service tracing function to the DDoS attack tools. Other common
approaches include load balancing 199 i.e. sharing the overall load over a closed network of
syndicated servers and a wide use of so-called honeypots, which are basically systems that are
set up with limited security and be used to trick the attacker to attack the honeypot and not the
actual system. The concept of honeypots, their development history and applications is discussed
in detail in chapter 7.
Intrusion Detection
Intrusion detection seems to be a very active research area. By performing intrusion detection a
host computer and a network can guard themselves against a source of network attack as well as
being a victim of a DDoS attack. Intrusion detection systems detect DDoS attacks either by using
the database of known signatures or by recognizing anomalies in systems behavior. Anomaly
detection mainly relies on detecting behaviors that are abnormal with respect to some preset
standard. Many systems have been developed in order to detect the faint signs of a DDoS attack.
For example, a scalable network monitoring system called NOMAD was designed by Talpade et
al. 200 in 1998, when first DDoS attacks became massive attention of the media. This system is
able to detect network anomalies by making statistical analysis of network data packer header
information. It can be used for detecting the anomalies of the local network traffic; however, it
will still fail in case traffic came from a large set of legitimate sources. Yet, Mirkovic et al. 201
proposed a system that may be capable of combating this problem. The systems is called DWARD, and it does DDoS attack detection at the source based on the idea that DDoS attacks
should be stopped as close to the sources as possible. D-WARD is installed at the edge routers of
a network and monitors the traffic being sent to and from the hosts in its interior. In case an
asymmetry in the data packet rates generated by an internal host is noticed, then D-WARD limits
the throughput channel to this host. The obvious drawback of this approach is that there is a
possibility of false positives, such as direct audio or video streams or massive downloads. There
are numerous other intrusion detection mechanisms 202 that have been developed in the recent
years, however none of them are 100% secure against a DDoS attack.
Intrusion Response
198
X. Geng, A. B. Whinston, “Defeating Distributed Denial of Service attacks”, IEEE IT Professional, Vol. 2, 2000,
pp. 36-42
199
R. B. Less, Taxonomies of Distributed Denial of Service networks, attacks, tools and countermeasures. Available
from http://www.ee.princeton.edu/~rblee/
200
R. R. Talpade, G. Kim, S. Khurana, “NOMAD: Traffic based network monitoring framework for anomaly
detection”, Proceedings of the fourth IEEE Symposium on Computers and Communication, 1998, pp. 442 – 451, can
bee seen at http://ieeexplore.ieee.org/
201
J. Mirkovic, G. Prie r, P. Reiher, “Attacking DDoS at the Source”, Proceedings of ICNP 2002, Paris, France,
2002, pp. 312-321
202
Such as MULTITOPS – T. M. Gil, M. Poleto, “MULTITOPS: a data-structure for bandwidth attack detection”,
Proceedings of 10th Usenix Security Symposium, Washington DC, August 2001, pp 23-38, or Data Mining – W. Lee,
S. J. Stolfo, K. W. Mok, “A data mining framework for building intrusion detection models”, Proceedings of the
1999 IEEE Symposium on Security and Privacy, Oakland, Ca, May 1999, pp. 120-132, can bee seen at
http://ieeexplore.ieee.org/
- 88 -
Once an attack is identified, the immediate response is to identify the attack source and block all
the traffic originating from that source. The blocking part is usually performed under manual
control, since an automated response system might cause even further Web service failure in
case of a false alarm. Automated intrusion response systems do exist, but they are deployed only
after a period of self- learning or testing. There is a number of approaches that target the tracing
and identifying of the real attack source, which are very well discussed by P. Zaroo 203 . Generally
the network administrator will use IP traceback, which traces the attack back towards its origin,
so that one can find out the true identity of the attacker. There are, however, numerous factors
that may render this process difficult, such as the distributed nature of the attack, or IP spoofing.
At a very basic level one can think of this as a manual process in which the administrator of the
network under attack places a call to his ISP asking for the direction from which the packets are
coming. However, since manual traceback is very tedious there have been various proposals in
the recent past to automate this process 204 . However, no matter how savvy the network
administrator is, it is impossible to prevent or stop a DDoS attack completely, therefore, one
must focus on minimizing the attack impact and on maximizing the quality of services.
Conclusion
Web Servers are fine programs, but innovative applications delivered over the World Wide Web
require that servers can be extended with custom-built programs. Unfortunately, these programs
can have flaws that allow attackers to compromise a system. The Common Gateway Interface
was the first and remains the most popular means of extending Web Servers with functionality.
Largely as a result of their power, CGI can completely compromise the security of a Web Server
and the host on which it is running. That is mainly because any program can be run through these
interfaces. This can include programs that have security problems or programs that outsiders
access to the system. Two techniques may be used to limit the damage that can be performed by
CGI programs:
•
•
The programs must be inspected by the system administrators to ensure that they can
perform only the desired functions.
The programs should be run in a restricted environment, namely the Web Server must be
configured carefully such that the possible damage done by a CGI process is limited.
However, some system administrators fail to configure a more or less secure Web Server. Yet
even in case the Web Server is fail proof from a CGI process it can still be compromised via a
DDoS attack. Undoubtedly, DDoS attacks present a serious problem in the Internet and
challenge its rate of growth and wide acceptance by the general public, government and
businesses. One great advantage of the development of DDoS attack and defense classifications
is that effective communication and cooperation between researchers can be achieved so that
additional weaknesses of DDoS attacks can be identified. These classifications need to be
continuously updated and expanded as new threats and defense mechanisms are discovered.
Moreover, DDoS attacks are not only a serious threat to Web services over wired networks, but
also for wireless infrastructures. Some progress was made in order to defend wireless networks
against DDoS attacks205 . Yet, further work is needed that combines well known security
203
P. Zaroo, “A Survey of DDoS attacks and some DDoS defense mechanisms”, Advanced Information Assurance
(CS626), available at: http://www.cs.purdue.edu/homes/zaroo/papers/my_papers/ddos_paper.pdf
204
Such as: S. Bellovin, “The ICMP traceback message”, available from
http://www.research.att.com/~smb/papers/draft-bellovin-trace.txt; or S. Savage, D. Wetheral, A. Karlin, T.
Anderson, “Network Support for IP Traceback”, IEEE/ACM Transaction on Networking 9, 2001, pp. 206-237
available from http://www.csd.uch.gr/~hy558/papers/savage-traceback-sigcomm00.pdf
205
X. Geng, Y. Huang, A. B. Whinston, “Defending wireless infrastructure against the challenge of DDoS attacks”,
Mobile Networks and Applications, Issue 7, 2002, pp 213-223, can be seen at
http://cism.bus.utexas.edu/works/articles/DDoS_ACM_final2_all.pdf
- 89 -
drawbacks of wireless protocols with defense techniques that are already well-established in a
wireless environment.
Chapter Summary
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
206
Web Servers are a special breed of software that is run on any Internet host and is used to
server HTML pages to requesting clients.
In case the server is connected to the Internet, it is automatically exposed to the whole
world. Unfortunately, this increased visibility can have some unwanted side effects.
Web Servers were developed only in early nineties as more and more common users
went online.
The problems that open up security holes in Web Servers are various, but most of them
spring up from either server misconfiguration, bugs in Web applications or denial of
service attacks.
All Web Server software, regardless of platform or manufacturer, unintentionally hides a
number of vulnerabilities, which allow the application to be used in a different way than
originally intended.
Misconfiguration of software was a common problem even before Web Servers. There
are good accounts of common mistakes in Clifford Stoll’s book “The Cuckoo's Egg”.
Many system intrusions talked about in the media were based on a simple strategy where
the attacker sent data to a program that the program couldn’t handle. These can be
referred to as bugs, or programming errors.
Common applications bugs allow Code Injection, Cano nicalization and HTML injection.
Denial of Service attacks constitute one of the major threats and are among the hardest
security problems in today’s Internet.
A DoS attack’s objective is to deny a user access to some type of service. In most cases, a
DoS attack uses one computer to flood another computer with network traffic,
specifically traffic that contains confusing messages that cause the victim computer to
waste time and resources trying to understand what it has received.
According to the WWW Security FAQ 206 : “A DDoS attack uses many computers to
launch a coordinated DoS attack against one or more targets. Using client/server
technology, the perpetrator is able to multiply the effectiveness of the DoS significantly
by harnessing the resources of multiple unwitting accomplice computers, which serve as
attack platforms”.
Internet Security is highly interdependent. No matter how secure a victim’s system may
be, whether or not this system will be a DDoS victim depends on the rest of the global
Internet.
The early DDoS attacks were manual, today they are fully automatic and use malware for
successful selection of agents.
DDoS attacks are a hard problem to solve. First, there are no common characteristics of
DDoS streams that can be used for their detection. Moreover, their distributed nature
makes it immensely hard to trace them back to the originating source.
DDoS defense strategies may be split into three categories: intrusion prevention,
intrusion detection and intrusion response.
Once an attack is identified, the immediate response is to identify the attack source and
block all the traffic originating from that source.
DDoS attacks cannot be stopped, they will always be a potential threat to any system.
Web Servers are fine programs, but innovative applications delivered over the World
Wide Web require that servers can be extended with custom-built programs.
- 90 -
Unfortunately, these programs can have flaws that allow attackers to compromise a
system.
- 91 -
Chapter 7
- 92 -
Chapter 7 — Building a Secure LAN
The phenomenon of widespread electronic intrusion is very recent. It is made possible by the
spread of personal computers and their connection to electronic networks. Although technically
sophisticated, intrusions are always the act of human beings. Intrusions, however, can be
controlled by a combination of technical safeguards, but they cannot be eliminated. It would
seem that some straightforward technological fixes would greatly reduce future threats. But
technological fixes are not the final answer. They are valid only until someone launches a new
kind of attack. Changes in the ways we use computers, however, will reduce our exposure to our
own and others’ mistakes. It is hard to build and implement a secure system, moreover, as
outlined in previous chapters 100% secure systems simply do not exist, but it should be the
central aim of every System Administrator to reach an adequate level of security for the
computer network on guard. In this chapter I am aiming to draw a line underneath all the
concepts introduced in the previous chapters in order to propose a feasible and scalable security
policy/strategy that could be used to secure information in the modern business world.
An IT security policy/strategy of some LAN is built with some system model in mind. As
already outlined in chapter one of this thesis: various security models exist, with the OSI model
dominating the perception of security on the Internet today. Yet I have proposed a different
perspective in this field, where I have identified five fronts, which are responsible for
information security. These five fronts have to be guarded simultaneously, thus they form a
Pentagon (Fig. 1), which is easier to perceive as a model, rather than the not applicable in the
modern world OSI model, which is more of a data flow diagram rather than a picture of how
things are working together simultaneously.
Fig 1 The Pentagon of Internet Security
The Pentagon is a collaboration of five fronts, each being of uttermost importance, meaning that
a failure to protect any given side of the Pentagon will result in the failure of the security system
as a whole. Next is a short overview of how one might approach the security of a LAN in a
company or some institution, where information safety is of high importance.
Server OS
Chapter two gave a thorough overview of the security evolution of server Operating Systems
(OS). I have taken an insight into a couple of well-known attacks, which were aimed at the
- 93 -
server OS. Moreover I have presented many possible flaws an Operating System has these days.
Yet it must be pointed out, that I have only focused on UNIX based systems, as according to
Netcraft nine out of ten servers on the web run some breed on UNIX. Windows Server was left
out intentionally, as a) its history doesn’t span over three and a half decades in comparison to
Unix, as it was first commercially released only in the mid- nineties; b) it does not represent the
majority of servers under attack (there is a discussion about this in chapter five as well); c) while
it has avoided some of the logical flaws brought in by Unix, it has introduced other problems,
which, unfortunately, can only be fixed by Microsoft and not the community as a whole (i.e.
Windows is not Open Source).
The security of any given OS has to be transformed into an endless process, which is to be
carried out by the System Administrator according to some pre-defined security policy. I am
suggesting the following approach:
•
•
•
•
•
•
•
•
•
Run system-updates on a weekly basis. Unix based system used to be hard to update, as
one had to stay alert in order to track down updating information. Nowadays the process
has been automated. As an example, the Debian Linux (one commonly used as an OS to
support the rather well known Apache Web Server) has an automatic script called “aptget” which downloads and installs new packages from the developer’s server.
No one shall be allowed to login using the “root” account, as changes are then hard to
trace. Instead the “su” command shall be used to grant temporary super user rights to the
logged in user.
Keep the number of shell accounts down to an absolute minimum. Ideally there shall be
only five accounts registered on the system i.e. root, www, mail, ftp and an account for
the system administrator. E- mail delivery can be organized without the use of shell
accounts 207 , this will limit the scope of work of the system administrator.
Software daemons, that are not well known to the Internet community shall not be used.
In case the use of such a daemon is inevitable, then they shall be isolated on a designated
machine, which is not included in the “trust” network of the LAN.
System accounts that interact with local daemons shall have minimal access privileges.
An example of such an account is the “www” user, in the name of which the Web Server
(discussed later) serves web pages to all the requesting clients.
All accounts shall create files and directories readable by them and their group only.
Public access to files/directories (i.e. anything above 770) must only be granted when
there is a necessity for such access (web pages and temporary files).
Trust networks are to be limited to a minimum. In case several machines are linked
together in order to share disk space, then a trust network is not necessary, files can be
shared via a set of stand-alone tools (such as rsync). In cases where several machines are
to share processing power, they are to be locked away behind a firewall208 . Nonetheless
the trust network is to be perceived as a “single machine”, as access to any machine on
the network will automatically mean access to all machines. Moreover, a firewall is of
little help in case the intruder undertakes an attack from the LAN.
Password selection policies are discussed in the “People” section of this chapter.
Moreover, an analysis of “weak” passwords can be found in chapter two.
Ideally systems not needing access to the network, shall not have network access and be
operated locally. As an alternative solution, the system may be booted without a remote
207
For example, the PUBLIC Voice Lab in Austria (http://pvl.at/) is using an internally developed tool which hooks
up all the mail delivery jobs to a database, where storage paths are stored. Users accessing their e-mail are not
authenticated as shell users, but are directed through a mail daemon, which fetches data according to local database
records. For more info download and test PVL’s Self Admin package – http://inspire.pvl.at/solutions/sadm/
208
The concept of firewalls has been left out of the scope of this thesis intentionally. Read chapters two and three for
references to explanatory reading.
- 94 -
•
access shell, making its resources available for the network, yet not leaving any chance
for anyone to even attempt a remote login.
Services such as database applications shall deny any remote connections. Instead a
tunneling application shall be used to build up local connections (eg. PHP+MySQL).
The above set of guidelines are all common sense security precautions that are met by savvy
system administrators. Yet it is by far not complete without links from the other fronts of the
Pentagon of security. Especially important is the tie between OS security and the Human
Elements of Internet Security. The tie between the two is investigated in the “People” section of
this chapter.
Web Server
One of the prevailing applications of the Internet today is the World Wide Web, consisting of
hundreds of millions of web pages. Some pages are static, some are dynamic, but what they all
have in common is some breed of Web Server software, which delivers the data to the client
machines via a Web Browser. Whereas Unix-based OS make up most of the Internet, there are
quite a few Web Servers running on the World Wide Web. According to Netcraft 209 the Apache
Web Server is delivering around 70% of all web pages on the net today (March 2005), with
ZEUS, MS Internet Information Server and Sun serving the rest. Thus my suggestion for a
security policy may be a little biased towards the Apache Web Server as I have several years
experience in administering it.
As already pointed out in chapter six – most problems that are brought in with a Web Server are
inherent to low quality application configuration. For example the Apache Web Server210 allows
to override all configuration options using an “.htaccess” file inside user’s “www” directories.
The extent of override directive’s power can be, of course, limited, yet many system
administrators find it easier to simply allow overrides without investigating the depth of possible
options. The list below is a brief policy, which any System Administrator shall follow, when
configuring a Web Server.
•
•
•
•
•
209
210
Limit the use of override directives (“.htaccess” file in Apache Web Server), such that
they are disabled as default and enabled only for users, who request their activation.
Overrides shall, of course, be limited to one system folder (and it’s subfolders), and be
not applicable to any other user’s spaces.
Override directive files shall always be protected i.e. not servable to the outside world by
the Web Server.
Shell users shall not be granted with public web space by default. Moreover, as it has
already been pointed out in the previous section of this chapter – the amount of shell
users should be kept to an absolute minimum. In case the presence of shell users is
mandatory and these users wish to maintain web pages, then these shall be limited to
minimal functionality. For example, the Apache Web Server has a whole set of “UserDir
Access Directives”, which shall be investigated in the httpd.conf file of the Web Server
in question.
The Web Server typically comes equipped with a set of extensions, most of which are not
used. Thus extensions that are not needed shall be deactivated.
In order to prevent high loads, the Web Server must be configured to accept a limited
number of connections. The Apache Web Server, for example, typically allows only 100
simultaneous connections. It may not sound as a very high- load figure, yet such a
bottleneck pays off in the sense, that the server cannot be taken down by a DDoS attack
http://news.netcraft.com/archives/web_server_survey.html
http://www.apache.org/
- 95 -
•
•
•
•
immediately. There will be time to react and take the necessary measures in order to
prevent full server disability. Every System Administrator shall be careful and be ready
to prevent the Web Server to runaway and take the whole system down with it as it
spirals down.
One of the main problems with any Web Server lies with custom code, that is written and
run by the user in his/her private web space. Ideally one would want to limit the ability of
any system user to use any kind of scripting language, yet static web pages are a trend of
the past. Thus it is usual to see ISPs giving their users access to powerful scripting
languages such as PHP, Perl, .NET, Java and others in conjunction with a Database
Management System (such as MySQL, MSSQL, PostgreSQL and others). Extreme care
must be taken in the configuration of these applications.
o For example one can and must limit system related functionality of PHP (such as
the “exec” and “system” functions, as they provide a tunnel to shell).
o The amount of e- mail that a script can send shall be limited as well.
o PHP must be run in “safe- mode” (it will be executed in the name of a special user,
thus disallowing access to the rest of the file system).
o “Magic Quotes”211 must be enabled in the scripting language.
o Ideally one would want to control the quality of the user’s code, yet in high load
systems this is a very costly procedure. Thus it is advisable for the System
Administrator to check the average system load a user’s script generates. In case
the load gets noticeably high – code shall be inspected.
o Every user should be isolated to his/her own database with a DB user, which is
granted limited access privileges. In case an injection should occur, only part of
the data will be lost/modified/stolen, whereas the overall system will not be
penetrated.
Web Server software must be updated on a regular basis.
The System Administrator si to check the overall system load generated by the Web
Server and it’s child processes. The Web Server may not take the whole system down
and shall be stopped in case such a possibility exists.
High load sites will usually be hosted on more than one machine, which will be accessed
via a load balancer212 . It is important to keep a separate machine on “cold-standby”. Once
a trace of a DoS attack is spotted by the system administrator, then the extra processing
power can be brought in to combat additional traffic, while the issue is resolved.
While the above is a good set of security policies applicable to most Web Servers on the Internet
today, it must be taken into account, that any Web Server software runs on some operating
system, thus it is consuming the OS’s resources and has access to the file tree of the computer. In
most scenarios the same System Administrator will be responsible for the installation, finetuning and tech support of the Web Server and the underlying OS. This is another lead towards
the end of this chapter, where the “Human Factor” is discussed in conjunction with other sides of
the Pentagon.
Transport Channel
Looking back at the first chapter – any web connection involves two parties: usually a server and
a client. These are linked together with the aid of a “transport channel”, which is in most cases a
TCP/IP network. Unfortunately, the Internet was originally designed in order to share and not
protect information, thus the TCP/IP network protocol does not provide us with any solutions to
secure the data, while it is traveling from point A to point B. Meaning that in almost all cases
211
Inside all of the user input all special characters that may result in code injection will be automatically escaped
with a backslash, these include “,’,/, et cetera.
212
A hardware solution to route client requests to various machines. Typically these machines synchronize each
other’s data, thus they appear as one single Web Server to the outside world.
- 96 -
user names and passwords flow as clear text over the Internet. Anyone savvy in network
technology can intercept this data, while it is in transit. Moreover, even script kiddies can
download special software to monitor data in a LAN. Besides the problem of traffic interception
there is also a potential threat of traffic alteration. For example e- mail messages may be altered
with fictitious content. Yet there are various technological solutions, which conceal most of the
traffic from the outside world, one of these being Virtual Private Networks (VPN), which
establish secure (read encrypted) connections between hosts on the Internet. For more details on
VPNs refe r to this chapter’s appendix. Nonetheless I will still attempt to suggest a policy, which,
if followed precisely, shall minimize the chance of a successful attack on a LAN:
•
•
•
E-mail
o In order to make sure that the e- mail has not been altered along its way from point
A to point B – always use digital signatures.
o Ideally all e-mail shall be encrypted as well. Yet this may not be possible when
communicating with people outside of the LAN. Nonetheless, encryption of all email communication must be encouraged. Moreover this task can be automated
and will not in any way whatsoever affect the performance of any LAN user.
Internal e-mail relays can be configured not to route any clear text e- mail to its
destination.
o E- mail must not be retrieved using the POP3 protocol. IMAP shall be used
instead, such that data is never replicated. It is easier to protect it centrally.
o Alongside with the IMAP protocol, secure authentication and connection shall be
used for all e- mail communication between the client and the server.
o Ideally e- mail must not be accessible from outside of the LAN. This is easily
achievable in case a VPN is installed and no web-based e-mail is available. For
personal communication people are encouraged to use purely web-based services
such as Google Mail 213 .
Intranet/LAN Servers
o Make sure that all web traffic in the LAN is passed via SSL. This will protect the
data from being sniffed internally.
o Follow security policies listed in the first part of this chapter.
Overall
o Make sure that DNS servers are not appointed dynamically, but are hard coded in
the computer’s network settings.
o Computer’s IP addresses shall not be assigned dynamically but be hard coded in
the network settings.
o Only authorized MAC addresses may access the LAN. This minimizes the risk of
someone hooking up on the LAN with a laptop.
o All communication of the LAN with the outside world (apart from HTTP) should
be disabled.
Traffic may be easy to intercept, but in case the user (data owner) is aware of the slight
possibility of such an event and takes the necessary precautions to protect his/her data, then
interception will be of little use, as the acquired data will be encrypted. Moreover, many of the
encryption tasks can be automated and remain transparent to the end user. It is, however, very
important to raise overall awareness of all LAN users. This is discussed in more details later in
this chapter.
213
http://gmail.com/
- 97 -
Client (OS and Browser)
Connections to servers are usually initiated by some sort of client. Over the last decade web
browsers are a prevailing type of client application that establishes a connection with a Web
Server. Yet a “client” is more. When talking about a client, what one actually means is a
computer with a set of application, such as an OS and a web browser, which establishes a
connection to a server via a network. This machine’s OS and applications need to be protected
from intrusions just as much as the server OS and its applications and the transport channel used
to link the two. Whereas a server in a LAN or a WAN has little direct human-computer
interaction, due to the nature of its functionality, a client is operated by a human being most of
the time when it accesses the network. When securing client machines in a LAN, the following
set of security guidelines may lock out most of potential problems:
•
•
•
•
•
•
•
•
•
214
Ideally all computers in the LAN should use the same OS and the same browser. As a
rule of thumb it is more secure to use less popular software. For example preference
should be given to the Firefox214 web browser over Internet Explorer. The primary reason
for such a decision is, of course, the fact that typically malware is written for software,
that is used more widely. Moreover, the Firefox web browser is Open Source, meaning
that bugs are fixed almost instantaneously by the community. Yet this leads to another
recommendation.
Software must be updated on a regular basis. Whereas some programs will take the
liberty of updating themselves automatically, others need to be updated manually. This
has a direct link to the security policy affecting the “human factor”. In fact, the client
machines are the ones in the highest risk area due to the volume of human-computer
interaction directed at them. Yet this is discussed in more details later in this chapter.
A simple “must” is the installation of firewall software on all client machines in a LAN.
There are various providers, many of which were reviewed in chapter five. A good
choice may be Symantec’s Norton Internet Security Suite. In case it is tuned well, then
the client is rather safe from being intercepted by a Trojan or a popular breed of computer
virus.
Many security specialists recommend to remove floppy drives from computers on a
LAN. I find this measure paranoid and ineffective, as any USB port can be used to
connect a flash card to a PC. Thus the client machines must not be altered in terms of
hardware.
Ideally computer users shall not have administrative privileges over the system they are
using, meaning that they will not be able to install any new software or edit the system’s
registry. Of course this will not keep off all the trouble, yet much of malware circulating
the net will become obsolete.
Making a reference to the server OS. All the e- mail containing executable files shall be
stripped of the attachment. Moreover, there are quite a few server based e- mail
processors, which scan incoming and outgoing e- mail for malware.
Besides installing firewall software on client machines, antiviral software must be
installed too. Apart from scanning local files, the boot sector and the registry for traces of
malware, it will also take care of incoming and outgoing e- mail.
Client machines should not be allowed to share any kind of resources over the LAN, let it
be processing cycles, disk space or local drives.
As it was already outlined before in this chapter – information is easier to protect in case
it is stored centrally. Thus work-related files, address books and calendars are to be
stored on a server and accessed remotely. There are various technological solutions
offering that level of flexibility, a rather well known one being the Microsoft Exchange
Server.
http://www.mozilla.org/
- 98 -
•
•
Sensitive information that is to be stored locally must be protected. This is best achieved
with automatic encryption tools such as PGP Disk, which mounts a virtual hard drive in
the overall file system. All the files written to that disk are automatically encrypted with
the user’s key and are accessible only with the presence of the key and a boot- up pass
phrase.
Cryptography keys are never ever to be stored on the local file system. What I
recommend is the storage of these in a USB Flash Stick, which can be carried around as a
key ring.
Even if all the above recommendations are followed precisely, the client machines are still
vulnerable to attack. Sensitive information does have to be obtained over software: intruders may
install simple keystroke loggers between the computer case and the keyboard. Read more about
this in the next section of this chapter.
People
Nowadays there exist technological solutions to tackle almost any kind of security threat on the
Internet. Yet servers and even whole LANs are broken into almost daily, information is stolen
and web sites are defaced. Whereas it is common for new vulnerabilities to be discovered in
widely used software (such as MS Windows), they do not usually lie at the root of the attack. As
it has already been pointed out in the previous chapters: the Internet is not autonomous and it is
managed by human beings. Meaning that either the whole system or parts of the system (LANs
or stand alone serve rs) are vulnerable to human error. There are various types of human error, all
having the potential to grant access to attackers. However, before I attempt to classify error
severity I will try and classify the majority of network users inside a LAN.
•
•
•
•
•
•
•
System Administrators – are responsible for managing the network, they are also
looking after servers and are primarily responsible for the smooth operation of the server
OS (chapter 2) and the Web Servers (chapter 6). Their secondary tasks include watching
over the whole network, making sure that it is secure and in working condition.
Software Developers – can be internal to the LAN, thus are more educated about the
available resources and local security policies. Yet, most of the time, software is
developed by third parties, or, in case of Internet Service Providing companies, software
may be very well written by the users of the provided hosting service.
Network Specialists – are responsible for hardwiring and tuning the LAN. Their primary
field of expertise lies with network topologies and various network-related hardware such
as switches, hubs, repeaters, firewalls et cetera.
IT Support Personnel – are usually employed at IT helpdesks. They have access to all
user accounts on the LAN and are responsible for resolving software related problems of
LAN users.
IT Managers – are, usually, ex-software developers, and thus are savvy in all aspects of
IT including security. Moreover, they are aware of the overall value of internal
information and are the ones, who will get punished for any security breach, if such
occurs.
Users savvy in IT – are common network users, who are aware of potential dangers that
the net brings to their PC (viruses, trojans and other malware), thus they are careful when
reading their e- mail and passing sensitive information through the net.
Other users – are aware of the existence of malware, yet take little action against it and
are the most common targets for social engineering attacks. Moreover they are not only
the ones who need the most protection, but they are also the ones, from whom the system
will need the most protection.
- 99 -
Once the target groups for a people-related security policy have been defined, the actual
guidelines can be presented as well. Yet I would like to point out, that I am picturing a rather
paranoid system, which should be attended to based on the value of protected information.
•
•
•
System Administrators
o It is wise to hire more than one System Administrator to look over the system, as
possible mistakes of one will be noticed by the other.
o System Administrators should take care of software updates on the servers.
o It is the Sysadmin’s task to read daily CERT reports concerning newly discovered
vulnerabilities and to make sure that the LAN is on guard against intrusions.
o They are responsible for tight configuration of the server and the Web Server
software, such that the system is grants minimal access to the other users of the
LAN and the Internet as a whole.
o Sysadmins are advised to install password control scripts, suc h that weak
passwords (discussed in chapter 2) are not allowed. Login passwords should be
minimum of 8 characters in length, they should contain at least two numerals and
one “special” character. A strong password could be “AKu1!kov9”, whereas
phonetically the same password will be considered weak – “AKulikov9”. Read
chapter two for more details on weak and strong passwords.
o User accounts are to expire, unless the password is not changed every three
month.
o Sysadmins are to control temporarily “not active” accounts i.e. in case some
account holder is on holiday – his/her system account should be temporarily
blocked.
Software Developers
o Extreme Programming (XP) techniques shall be practiced by all software
developers as one of the ground stones of XP is “pair-programming”, which
reduces severely the amount of bugs per KLOC215 .
o Unit testing in software development is also one of the main components of the
software development lifecycle, which helps produce much more stable and
secure code.
o Use of applications “heavy” on server’s resources (memory and processor cycles)
should be prohibited by the Sysadmins.
o Sysadmins shall prepare the Web Server against possible code injections through
third party software. Code injections are possible only due to the sloppiness of
software developers and can be avoided. Yet in case a code injection takes place it
should not have any disastrous consequences and cause minimal damage in the
user’s space only (disk/file space where some user installs third party software, in
case of a Web Server it will be the user’s public html folder and a dedicated
database).
Network Specialists
o Extreme caution shall be taken when tuning firewalls, routers and switches. Any
route of entry left open for no particular reason could be used for an attack. Thus
the network specialists are to check on each other’s work in order to minimize the
possibility of human error.
o Hubs, Switches, Routers and other network related hardware should not be
mounted in places accessible to the public 216 . Ideally all cables are to be hidden in
cable shafts and not left lying around. Yet with the growing popularity of wireless
215
Thousand Lines of Code
For example, in the Austrian Ministry of Foreign Affairs the central router is mounted on the wall in a publicly
accessible corridor. It is therefore rather easy to intercept traffic flowing through a LAN, which has no physical
connection with the Internet (at least this is what the employees of the ministry claim).
216
- 100 -
•
•
•
•
networks this precaution becomes obsolete. Moreover, wireless connections are
capable of automatically encrypting all network traffic and they should be
configured to do so.
IT Support Personnel
o They should never recover user’s passwords over the phone. Password recovery
procedures should be carried out in person.
o Any information concerning either the structure of the LAN or its users should
never be revealed to anyone.
IT Managers
o Since IT managers usually have more access to information on the LAN than
other users, they are in desperate need for security related training (read the next
section on this chapter on details of such training).
o Decision making process on information access policies must be documented and
coordinated with the Sysadmins.
o IT managers must make any security compromises public. Moreover, breakins
can be simulated and later discussed by the users. This will raise awareness and
prevent common Social Engineering scenarios from succeeding.
Users savvy in IT
o Need to have some freedom in picking their own software, yet installation must
be coordinated with IT Support Personnel, who, if in doubt, have to consult
themselves with the Sysadmins.
Applicable to all Users
o Users shall be punished for being careless. Passwords should be changed once
every three month, and strong passwords are to be maintained by the Sysadmins.
Yet people may forget their new passwords and get in contact with the local help
desk in order to restore network access. In case the protected LAN belongs to a
business, absent- minded users should be punished financially. However, such an
action creates the problem of passwords being scrabbled all over the working area
(post- its, pieces of paper, desk, computer). Users should be warned that they will
be restricted network access completely in case such an event shall take place.
o No computer should ever be left unattended with an active login. Key logging
software (discussed in chapter 5) has evolved to work invisibly in any system
passing data unnoticed through any firewall alongside with the browser’s web
traffic 217 .
o The Sysadmin should take care in installing software that will monitor user’s
behavior on the LAN. These exist simple packages 218 , which collect stats of
network usage and the types of commands users tend to use. Shall a anomaly be
detected, the account should be automatically blocked. Not only will this prevent
possible misuse of each other’s accounts, it will also prevent users from
experimenting with unknown commands (for example, under Unix the “rm –rf /”
command will erase all the data from the hard disk).
As seen from the above policy outline, the “people” element is critical to the security of every
side of the Pentagon. Moreover the concept of “central information control point” is introduced
in the face of the System Administrator. The natural question to ask is: “If the System
Administrator is the one in control of the whole system, who, then, controls the System
Administrator?”. Even in case when there are several Sysadmins managing the LAN, the whole
system is still in danger of being compromised internally. The possible consequences of such an
event have been brilliantly illustrated in Steven Spielberg’s science fiction movie “Jurassic
217
218
Eg. http://www.blazingtools.com/bpk.html
Eg. http://www.narus.com/
- 101 -
Park”. Depending on the overall value of the LAN and its internal resources a suitable solution
must be developed. For example, giving full access to all client account’s databases of some
bank to a System Administrator is simply unacceptable. A decentralized system of control can be
applied in this case. For example, one Sysadmin will have access to the whole system, except for
the logging facilities, which, in turn, shall be managed by someone else. Such a simple action
will make sure that, even in case of misuse of the system by the employees with the widest level
of access, traces of their work will be saved and analyzed for their purity. Whereas banks may
attend to this simple strategy to protect their system from interna l misuse, other organizations
may find it problematic to protect themselves from information leakage. The cheapest and most
effective, yet not bullet proof, solution may be the need for presence of two employees in order
to carry out database maintenance, where one will basically watch over the other. However, the
problem of trust cannot be solved with a 100% guarantee, just as the problem of trust cannot be
solved on the technological front (for example in public key cryptography and SSL
implementations, read chapter three for an explanation). Thus any organization, that has
information to protect, has to be very selective, when hiring a Sysadmin. Yet, the topic of human
psychology is out of the scope of this thesis. It is enough to understand, that the person managing
the servers on a LAN will almost inevitably have access to all the information and he/she may
very well use it for personal benefit, thus all has to be done in the power of management to
hire/keep a trustworthy employee.
Raising awareness
In order to raise the overall sense of security in a particular LAN all security issues have to be
made public. In other words, any attempt to compromise a LAN or any leakage of information is
to be made public over a series of security seminars. People responsible must not be punished at
first, but given a second chance to improve and let others learn from their mistakes. For example,
in case a weak password leads to some sort of information leakage, then a series of seminars for
LAN users may be organized based on the following schema:
•
•
•
•
Analyze the case
Analyze the value of information lost
Point at the people responsible i.e. the System Administrator and some LAN user, who
used a weak password
Explain what could be done in order to prevent such an event from occurring in the future
Although the above scenario is rather trite, it keeps happening every day. It is of uttermost
importance for the users of the LAN not only to follow security policies, but also to understand
the importance of security and the value of information standing at risk. In order to keep things a
bit more interesting, such that security seminars do not become routine and are paid little
attention from the users of the LAN, I suggest the management to simulate various types of
attack on a regular basis. This will keep the overall level of awareness high and increase the
popularity of security related seminars. Moreover users will become educated not only in
technical aspects of Internet Security but also topics such as Social Engineering (chapter 4) and
value of internal information.
“Paperless Office”
Bill Gates has suggested the implementation of a “Paperless Office” in his book “Business @
The Speed of Thought”219 . Gates’ prevailing idea back in 1999 was to get rid of all possible
printed documents within Microsoft in order to speed up business processes. Yet his idea can be
219
B. Gates, Business @ The Speed of Thought, Penguin Books Ltd., 1999
- 102 -
taken one step further in order to increase the security of a network against outside attacks. This
kind of approach has little to do with technical issues, it is much more focused on the “human
factor” on Internet Security. People are known to leave printed copies of documents lying around
(as they are more comfortable to read, than their digital versions); it is a common scenario for
someone to scribble access details on slips of paper or even on post-its anywhere around their
working area. In order to raise the user’s awareness and to implement an overall sense of security
within a particular company/institution sitting on a particular LAN a “Paperless Office”
approach in suggested, which consists of the following action set: At the end of each working
day, the cleaners are instructed to collect and destroy all paper that is found lying around
someone’s working place. All notes and post- its are to be collected and destroyed as well. Of
course documents printed on paper are important, yet they are not to be left easily accessible,
instead they are to be locked away. Putting them away in an unsafe drawer shall not be enough
of a security precaution, as the contents of any unlocked drawer are to be trashed as well. Of
course the constant application of such a procedure sounds more like an utopia and will probably
end up as being a very costly and rather ineffective procedure. Yet these “raids” can be
organized by the manage ment on a regular basis (for example once-twice every month). Such a
procedure, alongside with security seminars shall keep the overall level of security awareness
above average and help protect the LAN from SE attacks. However, a paperless office will
inevitably also bring along new problems, such as:
•
•
Centralized storage of sensitive information, meaning that in case the point of storage is
broken into, then all information is accessible at once.
Use of “high-tech devices” (such as mobile phones or PDAs) for personal notes. Personal
electronics are more likely to be lost or accessed by third parties (as they are carried
around), who, in turn, may be able to get access to desired information.
Whereas the first issue can be tackled with the use of appropria te technological solutions and the
employment of qualified personnel, the second brings back the problem of the “human factor”,
which can compromise the security of either some standalone system or the LAN as a whole.
It becomes rather clear, that the people operating the Internet as a whole are it’s weakest security
link on any of the given fronts. Suppose the net could work on its own, locking out potential
human mistakes on the Server OS, Web Server and the Transport Channel fronts, then the task of
establishing a secure LAN would have been much easier to tackle, as client machines can be
brought to a standard set of hardware and software tools and the people operating these can be
educated to be absolutely paranoid. Yet this is not the case and there are people operating all
fronts of Internet Security. Moreover, some fronts, such as the transport channel, were open for
misuse from the very beginning, thus we are left to combat a technological lock- in, building
secure solutions by using insecure technologies. However, the cheapest security solution is the
implementation of a security policy, which all LAN users must follow and understand. High-end
technological solutions are of little help in case they are used incorrectly or in case they can be
bypassed due to simple human carelessness.
To Sum Up
Most successful attacks against banks, corporations or even governments go unmentioned in the
media. Some of them even go unnoticed by the victims. And those that go public are not
rewarded. When Citibank lost $12 million to a Russian hacker in 1995, it announced that the
bank had been hacked into and instituted new and more powerful security measures to prevent
such attacks from occurring in the future. Even so, millions of dollars were withdrawn by people,
who believed their funds were vulnerable immediately after Citibank’s announcement. Citibank
recovered, but the lesson was clear: “Don’t publicize”. We need to publicize attacks. We need to
- 103 -
publicly understand why systems fail. We need to share information about security breaches:
causes, vulnerabilities, effects, methodologies. Secrecy only aids the attackers.
Security is not a product it is a process. One cannot just add it to a system. It is vital to
understand the real threats to a system, design a security policy that can prevent these threats,
and build in appropriate security countermeasures from the beginning. Perfect solutions are not
required, as they are in many cases simply not worth the time and money invested into their
setup and support, however, systems that can be easily broken are unacceptable. Good security
processes are essential to make security products work. In the real world, security threats are
everywhere. They’re not things to be avoided, they’re opportunities to make money. The prize
doesn’t go to the company that best avoids the threats, it goes to the company that best manages
the risk. I believe that computers alone cannot defend against a human attacker, hence efficient
systems employ experienced security analysts. The fundamental problems in security are no
longer about technology, they are about how this technology is used and by whom this
technology is used. It is essential to estimate the value of information, that is to be protected
from unwanted access, and only then build a security policy based on these estimates. Low value
information may usually be wanted only by script kiddies or someone penetrating a LAN “for
fun”, thus the level of protection does not have to be at the highest level of standards. Yet, as it
has already been pointed out before – systems that can easily be broken into are simply
unacceptable. Whereas in case there exists very sensitive information to hide from the outside
world, one must be extremely careful, when planning a security system. It will pay off to
investigate cases from the past, where typical attack scenarios are analyzed. Top-notch IT
solutions will never guarantee 100% security, as they are linked to people, operating these
solutions. No system is 100% secure, as there always remains someone will full access. Thus this
person/group of people must be selected with uttermost accuracy, they must also be rewarded
accordingly, such that no desire for information leakage shall arise. However, the issues of
human psychology are out of the scope of this thesis, yet one must keep in mind, that the person,
who has the most power within an organization – is the System Administrator, followed by the
IT department. Who watches over these people? How does one solve “the people” problem?
These questions remained unanswered over the whole history of the Internet and no viable
solution has yet been proposed to tackle them. Evident to this statement is the recent appearance
of a copy of the Central Bank of Russia customer’s accounts database on the local IT market220 .
Moreover, databases of GSM operators have been circulating the Internet for many years now.
Most probably this data was stolen by the company’s employees. The problem of security does
not lie with technology, it lies with the people using and operating that technology.
Despite its size and rapid growth, the Internet is still in its infancy. So is the software industry.
We are just beginning to learn how to develop secure software, and we are beginning to
understand that for our future, if it is to be online, we need to incorporate security into the basic
underpinnings of everything that we develop. The biggest obstacles to the evolution of Web
Security are by far not technological, they are a result of the market pressures created by its
sudden growth. Moreover, there are political pressures from governments, attempting to
understand and control the evolving market. On the technical front, we have in our hands most of
the tools we need to begin building a secure Web. It will not be sudden and it will result in a
lengthy process of evolution. As with any evolutionary process a number of dead ends will not
survive, whereas others will prosper. Some of the failures will be sudden and dramatic, others
will be gradual and quiet. The Web today is much smaller than it will eventually grow to be –
but it is already too large to understand anymore. There is a hard task ahead of us: evolving an
220
http://top.rbc.ru/index.shtml?/news/society/2005/03/30/30062622_bod.shtml -- RBC.ru stands for
RosBusinessConsulting and is a reliable information source on financial information inside Russia. On the local
market, preference is given to RBC over Reuters.
- 104 -
insecure architecture into a secure environment for electronic commerce and safe
communication.
As a final note I would like to point out, that a system can not be said to be secure and left at that
stage. The security of a LAN or of a particular system is to evolve alongside with the Internet
and the surrounding world. It is to be updated daily, some policies becoming obsolete and some
taking a slightly paranoid edge. Yet one can never stop the process of creation of a secure
environment, one must adapt to the changing world and the span of evolving technologies on the
net. Evolution of security is never to reach a final stage, it is an endless process, which becomes
more and more complicated as time goes by. However, as long as the Internet is managed by
human beings, they will remain the primary source of problems related to the security of the
system. Any human mistake can be noticed by someone with malicious deeds in mind,
moreover, we can be directed by someone into making a mistake (read chapter 4 for examples),
which will be exploited for someone else’s benefit. Thus, even having all the technology at hand
we are unsafe and the only way towards a secure network is the education of its users. Using the
net safely shall become a commonsense day-to-day activity, just like driving a car is perceived
today. The overall level of user’s security education will inevitably rise, leaving potential
hackers less and less chances for a successful attack. However, the Internet is still in its infantile
stage and it will grow exponentially over the next decades alongside with its user base. Thus it is
time to think safely now and start helping each other out in order to avoid all common scenarios,
that were investigated over the course of this thesis. Attacks and attacker will always get better,
and systems fielded today could be in place in 20 years from now. We need to refocus on the
process instead of the technology in order to achieve a secure web, as the fundamental problem
in security has always been about technology, yet it is more about how we use this technology.
I hope this thesis has aided the reader into thinking more safe ly and given ground for further
research and development.
- 105 -
Bibliography
1. Alvarez G., Petrovic S., “A new taxonomy of Web attacks”, Computers & Security, Vol.
22, 2003, pp. 435-449
2. Anderson J. P., Computer Security Technology Planning Study. ESD-TR-73-51,
Hanscom Field, Bedford, MA, October 1972
3. Anderson R. J., Security Engineering. Wiley Computer Publishing, 2001
4. Anderson R. J., Secrets Security Engineering: A Guide to Building Dependable
Distributed Systems, John Wiley & Sons Inc. (9 April, 2001)
5. Anley C., “Advanced sql injection in sql server applications”, Technical Teport, Next
Generation Security Software, January 2002. Can be seen at
http://www.nextgenss.com/papers/advanced_sql_injection.pdf
6. Aubrey-Jones D., “Internet – Virusnet?”, Networking Security, Feb 1997, pp 15-19
7. Babcock C., “Beware of a macro virus epidemic”, Computerworld, July 18, 1996, p. 122
8. Bellovin S. M., “Security Problems in the TCP/IP Protocol Suite”, Computer
Communication Review 19(2), April 1989, can be seen under
http://www.research.att.com/~smb/papers/ipext.pdf
9. Bellovin S. M., “The ICMP traceback message”, available from
http://www.research.att.com/~smb/papers/draft-bellovin-trace.txt
10. Bellovin S. M.. “Security Problems in the TCP/IP Suite”, ACM Computer
Communications Review, 19(2), March 1989
11. Biukovic L., “Unification of cyber-jurisdiction rules: just how close are the EU and the
US?”, Telematics and Informatics, Issue 19, 2002, p 142
12. Bontchev V., “Macro Virus Identification Problems”, Computers and Security, v 17 no 1,
1998, pp. 69-89
13. Bontchev V., “Possible Macro Virus Attacks and How to Prevent Them”, Computers and
Security, v 15 no 7, 1996, pp 595-626
14. Brock J. L., Trochelman G., Hoy J. B., Brewer M. T., Peterson B. A., Dittmer G.. GAO
Report – Morris Worm. INFORMATION MANAGEMENT AND TECHNOLOGY
DIVISION, WASHINGTON, D.C. June 1999
15. Carnegie-Mellon Software Engineering Institute, CERT Coordination Center, "Social
Engineering," CERT Advisory CA-90.04, revised Sept. 18, 1997
16. CERT Coordination Centre, “Ongoing Network Monitoring Attacks”, Annual Report
1994, Appendix A, CA-94:01
17. Cohen F., “Information System Attacks: A preliminary classification scheme”,
Computers & Security, Vol. 16, 1997, pp. 29-46
18. Cohen F., “Computer Viruses: Theory and Experiments.” Computers and Security, Vol.
6, pp 22-35, Elsevier Advanced Technology Publications, 1987
19. Cohen F., Trends in Computer Virus Research. 1991, Page 10.
http://all.net/books/integ/japan.html
20. Computer Incident Advisory Capability, U.S. Dept of Energy, CIAC Note 94-03a, July 6,
1994
21. Denning D. E., Brandstad D. K, “A Taxonomy for Key Escrow Encryption Systems”,
Communication of the ACM, Vol. 39, No. 3, March 1996, can be seen under
http://www.cosc.georgetown.edu/~denning/crypto/Taxonomy.html
22. Denning P. J., “Computer Viruses”, American Scientist, Issue 76 (May-June) 1988, pp
236-238.
23. Dewdney A. K., “A Core War Bestiary of Viruses, Worms and Other Threats to
Computer Memories”, Scientific American 252, 5, March 1985, can be seen here —
http://vx.netlux.org/lib/mad02.html
24. Digital Signature Law Survey, http://rechten.kub.nl/simone/ds- lawsu.htm
- 106 -
25. Eichin M. W. and Rochlis J. A., “With Microscope and Tweezers: An Analysis of the
Internet Virus of November 1988”, Proceedings of the IEEE Symposium on Research in
Security and Privacy, 1989, pp 236-343, can bee seen at http://ieeexplore.ieee.org/
26. Farmer D., Venema W., Improving the Security of Your Site by Breaking Into it.
Eindhoven University of Technology. Can be seen under
http://www.fish.com/security/admin- guide-to-cracking.html
27. Feistel H., “Cryptography and Computer Privacy”, Scientific American, May 1973,
Vol. 228, No. 5
28. Ferguson P., Senie D., “Network ingress filtering: defeating Denial of Service attacks
which employ IP source address spoofing”, in: RFC 2827, 2001
29. Gates B., Business @ The Speed of Thought, Penguin Books Ltd., 1999
30. Gemignami M., “Viruses and Criminal Law”, Communication of the ACM, Vol. 32, No.
6, June 1989, p 670
31. Geng X., Huang Y., Whinston A. B., “Defending wireless infrastructure against the
challenge of DDoS attacks”, Mobile Networks and Applications, Issue 7, 2002, pp 213223, can be seen at http://cism.bus.utexas.edu/works/articles/DDoS_ACM_final2_all.pdf
32. Geng X., Whinston A. B., “Defeating Distributed Denial of Service attacks”, IEEE IT
Professional, Vol. 2, 2000, pp. 36-42
33. Gil T. M., Poleto M., “MULTITOPS: a data-structure for bandwidth attack detection”,
Proceedings of 10th Usenix Security Symposium, Washington DC, August 2001, pp 23-38
34. Goldberg I., Wagner D., “Randomness and the Netscape Browser”, Dr. Dobb’s Journal,
January 1996
35. Hafner K., “Kevin Mitnick, Unplugged”, Esquire, 1995, August, p.81-88
36. Harley D., Slade R., Gattiker U. E., Viruses Revealed, McGraw Hill, 2001
37. Highland H., “A Macro Virus”, Computers and Security, v 8, 1989, pp. 178-188
38. Howard M., LeBlank D., Writing Secure Code, Microsoft Press, 2001
39. Hruska J., “Is the Virus Problem getting worse?”, Network Security, Volume 2001, Issue
2, 1 February 2001, Pages 13-16
40. Knaser S. D., “Global Communications and National Power: Life on the Pareto Frontier”,
World Policy Journal, 1991, pp 337-360
41. Landwehr C. E., Bull A. R., McDermott J. P., and Choi W. S., A Taxonomy of Computer
Security Flaws, with Examples. Information Technology Division, Code 5542, Naval
Research Laboratory, Washington, D.C. 20375-5337, can be seen under
http://www.cs.mdx.ac.uk/research/SFC/Papers/1994landwehr-acmcs.pdf
42. Landwehr C. E., Bull A. R., McDermott J. P., Choi W. S., “A taxonomy of Computer
Program Security Flaws, with Examples”, US Navy Report NRL/FR/5542-93-9591, (Nov
19, 1993). Please note, that this is a slightly different report, compared to the one listed
right above.
43. Lange L., “Hack punches hole in Microsoft NT security”, EE Times, 31.03.97, can be
seen under http://www.eetimes.com/news/97/947news/hack.html
44. Lee W., Stolfo S. J., Mok K. W., “A data mining framework for building intrusion
detection models”, Proceedings of the 1999 IEEE Symposium on Security and Privacy,
Oakland, Ca, May 1999, pp. 120-132
45. Leebron D. W., “Lying down with Procrustes: An Analysis of Harmonization Claims”, in
Bhagwati J. N., Hudec R. E., Fair Trade and Harmonization 1, MIT Press, 1996, pp. 41,
43-50
46. Less R. B., Taxonomies of Distributed Denial of Service networks, attacks, tools and
countermeasures. Available from http://www.ee.princeton.edu/~rblee/
47. McIlroy M. D., “Virology 101”, Computing Systems, University of California Press:
Berkeley, CA, 1989, page 4
48. Minor J. R., “Hackers, Phreakers, and Crackers”, ‘The true story of Kevin Mitnick World famous Computer Hacker’, Interzine. 1995
- 107 -
49. Mirkovic J., Prier G., Reiher P., “Attacking DDoS at the Source”, Proceedings of ICNP
2002, Paris, France, 2002, pp. 312-321
50. Mitnick K., “My first RSA Conference” Security Focus, April 30, 2001
51. Mitnick K., The Art of Deception, Wiley Publishing Inc., 2002
52. Mitnick K., The Art Of Intrusion: The Real Stories Behind The Exploits Of Hackers,
Intruders, And Deceivers, John Wiley & Sons, 2005
53. Nazario J., Defence and Detection Strategies against Net Worms, Artech House
Publishers, 2003
54. Park K., Lee H., “The effectiveness of route-based packet filtering for Distributed DoS
attack prevention in power- law Internets”, Proceedings of the ACM SIGCOMM 2001,
ACM Press, 2001, pp. 15-26
55. Powell T., Schneider F., JavaScript: The Complete Reference, Second Edition, McGrawHill/Osborne, 2004
56. Reid B., “Reflections on some recent widespread computer breakins”, Communication
of the ACM, Volume 30, February 1987.
57. Rivest R. L., “The case against regulation encryption technology”, Scientific American,
October 1998, pp. 116-117
58. Robinson P., “Word is out on virus that attacks macros”, Computer Weekly, 31 August
1995, p. 10
59. Ryburn P., COMP 1200, University of Memphis, January 1997
60. Savage S., Wetheral D., Karlin A., Anderson T., “Network Support for IP Traceback”,
IEEE/ACM Transaction on Networking 9, 2001, pp. 206-237 available from
http://www.csd.uch.gr/~hy558/papers/savage-traceback-sigcomm00.pdf
61. Schneider B., Secrets and Lies, 2000, John Wiley & Sons, Inc.
62. Scott D., Sharp R., “Abstracting Application-Level Web Security”, WWW2002, May
2002, can be seen at: http://www-lce.eng.cam.ac.uk/~djs55/swap/abstracting.pdf
63. Shannon C. E., “A mathematical theory of communication”, Bell System Technical
Journal, vol. 27, p. 379-423 and 623-656, July and October, 1948
64. Shimomura T., Markoff J., Takedown: The Pursuit and Capture of Kevin Mitnick,
America's Most Wanted Computer Outlaw-By the Man Who Did It, Warner Books Inc,
1998
65. Shoch J., Hupp J., “The ‘Worm’ Programs – Early Experience with a Distributed
Computation”, Communication of the ACM, March 1982, pp 172-180.
http://portal.acm.org/citation.cfm?id=358455
66. Singh S., The Code Book, The Science of Secrecy from Ancient Egypt to Quantum
Cryptography, Fourth Estate Ltd. 2000
67. Solomon A., “A Brief History of Computer Viruses”, Computer Fraud and Security
Bulletin, Dec 1993, pp 9-19
68. Spafford E. H., The Internet Worm Incident, Purdue CS Technical Report TR-CSD-933
69. Spafford E. H., The Internet Worm Program: An Analysis. Purdue CS Technical Report
TR-CSD-823
70. Stoll C., The Cuckoo’s Egg: tracking a spy through the maze of computer espionage,
Pocket Books, October 2000
71. Sussman V., “Gotcha! A Hard-Core Hacker Is Nabbed”, U.S. News & World Report,
1995, February
72. Talpade R. R., Kim G., Khurana S., “NOMAD: Traffic based network monitoring
framework for anomaly detection”, Proceedings of the fourth IEEE Symposium on
Computers and Communication, 1998, pp. 442 – 451, can bee seen at
http://ieeexplore.ieee.org/
73. The World Wide Web Security FAQ available from http://www.w3.org/Security/FAQ/
74. Thompson K., “Reflections of Trusting Trust”, Communication of the ACM, Vol. 27, No.
8, Aug 1984, pp. 761-763. http://www.acm.org/classics/sep95/
- 108 -
75. Verma P., “Virus Protection”, Encyclopedia of Information Security (Kluwer, to be
published), can be seen under: http://www.eecs.umich.edu/~pverma/pubs/virus.pdf
76. Zaroo P., “A Survey of DDoS attacks and some DDoS defense mechanisms”, Advanced
Information Assurance (CS626), available at:
http://www.cs.purdue.edu/homes/zaroo/papers/my_papers/ddos_paper.pdf
- 109 -

Chapter 2

Transcription

Similar documents

Kallima - Press Release - Exhibit-e

Dionne Warwick to be Featured in Student Council Concert

Sorry, guys: The pop world belongs to Lady GaGa and Róisín Murphy.

Introduction to Plant Virology • History • Definitions • Classification

Corporate Brochure

Mark Shtern

Viruses (1)

Bond Movies Dr. Jonathan M Sackier As an Englishman of a certain