Security 101

1
Security 101

• An Overview of Security Issues in Application
  Software
• Benjamin Khoo, PhDNew York Institute of
  Technology
• School of Managementkkhoo_at_nyit.edu

2
Acknowledgement

• Materials for many of these slides had been
  adapted from the web and also from security-based
  companies such as Outscheme Inc., Holub
  Associates, Security Innovation, Klocwork,
  Compuware, Microsoft, Secure Software, Cigital,
  Fortify Software, SPI Dynamics, Logic Gear, etc
• Their contributions to this set of slides is
  gratefully acknowledged.
• Ben

3
Agenda

• Understanding the Basics
• Introduction
• Security Issues
• Application Security
• Security Through Obfuscation
• Summary

4
What is Computer Security?

• Computer security is a combination of many
  protective measures taken to ensure the safety of
  the data and resources of both the owners and the
  users of the computer systems.
• Computer security involves both keeping private
  information safe and preventing loss of
  resources.
• Computer security concerns active attacks from
  external sources, internal abuse and inadvertent
  loss of information.

5
What is Computer Security? (2)

• We often think of an attack as coming from a
  malicious outsider trying to wreak havoc or steal
  information. However, this is just one type of
  security vulnerability.
• Another type of security vulnerability is failure
  to enforce restrictions on access to the data
  that are based on the authorization level of the
  user.
• For example, not all internal employees need
  access to the same data. Providing complete
  access to all employees' health information to
  everyone in the Human Resources department is a
  security risk. In this case the application must
  provide varying access to the data, based on the
  privileges (security authorization) of the user.
  The system must also authenticate the user to
  verify their identity within the computer system.

6
What are We Protecting?

• Protecting data
• Integrity-Ensuring that business transaction
  data is not altered or corrupted. If something
  has been changed or modified since it was
  created, verifying that the changes are
  legitimate.
• Confidentiality-Ensuring unauthorized access
  to information will be denied.
• (Users Data) Privacy-For example, Web sites
  and applications should have a privacy statement
  that defines how user information will be
  handled. In addition, the producer also needs to
  put in a concerted effort to protect users data.

7
What are We Protecting? (2)

• As intellectual property-Ensuring that asset
  such as business intelligence, source code, and
  any data related to intellectual property is
  safeguarded.
• Availability-Ensuring that data availability
  is as expected. A denial-of-service attack or a
  natural disaster is an example of data
  availability threats.
• Protecting network computing resources-Ensuring
  that unauthorized uses of network resources are
  denied.

8
Introduction
Area
Changes

• Business usage of Internet and related networks
  has changed to an interconnected, transactional
  model
• More reasons for connectivity partnerships,
  outsourcing, consumer service

Internet Usage

• Growing in complexity
• Outsourcing of more functions

Supply Chains

• Have been developed, extended, or interconnected
  to support an emerging model of networked business

Applications

• Evolving to address concerns around
• - technology controls
• integrity of financial data
• privacy needs for personal information

Regulations
9
Introduction (2)
The Security Problem
83 per cent of global financial institutions
admitted their systems have been compromised in
the past year, compared to only 39 per cent in
2002. - Deloitte's 2004 Global Security Survey

Recovering from a security breach takes an
average 22 hours and causes 2 million in lost
revenues. - Aberdeen Group
Demand that providers of all software both
'shrink-wrapped' and custom demonstrate the use
of security vulnerability testing during
development. - Gartner
10
Introduction (3)
Emerging Threats

• Todays threat is not simply hackers looking for
  computing resources, defacement opportunities, or
  simple network and host access
• Convergence between criminal activities and
  technology leveraged attacks is here
• Phishing attacks, data theft, identity theft
• Todays threat is
• Direct attacks from technologically enabled
  criminals
• Attacks targeted at business logic and process
• Resource target is data theft, often for
  financial gain

11
Introduction (4)

• Secrecy ? Security.
• Secrecy You can't find the safe.
• Security You can't open the safe, even if you
  know
