session management security and applied reverse benchmarking - tom stracener, sr. security analyst,...

Session Management Security and Applied Reverse Benchmarking

- Tom Stracener, Sr. Security Analyst, Cenzic Inc.

November 2007

Cenzic Confidential2

Agenda

• Security Statistics

• Application Layer Basics

• Session Management Vulnerability Types

• Session Poisoning as a research area

• Reverse Benchmarking as applied to session management testing methods

• Q&A


Web Vulnerabilities

Source: Cenzic Q3 Application Trends Report


Web vulnerabilities by Major Type



Web Browser Vulnerabilities



Percentage of Applications by Vulnerability

Source: Cenzic Q3 Application Trends Report – Cenzic ClickToSecure Managed Services


Incidents by Category



Incidents by Sector



Vulnerability by Class



Anatomy of a web application

Single Factor Session Management

UI Layer (Browser Logic)

Server and Middleware (Session Management)

Custom Applications

Web Browser

JavaScript Plug-Ins/API

Java DOM HTML/DHTML

Cookies

HTTP SSL HTTP-S Authentication Certificates

Digital Signatures

Communication Layer (Protocol Layer)

Web Server SW/HW

J2EE PHPASPJava .NET

Data LayerDatabases SSI Raw Data CSS/XSLXML

File System

JavaScript VB Script C/C++ PHP/LAMP CGI


Session Mgmt Overview

HTTP is a stateless protocol.

A Session identifies a user with a persistent (but changing) state within the application.

Web Applications must track and maintain state for a user across application boundaries over time.

99% of all session management mechanisms offer single-factor protection and were not designed for security.


Session Mgmt Overview

Types of session management mechanisms

