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