The French Connection

// Challenge 1 //
Michael

1. The Scenario
The challenge is based around the defacement of a web site belonging to a medium-sized public company. It was hosted on the company's own server and maintained by its IT department. A help desk employee was notified of the defacement on a Friday evening, and after confirming the incident, attempted to contact a list of IT department members, eventually getting hold of a junior technician. The technician in turn contacted his supervisor, who advised him to move the web server from the internal network to the DMZ and restore the site. The technician did this, using what appeared to be backup files left on the server by the person who defaced the site. The company's stock fell after the hack was discussed on a public message board.

2. Analysing the Company Background

Before discussing the technical aspects of the incident, it's important to look at the background and the circumstances surrounding it, as these are vulnerabilities in themselves. There was the absence of an incident response procedure, which could have helped quickly resolve the issue and limit the damage. The incident here was a fairly common one, and could easily have been anticipated and prepared for. The next step should have been to ascertain whether the site was indeed compromised, or whether the name server was modified to redirect the site's URL. Because of the potential damage to the company's reputation, the preferable option would have been to immediately take the site offline. 2.1 The Employees Although the junior IT person couldn't resolve the issue without guidance, he still had administratorlevel access to the server and the firewall without the proper training. Given this particular employee was the first available at the time, it's likely most the IT department also had administrator-level access. This vastly increases the probability of an insider threat or a compromise through social engineering. There was a possibility the defacement itself was an attempt to socially engineer the IT department into installing what they thought were backup files left on the server, but which could have been executables/scripts. This wasn't considered.

We should also look at why the senior IT person wasn't motivated to deal with a serious incident in person, and why basic security wasn't implemented. Was he underpaid, under-trained or de-skilled? Or is the recruiting process flawed? 2.2 The DMZ Another factor identified is the web server wasn't already in the DMZ, where publicly-available resources should have been, but was on the company's internal network prior to the incident.

3. Analysing the Server Logs

When examining the server logs, the system administrators couldn't find any entries for the times immediately prior to, or during the incident, so the attacker had covered his/her tracks by removing them. However, there were a number of entries covering a ten minute period some time after the site was restored.

Although the events are listed as taking place sometime after the site was restored, they match the incident outlined in the scenario, so it's certain the attacker had also modified the times on the server logs, or possibly altered the system time. The log also shows the domain name of the attacker (chewie.hacker.fr) and the target (www.victim.com), the attacker's use of a Mozilla browser running on a Microsoft Windows 98 OS, and the operations performed. The first four entries show a request for cmd.exe residing in /scripts/../winnt/system32/, which allows the attacker to use a command shell to move between directories, list their contents and perform file operations. As the logs show, the attacker was using c+dir to probe volumes C:, D: and E:, and had settled on volume C:. Most the requests returned status code 200, indicated they were

successful, apart from the attempt to access volume E:, which could be unreachable over the Internet.

Having determined the contents of each volume, c+dir was used to search the /asfroot and /inetpub directories, where publicly-available web content would normally be placed. Another two entries (not shown here) reveal there was an attempt to download a file called mmc.gif. Both requests were rejected by the server.

After returning to volume D: and viewing a list of files available in the \wwwroot\ directory, the attacker visited the web pages buzzxyz.html, xyzBuzz3.swf and index.html.

The cmd.exe file also allowed a number of file operations. Here, detour.html was renamed detour.html.old, so it would be hidden from web browsers. Next, a directory called c:\ArA\ was created in volume C:, and the cmd.exe file was copied from /winnt/system32/ to that location and renamed cmd1.exe. This would allow the attacker to execute commands in future if access to the usual executable was revoked.

Using cmd.exe and the echo command, the attacker entered some HTML code and directed the output to a file called default.html in the recently created \ArA\ directory. This file would be rendered in a web browser as:

**** SCRIPT KIDZ, INC ****

You, my friendz, are completely owned. I'm here, you're security is nowhere. Someone should check your system security coz you sure aren't. Moving back to \wwwroot\ in volume D:, the file index.html was renamed to index.html.old, and replaced with the recently created HTML file, which is now the default home page.