Transcript MISC PICTURES - Hiram College

Program Security – Part 3
Malware
 7 Years ago, "malware" simply referred to viruses.
 Today, hackers and spammers have developed all sorts




of ways to invade computers .
Malware is growing quickly.
McAfee Avert Labs expected in 2006 to have recorded
their 225,000th unique computer/ network threat, finding
50,000 threats between Jan and Nov of 2006 alone.
The motive for creating malware has been profit or
spying in most cases, and as profits from creating
malware have grown, paid professionals have begun to
make new and ever more dangerous forms.
The return on creating malware has been high in large
part because so many victims do not know what to look
out for.
From http://www.itsecurity.com/features/nastiest-malware-trends-011207/
2
Malicious Software
 Programs exploiting system vulnerabilities are
known as malicious software or malware
 Some are program fragments that need a host
program
 e.g. viruses, logic bombs, and backdoors
 Some are independent self-contained programs
 e.g. worms, bots replicating or not
 These are sophisticated threats to computer
systems
3
Malware Terminology











Virus
Worm
Logic bomb
Trojan horse
Backdoor (trapdoor)
Mobile code
Auto-rooter kit (virus
generator)
Spammer and flooder
programs
Keyloggers
Rootkit
Zombie, bot




Adware
Browser hijacks
Internet dialers
Drive-by-downloads
(DBDs)
4
Kinds of Malicious Code
 Virus: a program that attaches to an executable





host program and is capable of infecting other
executable programs.
Trojan Horse: a program that has a “secondary”
non-obvious functionality.
Worm: a program that self-replicates by itself
over a network.
Logic bomb: a program that triggers some action
when a certain condition is satisfied.
Time bomb: a program that triggers some action
at a certain time.
Program with a trapdoor/backdoor: a program
that has a functionality that is activated through
some secret input.
5
Viruses
History of Computer Viruses
 Programmers wrote the first computer viruses
on Apple II computers.
 In 1983, Fred Cohen was a graduate student at
the USC. He described a type of Trojan horse
that an instructor (Len Adleman) named a
“computer virus.”
 Cohen designed a computer virus to acquire
privileges on a VAX-11/750 running the UNIX
OS.
 He obtained all system rights within half an hour
on the average (longest time=an hour, shortest
time less than 5 minutes).
7
History of Computer Viruses
 The virus did not degrade the respond time
noticeably. Most users never knew the system was
under attack.
 In 1984, Cohen’s experiment on a UNIVAC 1108
showed that viruses could spread throughout that
system.
 Unlike the UNIX system, the UNIVAC partially
implemented the Bell-LaPadula model, using
mandatory protection mechanisms (the simple
security condition was implemented but the *property was not).
 As writing was not inhibited (no *-property
enforcement), viruses spread easily.
8
History of Computer Viruses
 The Brain (Pakistani) virus was created in early 1986.
 Written for IBM PCs
 Alters the boot sectors of floppy disks, possibly
corrupting files in the process.
 Also spreads to any uninfected floppy disks
inserted into the system.
 In 1987, computer viruses infected Macintosh,
Amiga, and other computers.
9
History of Computer Viruses
 The MacMag Peace virus would print a
“universal message of peace” on March 2, 1988,
and then delete itself.
 In 1987, Tom Duff experimented on UNIX
systems with a small virus that copied itself into
executable files.
 48 infected programs were placed on the
most heavily used machine in the computer
center.
 The virus spread to 46 systems in 8 days.
10
History of Computer Viruses
 In 1989, Harold J. Highland developed a virus
for Lotus 1-2-3.
 The virus was stored as a set of commands in a
spreadsheet, and was loaded when a file was
opened.
 The virus was intended for a demonstration only.
 It changed a value in a specific row, column and
then spread to other files.
11
Pseudocode for a Virus
beginvirus:
if spread-condition then begin
for some set of target files do begin
if target is not infected then begin
determine where to place virus instructions
copy instructions from beginvirus to endvirus
into target
alter target to execute added instructions
end;
end;
end;
perform some action(s)
goto beginning of infected program
endvirus:
12
 The insertion phase must be present:
 Need not always be executed.
 The Lehigh virus would check for an uninfected
boot file (the spread condition in the
pseudocode).
 If one is found, it would infected the file (the
set of target files).
 The virus would then increment a counter and
test to see if the counter = 4.
 If 4 is reached, the virus would erase the disk.
13
14
What the Brain Virus does
 • Once activated:
 Upper memory bound is reset below itself.
 Traps disk read interrupt by resetting the pointer to
itself.
 Traps boot read calls so that they return proper
contents
 Virus is stored in six disk sectors (including boot).
 With every read it inspects the boot sector and if it
doesn’t find itself it replicates.
15
The Brain Virus
 Reportedly originated from Pakistan.
 Original version contained the following
text code:
 Welcome to the Dungeon (c) 1986 Basit * Amjad (pvt)
Ltd. BRAIN COMPUTER SERVICES 730 NIZAM
BLOCK ALLAMAIQBAL TOWN LAHORE-PAKISTAN
PHONE: 430791,443248,280530.
Beware of this VIRUS.... Contact us for vaccination...
 The virus was reportedly written to curb/identify illicit
copying of software
16
Viruses
 A virus is a piece of software that can "infect" other




programs by modifying them
The modification includes a copy of the virus
program, which can then go on to infect other
programs.
A virus can do anything that other programs do.
The difference is that a virus attaches itself to another
program and executes secretly when the host
program is run.
Once a virus is executing, it can perform any function
the user of the infected program can perform, such
as erasing files and programs. (So, if user is root!)
17
Viruses
 Most viruses carry out their work in a manner
that is specific to a particular operating system
and, in some cases, specific to a particular
hardware platform.
 Thus, they are designed to take advantage of
the details and weaknesses of particular
systems.
 A typical virus goes through several phases.
18
Viruses
 During its lifetime, a typical virus goes through the
following four phases:
1. Dormant phase:
 The virus is idle.
 The virus will eventually be activated by some
event, such as a date, the presence of another
program or file, or the capacity of the disk
exceeding some limit.
 Not all viruses have this stage.
19
Viruses
2. Propagation phase:
 The virus places an identical copy of itself into
other programs or into certain system areas
on the disk.
 Each infected program will now contain a
clone of the virus, which will itself enter a
propagation phase.
20
Viruses
3. Triggering phase:
 The virus is activated to perform the function
for which it was intended.
 As with the dormant phase, the triggering
phase can be caused by a variety of system
events, including a count of the number of
times that this copy of the virus has made
copies of itself.
21
Viruses
4. Execution phase:
 The function is performed, which may be
harmless, e.g. a message on the screen, or
damaging, e.g. the destruction of programs
and data files
22
Virus Structure
 A virus can be prepended or postpended to an
executable program, or it can be embedded in
some other fashion.
 The key to its operation is that the infected
program, when invoked, will first execute the
virus code and then execute the original code of
the program.
 Once a virus has gained entry to a system by
infecting a single program, it is in a position to
infect some or all other executable files on that
system when the infected program executes.
23
Virus Structure
 Thus, viral infection can be completely
prevented by preventing the virus from gaining
entry in the first place.
 Unfortunately, prevention is extraordinarily
difficult because a virus can be part of any
program outside a system.
 Thus, unless one is content to write all one's
own system and application programs, one is
vulnerable.
24
A Virus Has 3 Parts
 Infection mechanism:
 The means by which a virus spreads, enabling it
to replicate.
 The mechanism is also referred to as the infection
vector.
 Trigger:
 Event or condition determining when the payload
is activated or delivered.
 Payload:
 What the virus does, besides spreading.
 The payload may involve damage or may involve
