2007 Dr Benjamin Khoo, PhD NYIT, New York 1 Security 101 An Overview of Security Issues in Application Software Benjamin Khoo, PhD New York Institute of Technology School of Management

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 3 Agenda Understanding the Basics Introduction Security Issues Application Security Security Through Obfuscation Summary

2007 Dr Benjamin Khoo, PhD NYIT, New York 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.

2007 Dr Benjamin Khoo, PhD NYIT, New York 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.

2007 Dr Benjamin Khoo, PhD NYIT, New York 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. – (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, PhD NYIT, New York 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.

2007 Dr Benjamin Khoo, PhD NYIT, New York 8 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 Area Changes 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, PhD NYIT, New York 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 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 SYSTEM APPLICATION SECURITY `96 - Present Beginning ` 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, PhD NYIT, New York 10 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, PhD NYIT, New York 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 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, PhD NYIT, New York 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).

2007 Dr Benjamin Khoo, PhD NYIT, New York 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 other ’ s identity. – The transaction records must be in a form that will hold up in a court of law.

2007 Dr Benjamin Khoo, PhD NYIT, New York 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.

2007 Dr Benjamin Khoo, PhD NYIT, New York 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 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 came from a friend and got through the virus check, so why can’t I click on it?”

2007 Dr Benjamin Khoo, PhD NYIT, New York 16 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, PhD NYIT, New York 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 there’s no mandatory audit requirement. – There are solutions (e.g. CitiCard single-use numbers)

2007 Dr Benjamin Khoo, PhD NYIT, New York 18 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, PhD NYIT, New York 19 No Program is an Island

2007 Dr Benjamin Khoo, PhD NYIT, New York 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: hours – 4 people, each trying ¼ the codes: hours – 10,000 people, each trying 1 code: 2 seconds

2007 Dr Benjamin Khoo, PhD NYIT, New York 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?

2007 Dr Benjamin Khoo, PhD NYIT, New York 22 Risk Assessment A simplistic quantitative model SLE = AV x EF SLE: Single Loss Expectancy AV: Asset Value EF: Exposure Factor ( %) 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,

2007 Dr Benjamin Khoo, PhD NYIT, New York 23 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, PhD NYIT, New York 24 Security Attacks On the Rise

2007 Dr Benjamin Khoo, PhD NYIT, New York 25 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 Network 75 percent of hacks happen at the application

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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 …

2007 Dr Benjamin Khoo, PhD NYIT, New York 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)

2007 Dr Benjamin Khoo, PhD NYIT, New York 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 compared to (Meta Group,January 2002)

2007 Dr Benjamin Khoo, PhD NYIT, New York 30 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, PhD NYIT, New York 31 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, PhD NYIT, New York 32 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, PhD NYIT, New York 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 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, PhD NYIT, New York 34 Entry points are everywhere Application Under Test OS User Input files Libraries/ network Login screens Web forms Custom clients … Exec. content Remote files Corrupt files Secret content … Missing/Trojaned libraries Corrupt packets Bandwidth attacks RPC/Web Services … Resource starvation Secret content …

2007 Dr Benjamin Khoo, PhD NYIT, New York 35 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, PhD NYIT, New York 36 Proactive Security Development As 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, PhD NYIT, New York 37 When Hackers Attack why? Monetary Denial of Service/Publicity – Spammers – Extortionists Eavesdropping ($$$) Intellectual Property/Idea Theft Script Kiddie fame Black Hat

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 39 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, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 41 Vulnerability Network Interface Application Client Interface Reverse- engineering interactional

2007 Dr Benjamin Khoo, PhD NYIT, New York 42 Networked/Interactional Application Security

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 45 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, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 47 Network Security Port Scan – nmap -sS -v -p /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, PhD NYIT, New York 48 Network Security Packet Sniffing – Ethereal, Sniffit, Tcpdump Packet Spoofing Wardriving – Netstumbler WEP Cracking – Airsnort

2007 Dr Benjamin Khoo, PhD NYIT, New York 49 Application Security Access to the source

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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?

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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)

2007 Dr Benjamin Khoo, PhD NYIT, New York 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?

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 59 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, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 64 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, PhD NYIT, New York 65 Code Obfuscation Java/.NET source compiler Classes/ assemblies decompiler VM Execute

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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?

2007 Dr Benjamin Khoo, PhD NYIT, New York 69 Code Obfuscation simple goal Java/.NET source compiler Classes/ assemblies decompiler VM Execute obfuscator Munge, munge, munge,...

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 71 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, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 73 Control Flow Obfuscation ● Decompilers must analyze control flow to rebuild source statements for if x<0 y=y+1 y=y-1 x++ if x<100 for if x<0 y=y+1 y=y-1 x++ if x<100 goto

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 78 Summary As 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, PhD NYIT, New York 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

2007 Dr Benjamin Khoo, PhD NYIT, New York 80 References Preemptive Solutions, Inc. – – Code Security whitepapers, demos, etc. – Many Javascript injection attacks /SQLInjection/default.aspx – MSFT article on SQL injection

2007 Dr Benjamin Khoo, PhD NYIT, New York 81 References Chkrootkit - – Linux based rootkit detector RK Hunter - – Linux based rootkit detector Airsnort - airsnort.shmoo.org – Linux WEP cracker Airmagnet - – Windows wireless net finder

2007 Dr Benjamin Khoo, PhD NYIT, New York 82 References Dasho-Pro - – 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, PhD NYIT, New York 83 References Reflector - –.NET decompiler (any language) Dotfuscator - –.NET Code security tool – Community Edition included in VS Preemptive Demos – html – Flash demos of SQL injection, reverse-engineering, license check bypass

2007 Dr Benjamin Khoo, PhD NYIT, New York 84 References – Cracks for most games – Cracking tutorials, cracks, tools – SoftIce debugger (aka cracking tool) – Port knocking article

2007 Dr Benjamin Khoo, PhD NYIT, New York 85 References “Writing Secure Code”, Howard/Leblanc, Microsoft Press, ISBN – Excellent Reference “Decompiling Java”, G.Nolan, Apress, ISBN – 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, , August 2002 – University of Arizona