Why WAPPLES?

2009. 7. 21

Originality (1/3)

In Korea,WAPPLES holds#1 WAF market share 、over 60%!!

COCEP EngineperformsLogic Analysis+Positive/negativeSecurity by rules

Higher Security Levelex) Can detect altered/unknown attacks

Strong PointsFundamentally Unique Concept

Ease of Useex) No need for manual update

Misdetection to 0%

WAPPLES

Pattern matchingbased on IPS/Network engine

Cannot detect altered/unknown attack

High cost to maintainex) security level is in proportion to the number of patterns

Possibility for misdetectionMisdetection can cause service suspension

Other WAFs

WAPPLES versus other Web Application Firewalls(WAFs)

2/12

Originality (2/3)

WAPPLES is FUNDAMENTALLY DIFFERENT!

After gaining extensive experience in developing IDS, Penta has found some critical weak points in the pattern matching method:

• Misdetection and impossible deployments • Management difficulties

In order to overcome these weak points, a whole new architecture with higher security level, lower managing cost, and no misdetection was developed.

WAPPLES has a unique Logic Analysis Engine (COCEP engine) to detect web attacks.(WAPPLES also supports pattern methods with COCEP engine in order to meet customers’ desire)

3/12

Originality (3/3)

COCEP Engine(Logic Analysis Engine) Diagram

4/12

Features

Strong points of Logic Analysis against Pattern Matching

Higher Security Extremely low possibility of false positive

Accurate detection against modified attacks.

Higher Performance No additional system load by inputting new patterns.

Generally, more than 3000 patterns lead to low system performance.

No difference in performance, in both test environment and real operation environment.

Ease of Use and Less Maintenance Installation without(or with minimal) changes in server and network settings is possible.

Extremely little managing burden of administrator.

Low operation cost – receives not signature update service but S/W update service.

5/12

COCEP Engine Process – SQL Injection Rule

WAPPLES’s SQL Injection Rule acts as below.

(1) Inspect whether there is any SQL reserved word

(2) Check SQL phrase including the reserved word in step (1) is appropriate to SQL grammar

(3) Evaluate whether the SQL phrase is effective as a attack

Ex) SQL phrase including meaningless bypass code like [aaa’ or ‘1’=’1]

SQL phrase accessing vulnerable procedures or functions

Positive Effects WAPPLES can detect an infinite number of modified SQL injections.

WAPPLES does not need a new pattern if only attack is the same type.

Just because SQL phrase include a few SQL reserved words, WAPPLES does not judge it an attack.

Extremely low possibility of false positive

6/12

COCEP Engine Process – Suspicious Access Rule

WAPPLES’s Suspicious Access Rule acts as below.

(1) Send back validation request(HTTP request) to suspicious client accessing to web server

(2) Deny the client’s access, when it reply abnormal response.

Validation request is needed to check the client’s capability for HTTP manipulation.

- Whether it can understand HTTP request header or not

- Whether it can process(create, update, and so on) a cookie or not

- Whether it can send a response for HTTP status request

Positive Effects WAPPLES can detect an unknown robot or scanner without adding new patterns.

7/12

COCEP Engine Process – 3 Contents Filtering Rules

WAPPLES has 3 contents filtering rules against privacy leakage; Privacy input filtering

Privacy output filtering

Privacy file filtering

These rules inspect http message not by simple pattern matching, but by evaluation of message data.

They can identify credit card number, e-mail, mobile number, bank account number, address and so on.

Ex) For credit card number, validate checksum by Luhn algorithm(ISO/IEC 7812-1:2006).

Positive Effects Accurate detection and control of privacy data

WAPPLES can detect various type of privacy data (High extensibility)

8/12

Example of False-Positive and Misdetection (1/5)

Signature(Patterns) Sample related to SQL Injection Ex) In case that a HTTP message includes string “… having a good time. Seoul ==> Tokyo …”

Limitation

• The use of the ‘having‘ is common in a Website. The regular expression that detects “the having” results in too many false positives.

Signature Signature Name

part="openquery", rgxp="select.*from.*openquery" SQL Injection 1

part="openrowset", rgxp="select.*from.*openrowset" SQL Injection 2

part="waitfor", rgxp="[^a-zA-Z]waitfor\s*delay" SQL Injection  - Waitfor

part="having", rgxp="[^A-Za-z]having[^\&]{0,20}=[^\&]{0,20}"

SQL Injection - "having" statement injection attampt

part="opendatasource", rgxp="select.*from.*opendatasource" SQL Injection - opendatasource

part="openquery", rgxp="select.*from.*openquery" SQL Injection - openquery

part="openrowset", rgxp="select.*from.*openrowset" SQL Injection - openrowset

part="syscolumns", rgxp="select.*from.*syscolumns" SQL Injection - SQL server administrative objects

