An attack is any unauthorized action undertaken with the intent of hindering, damaging, incapacitating, or breaching the security of your server. Such an attack might range from a denial of service to complete compromise and destruction of your server. The level of attack that is successful against your network depends on the security you employ
Developing & attack strategy
The days of roaming around the Internet, cracking this and that server are basically over. Years ago, compromising the security of a system was viewed as a minor transgression as long as no damage was done. Today, the situation is different. Today, the value of data is becoming an increasingly talked-about issue. Therefore, the modern cracker would be wise not to crack without a reason. Similarly, he would be wise to set forth cracking a server only with a particular plan.
The only instance in which this does not apply is where the cracker is either located in a foreign state that has no specific law against computer intrusion (Berferd again) or one that provides no extradition procedure for that particular offense (for example, the NASA case involving a student in Argentina). All other crackers would be wise to tread very cautiously.
Your attack strategy may depend on what you want to accomplish. We will assume, however, that the task at hand is basically nothing more than compromise of system security. If this is your plan, you need to lay out how the attack will be accomplished. The longer the scan takes (and the more machines that are included within it), the more likely it is that it will be immediately discovered. Also, the more scan data that you have to sift through; the longer it will take to implement an attack based upon that data. The time that elapses between the scan and the actual attack, as I’ve mentioned, should be short.
Some things are therefore obvious (or should be). If you determine from all of your data collection that certain portions of the network are segmented by routers, switches, bridges, or other devices, you should probably exclude those from your scan. After all, compromising those systems will likely produce little benefit. Suppose you gained root on one such box in a segment. How far do you think you could get? Do you think that you could easily cross a bridge, router, or switch? Probably not. Therefore, sniffing will only render relevant information about the other machines in the segment, and spoofing will likewise work (reliably) only against those machines within the segment. Because what you are looking for is root on the main box (or at least, within the largest network segment available), it is unlikely that a scan on smaller, more secure segments would prove to be of great benefit.
Types of attacks
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.
STEPS FOR REMOTE ATTACKS
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 whole 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.
A spoofing attack involves nothing more than forging one’s source address. It is the act of using one machine to impersonate another. To understand how this occurs, you must know a bit about authentication.
Every user has encountered some form of authentication. This encounter most often occurs while connecting to a network. That network could be located in the user’s home, his office, or, as in this case, the Internet. The better portions of authentication routines known to the average user occur at the application level. That is, these methods of authentication are entirely visible to the user. The typical example is when a user is confronted with a password prompt on FTP or Telnet. The user enters a username and a password; these are authenticated, and the user gains access to the resource.
On the Internet, application-level authentication routines are the minority. Each second, authentication routines that are totally invisible to the user occur. The difference between these routines and application-level authentication routines is fundamental. In application-level authentication, a machine challenges the user; a machine requests that the user identify him. In contrast, non-application-level authentication routines occur between machines. One machine demands some form of identification from another. Until this identification is produced and validated, no transactions occur between the machines engaged in the challenge-response dialog.
Such machine-to-machine dialogs always occur automatically (that is, they occur without human intervention). In the IP spoofing attack, the cracker attempts to capitalize on the automated nature of the dialog between machines. Thus, the IP spoofing attack is an extraordinary method of gaining access because in it, the cracker never uses a username or password.
Who Can Be Spoofed?
The IP spoofing attack is unique in that it can only be implemented against a certain class of machines running true TCP/IP. True TCP/IP is any fully fledged implementation of TCP/IP, or one that–in its out-of-the-box state–encompasses all available ports and services within the TCP/IP suite. By this, I am referring almost exclusively to those machines running certain versions of UNIX (only a handful is easily spoofed). PC machines running DOS, Windows, or Windows 95 are not included in this group. Neither is Macintoshes running MacOS. (It is theoretically possible that Macs running A/UX and PCs running Linux could be vulnerable, given the right circumstances.)
I cannot guarantee that other configurations or services will not later be proven vulnerable to IP spoofing, but for the moment the list of vulnerable services is short indeed:
Any configuration using Sun RPC calls
Any network service that utilizes IP address authentication
The X Window System from MIT
The R services
How Spoofing Attacks Work?
Spoofing attacks differ from random scanning and other techniques used to ascertain holes in the system. Spoofing attacks occur only after a particular machine has been identified as vulnerable. By the time the cracker is ready to conduct a spoofing attack, he or she knows the target network is vulnerable and which machine is to be attacked.
Hardware address spoofing is, to a certain extent, also dependent upon the card. Cards that do not allow for software-driven settings of the hardware address are generally useless in this regard. You might be able to report an address, but in most instances, the technique does not actually work. Older cards support software-driven alteration of the address, usually with a jumper setting. (This is done by shorting out the jumper pins on the card.) A good example is the old Western Digital Ethernet card. Newer cards are more likely to automatically allow software-driven changes, whereas IRQ settings may still be a jumper issue. It is likely, however, that in the near future, Ethernet cards may not have jumpers at all due to the fact that plug-and-play technology has emerged.
This type of spoofing works because each machine on a given network segment trusts its pals on that same segment. Barring the installation of a hub that hardwire-routes packets to each machine, at least a few trust relationships between machines will exist within a segment. Most commonly, those machines know each other because their addresses are listed within some database on each machine. In IP-based networks, this is done using the IP address–I hope–or with the hostname. (Using hostnames is a potential security problem in itself. Whenever possible, hard numeric addresses should be used.)
Machines within a network segment that are aware of the addresses of their pals are referred to as machines that trust each other. When such a trust relationship exists, these machines may remotely execute commands for each other with no more authentication than is required to identify the source address.
Crackers can determine trust relationships between machines using a wide range of commands or, more commonly, using scanners. One can, for example, scan a host and easily determine whether the R services are running. Whatever method is used, the cracker will attempt to map the trust relationships within the target network.
What Can Be Done to Prevent IP Spoofing Attacks?
IP spoofing attacks can be thwarted by configuring your network to reject packets from the Net that claim to originate from a local address (that is, reject packets that purport to have an address of a workstation on your internal network). This is most commonly done with a router.
Routers work by applying filters on incoming packets; for example, they can block particular types of packets from reaching your network.
Tel-net based attacks
The purpose of the Telnet protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication (“linking”) and process-process communication (distributed computation).
Telnet is unique in its design with the notable exception of rlogin. Telnet is designed to allow a user to log in to a foreign machine and execute commands there. Telnet (like rlogin) works as though you are at the console of the remote machine, as if you physically approached the remote machine, turned it on, and began working.
Telnet can also be used in a variety of ways to attack or otherwise cull information from a remote host. By the time this book is released, many more Telnet attack techniques will have surfaced. If you run a network and intend to supply your users with Telnet access, beware. This is especially so on new Telnet servers. These new servers may have bugs that have not yet been revealed. And, because Telnet is so interactive and offers the user so much power to execute commands on remote machines, any hole in a Telnet distribution is a critical one. It stands in the same category as FTP or HTTP in this respect (or is perhaps even worse).
Telnet is an interesting protocol. As explained earlier, one can learn many things using Telnet. For example, you can cull what version of the operating system is being run. Most distributions of UNIX will report this information on connection. It is reported by at least one authoritative source that various scanners use the issue information at connect to identify the type of system (SATAN being one such scanner). The operating system can generally be determined by attacking any of these ports:
Port 21: FTP
Port 23: Telnet (Default)
Port 25: Mail
Port 70: Gopher
Port 80: HTTP
In their now-famous paper, “Improving the Security of Your Site by Breaking into It,” Dan Farmer and Wietse Venema point out ports that can be attacked. Specifically, they address the issue of port 6000:
X windows is usually on port 6000…If not protected properly (via the magic cookie or xhost mechanisms), window displays can be captured or watched, user keystrokes may be stolen, programs executed remotely, etc. Also, if the target is running X and accepts a Telnet to port 6000 that can be used for a denial of service attack, as the target’s windowing system will often “freeze up” for a short period of time.
X Terminals are generally diskless clients. These are machines that have the bare minimum of hardware and software to connect to an X server. These are most commonly used in universities and consist of a 17″ or 19″ screen, a base, a keyboard and a mouse. The terminal usually supports a minimum of 4 megabyte of RAM but some will hold as much as 128 megabytes. X terminals also have client software that allows them to connect to the server. Typically, the connection is via fast Ethernet, hardwired to the back of the terminal. X Terminals provide high-speed connectivity to X servers, coupled with high-powered graphics. These machines are sold on the Internet and make great “additional” terminals for use at home. (They are especially good for training.)
Another interesting thing that Telnet can be used for is to instantly determine whether the target is a real or virtual domain (this can be done through other methods, but none perform this function quite as quickly). This can assist a cracker in determining exactly which machine he or she must crack to reach your resources or, more precisely, exactly which machine he or she is engaged in cracking.
Under normal circumstances, a real domain is a domain that has been registered with InterNIC and also has its own dedicated server. Somewhere in the void is a box with a permanent IP address, and that box is attached permanently to the Internet via 28.8Kbps modem, ISDN, 56Kbps modem, frame relay, T1, T3, ATM, or perhaps, if the owner spares no expense, SONET. As such, when you Telnet to such a real site, you are reaching that machine and no other.
Virtual domains, however, are simply directories on a real server, aliased to a particular domain name. That is, you pay some ISP to register your domain name and create a directory on its disk where your virtual domain exists. This technique allows your_company.com to masquerade as a real server. Thus, when users point their browsers to www.your_company.com, they are reaching the ISP’s server. The ISP’s server redirects the connection request to your directory on the server. This virtual domain scheme is popular for several reasons, including cost. It saves your company the trouble of establishing a real server and therefore eliminates some of these expenses:
Basically, you pay a one-time fee (and monthly fees thereafter) and the ISP handles everything. To crackers, this might be important. For example, if crackers are about to crack your domain–without determining whether your machine is truly a server–they may get into trouble. They think they are cracking some little machine within your internal offices when in fact, they are about to attack a large, well-known network provider.
Telnet instantly reveals the state of your server. When a cracker initiates a Telnet connection to your_company.com (and on connect, sees the name of the machine as a node on some other, large network), he or she immediately knows that your address is a virtual domain.
Moreover, Telnet can be used for other nefarious purposes. One is the ever-popular brute-force attack. I am not sure why brute-force attacks are so popular among young crackers; almost all servers do some form of logging these days. Nevertheless, the technique has survived into the 1990s. These attacks are most commonly initiated using Telnet clients that have their own scripting language built in. Tera Term is one such application.
Tera Term sports a language that allows you to automate Telnet sessions. This language can be used to construct scripts that can determine valid usernames on a system that refuses to cough up information on finger or sendmail-expn queries. Versions of Telnet reveal this information in a variety of ways. For example, if a bogus username is given, the connection will be cut. However, if a valid username is given, a new login: prompt is reissued.
Moreover, Telnet is a great tool for quickly determining whether a particular port is open or whether a server is running a particular service. Telnet can also be used as a weapon in denial-of-service attacks. For example, sending garbage to certain ports on an NT Web server under IIS can cause the targeted processor to jump to 100 percent utilization. Initiating a Telnet session to other ports on an NT Web server can cause the machine to hang or crash. This is particularly so when issuing a Telnet connection request to port 135.
One can also crash Microsoft’s Internet Information Server by Telnetting to port 80 and issuing a GET…/… request. Reportedly, however, that problem was remedied with the Microsoft Windows NT Service Pack 2 for Windows NT 4.0. If you do not have that patch/service pack, get it. A good treatment of this and other problems can be found in the Denial of Service Info post, posted by Chris Klaus of Internet Security Systems.
Finally, Telnet is often used to generate fake mail and fake news. Spammers often use this option instead of using regular means of posting Usenet messages. There are certain options that can be set this way that permit spammers to avoid at least some of the screens created by spam-killing robots on the Usenet network.