We were notified that there was an existing presentation from DEF CON 24 that talked about the same topic by Zack Fasel and Erin Jacobs titled "I Fight for the Users, Episode I - Attacks Against Top Consumer Products" (https://www.youtube.com/watch?v=XkJ2tH21Wf8). We sincerely apologize for not providing credit and want to assure our readers that this was not an intentional or malicious act on our part to copy any existing content. This was an issue we came across on a recent engagement and thought that it would be a good topic to discuss to help users understand the risks with these devices.
Many companies have come out with 2.4/5GHz wireless cameras which operate over 802.11 wireless protocols and frequencies. These cameras are very convenient, in that only power needs to be provided for placement, which allows home and business users to place cameras without complicated network wiring.
Adding cameras to home and office areas is an excellent way to discourage crime and to provide evidence if a crime is committed. While wireless cameras are undoubtedly the easiest to set up, they also have a serious drawback which affects all wireless devices.
The current 802.11 wireless standards allow for anyone to send a deauthentication frame for a client to a wireless access point, which causes the client to have to re-authenticate. An attacker can send a flood of these deauthentication frames to the wireless access point and jam the client’s access for as long as the attacker needs. Encryption is not required for the deauthentication frame so this attack works even if the wireless access point is using encryption (e.g. WEP, WPA, WPA2). Normally, this blocks a single user from a network and is very noticeable since the user would lose network access. However, with a wireless camera, which is likely not constantly monitored, an attacker could disrupt the camera’s network connectivity, physically access the monitored area, and leave without being visible on camera. Reviewing the camera clips during a deauthentication attack will show that no motion was detected and is likely to look more like an inside job with someone disabling the camera and then re-enabling it.
Attack Example
To show how easy this attack is to conduct, let’s look at conducting the attack against a Nest Indoor camera. Note that this attack will work against any wireless camera such as Arlo, Amcrest, etc. The Nest is only being used as an example due to its popularity.
Our example Nest device has a MAC address that is 18:B4:30:5A:DB:21.
Figure 1 - Nest Information Shown In Router
On the attacker machine running Kali Linux, I’ve added a USB Alfa wireless card, which Linux added as wlan0.
To successfully de-authenticate a wireless camera, three pieces of information must be available. The attacker must know the camera’s MAC address (1), the access point’s channel frequency (2), and the corresponding wireless access point’s MAC address (3).
Using Kismet, this information is easily gathered passively and the attacker does not need to be authenticated to the access point. Note that the Nest camera is connected to the “Sunami” network, whose MAC address is 34:97:F6:07:35:28.
Figure 2 - Access Point Details From Kismet
Figure 3 - Nest Client Details From Kismet
Using the “airmon-ng” tool, an attacker can kill conflicting services and set the wireless device into monitor mode on the correct channel – in this case, Channel 2:
- # airmon-ng check kill
- # airmon-ng start wlan0 2
The attacker can then use the “aireplay-ng” tool to launch the deauthentication attack; where “-a” is the access point MAC address (BSSID), “-c” is the client MAC address to be deauthenticated, and “--deauth” is set to 0, which means to continue until the command is cancelled:
- # aireplay-ng --deauth 0 -a 34:97:F6:07:35:28 -c 18:B4:30:5A:DB:21 wlan0mon
- 16:24:46 Waiting for beacon frame (BSSID: 34:97:F6:07:35:28) on channel 2
- 16:24:47 Sending 64 directed DeAuth. STMAC: [18:B4:30:5A:DB:21] [265|276 ACKs]
- 16:24:48 Sending 64 directed DeAuth. STMAC: [18:B4:30:5A:DB:21] [58|58 ACKs]
- 16:24:48 Sending 64 directed DeAuth. STMAC: [18:B4:30:5A:DB:21] [63|61 ACKs]
- 16:24:50 Sending 64 directed DeAuth. STMAC: [18:B4:30:5A:DB:21] [252|251 ACKs]
- ….
In the following screenshot of the Nest video console, we can see that the computer time shows 4:33 PM, however, we can see that video stopped with the wall clock reading 4:25.
This created a 10-minute gap where no video footage was recorded. During this time, much hand waving was conducted to ensure that if motion was detected, an alert would be received. No alerts fired. When video stops recording, the camera just waits at the last recorded frame. Unless someone was actively viewing the footage and expected the footage to change, such as the clock hands moving, then this issue would not have been identified.
Figure 4 - Beginning The Attack
Once the deauthentication attack is cancelled, we see that the video begins again. Again, note that no alerts were fired regarding the camera being down. All settings in Nest were checked to identify a method of changing the alert settings when the camera goes offline, but this is not a user configurable setting.
Figure 5 - Gap In Footage From Attack
Overall the camera was offline for more than 10 minutes, with no video recorded and no alerts being fired. If this was a real attack, the clock would likely have been stolen.
This test was repeated multiple times and only one of the tests caused an email to be sent stating that the camera was offline for more than 10 minutes. It is believed that the lack of notification is due to a few packets slipping through during the attack, which initiates the authentication with Nest Cloud Services. It takes approximately 20 seconds for Nest to fully authenticate and start sending video. The attack was being conducted at maximum speed, blocking almost all packets from being sent. By reducing the attack timing, an attacker can allow a few packets through to Nest, keeping the camera down alert from being emailed, even though no video is being recorded. In the one test which caused a notification to fire, the attack caused issues with the Access Point itself and multiple other clients had intermittent network issues. Even if this alert works consistently at the 10-minute mark, this still allows an attacker enough time to enter the facility, stop the deauthentication attack, wait 1 minute in a safe location, restart the deauthentication attack, and repeat this process until the objective is complete.
Mitigation
Due to this issue being a limitation of current 802.11 wireless protocols, there is no way to remediate this vulnerability aside from switching to wired cameras. Some mitigation can be put in place by monitoring for deauthentication frames near the camera and alerting on abnormal amounts. Due to the large amount of deauthentication packets required to guarantee no video is captured, it is easy to identify if malicious activity is being conducted.
If your organization has 802.11 wireless equipment with Intrusion Detection System (IDS)/Intrusion Prevention System (IPS) functionality, check for a signature for “Deauthentication Flood Denial of Service”. Ensure that this signature is enabled and that a real-time alert is sent upon detection.
If you are using the cameras in your home or your organization does not have an 802.11 wireless IDS/IPS, then a computer or Raspberry Pi could be set up on a wired connection with a wireless card in monitor mode to monitor for such activity. The following link is an example of a python script which uses a wireless interface already set to monitor mode (with airmon-ng) to log deauthentication frames.
This script requires the aircrack-ng suite, scapy, and the wireless interface to be placed into monitor mode before the script is run:
- # airmon-ng check kill
- # airmon-ng start wlan0
The logfile is automatically created in the same directory as the script, but can be configured using the “logfilename” variable in the script to add a path. The output is shown below – note that the AP and Client flip back and forth as bi-directional communication occurs. The output below is from aireplay-ng’s –deauth being set to 1, which is the lowest setting and sends 64 deauthentication packets. For cameras, over 200 deauthentication packets in a 2 minute window is extremely suspicious.
- # python deauthmon.py wlan0mon
- WARNING: No route found for IPv6 destination :: (no default route?)
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- […SNIP…]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class2-from-nonauth]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [34:97:f6:07:35:28] CLIENT: [18:b4:30:5a:db:21] Reason: [class3-from-nonass]
- AP: [18:b4:30:5a:db:21] CLIENT: [34:97:f6:07:35:28] Reason: [class3-from-nonass]
The log file can be captured by a Security Information & Event Management (SIEM) system by sending it through syslog or running it through an agent file parser. Alternatively, the file can be parsed directly into packets counts and sent via email. However, even with monitoring, the alert must be sent to someone who will be able to respond onsite quickly and will actually go onsite when an excessive amount of deauthentication frames occur. While this is currently not an overly exploited attack method, it is likely to become more popular as wireless cameras get placed in sensitive locations such as server rooms, offices, convenience stores, etc.
When purchasing or replacing cameras, we recommend utilizing wired cameras whenever possible and requiring wired cameras for high risk areas where the footage is likely to be used in police reports. Such places include cashier areas, server rooms, and facility door cameras.
Are you unsure of your organization’s physical or wireless security posture? Contact us today to learn more about how we can help you assess your physical or wireless security.
