|
|
What Is a Remote Attack?
A remote attack is any attack that is initiated
against a machine that the attacker does not currently have control over; that
is, it is an attack against any machine other than the attacker's own (whether
that machine is on the attacker's subnet or 10,000 miles away). The best way to
define a remote machine is this:
A remote machine is any machine--other than the one
you are now on--that can be reached through some protocol over the Internet or
any other network or medium.
The first steps, oddly enough, do not involve
much contact with the target. (That is, they won't if the cracker is smart.) The
cracker's first problem (after identifying the type of network, the target
machines, and so on) is to determine with whom he is dealing. Much of this
information can be acquired without disturbing the target. (We will assume for
now that the target does not run a firewall. Most networks do not. Not yet,
anyway.) Some of this information is gathered through the following techniques:
Ø
Running a
host query. Here, the cracker gathers as much information as is currently held
on the target in domain servers. Such a query may produce volumes of information
or may reveal very little. Much depends on the size and the construct of the
network.
Ø
For
example, under optimal circumstances of examining a large and well-established
target, this will map out the machines and IPs within the domain in a very
comprehensive fashion. The names of these machines may give the cracker a clue
as to what names are being used in NIS (if applicable). Equally, the target may
turn out to be a small outfit, with only two machines; in that case, the
information will naturally be sparse. It will identify the name server and the
IPs of the two boxes (little more than one could get from a WHOIS query). One
interesting note is that the type of operating system can often be discerned
from such a query.
Ø
A WHOIS
query. This will identify the technical contacts. Such information may seem
innocuous. It isn't. The technical contact is generally the person at least
partially responsible for the day-to-day administration of the target. That
person's e-mail address will have some value. (Also, between this and the host
query, you can determine whether the target is a real box, a leaf node, a
virtual domain hosted by another service, and so on.)
Ø
Running
some Usenet and Web searches. There are a number of searches the cracker might
want to conduct before actually coming into contact with the target. One is to
run the technical contact's name through a search engine (using a forced,
case-sensitive, this-string-only conditional search). The cracker is looking to
see if the administrators and technical contacts sport much traffic in Usenet.
Similarly, this address (or addresses) should be run through searchable archives
of all applicable security mailing lists.
Collecting information about the system
administrator is paramount. A system administrator is usually responsible for
maintaining the security of a site. There are instances where the system
administrator may run into problems, and many of them cannot resist the urge to
post to Usenet or mailing lists for answers to those problems. By taking the
time to run the administrator's address (and any variation of it, as I will
explain in the next section), you may be able to gain greater insight into his
network, his security, and his personality. Administrators who make such posts
typically specify their architecture, a bit about their network topology, and
their stated problem.
Even evidence of a match for that address (or
lack thereof) can be enlightening. For example, if a system administrator is in
a security mailing list or forum each day, disputing or discussing various
security techniques and problems with fellow administrators, this is evidence of
knowledge. In other words, this type of person knows security well and is
therefore likely well prepared for an attack. Analyzing such a person's posts
closely will tell you a bit about his stance on security and how he implements
it. Conversely, if the majority of his questions are rudimentary (and he often
has a difficult time grasping one or more security concepts), it might be
evidence of inexperience.
From a completely different angle, if his
address does not appear at all on such lists or in such forums, there are only a
few possibilities why. One is that he is lurking through such groups. The other
is that he is so bad-ass that he has no need to discuss security at all.
(Basically, if he is on such lists at all, he DOES receive advisories, and that
is, of course, a bad sign for the cracker, no matter what way you look at it.
The cracker has to rely in large part on the administrator's lack of knowledge.
Most semi-secure platforms can be relatively secure even with a minimal effort
by a well-trained system administrator.)
In short, these searches make a quick (and
painless) attempt to cull some important information about the folks at the
other end of the wire.
You will note that I referred to "any
variation" of a system administrator's address. Variations in this context
mean any possible alternate addresses. There are two kinds of alternate
addresses. The first kind is the individual's personal address. That is, many
system administrators may also have addresses at or on networks other than their
own. (Some administrators are actually foolish enough to include these addresses
in the fields provided for address on an InterNIC record.) So, while they may
not use their work address to discuss (or learn about) security, it is quite
possible that they may be using their home address.
The Operating System
You may have to go through various methods
(including but not limited to those described in the preceding section) to
identify the operating system and version being used on the target network. In
earlier years, one could be pretty certain that the majority of machines on a
target network ran similar software on similar hardware. Today, it is another
ball game entirely. Today, networks may harbor dozens of different machines with
disparate operating systems and architecture. One would think that for the
cracker, this would be a hostile and difficult-to-manage environment. Not so.
The more diverse your network nodes are (in
terms of operating system and architecture), the more likely it is that a
security hole exists. There are reasons for this, and while I do not intend to
explain them thoroughly, I will relate at least this: Each operating system has
its own set of bugs. Some of these bugs are known, and some may be discovered
over time. In a relatively large network, where there may be many different
types of machines and software, you have a better chance of finding a hole. The
system administrator is, at day's end, only a human being. He cannot be
constantly reviewing security advisories for each platform in turn. There is a
strong chance that his security knowledge of this or that system is weak.
In any event, once having identified the various operating systems and architectures available at the target, the next step is study. A checklist should be made that lists each operating system and machine type. This checklist will assist you tremendously as you go to the next step, which is to identify all known holes on that platform and understand each one.
So it is necessary to know
Ø
Who the
administrator is
Ø
The
machines on the network, and perhaps their functions and domain servers
Ø
Their
operating systems
Ø
Their
probable holes
Ø
Any
discussion by the administrator about the topology, management, policies,
construction, or administration of the network
Remote attacks are becoming increasingly
common. As discussed in several earlier chapters, the ability to run a scan has
become more within the grasp of the average user. Similarly, the proliferation
of searchable vulnerability indexes have greatly enhanced one's ability to
identify possible security issues.
Some individuals suggest that the free sharing
of such information is itself contributing to the poor state of security on the
Internet. That is incorrect. Rather, system administrators must make use of such
publicly available information. They should, technically, perform the procedures
described here on their own networks. It is not so much a matter of cost as it
is time.
One interesting phenomenon is the increase in
tools to attack Windows NT boxes. Not just scanning tools, either, but sniffers,
password grabbers, and password crackers. In reference to remote attack tools,
though, the best tool available for NT is SAFEsuite by Internet Security Systems
(ISS). It contains a wide variety of tools, although the majority were designed
for internal security analysis.
For example, consider the Intranet Scanner,
which assesses the internal security of a network tied to a Microsoft Windows NT
server. Note here that I write only that the network is tied to the NT server.
This does not mean that all machines on the network must run NT in order for the
Intranet Scanner to work. Rather, it is designed to assess a network that
contains nodes of disparate architecture and operating systems. So, you could
have boxes running Windows , UNIX, or potentially other operating systems
running TCP/IP.
a well-orchestrated and formidable remote
attack is not the work of some half-brained
cracker. It is the work of someone with a deep understanding of the
system--someone who is cool, collected, and quite well educated in TCP/IP.
(Although that education may not have come in a formal fashion.) For this
reason, it is a shame that crackers usually come to such a terrible end. One
wonders why these talented folks turn to the dark side.