2007 Dr Benjamin Khoo, PhDNYIT, New York1
Security 101
An Overview of Security Issues in
Application Software
Benjamin Khoo, PhD
New York Institute of Technology
School of [email protected]
2007 Dr Benjamin Khoo, PhDNYIT, New York2
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
2007 Dr Benjamin Khoo, PhDNYIT, New York3
Agenda
• Understanding the Basics• Introduction• Security Issues• Application Security • Security Through Obfuscation• Summary
2007 Dr Benjamin Khoo, PhDNYIT, New York4
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.
2007 Dr Benjamin Khoo, PhDNYIT, New York5
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.
2007 Dr Benjamin Khoo, PhDNYIT, New York6
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.
– (User’s 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 user’s data.
2007 Dr Benjamin Khoo, PhDNYIT, New York7
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.
2007 Dr Benjamin Khoo, PhDNYIT, New York8
Introduction
• Have been developed, extended, or interconnected to
support an emerging model of networked business
• Growing in complexity• Outsourcing of more functions
Internet Usage
Supply Chains
Applications
AreaArea ChangesChanges
Regulations
• Business usage of Internet and related networks has
changed to an interconnected, transactional model
• More reasons for connectivity: partnerships,
outsourcing, consumer service
• Evolving to address concerns around:
- technology controls
– integrity of financial data
– privacy needs for personal information
2007 Dr Benjamin Khoo, PhDNYIT, New York9
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
NETWORK SYSTEMAPPLICATION
SECURITY
`96 - Present Beginning `00 2004+
• Code Inspections
• Automated Flaw Discovery
• Remediation
• Certification
• Single sign-on
• Biometrics
• Web services
• ISP Packaged Apps
• Firewalls
• Intrusion Detection
• VPN
• Filtering
Demand that providers of all software — both 'shrink-wrapped' and custom — demonstrate the use of security vulnerability testing during development. - Gartner
2007 Dr Benjamin Khoo, PhDNYIT, New York10
Introduction (3)
• Today’s 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
• Today’s threat is:– Direct attacks from technologically enabled
criminals– Attacks targeted at business logic and process– Resource target is data theft, often for
financial gain
Emerging Threats
2007 Dr Benjamin Khoo, PhDNYIT, New York11
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 issecure 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.
2007 Dr Benjamin Khoo, PhDNYIT, New York12
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).
2007 Dr Benjamin Khoo, PhDNYIT, New York13
e-Commerce Security ExampleWeb 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 other’s identity.– The transaction records must be in a form that will hold up in a court of law.
2007 Dr Benjamin Khoo, PhDNYIT, New York14
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.
2007 Dr Benjamin Khoo, PhDNYIT, New York15
People are Human, not StupidAny 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 can’t 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 can’t remember long passwords.”
– “I don’t have a clue what all that junk in the Security-Options dialog means!”
– “If I enable security, I can’t browse!”
– “The email came from a friend and got through the virus check, so why can’t I click on it?”
2007 Dr Benjamin Khoo, PhDNYIT, New York16
Hackers Exploit Bugs• Attacks that don’t exploit human factors
exploit bugs.
• All software has bugs in it.
• Firewalls don’t 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.
2007 Dr Benjamin Khoo, PhDNYIT, New York17
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 there’s no mandatory audit
requirement.
– There are solutions (e.g. CitiCard single-use numbers)
2007 Dr Benjamin Khoo, PhDNYIT, New York18
Worry about the right thing(2)• Firewalls don’t 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.
2007 Dr Benjamin Khoo, PhDNYIT, New York20
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
2007 Dr Benjamin Khoo, PhDNYIT, New York21
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?
2007 Dr Benjamin Khoo, PhDNYIT, New York22
Risk AssessmentA simplistic quantitative model
SLE = AV x EFSLE: Single Loss ExpectancyAV: Asset ValueEF: Exposure Factor (0 - 100%)
ALE = SLE x AROALE: Annualized Loss ExpectancyARO: 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
2007 Dr Benjamin Khoo, PhDNYIT, New York23
What Affects Security?• Viruses, worms, Trojan horses
• Phishing, identity theft
• Physical security
• Firewalls, network security
• Defects in platform / patches
• Authentication / authorization
• Application security
2007 Dr Benjamin Khoo, PhDNYIT, New York25
Security Attacks On the Rise
(2)• Hacking tools freely
available
• Business applications exposed on internet
• Increasing tangible and intangible costs Operating System
App Server
Web Server
Database Server
Application
Network75 percent of hacks happen at the application
2007 Dr Benjamin Khoo, PhDNYIT, New York26
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
2007 Dr Benjamin Khoo, PhDNYIT, New York27
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 …
2007 Dr Benjamin Khoo, PhDNYIT, New York28
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)
2007 Dr Benjamin Khoo, PhDNYIT, New York29
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)
2007 Dr Benjamin Khoo, PhDNYIT, New York30
The Defender’s 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
2007 Dr Benjamin Khoo, PhDNYIT, New York31
The Attacker’s 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
2007 Dr Benjamin Khoo, PhDNYIT, New York32
The Defender’s Dilemma and the
Attacker’s 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
2007 Dr Benjamin Khoo, PhDNYIT, New York33
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 today’s hacks and look forward to tomorrow’s• Understand how to close these issues efficiently and
effectively
• The answer: study how the hackers get in
2007 Dr Benjamin Khoo, PhDNYIT, New York34
Entry points are everywhere
Application Under Test
OS
UserInput
files
Libraries/network
Login screensWeb formsCustom clients
…
Exec. contentRemote filesCorrupt filesSecret content
…
Missing/Trojaned librariesCorrupt packetsBandwidth attacksRPC/Web Services
…
Resource starvationSecret content
…
2007 Dr Benjamin Khoo, PhDNYIT, New York35
From entry point to breach• A system can be breached in one of three*
ways:– By sending it input it can’t or shouldn’t 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
2007 Dr Benjamin Khoo, PhDNYIT, New York36
Proactive Security
DevelopmentAs defenders, software developers must
always be vigilant and work smart.
Security Principles to live by:1. Secure by Design, Default and Deployment
2. Learn from Mistakes
3. Minimize Your Attack Surface
4. Use Least Privilege
5. Assume External Systems are Insecure
6. Remember that Security Features != Secure Features
7. Never Depend on Security by Obscurity Alone
8. Fix Security Issues Correctly
9. Plan on Failure
2007 Dr Benjamin Khoo, PhDNYIT, New York37
When Hackers Attackwhy?
• Monetary• Denial of Service/Publicity
– Spammers– Extortionists
• Eavesdropping ($$$)• Intellectual Property/Idea Theft• Script Kiddie fame• Black Hat
2007 Dr Benjamin Khoo, PhDNYIT, New York38
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
2007 Dr Benjamin Khoo, PhDNYIT, New York39
Categories of Application Security
• Data Security– Encryption
• Client-side Application Security– Licensing– IP Protection– Code Theft
• Server Security– Limited to Interactional Interface
2007 Dr Benjamin Khoo, PhDNYIT, New York40
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
2007 Dr Benjamin Khoo, PhDNYIT, New York41
Vulnerability
NetworkInterface Application
ClientInterface
Reverse-engineering
interactional
2007 Dr Benjamin Khoo, PhDNYIT, New York43
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
2007 Dr Benjamin Khoo, PhDNYIT, New York44
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
2007 Dr Benjamin Khoo, PhDNYIT, New York45
Interactional Security
• Input Validation– Language environments such as Java/.NET
prevent memory overwriting attacks– Prevent SQL injection– Prevent injected executables– Verify Ranges
2007 Dr Benjamin Khoo, PhDNYIT, New York46
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
2007 Dr Benjamin Khoo, PhDNYIT, New York47
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
2007 Dr Benjamin Khoo, PhDNYIT, New York48
Network Security• Packet Sniffing
– Ethereal, Sniffit, Tcpdump• Packet Spoofing• Wardriving
– Netstumbler• WEP Cracking
– Airsnort
2007 Dr Benjamin Khoo, PhDNYIT, New York50
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
2007 Dr Benjamin Khoo, PhDNYIT, New York51
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
2007 Dr Benjamin Khoo, PhDNYIT, New York52
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?
2007 Dr Benjamin Khoo, PhDNYIT, New York53
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
2007 Dr Benjamin Khoo, PhDNYIT, New York54
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
2007 Dr Benjamin Khoo, PhDNYIT, New York55
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
2007 Dr Benjamin Khoo, PhDNYIT, New York56
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)
2007 Dr Benjamin Khoo, PhDNYIT, New York57
Games
• Almost every game on the shelf has a crack for the licensing scheme on the net days after it was released
• Why bother?
2007 Dr Benjamin Khoo, PhDNYIT, New York58
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
2007 Dr Benjamin Khoo, PhDNYIT, New York59
Psychological Warfare
• It's about the 2 months• Use layers of license protection of
increasing complexity– Understand things will likely be cracked
2007 Dr Benjamin Khoo, PhDNYIT, New York60
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
2007 Dr Benjamin Khoo, PhDNYIT, New York61
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
2007 Dr Benjamin Khoo, PhDNYIT, New York62
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
2007 Dr Benjamin Khoo, PhDNYIT, New York63
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
2007 Dr Benjamin Khoo, PhDNYIT, New York64
Reverse Engineering Tools● Java and .NET work differently
● Java --> Bytecode● .NET --> 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
2007 Dr Benjamin Khoo, PhDNYIT, New York65
Code Obfuscation
Java/.NETsource
compilerClasses/
assemblies
decompiler
VMExecute
2007 Dr Benjamin Khoo, PhDNYIT, New York66
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
2007 Dr Benjamin Khoo, PhDNYIT, New York67
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
2007 Dr Benjamin Khoo, PhDNYIT, New York68
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?
2007 Dr Benjamin Khoo, PhDNYIT, New York69
Code Obfuscationsimple goal
Java/.NETsource
compilerClasses/
assemblies
decompiler
VMExecute
obfuscatorMunge, munge,
munge,munge, munge,
...
2007 Dr Benjamin Khoo, PhDNYIT, New York70
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
2007 Dr Benjamin Khoo, PhDNYIT, New York71
Identifier Renaming
getPayroll(int) --> a(int)getUser(String) --> b(String)addValue() --> c()delValue(float) --> d(float)
Overload Induction:getPayroll(int) --> a(int)getUser(String) --> a(String)addValue() --> a()delValue(float) --> a(float)
2007 Dr Benjamin Khoo, PhDNYIT, New York72
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
2007 Dr Benjamin Khoo, PhDNYIT, New York73
Control Flow Obfuscation● Decompilers must analyze control flow
to rebuild source statements
for
if x<0
y=y+1y=y-1
x++
if x<100
for
if x<0
y=y+1
y=y-1
x++
if x<100
goto
goto
goto
goto
2007 Dr Benjamin Khoo, PhDNYIT, New York74
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
2007 Dr Benjamin Khoo, PhDNYIT, New York75
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
2007 Dr Benjamin Khoo, PhDNYIT, New York76
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
2007 Dr Benjamin Khoo, PhDNYIT, New York77
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
2007 Dr Benjamin Khoo, PhDNYIT, New York78
SummaryAs defenders, software developers must
always be vigilant and work smart.
Security Principles to live by:1. Secure by Design, Default and Deployment
2. Learn from Mistakes
3. Minimize Your Attack Surface
4. Use Least Privilege
5. Assume External Systems are Insecure
6. Remember that Security Features != Secure Features
7. Never Depend on Security by Obscurity Alone
8. Fix Security Issues Correctly
9. Plan on Failure
2007 Dr Benjamin Khoo, PhDNYIT, New York79
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
2007 Dr Benjamin Khoo, PhDNYIT, New York80
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/SQLInjection/default.aspx
– MSFT article on SQL injection
2007 Dr Benjamin Khoo, PhDNYIT, New York81
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
2007 Dr Benjamin Khoo, PhDNYIT, New York82
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)
2007 Dr Benjamin Khoo, PhDNYIT, New York83
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
2007 Dr Benjamin Khoo, PhDNYIT, New York84
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
2007 Dr Benjamin Khoo, PhDNYIT, New York85
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 28:8, 735-746, August 2002– University of Arizona