|
|
An internal breach can be defined as any breach of security on a network to which the hacker or cracker has some access, on which he is a user with a valid account, or where he is a member of a company that maintains such a network.
Whether you are a victim or a perpetrator of an internal breach, know this: Authorized users have access to an enormous amount of information that remote (and unauthorized) users and crackers work hard to acquire. For example, building a list of users on a UNIX system is only a few keystrokes away for the authorized user. It can be done as simply as this:
ypcat passwd || cat /etc/passwd) | sed -e `s/:.*//'
Compare this with building a reliable username list from the outside. This might entail writing a script that routinely issues finger and ruser requests, checks the data against an outfile, and discards dupes. Even if the network you are targeting is small, you could spend a lot of time trying to obtain a decent list. In contrast, larger networks such as ISPs might render hundreds of names at a time. It depends on how lazy the system administrator is at that location. As I discuss in Chapter 13, "Techniques to Hide One's Identity," if the system administrator has failed to install a hacked finger daemon or failed to restrict finger access either marginally or completely, a huge user list can be obtained with a single command line. So my first point is this: Local users who have even limited but authorized access can obtain quite a bit of information about users.
Additionally, they have access to tools that are unavailable to remote, unauthorized users. Exactly what those tools are depends on the system; but in most UNIX-based environments, this includes at least shell language access and probably Perl access. If the network in question is an ISP, it probably also includes access to a C compiler. If that ISP is running Linux, there is a strong chance that a laundry list of compilers is available. Most system administrators who use Linux install the majority of, if not all, development packages. Certainly, TCL will be available. This will probably be accompanied by gcc and g++, a BASIC development package, and perhaps Pascal, Python, FORTRAN, and others. Aren't Linux and GNU wonderful?
Nevertheless, the shell languages alone are enough. These, coupled with awk and sed, formulate a formidable programming environment. And this doesn't apply exclusively to UNIX, either. Here are some power-packed development tools that could empower a user on other networks or platforms:
Ø C and C++
Ø VB
Ø Java
Ø Assembly
Ø Perl
In fact, user access to programming tools is an even more critical issue in the Windows 95 environment. NT, providing it is installed correctly, boasts strong access control. This control is at least as strong as in most implementations of non-trusted UNIX. In contrast, Windows 95 has no access control.
Because of this, a local user can install such development packages on his workstation at any time. Most of these tools now exist in free form, either from GNU or some other organization or vendor. There are even TCL interpreters for Windows 95, so the user need not spend $400 for a development package. Contrast this with the UNIX and NT environments. A local user installing such packages on a local workstation has serious problems. For example, access control policies can prevent users from executing programs in certain directories. Also, disk quotas are often instituted on such networks. Thus, a user only gets (for example) 8MB of space for himself. This precludes all but the smallest compilers, and even then, installation is tricky.
Conversely, a user can install anything he likes on a Windows 95 network; however, he probably doesn't even have to. If a full distribution of Office is available and no third-party access-control product has been installed, the local user will at least have access to WordBasic or other tools that, while not generally characterized as full-fledged development tools, can offer increased levels of access and control. Let's not even consider the possibilities if Java is available.
Moreover, local users have an immediate avenue to the network. They are therefore prime candidates to place a sniffer on the drive or drives. As discussed in earlier chapters, this allows them to obtain (at the very least) the usernames and passwords of those located on the same network segment.
There are other advantages of being a local user. One is simply that you are authorized to be there. Think of this not in terms of computers but in terms of real life. An individual who is about to commit a burglary late at night is already in a compromised position. If he is found loitering about the grounds of a local resident's home, he already appears suspicious. However, if he lives inside the house as a guest, he has every right to be lurking about at 3:00 a.m.
Similarly, a local user with authorized access (who intends to exceed that access) is supposed to be there. Although it might seem odd for someone to be logged on in the middle of the night, normal user activity during the day is perfectly acceptable.
With this right comes certain amenities. One is that the user's presence on the system need not be hurried. In contrast, a cracker who tries to leverage the simple access he has gained may be forced to spend only short periods on the network. Until he gains root (or a reasonably facsimile thereof), he is constantly under pressure and the threat of being discovered. In contrast, a local, authorized user can crack at his leisure. He need not hurry at all. In fact, he could spread his activity over a period of months.
Furthermore, local users have the ability to use perfectly innocuous techniques (that in themselves cannot be deemed unauthorized) to derive information about the system. A user can quietly run netstat, arp, ifconfig, and other queries without anyone thinking twice. Therefore, he has the luxury of building an enormous knowledge base about the system using techniques that will likely never be logged. The system administrator who ends up investigating a breach that started this way can only hope that some of these queries were redirected to outfiles or hope for other tangible evidence.
That said, being a local user does have its disadvantages. For instance, cracking under an authorized account places the user in a compromised position if trouble does eventually surface; the system administrator can easily determine who has been doing the cracking. If the cracker is unaware that his activity has been detected (and the system administrator has been logging that activity), he is basically up the creek without a paddle. Subsequent testimony of co- workers can at least establish that this user was sitting at that desk all day long.
Moreover, the local user is under a lot of pressure to avoid leaving materials or evidence behind. The remote user needn't worry about this. For example, a remote user can issue a finger query from his local prompt and redirect the information to a file. No one will be scanning the remote user's directories for such files. In contrast, the local user cannot safely leave that information on the drive. In fact, if the situation is sufficiently serious, the local user shouldn't place the information on the drive at all, even if he intends to delete it later. Data recovery techniques are now sufficiently advanced that if the local user discards or otherwise deletes the information, it can probably be recovered. In such an instance, the smart local cracker will at least encrypt the data before discarding it. However, this may even be a wasted effort, depending on the operating system, the version, the type of file, and so forth.
Anatomy of a Local Crack
Remote holes are matters of extreme concern. In fact, when a remote hole surfaces, crackers have to work to capitalize on that hole within the first few days of its reporting. If they fail to do so, the hole will be swiftly closed, precluding further exploitation. Moreover, programmers are extremely careful when coding remote applications, be they client or server. Big vendors are likewise careful because applications that offer remote access form the very binding thread of the Internet. If these applications could not be trusted, the Internet would come to a grinding halt. Lastly, because so much focus has been on remote applications (particularly by crackers who do often crack across borders or even continents), it is rare to find a remote hole that can result in root or even privileged access.
In contrast, internal applications may often be flawed. It's not that programmers who work on internal applications are less careful than their counterparts who code remote applications; rather, programmers who work on internal applications have a more difficult task. For example, client/server applications are generally limited in their scope. True, these applications may call others, but their scope is typically limited to a handful of operations that occur outside the client/server relationship.
In contrast, local internal applications may be required to interface with dozens of system utilities or processes. As I mentioned at the beginning of the book, many don't expect these utilities or processes to have security implications. Finally, internal applications could be coded by anybody. Third-party vendors abound for local internal applications. Conversely, there are only so many vendors that design fully fledged server packages for a given platform. In the UNIX community, this is especially so. How many HTTP servers are there for UNIX? Compare this to the number of text editors, CD-ROM utilities, and printing tools. The latter exceed the former by a huge margin.
This is less so in the IBM-compatible and Macintosh communities. However, these communities have still other problems. For example, in Windows 95, a malicious cracker could easily attack the underlying database system by removing just a few key files. So there is no comfortable trade-off.
Gathering Information
The internal cracker need not concern himself with complex techniques, such as scanning, and tools. He simply needs to know the system and its holes. This is not a complicated matter.
Much depends upon the type of network he is attempting to crack. However, one thing remains universal, regardless of the platform with which he is working: known holes. To obtain known holes, the cracker may have to do either a little research or a lot (probably a little less now that this book exists).
For information about internal (and remote) holes, BUGTRAQ is a great source. The technical level of the information available there is generally very high. Moreover, there are often detailed analyses of tools and techniques for a wide variety of platforms.
What is even more extraordinary about BUGTRAQ is that readers post to it with detailed information about this or that hole. When a posting like the one referenced previously appears, it is immediately followed by commentary from other members of the list. Much of the time, other members take code, policy, or theory and test it out in their own environment. This yields even further information about the discussed attack.
The fact is, the majority of information posted to BUGTRAQ refers to secondary holes that can only be exploited by local users. Tracking a few such advisories can be instructive. Suppose we take HP-UX as an example; a search through BUGTRAQ looking for pure security advisories or holes produces some very interesting information.
Many types of advisories are posted each day. Many of them contain explicit instructions for testing your state of vulnerability. These instructions generally include source or shell code. A local cracker need not be a genius to exploit this information. In fact, if a cracker is a subscriber of BUGTRAQ (and perhaps a dozen other public security mailing lists), he doesn't even need to search for the information. As soon as a vulnerability hits the wire, it is automatically mailed out to all members of the list. If the cracker is such a member, he gets this news hot off the press. So the information is there. This situation, therefore, breaks the local crack into two categories or classifications:
Ø The crack of opportunity
Ø The average crack
The Crack of Opportunity
An opportunity crack is one that suddenly emerges. This is where the cracker has been monitoring or at least receiving security advisories on a regular basis. He cranks up his browser one morning and a new vulnerability is available. This situation is very common.
The Average Crack
If an average crack occurs on your network, it is your fault and not the cracker's. That is because the average crack involves exploitation of known vulnerabilities. This brings us to an issue of some concern: Just what is a "known vulnerability," and what is the time period after which your security personnel or system administrator should be aware of it?
A known vulnerability is any vulnerability that has been papered. Technically, a vulnerability should not be deemed known until some authoritative source has acknowledged it. Examples of an authoritative source would be CERT, CIAC, or the vendor. However, you should not cast this in stone. Sometimes, vendors hide from the inevitable. They may know the hole exists, but may stall the publication of it until a fix has been found. Even though such a hole has not been papered, it is an existing, known vulnerability. If it has been circulated within the cracker community, it makes little difference whether the vendor is hiding or not. If crackers have started using the hole to exploit systems, and if the first case of this activity has been reported to a security group, the hole is real and known.
Situations like this do arise, and you can identify them. They usually surface as follows: An individual system administrator whose site has been successfully attacked via the hole independently posts to a security list or newsgroup. That post is vague about the particulars but explains that the vendor was contacted. The post indicates that the vendor said it was working on a fix and an advisory. The individual system administrator then requests information, such as whether anyone has had similar experiences.
In general, your system administrator or security personnel should know about a papered hole within one week of its discovery. That is what they are paid to do: Discover holes and the fixes for them. If your network gets cracked because of an age-old hole that has been papered for more than a year, you have a problem.
Remote Local Users
A remote local user is a user who possesses an account on your system but has no physical access to it. In some respect, we are all remote local users because we have accounts on boxes located within the offices of our ISPs. That is, we are local because we are logged to the system and have a user ID and a password, but we are physically remote to the box itself.
This is now becoming more common on private networks and is no longer simply an issue for ISPs and software development firms. People all over the country (even the world) are now doing much of their work at home or on the road. I, for one, haven't seen the inside of an office for over two years. Indeed, this entire book was authored, submitted, and edited without me ever meeting my editors; all of it was done over the Internet. Large firms now have their employees telecommute on a regular basis.
The Process
Whether a user is a local user or a remote local user, his basic attack will be pretty much the same. The only tactical advantage that a true local user has is that he can manipulate hardware and perhaps gain access to certain tools that cannot be used remotely.
Examples of such tools include any X applications. Although X applications can be maintained nicely over the Internet, this is rarely done in practice. First, it is a security risk; second, the client's transmission speed is usually insufficient (if the remote user is cruising with a 28.8 modem). The same can be said for running Windows or Windows NT over the Internet. Unless you have at least an ISDN at both ends, it's not worth the trouble. True, some applications--notably those designed by Microsoft--only move the underlying data as opposed to all that graphical material, but the larger portion of applications aren't designed that way.
Utilities to protect
The Kane Security Monitor
The Kane Security Monitor is available for Windows NT, and a sister application is available for Novell NetWare. The Kane system is extremely flexible, offering system administrators the ability to define their own security events. That is, you can assign significance to a wide range of events that might occur that, in your opinion, constitute a security breach. (This is in some ways the equivalent of the access control alarm model available in VMS.)
NetXRay Protocol Analyzer and
Network Monitor Software
Using Windows? Try NetXRay by CINCO. This truly is a well-coded package. It allows monitoring of multiple network segments, and supports multiple instances of the monitor and capture (and analysis) of just about any type of packet you can dream of. What's more, you can take it for a test drive (but it will only record a handful of packets; it's only a demo).
inftp.pl
inftp.pl is a Perl script that records incoming FTP sessions. It was written by Stephen Northcutt, a system administrator on a military network. Northcutt is the developer of a few finely coded utilities. This utility (perhaps used in conjunction with another from Northcutt, called inpattern.pl) allows you to incisively log FTP traffic. The combination of the two utilities results in logs that trap specific events or patterns. Both are available at the location listed here, as is a document authored by Northcutt titled "What Do Castles Have in Common with Corporate Networks?" The document offers a brief (but surprisingly clear) treatment of firewalls. Northcutt provides some good links in the meantime.
NOCOL Network Operations Center
OnLine
NOCOL, which is for UNIX systems, monitors traffic on the network. It is a big package and has many important features. It uses a standard Curses-based interface, but has support for additional Perl modules written by the user. (It even has a Perl interface. Appropriately enough, it is called PerlNOCOL.)
Internal network breaches are far more common than you think. The problem is, they are not reported as fastidiously as other types of cracking activity. This is due primarily to the need for corporate secrecy. Many in-house crackers are caught and simply discharged with little fanfare.
In past years, internal network security has been a concern primarily for large institutions or corporations. However, the rise of the personal computer changed that climate. Today, most businesses have some form of network. Thus, even if you maintain a small company, you may want to reevaluate your computer security policies. Disgruntled employees account for a high percentage of internal damage and theft of proprietary data. You should have some form of protection and--if possible--a disaster recovery plan.