• how it works.
• Secret systems are never secure!
• The best way to assure that an encryption
• algorithm is secure is to have thousands of
• knowledgeable people try to break it.
• Security ? Technology
• Security comes from well-thought-out protocols
  (in
• the diplomatic sense).
• Technology only gives you a means to implement
  a portion of the protocol.

12
Security is about risk and liability

• If the cost of fixing a security breach is higher
  than the cost of writing off the loss, businesses
  will take the loss.
• Security is all about lowering risk to a
  reasonable level, not eliminating risk.
• Ultimately, security comes from a web of
  contracts (in the legal sense) that impose
  liability when security is compromised.
• E.g. Insurance is an important component of
  a secure eBusiness system. (SSL ? security).

13
e-Commerce Security Example

• Web security is an essential element that
  provides consumers and producers confidence and
  acceptance in the use of commercial applications.
  An e-commerce site needs to address the following
  security issues
• The interactions and transactions between a
  buyer and merchant must be strictly
  confidential and data integrity must be
  preserved.
• A buyer and merchant must be able to verify
  each others identity.
• The transaction records must be in a form that
  will hold up in a court of law.

14
Characteristics of a Secure System

• Access control
• Only authorized individuals can access it.
• Confidentiality
• Only authorized individuals can read the text.
• Authentication
• The writers are who they say they are.
• Non-repudiation
• The writers can't claim they didn't write it.
• Integrity
• The document you received is the one I sent.

15
People are Human, not Stupid

• Any system that depends on abnormal behavior is
  insecure. The following behaviors are reasonable
• Hi. This is Fred from IT. Can I have your
  password so I can check the system?
• I cant remember 50 passwords, so I use the
  same password everywhere.
• At one point 80 of the passwords at Berkeley
  were characters from the Lord of the Rings.
• I cant remember long passwords.
• I dont have a clue what all that junk in the
  Security-Options dialog means!
• If I enable security, I cant browse!
• The email came from a friend and got through the
  virus check, so why cant I click on it?

16
Hackers Exploit Bugs

• Attacks that dont exploit human factors exploit
  bugs.
• All software has bugs in it.
• Firewalls dont protect against bugs.
• The more popular (pervasive) the system, the more
  people will try to attack it.
• Bad design (e.g. activeX) is a bug.

17
Worry about the right thing!

• Nobody intercepts credit-card transmissions on
  the internet.
• Lots of people hack into merchant databases and
  harvest credit-card numbers by the thousand.
• Until recently, VISA did not require credit
  card numbers to be encrypted.
• Even now, most merchant databases are still
  not encrypted, since theres no mandatory
  audit requirement.
• There are solutions (e.g. CitiCard single-use
  numbers)

18
Worry about the right thing(2)

• Firewalls dont protect against denial of service
  or bug-based attacks.
• Firewalls have bugs too!
• If your router is your firewall, someone can
  simultaneously hack into both!
• Typically, layered systems with multiple
  firewalls (from different vendors) are used.
• A bug in a subroutine in an app server is behind
  all of the above, and can be accessed through all
  of them.

19
No Program is an Island
20
How long will it take?

• Not "is it breakable?" But "how long will it
  take to break it?
• Will the information have value at that time?
• Consider a 4-wheel combination lock. How long to
  try every combination?
• 10,000 possibilities (13 bits), 1 every 2
  seconds 20,000 seconds (5.5 hours)
• 2 people, each trying ½ the codes 2.750
  hours
• 4 people, each trying ¼ the codes 1.375
  hours
• 10,000 people, each trying 1 code 2
  seconds

21
Cost of a Brute-Force Attack

• Breaking a cipher is a function of
• number of possible keys (10,000 possibilities
  13 bits)
• cost of the hardware (number of processors)
• time
• Given enough time or enough money, you can crack
  anything.
• Will the value of the text outlive the time
  required to break the encryption?

22
Risk Assessment

• A simplistic quantitative model
• SLE AV x EF
• SLE Single Loss Expectancy
• AV Asset Value
• EF Exposure Factor (0 - 100)
• ALE SLE x ARO
• ALE Annualized Loss Expectancy
• ARO Annualized Rate of Occurrence (0.0 Never
  1.0 Always this is frequency rather than
  probability).
