Immediate intrusion detection: Catching hackers red-handed on your web server!

Introduction

This white paper focuses on how administrators can set up their web servers successfully and safely. Describing the tools used by hackers to gain backdoor access to your IIS web servers, this paper details the necessary steps to detect successful intrusions on your network, as well as explaining how to prevent such attacks to your web server.

The following topics are covered:

• IIS servers = prime hacker targets

• Open to attack

• Tools of the trade

• The Internet Printing Protocol (IPP) exploit

• The UNICODE and CGI-Decode exploits

• Custom-made applications

• Leftovers: detecting an intrusion

• Intrusion detection through centralized event log monitoring

• List of system files

• How to detect attacks on your server

• Step 1: Configuring your domain & web server to audit objects

• Step 2: How LANguard S.E.L.M. detects attacks & notifies admin

• Step 3: Testing your new IDS

• General note

IIS servers = prime hacker targets

Internet Information Services (IIS) web servers - which host web pages and serve them to users - are highly popular among business organizations, with over 6 million such servers installed worldwide. Unfortunately, IIS web servers are also popular among hackers and malicious fame-seekers – as a prime target for attacks!

As a result, every so often, new exploits emerge which endanger your IIS web server’s integrity and stability. Many administrators have a hard time keeping up with the various security patches released for IIS to cope with each new exploit, making it easy for malicious users to find a vulnerable web server on the Internet. There are multiple issues which can completely endanger your Web server - and possibly your entire corporate network and reputation.

Figure 1: Many exploits give hackers access to pages and code that they are not authorized to view

Open to attack

Hacker tools abound on the Internet. With them, the average teenage hacker can easily attack and even control your web server, with the possibility of penetrating your internal network. In other words, it is not too difficult for outsiders to access classified corporate information. Worse still, hackers need not be teenagers out for a thrill, as commonly presumed: disgruntled employees and competitors, for instance, may have their own reasons for breaking into confidential areas of your network.

Few hacker attacks are actually instantly recognizable as such, and fewer still become high profile affairs reported in the media. Most attacks are not easy to discover because many intruders prefers to remain hidden so that they can use the IIS web server they have hacked as a launch base for attacks on far more important or popular web servers. Apart from endangering your own web site’s integrity, such use of your server can render you liable should it be used to launch an attack on another organization.

Tools of the trade

Many tools exist to facilitate hackers who wish to deface a web site. Such tools are so easy to use that even someone with no prior hacking experience can make a mess out of a web server in no time at all.

The Internet Printing Protocol (IPP) exploit

Figure 2: IPP exploit made easy

A program that makes use of this exploit is Internet Printing Protocol Exploit v.0.15 (Figure 2). This is based on the infamous original exploit code in a C program file named “jill.c”, made public by a hacker using the alias “dark spyrit”.

This application uses a vulnerability in the IPP buffer overflow on an IIS web server. All the hacker needs to do is type in the name of the targeted web server (or a computer with IIS installed on it) and click on “Connect”.

Upon connecting, the application will send the actual string that overflows the stack, leading to the execution of custom code (that is known as shell code) and connecting the file cmd.exe to the specified port on the attacker’s side (default being 31337).

This can bypass typical firewall configurations and other similar security measures.

Once that is done, the hacker is presented with a command line and SYSTEM access, from where he could carry out a number of activities that an administrator would definitely not have authorized, such as gaining access to databases which could contain credit card details and other such confidential data.

The UNICODE and CGI-Decode exploits

Figure 3: Unicode exploit using Internet Explorer

Two other exploits preferred by web site defacers include the UNICODE and CGI-Decode exploits. Here, the hacker can simply use the browser itself to do anything on a target machine that is running an un-patched version of IIS. All it takes is Internet Explorer and a “magic string” to execute anything under the anonymous account of the IIS. Figure 3 shows a directory dump of C:\ of the IIS server in the web browser itself! This is just a simple example to demonstrate that the hacker can gain access to your web server’s hard disk.

