| The Problem | Imagine that one day you go to your favorite website and the site
appears to be defaced. List what you would do to find out what
happened to the site and where the break-in was.
|
| Where do you start?
| The first place to look for clues about what happened are on the
defaced page itself. In order to do this effectively, it would
probably be best to save a backup copy of the site because the
administrators (or even potentially the attackers) may take the
site down at anytime. wget is a helpful tool for this.
|
| What should you be looking for in the page?
|
Many attackers leave their name or callsign on the page itself.
Look for this and try a Google search for this name on both the
web and newsgroups. If you find any information about them, you
may be able to reconstruct a pattern of attacks from their history.
Do they tend to attack certain versions of webservers or a particular
CGI? Does this website fit that pattern?
If you cannot find any information on this particular attacker,
he or she may be part of a team. You can also check on the team.
|
| So if you find the attacker and everything fits the pattern,
are you done?
| In many cases, if you find information on the attacker and they
have a pattern which matches the current situation, you are probably
done. However, there are times where this may not be the case. The
attacker may have decided to try a new technique this time. Another
possibility is that the name listed on the page was forged; an
attacker may have placed another well-known attacker's name on the
page for any number of reasons. In either case, you don't have a
definitive answer at this point.
|
| Stop and consider ->
| What motives might an attacker have for putting another attacker's
name on the defaced site? What effect might this have on your
investigation?
|
| What do you do if you can't find any information on the
attacker?
| It may be the case that the attacker left no uniquely identifying
information on the defaced site or that they have no recorded history
of attack (at least under the name given on the page). So at this
point, you have no past history to draw on.
|
| How would an expert proceed next?
| If there is no history to support an investigation, an expert will
usually consider how the defacement could have happened and then
look at these options. In particular, an expert will consider the
whole situation at hand: we have a client/server architecture in
which the client expected one thing but got something different.
|
| Where could problems arise?
| In client/server architectures, there are three main components,
the client, the server, and the connection between them. There
could be problems with any of these. In general, an expert will
rule out problems with the client unless it is showing other
symptoms of being attacked. For this question, assume that the
client is operating correctly.
|
| Stop and consider ->
| What problems could possibly happen on the client to cause
this error? Is an attack on the client likely?
|
| How do you investigate problems in the network?
| The first step in investigating problems in the network is
identifying potential problems. We know that the client is
operating correctly and is following proper procedures to
connect to the server. If we assume that the problem is in
the network, that means that somehow the network is delivering
the wrong information to the client. We may assume that the
network protocols are operating according to specifications,
so this isn't simply an incredibly lucky bug. Somehow, the
network is not getting data from the server to the client, yet
the client is receiving data from somewhere. Thus, there must
be another server which is distributing incorrect data.
|
| How do you find a rogue server?
|
The first thing to consider is how this server could convince
the network to deliver data to the client and claim it came
from the true server.
It may be the case that an attacker has
merely misdirected the client by attacking not the main webserver,
but rather a DNS server. Check the whois database for information
on the official nameserver for this website. Run nslookup on
the webserver using your usual DNS server and on the one in whois.
If the results differ, the attacker may have simply compromised
your local nameserver.
Another possibility is a "man-in-the-middle" attack. This is
possible by exploiting poor TCP/IP implementations in either the
client or the server. Investigating this is beyond the scope of
this case study.
|
| Stop and consider ->
| Can you trust whois?
|
| What if there isn't a problem in the network?
|
If you've managed to rule out the possibility of the problem in
the network, it's quite probable that the attacker has managed
to compromise the server.
|
| How can you investigate the server?
| Investigating the server can be tricky. As the user of the client,
you probably do not own the server nor are you authorized to use it in
any way other than requesting web pages. So you request a web page,
but one that does not exist. You can do this by telneting to port
80 on the webserver and asking for a page that you know can't
exist (e.g. http://www.hacked.site/awlunteoawio1im2124). The
webserver should then report an error and in that error, tell you
which webserver it is, which version it is, and usually what add-on
modules are running on the server. By researching these particular
pieces of software, you may be able to find a bug that is being
exploited.
|
| It doesn't appear that the website has any server holes.
What now?
| Even if a webserver doesn't have any holes that are well-publicized,
it may be the case that an attacker has found a new or obscure hole
and is using it. Supposing that a webserver was not attacked by
hitting the server itself, it may also be the case that a CGI program
that was running was buggy or incorrectly configured. You may have
to investigate this based on past knowlegde of what software was
running on the site (as it is not available now!).
|
| The webserver had no security holes and wasn't running any
insecure CGIs. Where do we look next?
|
The webserver may not have been compromised, but another server
might have. If the web site is small, the same machine that runs
the webserver may also be running a buggy FTP server. It is
difficult to detect this without port scanning, which could get
you into a lot of trouble.
Another possibility is that another machine on the same subnet
as the webserver was compromised and it had special priviledges
to access the webserver. This can be very difficult for
an outsider to determine.
|
| Stop and consider ->
| If the server side is so difficult to diagnose, why should we
care? Why are we investigating anyhow?
|
| Conclusion
| Hopefully, this exercise has shown you that it is very difficult
to find the root of the problem when a webserver is defaced. The
problem could lie in many places, including some not mentioned here.
|
| Exercises
|
- List some places where a problem could exist that we did not
mention.
- Suppose you were the administrator of this website. What
would you do differently? How could organizational politics
affect your solving the problem?
|