Attacking the Application Server

Vulnerable Server Configuration

Default Credentials

  • Apache Tomcat:
    • admin - (none)
    • tomcat - tomcat
    • root - root
  • Sun JavaServer:
    • admin - admin
  • Netscape Enterprise Server:
    • admin - admin
  • Compaq Insight Manager
    • administrator - administrator
    • anonymous - (none)
    • user - user
    • operator - operator
    • user - public
  • Zeus
    • admin - (none)

Default Content

  • Debug Functionality
    • Functionalities meant to check diagnostics of a system.
    • Example: phpinfo()
  • Sample Functionality
    • Some servers include sample scripts and pages
    • Usually don't provide opportunities for an attacker.
    • May not always be the case:
      • Contain security vulnerabilities
      • Implement functionality directly useful to attacker
    • Example:
      • Dump Servlet in Jetty version 7.0.0
        • /test/jsp/dump.jsp
        • Prints installation and request info
        • Can perform simple XSS
        • /test/jsp/dump.jsp?%3Cscript%3Ealert(%22xss%22)%3C/script%
  • Powerful Functions
    • App servers may allow web archives (WAR files) to be deployed over HTTP port
      • With proper administrative credentials
    • Deployment process is a huge target
    • Common exploit frameworks will scan for default credentials, upload a web archive with a backdoor, and execute it to get a command shell
  • JMX
    • Installed by default in a JBoss installation
    • ○○"Raw view into the microkernel of the JBoss Application Server"
    • Allows you to access Managed BEans in a JBoss App. Server directly.
    • JMX console contains functionality allowing arbitrary WAR files to be deployed
  • Oracle Applications

Directory Listings

  • Three types of responses:
    • Return default response such as index.html
    • Return an error
    • Return listing of directory contents
      • Can be inconsequential
      • Reasons it may be bad:
        • Not enforcing proper access control
        • Files/directories are in web root of server

WebDAV Methods

  • A collection of HTTP methods used for Web-based Distributed Authoring and Versioning
  • Widely available since 1996, and may include:
    • PUT
    • DELETE
    • COPY - Copies specified resource to location given in Destination header
    • MOVE - Moves specified resource to location given in Destination header
    • SEARCH - Searches directory path for resources
    • PROPFIND - Retrieve info about a specific resource
    • OPTIONS: list the HTTP methods

The Application Server as a Proxy

  • Web server may be configured to act as forward or reverse HTTP proxy server
  • Example attacks:
    • Leverage server to attack other systems
    • Leverage server to connect to other hosts on internal network
    • Leverage server to connect to services on proxy host itself
  • 2 ways to cause forward proxy to make onward connections:
    • Make HTTP request with full URL and optionally a port number.
      • Make sure content is from the other host, not the original one.
    • Use CONNECT method to specify hostname and port number
      • If it responds with Connection established, its proxying.
  • Process:
    • Use GET and CONNECT requests to connect to other servers
      • Connect to different IP addresses and ports
      • Try to connect to common port numbers on the web server using 127.0.0.1

Misconfigured Virtual Hosting

  • Process:
    • Submit GET request using:
      • Correct HOST header
      • Random HOST header
      • Server IP as HOST header
      • No HOST header
    • Compare request responses

Securing Web Server Configuration

  • Things to do:
    • Change default credentials
    • Block public access to admin functions/interfaces
    • Remove default content and functionality
    • Harden remaining default content
    • Check web directories for directory listings
    • Disable all methods not used by the app
    • Ensure web server not configured to run as a proxy
      • If necessary, harden the configuration
    • Ensure security hardening in place for virtual hosting

Vulnerable Server Software

  • Most common new vulnerabilities exist in:
    • Server-side extensions in IIS and Apache
    • New web servers created from the ground-up.

Application Framework Flaws

  • The .NET Padding Oracle
    • Encryption process:
      • Get plaintext message
      • Pad message with required number of padding bytes
      • XOR first plaintext block with initialization vector
      • Encrypt the XORed value from step 3 with Triple-DES
      • Encrypt rest of message recursively
        • Cipher Block Chaining (CBC)
      • XOR second plaintext block with encrypted previous block
      • Encrypt the XORed value using Triple-DES
    • The Padding Oracle
      • September 2010 .NET had an information disclosure flaw. Incorrect padding in message resulted in 500 HTTP response code.
      • Process:
        • Supply string with only first two ciphertext blocks to the app
          • These are the IV, followed by the first block of ciphertext
          • Supply IV of only 0's
        • Make series of requests, incrementing last byte of this IV
        • Last byte XORed with last byte in the ciphertext
        • Unless last byte is 0x01, the algorithm throws an error
        • Leverage the error condition
          • Known that: x XOR y = 0x01
            • Failure to do so causes 500 error
          • So, just brute-force last byte until results in 0x01
            • Basically, brute-force until 200 response occurs.
          • Repeat as needed
          • Can be used to decrypt an entire message.
          • Can also be used to encrypt a message

Memory Management Vulnerabilities

  • Apache mod_isapi Dangling Pointer
    • 2010 flaw where mod_isapi could be forced to be unloaded from memory when errors occur.
    • Function pointers still in memory can be called from ISAPI functions referenced, accessing arbitrary parts of memory.
  • Microsoft IIS ISAPI Extensions
    • Vulnerability: IIS 4 and 5 have many ISAPI extensions enabled by default.These were found to have buffer overflow vulnerabilities.
      • Can leverage to execute arbitrary code in Local System context
      • Allowed the Nimda and Code Red worms.
    • Seven Years Later: Flaw in IPP service in 2008, but it is not enabled by default.
  • Apache Chunked Encoding Overflow
    • Vulnerability: Buffer overflow caused by integer signedness error in Apache web server 2002.
    • Eight Years Later: Integer overflow error found in 2010 Apache mod_proxy when handling chunked encoding in HTTP responses.
  • WebDAV Overflows
    • Vulnerability: Buffer overflow in core Windows OS discovered in 2003. Exploitable by many means, including WebDAV support built into IIS 5.
    • Seven Years Later: WebDAV implementation in 2010 had overflow vulnerability with extremely long paths in OPTIONS requests in Sun's Java System Web Server.

Encoding and Canonicalization

Finding Web Server Flaws

  • Most likely won't find vulnerabilities listed in the past two sections, but rather new ones that now exist in new updates and implementations.
  • Good resources:
    • Security Focus
    • OSVDB
    • Bugtraq
    • Full Disclosure
    • Exploit Database (exploit-db)
    • Metasploit
    • Open Source web server security updates (nowadays these are less detailed)

Securing Web Server Software

  • Choose Software with a Good Track Record
  • Apply Vendor Patches
  • Perform Security Hardening
    • Disable functionalities that aren't required
    • Consider using managed code rather than custom-written server extensions
    • Rename default functions and resources
    • Apply least-privilege
  • Monitor for New Vulnerabilities
  • Use Defense-in-Depth
    • Restrict web server capabilities
    • Use strict network-level filters
    • Use an IDS

Web Application Firewalls

  • Process:
    • Check for presence of WAF:
      • Submit random parameter name to application with clear attack payload in the value
        • If returned in response, submit many fuzz strings and encoded variants
      • Confirm behavior by performing attacks on variables in app
    • Methods of bypassing WAF:
      • Use benign strings unlikely to exist in standard signature database
      • If request blocked, try using in a different location or context
        • Different method, different area (in body of request instead of a parameter), etc.
      • Try submitting parameter as a cookie if ASP.NET
        • Request.Params['foo'] gets the cookie named foo
      • Find areas where user input is used and submitted, then map these.

results matching ""

    No results matching ""