Attacking the Application Server

makeshiftklipInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

79 εμφανίσεις

The Web Application Hacker’s
Handbook, 2ed.: Chapter 18

By Heath Carroll


Vulnerable Server Configurations


Vulnerable Server Software


Web Application Firewalls


Examples and Questions


Summary


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


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


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)



Rick
Astley’s

never
gonna

give you up…


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)


Examples applicable to App server interfaces:

Websites which list many common default credentials:

www.cirt.net/passwords

www.phenoelit
-
us.org/dpl/dpl.html



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


Hacker Tools:


Nikto



Burp


Google


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.



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)


DEMO TIME!


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)


Server administrators may forget to secure the default host (the
machine itself) on a
v
irtual
h
ost server


The virtual hosts are secured, but the default host is not.


Security features bypassed when accessing the default host.


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.


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


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


Yes, buffer overflows occur in server
-
side services, too.


Especially in newer technologies


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.


m
ay allow arbitrary file access outside of the web root


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


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


Not as useful as you’d think


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?

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



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


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