breaking in through the front door

Breaking In Through The Front Door

The Impact of Web Applications and Application Service Provision on Traditional Security Models

Shaun Clowes – shaun@securereality.com.au

Overview

A Brief History of Computing Web Application environments Dangers of Web Applications Exploiting PHP Applications Testing Web Applications Protecting Web Applications Questions?

A Brief History Of Computing

How has the security problem space evolved over time?

What new problems are we facing? Are we eliminating old problems?

Ancient History

Ancient History – 1940’s and 50’s Eniac, Univac etc. Not exactly many security issues

Commercial Computing

Early 1960’s Transistors and later Integrated Circuits IBM’s 701 and later 360 Batch processing Still not exactly difficult to secure

Multi User Systems

Late 1960’s IBM’s 360/67, CP/CMS and later VM/CMS Terminals Security begins to become an issue Students stealing CPU time

Centralized Computing

1970 PDP Machines The birth of Unix Word processing, true multi user operating

systems Attacks against local applications and social

engineering

Client / Server

Late 1970’s and early 1980’s Microcomputers interfacing with

Minicomputers and Mainframes Advent of ‘Network Services’ Security becomes a larger problem space Attacks against open services The advent of anonymity

The Internet

Circa Late 1987 to now Unix supports TCP/IP, commercial

connections Security explodes, threat rises dramatically Complete anonymity Service attacks become widespread The Morris Worm - 1988

The Defence

Internet not friendly Attacks:

– Local Applications– Social Engineering– Externally Accessible Services

Developed defence technologies

Firewalls

Packet Filters – IP routers with filters

Application Layer – Marcus Ranum – DEC SEAL

Stateful Inspection– Gil Shwed – Firewall 1 - Checkpoint

Limiting exposure of services

Intrusion Detection Systems

Network Based– Network Flight Recorder, Snort etc– Detect

Host Based– LIDS etc– Detect, Prevent

Limit anonymity, Limit timeframe for attacks

Defence Weaknesses

Local attacks still very common where command execution is possible

Administrators actively patch multi user machines

Access to other machines (e.g Web Servers) limited to trusted users

Where Are We Headed?

Centralized Computing

Client/Server Computing

???

Where Are We Headed?

Centralized Computing

Client/Server Computing

Web/Thin Client/ASPComputing

Architecture

Architecture Benefits

No client side software (web browser)– No versioning issues– No platform compatibility issues

3rd tier servers behind firewall, not directly accessible

Web Applications run on trusted machine – Can they trust their environment?

Architecture Drawbacks

Processing load on web server Can be complex to develop in traditional

languages

Architecture Risks

Web Applications must be secure– Can access 3rd tier servers with privileges– Subverted Web Applications not controlled

(typically) by Firewall– IDS unlikely to see attacks against Web

Applications Web Applications do not fit into security

model for Centralized or Client/Server computing

The Result

Despite risks/drawbacks, Web Applications being deployed in increasing numbers

So what sort of attacks are we exposing ourselves to?

Attack Scenarios - 1

1. Attack SQL queries including client input2. Gain elevated privileges to

1. Application – See Attack Scenario 22. Database server

3. Use access on Database server to further elevate privileges

– On DB Server via local exploits– On other hosts by trust relationships and

service attacks

Attack Scenarios 1 cont.

SQL attacks well covered elsewhere, not focus here

For more information:– Search BugTraq– David Litchfield – “Remote Web Application

Dissassembly with ODBC Error Messages”

Attack Scenarios 2

1. Attack vulnerabilities in Web Application code or environment

2. Results in:1. Elevated Privileges in Application

Exploit Application further

2. Local Code Execution Exploit local vulnerabilities (little patching) Exploit trust relationships with 3rd tier

3. End Result:– Major privileges on network

Other Attack Scenario’s

Other Attacks possible against underlying Architecture (e.g Web Server)

Well covered in JD Glaser’s presentation

Driving the Change

Web Applications previously developed in:– Perl– C

Not designed for the Web Web Languages developed:

– PHP– ASP (VBScript)– ColdFusion

Web Languages

4th Generation Languages Tags embedded in HTML pages Very feature rich Designed to be simple

– Coding falls to Web Designers

Web Languages - Issues

Languages make it hard to write secure applications (especially PHP)

One function can behave in many ways (for ease of use)

Loosely typed, no variable declaration Blur border between user input and

application variables Software written by non coders, don’t

understand issues

Focus on PHP

PHP = “PHP Hypertext Preprocessor” Installed on 37% of Apache servers (E-Soft

Web Survey) Lots of applications being written for it Discuss

– Common mistakes with PHP– How PHP makes secure code difficult

PHP – Global Input Variables

Form variables end up as global variables in script

For Example:

When submitted, the variable $hello in PHP contains the value specified in the form

<FORM ACTION="<name>.php" METHOD="post"><INPUT TYPE="text" NAME="hello"><INPUT TYPE="submit"></FORM>

PHP – Global Input Variables

Attacker can pollute the global namespace For Example:

– A script sets the variable $auth to true if its authenticated the remote user

– The attacker provides auth as true through form input

Script cannot trust any variable it hasn’t explicitly set

PHP – File Upload

SecureReality Advisory 1 (SRADV00001) Automatically handles RFC 1867 For Example:

If file is less than max_file_size its saved locally (usually in /tmp)

<FORM ENCTYPE=“multipart/form-data” ACTION="<name>.php" METHOD="post"><INPUT TYPE="hidden" name="MAX_FILE_SIZE" value="1000"> <INPUT TYPE=“file" NAME="hello"><INPUT TYPE="submit"></FORM>