Initially, this access is limited to the user rights of the IIS anonymous user account (IUSR_computername). Once the hacker has IIS anonymous access, he can easily upload an ASP file, which can escalate his access to SYSTEM privileges. Such an action would give him full access to the hacked computer, meaning he can do anything.

Custom-made applications

Though such methods are simple enough, many web site cracker groups produce their own applications to automate the process of defacing a web site.

Figure 4: IIS Storm by m0sad

One such group is M0sad, an Israeli hacker unit that developed and released a hacking tool named IIS Storm v.2 (see Figure 4). An excerpt from the product manual runs: “IIS Storm is a tool made for Remote Web Site Defacement that is running IIS (Internet Information Serve [NT platform]) and that also vulnerable to the Unicode Exploit.”

Tools such as this give full hacking capabilities to both skilled and unskilled hackers. IIS Storm also allows users to hide their original IP address through anonymous proxies, and to easily replace files on the target website with their own custom HTML pages.

PoizonB0x, another notorious group of self-proclaimed “cyber-terrorists” and “net-warriors”, created iisautoexp.pl, an automated tool that handles all the legwork required to gain access and perform defacing operations.

To deface a web site, all the malicious user has to do is simply give the name of the web site to the script and run it. If the web site is vulnerable to attack (that is, if it does not have the appropriate patches applied), the front page (index.htm, default.htm, default.asp or variants) is changed to read “PoizonB0x Ownz YA”. This way, hackers can create a batch file with the names of their target web sites, producing a mass defacement of IIS web servers. This script can be adapted and run on both Windows and UNIX machines.

Leftovers: detecting an intrusion

Figure 5: An example of a hacked web site

There are more than 6 different known exploits for IIS, and hackers and security auditors have created several tools for each that make different use of these issues.

Some administrators will only notice that their web site has been hacked when, instead of seeing corporate material on the company web site, they are instead surprised with something like the example in Figure 5. Of course, this is not the preferred way to detect that your web server has been penetrated!

To make matters worse, many hackers prefer stealth and will not deface a web page. Instead they make sure that they do not leave any traces of their intrusion and may even delete the log files created by IIS to hide their activity so that the administrator will never notice that the server has fallen victim to an attack.

Intrusion detection through centralized event log monitoring

The fact is that almost all exploit tools for IIS servers make use of the same system files that are readily available on the server itself. Therefore, monitoring the activity on these files will successfully catch malicious activity.

However, to monitor each and every single server and workstation on the corporate network would be far too time-consuming and tedious. Administrators would not be able to cope with such a laborious approach, no matter how much this would help meet their intrusion detection needs.

However, a network-wide security event log monitor such as GFI’s LANguard Security Event Log Monitor (S.E.L.M.) conveniently centralizes the security event logs of all your Windows NT/2000 servers and workstations and alerts you to possible intrusions/attacks in real time.

An added benefit of this approach is that, because it analyses the system event logs, rather than sniffing network traffic like conventional IDS products do, LANguard S.E.L.M. is not impaired by switches, IP traffic encryption or high speed data transfer.

List of system files

The system files used by most exploit tools for IIS servers are given below. By monitoring file activity here, LANguard S.E.L.M. can detect intruders.

1. cmd.exe: This is the command line emulation program in Windows NT and 2000. From here, users can administer the server via the command line rather than the GUI (the graphic user interface in Windows machines). Hackers use this to create and delete files and run programs.

2. ftp.exe: This is the command line FTP client available with all Microsoft Windows platforms. Hackers use this to obtain the files they need on the server machine from a remote FTP server.

Figure 6: The command line

3. net.exe: This program enables machine administration. Under the system account, hackers can use this tool to create backdoor users and groups, start and stop services, access other machines on the network, and more.

4. ping.exe: This program simply sends an ICMP echo packet to remote hosts. Hackers can use your server together with other vulnerable servers to run ping against a target host, thus creating a DDoS (Distributed Denial of Service attack) on the target.

