attacking the application server

28
Attacking the Application Server The Web Application Hacker’s Handbook, 2ed.: Chapter 18 By Heath Carroll

Upload: robbin

Post on 26-Feb-2016

39 views

Category:

Documents


1 download

DESCRIPTION

Attacking the Application Server. The Web Application Hacker’s Handbook, 2ed.: Chapter 18 By Heath Carroll. Chapter Overview. Vulnerable Server Configurations Vulnerable Server Software Web Application Firewalls Examples and Questions Summary . Synopsis. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Attacking the Application Server

Attacking the Application ServerThe Web Application Hacker’s Handbook, 2ed.: Chapter 18By Heath Carroll

Page 2: Attacking the Application Server

Chapter Overview• Vulnerable Server Configurations• Vulnerable Server Software• Web Application Firewalls• Examples and Questions• Summary

Page 3: Attacking the Application Server

Synopsis• Web applications are layered upon frameworks

that provide much of their functionality• These layers may be vulnerable and may allow a

hacker to compromise the entire web app.• Two major categories of vulnerabilities are of

concern to us:• Server configuration weaknesses• Application server software exploits

Page 4: Attacking the Application Server

Vulnerable Server Configurations• Several major opportunities for attack:• Default Credentials• Default Content• Directory Listings• WebDAV Methods• Application Server as a Proxy• Misconfigured Virtual Hosting• Securing Web Server Software

Page 5: Attacking the Application Server

Vulnerable Server Configuration: Default Credentials• Servers and other interfaces may have

default credentials still in place.• Concept Example 1:

Jailbroken iPhone: devices have default admin level access with user account root and password alpine (exploited with ikee worm in 2009)

Page 6: Attacking the Application Server

ikee worm Rickrolled victims in

2009Rick Astley’s never

gonna give you up…

Page 7: Attacking the Application Server

Vulnerable Server Configuration: Default Credentials• Servers and other interfaces may have default

credentials still in place (cont’d).• Concept Example 2:

Ever forgotten your wireless password?If you ever log in to an unsecured Wi-Fi router, try

going to 192.168.1.1 in your browser. When prompted for a username and password look up the device defaults and you might be able to filter every other user but yourself (or something more malicious)

Page 8: Attacking the Application Server

Vulnerable Server Configuration: Default Credentials• Examples applicable to App server interfaces:

Websites which list many common default credentials:www.cirt.net/passwordswww.phenoelit-us.org/dpl/dpl.html

Page 9: Attacking the Application Server

Vulnerable Server Configuration: Default Content• The default software vender settings may also

leave useful system functions unsecured:• Debug and test functions (phpinfo.php)• Sample scripts useable by admins (Jetty Dump Servlet)• Erroneously unprotected functionality (common examples

exploit the ability to upload Web ARchives, which can later be triggered to provide a backdoor) • Man pages

Page 10: Attacking the Application Server

Vulnerable Server Configuration: Default Content• Hacker Tools:• Nikto • Burp• Google

Page 11: Attacking the Application Server

Vulnerable Server Configuration: Directory Listings• Why would directory listings help an attacker:

• The obvious reason: Useful scripts and stuff that shouldn’t even be in the file tree may be there. (i.e. logs, backup files, etc.)

• Less obvious: The web app may not enforce proper access controls over its file system, relying instead on obfuscation to protect sensitive data and files. Just knowing their URLs would allow an attacker access to them.

Page 12: Attacking the Application Server

Vulnerable Server Configuration: WebDAV• Web-based Distributed Authoring and Versioning• HTTP methods (like GET and POST) that extend the

standard HTTP protocol methods.• More widely used as “the cloud” expands• PUT, DELETE, COPY, MOVE, SEARCH, PROPFIND

• HTTP OPTIONS method can commonly be used to find the other methods which may be immediately available (with sufficient privileges)

Page 13: Attacking the Application Server

Vulnerable Server Configuration: WebDAV

DEMO TIME!

Page 14: Attacking the Application Server

Vulnerable Server Configuration: WebDAV

Page 15: Attacking the Application Server

Vulnerable Server Configuration: The Application Server as a Proxy• If an app server is configured as a forward proxy

(or can be configured as one by an attacker) some functionality opens up:• Effectively “spoof” the attackers IP address when

attacking other systems on the Internet• Connect to other hosts on the server’s network that are

normally firewalled away from the attacker• Connect to other services on the server itself to exploit

trust and authentication relationships elsewhere (uses the loopback interface)

Page 16: Attacking the Application Server

Vulnerable Server Configuration: Misconfigured Virtual Hosting• Server administrators may forget to secure the

default host (the machine itself) on a virtual host server• The virtual hosts are secured, but the default host is not.• Security features bypassed when accessing the default

host.

Page 17: Attacking the Application Server

Vulnerable Server Configuration: Securing Web Server Configuration• All these problems! So how do we secure them?• Change default credentials and remove default accounts • Block access to everything not required for the server to