benign but noticeable activity.
25
General Depiction of
A Virus Structure
The virus code, V, is prepended
to infected programs.
It is assumed that the entry point
to the program, when invoked, is
the first line of the program.
An infected program begins with
the virus code.
The first line of code is a jump to
the main virus program.
The second line is a special
marker that is used by the virus
to determine whether or not a
potential victim program has
already been infected with this
virus.
26
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Another Depiction of
A Virus Structure
When the program is invoked,
control is immediately transferred
to the main virus program.
The virus program first seeks out
uninfected executable files and
infects them.
Next, the virus may perform some
action, usually detrimental to the
system.
This action could be performed
every time the program is
invoked, or it could be a logic
bomb that triggers only under
certain conditions.
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie27
Brown,
Another Depiction of
A Virus Structure
Finally, the virus transfers control
to the original program.
If the infection phase of the
program is reasonably rapid, a
user is unlikely to notice any
difference between the execution
of an infected and uninfected
program.
28
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie
Brown,
Virus Classification
 There has been a continuous arms race
between virus writers and writers of antivirus
software since viruses first appeared.
 As effective countermeasures have been
developed for existing types of viruses, new
types have been developed.
 Many classify viruses by target or concealment
strategy:
Boot sector
File infector
Macro virus
Encrypted virus
Stealth virus
Polymorphic virus
Metamorphic virus
29
Virus Classification by Target
 Boot sector infector:
 Have O/S on a disk.
 Infects a master boot record or boot record
and spreads when a system is booted from
the disk containing the virus.
 Special code transfers the O/S from disk to
memory and the computer starts (Boot load).
 Boot sector contains the bootstrap loader
pointing to sector that has system
initialization.
 Virus substitutes (circumvents) bootstrap
loader process.
30
Virus Classification by Target
 File infector:
 Infects files that the operating system or shell
consider to be executable.
 Macro virus:
 Infects files with macro code that is
interpreted by an application.
31
Virus Classification by Concealment Strategy
 Encrypted virus:
 The virus creates a random encryption key, stored
with the virus, and encrypts the remainder of the
virus.
 When an infected program is invoked, the virus
uses the stored random key to decrypt the virus.
 When the virus replicates, a different random key
is selected.
 Stealth virus:
 A form of virus explicitly designed to hide itself
from detection by antivirus software.
 Thus, the entire virus, not just a payload is hidden.
32
Virus Classification by Concealment Strategy
 Polymorphic virus: A virus that mutates with every
infection, making detection by the “signature” of the
virus impossible.
 A common detection technique is to search for a
signature - some special characters in the virus
 Change form at each replication.
 How?
 Intersperse arbitrary meaningless
instructions into code.
 Change control flow, rearrange.
 Use encryption: virus stores key K,
C = Enc(K,code), Dec_Loader_Code.
33
 Metamorphic virus:
 As with a polymorphic virus ,a metamorphic
virus mutates with every infection.
 The difference is that a metamorphic virus
rewrites itself completely at each iteration,
increasing the difficulty of detection.
 Metamorphic viruses may change their behavior
as well as their appearance.
34
Macro Viruses
 In the mid-1990s, macro viruses became by far the
most prevalent type of virus.
 Macro viruses are particularly threatening for a
number of reasons:
 1. A macro virus is platform independent.
 Virtually all of the macro viruses infect Microsoft
Word documents.
 Any hardware platform and operating system that
supports Word can be infected.
35
Macro Viruses
 2. Macro viruses infect documents, not
executable portions of code.
 Most of the information introduced onto a
computer system is in the form of a document
rather than a program.
 3. Macro viruses are easily spread.
 A very common method is by electronic mail.
36
Macro Viruses
 Macro viruses take advantage macros found in Word




and other office applications such as Microsoft Excel.
A macro is an executable program embedded in a
word processing document or other type of file.
Typically, users employ macros to automate repetitive
tasks and thereby save keystrokes.
The macro language is usually some form of the Basic
programming language.
A user might define a sequence of keystrokes in a
macro so that the macro is invoked when a function
key or special short combination of keys is input.
37
Macro Viruses
 Successive releases of Word provided
increased protection against macro viruses.
 Microsoft offers an optional Macro Virus
Protection tool that detects suspicious Word files
and alerts the customer to the potential risk of
opening a file with macros.
 Various antivirus product vendors have
developed tools to detect and correct macro
viruses.
 As in other types of viruses, the arms race
continues in the field of macro viruses, but they
no longer are the predominant virus threat.
38
E-mail Viruses
 A more recent development in malicious
software is the e-mail virus.
 The first rapidly spreading e-mail viruses, such
as Melissa, made use of a Microsoft Word
macro embedded in an attachment.
 If the recipient opens the e-mail attachment, the
Word macro is activated.
 Then the e-mail virus sends itself to everyone on
the mailing list in the user's e-mail package, and
also does local damage.
39
E-mail Viruses
 At the end of 1999, a more powerful version of
the e-mail virus appeared.
 This newer version can be activated merely by
opening an e-mail that contains the virus rather
than opening an attachment.
 The virus uses the Visual Basic scripting
language supported by the e-mail package.
 Thus we see a new generation of malware that
arrives via e-mail and uses e-mail software
features to replicate itself across the Internet.
40
E-mail Viruses
 The virus propagates itself as soon as activated
(either by opening an e-mail attachment of by
opening the e-mail) to all of the e-mail
addresses known to the infected host.
 As a result, whereas viruses used to take
months or years to propagate, they now do so in
hours.
 This makes it very difficult for antivirus software
to respond before much damage is done.
 Ultimately, a greater degree of security must be
built into Internet utility and application software
on PCs to counter the growing threat.
41
Resident Viruses
 Resident code in O/S: code that is constantly on
memory & handle events.
 An infected resident code program will be
activated many times giving the opportunity
to the virus to do various checks, clean
traces, trigger malicious actions or perform
more infections.
42
Signatures
 What is the telltale sign of the virus existence?
 Particular piece of code existing as part of an
executable.
 Virus-specific traces in various O/S locations
(e.g., registry etc.)
 A virus scanner looks for such virus signatures.
 A virus may want to recognize itself as well.
43
Virus Countermeasures
 The ideal solution to the threat of viruses is
prevention:
 Do not allow a virus to get into the system in
the first place.
 This goal is, in general, impossible to achieve,
although prevention can reduce the number of
successful viral attacks.
 The next best approach is to be able to do the
following:
 Detection: Once the infection has occurred,
determine that it has occurred and locate the
virus.
44
Virus Countermeasures
 Identification: Once detection has been
achieved, identify the specific virus that has
infected a program.
 Removal: Once the specific virus has been
identified, remove all traces of the virus from the
infected program and restore it to its original
state.
 Remove the virus from all infected systems so
that the disease cannot spread further.
 If detection succeeds but either identification or
removal is not possible, then the alternative is to
discard the infected program and reload a clean
backup version.
45
General Rules of Thumb for Preventing a
Virus Infection
 Don’t execute code you are not sure about.
 Don’t click on icons you are not sure what
they will do.
 Use software that you trust.
 Backup your files.
 Use virus scanners (anti-virus software)
 Don’t accept disks or downloads from those you
don’t trust.
46
Anti-Virus Evolution
 Advances in virus and antivirus technology go hand
in hand.
 Early viruses were relatively simple code fragments
and could be identified and purged with relatively
simple antivirus software packages.
 As the virus arms race has evolved, both viruses
and, necessarily, antivirus software have grown
more complex and sophisticated.
47
Anti-Virus Evolution
 We often classify antivirus software as being in
