Teaching tip: Utilizing simple hacking techniques to teach system security and hacker identification

Journal of Information Systems Education, 2003 by Sanders, Aaron D

ABSTRACT

This first half of this paper details the tools and methodologies employed to determine the identity and physical location of a hacker who infiltrated a server and altered a Web page. The second half of this paper recreates the scenario in a laboratory environment, in order to instruct students on system administration, server security, network management, and basic data communications.

Keywords: Hands-on exercises, system administration, IIS security, server configuration

1. INTRODUCTION

As an undergraduate student working on my Bachelor of Science degree in Information Systems, I had the opportunity to work as a part-time Network Administrator. My duties included performing administrative and troubleshooting tasks on the servers, workstations, and network. The domain consisted of five servers, all running Windows 2000 Server and Internet Information Services (IIS) 5.0.

One morning I received an email message informing me that one of the servers had been compromised, and one of the Web pages altered. The actual damage was minor: The page had been changed from its original state to a black background with a large yellow smiley face, and the message "You've been HaCkEd. Have a nice day!" Although no malignant damage had occurred, I realized that this provided a unique opportunity for me to attempt to determine the identity of the hacker (I choose to use the more popular although incorrect term "hacker", because it causes less confusion than "cracker", which is the correct term in this situation). Not only could I examine the tools and methodologies employed in similar s cenarios, but this situation would also provide valuable knowledge in server security and system administration.

2. PROCEDURE

The first step in attempting to determine the identity of the hacker was to search for clues in the directory containing the altered page. Interestingly enough, the process methodology mirrored standard troubleshooting procedures, or a police officer attempting to solve a crime. One must start at the scene of the crime and gather as many direct clues as possible, then work their way outward, examining the larger picture. Since the directory contained published Web pages, it existed as a subdirectory to the wwwroot directory (\inetpub\wwwroot). The first piece of useful information that appeared was the created and modified dates for the altered Hypertext Markup Language (HTML) file. Although these dates were not an absolute fingerprint, they provided a frame of reference to use in searching for other clues.

The next step was the examination of the _vti_cnf subdirectory, which on servers with FrontPage Extensions enabled, is used by FrontPage to store configuration information for files in the parent directory. Every directory available via the Web will have a _vti_cnf subdirectory, which contains configuration files for each HTML file in the parent directory. These configuration files will have the same filename and extension as their HTML counterparts, with the only difference being that when you view the configuration files in a browser, configuration information will be displayed, rather than the actual page they mirror. The configuration files residing in the _vti_cnf subdirectory contain some important information, including the file's author, last time modified, next to last time modified, and time created. (On a configuration note, it is highly recommended that the computer under examination be configured to view hidden files, as some of the files in the _vti_cnf directory may be hidden files). As they logically should, the dates and times listed in the configuration file for the altered page matched the dates and times discovered by viewing the properties on the altered page. The author's name was the most important piece of information gained from the configuration file, and a crucial piece of the puzzle. The name was a valid account in the Active Directory for the server, and someone who would not be hacking servers and altering other people's Web pages. At this point, the evidence seemed to suggest that someone had correctly guessed the password of a user that had access to the server and directory, connected to the directory, and altered the Web page.

The next step was to examine the various log files created by US and other connectivity programs. The first log files requiring examination are the Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP) logs that US automatically creates. The default storage location for the HTTP log files is the \%windir%\System32\LogFiles\W3SVC1 (%windir% being the directory that Windows 2000 is installed in, normally \WINNT) directory, their default filename is exLOGDATE.log, and there is one file for each day that US had HTTP activity. Although the filenames and location can vary depending on options chosen during US configuration, it is rare for the defaults to be changed. If finding their location is problematic, the Start Menu's Find option can be used to search for files named "*.log" on all drives. This will reveal their location and naming convention. The HTTP logs contain GET (when someone requests a file from the server via the Web) requests and POST (when someone places a file on the server via the Web) requests, although the HTTP logs record POST requests only when files are placed on the server using Microsoft FrontPage or similar methods. The log files contain the date of request and files requested, along with the Internet Protocol (IP) address that made the request.