Transcript Here is the Original File

Whitewater HTTP Vulnerabilities
Nick Berry, Joe Joyce, & Kevin Vaccaro
.
Syntax & Routing
Attempt to capture and modify HTTP traffic between a client
and server on a closed network. It is assumed that HTTP is
the only protocol in use and there are no other security
measures currently implemented on the web server.
Test Method: Capture client HTTP traffic via a proxy server
on a LAN and attempt to read, edit, and forward the HTTP
messages to the web server. Once the edited message has
been received by the server, it will serve a resource that was
not originally requested by the client.
Conclusions: HTTP traffic was able to be captured and
modified on all four web servers on each operating system.
There is no mechanism for obfuscating HTTP traffic in any of
the servers tested when exclusively using the HTTP protocol.
Project Summary
Authentication
Identify web servers more vulnerable to attack
due to their implementation of recent changes to
the HTTP protocol.
The project team focused on five areas of HTTP
to find scenarios in which servers are not secure.
Attempt to obtain confidential authentication credentials sent
from a client requesting a resource that is within a protection
realm on the HTTP server.
Servers Tested:
Caching
Test Method: Capture client traffic via a proxy server and
attempt to use the clients credentials to gain access to
protected resources on the web server.
Conclusions: All four web servers used a base-64 encoding
to receive the authentication request. The IIS server
performed differently in that it decoded the base-64 into a
Windows-1252 charset instead of UTF-8. By intercepting the
interaction between the client and the server, it is possible to
intercept the encoded credentials, decode them, and use
them to access protected resources. Although encoding is
not encryption, it provides some method of obfuscation of the
authentication credentials.
Attempt to obtain user authentication credential data from a
server side cache via HTTP.
Semantics & Content
Test Method: Send HTTP requests with the intent of
obtaining data in the webserver authentication cache.
Attempt to obtain product information through HTTP headers
that disclose information about the sender’s system.
Attackers may be able to use this data to more effectively
attack the system.
Conclusions: Using strictly HTTP, none of the web servers
would serve data from their authentication cache. Each
server had a different method of caching authentication
credentials, but none could be accessed via HTTP alone.
Operating Systems:
Range Requests
Use the Range header to request byte ranges that overlap
and are out of order with the goal of denying service to
legitimate clients. Serving the resource in many parts uses
much more time, memory, and bandwidth than a normal
Range request.
Test Method: Send HTTP requests with a ‘Range’ header
requesting several overlapping and out of order byte ranges.
Conclusions: IIS, Tomcat, and NGINX each served
overlapping and out of order byte ranges, requiring much
more data to be served.
Apache, however, would aggregate the byte ranges, so no
overlapping or out of order byte ranges would be served. The
size of the served resource was significantly smaller than the
resource served by the other three web servers.
POSTER TEMPLATE BY:
www.PosterPresentations.com
Testing Method: Capture HTTP requests between the
server and client and try to obtain operating system and
server data from the “Server” header.
Conclusions: NGINX, Apache, and IIS responded with the
name of the server, the version number, and the operating
system on which the server was running. Only Tomcat sent a
“Server” header that did not contain the operating system on
the host machine.
Testing Tools:
Security Rating Key
Signifies some server functionality that mitigates vulnerabilities
relating to a specific area of the HTTP protocol.
- Signifies vulnerabilities that can be exploited by HTTP messages
implementing the new functionality.