one of four generations of antivirus software
 A first-generation scanner requires a virus
signature to identify a virus.
 The virus may contain "wildcards" but has
essentially the same structure and bit pattern
in all copies.
 Such signature-specific scanners are limited
to the detection of known viruses.
48
Anti-Virus Evolution
 A second-generation scanner uses heuristic
rules to search for probable virus infection, e.g
to look for fragments of code that are often
associated with viruses.
 Another second-generation approach is
integrity checking, using a hash function
rather than a simpler checksum.
49
Anti-Virus Evolution
 Third-generation programs are memory-resident
programs that identify a virus by its actions
rather than structure in an infected program.
 These have the advantage that it is not
necessary to develop signatures / heuristics,
but only to identify the small set of actions
indicating an infection is attempted and then
intervene.
50
Anti-Virus Evolution
 Fourth-generation products are packages
consisting of a variety of antivirus techniques
used in conjunction.
 These include scanning and activity trap
components.
 In addition, such a package includes access
control capability, which limits the ability of
viruses to penetrate a system and then limits
the ability of a virus to update files in order to
pass on the infection.
51
Generic Decryption
 More sophisticated antivirus approaches and
products continue to appear.
 Some of the most important are
 Generic decryption (GD)
 This technology enables the antivirus program
to easily detect even the most complex
polymorphic viruses, while maintaining fast
scanning speeds.
 In order to detect encrypted viruses,
executable files are run through a GD
emulator
52
Generic Decryption
 CPU emulator: A software-based virtual
computer that interprets instructions in an
executable file rather than executing them on
the underlying processor.
 Virus signature scanner: scans the target code
looking for known virus signatures.
 Emulation control module: Controls the
execution of the target code.
 At the start of each simulation, the emulator
begins interpreting instructions in the target
code, one at a time.
53
Generic Decryption
 Thus, if the code includes a decryption routine that
decrypts and hence exposes the virus, that code is
interpreted.
 In effect, the virus does the work for the antivirus
program by exposing the virus.
 Periodically, the control module interrupts
interpretation to scan the target code for virus
signatures.
 During interpretation, the target code can cause no
damage to the actual personal computer
environment, because it is being interpreted in a
completely controlled environment.
54
Generic Decryption
 The most difficult design issue with a GD scanner is
to determine how long to run each interpretation.
 Virus elements are activated soon after a program
begins executing, but this need not be the case.
 The longer the scanner emulates a particular
program, the more likely it is to catch any hidden
viruses.
 However, the antivirus program can take up only a
limited amount of time and resources before users
complain.
55
Digital Immune System
 The digital immune system is a comprehensive
approach to virus protection developed by IBM
and subsequently refined by Symantec.
 The objective of this system is to provide rapid
response time so that viruses can be stamped
out almost as soon as they are introduced.
 When a new virus enters an organization, the
immune system automatically captures it,
analyzes it, adds detection and shielding for it,
removes it, and passes information about that
virus to other systems so that it can be detected
before it is allowed to run elsewhere, as the next
slide illustrates
56
Digital Immune System
1. A monitoring program on each
PC uses a variety of heuristics to
infer that a virus may be present,
and forwards a copy to an
administrative machine.
2. The admin machine encrypts
this and sends it to a central virus
analysis machine.
3. This machine creates an
environment in which the infected
program can be safely run for
analysis. The virus analysis
machine then produces a
prescription for identifying and
57
removing the virus.
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Digital Immune System
4. The resulting prescription is
sent back to the administrative
machine.
5. The administrative machine
forwards the prescription to the
infected client.
6. The prescription is also
forwarded to other clients in the
organization.
7. Subscribers worldwide receive
regular antivirus updates to
protect from new virus
58
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Digital Immune System
 The success of the digital immune system
depends on the ability of the virus analysis
machine to detect new and innovative virus
strains.
 By constantly analyzing and monitoring the
viruses found in the wild, it should be possible to
continually update the digital immune software
to keep up with the threat.
59
Behavior-Blocking Software
60
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Worms
Worms
 A worm is a program that can replicate itself and send




copies from computer to computer across network
connections.
Upon arrival, the worm may be activated to replicate
and propagate again.
In addition to propagation, the worm usually performs
some unwanted function.
Network worm programs use network connections to
spread from system to system.
Once active within a system, a network worm can
behave as a computer virus or bacteria, or it could
implant Trojan horse programs or perform any number
of disruptive or destructive actions.
62
Worms
 To replicate itself, a network worm uses some sort of
network vehicle such as email, remote execution or
remote login capabilities.
 The new copy of the worm program is then run on
the remote system where, in addition to any
functions that it performs at that system, it continues
to spread in the same fashion.
 A network worm exhibits the same characteristics as
a computer virus: a dormant phase, a propagation
phase, a triggering phase, and an execution phase.
63
Worms
 The propagation phase generally:
 searches for other systems to infect by examining
host tables or similar repositories of remote system
addresses;
 establishes a connection with a remote system;
and copies itself to the remote system and causes
the copy to be run.
 The network worm may also attempt to determine
whether a system has previously been infected
before copying itself to the system.
64
Worms
 In a multiprogramming system, it may also disguise




its presence by naming itself as a system process
or using some other name that may not be noticed
by a system operator.
The concept of a computer worm was introduced in
John Brunner’s 1975 SF novel “The Shockwave
Rider”.
The first known worm implementation was done in
Xerox Palo Alto Labs in the early 1980s.
It was a nonmalicious search for idle systems to
use to run a computationally intensive task.
As with viruses, network worms are difficult to
counter.
65
Worms vs Viruses
 Both self-replicate.
 A virus needs a carrier. It will be activated
whenever the carrier is activated.
 A worm does not need a carrier: when it is
unleashed it either advances by itself or dies.
66
Morris Worm
 Until the current generation of worms, the best known
was the worm released onto the Internet by Robert
Morris in 1988.
 Ironically, Morris’s father was the chief technology
scientist for the National Security Agency at the time.
 The Morris worm was designed to spread on UNIX
systems and used a number of different techniques for
propagation.
 When a copy began execution, its first task was to
discover other hosts known to this host that would
allow entry from this host.
67
Morris Worm
 The worm performed this task by examining a variety
of lists and tables, including
 system tables that declared which other machines
were trusted by this host, users' mail forwarding
files,
 tables by which users gave themselves permission
for access to remote accounts,
 the status of network connections.
 For each discovered host, the worm tried a number
of methods for gaining access:
68
Morris Worm
 It attempted to log on to a remote host as a
legitimate user, having cracked the local
password file, and assuming that many users
use the same password on different systems.
1. It exploited a bug in the fingerd protocol
2. It exploited a trapdoor in the debug option of the
remote sendmail process.
69
Morris Worm
 If any of these attacks succeeded, the worm
achieved communication with the operating
system command interpreter.
 It then sent this interpreter a short bootstrap
program, issued a command to execute that
program, and then logged off.
 The bootstrap program then called back the
parent program and downloaded the remainder
of the worm. The new worm was then executed.
70
Morris Worm
 Launched in 1988, November 2
 Infected 10% of the Internet in a matter of
hours.
 Damage $10M - $100M
 “Killed” a number of days afterwards as system
administrators worked to clean up their systems.
 Wreaked unimaginable havoc as safeguards
were not in place for such an attack.
71
Morris Worm Details
 Hid itself: changed its name so that it would look
inconspicuous in the list of processes.
 Took measures to prevent the exposure of its code.
 Prevented a “core dump” from being created; this
disallowed the recovery of the worm’s code if a
crash occurred.
 Read the current time to seed its random number
generator.
 Used a random number to checks whether or not to
