0% found this document useful (0 votes)
56 views91 pages

Lecture6 Software Flaws

Uploaded by

asmm.rahaman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
56 views91 pages

Lecture6 Software Flaws

Uploaded by

asmm.rahaman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 91

SOFTWARE FLAWS

Part 4  Software 1
Why Software?
 Why is software as important to security as crypto, access
control, protocols?
 Virtually all information security features are implemented
in software
 If your software is subject to attack, your security can be
broken
o Regardless of strength of crypto, access control, or protocols
 Software is a poor foundation for security

Part 4  Software 2
Bad Software is Ubiquitous
 NASA Mars Lander (cost $165 million)
o Crashed into Mars due to…
o …error in converting English and metric units of measure
o Believe it or not
 Denver airport
o Baggage handling system  very buggy software
o Delayed airport opening by 11 months
o Cost of delay exceeded $1 million/day

 MV-22 Osprey
o Advanced military aircraft
o Faulty software can be fatal

Part 4  Software 3
Software Issues

Alice and Bob (Normal Trudy


User)  Actively looks for
 Find bugs and flaws bugs and flaws
by accident  Likes bad software…
 Hate bad software…
 …and tries to make
 …but they learn to it misbehave
live with it  Attacks systems via
bad software

Part 4  Software 4
Complexity
 “Complexity is the enemy of security”, Paul
Kocher, Cryptography Research, Inc.

System Lines of Code (LOC)


Netscape 17 million
Space Shuttle 10 million
Linux kernel 2.6.0 5 million
Windows XP 40 million
Mac OS X 10.4 86 million
Boeing 777 7 million
 A new car contains more LOC than was required
to land the Apollo astronauts on the moon
Part 4  Software 5
Lines of Code and Bugs
 Conservative estimate: 5 bugs/10,000 LOC
 Do the math
o Typical computer: 3k exe’s of 100k LOC each
o Conservative estimate: 50 bugs/exe
o Implies about 150k bugs per computer
o So, 30,000-node network has 4.5 billion bugs
o Maybe only 10% of bugs security-critical and only 10% of those
remotely exploitable
o Then “only” 45 million critical security flaws!

Part 4  Software 6
Software Security Topics
 Program flaws (unintentional)
o Buffer overflow
o Incomplete mediation
o Race conditions
 Malicious software (intentional)
o Viruses
o Worms
o Other breeds of malware

Part 4  Software 7
Program Flaws
 An error is a programming mistake
o To err is human
 An error may lead to incorrect state: fault
o A fault is internal to the program
 A fault may lead to a failure, where a system departs from
its expected behavior
o A failure is externally observable

error fault failure

Part 4  Software 8
Example
char array[10];
for(i = 0; i < 10; ++i)
array[i] = `A`;
array[10] = `B`;
 This program has an error
 This error might cause a fault
o Incorrect internal state
 If a fault occurs, it might lead to a failure
o Program behaves incorrectly (external)
 We use the term flaw for all of the above
Part 4  Software 9
Secure Software
 In software engineering, try to ensure that a program
does what is intended
 Secure software engineering requires that software does
what is intended…
 …and nothing more
 Absolutely secure software? Dream on…
o Absolute security anywhere is impossible
 How can we manage software risks?

Part 4  Software 10
Program Flaws
 Program flaws are unintentional
o But can still create security risks
 We’ll consider 3 types of flaws
o Buffer overflow (smashing the stack)
o Incomplete mediation
o Race conditions
 These are the most common flaws

Part 4  Software 11
Buffer Overflow

Part 4  Software 12
Attack Scenario
 Users enter data into a Web form
 Web form is sent to server
 Server writes data to array called buffer, without checking
length of input data
 Data “overflows” buffer
o Such overflow might enable an attack
o If so, attack could be carried out by anyone with Internet access

Part 4  Software 13
Buffer Overflow
int main(){
int buffer[10];
buffer[20] = 37;}

 Q: What happens when code is executed?


 A: Depending on what resides in memory
at location “buffer[20]”
o Might overwrite user data or code
o Might overwrite system data or code
o Or program could work just fine

Part 4  Software 14
Simple Buffer Overflow
 Consider boolean flag for authentication
 Buffer overflow could overwrite flag
allowing anyone to authenticate
Boolean flag
buffer
F OU R S C … T
F

 In some cases, Trudy need not be so lucky


as in this example
Part 4  Software 15
Overview of Memory Organization
¬ low
 Text  code text address
 Data  static variables data
 Heap  dynamic data