5. tftp.exe: This is a TFTP client that is also available with all Microsoft Windows machines. Some hackers prefer this to ftp.exe and will use it to get the files they need to further penetrate the IIS server.

When a cracker runs cmd.exe using the UNICODE exploit, it is actually run by the Internet Guest Account (IUSR_machinename). Since this user has no business running this file, LANguard S.E.L.M. can log any events in which this account runs cmd.exe. This way, LANguard S.E.L.M. can immediately inform the administrator of the intrusion.

Buffer overflow attacks obtain the SYSTEM account instead. This means that from here, the malicious user who has already intruded the machine can change to any other user and basically do anything that the Operating System itself can. However if LANguard S.E.L.M. is enabled to monitor cmd.exe and log whenever the SYSTEM account has accessed this file, the network administrator will now be able to detect such activity - because to change to another user, tools make use of the command line itself.

How to detect attacks on your server

After examining how intruders operate, administrators can now configure their server and LANguard S.E.L.M. to catch hackers red-handed.

 

Step 1: Configuring your domain & web server to audit objects

To monitor commonly used files, object auditing must be enabled in Windows 2000. This allows the administrator to be notified via the event log, and benefit from LANguard S.E.L.M. by being alerted upon successful intrusion.

Figure 7: Audit Policy – object access

If the web server is a standalone server, to enable object auditing, you must:

1. Go to the Local Security Settings. This can be done from the CONTROL panel – Administrative Tools – Local Security Policy.

2. From the MMC interface, select Local Policies and then Audit Policy.

3. Double-click on Audit Object Access and select Success and Failure.

4. If on the other hand, the web server is part of the domain, you must enable object auditing as a Domain Policy (rather than just Local Policy). To enable object auditing:

5. Go to Control Panel – Administrative Tools – Domain Security Policy. The same has to be done on the Domain Controller Security Policy, also found in Administrative Tools.

6. From the MMC interface, select Local Policies and then Audit Policy.

7. Double-click on Audit Object Access and select Success and Failure.

Once that is done, the files you want to audit must be specified. In this case we want to audit: cmd.exe, ftp.exe, net.exe, ping.exe and tftp.exe.

To enable object access auditing to log each time the SYSTEM account and Internet guest account attempt to run cmd.exe:

Figure 8: Security tab

1. Right-click on cmd.exe and select Properties.

2. Next select the Security tab and click on Advanced (see Figure 8).

3. Select the Auditing tab and click on Add.

4. Here you can select which users should get logged when they try to access the Object (cmd.exe). Select the SYSTEM account.

5. To enable full auditing on cmd.exe / SYSTEM account, select all Successful and Failed options.

6. Press OK, select Add and do the same for the IUSR account.

7. This procedure must be followed for ftp.exe, net.exe, ping.exe, and tftp.exe.

Step 2: How LANguard S.E.L.M. detects the attack and notifies admin

LANguard Security Event Log Monitor successfully detects the previously described exploit tools and even upcoming tools which make use of similar methods by checking for object access on the abovementioned files and any other files that you choose to monitor.

LANguard S.E.L.M. distinguishes between the various types of operating systems and takes into consideration the roles they play in a network. It applies different event interpretation methods depending on whether the  events are happening on a workstation or on a server or domain controller.

As web servers are a prime target for hackers, it is recommended to mark these machines as either medium or high security computers. Preferably such machines are to be marked as high security in the Computers to Monitor node in the LANguard S.E.L.M. configuration.

The following procedure enables LANguard S.E.L.M to alert the administrator immediately upon attack:

Figure 9: Security tab, LANguard S.E.L.M configuration console

1. Start up the LANguard S.E.L.M. Configuration.

2. Right-click on Computers to Monitor from the left-hand panel and select New – Single Computer Entry.

3. Type in the name of the computer and press Enter.

4. In the General tab, select Real Time in the Scanning Schedule section.

