Enterprise Security - Intrusion Detection Provides A Pound Of Prevention

Published: August 15, 1997

Attacks on systems and networks have skyrocketed as rapidly changing technology, systems integration, global networks, information warfare and hacker boredom have become prevalent. Is your network next? Have you been hit already.

In the past, teams of friendly attackers, known as "Tiger Teams," would test the security of systems and networks. Today, teams like this and friendly attacks by both internal information systems security (InfoSec) staff and consultancies have branched out.

We have put together such a venture. Our team attempts to penetrate a system or an organization's network by taking on the role of attacker. Using an external attack approach, the team typically performs "zero-knowledge" attacks, meaning the team is given only the name of the target organization. Sometimes the client provides the team with the names or the types of systems or information management is most concerned about.

Targets can include payroll and human resources departments, fund transfers, proprietary data (such as product designs and source code) and customer databases. The clients are varied: manufacturing, health care and pharmaceuticals companies and major financial institutions. Here we discuss our attack and intrusion-detection procedures and offer an approach to intrusion prevention.

In addition, we present the methodology used to analyze individual system security and show you how to strengthen intrusion detection using commonly available tools. For more specific information concerning the attack systems and tools used, see "Test Systems and Tools" and "Specific System Attack," on Network Computing Online at https://www.NetworkComputing.com/815/815ws1.html.

Playing the Hacker

Our methodology of attack is similar to that of a would-be attacker. It begins with exploring and mapping the target organization's Internet connections. We start with whois queries to the Internet Network Information Center (InterNIC) to determine domain information, namely Domain Name System (DNS) servers. We attempt to map the internal network topology using DNS queries. Typically, we request a DNS zone transfer from the organization's authoritative name servers. Although most commercial firewalls can block this type of probe, a surprising number of organizations don't implement the block.

Next, using traceroute, we try to uncover possible candidates for a firewall host or packet-filtering router, which would reveal itself as the last hop before our probe packets begin to get dropped. We make a note of this machine's address for reference.

With the DNS zone transfers as a guide, we attempt to find supposedly untrusted machines, just outside the firewall. Most administrators are not overly concerned with security on external machines because these are considered sacrificial machines, relegated to a demilitarized zone. However, these same administrators open their firewalls to permit any type of network traffic coming from these sacrificial machines to connect to machines behind the firewall—either as a convenience to themselves or because of an oversight.

Another problem we see all too frequently is that the untrusted DNS server, though outside the firewall, contains the organization's complete DNS maps. Properly configured, it should contain maps only for those hosts that the Internet-at-large needs to know about, such as the DNS server, the external mail gateway, and possibly, the company's Web site.

Using strobe to perform port scans on these external machines, we can note any and all system services that can be reached for possible exploitation. If we are successful at breaking into any of these machines on the outside of the firewall, we make note of all valid user names in the password file and see if there are any machines mentioned in the hosts file that weren't listed in our DNS maps.

If we obtain "super-user" access, we run crack, a Unix-based password decoder, on the shadowed password file, in anticipation that these same logins and passwords also exist on other machines. We've found that crack does some rather extensive dictionary attacks on people's encrypted passwords and generally has a high rate of success. In some cases, the password file isn't even shadowed, and super-user access isn't required to get at the encrypted passwords.

We also check the hosts.equiv file for systemwide trusted hosts and in people's home directories for .rhosts files, yielding individual trusted logins. Often, machines are configured to reciprocate this trust, opening up a whole can of worms. We peruse the wtmp log with Last, to see where legitimate users are logging in from. With this information, we can fuel our attack.

Then, we proceed to strobe any internal machines that can be reached from this vantage point. We attempt to connect directly to machines behind the firewall, hoping that the firewall has been misconfigured in some way—many times it is. In all cases, we look for old versions of common system services that can be exploited, such as sendmail, yellow pages or Network Information Service (NIS). Utilizing the trusted host information we previously gleaned, we often obtain instant access to many more machines using rsh, rlogin and other Unix programs. We also look for any unusual services running on these machines and attempt to exploit security holes that may be present. We may even have a go at gaining access to the firewall machine itself.