• Cookies (RFC 2109,

• HTML Hidden Field Values

• URL Tokens

• Ex.

http://eBiz/Cart/checkout.php?session_id=2006011617415164.60.123.42&pid=&cat_id=&attrib


3 Challenges of Session Mgmt Security

1. Web Applications must maintain state securely

User session data must individuate one user from another so that state information does not overlap, for the purpose of enforcing proper user privileges and roles.

Ex. User 2Pac (registered user), 50Cent (Admin), Master P (anonymous) have access to different pages and functions within the application.



2. Distributed Components within Web Applications must share user session information securely

User session data must be shared and validated by application components that process user requests and information associated with a user.

Ex. Shopping Cart (Add/remove items), Wish List (Add/Remove items), Checkout & Transaction (SSL), Confirmation of Order (SSL), Reciept (SSL)



3. State maintaining mechanisms must handle state transitions securely as the user moves between functional hierarchies.

As the user’s privilege level changes within the application, state tracking must securely handle these transitions without data leaks or exposures.

Ex. Spot (anonymous) authenticates and adds several items to his wishlist (registered) and then makes a purchase (SSL-cart) by selecting an item and performing the transaction (SSL-cart). The transaction details are stored in Spots purchase history (SSL-cart).


Misconceptions Regarding Session Security

“Our Sessions are Secure”

“There really aren’t any exploits”

“Our Session IDs aren’t predictable so we are safe.”


Cookie Security Flaws

Cookie Tampering

Cookie Persistence and Expiration

Types of Cookie Security Flaws

Cookie Theft/Hijacking (single factor attack)

Cross-Site Cooking (Cookie Based Session Fixation)


Cookie Security Flaws

Session Replay Attacks\Expiration

Session Poisoning (New)

Types of Session ID Flaws

Session Hijacking (single factor attack)

Session Tampering\Prediction


Session Vulnerabilities and Examples

Insecure Session Teardown/Session Timeout

The Session IDs used during a session are not removed following termination or inactivity of a session, allowing the Session IDs to be reused by an attacker to access the previous users session. (non-concurrent attack)

S1…………S1…………..L1……….S1

T1………….T2………….T3…………T4

Reuse of S1 following Logout L1



Session Replay Attacks

Session information persistently stored by an intermediate server or

application is reused to access a users session.

1. Caching Proxies

2. Web Proxies\Reverse Proxies

3. Internet Gateways

4. Logging Servers/Webtrends, etc.

URL-based Session IDs can be cached in web logs, Proxy Servers, logged in

HTTP Referrer Fields. A Session replay attack involves uses these

credentials to gain access to the application to take over an existing session.



Session ID Prediction

Generating Sequential Session IDs is dangerous, as an attacker can predict the next value and take over a concurrent session.

Using static information like the data and IP addresses in Session IDs can allow an attacker to analyze and break down the session ID, making it easier to brute force valid session tokens.

/Cart/checkout.php?session_id=2006011617415164.60.123.42&pid=&cat_id=&attrib






Session ID Prediction (Example)



Session Hijacking Attacker submits a concurrent request with a valid session ID for

a current user and gains access to their web session. The attack can involve combinations of other attacks to capture a live Session ID, or could capture unencrypted Session Tokens from the LAN.

Brute Force attacks against Session IDs.

Local Sniffer-based attacks

Cookie Reuse.

URL Session ID Harvesting/logging via proxy or XSS.



Session Fixation

Attacker fixes the user’s session ID prior to authentication, so that the Session ID

supplied by the attacker is used by the application.

Depends upon the application trusting the session ID supplied by the client. The

ability to generate or predict Session IDS that are valid for the Session Token

syntax makes the attack more likely to succeed.



Session ID Poisoning (New Research Area)

Attacker appends arbitrary data to a users session ID, resulting in potentially unsafe content being propagated via the Session ID mechanism.

Depends upon the application sanitizing the session ID.

Session_id=ghzdkfl11020003<script>maliciouscontent<script>


Hailstorm Overview

Session Poisoning Attack Example

ttp://www.internet.com/forums/viewtopic.php?p=36660&sid=15170326da8f83631f59d120a6dea3f8<script>alert(document.cookie)</script>

Characteristics of the attack

1. Malicious Content “Piggiebacks” on a session ID

2. Content is innocuous to the attacked application

3. Malicious Content logged by intermediaries

4. Malicious Content executed (reflected) by an intermediary (e.g. a web proxy server).


Hailstorm Overview

Session Poisoning Attack Example

Characteristics of the attack

1. Malicious Content “Piggiebacks” on a session ID

2. Content is innocuous to the attacked application

3. Malicious Content logged by intermediaries

4. Malicious Content executed (reflected) by an intermediary (e.g. a web proxy server).


Versions of PHP are vulnerable when used in conjunction with software that relies on PHP Session Management mechanisms.Verified on Apache/2.0.55 (Win32) PHP/5.1.2


Reverse Benchmarking & Session Management Security Testing Procedures.

(A scanner darkly)


Analyzing Application Security Scanners

Security Assessment Methods and Quality-based Criteria

• Functionality (Black vs White Box)

• Ergonomics & Usability

• Performance

• Feature Sets

• Bling

• Accuracy

• False Positive Rates i.e. Signal to Noise


Analyzing Application Security Scanners

Benchmarking Concepts

• Benchmarking black box scanners is ultimately a systematic comparison

• Most common Benchmarking technique is ‘positive’ or ‘comparative’ benchmarking

• The goal is to see which scanner does the best against a selected application


Positive and Negative Accuracy concepts

Detection Metrics Matrix


What is Reverse Benchmarking?

• It’s a type of passive Reverse Engineering.• Taxonomic understanding of False Positives • Causes Massive False Positives• Understanding vulnerability detection methods• Think of it as Detection Logic Fuzzing

Exposes poor coding, faulty detection logic Reveals Security Testing design flaws Confuses Stateless Testing Mechanisms


Rationale for Reverse Benchmarking

Most of the Common False Positive Types have been around since 1999-2000

Most testing mechanisms are entirely stateless and have evolved little

Very little is known about False Positives, as a science

There are no taxonomies or Top 10 lists for Common False Positive Types


Reverse Benchmark Target

Web Application Scanner

Enumerates and Categorizes False Positive Types

Reveals Vacuous or Meaningless results

Reveals Semantic flaws in vulnerability Categorization

Reveals systemic flaws in application spider technology


Hailstorm Overview

Reverse Benchmarking Example• 4 page test target• Generated over 57,000 False Positives.


Session Hijacking SmartAttack


Reverse Benchmarking Methodology


Reverse Benchmarking Goals

The goal of Reverse Benchmarking is not to malign vendors, but to aid the security community and help developers avoid the same mistakes with each new generation of technology

Systematically performed, Reverse Benchmarking can help security practioners learn to quickly distinguish false positives from valid security issues, as they will learn the conditions under which the

technology they are using fails.

Based on the type of trigger that elicits the false positive, a taxonomy of false positive types can be developed. A set of common causes or contributing factors for each type can be outlined.


Out of Session FaultsDetection of session management security issues under the mistaken assumption that a session exists when in fact it does not, or the scanner has lost state with the application.

In Session parameters

In Session Progression

Stateless

Progression

Common Causes of False Positives


Partial Match ProblemsDetection strings may be a subset of existing content and triggered by the presence of unrelated words or elements within the HTML or DOM

GET /search.pl~bak

July 2007 200 OK

Common Causes of False Positives


Parameter EchoingParameter values may be echoed back in places within a web application, and this can trigger false positives.

<TEXTAREA rows=3 ls=100>

<?php

// get the form data

$field1 = $_POST['comments'];

// Echo the value of the comments parameter

echo "Backacha Biatch: $field1";

?>

</TEXTAREA>


Mistaken Identity

Some security tests look for vulnerability conditions so general that the vulnerability reported must be disambiguated in order to be

verified.

Many types of PHP forum software, Calendars, Blogs reuse a common code base and so overlapping URI and application responses

GET /search.pl

Alibaba Search Overflow Paul’s Search SQL InjXn

YABB Search.pl XSS


Semantic Ambiguity

Signature-based detection is often relies on signatures that are generic and thus are neither necessary nor sufficient for the vulnerability to be present.

[Microsoft][ODBC SQL Server Driver]

Many false positives arise because the vulnerability is more complex than the vulnerability conditions checked for by the signatures.


Response Timing

Slow, unresponsive, or delayed server-side processing can trigger security checks that are timing dependent

Some SQL injection tests use a wait_for_delay expression and measure the timing.


Custom 404 Pages

Simple file scanning routines and other security tests will trigger erroneously in the

presence of custom 404 pages.

Some signatures are based on 302 Redirects

GET /search.pl~bak

302 200


Creating a Reverse Benchmark target

Nature of the target will depend on your goals as a researcher

Reverse Engineering

1. Emphasis on exposing as much of the signature base and rule set as possible without inspecting datafiles or code. Clear generic cases that will likely impact the largest portion of the rule base

2. Focus on generic trigger signatures, including available open source scanners. (i.e. use of Nikto detections strings in response data.




Bakeoffs/Comparisons

1. Emphasis on exposing false positives or signature flaws of all varieties, including the uncommon or essoteric. Use of non-standard or overly difficult application configuration to stress test the scanner.

2. Focus on unusual or non-standard trigger signatures. i.e. Javascript or Flash road test




Reverse Engineering


Open Reverse Benchmarking Project



Backatcha Roadtest Results Overview

Took 4 popular blackbox web application security scanners

Ran their default policies against the target reverse benchmarking application

Put the results into high level buckets

Generated a few graphs with the results


Total False Positives

92%

2% 2%

4%

Scanner 1

Scanner 2

Scanner 3

Scanner 4


Out of 4 scanners, 1 scanner generated 92% of the false positive volume

Roughly 9000 false positives total

3 other scanners came in at 2%, 2% and 4%.

In terms of numbers, our 3 page application generated 180, 180, and 360 false positives in the remaining scanners

Total False Positives

92%

2% 2%

4%

Scanner 1

Scanner 2

Scanner 3

Scanner 4


Scanner 1 False Positives

42%

5%2%7%

30%

14%0%

Path Manipulation

Command Injection

XSS

SQL Injection

File Disclosure

Known Vulnerabilities

Misconfigurations



29%

11%

4%

21%

21%

0%

14%

Path Manipulation

Command Injection

XSS

SQL Injection

File Disclosure


Misconfigurations



0%

29%

67%

2%

1%

0%

1%

Path Manipulation

Command Injection

XSS

SQL Injection

File Disclosure


Misconfigurations



4%

0%

53%

0%

7%

0%

36%

Path Manipulation

Command Injection

XSS

SQL Injection

File Disclosure


Misconfigurations


Further Research

Improve reverse benchmarking target

Add more tests

Improve testing methodology

Test with more scanners

Partner with OWASP

Help develop Reverse Benchmarking Module for SiteGenerator


Hailstorm Overview

SmartAttack Library provides for robust testing and analysis of Session Security

Session Management SmartAttacks target a wide-range of Session-Based vulnerabilities.

Session Hijacking

Privilege Escalation

Authorization Boundary


Privilege Escalation SmartAttack

The SmartAttack gathers session credentials from a previous user and injects them in a more privileged user’s session. Pages accessible only by the privileged user should not be accessible using the gathered session credentials if the sessions are maintained correctly


Privilege Escalation SmartAttack


Session Expiration

The SmartAttack gathers session credentials from a previous user and injects them into a different session once the first user logs out. Pages accessible with these credentials are vulnerable to session id/cookie reuse-based attacks.



The SmartAttack takes an application traversal by a previous user and attempts to access pages restricted to that user by suppressing session credentials. Tests for authentication/authorization boundaries within an application, and also detects fail open bugs in session management.


Thank You for Your Time!

Tom Stracener

For more info: [email protected] or 1-866-4-CENZIC (1-866-423-6942)


Questions & Answers

session management security and applied reverse benchmarking - tom stracener, sr. security analyst,...

Documents