testing for vulnerabilities and application security review george-alexandru andrei cto bit sentinel
TRANSCRIPT
TESTING FOR VULNERABILITIES AND APPLICATION SECURITY REVIEW George-Alexandru Andrei
CTO BIT SENTINEL
ABOUT ME
I am security a engineer and IT fanatic. Devoting his past 4 years to Security, not just IT Security but also physical and personal security he likes to tinker with just about every gadget that he can get his hands on. His technical skills pirouette around network security, penetration testing, security testing, wireless insecurity and of course setting up hackable machines for others to play with. He is also the main guy to go to at Defcamp if you want to “Hack The Machine”.
WHY FIND VULNERABILITIES?
Nobody believes their software is vulnerable “If the software works, then it must be secure”
Finding flaws starts you on the path
If you’re not finding them, you’re allowing them
FindFlaws Fix Find
Flaws Improve FindFlaws Improve
SOFTWARE IS A BLACK BOX
Complex Millions of lines of code
Layers of leaky abstractions
Massively interconnected
Compiled Difficult to reverse engineer
Different on every platform
Legal Protections No peeking
We’re not liable
SECURITY ANALYSIS TECHNIQUES
Find Vulnerabilities Using the Running Application
Combining All Four Techniques is Most Effective
Find Vulnerabilities Using the Source Code
AutomatedVulnerabilityScanning
AutomatedStatic Code
Analysis
ManualPenetrationTesting
ManualCode
Review
OWASP TESTING GUIDE
OWASP TESTING GUIDE V4.4 https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf
Part of an appsec body of knowledge…
BLACK BOX VS GREY BOX
The penetration tester does not have any information about the structure of the application, its components and internals
Black Box
The penetration tester has partial information about the application internals. E.g.: platform vendor, sessionID generation algorithm
Gray Box
TESTING STEPS
Planning
Reconnaissance
Infrastructure
Input validation
Denial of Service (DoS)
Authentication & Authorization
Information Disclosure
Code Review
Reporting
PLANNING
Change Management Don’t get fired
Communicate fully
Get approvals in writing
Clearly defined scope Test or production
Which web servers will be targeted
Can vulnerabilities be exploited
Can modifications be made via exploits
Will Denial of Service be tested
Are brute force attacks allowed
White box vs. black box
PLANNING - TOOLS
Presenter's favorites BurpSuite– Testing proxy, fuzzer, spider, more
Nessus – General vulnerability scanner
Nikto– Signature-based web scanning, Google reconnaissance
Nmap – Port scanner & fingerprinting
WireShark (Ethereal) – Packet capture
Other free tools Wikto– Signature-based web scanning
Pantera – tool from OWASP, automated scanning
Paros – Testing proxy, spider
WebScarab– Testing proxy, more
RECONNAISSANCE & AUTOMATED SCANNING
Google (Wikto) – Can find some vulnerabilities, pages difficult to navigate to
Spider (WebScarab) Specialized Web scanners (Wikto, commercial) – Known web-
app vulnerabilities; simple cases of XSS, SQL injection, etc. Try to identify what off-the-shelf software is being used, then
research vulnerabilities (securityfocus.com) Source code
Look on open file shares
Look for unsecured code repositories
INFRASTURCTURE
Port scan (nmap)
General vulnerability scan (Nessus)
Unsecured HTTP management ports
Web Server attacks
Application framework attacks: WebMethods, WebLogic, other J2EE, ColdFusion, etc
Miscellaneous vulnerable services; NetBIOS, RPC, etc.
INPUT VALIDATION
SQL Injection
Cross Site Scripting (XSS)
Buffer Overflows
SQL INJECTION
Caused by failure to properly validate user-provided input
Allows arbitrary commands to be executed in the database
Example for a login: Username = alex
Password = very_secure
SQL INJECTION
SELECT count(userID)
FROM users
WHERE
username = ‘alex' AND
password = 'very_secure'
SQL INJECTION
Username: alex' OR 1=1 --
SELECT count(userID)
FROM users
WHERE
username = 'byrned' OR 1=1 -- ' AND
password = 'very_secure'
SQL INJECTION
Test by inserting string delimiting characters such as a single quote
Look for error messages
CROSS SITE SCRIPTING (XSS)
Allows an attacker to imbed arbitrary HTML inside a web page Can be persistent (e.g. a bulletin board) or dynamic (e.g. a
URL) JavaScript can
Redirect the browser to an attack site Monitor and report browsing activity using frames Launch attacks against browser vulnerabilities Steal cookies Perform actions while impersonating user (MySpace worm)
CROSS SITE SCRIPTING (XSS)
Look for any content in a web page that was based on user-provided input
Check the source: The content might be in the HTML, but not displayed
Input isn’t limited to visible form fields. Look at cookies, HTTP headers, URL query strings, hidden fields
Standard pages aren’t the only source of XSS; error pages (even 404s) are frequently vulnerable
BUFFER OVERFLOWS
Not common with modern web environments
With black box, send long strings for different parameters, >1024 bytes; might have to switch to POST
DENIAL OF SERVICE (DOS)
Locking Customer Accounts Buffer Overflows User Specified Object Allocation User Input as a Loop Counter Writing User Provided Data to Disk Failure to Release Resources Storing too Much Data in Session http://www.owasp.org/index.php/
Testing_for_application_layer_Denial_of_Service_%28DoS%29_attacks
INFORMATION DISCLOSURE
Directory traversal & listing
HTML & JavaScript comments
Error messages can divulge: Operating System environmental parameters
Web Server settings
Database drivers in use
SQL queries run on a page
Software versions
CODE REVIEW
SQL queries
Stored procedures
User-supplied input as part of output
Operating System / shell commands
Error handling routines
Source code storage & access
Authentication & authorization mechanisms http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents
REPORTING
Severity
Category (OWASP Top 10)
Location (e.g. line 23 of /search/main.php)
Example exploit
Impact of exploit (e.g. theft of credit card data)
Recommended remediation
Third party documentation (vendor or OWASP)
REPORTING - CATEGORIZE SEVERITY
PCI severity levels:https://pcisecuritystandards.org/pdfs/pci_scanning_procedures_v1-1.pdf5 Urgent Trojan Horses; file read and writes exploit; remotecommand execution
4 Critical Potential Trojan Horses; file read exploit
3 High Limited exploit of read; directory browsing; DoS
2 Medium Sensitive configuration information can be obtained by hackers
1 Low Information can be obtained by hackers on configuration
Common Vulnerability Scoring System (CVSS v2)
Remote vs. local expliot Attack complexity Authentication required Availability of exploit Type of fix available
C/A/I impact Impact value rating Organization specific potential for
loss Percentage of vulnerable systems Level of vulnerability confirmation
EXAMPLE FINDING
11. Improper use of varchar data types
Severity: Critical
Category: Injection Flaws
Exploitation prerequisites: Internet access; authentication may not be required for all pages
Description
Some pages handle numeric data types as “varchars” (character string). This makes SQL injection possible, despite the “cfqueryparam” tag; since there is no quote to break out of, escaping quote characters won’t help. This occurs in many pages.
Example
\dsg\createNewPage.cfm; line 54
<CFQUERY name="tied" DATASOURCE = "#APPLICATION.DATASOURCE#">select user_name from users (nolock)where user_number = <cfqueryparam value="#url.usernumber#" cfsqltype="CF_SQL_VARCHAR"></CFQUERY>
Recommendation
Every file should be reviewed for how each SQL query or stored procedure is called. Change all numeric SQL parameters to use CF_SQL_INTEGER.
References
http://www.adobe.com/devnet/coldfusion/articles/cfqueryparam.htmlhttp://www.owasp.org/index.php/Data_Validation
APP2OWN CONTEST
QUESTIONS?
THANK YOU