This chapter gives a brief introduction to some of the security challenges implicit in wireless networks. The IEEE’s certification for “wireless Ethernets” is classified and controlled by the 802.11 standard. 802.11 is further broken down into more specific certifications, such as 802.11a, 802.11b, and 802.11g. Each defines a different method for providing wireless Ethernet access. Each protocol specifies various aspects of data transfer that distinguishes it from the other certifications.
Despite gains by 802.11g, 802.11b is currently the most prevalent standard for wireless LANs worldwide, and support for it is found in almost every wireless device. An 802.11b device operates by sending a wireless signal using direct sequence spread spectrum (DSSS) in the 2.4-GHz range.
This chapter assumes that you have at least a passing familiarity with wireless security threats (e.g., wardriving), that you have set up at least one simple 802.11 network, and that you understand the basics of WEP and computer viruses. We will therefore focus primarily on 802.11b security, how to crack it, and what defenses are theoretically possible. We also introduce the growing threat posed by wireless airborne viruses, and some possible countermeasures.
Before we get into cracking Wired Equivalent Privacy (WEP) and discuss possible countermeasures, let us pause to consider how the humble antenna can help control radio frequency signal drift. Antennas can be used for both good and evil. On the one hand, you can control the signal drift of your wireless LAN (WLAN) by manipulating antennas. On the other hand, directional antennas make it easier for wardrivers to probe your networks from a distance.
For example, a wardriver can use a mobile 2.4-GHz antenna from her car parked down the street to boost the signal bleeding from your house. To counter this to some extent, you can position your access point (AP) antennas to point away from the street. You can also move the access point to the center of your house to reduce signal bleed. You can even reduce (or turn off) the signal on one or both of your AP antennas using the software that ships with most quality access points.
On the enterprise side, you can also use directional antennas to focus your signal. For example, we recently set up a long-distance building-to-building link. To do this we used a 24-dB parabolic antenna on the transmitting side (Figure 17-1). The goal was to achieve a strong link over a long distance, while avoiding excessive signal scatter.
Figure 17-1. Our parabolic antenna shown in horizontal polarization; in suburban terrain, mounting in vertical polarization produces less signal scatter than horizontal polarization
We bought this high-powered antenna on eBay for less than $50. As you can see, this particular antenna is quite large. Thus, you must have adequate room for mounting (you need to do a rooftop mount, rather than a wall side-mount). Otherwise, you should select a more slender Yagi antenna. You can also build your own directional antenna out of a Pringles ™ can.
The 24-dB antenna in Figure 17-1 has a very tight beam width of only eight degrees. This helps prevent signal bleed along the transmit path. However, be careful, as you can still get some signal bleed behind the antenna, to the sides, and especially past your target (overshoot). By using antenna positioning, directional antennas, and power output tweaks, you can help prevent excessive signal bleed. This provides a modicum of additional security, but of course is only a small part of your total security solution. We discuss other ways to protect your transmissions later in the chapter.
Wireless transmissions are inherently unsafe, as they allow wireless hackers (wardrivers) to access your data from a nearby parking lot. As most readers also know, the IEEE 802.11 standard includes basic protection, known as the Wired Equivalent Privacy (WEP) protocol. This protocol defines a set of instructions and rules by which wireless data can be transmitted over airwaves with added security.
The WEP protocol standardizes the production of hardware and software that use the IEEE 802.11 protocol. To secure data, WEP uses the RC4 algorithm to encrypt the packets of information as they are sent out from the access point or wireless network card. RC4 is a secure algorithm and should remain so for several years to come. However, in the case of WEP, it is the specific wireless implementation of the RC4 algorithm, not the algorithm itself, that is at fault.
The following section will show in detail how WEP is cracked. On a busy corporate network, a wardriver can capture enough data to break your WEP encryption in about two to six hours. Breaking a home user’s encryption might take longer (up to two to four weeks), since the flux of data is often much lower. Nevertheless, we recommend that you use WEP when possible, not just as a minor security barrier, but also because it serves as a gentle warning (akin to a login banner disclaimer on a network) that your network is private, rather than shared with the entire community. Also, some products (such as Windows XP) automatically associate with the strongest wireless signal by default. Using WEP prevents your neighbors from inadvertently sucking up your bandwidth, or from unknowingly browsing the Web using your home IP address!
The WEP protocol defines methods through which wireless data should be secured. Unfortunately, it can easily be cracked, as we will demonstrate. Although proposed standards (such as Wi-Fi Protected Access, or WPA) purport to ameliorate the known weaknesses in WEP, the reality is that WPA has backward compatibility issues with most 802.11b hardware. Thus, WEP continues to be the most prevalent (albeit flawed) primary encryption scheme for WLANs.
WEP uses the RC4 algorithm to encrypt its data. RC4 is one of the most popular methods of encryption and is used in various applications, including Secure Sockets Layer (SSL), which is integrated into most e-commerce stores. RC4 uses a streaming cipher that creates a unique key (called a packet key ) for each and every packet of encrypted data. It does this by combining various characteristics of a pre-shared password, a state value, and a value known as an initialization vector (IV) to scramble the data. This part of RC4 is known as the key scheduling algorithm (KSA). The resultant array is then used to seed a pseudorandom generation algorithm (PRGA), which produces a stream of data that is XORed with the message (plain text) to produce the cipher text sent over the airwaves.
The transmitted data consists of more than just the original message; it also contains a value known as the checksum . The checksum is a unique value computed from the data in the packet, used to ensure data integrity during transmission. When the packet is received and decrypted, the terminal checksum is recalculated and compared to the original checksum. If they match, the packet is accepted; if not, the packet is discarded. This scheme not only protects against normal corruption but also alerts the user to malicious tampering.
Once the data is encrypted, the IV is prepended to the data along with a bit of data that marks the packet as being encrypted. The entire bundle is then broadcast into the atmosphere, where it is caught and decrypted by the receiving party.
The decryption process is the reverse of the encryption process. First, the IV is removed from the data packet and is then merged with the shared password. This value is used to recreate the KSA, which is subsequently used to recreate the keystream. The stream and encrypted data packet are then XORed together, resulting in the plain-text output. Finally, the CRC is removed from the plain text and compared against a recalculated CRC; the packet is then either accepted or rejected.
Most experts consider RC4 to be a strong algorithm. However, due to various errors in the implementation of the IV, it is trivial to crack WEP. The following sections explain in detail how and why it is possible to crack WEP.
When data is transferred via the airwaves, it can easily be captured using programs downloaded from the Internet. This type of monitoring was anticipated, and it is the reason WEP security was added to the 802.11 standard. Through WEP, all data can be scrambled to the point where it becomes unreadable. While WEP does not prevent the wanton interception of data, it protects the captured data from casual interpretation.
However, there are faults in implementation of RC4. If a hacker can determine what data is being sent before it is encrypted, the captured cipher text and known plain text can be XORed together to produce the keystream as generated by the PRGA. The reason for this flaw is that WEP produces the cipher text by merging only two variables together using XOR. Equation 1 depicts the final function of the RC4 algorithm, which encrypts the data:
| Cipher text = Plain text XOR Keystream |
As you can see, the only value masking the plain text is the keystream. If we reverse this process, we see that the only value masking the keystream is the plain text, as depicted by Equation 2.
| Keystream = Cipher text XOR Plain text |
It is a simple matter to extract a keystream from encrypted data, as long as we have both the cipher text and the original plain text. The cipher text is simple to capture; all that is needed is a wireless sniffer, and we can gather gigabytes worth of encrypted data from any wireless network.
The quality of a sniffer is directly related to the information it can provide for its user. For example, many hackers consider dsniff to be one of the best sniffers available—not because dsniff captures any better than Ethereal, which is at the top of the list for many professionals, but because dsniff incorporates extra features, such as a built-in password sniffer, ARP spoofing technology, and more. These small additions make the program more streamlined, if collecting passwords is your goal. On the other hand, some troubleshooting requires the use of an expensive, all-in-one hardware/software sniffer package. These devices, which would be overkill for a small network, can collect gigabytes of data and never miss a packet.
In addition to landline sniffers, the introduction of wireless networks has caused the creation of a new niche of sniffers. Due to the unique physical and technical properties of WLANs, the quality and functionality of a wireless sniffer is tied to how well it can be integrated into an existing wireless network. Some sniffers only capture packets from WLANs to which they are associated, while others can capture data on all operating networks in physical proximity to them. For an 802.11b network, up to 14 different channels are used to transmit data. As a result, it is possible to have up to four different and totally separate WLANs in the same general area (several channels are used per network). To collect data from all local wireless networks, the wireless device on which the sniffer is operating has to operate in a passive mode. While this allows it to capture all data, the device will not be able to connect to any existing wireless network. In other words, it will be continuously jumping channels, which is similar to jumping networks several times a second. Due to the nature of networking, this process wreaks havoc on any communication sessions you attempt to capture. To make it even more complicated, sniffing a wireless network in passive mode requires special drivers, or at the minimum a patch to existing drivers.
When a network card is manufactured, it is assigned a unique identifier known as a Media Access Control (MAC) address. Since this address is supposed to be unique, it serves as one of the fundamental methods by which data is transmitted over a network. While there are many other communication protocols that sit on top of the MAC address to help with data flow, the MAC address is used in the first and last legs of the transmission process. It is important to understand the significance of the MAC address, because it indirectly affects the data a sniffer can access.
When a network card is operating normally, it actually scans each packet of data traveling over the network to see if any of the data is labeled with its MAC address. If there is a match, the data is passed up to the next layer in the protocol stack, and ultimately to the program to which it was sent. If the packet is not addressed to the NIC, for practical purposes it will be ignored.
Since the sniffer software actually operates above the hardware layer of the communication stack, it only receives data sent to the computer on which it is operating. In other words, the sniffer only sees local data. While this level of access can be helpful in some situations, the limited access restricts most troubleshooting efforts. This is where promiscuous mode comes into play.
When a network card is placed in promiscuous mode, it accepts all data passed on the wire to which it is connected, regardless of the MAC address. However, there are still some obstacles a sniffer must overcome to gain access to network traffic, including additional support for wireless data, which uses radio waves to pass data, and limitations due to networking technology.
There are many examples of wireless sniffers; an excellent example is Kismet (available from http://www.kismetwireless.net). However, if you are doing a walk-around site audit for a large campus, it may be more convenient to use a “pocket sniffer.” An example is the Airscanner Mobile Sniffer (shown in Figure 17-2), which runs on Windows Mobile/PocketPC.
It can be downloaded from http://www.airscanner.com and is free for personal use. It will enable you to do all of the following:
Sniff wireless packets in promiscuous mode.
Decode UDP, TCP, Ethernet, DNS, and NetBIOS packets .
Conduct network analysis on an entire WLAN segment.
Customize filters for source and/or destination IP address, UDP port, TCP port, or MAC address.
View real-time packet statistics .
Save results of capture sessions.
Export data to libcap format (e.g., Ethereal) for further analysis on a desktop PC.
With Airscanner Mobile Sniffer, you can export the packet capture from your pocket PC to a desktop for further analysis with Ethereal. Ethereal (discussed in Chapter 6) is one of the most popular desktop sniffers available. It performs packet sniffing on almost any platform.
Now that we have obtained a wireless sniffer for capturing encrypted data from a WLAN, we can extract a keystream as long as we have both the cipher text and the original plain text. How do we know the original data value? The usual way an attacker can predetermine plain text is to trick someone into receiving or sending a predictable message. For instance, a chat session or email could provide an attacker all the plain text she needs. However, this method can be difficult if extraneous data becomes intermingled with the predictable data. For example, TCP/IP packets include IP headers and other distracting information. Checksums, proprietary data additions by the email server, and more can obscure the predictable data. Therefore, if an attacker is going to succeed with this method, she needs to send a message that increases the chances of obtaining predictable data. This could be easily accomplished using an email full of blank spaces (e.g., " “) or a long string of the same character (e.g., “AAAAAAAAAAAAAAAAAAAAAAAA”).
Another method used to predetermine plain text is to look for known communication headers. TCP/IP packets include IP headers that are required to ensure proper delivery. If we can determine the IP address of the access point or client WNIC and make an educated guess about the rest of the data based on user habits, we can deduce the plain text. In fact, because of the way 802.11 is set up, almost every packet that is sent includes a SNAP header as its first byte. This simple fact is one of the major weaknesses through which WEP can be cracked, as you will learn later.
Assuming an attacker can determine the plain text of a message and use this to glean the keystream, what can she do with this information? The answer to this will become apparent as you read on. Also note that one or even a couple of keystreams by themselves are basically worthless. It is when you combine the knowledge gained in this type of wireless attack with other wireless hacking techniques that the power of knowing a keystream becomes manifest.
WEP uses a value known as an initialization vector , commonly called the IV. The RC4 algorithm uses this value to encrypt each packet with its own key by merging or concatenating the pre-shared password with the IV to create a new and exclusive packet key for each and every packet of information sent over the WLAN. However, if the sending party uses an IV to encrypt the packet, receiving parties must also know this bit of information if they are going to decrypt the data. Because of the way WEP was implemented, this requirement turned an apparent strength into a weakness.
WEP uses a three-byte IV for each packet of data transmitted over the WLAN. When the data is sent, the IV is prepended to the encrypted packet. This step ensures the receiving party has all the information it needs to decrypt the data. However, if we take a closer look at the statistical nature of this process, we quickly see a potential problem. A byte is eight bits. Therefore, the total size of the IV is 24 bits (8 bits x 3 bytes). If we calculated all the possible IVs, we would have a list of 224 possible keys. This number is derived from the fact that a bit can either be a 0 or a 1 (2), and there are a total number of 24 bits (24). While this may sound like a huge number (16,777,216), it is actually relatively small when associated with communication. The reason is found in the probability of repeats.
The IV is a random number. When most people tie the word random to a number like 16,777,216, their first assumption is that an attacker would have to wait for 16 million packets to be transferred before a repeat. This is false. In fact, based on probability, you could reasonably expect to start seeing repeats (also known as collisions) after just 5,000 packet transmissions or less. Considering the average wireless device transmits a 1,500-byte packet, a collision could be expected with the transfer of just a 7-10 MB file ( 5,000 packets x 1,500 bytes = 7,000,000 bytes or 7 MB).
The keystream is produced from various properties of the password and the IV. In the case of a collision, the IV is known as a three-character value of “1:2:3”. While we do not know the password, it is irrelevant, because it never changes. We can now deduce the keystreams generated by matching IV values.
This weakness is not so much the fault of WEP itself as of a small IV size. If the IV were several times longer, the time between repeated IVs would be larger, creating a more difficult scenario for any attacker attempting to send predictable data through a network. Considering a packet is generally 1,500 bytes long and the IV is only 3 bytes long, there would have been room for growth. However, in the name of speed and a maximized data flow, the protocol designers reduced the IV size.
Now that we have reviewed the theory, let’s examine the practical steps for cracking WEP. The most important resource for cracking a WEP-encrypted signal is time. The longer you capture data, the more likely you are to receive a collision that will leak a key byte. Based on empirical data, there is only about a five percent chance of this happening. On average, you need to receive about five million frames to be able to crack a WEP-encrypted signal. In addition to a wireless sniffer, you’ll need a series of Perl scripts available from http://sourceforge.net/projects/wepcrack/, called (appropriately) WEPCRACK.
Once you have acquired the necessary tools, perform the following steps for cracking a WEP-encrypted signal:
Capture the WEP-encrypted signal using your wireless sniffer (about five milion frames).
From a command prompt, execute the prism-getIV.pl script with the following syntax:
prism-getIV.pl capturefile_namewhere capturefile_name is the name of your capture file from step 1. When a weak IV is found, the program creates a file named IVfile.log.
Run WEPcrack.pl, which looks at the IVs IVfile.log and attempts to guess at a WEP key. The output of WEPcrack.pl is in decimal format. You will need a decimal-to-Hex conversion chart.
Take the Hex version of the key and enter it into your Client Manager, and you’re done!
As WEP is hopelessly flawed, we recommend implementing Virtual Private Networking (VPN) for your WLANs. A VPN is a virtual, encrypted network built on top of an existing network. This process is also known as tunneling, because the encrypted data stream is set up and maintained within a normal, unencrypted connection. A VPN extends the safe internal network to the remote user. Therefore, the remote wireless user exists in both networks at the same time. The wireless network remains available, but a VPN tunnel is created to connect the remote client to the internal network, making all the resources of the internal network available to the user.
As we’ve discussed, the encryption used by most implementations of WEP is flawed. However, if a system employs VPN encryption in addition to WEP encryption, an attacker is forced to decipher the data twice. The first layer is the crackable WEP encryption and the second layer is the robust VPN encryption. Since attackers cannot easily reproduce the VPN’s passphrase, certificate, or smartcard key, their success rate at cracking the VPN traffic will be very low.
While using both a VPN and WEP is definitely an advantage, there is a major downside. The problem arises due to the additional processing that encrypting and deciphering data requires. Using WEP with VPN on a properly configured firewall/access point can affect transmission speed and throughput by as much as 80%. This impact can have serious consequences on network connectivity and may all but eliminate the end user’s enthusiasm for the wireless connection.
In addition, using VPN over wireless requires that client software be installed on every user’s device. This requirement creates a few issues for end users. For example, most embedded VPN software is written for the Windows platform. Macs, Unix-based computers, and palm-top computers may not be able to connect to the WLAN. While this problem may not be an issue for most home users and small businesses, it could be seriously detrimental for a large or rapidly growing corporation.
The remote authentication dial-in user service (RADIUS) is a protocol responsible for authenticating remote connections made to a system, providing authorization to network resources, and logging for accountability purposes. While the protocol was actually developed years ago to help remote modem users securely connect to and authenticate with corporate networks, it has now evolved to the point where it can also be used in VPNs and WLANs to control almost every aspect of a user’s connection.
There are several brands of RADIUS servers available. One of the more popular is Funk’s Steel Belted RADIUS server, which is often deployed with Lucent WLAN setups. Cisco has one, Microsoft has another, and there is even one called FreeRADIUS which is for Unix users. Regardless, they all work relatively the same way.
The Temporal Key Integrity Protocol (TKIP) is a more recent security feature offered by various vendors to correct WEP’s weaknesses. TKIP was developed by some of the same researchers who found the vulnerabilities in the RC4 implementation.
TKIP still uses RC4 as the encryption algorithm, but it removes the weak key problem and forces a new key to be generated every 10,000 packets or 10 KB, depending on the source. In addition, it hashes the initialization vector values, which are sent as plain text in the current release of WEP. This means the IVs are now encrypted and are not as easy to sniff out of the air. Since the first three characters of the secret key are based on the three-character IV, the hashing of this value is a must. Without protecting the IV from casual sniffing attacks, a hacker can turn a 64-bit key (based on 8 characters x 8 bytes in a bit) into a 40-bit key (based on 8-3 characters x 8 bytes in a bit).
Even with this extra security, TKIP is designed like the current version of WEP. The similarity allows TKIP to be backward compatible with most hardware devices. Consumers merely have to update their firmware or software in order to bring their WLANs up to par.
While this new security measure is important, it is only temporary; TKIP is like a Band-aid to patch the hemorrhaging WEP security. TKIP still operates under the condition that an attacker only has to crack one password in order to gain access to the WLAN—one of the major factors that caused the current release of WEP to be crackable. If WEP included a multifaceted security scheme using stronger encryption and/or multiple means of authentication, an attacker would have to attack the WLAN from several points, thus making WEP cracking much more difficult.
The Secure Sockets Layer (SSL) is a protocol that has been in use for years online. The most popular form uses RC4 to encrypt data before it is sent over the Internet, providing a layer of security to any sensitive data. It also uses public key encryption to securely distribute the secret keys that it then uses for the RC4 algorithm. SSL has been incorporated into almost all facets of online communication. Web stores, online banks, web-based email sites, and more use SSL to keep data secure. The reason SSL is so important is because without encryption, anyone with access to the data pipeline can sniff and read the transmitted information as plain text.
Authentication is one of the most important and necessary aspects of building a secure WLAN. While there is some protection in the pre-shared password used to set up WEP, the password only encrypts the data. The flaw in this system is that it assumes the user is allowed to send data if the correct pre-shared password is used. And if you only use WEP (in conjunction with a DHCP WLAN), there is no way to track and monitor wireless users for security reasons. Authentication of some kind is required.
Although authentication is important and necessary, it too is potentially vulnerable to several types of attacks. For example, user authentication assumes that the person sending the password is indeed the owner of the account, which may not be the case. Another weakness of an online authentication system is that user information must be sent from the client to the host system. Therefore, the authentication information can be sniffed, which makes SSL even more important to the authentication of users.
Since WLANs operate in a world that is meant to be user-friendly and cross-platform, using proprietary software to encrypt and authenticate users would be tedious and present simply another obstacle for the user. Instead of designing an authentication system this way, many vendors are using a system that has been tried and tested for years: by using a web browser with SSL enabled, an end user can make a secure and encrypted connection to a WLAN authentication server without having to deal with cumbersome software. Since most wireless users are familiar with using secure web sites, the integration of SSL goes unnoticed. Once the connection is made, the user account information can be passed securely and safely.
Let us turn now to another rapidly growing wireless security threat—wireless computer viruses. With the explosive growth of WLANs, cellular phone manufacturers and carriers have piggybacked on Wi-Fi in order to resuscitate their hopes for universal, high-speed wireless connectivity. Along with this growth in coverage and bandwidth has come an increase in the number and sophistication of mobile devices. There are currently hundreds of millions of PDAs and smart phones available worldwide, and the number is growing rapidly. With this phenomenal growth of “embedded” mobile devices, the threat of wireless viruses is likewise growing. Many of these handheld devices are potentially susceptible to some form of virus or hostile code that could render them nonfunctional. This section introduces various threats posed by airborne (wireless) viruses and hostile code.
Because of their susceptibility to viruses, handheld devices are potentially dangerous to a corporate network. Small business and home users also require protection from wireless viruses.
Malicious virus writers have a passion for owning new technology. New platforms such as Palm and Windows CE are highly attractive targets to virus and Trojan writers. Being the first to infect a new platform provides the virus writer with instant notoriety. As technology in the handheld device and wireless networking industries advances, virus writers have plenty of room for growth. In addition, the number of targets is growing at an exponential rate. In fact, the first viruses to target wireless devices and handhelds have already emerged.
For example, the Phage virus was the first to attack the Palm OS handheld platform. This virus infects all third-party application programs. Then the infected executable files corrupt other third-party applications in the host Palm handheld device.
Palm OS Phage spreads to other machines during synchronization. When the Palm device synchronizes in its cradle with a PC or via an infrared link to another Palm device, the virus transmits itself along with infected files.
The early handheld viruses spread slowly, since most PDAs were not wireless-enabled. However, with the growing prevalence of handheld wireless functionality, the threat grows as well. In fact, the modern Windows Mobile device has most of the ingredients for viral spread, such as a processor, RAM, writable memory, Pocket Microsoft Word, and even a Pocket Outlook mail client. Worse, unlike their desktop counterparts, security measures such as firewalls and virus scanners for handhelds are not widely used. Combine all this with an unsecured wireless link, and the potential for viral spread multiplies. The future may be even worse. With distributed programming platforms such as .NET, combined with Microsoft’s Windows Mobile platforms, such as Pocket PC and Smartphone, the potential for viruses is even greater. Imagine a virus catching a ride on your “smart” watch (Windows CE) until it gets close enough to infect your corporate networks as you unwittingly drive by unsecured access points.
An example of a wireless virus is the Visual Basic Script-based Timofonica Trojan horse virus that hit a wireless network in Madrid, Spain. Like the “I Love You” email virus, Timofonica appends itself to messages you send and spreads through your mail client’s contact list. In Timofonica, the Trojan horse sends an SMS (Short Messaging Service) message with each email across the GSM phone network to randomly generated addresses at a particular Internet host server. This can create annoying SMS spamming, or even a denial-of-service condition.
A similar denial-of-service attack occurred in Japan when a virus that sent a particular message to users on the network attacked the NTT DoCoMo “i-mode” system. The 911 virus flooded Tokyo’s emergency response phone system using an SMS message. The message, which hit over 100,000 mobile phones, invited recipients to visit a web page. Unfortunately, when the users attempted to visit the page, they activated a script that caused their phones to call 110 (Tokyo’s equivalent of the 911 emergency number in the United States). The virus overloaded the emergency response service and may have indirectly resulted in deaths.
From lessons in biology, we know that viruses infect every other organism, without exception, including even the tiniest bacteria. Thus, biologists and antivirus experts were not surprised to hear of the first malware infections of mobile devices. The first PDA virus appeared on the Palm platform in 2000.
The Palm OS has a different architecture from desktop computers, so it’s less susceptible to immediate infections from existing desktop viruses. In addition, safeguards are built into the OS to help protect data at various points. Nevertheless, Palm eventually succumbed to its first virus. Experts predict future infections will be far worse.
The Palm has several potential methods of infection. For example, when the handheld is synchronized with its desktop counterpart, there is a transmission of data. Fortunately, most desktop viruses, even if rampant on the office machine, will not infect the PDA itself. In addition, this type of virus is usually picked up by desktop antivirus (AV) software. If a Palm does become infected, it can pass the infection back to other desktops: when the Palm carrying the infected file synchronizes with another remote desktop, it can pass the infection, much like the slow floppy disk infections of old (although transmission is much more difficult than with floppies).
Theoretically, there’s also a potential for infection from new attacks that use existing desktop viruses as a vector. If a virus writer could “wrap” a Palm-specific virus in a desktop virus, the desktop AV software might not detect it. A user could unwittingly download the “clean” file from the desktop; when executed, the file would unwrap and release the Palm-specific virus. In addition, the Palm can potentially pass malicious code by infrared beaming. However, this feature requires the user to manually accept the infrared connection; there is no default promiscuous mode for Palm infrared reception. Beaming requires close physical proximity, usually four feet or less.
The greatest threat to handhelds, however, comes from wireless connections. In this case, the broadcast virus would totally bypass AV software on the desktop computer. The only way to protect against airborne viruses is at the wireless server or on the PDA itself. AV solutions for both the handset and the central server have been developed, but the technology is still in its infancy.
As mentioned earlier, Phage was the first Palm virus; it was discovered in September 2000. When the virus is executed, infected PDA files display a grey box that covers the screen, whereupon the application terminates. The virus infects all other applications on the Palm. When a “carrier” Palm is synchronized with a clean Palm, the clean Palm receives the Phage virus in any infected file. The virus then copies itself to all other applications on the clean Palm. The Phage virus can be removed by deleting any file that is infected. In addition, you must delete any occurrence of the file phage.prc from your backup folder. You can then reboot your Palm and resynchronize with the desktop.
Similarly, the Liberty Crack Trojan acts as a Trojan by coming in a disguise (although it does not open a backdoor). Liberty is a program that allows you to run Nintendo GameBoy games on the Palm OS. Liberty is shareware, but like all useful shareware it has a crack that converts it to the full registered version. The authors of Liberty decided to pay back the pirates by releasing a “crack” for Liberty that was actually a virus. The authors distributed it on IRC. Unfortunately for the pirate, when executed the Liberty Crack Trojan deletes all applications from the PDA. The Liberty virus spreads through desktops and wireless email. In fact, it may be the first known PDA virus to spread wirelessly in the real world.
Another virus, known as Vapor , does just what it sounds like it should; when infected with Vapor, all the files on the PDA “disappear.” When the infected file is executed, all application icons vanish as if deleted. It’s a trick; the files still exist. In reality, the virus simply removes the icons from the display. It’s similar to setting all files as Hidden on a desktop system.
Older handsets were relatively immune from airborne viruses because they lacked functionality. However, Internet-enabled smart phones are facile hosts for infection, as the Tokyo 911 virus, which attacked with an SMS message, illustrates. A potential vulnerability of SMS is that it allows a handset to receive or submit a short message at any time, independent of whether a voice or data call is in progress. If the handset is unavailable, the message is stored on the central server. The server retries the handset until it can deliver the message. In fact, there are desktop tools that script-kiddies use for SMS bombing. The principle of this tool, when coupled with the power of a replicating virus, could potentially result in wide-scale denial-of-service attacks.
Another example of such an SMS-flooding virus occurred in Scandinavia. When a user received the short message, the virus locked out the handset buttons. This effectively became a denial-of-service attack against the entire system.
Similarly, a Norway-based WAP service developer known as Web2WAP found another example of malicious code while testing its software on Nokia phones. During the testing, they found that a certain SMS was freezing phones that received it. The code knocked out the keypad for up to a minute after the SMS was received. This incident is similar to format attacks that cause crashes or denial-of-service attacks against Internet servers.
Starting in the summer of 2003, all Dell handheld devices began shipping with an embedded version of McAfee Antivirus. Although it was unclear which Windows CE viruses Dell and McAfee were trying to protect against (since none existed at that time), other companies scrambled to compete. For example, soon after McAfee became standard on all Dell PDAs, Symantec released a beta version of their antivirus tool for Windows Mobile/Pocket PC. There are currently several virus scanners for Windows CE.
Rather than simply installing a commercial CE virus scanner, however, we recommend that you get under the hood and start dissecting embedded binaries yourself. In Chapter 4 we explained the steps for reverse engineering Windows CE applications. In addition, you can download special tools for debugging viruses and Trojans on Windows CE. For example, Airscanner Mobile AntiVirus Pro (shown in Figure 17-3) is free for personal use and has an array of advanced features for dissecting malware on your mobile device. It is available for you to download from http://www.airscanner.com.
Maximum Wireless Security, by Cyrus Peikari and Seth Fogie. SAMS, December 2002.
Wireless LANs, by Jim Geier. SAMS, July 2001.
Airscanner Mobile AntiVirus User’s Manual, by Cyrus Peikari. (http://www.airscanner.com)
Airscanner Mobile Sniffer User’s Manual, by Seth Fogie and Cyrus Peikari. (http://www.airscanner.com)
“The New Virus War Zone: Your PDA.” ZDNet News, August 2000.
“PDA Virus: More on the Way.” ZDNet News, September 2000.
“PDA Virus Protection Released.” Infoworld.com, August 2000.
“Handhelds: Here Come the Bugs?” CNET News.com, March 2001.
“Wireless Viruses Pose a New Threat.” Computer Times, October 2001
“Wireless Phone Hack Attack?” Wired News, August 2000.