As the saying goes, there is more than one way to skin a cat, and in the digital security world this saying holds some definite truth. Attackers can often compromise an organization’s network without ever having to touch a perimeter firewall. This chapter is about some of the ways they do this—for example, by compromising a dial-up-enabled system, which can provide almost immediate access to internal networks. Dial-up access is a threat that tends to be overlooked or neglected by almost every organization, and in this chapter you’ll look at the dangers of doing so. You’ll also look at threats created by deploying wireless networks, and finally, you’ll look at issues that are specific to Bluetooth devices. Let’s start skinning that cat.
A common way attackers try to bypass an organization’s perimeter defenses is to gain access to dial-up systems connected to a public switched telephone network (PSTN). To detect these systems, attackers dial telephone number blocks belonging to an organization, looking for responsive modems that might be poorly secured. This identification process is known as war dialing. (War dialing is also called demon dialing and carrier signal scanning.) The example network topology shown in Figure 13-1 illustrates how war dialing poses a threat to your organization’s security.
Figure 13-1 shows a typical network configuration. The database server located in the internal network is a prime target for attackers because it stores social security numbers, financial information, and other valuable information. An attacker coming in from the Internet would have a series of security mechanisms to defeat before reaching the prize. A firewall at the perimeter protects the perimeter network (also known as the demilitarized zone or DMZ); if he is able to bypass this firewall, access beyond the perimeter network to the internal network is protected by a second firewall. The administrator of this network also went a step further and raised the bar on potential attackers by placing intrusion detection system (IDS) sensors on segments immediately before and after the second firewall to detect and stop malicious traffic inbound toward the internal network. Assuming that the firewall rules, systems, and application are well designed and configured, being able to connect to the database server, let alone compromising it, is a formidable task. Score one for the good guys.
The attacker hasn’t lost yet, however. Unfortunately for the defenders, misconfigured modems still pose a threat, as illustrated in Figure 13-2.
The example network has several places where an attacker might find dial-up systems. One of these is the user desktop environment. Gaining access to any dial-up system through the PSTN allows the attacker to bypass all the security mechanisms on this network and gain an unobstructed path to the database server. Score a big one for the bad guys.
Important
Don’t be fooled into thinking that desktop environments are the only place where the threat of insecure dial-ups exists. Every system on your network (firewalls, routers, desktops, and so on) has the potential to have a misconfigured modem attached to it, and these devices need to be detected. No system is exempt, so scour your entire network for these types of holes.
Why insecure dial-ups are a threat to your organization should be clear, but before you start war dialing your own organization’s telephone number blocks, you must understand an important "how" aspect. Like most systems, services, or devices on a network, modems become a security risk when the software controlling them is misconfigured, unpatched, or contains weak passwords. Compared to other systems, services, and devices, dial-up access systems are much easier to introduce into your network without your knowledge.
Let’s take a Secure Shell (SSH) server as an example. If a company employee wants to enable external SSH access to an internal system, she’d have to install the SSH server software and then, in an additional step, ask the network administrators to allow incoming SSH traffic (typically through port 22) at the firewall. When informed of the presence of an SSH server on their networks, administrators can take appropriate actions to secure the server. Setting up a modem for remote access does not require this extra step. Any employee who wants to access internal systems without being on location can do so simply by connecting personal systems to the PSTN and downloading and enabling remote-access software (such as Symantec pcAnywhere)—all without needing to inform network administrators that a big hole has just opened up on their network. The important point to remember is that dial-up access systems can be attached to your networks without your knowledge; if not properly secured, these unauthorized dial-up access systems can become a real security hazard. Detecting and securing these access points will be discussed later in this chapter.
War dialing your own organization is fairly straightforward and can be broken down into the following steps:
To be able to detect an insecure modem you have to know which telephone number to dial. As an employee of your organization, you are in the fortunate position of being able to acquire this information easily from telephone administrators or your operations centers. Attackers, on the other hand, have to guess at a potential telephone number block based on numbers found through a variety of different sources, such as registrar records, business cards, SEC filings (via Edgar Online), phonebooks, and phone number lookup via Google and services such as www.555-1212.com
Tip
Using automated war dialers requires providing these tools with a list of phone numbers to dial. If your organization’s telephone number block ranges from, say, 123-1000 to 123-9999, manually typing all 9000 numbers into a list would be extremely tedious and prone to error. It’s easier to make this list with the help of your favorite scripting language, such as Perl or VBScript. The following example uses the Windows FOR command to generate a phone list from 123-1000 to 123-9999 into the text file Wd_phonelist.txt:
for /L %i in (1000,1,9999) do echo 123-%i >> wd_phonelist.txt
Once you identify the telephone number blocks to dial, the next step is to actually dial those numbers and start detecting dial-ups. To do this, you can use automated or manual techniques.
Automated techniques. There are several free and commercial tools called war dialers that you can use to automate your war dialing attacks. Some of them are listed in Table 13-1.
Most war dialers work in the same way. You give them the telephone number blocks you’ve identified and the war dialer dials the telephone numbers one by one. If a modem is detected, the telephone number is flagged and the war dialer moves on to the next number. At the end of the war dialing session, the war dialer returns a list of telephones with responsive modems.
A problem with automated war dialing is that it can take a long time to complete. Assume that it takes 20 seconds to test each number, which makes the total time to complete a war dial for a telephone block of 10,000 numbers to be 200,000 seconds, or a little more than 55 hours.
Tip
Be aware that dialing large blocks of telephone numbers in sequential order can sometimes invoke the ire of local phone carriers. Be sure to inform them of your war dialing activities before conducting your tests and also to check with your legal representation and make sure that the statutes are in your favor.
Manual techniques. A more efficient way to detect modems connected to the PSTN is to do a "walk through." This technique involves security teams physically moving from computer to computer checking each one to see whether it is connected to the PSTN. An obvious disadvantage of this method is the staff resources it requires. However, it has the advantage of finding all modems connected to the PSTN whether they respond to incoming calls or not.
Once attackers identify dial-up-access systems, attackers will try to gain access to those systems. They attempt to gain access in much the same way they would for any other system such as a database, Telnet, or Web server:
Weak passwords. Check all dial-up systems for weak passwords (see Chapter 15). Remote access setups for business partners are notorious for weak passwords and are prime targets for attackers.
Application weaknesses. What software is being used with the detected dial-up systems? Does it have the latest patches? Does it have any known vulnerabilities that attackers could exploit?
Configuration weaknesses. If the dial-up is authorized, is it configured correctly? For instance, check to ensure that there are no default accounts enabled with known default passwords. Eliminate any accounts that are enabled but no longer used.
Here are some countermeasures to help reduce the risk from insecure modems:
Create policy. Create a policy that clearly indicates whether dial-up access is allowed. If it is allowed, define its terms of use in the policy.
Use strong passwords. If dial-up-access systems are allowed in your organization, they should be protected by strong passwords. This goes without saying for any system or device on your network. (For more information about password attacks, see Chapter 15.)
Patch systems. Make sure that all remote-access software has up-to-date security patches.
Scan regularly and frequently. Conduct war dialing and walk throughs for your organization on a regular and frequent basis. Scanning your organization just once or infrequently is inadequate security, because dial-ups can be introduced into your network at any time and without your knowledge.
Secure network design. Systems that provide dial-up access should not reside on your internal networks and be quarantined elsewhere. If a remote access system is compromised, the threat level exposed by the intrusion can be mitigated by other mechanisms, such as a firewall, as illustrated in Figure 13-3.
Use callbacks. A callback is a security feature in which the remote system validates a caller’s credentials, hangs up, and calls the client back at a predetermined authorized number to establish the session. (See Figure 13-4.) You should use callbacks when you know ahead of time what telephone numbers clients will use to access your systems remotely over the PSTN.
Using callbacks helps to ensure that only legitimate clients can access remote systems.
Disable or remove unnecessary modems. Remove modems from systems that do not require use of a modem. If removal is not possible, disable the modem. For systems that do require use of a modem, the modem should be enabled only when it’s needed and otherwise disabled. Removing or disabling unnecessary modems will greatly reduce your exposure to war dialing attacks.
Wireless networks have created a world of mobility for users, but they’ve also created a world of security headaches for organizations trying to protect their networks. Common security measures for wireless networks include:
Media Access Control (MAC) address filtering
Disabling Service Set ID (SSID) broadcasts
Protecting Wired Equivalent Privacy (WEP)
Let’s take a look at how inherent weaknesses in each of them can create a threat to your organization. Later in this section, more reliable security alternatives are discussed.
The MAC address of a network interface card (NIC) is used to uniquely identify devices on a network. MAC filtering, which is designed to allow NICs with certain MAC addresses onto a wireless network and leave all others out, is a half-baked security measure that will keep low-skilled attackers out of your wireless network but not others. Relying solely on MAC address filtering for wireless security is not a good idea for the reasons given in this section.
The first three octets of a MAC address—also known as the Organizationally Unique Identifier (OUI) or company_id—can be used to identify the manufacturer of a NIC. In Figure 13-5, the first three octets are 00-06-25. According to the Institute of Electrical and Electronics Engineers (IEEE), which assigns OUIs, the organization that manufactures this NIC is The Linksys Group. A current list of organizations and assigned OUIs can be found at http://standards.ieee.org/regauth/oui/oui.txt.
Several 802.11 devices implement MAC filtering to keep unwanted devices from entering a wireless network. Here’s an example of how it works. Assume an attacker with a MAC address of 12-34-56-78-90-00 wants to gain access to a wireless network that filters all MAC addresses except 00-00-00-00-00-01 and 00-44-22-55-00-08. With MAC filtering enabled, the attacker should be "blocked" from this wireless network, right? Well, not exactly. The problem with relying on MAC filtering to keep attackers out is that attackers can simply configure their wireless NICs to an unfiltered MAC address as illustrated in Figure 13-6. It’s fairly easy to determine which MAC addresses are allowed because they are sent in clear text and can be sniffed by tools such as Kismet (http://www.kismetwireless.net) and AirSnort (http://airsnort.shmoo.com.)
The network name or Service Set ID (SSID) of a wireless network is a unique, 1-to 32-byte identifier used to differentiate two physically close wireless networks from another. Any wireless device that wants to connect to a particular wireless network in infrastructure mode, where wireless networks are bridged with Ethernet network, must know the wireless network’s SSID. The problem with this scenario is that the SSID is essentially a secret shared by many users and devices. A SSID known to many is a definite security no-no because you have zero control over who knows the SSID and can access your wireless network. Figure 13-7 shows wireless network SSIDs detected using Microsoft Windows XP.
Several access point (AP) manufacturers advise network administrators to disable SSID broadcasting to hide wireless networks from unauthorized users and attackers. However, as with MAC address filtering, disabling SSID broadcasts does not prevent unauthorized access; it just makes determining a valid SSID a little less automated for attackers. The inconvenience to the attacker is negligible because determining the SSID on a non-SSID-broadcasting network is not difficult, for the following reasons:
Default SSIDs. Several manufacturers ship their AP with a default SSID such as "linksys" or "default." Network administrators often do not know that they should change these SSIDs, so knowledgeable attackers can gain access to a wireless network regardless of whether SSID broadcasting is disabled.
Sniffing. Even with the SSID changed to something difficult to guess and SSID broadcasting disabled, an attacker can use a wireless sniffer to retrieve a wireless network’s SSID.
The last common wireless security mechanism we’ll look at is the Wired Equivalent Privacy (WEP) protocol. Get ready for more security foibles.
Wired Equivalent Privacy (WEP) is a security protocol defined in the IEEE 802.11 standard; it is used to protect wireless networks from unauthorized access and sniffing attacks. Like MAC address filtering and disabling SSID broadcasting, the WEP protocol suffers from several flaws. To understand these flaws, you need to first understand how the protocol works.
More Info
A copy of the IEEE 802.11 standard can be found at http://standards.ieee.org/wireless.
To help prevent unauthorized access to wireless networks, the 802.11 standard defines open system authentication and shared key authentication.
The name "open system authentication" is misleading—a better name would be "open door authentication" or "unauthorized users please come in authentication." Because this authentication scheme allows any wireless device (attackers and all) to join the wireless network, it is a very weak authentication mechanism. Figure 13-8 illustrates open system authentication.
As shown the figure, when a device attempts to join a wireless network, it first sends an authentication request to the access point. The request is accepted without challenging the device and the access point "authenticates" the device and the device joins the network.
Shared key authentication requires the access point and the joining system to share the same WEP key before a system is allowed to join a shared key authenticated wireless network. Figure 13-9 illustrates this authentication process.
When a device attempts to join the wireless network, it first sends an authentication request to the access point. The access point responds with a random challenge that the device takes and encrypts with the shared WEP key to produce ciphertext. The access point decrypts the ciphertext, extracts the plaintext, and compares it with the original challenge. If the two match, the device is allowed to join the wireless network.
Let’s look at these steps in more detail to understand WEP weaknesses. In step 2 in Figure 13-9, the access point sent the wireless device a challenge to encrypt with the shared WEP key and produce ciphertext. To do this, the client performs an exclusive OR (XOR) on the challenge and checksum data with an RC4 key stream that was generated by seeding a pseudo random number generator (RNG) with a 40-bit or a 104-bit WEP key and 24 bits of random data called an initialization vector (IV).
The binary exclusive OR (XOR) operator returns 1 if one of its inputs is 1 and the other is 0, and returns 0 if both inputs are 1 or 0. The following table illustrates this behavior:
A | B | A XOR B |
|---|---|---|
0 | 0 | 0 |
0 | 1 | 1 |
1 | 0 | 1 |
1 | 1 | 0 |
The challenge usually is a random 64-bit or 128-bit number; for our example, however, we’ll use something shorter and pretend the challenge is ABCD, which is 0×41 0×42 0×43 0×44 in hexadecimal notation or 01000001 01000010 01000011 01000100 in binary notation (let’s not worry about checksums). The ciphertext of ABCD would be generated in the following manner:
Challenge (C) | 01000001 01000010 01000011 01000100 | |
XOR | RC4 key stream (K) | 01010101 01010101 01010101 01010101 |
Ciphertext | 00010100 00010111 00010110 00010001 |
The device sends the ciphertext (C XOR K) and the IV to the access point, as shown in step 3. In step 4, the AP takes its copy of the shared WEP key and the transmitted IV and creates a matching key stream. An XOR operation then decrypts the ciphertext with the key stream to retrieve the plaintext.
00010100 00010111 00010110 00010001 | ||
XOR | RC4 key stream (K) | 01010101 01010101 01010101 01010101 |
Plaintext | 01000001 01000010 01000011 01000100 | |
Original challenge | 01000001 01000010 01000011 01000100 |
Bingo! The plaintext (CT XOR K) converted to ASCII produces ABCD, which matches the original challenge exactly and so the client is allowed onto the wireless network. No problems so far, right? Well, not exactly. Look at how we produced the ciphertext and the plaintext, and consider the following behavior of the XOR operator:
If A XOR B = C, then C XOR A = B and C XOR B = A
Say that A is the plaintext challenge, B is the key stream, and performing the XOR operation on (or "XORing") A and B produces ciphertext C. Therefore, XORing the original challenge with the ciphertext should produce the key stream. Let’s try it out:
Original challenge | 01000001 01000010 01000011 01000100 | |
XOR | Ciphertext (CT) | 00010100 00010111 00010110 00010001 |
RC4 key stream (K) | 01010101 01010101 01010101 01010101 |
Any attacker that can sniff the plaintext challenge (Step 1) and the ciphertext (Step 2) can derive the key stream without knowing the shared WEP key, and then use it to authenticate herself onto the wireless network.
What’s more, the key-scheduling algorithm of RC4 has a known vulnerability that allows attackers with enough packets to retrieve static WEP keys. Having a WEP key allows an attacker to decrypt any packet encrypted with that key and view its contents (unprotected credit card numbers, medical records, and so on). The situation is made worse by the fact that WEP keys are static and not easily or often changed.
WEP is also used to protect data in transit across a wireless network. As described earlier, the size of the IV is 24 bits, and so the number of possible IVs is 224. This is not too huge of a number when counting packets on a network. If one IV per packet is used on a wireless network, IVs will have to be reused at some point. Since the IVs are sent in clear text, an attacker sniffing packets over the wireless network can build a large database of IVs and their corresponding key streams (we just showed how an attacker can determine key streams by XORing plaintext and ciphertext). Any packet that uses an IV that the attacker has a record of could be easily decrypted using the matching key stream.
More Info
Detailed research done by Nikita Borisov, Ian Goldberg, and David Wagner on WEP weaknesses can found at http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html.
Important
Looks like three strikes already for wireless security. Don’t give up on it yet. Remember that layering security mechanisms such as MAC address filtering, suppressing SSID broadcasting, and enabling WEP will stop a majority of less sophisticated attackers. Any roadblock you put in front of attackers is much better than none at all. The key is to be able to recognize the weaknesses in each and not to rely solely on one to protect your wireless networks. Additional mechanisms to further protect your wireless networks will be discussed next.
Penetration tests of your organization’s wireless networks can be divided into the following steps:
Detecting wireless networks
Assessing vulnerability
To detect wireless networks, attackers drive around your organization’s physical premises (hence the name war driving) with war driving tools. Their goal is to detect insecure wireless networks that they can compromise. You should conduct your own war driving penetration tests to determine how far outside your organization’s premises your wireless networks are exposed (plus it’s a good reason to get out of the office). You should also perform war driving attacks inside your organization to try to detect any unauthorized access points that could pose a threat; this type of war driving is known as war walking.
Table 13-2 lists some free and commercial tools that you can use to help you analyze wireless networks.
Table 13-2. Wireless Network Analysis Tools
Location | |
|---|---|
AirSnort | |
Kismet | |
Sniffer Wireless | |
NetStumbler | |
WaveStumbler | |
AirMagnet | |
Ethereal |
Note
Another interesting way to find wireless networks is to look for war chalking inscriptions. With war chalking, attackers make a notation on a sidewalk or nearby wall about a wireless network they’ve detected from outside an organization. As part of your penetration tests, you should simply walk around your company premises looking for these markers. Of course, this method relies on someone having taken the time to chalk a location where they detected a wireless network, so keep in mind that it’s not an especially reliable method of detection. More information about war chalking can be found at http://www.warchalking.org.
Once you’ve detected a wireless network within your organization, you’ll need to determine what security mechanisms are protecting your network, if any. Ask the following questions:
Is WEP enabled? Are you using a 40-bit or 128-bit key?
Is MAC filtering enabled?
Is SSID broadcasting disabled?
What other defenses do you have enabled on this wireless network?
You learned that several of these mechanisms are easily defeated; now you need to know what protection you do have, and what risks you’re exposed to.
The point of war driving is to locate wireless networks that might be used to gain further access and, as you learned in the previous sections, there is almost nothing you can do to stop attackers from detecting your wireless network. However, several countermeasures can help prevent your wireless networks from being compromised:
Create policy. Prohibit the use of wireless equipment within your organization other than those that have been authorized and properly secured. Unauthorized or poorly secured access points create a huge risk to your organization’s security, and this should be called out in policy. Your policy should also prohibit employees from joining the wireless networks of other companies—for example, if your organization is on the fifth floor, and the organization on the sixth floor has a wireless network whose signals are causing interference. Any multihomed machine within your organization that is joined to another organization’s wireless network—either for fun or by accident—is essentially bridging the two networks and creating a major threat to both organizations.
Scan regularly. To help enforce your policy, you should regularly war drive your organization’s premises. Any unauthorized wireless equipment discovered should be disconnected from your organization’s networks immediately. Authorized wireless equipment should be reviewed and secured.
Educate users. As mentioned, WEP has several weaknesses and, although it is sufficient to thwart low-skilled attackers, it is ineffective against more skilled attackers. Inform employees that if they use wireless networks protected by WEP, they do so with the understanding that their data could be intercepted or modified en route.
Use encrypted protocols over wireless networks. If your company transmits sensitive or critical data over wireless networks, you should use protocols that support encryption. For instance, if employees transmit sensitive information to internal websites over a wireless network in your organization, they should do so over a Secure Socket Layer (SSL). This way, if an attacker is able to decrypt any of the WEP-encrypted packets on the wireless network, the data retrieved is still protected by SSL and therefore is essentially useless to the attacker.
Use the IEEE 802.1x standard. The IEEE 802.1x standard addresses many of the security weaknesses in WEP by providing secure authentication, dynamic key changes, and transport security. Your organization should consider moving to this standard if it hasn’t done so already. More information about the 802.1x standard can be found at http://standards.ieee.org/reading/ieee/std/lanman/restricted/802.1X-2001.pdf.
Use existing wireless security mechanisms. If migrating to a standard such as 802.1x is not feasible, your organization should continue to use a combination of existing wireless security mechanisms such as MAC address filtering, disabling SSID broadcasting, and WEP. A majority of attackers have no clue about what they are doing, and these simple roadblocks are sufficient to keep these attackers out of your organization’s wireless networks. As mentioned, some security is always better than no security. That said, you still need to make sure you understand weaknesses in each mechanism you choose to employ. For example, as you saw, disabling SSID has both performance and security drawbacks that should be considered when planning wireless networks. Doing so could also affect services such as the Windows Wireless Zero Configuration service. The key is to understand the weaknesses in each defense scheme and account for those weaknesses with other defenses.
Important
Be aware that several tools that automate exploiting wireless security weaknesses are available for public download—for example, Tim Newsham’s WEP cracker at http://lava.net/~newsham/wlan. Attackers pose an even greater threat to your wireless networks with these kinds of tools.
WiFi protected access. The WiFi protected access (WPA) standard was designed to address several shortcomings of WEP with respect to transport security and authentication. The WPA standard is an intermediate solution until the IEEE 802.11i standard, another standard designed to solve several WEP problems, is completed and is suitable for organizations that cannot wait. Information about WPA can be found at http://www.weca.net/OPenSection/protected_access.asp.
Traditionally, wireless devices such as cell phones, laptops, and personal digital assistants exchanged data with each other over mediums such as the infrared (IR) light spectrum or through device cradles. Exchanging data over these two mediums had several limitations that had an impact on the usability of devices. For instance, over IR, devices had to be in direct line of sight or very close to each other, devices could not simultaneously communicate with multiple devices, and communications could be affected by interference from other IR devices such as television remotes. Device cradles were cumbersome and often required different cables and software for different machines and operating systems. Also, users had to explicitly initiate communication between devices since automatic discovery was not supported.
Bluetooth, a wireless specification that uses short-range radio, was designed to address many of these issues. First, since Bluetooth operates over radio instead of a light spectrum like IR, devices are not required to be in line of sight of each other because obstacles can be navigated around. The Bluetooth standard also allows a single device to communicate simultaneously with multiple other devices. Being a wireless medium, Bluetooth does not require the use of cables as in the case of device cradles. One way that Bluetooth avoids interference with other devices is by limiting the reach of radio signals to approximately 10 meters, as shown in Figure 13-10. This reduces the chance of device signals crossing over and interfering with each other. Another way Bluetooth devices avoid interfering signals from other devices is by using a random frequency hopping algorithm. In frequency hopping, the frequencies used are changed many times a second, which effectively lowers the chance of interfering signals; if such a collision occurred, the disruption would be minimal and short-lived.
As you can see, the Bluetooth standard addresses several annoyances and limitations of traditional mediums, but in doing so has also introduced several new threats. Before looking at these threats, let’s first establish a good baseline by understanding how this technology works. For two devices to communicate over Bluetooth, they must first be "paired." This means that the two devices exchange passkeys (depending on the authentication level chosen) and create a trusted connection between each other. When two paired Bluetooth devices are within range of each other, a Personal Area Network (PAN), or piconet, is automatically set up between the devices. In this piconet, one device assumes the role of "master" while all other devices become "slave" devices. A scatternet is formed when one device from one piconet is also a part of another piconet, as shown in Figure 13-11.
More Info
For more information about the Bluetooth standard, visit the official Bluetooth website at http://www.bluetooth.com. If you are seeking more technical or development resources (hey, good for you!), visit http://www.bluetooth.org.
Unlike the topics of port scanning and password attacks, it’s difficult to say exactly which attacks to watch out for because the specific set of attacks varies from device to device and implementation to implementation. A Bluetooth-enabled cell phone will certainly have a different attack set than of a pair of Bluetooth-enabled chopsticks. However, the key to dealing with security for Bluetooth devices, as for any other wireless technology, is to realize that any time a signal is emanated—for example, between a Bluetooth keyboard and a transceiver—an attacker can potentially intercept, view, and modify the data in that signal (encrypted or not). Once you establish this baseline for your penetration tests, you’ll be better prepared to deal with the threats associated with any wireless technology. Now let’s look at the following threats to Bluetooth devices:
Device detection
Data theft
Services theft
Network sniffing
Important
Just because an attacker needs to be within 10 meters of a Bluetooth device to attack it directly, don’t be fooled into a false sense of security. Depending on the devices connected, it might be possible for attackers to attack other devices across scatternets. An attacker could even be in another room eavesdropping on your Bluetooth communiqués because the signals can penetrate walls. You just never know.
If the purpose of your penetration tests is exploratory, you (and attackers) can use tools such as Btscanner (http://www.pentest.co.uk) and Redfang (http://www.atstake.com/research/tools/info_gathering). These tools automate Bluetooth device discovery and interrogation. If you have programming experience, you can also create your own Bluetooth detection tool using toolkits such as the Microsoft Bluetooth Platform software development kit (SDK) at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bluetooth/bluetooth/about_bluetooth.asp.
The data on Bluetooth devices are very likely to be targets of attack—cell phones, for example, contain potentially sensitive contact data and other personal information. Implementation flaws of certain mobile phones were reported by AL Digital to allow attackers to steal data (dubbed bluesnarfing), such as contact information and personal notes.
More Info
You can find more information about Bluesnarfing at http://news.zdnet.co.uk/communications/wireless/0,39020348,39145881,00.htm.
To mitigate the problem of data theft against Bluetooth-enabled devices, it’s important to ensure that your device is up-to-date on firmware. Furthermore, devices should be set to use the high level of authentication implemented by your device manufacturer.
More Info
See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcebluet/html/ceconbluetoothreference.asp for a table of the three security modes defined by Bluetooth.
Finally, if Bluetooth functionality is not required, reduce the attack surface area and simply disable it.
Attackers might try to pair with your Bluetooth devices to steal services provided by those devices. Spammers can also use the technique called bluejacking to send unauthorized messages to nearby Bluetooth devices.
More Info
More about bluejacking can be found at http://news.zdnet.co.uk/communications/wireless/0,39020348,39117662,00.htm.
Ensure that your organization uses the highest level of authentication provided by your device’s Bluetooth implementation. Also, use long, difficult-to-guess passkeys when pairing devices. Changes to passkeys should also be done often and only over authenticated and encrypted sessions. Finally, avoid pairing in public places because attackers might be eavesdropping on information exchange during pairing handshakes.
In the same way that attackers can eavesdrop on data on Ethernet networks, unprotected data transmitted over the radio can be sniffed.
More Info
For more information about eavesdropping on data, see Chapter 19.