Once on the internal network, we proceed to search for notoriously insecure system services that we can use to get a firm foothold inside the network proper. The more territory we can secure for ourselves early on, the harder it will be to lock us out. This usually takes just 10 to 30 minutes because most organizations are not expecting an attack on their internal network.

Fortifying Our Keep After we've gained access, our next goal is to secure multiple access points into the network in case our initial intrusion is detected. We usually have two main priorities: ascertaining other firewalls on the inside (in the case of a large organization) and identifying any dial-up terminal servers or workstations/servers with directly connected modems. In the course of this search, we keep an eye out for any systems designated as network administration servers.

Typically, network administration machines run some commercial network management software, such as Computer Associates International's CA-Unicenter, Hewlett-Packard Co.'s HP OpenView or IBM Corp.'s NetView. Network administration machines often have trust relationships with other key machines on the network and, more important, boot images and configuration files for routers and terminal servers. These configuration files invariably contain clear-text passwords for routers that are network boot clients.

Most router and terminal server vendors support password encryption, which would make an attack more difficult. However, it seems many administrators are unaware of this feature: Most of them do not enable it.

After securing at least one other Internet gateway for our use, we concentrate on the terminal servers. Dial-up access through a terminal server ensures that we will not be locked out of the network if the organization discovers it is under attack and decides to shut off all Internet access.

We invoke strobe with the name of a site on the Internet. It passively scans it and tells us what system services that we may try to attack are running.

Dial-up lines are almost always overlooked by network security administrators or are managed by a separate group with minimal communication between the two groups. As an added bonus, most organizations rely on remote dial-up access, rather than Internet connections, as part of their core business and will not shut it down—even in the event of an attack. And it is very difficult to change all dial-up passwords and notify the users in a short period of time. It is also rare for an organization to have any significant monitoring capability for dial-up usage. This gives us a stealthy and almost guaranteed way into the network.

The only remaining challenge is to determine the phone numbers assigned to the now-compromised terminal servers. We usually start by looking in both the network administration machines and terminal servers for notes or comments about dial-up telephone numbers. At the same time, we attempt to dial out using the terminal servers' modems to a phone equipped with Caller ID. Failing this, we will run a "war dialer" program that scans phone exchanges looking for modem carriers, and try calling the helpdesk to "social engineer" the dial-up numbers. At least one of these methods always works.

We make assumptions about what exchanges to "war dial" based on phone numbers listed for the organization in the InterNIC, and from files perused on the machines on which we've gained access. We commonly find a helpdesk phone number in the post-login banner of the machines we've compromised.

Once we're sure that we can't easily be locked out, we proceed to map out the internal topology of the network in great detail.

We embark on a campaign to get as much "real estate" (compromised machines) as possible. On each new machine, we search for files containing information about our ultimate target machines—those machines the organization considers most sensitive. We note the names of machines that sound interesting, popular applications running on the network and valid user name/password combinations. Using a combination of this information and assorted technical attacks, we attack our target machines, usually mainframe systems or high-performance Unix servers.

Once we are this deep into the organization's networks, our target machines are no match for our wry wit and charm. Seriously, after having collected so much information about the organization's networks, systems and users, our target's security seems feeble and much too dependent on the outlying security structure. We now provide a demonstration to the client along with full and detailed reports of our activities, thereby concluding the exercise.

Take Two

Another possible scenario, though we have yet to encounter it, is failure to break through any of the Internet connections. If this were to happen, we would begin a systematic dial-up attack to scan the telephone exchanges used by the organization. This would succeed even if the company has implemented an advanced dial-up security system. As all seasoned network professionals know, there's always at least one employee who decides to set up his or her own remote access to a desktop machine using Symantec Corp.'s pcANYWHERE or a similar product without a password.

Note that during the early stages of the attack, we work exclusively at night. This strategy gives us the advantage of being alone on the network and lowers the risk of detection. It also gives us the time needed to clean up evidence of our activities before the network administrators come in for their morning coffee and routine check of the system logs.

Network Intrusion Detection

