hacking exposed: web application - frank.itlab.us» hacking exposed: web application »...

» Hacking Exposed: Web Application

» Countermeasure

» Conclusion

» Current Problem

» Case Study

» Overview

Contents:

2©2003 Foundstone Inc.

Who Am I?

» Yen-Ming Chen

– Managing Director of Asia (was Principal Consultant)

– Joined Foundstone in year 2000.

– Served Fortune 8 clients for consulting engagement

– Specialized in Web Application Assessment, Wireless Network

Assessment, Product Security Assessment, and Survivability

– Assessed Hundreds of Web Applications

– Articles in SecurityFocus, DevX, SysAdmin, PCWeek and other medias

– Co-authorship: HE 3rd edition, HE of web app, Win XP professional and

HackNote Web security

– MSIN from CMU Information Networking Institute (1999)


Agenda

» Overview

» Current Problem

» Case Study

» Countermeasure

» Conclusion

» Overview

» Countermeasure

» Conclusion

» Current Problem

» Case Study

» Overview

Contents:


Overview

» What is Web Application?

» Web Server vs. Web Application

» Web Application Vulnerability Study


World Wide Web

» World Wide Web Created by Tim-Berners Lee in 1989

» Key Concepts:

– Hypertext and Hyperlink(Text with links)

– Browser (User interface to access different resource)

» Goal: To Use One Program (Browser) To Access Different Type of

Resources, and Links to Other Resources

» Now: Backbone of E-Commerce


What is Web Application?

» Application based on WWW Architecture

» Usually a multi-tier architecture

» Requires: Browser, Web Server and Backend Server


Web Application Architecture

Web Browser

Database

Web Server

Application

Legacy Server

Other Server

Application

Application


Web Server vs. Web Application

» Web Application:

– Using programming language (e.g. ASP, PHP, Java, .Net, Perl or C) to

implement business logic and serve the client

» Web Server:

– Serves client request and forward to proper application for further

processing (e.g. IIS, Apache, thttpd and etc.)

» Web Application does not run without Web Server

» Web Server does run without Web Application (Serving static content)

» Web Application should contain:

– Web Server and underlying OS

– Web Application Code

– Backend Server


Web Server Vulnerability

» Vulnerability on the web server program itself

» Can be identified by:

– Port scan for web related ports (TCP 80, 443 and etc)

– Vulnerability scanner (Whisker.pl, N-Stealth, Nikto.pl and others)

» Example:

– IIS

• File system traversal vulnerability

• Unicode and superflous decode vulnerability

• Various buffer overflow in ISAPI filters (.ida, .printer, WebDAV and etc)

» Impact:

– Usually the attacker can take over the system running the web server


Web Application Vulnerability

» Vulnerability on web application itself

» Can be identified by:

– Source code review

– Application testing

• Automatic scanner

• Manual testing

» Example:

– SQL or command Injection

– E-Shop lifting

– Passport reset password flaw

» Impact:

– Data confidentiality and integrity breached

– System compromised


Web Application Vulnerability Study

» Studied 129 web application reviewed from year 2000 till 2003

» Extracted data:

– SIC code (Standard Industry Classification Code)

– Business Sensitive Information: Yes or No

– Finding Title

– Risk

– Finding Category


Application Profile

Distribution of Industry

Healthcare 5%

Financial service

9%Others 12%

IT

softw are/service

74%

Healthcare

Financial service

Others

IT softw are/service

Distribution of Industry

Healthcare 5%

Financial service

9%Others 12%

IT

softw are/service

74%

Healthcare

Financial service

Others

IT softw are/service


Business Sensitive Information?

Sensit ive Informat ion

71%

29%

Yes

No

Sensit ive Informat ion

71%

29%

Yes

No


Number of Vulnerability

454Median No.

111Lowest No.

172121Highest No.

4.884.704.82Average No.

449174623Total No.

Business Sensitive

Information: No

Business Sensitive

Information: Yes

General

Sensitive Information Does Not Imply Better Security!


Vulnerability by Risk Level

Vulnerabilities by Risk Level

High

28%

Low

19%

Medium

53%

High

Low

Medium

Vulnerabilities by Risk Level

High

28%

Low

19%

Medium

53%

High

Low

Medium


Web Application Vulnerability Group

» Vulnerability means a vulnerable state that could be exploited

» The vulnerable state could be a program or part of the software

development lifecycle

» So the vulnerabilities are grouped by:

– Application Design

– Application Implementation

– Application Deployment

– Infrastructure Configuration


General Risk Level by Vulnerability Type

design

implementation

infrastructure/...

deployment

High

Low0.00%

5.00%

10.00%

15.00%

20.00%

25.00%

30.00%

High

Medium

Low

design

implementation

infrastructure/...

deployment

High

Low0.00%

5.00%

10.00%

15.00%

20.00%

25.00%

30.00%

High