check for its existence (6 out of 7 times it checked)
for the first infection. Then it does not check.
 Was programmed to send one byte to a specific IP
address supposedly to monitor the spread rate.
72
Morris Worm Details
 The worm executes the Cracksome routine that
searches for machines to crack accounts.
 Then executes “other_sleep” for 30 seconds.
 Other_sleep is described later.
 Then execute Cracksome again.
 The worm spawns a new version of itself and
runs the infect routine.
 Then execute other_sleep for 120 seconds.
 It then repeats.
73
Morris Worm Details
 The Cracksome procedure prepared grounds for
the infect procedure:
 It checked various locations for possible
target machines.
 It launched a dictionary attack against the
/etc/passwd file using side information.
 It used public-account information and an
encrypted internal little dictionary of 432
words.
 The worm could also read a locally installed
dictionary if it couldn’t break an account.
74
Morris Worm Details
 The function other_sleep:
 The worm would try to connect to another
worm on the same network.
 After an identification step one of the two
worms would decide to die (decided at
random).
 However the worm did not die immediately: the
worm had to check at least 10 words from
internal dictionary, collect the entire list of users
to attack, complete the basic parts of cracksome
procedure etc.
75
Morris Worm Details – Problems Reared
Their Heads
 There were too many safeguards built-in to
prevent the worm from stopping too quickly that
actually made the termination through
other_sleep not very likely.
 Several worms began running in the same
machine.
 There was a slow response time in the
identification step.
 1 out 7 times the worm ignored the outcome
of the kill request anyway.
76
Morris Worm Details
 The infect routine:
 It attempted to infect a given IP address.
 It tried three approaches:
 Create a duplicate process on a remote machine
through a remote shell (an account would be
needed for that to be available from the
cracksome process).
 Exploit a buffer overflow in the fingerd the finger
daemon.
 Exploit a well-known sendmail bug where the
existence of a DEBUG option that shouldn’t have
been left activated that allowed the caller to
execute commands.
77
Morris Worm Details
 After a successful infection (i.e., gaining some
access to a remote machine): a bootstrap loader
was sent to the remote machine.
 99 lines of C code were compiled on the fly.
 The bootstrap loader would fetch the remaining
parts of the worm.
 Authentication was used again between the
bootstrap loader and the parent worm.
Morris Worm Details from slides by CSE281 - Computer Security (Spring
2008) University of Connecticut ©2006-8 Aggelos Kiayias
78
Worm in Action
 Internet hosts started to experience heavy loads of
processes (ps –e shows all processes)
 In a single machine multiple worm processes continued
running and reinfecting.
 The worm was hard to kill because it was changing its
process id constantly and it kept reinfecting a machine
(due to Morris’ error) the code was heavily biased
towards keeping the worm alive thus depleting the
infected machine’s resources with multiple processes.
79
Lessons Learned From the Morris Worm Attack
 The realization that the most devastating
attacks could come from inside the system!
 Hide /etc/passwd
 Assign different user id’s to services.
 Patch vulnerabilities.
 Develop programs to detect vulnerabilities.
 Don’t leave backdoors in software after
development.
80
Historical Notes
 Worm was written by Robert Morris, Jr. a 23
year old graduate student at Cornell.
 Reportedly when he realized the magnitude of
the disaster he tried to communicate
anonymously some method to stop the worm.
 At the same time the worm was reverseengineered and various countermeasures were
proposed.
 He was convicted under the Computer Fraud
and Abuse Act of ‘86 and received 3 years jail
time (suspended), 400 hours community service
and $10,000 fine.
81
Historical Notes
 1999 Morris received is PhD from Harvard and
was appointed an assistant professor at MIT.
 2006 Morris was tenured at MIT.
 His career was slower to develop than it would
have been had he not developed the worm.
82
Worm Propagation
Model
Propagation proceeds through
three phases.
In the initial phase, the number of
hosts increases exponentially.
To see that this is so, consider a
simplified case in which a worm is
launched from a single host and
infects two nearby hosts.
Each of these hosts infects two
more hosts, and so on.
This results in exponential growth.
After a time, infecting hosts waste
some time attacking alreadyinfected hosts, which reduces the
rate of infection.
83
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Worm Propagation Model
During this middle phase, growth
is approximately linear, but the
rate of infection is rapid.
When most vulnerable computers
have been infected, the attack
enters a slow finish phase as the
worm seeks out those remaining
hosts that are difficult to identify.
Clearly, the objective in
countering a worm is to catch the
worm in its slow start phase, at a
time when few hosts have been
infected.
84
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Worm Attacks - Code Red
 The contemporary era of worm threats began with the





release of the Code Red worm in July of 2001.
Code Red exploits a security hole in the Microsoft
Internet Information Server (IIS) to penetrate and
spread.
It also disables the system file checker in Windows.
The worm probes random IP addresses to spread to
other hosts.
During a certain period of time, it only spreads.
It then initiates a denial-of-service attack against a
government Web site by flooding the site with packets
from numerous hosts.
85
Worm Attacks - Code Red
 The worm then suspends activities and reactivates




periodically.
In the second wave of attack, Code Red infected
nearly 360,000 servers in 14 hours.
In addition to the havoc it caused at the targeted
server, Code Red consumed enormous amounts of
Internet capacity, disrupting service.
Code Red II is a variant that targets Microsoft IISs.
In addition, this newer worm installed a backdoor
allowing a hacker to direct activities of victim
computers.
86
Code Red Worm Details
 Released July 13, 2001.
 Infection took advantage of a buffer overflow in
the Microsoft Internet Information Server.
 For 20 days out of a month the worm spread.
 After the “latent period” of infection it defaced
the web-site.
 Exhibited a monthly pattern.
Code Red Worm Details from slides by CSE281 - Computer Security
(Spring 2008) University of Connecticut ©2006-8 Aggelos Kiayias
87
Code Red Worm
http://www.ciac.org/ciac/bulletins/l-117.shtml
88
Code Red Worm
89
Code Red Worm, Version 2
 Released July 19, 2001.
 Improved version that fixed some previous bugs
(esp. in how to select the IP addresses).
 Once the latent spreading period expired the
worm launches denial of service attacks to a
number of sites including www.whitehouse.gov
90
Worm Attacks - SQL Slammer Worm
 In early 2003, the SQL Slammer worm appeared.
 This worm exploited a buffer overflow vulnerability in
Microsoft SQL server.
 The Slammer was extremely compact and spread
rapidly, infecting 90% of vulnerable hosts within 10
minutes.
 Late 2003 saw the arrival of the Sobig.f worm, which
exploited open proxy servers to turn infected
machines into spam engines.
 At its peak, Sobig.f reportedly accounted for one in
every 17 messages and produced more than one
million copies of itself within the first 24 hours.
91








Slammer Worm
Exploits buffer overflow vulnerability in MS SQL
server.
Released January 25, 2003.
Rapid spread: 75,000 hosts within the first 10 minutes!
Routers flooded each other with routing updating
messages.
Worm-generated (and related packets) reached global
Internet bandwidth in 15 minutes!!!
Slammer’s army of clones was doubling every 8.5
seconds!
In a matter of minutes, huge chunks of the Internet
were taken off-line.
$1billion losses - a conservative estimate
92
Slammer Attack Details
 Looked at the number of msec’s elapsed on
CPU clock since booting and interpreted this as
IP address.
 Slammer then prepared a properly addressed
envelope and pointed to itself as the code to send.
 Looped around immediately for next machine!
(not even waiting for reading clock again).
93
94
95
More Slammer Effects
 Some of the infrastructure brought down:
 ATM networks.
 South Korea cell phone network.
 Continental Airlines Ticket processing