heap
 Stack  “scratch paper” 
¬ stack
o Dynamic local variables pointer (SP)
o Parameters to functions 
stack ¬ high
o Return address
address

Part 4  Software 16
Simplified Stack Example
(Let func is called)
low 

void func(int a, int b){ :


char buffer[10];
:
}
void main(){
func(1,2); ¬ SP
buffer
}
¬ return
SP
ret address
a ¬ SP

high  b ¬ SP

Part 4  Software 17
Smashing the Stack
low 

 What happens if :
??? :
buffer overflows?
 Program “returns” ¬ SP
to wrong location buffer
overflow
ret ¬ ret…
SP NOT!
A crash is likely
overflow
a ¬ SP

high  b ¬ SP

Part 4  Software 18
Smashing the Stack
low 
 Trudy has a
:
better idea… :
 Code injection
 Trudy can run ¬ SP
code of her evil code

choosing… ret
ret ¬ SP
a ¬ SP
o …on your machine
high  b ¬ SP

Part 4  Software 19
Smashing the Stack
:
:
 Trudy may not know… NOP
1) Address of evil code :
2) Location of ret on stack NOP

 Solutions evil code

1) Precede evil code with ret


¬ ret
NOP “landing pad” ret
:
2) Insert ret many times
ret
:
Part 4  Software 20 :
Stack Smashing Summary
 A buffer overflow must exist in the code
 Not all buffer overflows are exploitable
o Things must align properly
 If exploitable, attacker can inject code
 Trial and error is likely required
o Fear not, lots of help is available online
o Smashing the Stack for Fun and Profit, Aleph One
 Stack smashing is “attack of the decade”…
o …for many recent decades
o Also heap & integer overflows, format strings, etc.

Part 4  Software 21
Stack Smashing Example
 Suppose program asks for a serial number
that Trudy does not know
 Also, Trudy does not have source code
 Trudy only has the executable (exe)

 Program quits on incorrect serial number


Part 4  Software 22
Buffer Overflow Present?
 By trial and error, Trudy discovers
apparent buffer overflow

 Note that 0x41 is ASCII for “A”


 Looks like ret overwritten by 2 bytes!
Part 4  Software 23
Disassemble Code
 Next, disassemble bo.exe to find

 The goal is to exploit buffer overflow


to jump to address 0x401034
Part 4  Software 24
Buffer Overflow Attack
 Find that, in ASCII, 0x401034 is “@^P4”

 Byte order is reversed? What the … ?


 X86 processors are “little-endian”
Part 4  Software 25
Overflow Attack, Take 2
 Reverse the byte order to “4^P@” and…

 Success! We’ve bypassed serial number


check by exploiting a buffer overflow
 What just happened?
o Overwrote return address on the stack

Part 4  Software 26
Buffer Overflow
 Trudy did not require access to the source code
 Only tool used was a disassembler to determine
address to jump to
 Find desired address by trial and error?
o Necessary if attacker does not have exe
o For example, a remote attack

Part 4  Software 27
Source Code
 Source code for buffer overflow example
 Flaw easily
exploited by
attacker…
 …without
access to
source code!

Part 4  Software 28
Stack Smashing Defenses
 Employ non-executable stack