• E.g., a threat occurring once every 10 years has
  an ARO of 1/10 or 0.1 a threat occurring 10
  times a year has an ARO of 10.
• Source A Guide to Building Secure Web
  Applications and Web Services, The Open Web
  Application Security Project, http//www.owasp.org
  

23
What Affects Security?

• Viruses, worms, Trojan horses
• Phishing, identity theft
• Physical security
• Firewalls, network security
• Defects in platform / patches
• Authentication / authorization
• Application security

24
Security Attacks On the Rise
25
Security Attacks On the Rise (2)

• Hacking tools freely available
• Business applications exposed on internet
• Increasing tangible and intangible costs

Network
75 percent of hacks happen at the application
Application
Database Server
Web Server
App Server
Operating System
26
Business At Risk

• Brand and Intellectual Property losses
• Legal / Regulatory costs
• System abuse
• System access denied
• Data stolen, deleted, or modified
• IT and end-user productivity costs

27
Security Security Security

• Security incidents reported to CERT grew by
  2,099 between 1998 and 2002
• Estimates put the cost of the MyDoom worm alone
  at over 4 billion
• several new versions have surfaced on the
  Internet That could mean that bigger Doom is on
  the way

28
Poor Software quality - Root Cause of Security
Vulnerabilities
35 of all successful attacks are a result of
software defects

• Most vulnerabilities come from software
  implementation (coding) errors (Congressional
  Testimony, Richard D. Pethia, CERT Director)

• Traditional testing will not identify security
  problems, since it looks for predictable user
  behavior, not unpredictable hacker attacks (Watts
  Humphreys of the SEI Institute)

29
How serious are we about software quality?

• U.S. Average Defect Rate 5.9 to 7 defects per
  thousand lines of code (Software Assessments,
  Benchmarks, and Best Practices by Capers Jones)
• Software defects rates have increased 15 in
  1999-2000 compared to 1997-1998 (Meta
  Group,January 2002)

30
The Defenders Dilemma

• The defender must defend all points
• The defender can defend only against known
  attacks
• The defender must be constantly vigilant
• The defender must play by the rules

31
The Attackers Advantage

• The attacker can choose the weakest point.
• The attacker can probe for unknown
  vulnerabilities
• The attacker can strike at will
• The attacker can play dirty

32
The Defenders Dilemma and the Attackers
Advantage

• The defender must defend all points the attacker
  can choose the weakest point.
• The defender can defend only against known
  attacks the attacker can probe for unknown
  vulnerabilities
• The defender must be constantly vigilant the
  attacker can strike at will
• The defender must play by the rules the attacker
  can play dirty

33
Understanding the adversary

• What would you do if you wanted to better
  understand your adversaries?
• Talk to them?
• Hackers tend to be one-trick ponies and focus on
  what worked yesterday
• Hackers are not bound by ship pressure, no need
  to be efficient
• Truth is studying hackers will just depress you
• They have low-level C and assembly skills
• They have access to thousands of freeware hacking
  tools
• They read the thousands of hacker sites out there
  chock full of tips, hints and tutorials
• We really need to understand all adversaries
• Study todays hacks and look forward to
  tomorrows
• Understand how to close these issues efficiently
  and effectively
• The answer study how the hackers get in

34
Entry points are everywhere
Login screens Web forms Custom clients
OS
Resource starvation Secret content
Application Under Test
User Input
Libraries/ network
Exec. content Remote files Corrupt files Secret
content
Missing/Trojaned libraries Corrupt
packets Bandwidth attacks RPC/Web Services
files
35
From entry point to breach

• A system can be breached in one of three ways
• By sending it input it cant or shouldnt handle
• Code hidden in data
• Long strings
• Format strings
• Magic bullets,
• By rigging its environment
• Hiding code in files
• Trojaning resources,
• By turning its own logic against it
• Alternate code paths
• Time of check, time of use
• Loop conditions,
• Not counting social engineering and the
  insider threat

36
Proactive Security Development

• As defenders, software developers must always be
  vigilant and work smart.
