Program Security

Lecture 3
Week 3
 Topics
 Security principles
 Vulnerabilities
Secure Program
Malicious Code
Top 10 Web application vulnerabilities
 Safeguard to Program threat
 Pillar to Software Security

2
 Principles for Building Secure
Systems
 Security is economics
• No system is completely, 100% secure against all attacks. Rather,
systems may only need to resist a certain level of attack.

 Least privilege
• Give a program the set of access privileges that it legitimately
needs to do its job but nothing more. Try to minimize how much
privilege you give each program and system component.

 Use fail-safe defaults

• Use default-deny polices. Start by denying all access, then allow
only that which has been explicitly permitted. Ensure that if the
security mechanisms fail or crash, they will default to secure
behavior, not to insecure behavior.

3
 Principles for Building Secure
Systems
 Separation of responsibilities
• Split up privilege, so no one person or program has complete
power. Require more than one party to approve before access is
granted.

 Defense in depth
• if you use multiple redundant protections, then all of them would
need to be breached before the system's security will be
endangered.

Physiological acceptability
• It is important that your users buy into the security model

 Human factors matter

• Security systems must be usable by ordinary people, and must
be designed to take into account the role humans will play.
4
 Principles for Building Secure
Systems
 Ensure complete mediation
• When enforcing access control policies, make sure
that you check every access to every object.
 Know your threat model
• Be careful with old code. The assumptions originally
made might no longer be valid. The threat model may
have changed.
 Detect if you can’t prevent
• If you can't prevent break-ins, at least detect them
(and, where possible, provide a way to recover or to
identify the perpetrator).
5
 Principles for Building Secure
