Open Mobile Menu

Blog

Mission Invisible: Wireless Surveillance Camera Denial of Service

Views: 4654

Written By: Tim Jensen January 09, 2017

Update 1/10/17: AppSec Consulting was 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. AppSec Consulting performs due diligence prior to posting any content, however, we had missed this talk. AppSec Consulting will commit to performing better due diligence in the future.

Many companies have come out with 2.4/5 Ghz 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 setup, 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 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), 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, who’s 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 setup 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, AppSec Consulting recommends 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 AppSec Consulting today to learn more about how we can help you assess your physical or wireless security.

Tim Jensen

Tim Jensen is a Senior Penetration Tester with AppSec Consulting with more than 7 years of experience in Information Security.  He holds the CISSP certification and has expertise in all aspects of ethical hacking, penetration testing and security operations.  Tim specializes in aligning systems to security frameworks such as DISA STIGS and conducting penetration tests to validate system security. He also specializes in brief and deep security impact analysis of new hardware, software, policies, and procedures being brought into an organization. He has conducted over 100 penetration tests involving external networks, internal networks, web application assessments, mobile devices, physical assessments, SCADA systems, and more. Tim was the co-founder of StaridLabs training academy, hacklab and tech incubator in Fargo, ND. StaridLabs provided free weekly information security training to IT professionals for over 4 years. Tim is heavily involved in his local community and with the Boy Scouts of America. He has been asked to speak at several conferences regarding a variety of information security topics.

read more articles by Tim Jensen