96
Recent Worm Attacks - Mydoom
 Mydoom is a mass-mailing e-mail worm that appeared
in 2004.
 It followed a growing trend of installing a backdoor in
infected computers, thereby enabling hackers to gain
remote access to data such as passwords and credit
card numbers.
 Mydoom replicated up to 1000 times per minute and
reportedly flooded the Internet with 100 million
infected messages in 36 hours.
97
Worm Technology
 The state of the art in worm technology includes the
following:
 Multiplatform: Newer worms are not limited to
Windows machines but can attack a variety of
platforms, especially the popular varieties of UNIX.
 Multi-exploit: New worms penetrate systems in a
variety of ways, using exploits against Web servers,
browsers, e-mail, file sharing, and other networkbased applications.
 Ultrafast spreading: One technique to accelerate the
spread of a worm is to conduct a prior Internet scan to
accumulate Internet addresses of vulnerable
machines.
98
Worm Technology
 Polymorphic: To evade detection, skip past filters,
and foil real-time analysis, worms adopt the virus
polymorphic technique.
 Each copy of the worm has new code generated
on the fly using functionally equivalent instructions
and encryption techniques.
 Metamorphic: In addition to changing their
appearance, metamorphic worms have a repertoire
of behavior patterns that are unleashed at different
stages of propagation.
99
Worm Technology
 Transport vehicles: Because worms can rapidly
compromise a large number of systems, they
are ideal for spreading other distributed attack
tools, such as distributed denial of service bots.
 Zero-day exploit: To achieve maximum surprise
and distribution, a worm should exploit an
unknown vulnerability that is only discovered by
the general network community when the worm
is launched.
100
Worm Countermeasures
 There is considerable overlap in techniques for
dealing with viruses and worms.
 Once a worm is resident on a machine, antivirus
software can be used to detect it.
 In addition, because worms propagation generates
considerable network activity, the monitoring of that
activity can lead form the basis of a worm defense.
 A classification scheme:
 Signature-based worm scan filtering: generates a
worm signature, which is then used to prevent
worm scans from entering/leaving a
network/host.
101
Worm Countermeasures
 Payload-classification-based worm containment:
examine packets to see if they contain a worm using
anomaly detection techniques
 Filter-based worm containment: focuses on worm
content rather than a scan signature. The filter
checks a message to determine if it contains worm
code.
 Threshold random walk (TRW) scan detection:
exploits randomness in picking destinations to
connect to as a way of detecting if a scanner is in
operation
102
Worm Countermeasures
 Rate limiting: limits the rate of scanlike traffic
from an infected host.
 Rate halting: immediately blocks outgoing
traffic when a threshold is exceeded either in
outgoing connection rate or diversity of
connection attempts.
 Rate halting can integrate with a signature- or
filter-based approach so that once a signature
or filter is generated, every blocked host can be
unblocked; as with rate limiting, rate halting
techniques are not suitable for slow, stealthy
worms.
103
Proactive Worm Containment
The Proactive Worm
Containment (PWC) scheme is
host based software that looks
for surges in the rate of
frequency of outgoing connection
attempts and the diversity of
connections to remote hosts.
When such a surge is detected,
the software immediately blocks
its host from further connection
attempts.
A deployed PWC system
consists of a PWC manager and
PWC agents in hosts.
104
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Proactive Worm Containment
 A PWC agent monitors
outgoing traffic for scan activity,
determined by a surge in UDP /
TCP connection attempts to
remote hosts.
If a surge is detected, the
agent:
1) issues an alert to local
system; 2) blocks all outgoing
connection attempts; 3)
transmits the alert to the
PWC manager; and 4) starts
a relaxation analysis.
105
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Proactive Worm Containment
A PWC manager receives an
alert, and propagates the alert to
all other agents.
The host receives an alert, and
must decide whether to ignore the
alert.
If the time since the last incoming
packet has been sufficiently long
so that the agent would have
detected a worm if infected, then
the alert is ignored.
106
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Proactive Worm Containment
Otherwise, the agent assumes
that it might be infected and
performs the following
actions:(1) blocks all
outgoing connection
attempts from the specific
alerting port;and (2) starts a
relaxation analysis.
Relaxation analysis. An agent
monitors outgoing activity for
a fixed window of time to
see if outgoing connections
exceed a threshold.
107
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Proactive Worm
Containment
If so, blockage is continued and
relaxation analysis is repeated
until the outgoing connection
rate drops below the
threshold, at which time the
agent removes the block.
If the threshold continues to be
exceeded over a sufficient
number of relaxation windows,
the agent isolates the host
and reports to the PWC
manager.
Meanwhile, a signature extractor
functions as a passive sensor
that monitors all traffic and
attempts to detect worms by
signature analysis.
108
“Computer Security: Principles and Practice”, 1/e, William Stallings & Lawrie Brown,
Network Based Worm Defense
The key element of a
network-based worm defense
is worm monitoring software.
Two types of monitoring
software are needed:
 Ingress monitors: located at
the border between the
enterprise network and the
Internet, in a border router,
external firewall, separate
passive monitor, or honeypot.
109
Network Based Worm Defense
Egress monitors: located at the
egress point of individual LANs
on the enterprise network as
well as at the external border, in
a LAN router or switch, external
firewall or honeypot.
The two types of monitors can
be collocated.
They are designed to catch the
source of a worm attack by
monitoring outgoing traffic for
signs of scanning etc.
110
Network Based Worm Defense
Worm monitors can act in the
manner of intrusion detection
systems and generate alerts to
a central administrative
system.
 It is also possible to
implement a system that
attempts to react in real time to
a worm attack, so as to counter
zero-day exploits effectively.
This is similar to the approach
taken with the digital immune
system
111
Network Based Worm Defense
This shows an example of a
worm countermeasure
architecture that works as
follows :
1. Sensors deployed at various
network locations detect a
potential worm.
2. Alerts are sent to a central
server that correlates /
analyzes incoming alerts.
3. Info is forwarded to a
protected environment, where
worm is sandboxed for analysis
112
Network Based Worm Defense
4. The protected system tests
the suspicious software against
an appropriately instrumented
version of the targeted
application to identify the
vulnerability.
5. The protected system
generates one or more software
patches and tests these.
6. The system sends the patch
to the application host to update
the targeted application.
113
Backdoors
Backdoors and Trapdoors
 What is a Backdoor?
 Once you penetrate the machine through one
of the ways we talked about previously, you
want to install a future access point
 A backdoor is a way in to the system that
allows an attacker admission whenever they
want
 What is a Trapdoor?
 Undocumented entry point to a module.
 Sometimes trapdoors are left unintentionally
from the development phase of a program.
 Obviously, a trapdoor is a backdoor (but not
necessarily conversely.)
115
Backdoors and Trojans
Backdoors and Trojans
 Trojans
 What are they?
 Trojan horse programs are programs that claim to
perform some desirable or necessary function but
also perform some function that the individual who
runs the program would not expect or want
 Classic example:
 Replace /bin/login - lets users log in to system but
saves passwords for later analysis
 Trojan Backdoor
 Combination of a backdoor hiding inside of a trojan
program
117
Backdoors and Trojans
 Trojan Backdoor
 Grouped several ways based on their method
of dissemination
 Application Level
 User mode Rootkit
 Kernel Level Rootkit
118
Backdoors and Trojans
 Application Level Trojan Backdoor
 Separate application runs on the system
giving attacker backdoor access
 Example programs
 Back Orifice 2000 (B02k) – we’ll investigate
later
 Sub7
 Hack-a-tack
 QAZ
 VCN
119
Backdoors and Trojans
 User Mode Rootkits
 Critical operating system components are