o “No execute” NX bit (if available)
o Seems like the logical thing to do, but some real code executes on the stack
(Java, for example)
 Use safe programming languages (Java, C#)
o At runtime, they automatically check memory that all memory accesses are
within the declared memory bound.
o Use safe C function (use strncpy instead of strcpy)
 Use a canary
o Runtime stack checking can be used to preventing stack smashing attacks.
o In this approach, when the return address is popped off of the stack, it’s checked to
verify that it hasn’t changed.
o This can be accomplished by pushing a special value onto the stack immediately after
the return address.
o Then, in order to overwrite the return address, this special value must first be
overwritten. This special value is usually referred to as a “canary,”

Part 4  Software 29
Stack Smashing Defenses
low 
:
 Canary :
o Run-time stack check
o Push canary onto stack
o Canary value: buffer
 Constant 0x000aff0d overflow
canary ¬

 Or, may depends on ret overflow


ret
a
high  b
Part 4  Software 30
Microsoft’s Canary
 Microsoft added buffer security check feature to C++
with /GS compiler flag
o Based on canary (or “security cookie”)
Q: What to do when canary dies?
A: Check for user-supplied “handler”
 Handler shown to be subject to attack
o Claimed that attacker can specify handler code
o If so, formerly “safe” buffer overflows become exploitable
when /GS is used!

Part 4  Software 31
Buffer Overflow (Conclusion)
 A major security threat yesterday, today, and tomorrow
 The good news?
o It is possible to reduce overflow attacks (safe languages, NX
etc.)
 The bad news?
o Buffer overflows will exist for a long time
o Why? Legacy code, bad development practices, clever attacks,
etc.

Part 4  Software 32
Incomplete Mediation

Part 4  Software 33
Input Validation
 Consider: strcpy(buffer, argv[1])
 A buffer overflow occurs if
len(buffer) < len(argv[1])
 Software must validate the input by checking the length
of argv[1]
 Failure to do so is an example of a more general problem:
incomplete mediation

Part 4  Software 34
Input Validation
 Consider data that is input to a Web form. Such data is
often transferred to the server by including it in a URL
 Suppose input is validated on client
 For example, the following is valid
http://www.things.com/orders/
final&custID=112&num=55A&qty=20&price=10&shipping=5&total=205
 Suppose input is not checked on server
o Why bother since input checked on client?
o Then attacker could send http message
http://www.things.com/orders/
final&custID=112&num=55A&qty=20&price=10&shipping=5&total=25

Part 4  Software 35
Incomplete Mediation
 Linux kernel
o Research revealed many buffer overflows
o Lots of these due to incomplete mediation
 Linux kernel is “good” software since
o Open-source
o Kernel  written by coding gurus
 Tools exist to help find such problems
o But incomplete mediation errors can be subtle
o And tools useful for attackers too!

Part 4  Software 36
Race Conditions

Part 4  Software 37
Race Condition
 Security processes should be atomic
o Occur “all at once”
 Race conditions can arise when security-critical process
occurs in stages
 Attacker makes change between stages
o Often, between stage that gives authorization, but before stage
that transfers ownership
 Example: Unix mkdir

Part 4  Software 38
mkdir Race Condition

 mkdircreates new directory


 How mkdir is supposed to work

mkdir
1. Allocate
space
2. Transfer
ownership

Part 4  Software 39
mkdir Attack
 The mkdir race condition
mkdir
1. Allocate
space
3. Transfer
ownership

2. Create link to
password file

 Not really a “race”


o But attacker’s timing is critical
Part 4  Software 40
Race Conditions
 Race conditions are common
 Race conditions may be more prevalent than buffer
overflows
 But race conditions harder to exploit
o Buffer overflow is “low hanging fruit” today
 To prevent race conditions, make security-critical processes
atomic
o Occur all at once, not in stages
o Not always easy to accomplish in practice
Part 4  Software 41
Malware

Part 4  Software 42
Malicious Software
 Malware is not new…
o Fred Cohen’s seminal virus work in 1980’s
 Types of malware (no standard definition)
o Virus  passive propagation
o Worm  active propagation
o Trojan horse  unexpected functionality
o Trapdoor/backdoor  unauthorized access
o Rabbit  exhaust system resources
o Spyware  steals info, such as passwords
o Botnets  malware for hire
o Ransomware  Use malware to encrypt data

Part 4  Software 43
Where do Viruses Live?
 They live just about anywhere, such as…
 Boot sector
o Take control before anything else
 Memory resident
o Stays in memory
 Applications, macros, data, etc.
 Library routines
 Compilers, debuggers, virus checker, etc.
o These would be particularly nasty!

Part 4  Software 44
Malware Timeline
 Brain virus (1986)
 Morris worm (1988)
 Code Red (2001)
 SQL Slammer (2004)
 Botnets
 Stuxnet (2010)
 Ransomware
 Future of malware?

Part 4  Software 45
Brain
q First appeared in 1986
q More annoying than harmful
q A prototype for later viruses
q Not much reaction by users
q What it did
1. Placed itself in boot sector (and other places)
2. Screened disk calls to avoid detection and maintained its
infections
3. Each disk read, checked boot sector to see if boot sector
infected; if not, then reinstall in the boot sector
q Brain did nothing really malicious
Part 4  Software 46
Morris Worm
 Appeared in 1988
 Designed to do three things-
o Determine where it could spread its infection,
o spread its infection when infection and…
o remain undiscovered
 Morris claimed his worm had a bug!
o It tried to re-infect infected systems
o Led to resource exhaustion
o Effect was like a so-called rabbit
Part 4  Software 47
How Morris Worm Spread

 Obtained access to machines by…


o User account password guessing
o Exploit buffer overflow in fingerd (Unix finder utility)
o Exploit trapdoor in sendmail

Part 4  Software 48
Bootstrap Loader
 Once Morris worm got access…
o “Bootstrap loader” sent to victim
 99 lines of C code
o Victim compiled and executed code
o Bootstrap loader fetched the worm
o Victim authenticated sender
 Don’t want user to get a bad worm…

Part 4  Software 49
How to Remain Undetected?
 If transmission interrupted, all of the codes had
been transmitted was deleted
 Code encrypted when downloaded
 Code deleted after decrypt/compile
 When running, worm regularly changed name and
process identifier (PID)

Part 4  Software 50
Code Red Worm
 Appeared in July 2001
 Infected more than 250,000 systems in about
15 hours
 Eventually infected 750,000 out of about
60,00,000 vulnerable systems
 Exploited buffer overflow in Microsoft IIS
server software
o Then monitor traffic on port 80, looking for other
susceptible servers
Part 4  Software 51
Code Red: What it Did
 Day 1 to 19 of month: spread its infection
 Day 20 to 27: distributed denial of service attack (DDoS)
on www.whitehouse.gov
 Later version (several variants)
o Included trapdoor for remote access
o Rebooted to flush all traces of the worm, leaving only trapdoor

Part 4  Software 52
SQL Slammer
 Infected 75,000 systems in 10
minutes!
 At its peak, infections doubled
every 8.5 seconds
 Spread “too fast”…
 …so it “burned out” available
bandwidth

Part 4  Software 53
Why was Slammer Successful?
 Worm size: one 376-byte UDP packet
 Firewalls often let one packet thru
o Then monitor ongoing “connections”
 Expectation was that much more data
required for an attack
o So no need to worry about 1 small packet

Part 4  Software 54
Stuxnet
 Worm that was originally aimed at Iran’s nuclear facilities and has
since mutated and spread to other industrial and energy-producing
facilities.
 The original Stuxnet malware attack targeted the programmable
logic controllers (PLCs) used to automate machine processes.
 It is capable of crippling hardware and because it appeared to have
been created by the U.S. National Security Agency, the CIA, and
Israeli intelligence.

Part 4  Software 55
What did the Stuxnet worm do?
 Stuxnet reportedly destroyed numerous centrifuges in Iran’s Natanz
uranium enrichment facility by causing them to burn themselves out.
 Over time, other groups modified the virus to target facilities including
water treatment plants, power plants, and gas lines.
 Stuxnet was a multi-part worm that traveled on USB sticks and spread
through Microsoft Windows computers.

Part 4  Software 56
Malware Related to Stuxnet
 Duqu (2011). Based on Stuxnet code, Duqu was designed to log
keystrokes and mine data from industrial facilities, presumably to
launch a later attack.
 Flame (2012). Flame, like Stuxnet, traveled via USB stick.
o Flame was sophisticated spyware that recorded Skype conversations, logged

keystrokes, and gathered screenshots, among other activities.


o It targeted government and educational organizations and some private

individuals mostly in Iran and other Middle Eastern countries.

Part 4  Software 57
Malware Related to Stuxnet
 Havex (2013). The intention of Havex was to gather information from energy, aviation, defense, and
pharmaceutical companies, among others. Havex malware targeted mainly U.S., European, and
Canadian organizations.
 Industroyer (2016). This targeted power facilities. It’s credited with causing a power outage in the
Ukraine in December 2016.
 Triton (2017). This targeted the safety systems of a petrochemical plant in the Middle East, raising
concerns about the malware maker’s intent to cause physical injury to workers.
 Most recent (2018). An unnamed virus with characteristics of Stuxnet reportedly struck unspecified
network infrastructure in Iran in October 2018.

Part 4  Software 58
Trojan Horse Example
 Trojan: unexpected functionality
 Prototype trojan for the Mac
 File icon for freeMusic.mp3:
 For a real mp3, double click on icon
o iTunes opens
o Music in mp3 file plays
 But for freeMusic.mp3, unexpected results…

Part 4  Software 59
Mac Trojan
 Double click on freeMusic.mp3
o iTunes opens (expected)
o “Wild Laugh” (not expected)
o Message box (not expected)

Part 4  Software 60
Trojan Example
 How does freeMusic.mp3 trojan work?
 This “mp3” is an application, not data

 This trojan is harmless, but…


 …could have done anything user could do
o Delete files, download files, launch apps, etc.
Part 4  Software 61
Botnet
 Botnet: a “network” of infected machines
 Infected machines are “bots”
o Victim is unaware of infection (stealthy)
 Botmaster controls botnet
o Often, using IRC
o P2P botnet architectures exist
 Botnets used for…
o Spam, DoS attacks, keylogging, ID theft, etc.

Part 4  Software 62
Botnet Examples
 XtremBot
o Similar bots: Agobot, Forbot, Phatbot
o Highly modular, easily modified
o Source code readily available (GPL license)
 UrXbot
o Similar bots: SDBot, UrBot, Rbot
o Less sophisticated than XtremBot type
 GT-Bots and mIRC-based bots
o mIRC is common IRC client for Windows

Part 4  Software 63
More Botnet Examples
 Mariposa
o Used to steal credit card info
o Creator arrested in July 2010
 Conficker
o Estimated 10M infected hosts (2009)
 Kraken
o Largest as of 2008 (400,000 infections)
 Srizbi
o For spam, one of largest as of 2008

Part 4  Software 64
Ransomware

 Recently,ransomware very popular


 Malware encrypts important info
o Key is provided only if ransom paid
o Sometimes key works, sometimes not…
 To pay or not to pay?
o Recent case, reportedly paid $5M
o In 2020 total ransom estimated $350M
o Payments are in cryptocurrency
Part 4  Software 65
Malware Detection
 Malware detection techniques
o Signature detection
o Change detection
o Anomaly detection
o Machine learning
 We briefly discuss each of these
o And consider advantages…
o …and disadvantages

Part 4  Software 66
Signature Detection
 A signature may be a string of bits in exe
o Might also use wildcards, hash values, etc.
 For example, W32/Beast virus has signature
83EB 0274 EB0E 740A 81EB 0301 0000
o That is, this string of bits appears in virus
 We can search for this signature in all files
 If string found, have we found W32/Beast?
o Not necessarily  string could be in normal code
o At random, chance is only 1/2112

Part 4  Software 67
Signature Detection
 Advantages
o Effective on “ordinary” malware
o Minimal burden for users/administrators
 Disadvantages
o Signature file can be large (10s of thousands)…
o …making scanning slow
o Signature files must be kept up to date
o Cannot detect unknown viruses
o Cannot detect some advanced types of malware
 The most popular detection method
Part 4  Software 68
Change Detection
 Viruses must live somewhere
 If you detect a file has changed unexpectedly, it
might have been infected
 How to detect changes?
o Hash files and (securely) store hash values
o Periodically re-compute hashes and compare
o If hash changes, file might be infected

Part 4  Software 69
Change Detection
 Advantages
o Few (if any) false negatives
o Can detect previously unknown malware
 Disadvantages
o Many files change  and often
o May be many false alarms (false positives)
o Heavy burden on users/administrators
o If suspicious change detected, then what?
Might have to fall back on signature detection

Part 4  Software 70
Anomaly Detection
 Monitor system for anything “unusual” or
“virus-like” or “potentially malicious” or …
 Examples of anomalous things
o Files change in some unexpected way
o System misbehaves in some way
o Unexpected network activity
o Unexpected file access, etc., etc., etc., etc.
 But, we must first define “normal”
o And normal can (and must) change over time

Part 4  Software 71
Anomaly Detection
 Advantages
o Chance of detecting unknown malware
 Disadvantages
o No proven track record
o Trudy might make abnormal look normal (go slow)
o Typically, anomaly detection is combined with another
method (e.g., signature detection)
 Also popular in intrusion detection (IDS)
 Difficult unsolved (unsolvable?) problem
o This sounds like a job for AI (equivalently, machine
learning, deep learning, big data)

Part 4  Software 72
Machine Learning
 Machine learning and AI is not widely applied to
malware detection problem
o Some AV systems claim to only use AI
 Models trained on features extracted from known
malware samples
 Then trained models used to classify
 Models can be viewed as higher-level “signatures”

Part 4  Software 73
Future of Malware
 Recent trends
o Encrypted, polymorphic, metamorphic malware
o Fast replication/Warhol worms
o Flash worms, slow worms
o Botnets, ransomware, and ???
 The future is bright for malware
o Good news for the bad guys…
o …bad news for the good guys
 Future of malware detection?
Part 4  Software 74
Encrypted Viruses
 Virus writers know signature detection used
 So, how to evade signature detection?
 Encrypting the virus is a good approach
o Ciphertext looks like random bits
o Different key, then different “random” bits
o So, different copies have no common signature
 Encryption often used in viruses today

Part 4  Software 75
Encrypted Viruses
 How to detect encrypted viruses?
 Scan for the decryptor code
o More-or-less standard signature detection
o But may be more false alarms

Part 4  Software 76
Polymorphic Malware
 Polymorphic worm
o Body of worm is encrypted
o Decryptor code is “mutated” (or “morphed”)
o Trying to hide decryptor signature
o Like an encrypted worm on steroids…

Q: How to detect?
A: Emulation might work
o Let the code decrypt itself
o Slow, and anti-emulation is possible

Part 4  Software 77
Metamorphic Malware
 A metamorphic worm mutates before infecting a new
system
o Sometimes called “body polymorphic”
 Such a worm can, in principle, avoids signature-based
detection
 Mutated worm must function the same
o And be “different enough” to avoid detection
 Detection is a difficult research problem

Part 4  Software 78
Metamorphic Worm
 One approach to metamorphic replication…
o The worm is disassembled
o Worm then stripped to a base form
o Random variations inserted into code (permute the code,
insert dead code, etc., etc.)
o Assemble the resulting code

 Result is a worm with same functionality as original,


but different signature

Part 4  Software 79
Future Malware Detection?
 There is so much malware, maybe it is better to
“detect” good code
o If code not on approved list, assume it’s bad?
o That is, use whitelist instead of blacklist

 Machine learning (AI) is clearly the wave of the


future in malware detection
o Offers many practical advantages
o Trudy may be able to fight back with AI too
o The arms race will likely continue!

Part 4  Software 80
Miscellaneous
Software-Based
Attacks

Part 4  Software 81
Miscellaneous Attacks
 Numerous attacks involve software
 We’ll discuss a few issues that do not fit into
previous categories
o Salami attack
o Linearization attack
o Time bomb

Part 4  Software 82
Salami Attack
 What is Salami attack?
o Programmer “slices off” small amounts of money
o Slices are hard for victim to detect
 Example
o Bank calculates interest on accounts
o Programmer “slices off” any fraction of a cent and puts it in his
own account
o No customer notices missing partial cent
o Bank may not notice any problem
o Over time, programmer makes lots of money!

Part 4  Software 83
Salami Attack
 Such attacks are possible for insiders
 Programmer added a few cents to every employee payroll
tax withholding
o But money credited to programmer’s tax
o Programmer got a big tax refund!

Part 4  Software 84
Salami Attacks
 In LA, four men installed computer chip that overstated
amount of gas pumped
o Customers complained when they had to pay for more gas than
tank could hold
o Hard to detect since chip programmed to give correct amount
when 5 or 10 gallons purchased
o Inspector usually asked for 5 or 10 gallons

Part 4  Software 85
Linearization Attack
 Program checks for
serial number S123N456
 For efficiency, check
made one character at a
time
 Can attacker take
advantage of this?

Part 4  Software 86
Linearization Attack
 Correct number takes longer than incorrect
 Trudy tries all 1st characters
o Find that S takes longest
 Then she guesses all 2nd characters: S
o Finds S1 takes longest
 And so on…
 Trudy can recover one character at a time!
o Same principle as used in lock picking

Part 4  Software 87
Linearization Attack
 What is the advantage to attacking serial number one
character at a time?de3
 Suppose serial number is 8 characters and each has 128
possible values
o Then 1288 = 256 possible serial numbers
o Attacker would guess the serial number in about 255 tries  a lot
of work!
o Using the linearization attack, the work is about 8  (128/2) = 29
which is easy

Part 4  Software 88
Linearization Attack
 A real-world linearization attack
 TENEX, an ancient OS (timeshare)
o Passwords checked one character at a time
o Careful timing was not necessary, instead…
o …could arrange for a “page fault” when next unknown
character guessed correctly
o Page fault register was user accessible

Part 4  Software 89
Time Bomb
 In 1986 Donald Gene Burleson told employer to stop
withholding taxes from his paycheck
 His company refused
 He planned to sue his company
o He used company time to prepare legal docs
o Company found out and fired him
 Burleson had been working on malware…
o After being fired, his software “time bomb” deleted important
company data

Part 4  Software 90
Time Bomb
 Company was reluctant to pursue the case
o So Burleson sued company for back pay!
o Then the company finally sued Burleson
 In 1988 Burleson fined $11,800
o Case took years to prosecute…
o Cost company many thousands of dollars…
o Resulted in a slap on the wrist for attacker
 An early example of a computer crime cases
 Many cases since follow a similar pattern
o That is, companies are reluctant to prosecute

Part 4  Software 91

You might also like