This is a selection of signatures from Product ‘S’ of Company ‘I’ .Below ‘part’ means substring-searching target and ‘rgxp’ means a regular expression describing a certain amount of text.After finding a string of ‘part’, ‘rgxp’ is applied.

9/12

Example of False-Positive and Misdetection (2/5)

Signature Sample of ‘SQL Injection WHERE Statement Manipulation’ Ex) In case that a HTTP message includes string “or ‘b’=‘b”

Limitation

• If SQL Injection source is modified from ‘a’=‘a’ to ‘b’=‘b’, the regular expression cannot detect the modified SQL Injection attack.

Signature Signature Name

part="or 'a' = 'a" SQL Injection WHERE Statement Manipulation

part="or 'a'= 'a" SQL Injection WHERE Statement Manipulation 1

part="or 'a'= 'a" SQL Injection WHERE Statement Manipulation 2

part="or 'a'='a" SQL Injection WHERE Statement Manipulation 3

part="or 'a' ='a" SQL Injection WHERE Statement Manipulation 4

part="or 'a'='a" SQL Injection WHERE Statement Manipulation 5

part="or 'a' ='a" SQL Injection WHERE Statement Manipulation 6

part="or a=a" SQL Injection WHERE Statement Override

part="or 1=1" SQL Injection WHERE Statement Override 1

10/12

Example of False-Positive and Misdetection (3/5)

Signature Sample related to DDoS attacks Ex) In case that HTTP URI includes “yahoo.co.jp/movie/deadoralive/default.jsp”

Limitation

• The use of the ‘alive‘ is common in Website. When DDoS signatures are turned on, the regular expression that just detects the ‘alive’ results in too many false positives.

Signature Signature Name

part="newserver" DDOS mstream agent to handler

part="stream/" DDOS mstream handler to agent

*part="alive" DDOS shaft agent to handler

part="alive tijgu" DDOS shaft handler to agent

part="killme" DDOS Trin00 Attacker to Master default mdie password

part="gOrave" DDOS Trin00 Attacker to Master default password

part="betaalmostdone" DDOS Trin00 Attacker to Master default startup password

part="*HELLO*" DDOS Trin00 Daemon to Master *HELLO* message detected

part="l44" DDOS Trin00 Daemon to Master message detected

part="PONG" DDOS Trin00 Daemon to Master PONG message detected

part="l44adsl" DDOS Trin00 Master to Daemon default password attempt

11/12

Example of False-Positive and Misdetection (4/5)

Signature Sample related to Privacy(Credit Card Number) Filtering Ex) For a credit card number “4254361480110015”

• 4254361480110016 : Detected in spite of invalid card number False-Positive• 4254-3614-8011-0015-1234-5678 : Detected in spite of not credit card number False-Positive• 4254_3614_8011_0015 : Credit card number, but not in pattern Misdetection

Limitation

• Although Credit Card Number is invalid or even not Credit Card Number, the regular expression filters it. • If Credit Card Number’s format is changed, it can not detect at all.

Signature Signature Name

part="349", rgxp="[^\d]349\d[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{3}[^\d]{1}"

Data Leakage: credit card number extraction - 213 - American Express

part="422", rgxp="[^\d]422\d[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[^\d]{1}"

Data Leakage: credit card number extraction - 24 - Visa

part="423", rgxp="[^\d]423\d[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[^\d]{1}"

Data Leakage: credit card number extraction - 25 - Visa

part="424", rgxp="[^\d]424\d[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[^\d]{1}"

Data Leakage: credit card number extraction - 26 - Visa

part="425", rgxp="[^\d]425\d[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[^\d]{1}"

Data Leakage: credit card number extraction - 27 - Visa

part="299", rgxp="[^\d]299\d[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{2}[^\d]{1}"

Data Leakage: credit card number extraction - 276-  Diner's Club / Carte Blanche

part="300", rgxp="[^\d]300\d[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{4}[-\.\s\\\/=]?\d{2}[^\d]{1}"

Data Leakage: credit card number extraction - 277-  Diner's Club / Carte Blanche

12/12

Example of False-Positive and Misdetection (5/5)

Signature Sample of ‘Buffer Overflow Attack Attempt’ If the Buffer Overflow Attack is modified like “abcdabcd…abcd”, the regular expression cannot

detect it.

Signature is made to cope with some scanners and robots. So, it leads to many misdetection.

Limitation

• It is very difficult to express an infinite number of cases as one pattern. • To add many single patterns gives additional system load to web application firewall.

Signature Signature Name

part="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

Buffer Overflow Attack Attempt

part="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

Buffer Overflow Attack Attempt 1

part="BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB"

Buffer Overflow Attack Attempt 2

part="CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC"

Buffer Overflow Attack Attempt 3

part="DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD"

Buffer Overflow Attack Attempt 4

part="EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE"

Buffer Overflow Attack Attempt 5

13/12