replaced or modified by the attacker to create
backdoors and hide on the system
 Example Programs
 Linux RootKit 5 (lrk5)
 T0rnKit for Linux, Solaris
 Other platform specific Rootkits for
 SunOS, AIX, SCO, Solaris
120
Backdoors and Trojans
 Kernel-level Root Kits
 The operating system itself is modified to
foster backdoor access and allow the attacker
to hide
 Example Programs
 Knark for Linux
 Adore for Linux
 Plasmoid’s Solaris Kernel-level Rootkit
 Windows NT Rootkit
121
Backdoors and Trojans
 List of RootKit Tools
 www.megasecurity.org
 List shows the names and default ports the
trojan’s use plus advice on using trojans
 Most popular consist of a small list
 Sub7 subseven.slak.org
 Back Orifice 2000 www.bo2k.com
 Hack-a-tack and VNC – both
Unix/Windows
 VNC can be found at
www.uk.resarch.att.com/vnc/
122
Setting the Stage for Next Example:
The Turing Award
 The A. M. Turing Award is given annually by the




Association for Computing Machinery to "an individual
selected for contributions of a technical nature made
to the computing community."
The contributions should be of "lasting and major
technical importance to the computer field".
It is recognized as the Nobel Prize of computing.
The award is named after Alan Turing, a British
mathematician who contributed to theoretical
computer science and artificial intelligence.
He was instrumental also in breaking the German's
Enigma Code during World War II.
123
Turing Award
 As of 2007, the award is accompanied by a prize
of $250,000, co-sponsored by Intel and Google.
 In 1983, Ken Thompson and Dennis M. Ritchie
shared the Turing Award for their development
of generic operating systems theory and
specifically for the implementation of the UNIX
operating system
124
Compiler with a Backdoor
 From Ken Thompson’s Turing Award lecture in
1983:
 A compiler can be designed to recognize the
moment it does the compilation of “login” and
install an uninvited backdoor to the program.
 The source of login would be perfectly clean but
the compiled executable will have a trapdoor.
 Recognizing this you may want to examine and
edit the source code of the compiler itself to
remove the backdoor modifying compilation.
 But the compiler could have been compiled from
the beginning to detect when it is to compile a
version of itself and despite the source
modification would still compile a backdoor
producing compiler!!
125
 • As Thompson put it: “You can't trust
code that you did not totally create
yourself (Especially code from
companies that employ people
like me.)”
126
Trojan Horses
Trojan Horses
 A Trojan horse is a program with an overt
(documented or known) effect and a covert
(undocumented or unexpected) effect.
 This term was named by Dan Edwards in the
Anderson Report (J. Anderson, “Computer Security
Technology Planning Study,” Technical Report ESDTR-73-51, Electronic Systems Division, Hanscom Air
Force Base, Hanscom, MA, 1974).
128
EXAMPLE: NetBus program
 Allows an attacker to control a Windows NT




workstation remotely.
The program acts as a server, accepting and
executing commands for a remote administrator:
Includes intercepting keystrokes and mouse
motions and sending them to the attacker.
Also allows the attacker to upload, download
files.
Would work if the victim NT system has a server
with which the NetBus program can
communicate.
129
Trojan Horses
 A Trojan horse (propagating Trojan horse or a
replicating Trojan horse) can make copies of
itself.
 One of the earliest Trojan horses was a version
of a game named Animal.
 When the game was played, it created an extra
copy of itself.
 The program was modified to delete one copy of
the earlier version and create two copies of the
modified program.
130
 As the modified version spread more rapidly




than the earlier version, it completely supplanted
the earlier version.
After a preset date, each copy of the modified
version deleted itself after it was played.
Karger and Schell, and later Thompson
examined detection of Trojan horses.
They constructed a Trojan horse that
propagated itself slowly and in a manner that
was difficult to detect.
Recall the central idea: The Trojan horse
modifies the compiler to insert itself into specific
programs, including later versions of the
compiler.
131
Viruses and Trojan Horses
 Authorities differ on whether or not a computer
virus is a type of Trojan horse.
 Some argue that the answer is YES.
 Overt action = infected program’s actions
 Covert action = virus’ actions (infect, execute)
 Some argue that the answer is NO.
 Overt purpose = virus’ actions (infect,
execute)
 Covert purpose = none
132
 In some sense, this disagreement is semantic.
 In any case, defenses against a Trojan horse
inhibit computer viruses.
133
Bots
What is a Bot?
 A bot is a program which can take over other
computers to launch hard to trace attacks
 If the attacks are coordinated, they form a botnet
 Characteristics:
 Remote control facility
 Via IRC/HTTP etc, for example
 Spreading mechanism
 Attack software, vulnerability, scanning
strategy
 Various counter-measures applicable
135
Bots
 Some uses of bots include:






Distributed denial-of-service attacks,
Spamming,
Sniffing traffic,
Keylogging,
Spreading new malware,
Installing advertisement add-ons and browser
helper objects (bhos),
 Attacking irc chat networks,
 Manipulating online polls/games.
136
Bots
 The remote control facility is what distinguishes a bot
from a worm.
 A typical means of implementing the remote control
facility is on an IRC (Internet relay chat) server.
 More recent botnets tend to avoid IRC mechanisms
and use covert communication channels via
protocols such as HTTP.
 Once a communications path is established between
a control module and the bots, the control module
can activate the bots, and even issue update
commands that download a file from some Internet
location and execute it.
137
Bots
 The first step in a botnet attack is for the attacker
to infect a number of machines with bot software
that will ultimately be used to carry out the
attack.
 The essential ingredients in this phase of the
attack are:
 Software that can carry out the attack;
 A vulnerability in a large number of systems
 A strategy for locating vulnerable machines, a
process known as port scanning.
 We will discuss port scanning in more detail later
and see some tools for doing it.
138
Rootkits
Viral and Worm Payloads
 What can a virus or worm do?
 There are so many options... but one is really
the one with the largest payoff to an attacker:
 Enable the installation of a ROOTKIT
 What is a rootkit?
 Set of tools that are cloaked and (possibly)
enable remote administration.
 (In)famous example: Back Orifice 2000
(BO2k) - Advertised as a “remote system
administration tool”
140
Back Orifice - B02k
 What does it do?
 Has a lot of capabilities like PCanywhere or






ControlIT to allow remote administration
Can be used by both good and bad hackers
Can run hidden or undetected
Supports encryption between attacker and victim
machine
Can run on any TCP or UDP port (We'll look at
ports shortly).
Used to run on 31337 as default port
Made it easy to detect – so authors changed
that
141
Remote Administration – What is Allowed?
 Automatic notification of an IP address.
 Remote windows registry editing.
 Watch the desktop remotely (streaming
video).
 Key-logging.
 Rebooting
 BO2k: a 100Kb base server installation so its
size doesn't raise flags.
142
Rootkits
 A rootkit is a set of programs installed on a system to
maintain administrator (or root) access to all the
functions and services of the operating system.
 The rootkit alters the host's standard functionality in a
malicious and stealthy way.
 A rootkit can make many changes to a system to hide
its existence, making it difficult for the user to
determine that the rootkit is present and to identify
what changes have been made.
 This is done by subverting the mechanisms that
typically report on processes, files, and registries.
143
BigCorp Hacks Your Computer?
 A major music entertainment company (Sony)
was distributing with its cd’s a rootkit that was
cloaked and allowed communication with Sony's
servers.
 After the discovery, they admitted the rootkit
and offered a way to remove the cloaking (but
not the functionality).
 Conventional removal would disable the CD
playing functionality of windows.
144
Classification of Rootkits
 Persistent: Activates each time the system boots.