• Security Principles to live by
• Secure by Design, Default and Deployment
• Learn from Mistakes
• Minimize Your Attack Surface
• Use Least Privilege
• Assume External Systems are Insecure
• Remember that Security Features ! Secure
  Features
• Never Depend on Security by Obscurity Alone
• Fix Security Issues Correctly
• Plan on Failure

37
When Hackers Attackwhy?

• Monetary
• Denial of Service/Publicity
• Spammers
• Extortionists
• Eavesdropping ()
• Intellectual Property/Idea Theft
• Script Kiddie fame
• Black Hat

38
What Applications Need Protection?

• Anything on the Internet
• Any application contains IP that competitors
  would benefit from
• If you have a reason to make something closed
  source

39
Categories of Application Security

• Data Security
• Encryption
• Client-side Application Security
• Licensing
• IP Protection
• Code Theft
• Server Security
• Limited to Interactional Interface

40
Data Security

• Encryption works well for data
• Sometimes, it's effectively perfect
• All Encryption algorithms are crackable
• It just might take millions of years
• Small problems are usually solved
• Keeping the key secret
• Transporting the key

41
Vulnerability
Client Interface
Reverse-engineering
interactional
Network Interface
Application
42

• Networked/Interactional
• Application Security

43
Interactional Security

• In this context, we almost always want protection
• Insecure apps can compromise servers
• Compromised servers can be used as spambots or
  attack launch points

44
Interactional Security

• Must limit interface vulnerability
• The max-security VS min-usage problem
• No direct access to the running application
• Indeed if we had that, we probably no longer care
  about the server itself
• Many possible attacks here
• Infamous buffer overrun
• Unexpected input

45
Interactional Security

• Input Validation
• Language environments such as Java/.NET prevent
  memory overwriting attacks
• Prevent SQL injection
• Prevent injected executables
• Verify Ranges

46
Interactional Security

• For most attacks good (perfect?) security is
  possible
• Diligence in input validation
• Smart information disclosure
• Unpredictable session keys
• No vital info in cookies
• No informational errors to the client
• DOS attacks
• More complex, often app-external solutions

47
Network Security

• Port Scan
• nmap -sS -v -p1-65535
• 22/tcp open ssh
• 25/tcp open smtp
• 53/tcp open domain
• 69/tcp filtered tftp
• 80/tcp open http
• 135/tcp filtered msrpc
• For on-demand services there is port-knocking
• Packet Sniffing/Spoofing

48
Network Security

• Packet Sniffing
• Ethereal, Sniffit, Tcpdump
• Packet Spoofing
• Wardriving
• Netstumbler
• WEP Cracking
• Airsnort

49

• Application Security
• Access to the source

50
Applications are not Data

• At least as far as security goes
• Encryption doesn't work well for applications
• Computers can't run encrypted programs
• Problem Deliver code a computer can understand
  that humans cannot
• Encrypting class loaders worked (java)
• For a minute or two anyway

51
Application Security

• The client is in the hands of the enemy
• The bad guy has all the time in the world to
  examine the how/what/where of your application
• Anything you protect can be unprotected
• Anything you hide can be found
• Watermarking is an attempt to solve this

52
Application Security

• Networked/Interactional systems always care about
  security
• What's protectable in your application?
• Open source is obviously not necessarily
  protection worthy
• Licensing scheme?
• DB Connection scheme?
• Algorithm IP?
• General IP?

53
Security through Obscurity

• This is bad right?
• Actually, it depends
• What are we protecting
• Sometimes more protection never hurts
• How much security are we getting?
• Seems to work for house keys, missiles, and
  hackers
• How much does it cost to implement?
• A lot of security for a little might be worth it,
  a little for nothing is good too

54
Security through Obscurity

• Security through obscurity is likely the world's
  most prevalent security model
• Probably because in many cases it is cheap or
  even free
• If it's all you have...
• Add to a good solution
• Front door locks and The Club
• The go elsewhere solution
• Rely on it accordingly

55
Security through Obscurity

• Short version What's the return-on-investment
• Or, security-for-investment
• How do we measure what security we've gained?
• Defensively, StO should increase the time it
  takes to get what is being secured

