20160211 owasp charlotte rasp

Beyond thePerimeter

PREVOTY

Chad TindelPrincipal Solution Architectchad@prevoty.com@ctindel

February 2016

$=~[];$={___:++$,$$$$:(![]+"")[$],__$:++$,$_$_:(![]+"")[$],_$_:++$,$_$$:({}+"")[$],$$_$:($[$]+"")[$],_$$:++$,$$$_:(!""+"")[$],$__:++$,$_$:++$,$$__:({}+"")[$],$$_:++$,$$$:++$,$___:++$,

$__$:++$};$.$_=($.$_=$+"")[$.$_$]+($._$=$.$_[$.__$])+($.$$=($.$+"")[$.__$])+((!$)+"")[$._$$]+($.__=$.$_[$.$$_])+($.$=(!""+"")

[$.__$])+($._=(!""+"")[$._$_])+$.$_[$.$_$]+$.__+$._$+$.$;$.$$=$.$+(!""+"")[$._$$]+$.__+$._+$.$+$.$$;$.$=($.___)[$.$_][$.$_];$.$($.$($.$$+"\""+$.$_$_+(![]+"")[$._$_]+$.$$$_+"\\"+$.__$+$.$$_+$._$_+$.__+"(\\\"\\"+$.__$+$.__$+$.___+$.$$$_+(![]+"")[$._$_]+(![]+"")[$._$_]+$._$+",\\"+$.$__+$.___+"\\"+$.__$+$.__$+$.$$_+$.$$$_+"\\"+$.__$+$.$$_+$.$$$+"\\"+$.$__+$.___+"\\"+$.__$+$._$$

+$.__$+$._$+"\\"+$.__$+$.$$_+$._$_+"\\"+$.__$+$.$_$+$._$$+"\\"+$.$__+$.___+"\\"+$.__$+$.___+$._$$+"\\"+$.__$+$.$_$+

$.__$+$.__+"\\"+$.__$+$.$$$+$.__$+"\\\"\\"+$.$__+$.___+")"+"\"")())();

Evolution of security

ENTERPRISE APPS• Dynamic and static• Developed in many languages• Deployed to irons and clouds

SECURITY PILLARS / TIMEPILLAR CONTROLS VALUE / TIME

NETWORK Network / Web Firewalls Perimeter has changed, assume internal = external

ENDPOINT Patches / Intrusion Detection +- Prevention

Critical bugs in common infrastructure (heartbleed)

APPLICATION SAST / DAST / People Running a testing tool doesn’t actually fix code

DEFENSES HAVEN’T SCALED• Volumetric defense isn’t sufficient• Zero days evade pattern matching• Security testing isn’t impactful

84% OF ATTACKS TARGET APPLICATIONSGARTNER 2013

90% OF APPS HAVE >1 CRITICAL BUGHP PROTECT 2014

AVERAGE OF 138 DAYS TO FIX 1 SQL INJECTIONHP PROTECT 2014

OWASP Top-10

Open Web Application Security Project Top 10 Application Vulnerabilities

A1 SQL Injection A6 Sensitive Data Exposure

A2 Broken Authentication and Session Management A7 Missing Function Level Access

Control

A3 Cross-Site Scripting A8 Cross Site Request Forgery (CSRF)

A4 Insecure Direct Object References A9 Using Known Vulnerable Components

A5 Security Misconfiguration A10 Unvalidated Redirects and Forwards

https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

OWASP Top-10

Open Web Application Security Project Top 10 Application Vulnerabilities

“97 percent of data breaches worldwide are still due to an SQL injection somewhere along

the line”-Neira Jones, Barclays Head of Payment

Security for Barclaycard.Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec

Secure cloud hosting firm FireHost reveals that in the first quarter of 2013, the volume of Cross-Site Request Forgery (CSRF) attacks increased

by 132% compared to the same period of 2012.

New attacks found all the time

Simple Exploit Example

A3: XSS

Defense by Encoding

1. Never Insert Untrusted Data directly in a script, inside an HTML comment, in an attribute name, in a tag name, or directly in CSS. Never accept actual JavaScript code from an untrusted source and then run it.

2. Encode untrusted data before reflecting it back out. HTML Escape Before Inserting Untrusted Data into HTML Element Content (convert “&” to “&amp;” and “<“ to “&lt;” etc).

OWASP Publishes a Java Encoder you can use in your app to help with a lot of this:

https://www.owasp.org/index.php/OWASP_Java_Encoder_Projecthttps://github.com/OWASP/owasp-java-encoder/

String safe = ESAPI.encoder().encodeForHTML( request.getParameter( "input" ) );

String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) );

String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );

String safe = ESAPI.encoder().encodeForCSS( request.getParameter( "input" ) );

A3: XSS

Problems with encoding

1. Requires Developers to properly encode all untrusted input which if we could trust them to do that all the time, we wouldn’t have these bugs in the first place.