5. Click on the Security tab, and drag the bar to High Security.

6. Done! Click on OK to apply the changes.

LANguard S.E.L.M. will now start scanning the specified computers for suspicious activity. LANguard S.E.L.M. is shipped with a set of categorization rules that filter out the event records and classify them into one of four categories: low, medium, high or critical importance. This way, you can have an instant overview as to whether any critical activity has taken place on your web-server.

LANguard S.E.L.M. is configured by default to collect all object event records. However, if one of the abovementioned files is accessed by the accounts discussed earlier, then the resulting event is classified as critical and you will immediately be notified by email that someone has accessed the file concerned.

On notification, you will be able to take early action and catch the hacker red-handed -- to prevent any further damage.

The events generated when an attack such as the ones discussed earlier are events numbered 560 and 562.

Event 560: Object Open – Meaning the object (e.g. cmd.exe was run) was accessed.

Event 562: Handle Closed – Meaning that the object is no longer in use (e.g. Cmd.exe was closed).

Step 3: Testing your new IDS

Once you have configured your IIS web server with LANguard S.E.L.M., you will want to test the new security features.

Figure 10: E-mail alert by LANguard S.E.L.M.

You can do this by creating a new ASP script. If you have properly set up your auditing policies and enabled object access on the indicated files, this script will create and trigger an object audit rule. LANguard S.E.L.M will then collect the generated event from the security event log, and – because a matching rule exists – it will send an email alert to the administrator to advise that cmd.exe has been accessed (see Figure 10).

The script below will simply run cmd.exe and make a directory listing of the C:\ in the background. You can place this file on your IIS server and try to access it via the web browser.

<%@ Language=VBScript %>

<%' ----------------------------------------------------------------

'  SELM_test.asp : used to test LANguard S.E.L.M

'  By :  Sandro Gauci <Sandro@gfi.com>

'  Co : GFi

' ----------------------------------------------------------------

Dim oScript

On Error Resume Next

Set oScript = Server.CreateObject("WSCRIPT.SHELL")

Call oScript.Run ("cmd.exe /c dir C:\", 0, True)

%>

<HTML>

<BODY>

You should now get an alert by LANguard S.E.L.M

</BODY>

</HTML>

 This ASP script can be downloaded from: ftp.gfi.com/testselm.zip

General note

Using LANguard S.E.L.M. to detect intrusions is vital, but it is equally important that you install the latest Service Packs issued by Microsoft, as well as keeping up-to-date with the latest patches and security alerts. For more information, please see the Microsoft web site: http://www.microsoft.com/security/

About GFI

GFI (www.gfi.com) is a leading provider of Windows-based messaging, content security and network security software. Key products include the GFI FAXmaker fax connector for Exchange and fax server for networks; GFI MailSecurity email content/exploit checking and anti-virus software; and the GFI LANguard family of network security products. Clients include Microsoft, Telstra, Time Warner Cable, Shell Oil Lubricants, NASA, DHL, Caterpillar, BMW, the US IRS, and the USAF. GFI has six offices in the US, UK, Germany, France, Australia and Malta, and has a worldwide network of distributors. GFI is a Microsoft Gold Certified Partner and has won the Microsoft Fusion 2000 (GEM) Packaged Application Partner of the Year award.

© 2002 GFI Software Ltd. All rights reserved. The information contained in this document represents the current view of GFI on the issues discussed as of the date of publication. Because GFI must respond to changing market conditions, it should not be interpreted to be a commitment on the part of GFI, and GFI cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. GFI MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. FAXmaker, Mail essentials, Mail Security and LANguard and the FAXmaker, Mail essentials, Mail Security and LANguard logos and the GFI logo are either registered trademarks or trademarks of GFI Software Ltd. in the United States and/or other countries. Microsoft, Exchange Server, VS API, Word, and Windows NT/2000/XP are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product or company names mentioned herein may be the trademarks of their respective owners.

back to top