Slide Heading
Ethical Hacking
Ed Chorbajian
Affinity Inc.
April 11, 2012
Introductions
• Affinity, Inc.
• http://affinityit.com
• IT services and solutions provider, helping Fortune
500 and growth companies
• Corporate Headquarters in Milwaukee, WI
• Ed Chorbajian
• echorbajian@affinityit.com
• New York, NY
• linkedin.com/in/edchorbajian
About Affinity, Inc.
About Affinity, Inc.
• Clients
About Ed Chorbajian
• Certifications
• CSSLP, GWAPT, CISSP, GPEN, GCIH, GSLC, SCJP
• Experience
• 5+ years Security
• 10 years Software Development
• Education
• MBA (80% complete) at New York University Stern
• MS in Computer Science
• BA in Mathematics and Physics
Agenda
Context
Static Analysis
Dynamic Analysis
Slide
Heading
Q&A
A Hacker is
• Someone who
• Finds information security vulnerabilities
• Exploits them
• (Black Hat)
An Ethical Hacker is
• Someone who
• Finds information security vulnerabilities
• Exploits them
• Has permission
• (White Hat)
Ethics
• Yes - “has permission” is a simplification
• Ethics describes right and wrong behaviors
• Our discussion today is not about ethics
Ethics
• Sometimes it depends on your point of view
• Hackers that made Stuxnet targeted Iranian
nuclear plants and probably delayed Iran’s
uranium enrichment program by two years
Find and Exploit Vulnerabilities
• SQL Injection humor
Find and Exploit Vulnerabilities
• SQL Injection humor
Find and Exploit Vulnerabilities
• SQL Injection humor
Find and Exploit Vulnerabilities
• SQL Injection humor
Find and Exploit Vulnerabilities
• SQL Injection – not so funny
• An attack targeting the victim’s data, database
and database server
• Data: possible to read, add, modify, delete
• Database: possible to drop tables, drop
indexes, create users, grant and revoke
privileges
• Database server: possible to mount further
attacks against the victim’s internal network
Partial List of Vulnerabilities
•
•
•
•
Injection
Cross-Site Scripting
Encryption implementation
Parameter Tampering
Partial List of Vulnerabilities
• Injection
• SQL Injection
• LDAP Injection
• XML Injection
• Code Injection
• OS Commanding
Partial List of Vulnerabilities
• Cross-Site Scripting
• Reflected Cross-Site Scripting
• Stored/Persistent Cross-Site Scripting
• DOM-based Cross-Site Scripting
Partial List of Vulnerabilities
• Encryption implementation
• Symmetric
• Asymmetric (Public/Private Key Cryptography)
• Password Hashes
• Key Management
Partial List of Vulnerabilities
• Parameter Tampering
• Business Logic Abuse
• Buffer Overflow
• Cross-Site Request Forgery
• Information Leakage
• Directory Traversal
• Authentication/Authorization
• Session Fixation
In the past …
• To defend your organization
• “You don’t need to outrun the bear in the
woods, just your neighbor”
• Be less insecure
than you neighbor
• Hackers attack
the easier targets
Today …
• Organizations are specifically targeted
• Hacktivists - political agenda
• Anonymous
Threat Agents
•
•
•
•
•
•
•
•
•
Unintentional/careless users
Non-professional hackers/script kiddies
Researchers
Professional hackers
Corporate/industrial espionage
Insiders/partners
Organized criminals
Hacktivists
Nation-state intelligence agencies
Today …
• Nation-state intelligence agencies
Source: http://www.mcafee.com/us/resources/reports/rp-virtual-criminology-report-2009.pdf
Today …
• Advanced Persistent Threat – APT
• Have large resources
• Have much patience
• Target specific organizations
• Purpose
• Intellectual Property
• Disruption
• Etc.
Today …
• Verizon 2012 Data Breach Investigations Report
•
•
March 22, 2012
(Larger Orgs are samples with at least 1,000 employees)
http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigationsreport-2012-press_en_xg.pdf
Today …
• Verizon 2012 Data Breach Investigations Report
• Hacktivists tend to target larger organizations
• High profile
• Motive is attention and publicity
• Denial of Service attacks
• Download and distribute secret information
• Website defacements
Today …
• Verizon 2012 Data Breach Investigations Report
• Organized criminals tend to target smaller
organizations
• Low profile
• Motive is money
• Smaller revenue - for each attack
• High volume - through many attacks
• Easier to exploit victims
Today …
• Verizon 2012 Data Breach Investigations Report
http://www.verizonbusiness.com/resources/reports/rp_data-breach-investigationsreport-2012-press_en_xg.pdf
Agenda
Context
Static Analysis
Dynamic Analysis
Slide
Heading
Q&A
Static and Dynamic Analyses
• Static - the source code
• Can see “everything”
• Dynamic - a running application
• See everything that is actually there, including
• Infrastructure
• Middleware
• Third-party libraries
• Actual source code used
Automated and Manual Techniques
• Automated Technique
• Use a tool that does much of the work
• Catches the more easily detected
vulnerabilities
• Manual Technique
• Use expertise to find vulnerabilities that the
tools cannot find on their own
• Do much of the work using many tools
Static Analysis
• Automated
• I personally worked with
• IBM Rational AppScan Source Edition for
Security (Ounce Labs)
• HP Fortify Static Code Analyzer
• Can scan 100,000s of lines of code
• Expensive tools
Process for Automated
• The client stages the source code:
• Complete source code that compiles/builds
without error
• Workspace and project files
• All dependencies
• SDLC documents
• The tools are ineffective when any required
component is missing
Process for Automated
• Inventory the source code
• Configure the tool
• Run the scan
• Could produce thousands of findings
• Analyze the results
Results of the Analysis
• Determine if each finding is a False Positive or a
True Positive
• Raise, lower or keep the suggested severities
• Critical
• High
• Medium
• Low
• Informational
Results of the Analysis
• Communicate the vulnerabilities to the client
• Provide recommendations on how to remediate
the security defects
• The client remediates the defects
• Available for assistance - includes explaining
in-depth technical questions on vulnerability
risks and remediation strategies
• Retest
True/False Positive/Negative
• False Positive – the tool found a security defect,
but it really is not a security defect
• The reason to vet the findings
• True Positive – the tool found a security defect,
and it really is a security defect
• The tool did its job
True/False Positive/Negative
• True Negative – the tool did not find the security
defect, and there is no security defect
• The tool did its job
• Not reported, but implied
• False Negative – the tool did not find the security
defect, but there really is a security defect
• The tool missed this
Manual Static Analysis
• Generally do a targeted search
• May not be practical to look at thousands or
millions of lines of code
• Examples
• Authentication/Authorization
• Encryption implementation
• Logging
• Output to web browser
Authentication/Authorization Example
• There was a backdoor in a client’s software
system, which was written by their vendor
• Hard-coded username and password
• Bypass normal authentication controls
• Unlimited access to the system
• Bypass normal authorization controls
• Logging turned off for this username
• Bypass normal auditing controls
Authentication/Authorization Example
• Vendor included the backdoor for convenience
• Support and maintenance
• In addition to this client, other organizations using
this vendor’s system had the same security issue
• With the same credentials!
Encryption Implementation Example 1
• Password hashes were not salted
• Cryptographic hash is a one-way function
• There are no encryption/decryption keys
• SHA-2
• Password is encrypted and is not feasible to
decrypt
Encryption Implementation Example 1
• How are password hashes utilized?
• When a user authenticates, the password is
hashed; then the result is compared to the
password hash stored in the database
• If a hacker get access to the password hashes
in the database, then they can use Rainbow
Tables to determine the password
• Pre-computed password hash values
Encryption Implementation Example 1
• Why is a salt necessary?
• A salt is value that is combined with the
password before being hashed
• The encrypted result is very different than
without the salt
• Preferably have a different salt for each user
Encryption Implementation Example 2
• Organization has encrypted credit card
information
• The encryption used AES-128 with the key
composed of two 8 character passwords
concatenated together
Encryption Implementation Example 2
• Normal use of AES-128
• Encryption key is 128 bits long
• 2^128 possible keys
• 300,000,000,000,000,000,000,000,000,000,000,000,000
• To guess the key, divide by 500,000 tries/sec
• (These days, over 2,000,000 tries/sec)
• Then again divide by 86,400 sec/day
• Divide by 100 (for a 1% chance of success)
• Trillions of years is still not remotely close
Encryption Implementation Example 2
• Normally use of AES-128
• 128 bits = 16 chars x 8 bits/char
• Each char has 2^8 = 256 possibilities
• Range from ’00’ to ‘FF’
• Hexadecimal notation
• 256^16 = (2^8)^16 = 2^(8*16) = 2^128
Encryption Implementation Example 2
• Normal use of AES-128
• Example key in Binary notation:
• 00011110001011010110101000011000011
00001010000111000110111010110011011
00101011101111011100010001011111001
11110010001001101111010
• Same key as 16 chars Hexadecimal notation:
• 1E2D6A1861438DD66CAEF7117CF9137A
Encryption Implementation Example 2
Encryption Implementation Example 2
Encryption Implementation Example 2
• Passwords consist of the 94 keyboard printable
characters
• ‘A’ through ‘Z’
• ‘a’ through ‘z’
• ‘0’ through ‘9’
• 32 symbols (not including SPACE)
• Hexadecimal ‘21’ through ‘7E’
Encryption Implementation Example 2
• A password type key reduces the key space from
256 possibilities to 94, for every char
• The effective key length changes from 128 to
105
• Moreover, user chosen 16-character passwords
has a randomness (entropy) of at best 38 bits
Encryption Implementation Example 2
http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
Encryption Implementation Example 2
•
•
•
•
•
2^38 bits = 274,877,906,944 possibilities
To guess the key, divide by 500,000 tries/sec
Then again divide by 86,400 sec/day
Divide by 2 (for 50% chance of success)
Result is on average the encryption key can be
cracked in 3 days
Encryption Implementation Example 2
• Better recommendation for client:
• Use AES-256
• Use hexadecimal instead of char
• Use two 32 chars XOR’ed together
Logging Example
• Failed credentials were logged
• If a user’s password was “ihearthacking7”
• And the user changed it to “ihearthacking8”
(not recommended to increment numbers)
• And at the next login the user mistakenly
entered the old password
• Easy for a hacker viewing the log to guess the
user’s current password
Output to Web Browser Example 1
• There was a first scan that found no output
encoding, thus very vulnerable to Cross-Site
Scripting
• Developers remediated defects
• Wrapped output with HTMLEncode everywhere
• The rescan found no issues
Output to Web Browser Example 1
• What is Cross-Site Scripting?
• An attack conducted through a vulnerable
website to the victim’s browser
• It allows an attacker to insert client-side script
in the browser
• The script can
• Deface the website
• Steal the session
• Redirect the victim to another website
Output to Web Browser Example 1
• What does HTMLEncode do?
• Less-than character (<) is converted to &lt;
• Greater-than character (>) is converted to &gt;
• Ampersand character (&) is converted to
&amp;
• Double-quote character (") is converted to
&quot;
• Thus, <script> is converted to &lt;script&gt;
Output to Web Browser Example 1
• But looking through the code, there was a sortable
HTML table written in JavaScript
• Output for ascending or descending was in the
<script> portion of the code
• HTMLEncode would not prevent Cross-Site
Scripting in this context
• Straightforward solution:
• If “ASC” then sort ascending
• Otherwise sort descending
Output to Web Browser Example 2
• Weak Cross-Site Scripting filtering
• Custom security library
• If code saw “<script>” or “</script>”, it just
removed it
• Example:
• Data1<script>MaliciousCode</script>Data2
• This code’s result:
• Data1MaliciousCodeData2
Output to Web Browser Example 2
• Unfortunately, a hacker can use:
• <scr<script>ipt>
• Thus, this code’s result:
• <script>
• ha.ckers Cross-Site Scripting Cheat Sheet
• Especially for filter evasion
• http://ha.ckers.org/xss.html
Agenda
Context
Static Analysis
Dynamic Analysis
Slide
Heading
Q&A
Dynamic Analysis
• Specifically, Web Application Penetration Testing
• Types:
• Black Box
• White Box
• Grey Box
Black Box
• Zero knowledge of the system beforehand
• Other than what is the target
• More realistic test (what an attacker would
experience)
• Unless the attacker is an insider
White Box
• Given knowledge of the system from the client
• Documents
• Source code
White Box
• More realistic test (in terms of resource allocation)
• Can find more vulnerabilities in a shorter time
frame
• Hiring dozens of expert ethical hackers at 8
hours/day trying for 5 years is prohibitive for
most budgets
Grey Box
• Given some knowledge of the system from the
client
• Documents?
• Source code?
Rules of Engagement
• Scope
• Anything to specifically focus on
• Anything to specifically avoid
• Time frames
• 2 weeks or 4 weeks or …
• Days/nights
• Weekdays/weekends
• Provide the client with source IPs
• To differentiate from a real attack
Permission Memo
•
•
•
•
Explicit, written and signed
Names of testers
Start and end dates
Contact information
Environment
• QA/test Environment
• Safer
• Data corruption
• Denial of Service
• Production Environment
• Real – what hackers see
• Testing may impact experience of the client’s
customers
Tools
• SecTools.Org
• List of the top 125 network security tools
• http://sectools.org
• BackTrack
• Pen Testing Distribution
• http://www.backtrack-linux.org
Tools
• Samurai Web Testing Framework
• Pen Testing Distribution
• Focused on
Web Applications
• http://www.samurai-wtf.org
Process Overview
• Research
• Gather information from external sources
• Gather Information from Web Application
• Find and exploit vulnerabilities
• Report findings
• Remediation by client
• Retest
Research
• Gather information from external sources
• Whois records
• Names
• Emails
• Phone numbers
• http://networking.ringofsaturn.com/Tools/whois.php
Research
• Gather information from external sources
• Google hacking
• site:theTargetWebsiteOfTest.tdl
• inurl:phpinfo
• intitle:“admin login”
• ext:xls
• groups.google.com
• insubject:"problem with my code“
• author:@theTargetWebsiteOfTest.tdl
Research
• Gather information from external sources
• Press releases
• Including vendors/partners
• Job postings
• Technologies and versions
• Linkedin profiles
• Facebook
• Twitter
• Blogs
Research
• Gather Information from Web Application
• Spider to follow links and download entire site
• Wget
• http://www.gnu.org/software/wget/
Research
• Wget
Research
• Wget
• After downloading the client’s website
• Look at all the images
• Menu graphics may reveal parts of the
site that some users do not have access
• Information leakage
Research
• Gather Information from Web Application
• Forced browsing – find pages and resources
that are not found through following links
• DirBuster
• https://www.owasp.org/index.php/Category:OWASP_DirBuster_Pr
oject
• Comes with a sorted (by popularity) word list
• small.txt: 88,000 words, dirs/files found >2 hosts
• medium.txt: 221,000 words, dirs/files found >1 host
• big.txt - 1,274,000 words, all dirs/files found
Research
• DirBuster
Research
• DirBuster examples:
• Find backup files
• index.php.bak
• It found a PHP include file, thus having the
PHP source code, and the credentials coded
within
• File’s permissions were set to world
readable
Research
• Gather Information from Web Application
• Word list generator
• CeWL
• http://www.digininja.org/projects/cewl.php
• Can be helpful for username/password
guessing
Research
• CeWL
Research
• Gather Information from Web Application
• View the web page’s HTML source code
• Internet Explorer: Page -> View source
• Firefox: View -> Page Source
• Read the comments for any interesting
information
• Usernames
• Passwords
• “TO DO: add security”
Find and Exploit Vulnerabilities
• Automated tool
• w3af
• Web Application
Attack and
Audit Framework
• http://w3af.sourceforge.net
Find and Exploit Vulnerabilities
• Examples
• Authentication
• Authorization
Find and Exploit Vulnerabilities
• Authentication example
• My home router - wanted to configure WiFi
• Own WPA-2 hexadecimal password
• MAC filtering
• Configured Hydra for router’s login webpage
• Online password cracker
• In about 2 hours, it found the password for the
admin account
• http://thc.org/thc-hydra/
Find and Exploit Vulnerabilities
• Hydra
Find and Exploit Vulnerabilities
• Authorization example
• Automated tool did not find any vulnerabilities
• Use an interception proxy – Burp
• Intercepts requests before they reach the
browser
• Intercepts responses after they leave the
browser
• http://portswigger.net/burp/proxy.html
Find and Exploit Vulnerabilities
• Authorization example
Find and Exploit Vulnerabilities
• Authorization example
• The application allowed users to view their
salary information
• After authenticating
• Changed assigned user ID before the
browser sent the response to the server
• Can now view anyone's salary
Questions?
Thank you