FALL 2013 www.DFInews.com 15
the bogus sign-in page by supplying a bogus username and password.
The network analysis had only begun at this
point; the next step was the use of DNS tools to
track the IP addresses of the bogus sites. 4 Looking
up the host name creditunion.pm168.com.cn
revealed the canonical name of s310.now.net.
cn and an IP address of 188.8.131.52. The IP
address was within range assigned to the Asia-
Pacific Network Information Center (APNIC) and,
in turn, to a smaller block that had been allocated to
the China Network Information Center (CNNIC),
responsible for IP address assignments in China. A
traceroute to this particular address showed a handoff
to China Telecom USA prior to going overseas.
The host name of the server collecting the
username, passwords, and credit card information
was as26489.epolis.ru with an IP address of
184.108.40.206. This address is part of the RIPE
address block; whois information provided contact
information at the rt-comm.ru network and a
Moscow telephone number.
Starting a packet sniffer at the beginning of
this exchange proved to be very useful. Figure
1 shows the TCP packets exchanged when the
authors submitted the bogus information; the
information at the top of the display (in red)
shows the HTTP contents of outbound packets
from the author’s computer and the bottom part of
the display (in blue) shows the response from the
Web server. 3 Note that the block of text starting
with method=GET (a common way of submitting
form information) contains the strings USERID=
has0234%40yahoo.com and PSWD=123456 which
correspond to the username and password, respectively, entered in the form.
The more interesting item of information is that
the host of the login.php file, as shown in the second
line of the packet stream, is as26489.epolis.ru. So,
although the bogus server is housed in the .cn domain, the user information is going to .ru (Russia),
having been referred via the bogus Web site (as
noted in the Referer line).
Case Study #3: Web E-commerce Server
The login attempt will always be successful, of
course, because this site is not authenticating users
but merely collecting usernames and passwords.
Having succeeded at that, the site shows a page
where the users can edit their account information.
In February 2006, the authors were involved in an
investigation of an e-commerce server that had
been hacked. The system administrator re-built the
server using a new hard drive so that we were able
to take a close look at the compromised system.
One of the key points in the exam was found in
the Web server logs. In particular, this HTTP GET
command entry stood out:
The authors supplied additional bogus information on this page, too; note that at this point, all
pretense of carrying an Amazon.com address in the
URL are dropped (Figure 2).
After hitting the
SUBMIT button, the
user is then taken to
the legitimate Amazon.
com Web site. Here,
of course, the author
is greeted by name, a
result of the Amazon
cookies on the author’s
computer. Any doubts
as to the legitimacy of
the previous few pages
is all but erased by the
appearance of a familiar
page which greets one by
192.0.2.36 - - [10/Jan/2006:15:08:38
-0500] “GET /shoppingcart/includes/
HTTP/1.1” 200 2423 “-” “-”
The version of the e-commerce
shopping cart software employed by
this particular business at the time had
a vulnerability whereby a nefarious
user could force the server to execute
a command. In this case, the “%xx”
entries represented the hexadecimal
representation of ASCII characters and
“translate” to the following command:
d=echo _START_;id;echo; echo_