Knowing that the risk of such an attack is real, you're probably wondering how you can tell if this is happening on your network, and how you can stop it. Let's deal with detecting the intrusion first.

People always ask us how an attack would look from a systems/network administrator's standpoint. We answer that question with questions. What type of monitoring and logging are you using? How much of it is actually turned on? Where do you store the logs? How do you protect them from modification? Which firewalls, terminal servers and internal machines are logging events? How often do you review the logs? Do you have tools to reduce the "signal-to-noise" ratio? Do you have an alarm mechanism?

All of these factors, and more, will dictate how much of an attack you can detect and how fast. Many organizations concentrate their intrusion detection efforts on their firewalls and ignore internal machines and dial-up lines. This is a mistake. Many firewalls are configured to log direct attacks against the firewall and don't highlight unusual activity coming from a trusted external machine, such as a Web server or DNS server. Additionally, attackers may not bother with your Internet connections. They may go straight for the dial-ups or come in from a business partner network connection. Your firewall can't log something it didn't see, right?

We first invoke crack with the purloined password file, which it subjects to its extensive dictionaries of words. We check on creack's progress from time to time with its reporter to see how successful it's been so far. Looks like we hit the jackpot!

Some people will tell you that all you have to do is monitor your network perimeter—firewalls, dial-ups, business partner network connections, and so on—and you'll be fine. This kind of thinking assumes that you know what your "perimeter" is at any given time. Remember our employee with the desktop dial-up? It also ignores the threat from malicious employees or contractors on your internal network.

We recommend that you focus your efforts across the board. It's important to monitor your network perimeter; however, you should also enforce security monitoring on internal machines. We have found that many organizations ignore the internal component of intrusion detection, much to their chagrin.

Network Intrusion Prevention

It's difficult to decide how to go about securing a large network and influencing an even larger number of users to practice good network security. Most people have a reactionary mind-set. Wait until something happens, then panic. For example, at the conclusion of these penetration tests, we provide a briefing to the senior management team at the client. The usual knee-jerk reaction is to shut down the Internet connections, pending the purchase of (better) security software.

What do we recommend? You might think that our advice, as advanced system hackers, would be of a technical nature. Do we suggest something along the lines of an advanced cryptographic system, smartcards, biometric authentication and the like? Nope.

We recommend that our clients start with the basics—build a strong foundation that can realistically improve security without wasting resources on ineffective security measures. There are so many simple things that an organization can do that get overlooked. Start simple.

The most often overlooked problem is that there must be an overall plan to address the many components that make up security. A risk assessment should be performed to determine the acceptable risk level to the organization. The results of the risk assessment will then drive the tone and rigor of a set of security policies, procedures and guidelines that tell people what they should do and how to manage information assets. Finally, a security architecture can be drafted to give direction as to which products and tools will be required to enforce the security policy. Just buying security software and distributing it to systems administrators is a waste of time and money. They'll get the software and not really be sure how to configure and manage it. And without understanding your risk, you'll never know when enough is enough.

This type of program is a long-term investment. It doesn't give instant results and there's no point where you can say "we're secure." Nothing will do that. There is no such thing as 100 percent secure. However, what it will do is gradually but surely improve security over time, giving you the peace of mind you're seeking. At the heart of any secure network should be a well-thought-out security policy. Otherwise, your network security will amount to some cheap trick, just smoke and mirrors.

Mark Abene is an independent security consultant.

Steven Lutz is an information security consultant at Ernst & Young LLP.
Dr. Gerald L. Kovacich, CFE, CPP, CISSP, is president of Information Security Management Associates, an InfoSec and high-tech crime investigations consulting firm.

Mark Abene can be reached at phiber@phiber.com.

Steven Lutz can be reached at steven.lutz@ey.com.
Gerald L. Kovacich can be reached at kovacich11@home.com.

For a Q & A on information security and intrusion detection see Network Computing Online at https://www.networkcomputing.com/815/815ws1.html.

"Copyright © 1997 CMP Media Inc., 600 Community Drive, Manhasset, NY 11030.

Reprinted from Network Computing with permission.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.