Medium

Low


General Risk Level by Vulnerability Type

» Highest Risk: Implementation

» Highest Medium Risk: Infrastructure/Configuration


Risk Level by Vulnerability Type

design

implementation

infrastructure/...

deployment

High

Low0.00%10.00%20.00%30.00%40.00%50.00%

60.00%

70.00%

High

Medium

Low

design

implementation

infrastructure/...

deployment

High

Low0.00%10.00%20.00%30.00%40.00%50.00%

60.00%

70.00%

High

Medium

Low


Risk Level by Vulnerability Type

» Highest probability in “High” Risk: Application Design

» Highest expectation score: Application Implementation

» Highest probability in “Medium” Risk: Infrastructure/Configuration


More Detailed Results

» Will be available in a coming research paper

» Stay tuned ……

» Current Problem

» Countermeasure

» Conclusion

» Current Problem

» Case Study

» Overview

Contents:


Current Problem

» Web Application Vulnerability

» Finding Web Application Security


Web Application Vulnerability

» Application Design

» Application Implementation

» Application Deployment

» Infrastructure Configuration


Application Design

» Vulnerability in the stage of application design

» Examples:

– Weak password (policy)

– No protection (Encryption) on confidential data

– Bad choice on using cryptography

– Weak authentication/authorization mechanism


Application Implementation

» Code defect – Happens during implementation

– Input validation problems

• Buffer overflow

• Code/SQL/Command Injection/execution

• Cookie/data manipulation

• File system traversal

• Exception handling

– Application logic problems

• Function state not maintained

• Logic error


Application Deployment

» Transition of application state (e.g. from test to production)

– Did not strip out information

• Test/Guest accounts

• Test information

• Debug configuration

• Account/Password information

– No audit/test before deployment

• Deployed bugged version

– Expose test environment


Infrastructure/Configuration

» Configuration problems on servers

– Patch level is not up to date!

– Weak user password (inherited from the design phase)

– Weak permissions

– Bad/debug configuration

» Configuration problems on network

– Did not properly block incoming traffic

– No blocking of out-going traffic

– No security between Web server and internal servers


Find Web Application Vulnerability

How Do You Find Web Application Vulnerability Today?

Raise Your Hand If You Use Automatic Tool!

Raise Your Hand If You Use Manual Test!

Raise Your Hand If You Don’t Use Any of Them!


What’s Wrong with Automated Tools?

» Assessment Plan

» Accuracy

» Flexibility

» Accountability and Traceability


Assessment Plan

» Do You know what will be tested?

» Do you have control to add or delete the test?

» Who is making the plan?

» What is the methodology?

» What is the knowledge base?


Common Methodology

» Check for server vulnerability

» Crawl (Find the web application)

» Identify input field

» Search for vulnerability

– Buffer overflow

– SQL injection

– Cross-site scripting

– File system traversal

– Information disclosure

» Search for logical vulnerability (Does not apply on automated tools!)

– State management

– Authorization or Access Control


Accuracy

» How accurate is the result?

– Can any tool identify “ANY” of the case study we are going to talk about?

» Is it confused by your customized error page?

» Can it login into your HTML Form-based authentication application?

» Can it assess authorization or access control problem?


Flexibility

» How easy can you modify the test item?

» How easy can you add/create a test item?

» How often is the test item being updated?


Accountability & Traceability

» Can you verify or reproduce any single vulnerability found?

» How easy/hard would that be?

» Can you identify what is the risk brought to you by the vulnerability?

» Can you change/define how the risk is calculated?


Challenge

Can Any Scanner Identify

Any Of The Case Studies

We Are Going To Show You?

» Case Study

» Countermeasure

» Conclusion

» Current Problem

» Case Study

» Overview

Contents:


E-Shoplifting

» Target

» Find the Price

» Change the Price


Target


Find the Price


Change the price…


To Encrypt or Not To Encrypt?

» Use Encryption Wrong Would HURT You!

» Case I: Vernam Cipher with Repeated Key

» Case II: DES with wrong mode


Case Study – Vernam Cipher

» Mission: A web interface to file repository in the firm

» User permissions

» Directory and filename obfuscated

» Result: Arbitrary file retrieval

» How we broke it?

» First problem: Test user account in production environment (test/test)

» Second problem: Using Vernam cipher (XOR algorithm) in the wrong way

(repeat using the same key) to obfuscate directory/file names

» Third problem: Server patch not up to date (IIS with +.htr source code

disclosure)

» All the problems gave us file system traversal on the system with

all the directory and filename obfuscated.


Case Study – DES with Wrong Mode

» Mission: Online Banking

– User Account and Password

– Encrypted with DES

» Result: Chosen ciphertext attack

» How:

– DES (or other block ciphers) can use different “modes”

– The application use the mode without Message Authentication Check

– Found a pair of plaintext to ciphertext:

• Account: 12345678901234

