Thanks to the 802.11 standard and the ease with which a device can be wirelessly connected to a network, the technology market has exploded with all sorts of wireless gadgets. The ability to just turn on a device and have it connect to the rest of the world is a great selling point that has gotten the attention of both home and business consumers. No one likes having a bunch of wires hanging around, nor is it particularly easy to install networking wires and keep the office décor aesthetically pleasing. However, along with the benefits of keeping a wire-free office comes some serious and significant drawbacks. In this article, we are going to look at one such adopter and highlight several problems we found that not only can give an attacker a first-person view into your office/home, but also ensure your wireless camera fails to operate as expected.
For the purposes of this article, we are going to probe and exploit the AXIS 207W wireless camera. Typical users of this camera will install it within range of their wireless network and will use the camera as a security, kid-, or spouse-monitoring device. This $300 (USD) camera boasts the "Best Image Quality in Its Class" award at http://www.axis.com/products/cam_207/index.htm and has a lot of features and functions that a user can link into to create a full wireless monitoring solution.
If there is one Achilles heel of wireless technology, it is that wireless devices can be easily disrupted. This happens because of a protocol-level oversight that gives an attacker the ability to knock any wireless device off the network, or by a physical level attack that causes wireless devices to go into "mute" mode. Either way, the target wireless device is knocked offline with no one the wiser.
In addition to denial-of-service (DoS) attacks, wireless networks have long been subject to other issues that could be leveraged against a camera user to expose sensitive data, or mislead such user into believing something untrue. The following sections will examine all of these issues and clearly demonstrate how easy it is to abuse wireless cameras.
Wireless Protocol Attacks
The 802.11 protocol uses three different types of packets to keep traffic flowing: data, management, and control packets. Data packets contain the information that passes to and from the wireless clients and the networks beyond the access point, such as HTTP traffic, emails, and so on. If encryption is enabled on the network, these packets are encrypted to prevent eavesdropping. Unfortunately, the management and control packets that are used to keep the network up and running are not encrypted or protected in any way. As a result, these packets can easily be spoofed by an attacker—even if the network is encrypted.
Numerous programs can do this, one of which is MDK2 from the BackTrack2 Live CD. The reason we highlight this particular program is that anyone with a laptop and wireless network card can have the perfect wireless camera DoS tool set up and running within minutes. Assuming you have BackTrack2 loaded and are at a shell with an Atheros card installed, the following commands are all that's needed to take out any wireless camera nearby:
# airmon-ng stop ath0 # airmon-ng start wifi0 6 # cd /pentest/wireless/mdk2* # ./mdk2 ath0 d
Figure 1 shows this program in action.
Figure 1 MDK2 taking out a wireless camera.
You'll note there are several supposed live MAC addresses, but in reality these are just broadcasted packets from the network. Our target was the MAC address of 00:40:8C:7A:0C:D8, which did go offline during the attack.
This type of attack can be detected by a wireless intrusion prevention system and seen in a sniffer capture. However, chances are the owner would not know what to do or how to fix the problem because these tools/skills are beyond the knowledge of the average user.
Physical Layer Attack
The second type of attack is much harder to perform, but only because the software/hardware requirements are a bit more restrictive. That said, this attack is also a lot more disruptive and is nearly impossible to detect.
When a wireless device wants to communicate, it must first perform a clear channel assessment to ensure the airwaves are not currently in use. This is done to avoid interference and disruption that can occur if two devices are emitting radio energy at the same time. While this is a necessary part of wireless communications, it also leaves every wireless device subject to a DoS attack.
Basically, if an attacker can tell his own device to constantly emit "traffic," any other device within range will never get a chance to "talk." The target devices will check to see if the channel is clear, hear the attacker's traffic, wait a bit, check again, then wait some more, and so on. Fortunately, the widespread availability of the tools needed for such an attack are not as easy to come by as BackTrack2.
However, this doesn't mean it is impossible—it just means you have to do some research or spend a few dollars on some specific gear. For example, our laptop is loaded. with the necessary software needed to perform this attack. But we also have a Windows Mobile device with a driver that includes what it calls the Continuous Preamble mode (see Figure 2). With such a device in his back pocket, it would be easy for an attacker to walk into a building and shut down any nearby cameras.
Figure 2 Continuous Preamble.
To illustrate how this attack impacts nearby wireless networks, Figure 3 shows the Wi-Spy RF analyzer with the Continuous Preamble mode enabled. The very big bulge in the middle reflects the energy being emitted by the PDA. This is not normal, and immediately causes any and all communication between the camera and the rest of the network to cease.
Figure 3 Wi-Spy illustrating impact of clear channel assessment attack.
As the previous illustrations demonstrate, it is fairly simple to knock a wireless camera offline. Unfortunately, there are no protections for these types of attacks, which is why using a wireless camera for anything important is not a good idea. The same principle applies to any critical networked device such as in a hospital, government building, and military use.
Most IP-based cameras have some kind of password-protected, web-based interface through which a person can keep an eye on what is happening. While some cameras are set up in an open area to provide a public service for viewers (for example, to check out traffic or weather conditions), these types of cameras are typically connected to a SOHO/corporate network and used for surveillance.
In such environments, the security officers generally do not want the public to see what images are being passed over the network. Having a bird's eye view of who is doing what in a business can be leverage for all sorts of nefarious deeds. For example, cameras can and have been used to capture credit card data, spy on workers, read data from screens, monitor passwords as they are typed, and much more.
Unfortunately, if an IP camera is passing packets as plaintext over a network that data can often be sniffed. This threat is further enhanced if that IP camera is passing the images over an unencrypted wireless network. Because most of these cameras pass images in an MJPG format, it is trivial to capture and view the contents.
To illustrate, we have set up out wireless camera with an unencrypted network, and have Backtrack2 up and running. We next opened up a shell and typed the following into the command line: driftnet –i ath0. This opened up a window, into which immediately loaded the image being passed over the wireless network. Because we sized the windows to the exact width/height of the captured images, driftnet gave us a "streaming" video feed of our targeted wireless camera (Figure 4). While this does require you to be authentication/associated to the wireless network, you do not need an IP address to use driftnet. In addition, it is entirely possible to do completely passive sniffing and recreate the images on your own.
Figure 4 Driftnet capturing live video feed.
One other issue related to using a wireless camera on an open wireless network is that the logon data is at risk of being exposed. In the case of the AXIS camera, the user/pass is sent as Base64-encoded data with each page request. If an attacker was nearby with a sniffer, he could very easily capture a request and decode that user/pass and then use that to gain access to the camera's web interface. As you will see in the second part to this series on Axis cameras, having system access to a network-attached device can become a significant security threat.