The rootkit must store code in a persistent store,
such as the registry or file system, and configure a
method by which the code executes without user
intervention.
 Memory-based: Has no persistent code and
therefore cannot survive a reboot.
 User-mode: Intercepts calls to APIs (Application
Program Interfaces) and modifies returned results.
 Kernel-mode: Can intercept calls to native APIs in
kernel mode; may hide the malware process by
removing it from the kernel's list of active processes.
145
Rootkits
 Rootkits do not directly rely on vulnerabilities or





exploits to get on a computer.
One method of rootkit installation is via a Trojan
horse program, run by a user.
Another means of rootkit installation is by hacker
activity.
Countering rootkits requires a variety of network- and
computer-level security tools.
Both net and host-base IDSs can look for the code
signatures of known rootkit attacks in incoming traffic.
Host-based antivirus software can also be used to
recognize the known signatures. Another approach is
to do some sort of file integrity check.
146
Rootkits
 Programs operating at the user level interact with the




kernel through system calls.
Thus, system calls are a primary target of kernellevel rootkits to achieve concealment. As an example
of how rootkits operate, we look at the
implementation of system calls in Linux.
In Linux, each system call is assigned a unique
syscall number.
When a user-mode process executes a system call,
the process refers to the system call by this number.
The kernel maintains a system call table with one
entry per system call routine; each entry contains a
pointer to the corresponding routine..
147
Rootkits
 The syscall number serves as an index into the
system call table.
 There are three techniques that can be used to
change system calls:
 Modify the system call table:
 The attacker modifies selected syscall addresses
stored in the system call table.
 This enables the rootkit to direct a system call
away from the legitimate routine to the rootkit's
replacement.
 The next slide shows how the knark rootkit
achieves this.
148
Rootkit System Table Mods
149
Rootkits
 Modify system call table targets: The attacker
overwrites selected legitimate system call routines
with malicious code. The system call table is not
changed.
 Redirect the system call table: The attacker redirects
references to the entire system call table to a new
table in a new kernel memory location.
 If a kernel-level rootkit is detected, by any means, the
only secure and reliable way to recover is to do an
entire new OS install on the infected machine.
150
Rootkits
 User Mode or Traditional Rootkits
 Don’t add applications but replace
existing system components with Trojan
versions
 These Rootkits have existed since 1990’s
 What do they do?
 Don’t give you root privilege, should
already be root
 Allows attacker to maintain root access
and hide their presence on machine
151
151
Rootkits
 User Mode
 At a minimum
 1) Install backdoor for attacker
 2) Hide evidence of system compromise
 Extra
 Collect information via sniffer for attacker
 Ex: Useful traffic such as passwords,
other information
152
152
Rootkits
 User Mode Rootkits
 For example ... replace system programs
 Replace ssh or other login programs with
one containing backdoor password for root
access
 Replace ifconfig program so it hides
presence of interface running in
promiscuous mode
 Putting network card into promiscuous
mode is done by most sniffer programs
 System administrator can become
suspicious to an attacker’s sniffer
153
153
Rootkits
Program
Replaced
Original
Function
Rootkit
Version
du
Disk utilization
find
Lies about disk space
Hides attackers tool space
Lies about attackers files
Finds files and
directories
Shows interface status Masks promiscuous mode
Lets users login to
Login but also a backdoor
system
root level password
Contents of a directory Lies about rootkit files
Show processes listening Lies about which ports used
on TCP/UDP ports
by attacker
Process list
Lies about processes attacker
wants to hide
ifconfig
login
ls
netstat
ps
Above list shows typically replaced programs
154
154
Rootkits
 User Mode Rootkits
 Where can we get one for Unix/Linux?
 www.packetstormsecurity.org/UNIX/penetrati
on/rootkits
 Try Googling for the following:
 lrk6 – Linux Rootkit 6
 shv4 – another popular Linux rootkit
Windows
But, two sites went inactive since I obtained
links for them this summer.
155
155
Rootkits
 User Mode Rootkits
 For example, the real rootkit, lrk5 written by
Lord Somer includes the following files:
chfn
ifconfig
netstat
syslogd
chsh
inetd
passwd
tcpd
crontab killall
pidof
top
du
login
ps
sshd
find
ls
rshd
su
See the gory details at
http://www.ossec.net/rootkits/studies/lrk5.txt 156
156
Rootkits
 Kernel Rootkit
 More devious or harder to detect
 Modify the kernel to completely and
transparently transform the system to
attacker’s needs
 If you can’t trust the kernel, you can’t trust
anything on your system!
 What a kernel rootkit does
 It redirects the system calls made by other
programs
157
157
Rootkits
 Kernel rootkit
 Example
 You want to login to the system, so a call is
made that says to run /bin/login
 Kernel maps the request to a hidden
program /bin/backdoorlogin
 Contains a backdoor whenever it is run
that allows access for root
 When you run your file integrity checker on
/bin/login
 It passes
158
158
Rootkits
 Kernel Rootkit
 Everything on your system looks pretty
good but isn’t
 All execution is potentially altered
 Your system is a total lie!
 In addition to execution redirection kernel
rooted machine hides processes that run
and their associated files
159
159
Rootkit
 Kernel Rootkits
 Example of hidden processes
 A process is listening to port 31337
 You do a netstat to see what ports are
open
 It will lie and hide that the port is open
 What do you do?
 Perform a scan of your system with
nmap from the network
 Would see the open 31337 port
160
160
Rootkits
 Creating a Kernel rootkit
 Easiest approach
 Use a LKM – Loadable Kernel Module
 These are used legitimately for dynamically
updating system functionality
 Example
 Support for new disk drive
 Can either rebuild the kernel to
support new capability or
 Dynamically update the kernel with a
loadable kernel module
161
161
Rootkits
 Kernel Mode rootkits:
 Linux
 Adore-ng for linux running kernels 2.4. 2.5
2.6
 Runs as a loadable kernel module
 Full featured including module hiding
 Windows
 FU
 Name comes from su command in Unix for
changing user names
162
162
Rootkits
 Kernel Mode Rootkits
 Can write your own ....
See:
Rootkits: Subverting the Window Kernel
by Greg Hoglund and JamieButler
163
163
Defenses Against Rootkits
Periodically do a file integrity check
 Create a MD5 hash function on files
 Create a DB of hashes for critical system
files
 Also can check against a known DB of file
hashes, 36,645,143 files are onfile
www.nsrl.nist.gov
 Store offline and periodically check your
files against hashes for changes
 Tripwire is the original file integrity checker164
from Purdue
164
Rootkits
 Defenses Against Rootkits
1. Don’t let them get root in the first place
 Install patches, close down services
2. Disable loadable modules in Linux
 This functionality is not needed for critical
systems like servers
165
165
Rootkits
 Detection
 User Mode Rootkits
 Strings command will work on any file
 Use it on a suspected executable to try and
see what the executable is doing.
166
166
The Linux command string Outputs All
Strings in a File (ex4 is the Executable File
for ex4.c in the Lab Exercises)
167
Rootkits
 Might suspect a compromised executable
/usr/src/.puta/.1file
 Using strings you see "ls" in the file and suspect
it is compromised.
 You try to see if ls is compromised:
$ cd /usr/src
$ ls –a
. .. linux linux-2.2.14 redhat
As expected since ls is compromised, .puta
doesn’t show up when the directory is
listed.
168
168
Rootkits
 Example continued
Use the following commands to show .puta
$ echo .* *
. .. .puta linux linux-2.2.14 redhat
$ cat .puta/.1file
.puta
.t0rn
.1proc
.1addr
169
169
Process Commands
 ps stands for Process status
 Shows the status of all running processes
 Gives you the pid – process identification