56
Security through Obscurity

• Increasing the time it takes to hack decreases
  the ROI of the thief
• Increases his exposure to be detected
• Makes other targets more appealing
• Gives him more work
• Frustrates him (or challenges him)

57
Games

• Almost every game on the shelf has a crack for
  the licensing scheme on the net days after it was
  released
• Why bother?

58
Games

• Cracks are complex
• We can still sell to the rich and non-technical
• Cracks are immoral
• We can still sell to the good guys
• Cracks are underworld
• We can still sell to those people not willing to
  risk virusizing their machines

new word
59
Psychological Warfare

• It's about the 2 months
• Use layers of license protection of increasing
  complexity
• Understand things will likely be cracked

60
Psychological Warfare

1. Evil-Johnny (EJ) spends 2 days cracking
2. EJ distributes crack, brags to friends
3. 2 days later, game fails again due to invalid
   license
4. Friends yell at EJ
5. EJ spends 3 more days cracking next tier
6. If (friends.stillTrustEJ()) goto 2

61
Auto-update/server dependence

• Apps that perpetually phone home can be changed
  or disabled
• Half Life 2 (released Nov. 2004)
• Valve, Inc. tracked cracked copies and prevented
  those versions from hitting their servers
  (crippling the install)
• The Ninja Beta release
• Subtlety is more powerful than force

62
Reverse Engineering Tools

• SoftIce
• Any C/C/etc. Windows app
• C - Reflector, ILDASM
• Java JODE, JAD
• Almost any profiler, debugger, disassembler, or
  decompiler is going to reveal plenty of
  information

63
Reverse Engineering Tools

• C reverse engineering was hard
• An exercise in machine language
• Following full program logic was very hard
• C decompilers rarely work
• Optimizations make this problem harder
• Cracking was easiest often because there was a
  single point of failure

64
Reverse Engineering Tools

• Java and .NET work differently
• Java --gt Bytecode
• .NET --gt MSIL
• Respective compilers tend to produce code that
  has a 1-1 relationship with original source
• Java and .NET compilers do almost no code
  optimization at all
• Writing a usable decompiler is not terribly
  difficult

65
Code Obfuscation
VM Execute
Classes/ assemblies
compiler
Java/.NET source
decompiler
66
Code Obfuscation

• We need a way to transform code such that
• The runtime still understands it
• Humans have a much harder time understanding it
• i.e., increase the effort and time required to do
  so
• Encryption would require we lock the package and
  hide the key
• Obfuscation sends the contents in plain view,
  it's just that the view isn't too good

67
What can obfuscators do to prevent code
reverse-engineering?

• What's the goal?
• Hide IP
• Make cracking harder (licensing)
• Hide valuable info (Db connection, etc)
• Hold-off copycat competitors

68
What can obfuscators do to prevent code
reverse-engineering? (2)

• Identifier Renaming
• Pruning
• Control Flow Obfuscation
• Optimizations
• String Encryption
• Why would I obfuscate server code?

69
Code Obfuscationsimple goal
VM Execute
Classes/ assemblies
compiler
Java/.NET source
obfuscator
decompiler
Munge, munge, munge, munge, munge, ...
70
Identifier Renaming

• Programmers use descriptive identifier names to
  describe classes, methods, fields, etc.
• Programmers love this for maintenance
• Hackers love this for hacking
• Runtimes don't really care
• How about renaming all identifiers prior to
  distribution so long as programmers can
  un-rename them

71
Identifier Renaming
getPayroll(int) --gt a(int) getUser(String) --gt
b(String) addValue() --gt c() delValue(float)
--gt d(float) Overload Induction getPayroll(i
nt) --gt a(int) getUser(String) --gt a(String) a
ddValue() --gt a() delValue(float) --gt a(floa
t)
72
Control Flow Obfuscation

• To a runtime, control-flow is about goto's
• Loops exist, but not exactly for loops, while
  loops, or do loops
• Loops are just backward jumps
• If statements get transformed into forward
  jumps
• Restructuring control-flow doesn't usually hurt a
  runtime