function (firewall ports and interfaces)• Remove default and extra content. Use Nikto.• Check all directories for listings, supply index.html for

each• Disable all HTTP and WevDAV methods not required• Make sure not configured as proxy server. If required,

harden all connects using ACLs at the network layer• Ensure default host enforces the same security policy as

virtual ones. Use Burp.

Page 18: Attacking the Application Server

Vulnerable Server Software• Developers tend to rely on the built in security

features of the software they use to build their web apps.

• Common exploitable areas include:• Application Framework Flaws• Memory Management Vulnerabilities• Encoding and Canonicalization• Finding Web Server Software

Page 19: Attacking the Application Server

Vulnerable Server Software: Application Framework Flaws• ASP.NET is a very well developed framework for

the building of robust web apps. Up until 2 years ago there was a CBC cryptographic algorithm vulnerability.• second most used web app server language, first most

used framework for developing in it • Comparable to Obj-C and Cocoa Touch framework

• Comparison of Web App Frameworks

Page 20: Attacking the Application Server

Vulnerable Server Software: Memory Management Vulnerabilities• Yes, buffer overflows occur in server-side services,

too.• Especially in newer technologies

Page 21: Attacking the Application Server

Vulnerable Server Software: Encoding and Canonicalization• Remember Chapter 3? It still applies.• Especially if different components/layers handle encoding

schemes in different ways.• Especially if further decoding is performed at each step.

• Each layer should perform the same decoding steps.

• Most prevalent weakness that can be exploited is path traversal.• may allow arbitrary file access outside of the web root

Page 22: Attacking the Application Server

Vulnerable Server Software: Finding Web Server Flaws• Use the Internet:• www.exploit-db.com• www.metasploit.com/• www.grok.org.uk/full-disclosure/• osvdb.org/search/advsearch• www.google.com

• Test on a locally installed version

Page 23: Attacking the Application Server

Vulnerable Server Software: Securing Web Server Software• Make sure any steps you perform do not violate

the contract with your vendor• Go with a well renowned product• UPDATE ASAP• Harden your server by disabling any unnecessary

functionality, port, and user accounts. Apply common sense

• Keep an eye on the horizon for the latest vulnerabilities to the services you use.• Bugtraq and Full Disclosure

• Use Defense-in-Depth (layered security)• Test your system

Page 24: Attacking the Application Server

Web Application Firewalls• Not as useful as you’d think

Page 25: Attacking the Application Server

End of Chapter Questions• Under what circumstances does a web server display

a directory listing?• What are WebDAV methods used for, and why might

they be dangerous?• How can you exploit a web server that is configured

to act as a web proxy?• What is the Oracle PL/SQL Exclusion List, and how

can it be bypassed?• If a web server allows access to its functionality over

both HTTP and HTTPS, are there any advantages to using one protocol over the other when you are probing for vulnerabilities?

Page 26: Attacking the Application Server

End of Chapter Questions1. A web server will display a directory listing if you request a URL for a

directory and:a. the web server cannot find a default document such as index.html;b. directory listings are enabled;c. you have the required permissions to access the directory.

2. WebDAV methods allow web-based authoring of web content.a. These methods may be dangerous if they are not subjected to strict access control.

Further, because of the complex functionality involved, they have historically been a source of vulnerabilities within web servers – for example, as an attack vector for exploiting operating system vulnerabilities via the IIS server.

3. If the proxy allows connection back out to the Internet, you could use it to attack third party web applications on the Internet, with your requests appearing to originate from the misconfigured web server.a. Even if requests to the Internet are blocked, you may be able to leverage the proxy

to access web servers within the organization that are not directly accessible, or to reach other web-based services on the server itself.

Page 27: Attacking the Application Server

End of Chapter Questions4. The PL/SQL Exclusion List is a pattern-matching blacklist designed to

prevent the PL/SQL gateway from being used to access certain powerful database packages.a. Various bypasses have been discovered to the PL/SQL Exclusion List filter.

These essentially arise because the filter employs very simple expressions, while the back-end database follows much more complex rules to interpret the significance of the input. Numerous ways have been discovered of crafting input that does not match the blacklist patterns but nevertheless succeeds in executing the powerful packages within the database.

5. It is possible that using HTTPS for communication may conceal your attacks from some network-layer intrusion detection systems. Using HTTP, however, will typically enable your automated attacks to execute much faster. The application may contain different content or behave differently when accessed via the different protocols, so in general you should be prepared to test using both.

Page 28: Attacking the Application Server

Summary• Web Applications are only as secure as their

weakest layer • The web server supporting a Web App is a viable

target for attackers• Default configuration and content exploits, unintentionally

open functionality, and flaws in the frameworks used can all lead to viable exploits

• Automated tools are very useful when attacking a server (for offensive or defensive purposes).