PHP – File Upload

The script is given variables– $hello = Location of file on local system– $hello_name = Remote filename– $hello_size = Byte size of file– $hello_type = MIME Type of file

PHP – File Upload

An attacker can set max_file_size to an arbitrary value

Gain? Limited by PHP configuration directive

upload_max_filesize Just submit multiple files Still limited by maximum execution time

PHP – File Upload

An attacker can get the application to work on a file local to the machine

Use a form like:

We’ve used our ability to affect global variables to create the variables expected by the script

<FORM ACTION="<name>.php" METHOD="post"><INPUT TYPE=“hidden" NAME="hello“ VALUE=“/etc/passwd”><INPUT TYPE=“hidden” NAME=“hello_size” VALUE=“100”><INPUT TYPE=“hidden” NAME=“hello_type” VALUE=“text/plain”><INPUT TYPE=“hidden” NAME=“hello_name” VALUE=“hello”><INPUT TYPE="submit"></FORM>

PHP – File Upload

This will often lead to exposure of sensitive file contents

Hard to detect this attack in all but the most recent versions of PHP

Latest versions make this easy to detect Latest documentation makes the problem

clear Problem still common

PHP – Remote Files

Typical file operations support Remote Files functionality

The following code opens a file:

If $hello beings with http:// or ftp:// PHP will go to network

<?phpIf (!($file = fopen(“$hello”, “r”))

echo(“Could not open file!”);?>

PHP – Remote Files

How does an attacker use it? Remote Files works for most file operations

in PHP Include() and require() read a file and

interpret it as though it were PHP code Typically used to support “library” concept

PHP – Remote Files

For example:

$langdir is a configuration variable specifying the directory for scripts for a certain language

<?php…include(“$langdir/phrases.php”);?>

PHP – Remote Files

The attacker can set $confdir with form input

If she can prevent the script overwriting it she can submit:

http://<myevilserver> If the attacker creates a file on their

webserver called languages.php Code execution

PHP - Parsing

Certain file types are configured in the web server to be parsed as PHP

Other types could well be returned as plain text

PHP Library files are typically named <library>.php, so they cannot have source retrieved

PHP – Parsing

Thus remote user can remotely request a library file and have it parsed

Loss of dependencies Code can no longer rely on an environment

Real Life Vulnerabilities

Following are several in depth examples of security compromises through popular open source PHP Web Applications.

Attacks are via Web Browser– No special software– Breaking in through the front door

Attacks are normal HTTP requests

Vulnerabilities

At time of writing vendors have not been notified of the vulnerabilities to be discussed. They have thus been omitted from this version of the presentation.

After the presentation the full slides will be available at http://www.securereality.com.au and

http://www.blackhat.com

Vulnerabilities - Conclusion

Exploiting PHP often like catching fish from a barrel

Code running on trusted host, in trusted network but still cannot trust its environment

Finding the Holes

File upload issues – Change file upload fields to hidden fields– Just try

Hidden fields – Often configuration variables– Modify them

Normal fields– Try special characters, ‘/\:;’

Finding the Holes

Getting the source:– Open source – Full or modified– IIS Holes

• Unicode exploit

• showcode.asp

• .htr hole

• Translate: f hole

• …. many more

– FTP to web server (anonymous)

Finding the Holes

Getting the source:– Non parsed backup files:

• .bak, .tmp, .old, .bac, .backup, .orig, .temp, .000, .~1, .php~, etc.

– File upload PHP exploitation

Spotting holes in source:– Grep!– Look for ‘vulnerable’ operations with variable

substitution

Finding the Holes

Vulnerable operations:– PHP Functions: include(), require(), eval(),

exec(), passthru(), ``, system(), popen(), fopen(), readfile(), file()

– Variable functions:

– Variable dereferencing:$hello = “confdir”; $$hello = “http://myhost”; echo “$confdir”;

$hello = “echo \”hi!\””; $hello();

Securing PHP

Later versions of PHP are very configurable Drastic Measures:

– Set open_basedir• Prevents any file open operations on files outside

specified directories

– register_globals off• Protects environment from user pollution

• The ultimate protection

• Breaks 99.99% of existing scripts

Securing PHP

Drastic Measures cont:– safe_mode on

• Heaps of restrictions

• Restrict which commands can be executed

• Disable functions, e.g exec(), system()

• Restricts file access based on ownership

• Kills file upload

• Designed for use in ISP environments

Securing PHP

Slightly less painful measures:– display_errors off, log_errors on

• Prevent error messages giving clues as to how code works

• Makes debugging hard

Mostly painless measures: – allow_url_fopen off

• Stops remote files functionality

• No more remote includes

Securing PHP – Future?

Capabilities– Defined once, enforced throughout script

Taint Mode– Tainted variables cannot be used in

• Include/Require Statements

• File Open Operations

• SQL Queries (maybe automatically filtered)

Securing Web Applications

External Solutions:– Use suEXEC for CGI under Apache– SubDomain (http://www.immunix.org) under

Linux

Securing Web Applications

Programming Concepts– Limit calls to external programs– Pass all user input through metacharacter filter

Securing Web Applications

Architecture– Adopt client/server architecture in Web

Applications– Server can rely on environment– Server can limit trust in client

Web Languages

The basic issue:– Web languages attempt to make rapid

development as simple as possible by being feature rich.

– This leads to security problems• Functions do more than expected to do

• Programmers (Web Designers!) get lazy

– Security is largely a code quality issue– Coders don’t want to give up ease for security

Thankyou!

Questions? SecureReality Web Site:

http://www.securereality.com.au

Email:

shaun@securereality.com.au