Remote Access

If attackers can't come in through the front door, they'll certainly go looking for the back. You will need to ensure that your authorized remote access systems (your backdoors) are well protected. In addition, you'll need to ensure that there are no backdoors you do not know about. In this step, we'll cover wardialing (searching for modems) and wardriving (searching for wireless access points). We'll also talk about VPN and reverse proxy testing.

Wardialing

Wardialing used to be the most popular way for attackers to break into corporate networks. This was before the Internet provided an easier method. Although its popularity has diminished, it is still a widely used technique for breaking past perimeter security controls.

Wardialing is primarily about finding modems within the phone number ranges assigned to your organization. The method is fairly easy. A computer is configured to dial each number and listen for any responding modem or fax tones. When it detects a modem or fax, it records the number and may also attempt to communicate with the responding device to determine what type of system it is. Smarter wardial programs are able to detect many remote access programs and can optionally attempt to log in to any authentication prompts provided by the answering modem.

One popular open source tool you can use for wardialing is THC-Scan from The Hackers Choice (http://www.thc.org). Although not exactly a new tool (the current version was released December 1998), it is still a useful wardialer. It supports the basics of wardialing and can detect modems, faxes, and PBXs, voice mail boxes, and voice (that is, a real person picking up the line).

Another more recent product that you may want to look into is ModemScan, available at http://www.wardial.net. ModemScan runs under Windows and has a user-friendly GUI. Many people find it easier to configure than THC-Scan, though both perform similar functions.

Commercial scanners are also worth examining. The current market leader is PhoneSweep, by SandStorm Enterprises (www.sandstorm.net/products/phonesweep). PhoneSweep supports many advanced features, including the ability to dial out on up to eight modems at one time simultaneously. PhoneSweep also has patented technology to support the identification of devices it detects.

Just as with any other part of your assessment, careful planning pays many dividends when performing your wardial. First, you need to determine which telephone lines belong to your organization. Even more important, you need to identify which numbers within this range are off limits. It is especially critical that you remove any emergency service numbers that may exist at your site. You would not want to block access to police, fire, and rescue numbers during your wardial exercise! All this targeting information needs to be included in your rules-of-engagement document.

You will also want to determine the times you will be wardialing. Getting a complete record of the modems in use in your environment may require conducting multiple wardial exercises during different hours of the day. For instance, users may only turn on their modems after hours to allow themselves access to their workstations from home. You may also want to avoid wardialing during certain periods to prevent business disruption. As with the target information, you will want to record test hours in the rules-of-engagement document.

Next, you will need to assemble your equipment. You will need a computer, modems, telephone lines, and software. It is better if the computer is not connected to your network. This is to prevent the remote possibility of someone dialing in to one of the attachment modems and gaining access to your network. The modems you select should be "real" modems, not Winmodems or any other type of DSP-based modem. Winmodems work by emulating a real modem and may not work as well for wardialing purposes. The telephone lines you use should be plain-old telephone service (POTS) lines. You should also disable any special phone services such as caller ID and call waiting. These can confuse the wardial software. Last, you will need to install and test the software you have selected to use.

Testing is an important part of wardialing. Wardials take a long time to finish. You would not want to conduct several days of wardialing only to find out that your wardialer was malfunctioning. Your test should include steps to verify that every type of connection you expect to encounter is properly identified by the wardialer. Here are some of the devices you may want to identify during your wardial exercise:

• Modems

• Faxes

• People

• Voice mail

• ISDN lines

• Busy lines

You will also need to decide how many rings to allow per number. Many modems will answer after only three rings, but this is configurable. If the modem is set to answer after five rings, and you only wait for four, you will not detect the modem. However, setting the ring count high will drastically slow down your scan. A typical setting is six rings, but you will need to carefully make this decision before proceeding.

Tip

Because many wardialers will default to five rings, you can add security to your site by increasing the ring count for your authorized modems to eight. Although this will make connecting to these modems slower, it may be a small price to pay to avoid detection by modem-based attackers.

Finally, you will perform the wardial. After the wardialer has finished, it should report back to you the telephone numbers with responding devices. Depending on the sophistication of your tool, you may also get other information, including identity and authentication details. For each reported number, you will need to verify whether the number is part of an authorized modem bank or is rogue. All rogue modems should be eliminated from your organization. For the remaining modems, you will want to verify that they effectively limit access to authorized users. This means enforcing the use of good usernames and passwordsor better yet, using a strong authentication system such as RSA's SecureID tokens.

Wardriving

801.11-based wireless LANS are very popular and very inexpensive to implement. In fact, they have become so inexpensive that users have probably started attaching wireless access points they have purchased to your internal network. Most of these have no security turned on, but as we discussed in Chapter 14, "Wireless Network Security," even if they did, attackers may still be able to use them to break into your network. Finding and eliminating these rogue access points is a very important part of securing your perimeter. In addition, you will want to verify that your authorized wireless LANS are properly secured.

Wardriving is the process of moving a wireless LAN receiving station around an area attempting to detect wireless LAN emissions. This can be done walking, driving, or even flying!

Most wardriving is performed using a laptop (or PDA) computer configured with software that sniffs wireless connections. It is also desirable to have a GPS or other type of location device to record exactly where you are when you detect the wireless LAN signals. The information you record in this case is the latitude, longitude, LAN identifier, and signal strength. If you move around and collect enough data, you can create a signal strength footprint that can be overlaid on top of a map. This makes it much easier to physically locate the access point.

Tip

Using an external antenna on the wireless access card you use for wardriving will dramatically increase the amount of access points you will detect. The internal antennas on most cards are toys compared to a good quality external antenna.

Many products exist to perform wardriving. A popular Windows-based program is Netstumbler (http://www.netstumbler.com). It has a well-designed graphical user interface and is reasonably easy to install. Many wardrivers, though, tend not to use it because it has difficulty detecting wireless access points that are not broadcasting their SSIDs.

Kismet is currently the most popular wardriving package. Kismet is available for Linux, and a port for Windows will probably eventually show up. What makes Kismet good for wardriving is that it will capture any wireless conversation that occurs and use this to detect access points, even if the access point is not broadcasting its SSID. In addition, Kismet can output packet captures in Tcpdump format. This makes it easy to analyze packet captures in open source packet-decoding software such as Ethereal. Last, Kismet (and Netstumbler) also supports a GPS interface to grab location data with every packet received. Figure 22.13 shows Kismet running at a recent SANS conference.

Figure 22.13. Kismet is excellent at detecting wireless access points.

The process of performing the wardrive is fairly simple once you have your equipment set up and tested. Simply move your equipment around your facility, recording any signals you receive. If you detect an access point, you should collect enough information to identify itand hopefully locate it. Later, you will compare the list of access points you found to the list of authorized access points for your site. Any rogue access points should be shut down immediately. This can be significantly complicated if you've got organizations near yours that have wireless LANs set up. In these cases, you may be able to use the location data from your GPS to determine whether the LAN is yours or not.

There are a couple of items to keep in mind if you plan to use a GPS to find access points. First, the GPS signal is line-of-site. If you cannot see the sky, you are probably not receiving any GPS signal. This means no location data inside. In these cases, you will have to manually record your location as you walk through a building. Next, make sure you are using an omni-directional antenna for GPS-based wardrives. Using a directional antenna will skew the signal strength results, depending on the direction the antenna is pointed. Use of directional antennas is still a good idea, though, to detect faint signals that may be coming out of some of your facilities.

If you are having difficulty tracking down an access point, you may be able to locate it based on the SSID. For instance, if you are near a Starbucks, an access point with an SSID of T-MOBILE is unlikely to be connected to your network! Instead, highly caffeinated customers are probably using it to surf the Internet.

At the end of your wardrive, you should have a good idea of what access points exist in your area. You can use this as a baseline for future scans, which you should conduct regularly. You will also want to verify the security controls for the access points you allow to remain on your network. As with modem-based access, strong authentication is a must. In addition, though, you should make sure that good encryption is used to protect all your wireless LAN conversations.

Note

The RC4-based encryption built in to 802.11 products is not considered strong.

VPNs and Reverse Proxies

The last form of remote access we will look at involves VPNs and remote proxies. Because the problems you will encounter are similar between VPNs and remote proxies, for the rest of this section, we will generically refer to both as VPNs. VPNs provide a popular way to allow remote employees to gain access to internal network resources. When well implemented, they can be very secure. However, it is important we verify that several key facets of the VPN are correct. Here are several areas we will need to examine:

• Encryption algorithm and key strength

• Method and strength of authentication

• Access controls

• Client-side restrictions

Encryption

Encryption has proven to be a reliable way of protecting network conversations. However, it is only as good as the algorithm and keys it is built upon. When assessing your VPNs you need to verify that a trusted algorithm is in use and that you cannot connect using weaker algorithms. Many VPN devices will support strong encryption but will agree to use weaker algorithms if requested. Man-in-the-middle attackers may make use of this feature by interrupting the session negotiations that make use of the better algorithms. Some VPNs will then fall back to the weaker systems. To make sure that your VPN does not do this, you should attempt to connect to your VPN using all the algorithms supported by your device and record which ones work. Any successful connections for algorithms or key sizes that are weaker than your policy allows indicates that your VPN may be vulnerable to this type of attack.

Authentication

The next item to examine is authentication. Any type of remote access should be carefully authenticated to prevent attackers from bypassing your perimeter controls. If you are using username/password-type authentication, you will want to make sure that your account policies are effective and that no weak passwords are assigned to your user accounts. Account policies, such as the number of attempts allowed before the account is locked out, can be tested by attempting to get the policy to trigger and noting the effect. If the account should lock out after three attempts, you should verify that this does happen by attempting four incorrect log-in attempts to the same account. Verifying password strength is more difficult.

A variety of password-cracking packages are available for your use. They can be separated into two main categories: online tools and offline tools. Online tools attempt to guess passwords by actually attempting logins. Any protocol that provides a login prompt can be assessed using an online tool. A good example of an online tool is Hydra (http://www.thc.org/releases.php). Hydra can attempt to log in to a target system using many protocols. It supports HTTP Auth, Telnet, FTP, IMAP, POP3, MySQL, and many others. In addition, Hydra is fully parallelized (it can send many simultaneous requests per second). Hydra is also the password cracker that Nessus uses to perform its password cracks.

Offline tools do not attempt to log in. Instead, they work using a copy of your encrypted (actually hashed) passwords. An offline tool works by taking a password guess, encrypting it using the same algorithm as the login process of the system being assessed, and then comparing the resulting value with the stored value. If the values match exactly, that means the guess equaled the password (in other words, the password has been cracked). Offline tools work many times faster than online tools, but you do need to be able to get a copy of the password file from the systems you will be assessing for them to work. You have many offline tools to choose from. On UNIX, many sites choose to use Crack, written by Alec Muffett (http://www.crypticide.com/users/alecm). Crack is primarily used for cracking passwords created using the crypt algorithm. This is the algorithm that most UNIX systems use to create their passwords. However, Crack can be compiled to support many other password algorithms. Crack is a dictionary-based tool that supports sophisticated word permutation. This means that you can feed Crack a list of words, and Crack will take each and perform interesting substitutions and modifications to crack the passwords when users have made small changes to a word to create their passwords. For instance, if the word is apple, Crack might try @pple, @pp1e, @pp13, apple1, and so on. This makes it much more likely that Crack will guess a user's password.

Another password cracker you should look into is John the Ripper (http://www.openwall.com/john). John comes preconfigured to crack several password algorithms, including UNIX crypt and Windows LANMAN hashes. It also supports permutation, as well as provides interesting brute force modes where it attempts many combinations of letters, numbers, and symbols to guess the password. With the increasing processing power available to us, brute force methods have become increasingly useful in discovering weak passwords.

The last password-cracking tool we will mention is L0phtCrack (http://www.atstake.com/products/lc). L0phtCrack is a commercial tool that was originally created to attack Windows LANMAN hashes but has recently added UNIX support. It has also added precomputed password tables, which can drastically speed up the process of breaking most English alphanumeric passwords. This is based on the research of Philippe Oechslin and is also implemented in an open source project called RainbowCrack (http://www.antsight.com/zsl/rainbowcrack/). L0phtCrack is an excellent password cracker that is user friendly and supports many useful features. However, it is significantly more expensive than free! If your budget supports it, though, it comes highly recommended.

If you can gain a copy of the password hashes for the system you are testing, use an offline tool. You will get better results faster. If you cannot, use an online tool. Either way, make sure to address this area because it is one of the most common ways that attackers gain access to networks.

In addition to worrying about the strength of the passwords, you need to look at how secure the transfer of the usernames and passwords is. If you allow the use of unencrypted protocols such as Telnet, any eavesdropper in your user environment will be able to capture a user's password. He then has free reign to log in to your network. You can reduce this risk by requiring the use of protocols that encrypt their authentication sessions. For example, if you are using a reverse proxy, you should verify that authentication only occurs after an SSL session has been established. This is only a partial solution, though. What if your users are using a web café to log in to your network? If a keystroke logger is installed on the computer your users choose to use, no amount of encryption will keep the password out of the hands of the attacker. A better, though more expensive solution is requiring strong authentication for all remote access.

Access Controls

A common configuration (some would say misconfiguration) of VPNs is to establish a protected connection between two organizations but enforce no restrictions on the traffic that can flow across the VPN. This, in effect, allows both organizations to bypass each other's perimeter security controls. If this actually is what was intended, you do not have any specific tests to perform in this area. However, if you have limited the connections that can be made through the VPN to the set needed by your remote users or remote business partners, while blocking access to more sensitive areas of your network, you will need to verify that these restrictions are being enforced. The methods you will use are identical to the tests you performed during the firewall verification. This time, though, you will be running the tests from a test system that has established a VPN connection into your network. You will want to attempt to scan systems and protocols that you are allowed and not allowed to reach to ensure that the filters are working correctly. You will also want to attempt scans before and after authentication to make sure the VPN device is properly blocking communications prior to VPN establishment.

Client-Side Restrictions

The last item you should examine for your VPNs is the effectiveness of controls on the client. If a user has established a VPN connection to your network, it is possible that an attacker who can compromise the user's computer can route his packets through the user's computer into your network. Some VPN products disable any routing functions while the VPN is established. If your product supports this, you should verify that it is working by attempting to enable the routing function of the user's workstation and sending packets to the workstation destined to your internal network. This will normally require that you establish a static route on your test workstation that sends all traffic destined to your internal IP addresses to the user workstation being examined.

Using antivirus and personal firewall products is also a very good idea for remote users' computers. If you require the use of these types of products, you will want to verify that they are installed, up to date, enabled, and effective. Just as with your public systems, vulnerability scanners can be run against your users' remote systems to check for exposures.

Testing for client-side restrictions is only realistic, though, if you enforce some kind of configuration control on the systems you allow to connect in to your network. If you allow users to connect using their personal systems, or while they are on the road with borrowed or rented equipment, you will have to rely on other controls to protect the access.