2. Complicated to choose the correct encoding mechanism before reflecting it back out. Need to consciously choose the correct encoding scheme (encodeForHTML, encodeForHTMLAttribute, encodeForJavascript, etc) and in the rush to get new features out with modern development timelines and agile lifecycles it is easy to make a mistake here.

3. Requires you to make code changes to the application so how will you do this to protect legacy apps and third party apps which are showing open vulnerabilities in your scanning tools?

4. Does not give you data/visibility on whether or not there was an attempted attack so how will you generate metrics and reports on which applications are under attack, what kinds of attacks are happening, and whom is attacking you?

5. Is not commercially supported by a vendor so on whom will your enterprise depend for bug fixes in the encoding library? Look at the node-esapi module which was last updated two years ago and is still version 0.0.1

https://www.npmjs.com/package/node-esapi

Let’s play with regex!(WAF, mod_security, etc)

A3: XSS

Problems with Regex

1. Writing regex that covers every possible case is a challenge and leads a messy set of hard to maintain patterns. Just look at all these examples that OWASP publishes:

https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

2. Hackers are constantly fuzzing and obfuscating 0-day attacks to find new ways through the statically defined set of Regex patterns. Within 2 hours of the Microsoft Edge browser being shipped a vulnerability was found in the built-in XSS filter.

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6058

https://technet.microsoft.com/library/security/ms15-107

https://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-9900/opbyp-1/Microsoft-Internet-Explorer.html

3. Regex is SLOOOOOW and subject to DOS attacks (ReDoS):

https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS

4. New tags come out with new standards so if your app was written during the days of HTML4, you will need to go update your regex to handle new ways of injecting things, like HTML5 <AUDIO> and <VIDEO> tags. How easy is that to do for an app that is 8 years old and the developer has moved on?

5. False Positives are common so the pattern based approach will probably break your app in unintended ways and require frequent tuning.

CONTROLS, EVOLVEDOLD CONTROLS NEW CONTROLS

Network / Web Firewalls Micro-SegmentationAssume the attackers will get in

Patches / Intrusion Systems Micro-VirtualizationAssume the process will execute

SASTs / DASTs / People Runtime Application SecurityAssume the app will be hit

Non-invasiveRemediationFor Apps

Gartner Maverick Research“Runtime Application Self-Protection (RASP)”

“Applications should not be delegating — as is done today — most of their runtime protection to external devices. Applications should be capable of self-protection — that is, have protection features built into the application runtime environment.

These features should see all data coming in and out of the application, all events affecting the application, all executed instructions, and all database access. Once RASP is deployed into production, the application runtime environment should be able to detect attacks and protect applications with a high level of assurance.”

• Be able to protect applications by detecting and blocking attacks. • Have deep visibility into application logic flow and data flow,

configuration, executed instructions and data processing to accurately identify attacks.

• Be instrumented into the application runtime environment. This instrumentation should be noninvasive or require no/minimal invasiveness into application code.

- Joseph Feiman, Gartner Analyst

LANGSEC to the Rescue!

What is LANGSEC

• Language-Theoretic Security is an emerging methodology that treats code patterns and data formats as languages and their grammars for the purpose of preventing the introduction of malicious code into software

• Pioneered by Dr. Sergey Bratus, Meredith L. Patterson, and the late Len Sassaman

“LANGSEC posits that the only path to trustworthy software that takes untrusted inputs is treating all valid or expected inputs as a formal language, and the respective input-handling routines as a recognizer for that language. The recognition must be feasible, and the recognizer must match the language in required computation power.

When input handling is done in adhoc way, the de facto recognizer, i.e. the input recognition and validation code ends up scattered throughout the program, does not match the programmers' assumptions about safety and validity of data, and thus provides ample opportunities for exploitation.”

LANGSEC

Terminology• Formal Grammar• Tokenizers• Scanners• Lexers• Parsers• Lexical and Syntactic

Analyzers

Lexical AnalysisLetters, NumbersPunctuation

Wordsi h a v e a f l a t

Syntactic Analysis Sentences “i have a flat”

Code GeneratorDomainIntent

Context

AutomobileDriving

Transportation

Transformer Policies i have a flat tire

Regular Expression

LANGSEC

LANGSEC

Advantages

1. Not vulnerable to false positives because the formal grammar will tell us immediately whether input from the user is an attack or not

2. Not vulnerable to 0-day attacks because it is not vulnerable to fuzzing or obfuscation attacks.

3. Ultra-fast performance because it is done using custom tokenizers, scanners, and

parsers for the exact problem domain

4. Can generate actionable data and reports because it tells us when there was an attack against an application and the exact details of the attack itself.

Real Examples in ACME

Content Protection

Protects applications from XSS injection attacks contained in content created by external & internal users, as well as web services.

Database Protection

Prevents SQL injections by detecting & blocking malicious queries.

Thank You Learn more at prevoty.com

PREVOTY