Systems
Don't rely on security through obscurity
• The phrase `security through obscurity' has come to be
understood to refer to systems that rely on the secrecy of their
design, algorithms, or source code to be secure.

Design security in from the start

Conservative design
• Systems should be evaluated according to the worst security
failure that is at all plausible, under assumptions favourable to
the attacker

 Proactively study attacks

• devote considerable effort to trying to break our own systems;
this is how we gain confidence in their security

6
 Secure Programs
 Different people have different perspective on
software quality.

 Tracking faults (from developers):

 Requirements
 Design
 Code inspections
Note: fixing might cause more faults

 Failures - are effects of faults

 Vulnerability and flaws do not map to faults and
failures
 "Bugs" means different things, depending on context.
 IEEE says "fault" is inside view from the developer
Failure - outside view from user 7
 Secure Programs
 Types of Flaws:
 validation error
 domain error
 serialization and aliasing
 inadequate identification and
authentication
 boundary condition violation
 other exploitable logic errors

8
 Non-malicious Program Errors?
 Buffer Overflows
 Accidental not checking array bounds Example C
program

9
 Non-malicious Program Errors?
 Incomplete Mediation - data exposed or
uncontrolled
http://www.testing.com/order.asp?cutID=115&part=66
6&qty=3&price=500&total=1500

 Time of Check to Time of use

 the process of executing the instruction
 Process all the data in the local storage
rather than put on the clipboard.

10
 Malicious Codes
 unanticipated
or undesired effects in programs
generated on the intent of damage

 damage could be in form of :

modification/destruction
stolen data
unauthorized access
damage on system
or other forms not intended by users

 Malware = malicious code that runs on a

victim’s system

11
 Malicious code ‐ some observations
Malicious code is any code added, changed or removed
from a software system in order to intentionally cause harm
or subvert the intended function of the system.

 “If you let somebody else execute code on your computer,

then it is not your own computer”
• User convinced of running a program, maybe done indirectly
by just inserting a USB memory (CD/DVD) into computer,
• User/system running a program (e.g. web browser) with a
vulnerability that can be taken advantage of,
• …
 Note that from a technical/scientific viewpoint:
• malicious code is “normal” code!!
 Thus: the malware problem is a software problem.
12
Malicious code ‐ some observations
Many users say:
I would never download unsecure
content!
But what type of content is safe?

13
 Malicious code ‐ some recent
trends
 Previously malware was normally of one specific kind.
 Nowadays, it is “multifunctional” and complicated.
• Malware is targeting end users through Web‐based
attacks (Symantec Internet Security Report xiv)
 Most viruses today are non‐destructive. Rather, they try
to take control over your computer to
• collect financial information or
• using it for malicious purposes, becoming a zombie, e.g.
to distribute spam. (claim is that 70% of all email is
spam)
 All kinds of malware tend to be called “virus”.
• Bagle, Mydoom, Netsky, Sasser, Kargo and Sober (2004)
• Conficker (2009)
14
 Malicious code ‐ reasons for
increase
A few trends that largely influence the wide spread of
malicious code:
 Growing number and connectivity of computers
• “everybody” is connected and dependant on computers
• the number of attacks increases
• attacks can be launched easily (automated attacks)
 Growing system complexity
• unsafe programming languages
• Heterogeneity
• hiding code is easy
• verification and validation is impossible (let alone proofs)
 Systems are easily extensible
• mobile code, dynamically loadable modules
• incremental evolution of systems
15
Taxanomy of Malicious Programs
Malicious
Programs

Need Host Independent

Program

Trapdoors Logic Trojan Viruses Bacteria Worms

Bombs Horses

16
 Malware
 Ismalicious software that is designed specifically to
damage or disrupt a system
 Also known as malicious programs. Figure shows the
total malware to-date.

17
 The problem of Malware
 How does Malware manage to run?
 Attacks a network-accessible vulnerable service
 Vulnerable client connects to remote system that
sends over an attack (a driveby)
 Social engineering: trick user into running/installing
 “Autorun” functionality (esp. from plugging in USB
device)
 Slipped into a system component (at manufacture;
compromise of software provider; substituted via
MITM)
 Attacker with local access downloads/runs it directly
• Might include using a “local root” exploit for privileged access

18
 What Can Malware Do?
 Pretty much anything
 Payload generally decoupled from how manages to
run
 Only subject to permissions under which it runs
 Examples:
 Brag or exhort or extort (pop up a message/display)
 Trash files (just to be nasty)
 Damage hardware (!)
 Launch external activity (spam, click fraud, DoS)
 Steal information (exfiltrate)
 Keylogging; screen / audio / camera capture
 Encrypt files (ransomware)
 Possibly delayed until condition occurs
 “time bomb” / “logic bomb”

19
 Malware That Automatically
Propagates
 Virus = code that propagates (replicates) across
systems by arranging to have itself eventually executed,
creating a new additional instance
• Generally infects by altering stored code

 Worm = code that self-propagates/replicates across

systems by arranging to have itself immediately executed
(creating new addl. instance)
• Generally infects by altering running code
• No user intervention required

 (Note: line between these isn’t always so crisp; plus

some malware incorporates both styles)

20
 The Problem of Viruses
 Opportunistic = code will eventually execute
• Generally due to user action
• Running an app, booting their system, opening
an attachment

 Separate notions: how it propagates vs. what else

it does when executed (payload)

 General infection strategy: find some code lying

around, alter it to include the virus

 Have been around for decades …

• … resulting arms race has heavily influenced
evolution of modern malware
21
 Propagation
 When virus runs, it looks for an opportunity to infect
additional systems
 One approach: look for USB-attached thumb drive, alter
any executables it holds to include the virus
• Strategy: when drive later attached to another system &
altered executable runs, it locates and infects executables
on new system’s hard drive
 Or: when user sends email w/ attachment, virus alters
attachment to add a copy of itself
• Works for attachment types that include programmability
• E.g., Word documents (macros), PDFs (Javascript)
 Virus can also send out such email proactively, using user’s
address book + enticing subject (“I Love You”)

22
 Examples of malicious codes:
 Trojan Horse - a program which performs a
useful function, but also performs an
unexpected action as well.

 Virus- a code segment which replicates by

attaching copies to existing executables.
Transient - only executes when the
program that it is attached to runs.
Resident - once the program executes the
virus stays in memory until it gets triggered
again. Terminate and Stay Resident (TSR). 23
 Examples of malicious codes:
 Worm - a program which replicates itself and
causes execution of the new copy.
 Bacteria - replicates until it fills all disk space, or
CPU cycles
 Logic bomb - malicious code that activates on
an event (e.g., date).
 Trap Door (or Back Door) - undocumented
entry point written into code for debugging that
can allow unwanted users.

24
 Examples of malicious codes:
 Spyware - This is new and can be non-malicious or
malicious.
 Can steal your information (Identity Theft) This is
done with a keystroke logger and even though you
use encryption on connections the damage is already
done before you can send it.
 Can steal your email addresses
 Can see what Web sites you visit
 Can see contents of files
 PopUp ads
 Slow down your computer
 Crash your computer
25
 How Viruses Attach
 Append viruses - execute first then transfers
control to original program.

 Surround virus -has control before and after

regular program.

 Integrated viruses - replace some of the target

program or all of the target and give the effect that
the target program worked.

26
 Virus Appended to a Program

+ or

Original Virus, B
Original Original
Program, A
Program, A Program, A
+ +
Virus, B Virus, B

27
28
 How Viruses Gain Control
 The virus needs to have the CPU execute it to be
in control.

 One way is to overwrite the program on the disk.

 Another is to move the original program and then

after the CPU executes it then transfer control to
the program.

 Another is to install itself in memory and change

the pointers of the operating system or interrupt
table to point to it.

29
 Homes for Viruses
 Install
itself in the boot sector (MBR)
master boot record.

 Memory resident virus - (TSR) terminate

and stay resident.

 Other homes such as applications like word

processors and spread sheets and even
attachments to email.

 Even attachments to vendor distributed

programs or games.
30
 Types of Viruses
 Parasitic Virus - attaches itself to executable files as part
of their code. Runs whenever the host program runs.
 Memory-resident Virus - Lodges in main memory as
part of the residual operating system.
 Boot Sector Virus - infects the boot sector of a disk,
and spreads when the operating system boots up (original
DOS viruses).
 Stealth Virus - explicitly designed to hide from Virus
Scanning programs.
 Polymorphic Virus - mutates with every new host to
prevent signature detection.

31
 The Source of Viruses
 Virusprogram can be small so it hides
very easily in a large program.

 Might
hide in a compiler, a data base
manager or a file manager.

 Thenumber one spot is an attachment

to email or some public download file.

32
 Virus Phases
 Dormant phase - the virus is idle

 Propagation phase - the virus places an

identical copy of itself into other programs

 Triggering phase – the virus is activated to

perform the function for which it was
intended

 Execution phase – the function is

performed
33
 Boot Sector Virus Relocating Code:

Phases of viral action:

34
Truths and Misconceptions About
Viruses
 Although other computers/operating systems are
vulnerable to Viruses, it seems the mentality of the
programmers of Viruses is more common on PCs.
 Viruses can modify hidden and read only files. True
 Viruses can appear only in data files or Word docs, or
in programs. False
 Viruses spread only on disks or in e-mail. False
 Viruses can not live in memory when the computer is
shut off, but they can still be on other storage devices.
Also Reboot (warm start) is vulnerable to Viruses in
memory. True
 Viruses cannot infect hardware. True
 Viruses can be malevolent, benign, or benevolent. True
35
Large-scale Malware
 Worm = code that self-propagates/replicates across
systems by arranging to have itself immediately
executed
 Generally infects by altering running code
 No user intervention required
 Propagation includes notions of targeting & exploit
 How does the worm find new prospective victims?
 How does worm get code to automatically run?

 Botnet= set of compromised machines (“bots”) under

a common command-and-control (C&C)
 Attacker might use a worm to get the bots, or other techniques;
orthogonal to bot’s use in botnet
36
Rapid Propagation

37
 How Worm Attack

+ + +

Original Worm, B
Program, A Original Worm, B Worm, B
Program, A

38
 Worms
 Characteristics of a worm:
 self-contained, do not require a host
 replication
 activated by creating process
 for network worms, replication occurs across
communication links
 Worms exploit flaws in the operating system
or inadequate system management to
replicate.
 Release of a worm usually results in brief but
spectacular outbreaks, shutting down entire
networks.
39
 Worms
 Protection against Worms
 requires a combination of basic system security and good
network security
 add-on tools:
 configuration review tools
 checksum-based change detection tools
 intrusion detection tools
 network security tools:
 wrapper program : filter network connections
 firewall system
 The most important means of defense is the
identification & authentication (I&A) controls, which
are usually integrated into the system. If poorly
managed, these controls become a vulnerability which
is easily exploited.
40
 Targeted Malicious Code

 The previous notes have dealt with

anonymous code not targeted to a specific
system, application or a particular purpose.

 Trapdoors - secret, undocumented entry

point into a module or program.

 Salami Attack

41
 Trapdoors and the Salami Attack
 Trapdoors are often caused by programmers leaving
debug routines in the code. Or failure to check array
bounds which lets code overrun the array bounds and
get placed on the stack.

 Causes of Trapdoors:
 Programmer forgets to remove them.
 Programmer intentionally leaves them in for testing.
 Leaves them in intentionally for maintenance of the
finished product.

 Leaves them in for later covert means of access.

 Salami Attacks refer to the simple fact, that when
dealing with real numbers the computer has a fixed size
and will perform rounding or truncation. There will
always be those programmers that will try to conceal
the small amounts on the hope that humans will not
notice 42
Top 10 Web App Vulnerabilities
 Attack associated to programs error
 Cross site scripting
 Injection flaws
 Malicious file execution
 Insecure direct object reference
 Cross site request forgery
 Information leakage and improper error
handling
 Broken authentication and session
management
 Insecure crypto storage
 Insecure comms
 Failure to restrict URL access
43
6
Cross Site Scripting: Stored XSS

5
44
Cross Site Scripting: Reflected XSS

45
 Virus Signatures
 Virus cannot be completely invisible but can be
very hard to detect, especially if it has self-
modifying code.

 The code it executes can be identified and a

program can scan for the tell-tail code.

 Usually it is at the start of a program or maybe a

test and jump to code at the bottom of the file.

 Ifthe virus writer wants to keep the program size

the same to prevent detection then it has to
replace some of the program code.

 But a good scanner with a checksum can detect

the changes in the code. 46
Example of cod red worm sign
GET/default.ida?NNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u780
1%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%
u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u53
1b%u53ff%u0078%u0000%u00=a HTTP/1.0

47
Safeguard to Program Threat
 Preventing Virus Infection
 Protection against viruses
 detection tools
 example : scanners, vulnerability monitors,
modification detection programs
 identification tools
 example : scanners
 removal tools
 example : disinfectors

 Scanners and disinfectors are the most popular classes of

anti-virus software.
 Personal and administrative practices and institutional
policies with regard to shared or external software usage
should form the first line of defense.
49
 Preventing Virus Infection
 Ways to prevent Virus infections
 Use only commercial software acquired from reliable, well
established vendors.
 Test all new software on an isolated computer.
 Do not put a floppy disk in the machine unless it has been
scanned first.
 Do not open attachments to email unless they have been
scanned. Including turn off the auto open of attachments in
mail readers.
 Scan any downloaded files before they are run.
 At least once a week update the virus signature data files.

 Make a bootable disk with a virus scan program on it and write

protected.
 Make and retain backup copies of executable system files in the
event the virus detection program can't remove the virus.

50
Preventing Web application attack
 Input validation.
 Strong output encoding.
 Do not use "blacklist" validation
 Do not use GET requests (URLs) for sensitive data or to perform value
transactions
 Disable or limit detailed error handling
 errors from all layers are adequately checked and configured to prevent
error messages from being exploited by intruders
 Do not allow the login process to start from an unencrypted page
 Encrypt Password
 Check the old password when the user changes to a new password
 Do not create cryptographic algorithms
 Do not use weak algorithms
 Ensure the access control matrix is part of the business, architecture, and
design of the application
 More….refer to OWASP TOP 10 Official document
 http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf
51
 Controls Against Program Threats
 Software Engineering
 Modularity, Encapsulation, and Information Hiding
 Peer reviews
 Hazard Analysis HAZOP, FMEA, FTA
 Independent Testing
 Good Design
 Prediction
 Static Analysis
 Configuration Management
 Proofs of Program Correctness
 Operating System Controls - trusted software,
confinement, audit log
 Administrative Controls - Standards of program
development
52
Pillar of software security

 Risk Management
 Touchpoints
 Knowledge

53
 Risk Management
 Business understands the idea of risk even
software risk
 Technical perfection is impossible
 There no such thing as 100% security
 Perfect quality is a myth
 Technical problem do not always spur
action
 Answer the So what? Question explicitly
 Help user undesrtand what they should do
about risk
 Build better software

54
Touchpoints

55
Knowledge catalog
 Principles
 Guidelines
 Rules
 Attack patterns
 Vulnerabilities
 Historical Risks

56
57
Summary of Program Threats and
Controls

 Malicious code gets a lot of publicity. But don't

let media attention distract you from the
seriousness of the threat.

 There is no real way to measure the amount of

damage that malicious code can do. All one can
do is estimate, and that is only for the
discovered programs, what about the ones that
haven't been discovered or haven't been
executed, or worst the ones that haven't been
written yet.
58
 Summary of Program Threats and
Controls
 Sitesto research for Viruses, Worms, Hoaxes and other
Malicious Code:
The Department of Energy's CIAC Hoax page
http://ciac.llnl.gov/ciac/CIACHoaxes.html
The Symantec Corporation (Norton Anti-virus Home)
SARC database
http://www.symantec.com/avcenter/hoax.html
Network Associates (McAfee and Dr. Solomon Anti-
virus) web page
http://vil.nai.com/villib/alpha.asp
The CERT (Computer Emergency Response Team)
http://www.cert.org/
The SANS Institute (System Administration,
Networking, and Security)
http://www.sans.org/newlook/home.htm 59
 Summary
 Viruses come in different forms
 Some are mere nuisances, some come with
devastating consequences
 E-mail worms are self replicating and clogs the
networks with unwanted traffic
 Virus codes are not necessarily complex
 It is necessary to scan the systems/networks for
infections on a periodic basis for protection
against viruses
 Anti-dotes to new virus releases are promptly
made available by security companies and the
forms the major counter measure.
60