• Encrypted: 5E7BEAD93BC906FFBE343ED7FCE0C8DD

– Use the first half “5E7BEAD93BC906FF” and you can access the account

“12345678” (For balance report)


Service Dependency

» Bad Session Management


Case Study – Bad Session Management

» Mission: Web Application Assessment

» A Web authentication system for internal expense application

» Use cookie to maintain user session state

» Encrypt and encode the cookie very well

» Result?

» We can modify any user’s password, information and answers to secret

question!

» We can view arbitrary expense report in the system

» How we broke it?

» Overlooked service dependency: “Modify user information” function does

not use the encrypted cookie to maintain the session.

» Expense system program does not correspond user identity with expense

report


Edit Profile


Change LogonID


Passport Password Reset Problem

» Application Function State Management Problem

» Original Function Flaw

1. User chooses to reset the password

2. User fills in information about the account

3. User answers the secret question in user profile

4. User is redirected to "emailpwdreset.srf" and the system sends an email to

an email address specified by user with the link to reset the password

» What is wrong?

– The state should be kept from step 1 to step 4

– However, due to coding error, the state is not maintained

– You can jump directly to step 4 and reset any user’s password

» Reference info: “Untrustworthy Passport”, Yen-Ming Chen,

SecurityFocus Guest Feature.


Application Deployment

» What can go wrong when you deploy your application?

» Network configuration

» Server configuration

» Application configuration

» Case Study: Bad Configuration Management

» Case Study: Bad Extranet Configuration Management


Case Study – Bad Configuration

Management» Mission: Web Application Assessment

» E-Commerce application

» Depends on another authentication service

» Allows user to store credit card information and perform financial transactions (e.g. online shopping)

» Result:

» Test interface on the Internet that exposes whole credit card number while production site discloses only last 4 digits (trick: special merchant ID!)

» Cookie replay (problem of the authentication service)

» Malicious file can be uploaded by merchant!

» How:

» Bad Configuration Management

» Bad design and implementation

» Service dependancy


Case Study -- Bad Extranet Configuration

» Mission: Web Application Assessment

– Application Server Resides in Extranet for Partners

» Result:

– No Findings in Web Application

– Break into the Intranet via Extranet

» How:

– Found a Web Server Broken by Honker Union (China) on the same subnet

– Own the Server via Unicode + Privilege Escalation

– Found Windows Domain Trust Relationships with Intranet Domain

– Become Domain Admin of the Intranet

» Countermeasure

» Countermeasure

» Conclusion

» Current Problem

» Case Study

» Overview

Contents:


Principles

» Defense in Depth

» Deny by Default

» Least Privilege


Software Development Lifecycle

» Requirement defined

» Design

» Prototype

» Implement

» Test

» Deploy

Security Should be Everywhere!


Requirement Defined

» Except Software and Business Requirements,

» Define Security Requirements

– Policy

– Procedure

– Audit Plan

– Incident Response Plan


Design

» Design with Security in mind

» Principles: CIA

– Confidentiality

– Integrity

– Availability

» Education

– Equip your developers with security knowledge

• Secure Coding

• Secure Development

• Security Testing


Prototype & Implement

» Educate your developer for secure coding practice!

– Avoid using dangerous functions!

– Do not leave information in the comment!

– Maintain the state!


Audit & Test

» Periodically audit/test your web application

» Audit/Test before each major release

» Both manual/automated audits should be used

» Full source code level audit should be conducted at least once

» Optional source code level after first release

» Measuring your web application security


Deployment

» Build a secure server baseline image for deployment

– Strengthen passwords

– Apply least privilege principle

– Erase example/sample files and applications

– Erase unnecessary services

» Use tools to strengthen your servers

– IISLockdown tool for IIS


Deployment – Cont’d

» Separate your test and production environment

– Sanitize the application before deployment!

– Protect the test environment

» Secure your network configuration

– Apply deny by default principle

– Block both incoming traffic and outgoing traffic

• Web server only listens and responds to incoming requests, it does not

initiate a request to the Internet (unless there is a worm!)

– Secure communication between important servers

• Use IPSec to secure communication between web server and other

important servers (e.g. database or DC)

» Conclusion

» Countermeasure

» Conclusion

» Current Problem

» Case Study

» Overview

Contents:


What We Did Not Talk About

» Web client-side security problem

– Vulnerabilities on browsers

• IE arbitrary code execution (too many)

• Browser hijacking


Bright Future?

» E-commerce based on WWW (That’s where money is!)

» WWW has to be public service (Threat level up!)

» Security problems exist for Web applications (The Risk is TRUE!)

» You can secure your web application with simple principles

» Both manual and automatic audit/test should be used

Question and Answer

Thank You!

Yen-Ming Chen

Foundstone Inc.

[email protected]

hacking exposed: web application - frank.itlab.us» hacking exposed: web application »...

Documents