Focused On Your Success

Managing Network Security

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 I’d 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 don’t 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 won’t 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 own protocol for a new application and attack over it.

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 can’t 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 doesn’t 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 doesn’t detect many of the common attacks used by attackers today.

49 - Attack any system that doesn't run Unix. Since almost all of today’s 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 infinity - 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 doesn’t 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.

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 hadn’t 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 fc@all.net.