HACKING WEB PLATFORMS

The web platform is comprised of common off-the-shelf (COTS) software that sits atop the host operating system but below the custom application logic.

The web platform commonly includes:

   • Web server software (such as IIS or Apache)
   • Extensions to the web server (ISAPI, or Apache modules)
   • Dynamic execution environments (ASP.NET, PHP, & J2EE)
   • Services and daemons (forums or web guestbook)

Historically, web server software vulnerabilities were one of the easiest ways to exploit a web site, but more recently, many popular web server software development teams have become increasingly security conscious, primarily because their products have taken a tremendous beating from hackers for so many years.

Attacks

• Exploitation with Metasploit
• Manual exploitation
• Evasion techniques

EXPLOITATION USING METASPLOIT

The Metasploit Framework is an open-source platform for developing, testing, and launching exploit code. It is easily amplified with pluggable exploit modules contributed by the worldwide community of folks engaged in “…legal penetration testing and research purposes only,” according to the Metasploit web site. Metasploit provides for easy exploitation of all types of vulnerabilities, including web platform holes.

MANUAL EXPLOITATION

Sophisticated attackers may expend substantially more time and effort to bring a web server down, so we’ll take some time in this section to illustrate some of the finer points of a handcrafted attack. The key things to notice in this example are the increased level of time and skill brought to bear on identifying and then exploiting the vulnerability, as opposed to the Metasploit example. Take-home point: just because you run a web platform that doesn’t rate a ton of attention from projects like Metasploit doesn’t mean you’re any less vulnerable!

Techniques

• Source code analysis
• Using tools like fuzzer
• Static analysis

EVADING DETECTION

Log Evasion Using Long URLs

Some web server software fails to log URI data beyond a certain number of characters.

For example, Sun-One Application Server & IIS only logs the first 4,042 characters of a request URI.This limit was set to prevent DoS attacks by attackers flooding the logs, but attackers have now used this feature for their own benefit.

When writing to the web logs, IIS will automatically truncate the query string with ellipses “…” when the length exceeds 4,097 characters. This allows an attacker to create a fake query that is filled with 4,097 characters with an attack appended at the end. The web server will still process the request properly and discard the fake parameter, allowing the attack to succeed, but it will not log the request hide

SQL Injection Attack

This kind of an attack is easily noticeable in the web logs if the attack is executed via the query string, as
shown in the following example.

GET /article.asp?id=convert(int,
(select+top+1+name+from+sysobjects+where+xtype='u')) HTTP/1.0
Connection: Close
Host: www.site.com
User-Agent: Mozilla/4.0
(compatible; MSIE 6.0; Windows NT
5.1; SV1;.NET CLR 1.1.4322)

The web server responds as normal, and
this is what the log entry looks like:
2005-10-04 22:10:24 127.0.0.1 -
127.0.0.1 80 GET /product_detail.
aspid=(int,(select+top+1+
name+from+sysobjects+where+xtype='
u'))|170|80040e07
|[Microsoft][ODBC_SQL_Server_
Driver][SQL_Server]Syntax_error_
converting_the_nvarchar_value_'tbl_Globals'_to_a_column_of_data_
type_int. 500 4910 561Mozilla/5.0+
(Windows;+U;+Windows+NT+5.1;+enUS;+
rv:1.7.10)+Gecko/
20050716+Firefox/1.0.6

You can clearly see from the bolded text SQL injection attack occurring and the database error that was returned in the response. It’s quite easy, at this point, to identify someone attempting SQL injection on the application by parsing the IIS logs for either any SQL database errors going back to the user or any SQL keywords being used in the request.

Let’s now look at the same request, hidden inside a long URI designed to evade detection in the IIS logs. We’ll use the same attack request but with a fake parameter of foo being used to fill the log buffer:


GET /product_detail.asp?id=convert (int,(select+top+1+name+from+
sysobjects+where+xtype='u'))&foo=<
4097 a's> HTTP/1.0Host: localhost
User-Agent: Mozilla/4.0
(compatible; MSIE 5.01; Windows NT
5.0)

Because the foo parameter is fake, the web application ignores it and the attack executes successfully. The log file logs the following request:

2005-10-04 22:31:01 127.0.0.1 -
127.0.0.1 80 GET /product_detail.
asp ...500 4965 4287 Mozilla/4.0+
(compatible;+MSIE+5.01;+Windows+NT+
5.0) - -

Notice how the query string has now been replaced with “...”and no error text from the response is logged.

Hiding Requests Using TRACK

TRACK is an HTTP method supported only by IIS that does exactly the same thing as theTRACE method. The response to a TRACK request is a repeat of the request sent. Here’s an example:

TRACK /HTTP/1.1Host: www.site.com

User-Agent: Mozilla/4.0

(compatible; MSIE 5.01; Windows NT5.0)

HTTP/1.1 200 OKServer:

Microsoft-IIS/5.xDate: Tue, 04

Oct 2005 23:07:12 GMT

X-Powered-By: ASP.NET

Content-Type: message/httpContent-

Length: 102

TRACK / HTTP/1.1

Host: www.site.com

User-Agent: Mozilla/4.0

(compatible; MSIE 5.01; Windows NT5.0)

In Microsoft IIS 5.x, all TRACK requests are not logged by the web server. This request by itself is not very dangerous and cannot be used to retrieve pages or submit attacks, but it can be used in DOS attacks.

Security best practices

• Implement Network Access Control
• Implement Firewall, DOS Protection
• Only open 80, 443 port for inbound connection.
• Keep Up with Security Patches
• Harden your system
• Don’t Put Private or sensitive Data in Source Code
• Don't use cleartext passwords in App configuration files.
• Rename include fi les to .asp, .php, or the appropriate extension for your web application platform.
• Regularly Scan Your Network for Vulnerable Servers
• Know What It Looks Like When You Are/Have Been Under Attack
• Use filesystem monitoring tools (tripwire)

IIS Hardening

• Turn off detailed error
• Install Web Folders on a Drive Other Than the System Drive
• Eliminate unused extension
• Use filesystem access control lists
• Use UrlScan
• Always Use NTFS for Web Server Volumes
• Move, Rename, Delete, or Restrict Any Powerful Utilities

Apache Hardening

• Disable Unnided Modules
• Implement ModSecurity
• Run Apache server in a contained environment (Chrooting)
• Properly configure your server
• Restrict root access
• Use tools to check hardening

Mod Security Features

• Request filtering
• Anti-evasion techniques
• HTTP filtering rules
• Full audit logging
• HTTPS intercepting
• Chroot functionality
• Mask web server identity

PHP Best Practices

• Apply strict input validation to all user input.
• Use eval(),passthru(),system(), and other functions sparingly and without user input.
• Turn register_globals off
• Restrict File Access (open_basedir)
• Disable risky functions
• Remove PHP Banner (expose_php)
• Set display_errors off
• Turn on safe mode
• Disable remote file operation (allow_url_open)

Common server vulnerabilities:

Default settings– These settings such as default user id and passwords can be easily guessed by the attackers. Default settings might also allow performing certain tasks such as running commands on the server which can be exploited.

Misconfiguration of operating systems and networks – certain configuration such as allowing users to execute commands on the server can be dangerous if the user does not have a good password.

Bugs in the operating system and web servers– discovered bugs in the operating system or web server software can also be exploited to gain unauthorized access to the system.

Lack of security policy and procedures– lack of a security policy and procedures such as updating antivirus software, patching the operating system and web server software can create security loop holes for attackers.