73
Control Flow Obfuscation

• Decompilers must analyze control flow to rebuild
  source statements

x
goto
for
for
goto
if xlt0
yy-1
goto
yy1
yy-1
x
yy1
goto
if xlt0
if xlt100
if xlt100
74
Control Flow Obfuscation

• Most decompilers crash on sufficiently nasty
  control flow
• JODE does well
• We must be careful not to break anything
• Additional indirection is usually removed by many
  runtimes
• Some techniques can introduce subtle errors
• Example using static variables can introduce
  subtle race conditions

75
Summary

• Interactional/Network Security
• Many good references available
• Input validation is often at the core of most
  protection techniques
• This problem is theoretically solvable
• Application complexity is where things are
  allowed to slip through

76
Summary

• Application Security
• The client is in the hands of the enemy
• Persistent server interaction
• Updates
• Phone home
• Provide a service!
• Obvious confirm Don't Spy
• Psychological Warfare
• If you're positive you're acting against the bad
  guy, you can take off the white hat

77
Summary

• Application Security
• Java and .NET are reverse-engineerable with
  one-click
• Obfuscation is cheap or FREE
• Dotfuscator CE in every copy of Microsoft Visual
  Studio 2003 and 2005
• Estimate how much a breach would cost you and
  plan accordingly

78
Summary

• As defenders, software developers must always be
  vigilant and work smart.
• Security Principles to live by
• Secure by Design, Default and Deployment
• Learn from Mistakes
• Minimize Your Attack Surface
• Use Least Privilege
• Assume External Systems are Insecure
• Remember that Security Features ! Secure
  Features
• Never Depend on Security by Obscurity Alone
• Fix Security Issues Correctly
• Plan on Failure

79
Suggested Preventive Tools for Windows

• Set-up auto-download of MS updates
• MS Baseline Security Analyzer
• MS Internet Info Server Lock-Down
• MS Tool to Remove Malicious Software
• MS Anti-Spyware
• Adaware
• Spybot Search and Destroy

80
References

• Preemptive Solutions, Inc.
• http//www.preemptive.com
• Code Security whitepapers, demos, etc.
• http//www.securityfocus.com/archive/1/272037
• Many Javascript injection attacks
• http//msdn.microsoft.com/msdnmag/issues/04/09/SQL
  Injection/default.aspx
• MSFT article on SQL injection

81
References

• Chkrootkit - www.chkrootkit.org
• Linux based rootkit detector
• RK Hunter - www.rootkit.org
• Linux based rootkit detector
• Airsnort - airsnort.shmoo.org
• Linux WEP cracker
• Airmagnet -
• Windows wireless net finder

82
References

• Dasho-Pro - www.preemptive.com
• Java Watermark/Code Security tool
• Used on the Java JDK's JCE library
• JODE - jode.sf.net
• Java Decompiler
• JAD - kpdus.tripod.com/jad.html
• Java Decompiler (bit out-of-date)

83
References

• Reflector - http//www.aisto.com/roeder/dotnet/
• .NET decompiler (any language)
• Dotfuscator - www.preemptive.com
• .NET Code security tool
• Community Edition included in VS2003-5
• Preemptive Demos
• http//www.preemptive.com/downloads/Documentation.
  html
• Flash demos of SQL injection, reverse-engineering,
  license check bypass

84
References

• www.gamecopyworld.com
• Cracks for most games
• www.astalavista.sk
• Cracking tutorials, cracks, tools
• www.compuware.com
• SoftIce debugger (aka cracking tool)
• http//www.linuxjournal.com/article/6811
• Port knocking article

85
References

• Writing Secure Code, Howard/Leblanc, Microsoft
  Press, ISBN 0735615888
• Excellent Reference
• Decompiling Java, G.Nolan, Apress, ISBN
  1590592654
• Details of reverse-engineering and protecting
  Java
• COLLBERG Christian Collberg, Clark Thomborson,
  Watermarking, Tamper-Proofing, and
  Obfuscation--Tools for Software Protection, IEEE
  Transactions on Software Engineering 288,
  735-746, August 2002
• University of Arizona