number
 Then, can use this in later commands to
suspend or kill the process
 Common form of the command for Linux and
BSD systems:
 -a = all processes on system
 -u = processes attached to users
 -x = all processes even those not
associated with a terminal like system
processes
170
170
Process Commands
 Lsof – list open files
 This will list the open files associated with a
user, a tcp port or a number of other
possibilities
 A ton of options with this command
 Can only see open files of processes that
you own unless you run it as root
 Example
lsof –i | less
Lists all the processes with active
network ports
171
171
/proc file system
 All running processes get their information from the
kernel
 If the kernel has been compromised, all the tools may fail
 Modern Unix systems make some process and system
information available via the /proc pseudo file system
 Each process has a /proc/pid
 Under each /proc/pid are files that describe process
attributes
172
172
/proc file system
 All running processes get their information from the
kernel
 If the kernel has been compromised, all the tools may fail
 Modern Unix systems make some process and system
information available via the /proc pseudo file system
 Each process has a /proc/pid
 Under each /proc/pid are files that describe process
attributes
173
173
/proc file system
 On Linux and FreeBSD systems
 /proc files are mostly text and can be accessed with
cat or echo commands
 Solaris
 /proc is binary and need special utilities
------------------------------------------------------------- One way to use /proc is to compare output from ps and
/proc/pid list
ps –aux > file.list
ls –d /proc/[1-9]*> file.proc
Looking for PID’s that appear in /proc but not in ps
May have been hidden
174
174
Detection of Rootkits
 Useful to compare ps vs. /proc info to identify rootkits
 Example of ps vs. /proc
Entries in /proc
1
2
3
4
5
6
153
271
341
Output from “ps ax”
1? S
0:06
3
4
5
6
0:00
0:00
0:00
0:00
?
?
?
?
SW
SW
SW
SW
init [3]
(kupdate)
(kupiod)
(kupiod)
(mdrecoveryd)
271 ? S
0:00 /sbin/pump –i eth0
341 ? S 0:00 portmap
175
175
Detection of Rootkits
 Process 153 is suspicious
 Do a netstat and it does not show up
# netstat –an
shows all active TCP connections
 However, maybe attackers were not so
thorough ...
# lsof –p 153
Command PID User FD Type
nscd
153 root cwd DIR
nscd
153 root rtd
DIR
nscd
153 root txt
REG
/usr/sbin/nscd
...
nscd
153 root 7u
IPV4
Device Size Node Name
3,5
4096
2
/
3,5
4096
2
/
3,5 201552
2
177
176
176
TCP*:47017 (LISTEN)
Detection of Rootkits
 Process 153 continued
 For some reason didn’t replace lsof
 /usr/sbin/nscd suggests it is a system program
 But, is not supposed to be present in this version of
Linux
 Telnet to port 47017 confirms it is a back door
process
 Looks like an ssh server
# telnet localhost 47017
Trying 127.0.0.1 ...
Connected to rh62.
Escape character is ‘^]’.
SSH-1.5-1.2.27
177
177
Rootkits
 Kernel Mode Rootkits – Finding them
 If entire system is a lie, how do you find them?
 If you scan your network with nmap
 Shows you ports open on your system
 Good idea to occasionally scan your own networks
 If you run a sniffer and ifconfig doesn’t show
promiscuous mode, may be a problem
178
178
Rootkits
 Sniffer puts the network card into “promiscuous” mode
 Can see this if you run the ifconfig command
 Rootkits thus replace the ifconfig command with a
trojan version or subvert the ifconfig call if kernel level
rootkit
-------------------------------------------------------------------------Below is what ifconfig should show if sniffer is running:
eth0 Link encap:Ethernet HWaddr 01:23:45:67:89:ab inet
addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 UP
BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:23515 errors:0 dropped:0 overruns:0 frame:0 TX
packets:9839 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 RX
bytes:3778586 (3.6 Mb) TX bytes:1569537 (1.4 Mb)
179
179






Rootkits - Detection
Automated tool, chkrootkit program, free, Unix/Linux
Available from: ftp.pangeia.com.br/pub/seg/pac
Searches for fingerprinting of user mode rootkits
It is a shell script that checks the system for binaries
for rootkit modification
Plus has the ability to detect well-known LKM rootkits.
Using the following commands chkrootkit searches for
common files rootkits place on the system
 Awk, cut, echo, egrep, find, head, id, ls, netstat, ps,
strings, sed, and uname.
Also, searches for hidden processes by comparing
contents of /proc directory with results from ps
command
180
180
Backdoors and Rootkits
 Kernel Level Rootkits
 Detection
 Rootkit Hunder
www.rootkit.nl/projects/rootkit_hunter.ht
ml
 Similar to chkrootkit
 Use it for second opinion
 For Windows rootkits
 Rootkit Revealer www.sysinternals.com
 Blacklight www.f-secure.com/blacklight 181
181
Rootkits
 Kernel Level Rootkits
 Detection
 Host based IDS’s can also check for
rootkits
 Virus scanners have signatures now of
many rootkits
 Skilled attackers can bypass this by
disabling virus scanner, then installing
rootkit
 Still effective for less skilled attacks
182
182
Rootkits - Cleanup
 After the initial attack a system may never be
the same.
 A complete clean up and system recovery
should be performed to prevent future attacks.
 It must be assumed that all information on the
system during the time of the attack has been
exposed.
 Locating all Trojan versions of standard system
can be difficult.
183
183
 A system administrator should not trust
any system utilities until they have been
restored from a safe source such as
distribution media.
 Unless you are positive that back ups
were made before the security breach,
backups should not be used.
184
Logic Bombs
Logic Bombs
 Some malicious logic triggers on an external event,




such as a user logging in or the arrival of midnight,
Friday the 13th.
A logic bomb is a program that performs an action that
violates the security policy when some external event
occurs.
– EXAMPLE:
Disaffected employees who plant Trojan horses in
systems use logic bombs.
A program that deletes company’s payroll records
when one particular record is deleted.
186
 The particular record is usually that of the person writing the






logic bomb.
The idea is if (when) he or she is fired, and the payroll record
deleted, the company loses all those records.
In the early 1980’s, a program posted to the USENET news
network promised to make administering systems easier.
The directions stated that the shar archive containing the
program had to be unpacked, and the program complied and
installed, as root.
Midway down the shar archive were the lines cd / and rm –rf *.
Anyone who followed the instructions caused the lines to be
executed.
These commands deleted all files in the system.
187
Recent Trends
 Mobile attacks using SMS (SMiShing), whereby malware such






as MSIL/Xrove infects smartphones via ActiveSync.
Media malware using MPEG video files or CODECs for MP3
audio players. Thanks to the popularity of video sharing sites
like YouTube, this mode of attack is expected to grow.
Increase in zombie computers and botnets.
Return of parasitic malware, which operate by modifying files
already existent on your hard drive.
Increased silent and targeted attacks on transactions instead
of computers.
Suicidal malware that uses polymorphic techniques to evade
detection.
Ransomware. A new threat, called ransomware, is where
malware authors hold computers hostage unless an infected
machine’s owner pays a certain amount.
188
References
 Some material is from
 Lecture slides prepared by Dr Lawrie Brown for
“Computer Security: Principles and Practice”, 1/e, by
William Stallings and Lawrie Brown, Chapter 7
“Malicious Software”.
• Morris Worm Details from slides for CSE281 - Computer
Security (Spring 2008) University of Connecticut ©20068 Aggelos Kiayias
• Code Red Worm Details from slides for CSE281 Computer Security (Spring 2008) University of
Connecticut ©2006-8 Aggelos Kiayias
189