Cisco has released security updates to address multiple vulnerabilities in Data Center Network Manager (DCNM). A remote attacker could exploit these vulnerabilities to take control of an affected system. For updates addressing lower severity vulnerabilities see the Cisco Security Advisories webpage.
The Cybersecurity and Infrastructure Security Agency (CISA) encourages users and administrators to review the following Cisco advisories and apply the necessary updates:
The idea of controlling your garage door remotely and verifying that everything is secure at home, or having packages delivered directly into your garage is enticing for many people. The convenience that many of these IOT devices provide often persuades consumers away from thinking about the possible security concerns.
McAfee Advanced Threat Research recently investigated Chamberlain’s MyQ Hub, a “Universal” garage door automation platform. The way Chamberlain has made this device universal is via a Hub, which acts as a new garage door opener, similar to the one that you would have in your car. This allows the MyQ Hub to retrofit and work with a wide variety of garage doors.
We found that Chamberlain did a fairly good job of securing this device, which is typically uncommon for IOT devices. However, we discovered that there is a flaw in the way the MyQ Hub communicates with the remote sensor over radio frequencies.
From an attack perspective there are three main vectors that we began to look at: local network, remote access (API, or third-party integration), and RF communications between the sensor and the Hub. The first thing we attempted was to gain access to the device via the local network. A quick port scan of the device revealed that it was listening on port 80. When attempting to navigate to the device at port 80 it would redirect to start.html and return a 404 error. No other ports were open on the device.
The inside of the Chamberlain MyQ Hub
Disassembling the Hub revealed a small SOC (system on a chip) module that was handling the Wi-Fi and web communications and a secondary PIC microcontroller which was responsible for controlling the RF side of things for both the garage door and the remote door sensor. The MyQ Hub listed on FCC’s website also included a Bluetooth module that was not present on the two MyQ Hubs that we purchased.
The UART connection was disconnected or not enabled, but the JTAG connection worked to communicate directly with the main Wi-Fi module. With the JTAG connection we were able to dump the entire contents of the flash chip and debug the system unrestricted. The main Wi-Fi module was a Marvell microcontroller that was running a RTOS (Real Time Operating System), which acts much different than a normal Linux system. While it will still run predefined applications, RTOS’ usually don’t have a filesystem like traditional systems do. We extracted the entire contents of the Marvell microprocessor, and were able to analyze the assembly and determine how the web server behaves.
From looking through the web server code we were able to identify how the device is setup through the local API as well as finding some interesting, albeit not very useful commands that we could send.
Local API commands
There were more URLs that we found to be accessible and some additional API paths, but nothing stood out as a good place to start an attack from. At this point we decided to investigate the other attack vectors.
We didn’t spend too much time looking into the third-party attack vector and remote API since it becomes sort of a gray area for researching. While we were testing with the /sys/mode API call we were able to put the device into a soft factory reset, where we were able to attempt to add the device to a different account. From capturing the SSL traffic on the mobile application, we were able to see that it was failing since the serial number was already registered to another account. We used a technique called SSL unpinning to decrypt traffic from the Android application; we’ll post a future blog explaining this process in greater detail. One thing that we wanted to try was to modify the Android app to send a different serial number. Since we don’t believe that the device ever cleared the original garage door information, we could have potentially opened the device from the new account. However, this is all speculation and was not tested because we didn’t want to access the remote API.
The last vector we looked at was RF. We began trying to break down the frequency modulation between the remote door sensor and the Hub. We originally thought it was some sort of FSK (frequency shift keying) where data is transmitted digitally. If the signal is in one frequency the corresponding bit is 0 and if the signal is shown on another frequency the bit is 1. This idea was thrown out since the MyQ remote sensor was using 3 different frequencies not just two.
Looking at the door sensor’s FCC filing we noticed a particularly helpful revision that they made.
OOK stands for “On OFF Keying” and is another method of encoding digital bits into RF. OOK will either be sending a signal (1) or not sending a signal (0). This means both the transmitter and receiver must be synchronized.
On Off Keying Graphical Representation
Here is the binary representation for the signal captured from the MyQ remote door sensor. This is a tightly zoomed-in window of the entire signal.
One full message captured, each color is a different frequency
We can observe the state transmission captured from all three frequencies and converted to hexadecimal. It’s easy to identify data patterns within the transmission, as represented in color above, but we were never able to crack it to arbitrarily transmit false states from our SDR (Software Defined Radio). We also noticed that the RF engineers at Chamberlain had security in mind not only by separating the signal into three separate frequencies, but also by implementing rolling codes. You may be familiar with the rolling code technique from things like your standard garage door opener or your car key fob. Rolling code devices prevent an attacker from directly capturing a signal and replaying it. This is prevented by the signal containing a unique identifier that is noted by the receiver and if the receiver ever sees that signal with the unique ID again it will ignore it.
The way attackers have overcome rolling code devices is by a method called “Roll Jam.” An attacker will jam the rolling code signal from the transmitter, blocking it from ever making it to the receiver, while simultaneously capturing the valid rolling code and storing it. This way the attacker now has an unused and valid rolling code that the receiver has never seen before. The caveat to this method is that normally the victim will notice that either the garage door or car didn’t unlock. A stealthier method to Roll Jam is always capturing the latest code and replaying the latest signal minus 1. This way the car or door will open but the attacker still owns the latest code for their use.
The MyQ also had a rolling code implementation that we were able to develop a variant of this technique against. We took the concept of jamming the original code from the receiver by transmitting a large amount of “noise” directly adjacent to the valid signal frequency. This causes the receiver in the MyQ Hub to overload and not hear the valid signal. However, with the precision of the SDR, we were able to ignore the noise that we are transmitting and store the signal. This was further complicated by the fact that there were three frequencies that we had to simultaneously listen for and jam. If you are interested in this FHSS (Frequency Hopping Spread Spectrum) Roll Jam technique, please read our white paper.
Within the research related to Chamberlain Garage Door Hub described in this blog, the only interference was to unlicensed spectrum radio frequency for the minimum period while the garage door hub was transmitting state signal, and there was no interference with any communications signal licensed or authorized under the Communications Act or FCC rules.
This technique worked, but since the remote sensor and the MyQ Hub always have the advantage in RF landscape, it was unreliable. The jamming aspect of the attack worked nicely; however, since we are outside of the garage and the remote sensor and the Hub are both located within the same garage, it is harder to jam and listen at the same time with the garage door and walls acting as barriers. With higher powered radios, frequency-tuned antennas, and disregard for FCC’s laws, the jamming of the remote sensor could take place at a much further distance than we were able to test in our lab environment.
A waterfall view of the remote sensor signal (red) and jamming (black)
With our jamming working reliably, we confirmed that when a user closes the garage door via the MyQ application, the remote sensor never responds with the closed signal because we are jamming it. The app will alert the user that “Something went wrong. Please try again.” This is where a normal user, if not in direct sight of the garage door, would think that their garage door is indeed open, when in reality it is securely closed. If the user believes the MyQ app then they would do as the application indicates and “try again” – this is where the statelessness of garage doors comes into play. The MyQ Hub will send the open/closed signal to the garage door and it will open, because it is already closed, and it is simply changing state. This allows an attacker direct entry into the garage, and, in many cases, into the home.
Since now the garage door is really open the attacker probably doesn’t want to leave the state as-is, notifying the victim that something went wrong again. Putting the garage door into a closed state and allowing the app to clear the error will put the victim at ease. This could be executed either by a replay from a previously captured closed signal, or, in the most simplistic manner by removing the remote sensor from the Velcro on the garage door and placing it in the vertical position, signaling to the Hub that the door closed successfully.
Attack Reproduction State Flowchart
We also realized that in a real-world scenario, an attacker wouldn’t likely sit outside of a garage all day, so we decided to automate the attack. We used GNU radio to implement a JIT (just in time) method of jamming where the SDR will sit dormant listening on the MyQ’s three separate frequencies. The moment it notices that the remote door sensor is beginning a transmission, it will dynamically enable and start jamming of the signal.
GNU Radio JIT Jamming and State Capture over 3 Simultaneous Frequencies
This expands the use cases of this type of attack by being able to create a small device that could be placed out of sight near the garage door. This technique is also described in more detail in our FHSS white paper. The JIT jamming makes it very difficult to locate the device using RF triangulation and allows it to be better equipped for battery operation.
While this may not be too common for individuals using the MyQ Hub, recall the earlier reference to third-party partnerships with MyQ for garage delivery. Another possible attack would be when a delivery driver uses the application. The primary reason users sign up for this service is the concept of a package delivery to a secure location (garage) even when they are not home. The victim can be absent from the property yet have access via the MyQ app over the internet to open or close the garage door if a delivery driver uses the MyQ hub for an in-garage delivery. A determined hacker could pull this attack off and the victim may have a higher probability of believing that the door may in fact be open. We disclosed our findings in full to Chamberlain on 9/25/2019, including detailed reproduction steps for the jamming attack. We also talked to Chamberlain on this issue with the third-party delivery drivers and how it could fit into this attack model. After extensive testing and validation of the issue, the vendor released an update to the myQ App as of version 126.96.36.199946. This update provides a valuable warning message to users indicating the garage door state may not be accurate, but it does not eliminate the user from remotely controlling the door itself.
The beauty of IOT devices are that they solve problems that we have learned to deal with. After we experience the convenience and the way these devices can automate, secure, or assist in our lives it is hard to see them ever going away. This ease and automation often overshadows the potential security threat that they may pose. Even simple enhancements to manual products over time have this effect; take for example the now-legacy garage door opener in your car. The ability to capture and replay the basic signals transformed the threat from physical to digital space. While the Chamberlain MyQ Hub ultimately produces a generally more secure method of accessing garages than its predecessors, consumers should be aware that any extension of a technology platform, such as using WiFi, a mobile app and FHSS RF transmissions, also extends possible threat vectors.
We would like to finish by commenting that the likelihood of a real-world attack on this target is low, based on the complexity of the attack and installation footprint. We have discussed this with Chamberlain, who has validated the findings and agrees with this assessment. Chamberlain has made clear efforts to build a secure product and appears to have eliminated much of the low-hanging fruit common to IoT devices. This vendor has been a pleasure to work with and clearly prioritizes security as a foresight in the development of its product.
NOTE: Within the research related to Chamberlain Garage Door Hub described in this blog, the only interference was to unlicensed spectrum radio frequency for the minimum period while the garage door hub was transmitting state signal, and there was no interference with any communications signal licensed or authorized under the Communications Act or FCC rules.
McAfee’s Advanced Threat Research team performs security analysis of products and technologies across nearly every industry vertical. Special interest in the consumer space and Internet of Things (IoT) led to the discovery of an insecure design with the McLear NFC Ring a household access control device. The NFC Ring can be used to interact with NFC-enabled door locks which conform to the ISO/IEC 14443A NFC card type. Once the NFC Ring has been paired with the NFC enabled door lock, the user can access their house by simply placing the NFC Ring within NFC range of the door lock.
McLear originally invented the NFC Ring to replace traditional keys with functional jewelry. The NFC Ring uses near field communication (NFC) for access control, to unlock and control mobile devices, share and transfer information, link people and much more. McLear NFC Ring aims to redefine and modernize access control to bring physical household security through convenience. Their latest ring also supports payment capability with McLear Smart Payment Rings, which were not in scope for this research.
Identity is something which uniquely identifies a person or object; an NFC tag is a perfect example of this. Authentication can be generally classified into three types; something you know, something you have and something you are. A NFC Ring is different from the general NFC access tag devices (something you have) as the Ring sits on your finger, so it is a hybrid authentication type of something you have and something you are. This unique combination, as well as the accessibility of a wearable Ring with NFC capabilities sparked our interest in researching this product as an NFC-enabled access control device. Therefore, the focus of our research was on NFC Ring protection against cloning as opposed to the door lock, since NFC access control tags and door locks have been well-researched.
The research and findings for this flaw were reported to McLear on September 25, 2019. To date, McAfee Advanced Threat Research has not received a response from the vendor.
Duplicating Keys Beyond the Hardware Store
In the era of Internet of Things (IoT), the balance between security and convenience is an important factor to get right during the concept phase of a new product and the bill of materials (BOM) selection. The hardware selection is critical as it often determines the security objectives and requirements that can be fulfilled during design and implementation of the product lifecycle. The NFC Ring uses an NFC capable Integrate Circuit (IC) which can be easily cloned and provides no security other than NFC proximity. The NFC protocol does not provide authentication and relies on its operational proximity as a form of protection. The problem with NFC Tags is that they automatically transmit their UID when in range of NFC device reader without any authentication.
Most consumers today use physical keys to secure access to their household door. The physical key security model requires an attacker to get physical access to the key or break the door or door lock. The NFC Ring, if designed securely, would provide equal or greater security than the physical key security model. However, since the NFC Ring can be easily cloned without having to attain physical access to the Ring, it makes the product’s security model less secure than a consumer having a physical key.
In this blog we discuss cloning of the NFC Ring and secure design recommendations to improve its security to a level equal to or greater than existing physical keys.
NFC Ring Security Model and Identity Theft
All McLear non-payment NFC Rings using NTAG216 ICs are impacted by this design flaw. Testing was performed specifically on the OPN which has an NTAG216 IC. The NFC Ring uses the NTAG 216 NFC enabled Integrated Circuit (IC) to provide secure access control by means of NFC communication.
The NFC protocol provides no security as it’s just a transmission mechanism. The onus is on product owners to responsibly design and implement a security layer to meet the security objectives, capable of thwarting threats identified during the threat modeling phase at concept commit.
The main threats against an NFC access control tag are physical theft and tag cloning by NFC. At a minimum, a tag should be protected against cloning by NFC; with this research, it would ensure the NFC Ring provides the same level of security as a physical key. Ideal security would also protect against cloning even when the NFC Ring has been physically stolen which would provide greater security than that of a physical key.
The NTAG216 IC provide the following security per the NFC Ring spec:
Manufacturer programmed 7-byte UID for each device
Pre-programmed capability container with one-time programmable bits
Field programmable read-only locking function
ECC based originality signature
32-bit password protection to prevent unauthorized memory operations
The NFC Ring security model is built on the “Manufacturer programmed 7-byte UID for each device” as the Identity and Authentication with the access control principle or door lock. This 7-byte UID (unique identifier) can be read by any NFC enabled device reader such as a proxmark3 or mobile phone when within NFC communication range.
The NFC Ring security model can be broken by any NFC device reader when they come within NFC communication range since the static 7-byte UID is automatically transmitted without any authentication. Once the 7-byte UID has been successfully read, a magic NTAG card can be programmed with the UID, which forms a clone of the NFC Ring and allows an attacker to bypass the secure access control without attaining physical access to the NFC Ring.
The NFC Ring is insecure by design as it relies on the static 7-byte UID programmed at manufacture within the NTAG216 for device identity and authentication purposes. The NFC Ring security model relies on NFC proximity and a static identifier which can be cloned.
In addition, we discovered that the UIDs across NFC Rings maybe predictable (this was a very small sample size of three NFC Rings):
NFC Ring#1 UID 04d0e722993c80
NFC Ring#2 UID 04d24722993c80
NFC Ring#3 UID 04991c4a113c80
There is only a 22-byte difference between the UID of NFC Ring#1 and NFC Ring#2 (0x24-0x0e). By social engineering when a victim purchased their NFC Ring, an attacker could purchase a significant sample size of NFC Rings around the same time and possibly brute force their NFC Ring UID.
Social Engineering consists of a range of techniques which can be used through human interaction for many malicious purposes such as identity theft. In the case of the NFC Ring the goal is to steal the user’s identity and gain access to their home. Reconnaissance can be performed online to gain background information such as what type of technology is being used by the victim for their home access.
One of the most common exchanges of technology today has become the passing of a phone between two untrusted parties to take a picture. The NFC Ring social engineering attack could be as simple as requesting the victim to take a picture with the attacker-supplied phone. The victim-as-helpful-photographer holds the attacker’s phone, which can read NFC tags and could be equipped with a custom Android app to read the NFC Ring UID, all transparent to the victim while they are snapping away. There is no sign to the victim that their NFC Ring is being read by the phone. It is recorded in the system log and cannot be viewed until a USB cable is attached with required software. Once the Ring is compromised, it can be reprogrammed on a standard writable card, which can be used to unlock smart home locks that partner with this product. The victim’s home is breached.
How It’s Done: NFC Ring Cloning
To successfully clone an NFC Tag, one must first identify the Tag type. This can be done by looking up the product specifications in some cases, or verifying by means of an NFC device reader such as a proxmark3.
From the NFC Ring specs we can determine most of the required tag characteristics:
Setting attacker’s phone to silent to prevent NFC Tag detection sound
Running our customized Android app to prevent Android activity popup when NFC Tag detected and read.
Mitigation Secure Design Recommendations
Lock the door. The existing insecure design can be mitigated by using NFC Doorlock password protection in combination with the NFC Ring for two factor authentication.
Authenticate. NFC Ring designers must mandate a secure PKI design with an NFC Tag which contains a crypto module that provides TAG authentication. The NFC Ring secure design must mandate a security layer on top of NFC to access control device manufacturers to ensure secure and trustworthy operation.
Randomize UIDs. In addition, the NFC designers must ensure they are not manufacturing NFC Rings with sequential UIDs which may be predictable with purchase date.
To make customers aware of the security risks associated with products available on the market, product manufacturers should clearly state the level of security which their product provides in comparison with the technology or component they claim to be advancing. Are customers holding the master key to unlock their door, and are there duplicates?
In the case of the NFC Ring, while convenient, it clearly does not provide the same level of security to consumers as a physical key. This decrease in security model from a physical key to a NFC Ring is not due to technology limitations but due to an insecure design.
This week McAfee Advanced Threat Research (ATR) published new findings, uncovering security flaws in two popular IoT devices: a connected garage door opener and a “smart” ring, which, amongst many uses, utilizes near field communication (NFC) to open door locks.
I’d like to use these cases as examples of a growing concern in the area of product security. The industry of consumer devices has seen some positive momentum for security in recent years. For example, just a few years back, nearly every consumer-grade router shipped with a default username and password, which, if left unchanged, represented a serious security concern for home networks. At a minimum, most routers at least now ship with a unique password printed on the physical device itself, dramatically increasing the overall network security. Despite positive changes such as this, there is a long way to go.
If we think about the history of garage doors, they began as a completely manual object, requiring the owner to lift or operate it physically. The first overhead garage door was invented in the early 1920s, and an electric version came to market just a few years later. While this improved the functionality of the device and allowed for “remote” entry, it wasn’t until many years later that an actual wireless remote was added, giving consumers the ability to allow wireless access into their home. This was the beginning of an interesting tradeoff for consumers – an obvious increase in convenience which introduced a potential new security concern.
The same concept applies to the front door. Most consumers still utilize physical keys to secure the front door to their homes. However, the introduction of NFC enabled home door locks, which can be opened using compatible smart rings, adds both convenience and potentially compromised security.
For example, upon investigating the McLear NFC Ring, McAfee ATR uncovered a design insecurity, which could allow an attacker to easily clone the NFC Ring and gain entry to a home utilizing an NFC enabled smart lock.
While the NFC Ring modernizes physical household security, the convenience that comes with technology implementation also introduces a security issue.
As we move towards automation and remote access to nearly every computerized system on the planet, it’s our shared responsibility to maintain awareness of this fact and demand a higher bar for the products that we buy.
So what can be done? The responsibility is shared between consumers and manufacturers, and there are a few options:
Practice proper cyber hygiene. From a technical perspective, consumers have many tools at their disposal, even when security concerns do manifest. Implement a strong password policy, put IoT devices on their own, separate, network, utilize dual-factor authentication when possible, minimize redundant systems and patch quickly when issues are found.
Do your research. Consumers should ensure they are aware of the security risks associated with products available on the market.
For product manufacturers:
Manufacturer supported awareness. Product manufacturers can help by clearly stating the level of security their product provides in comparison with the technology or component they seek to advance.
Embrace vulnerability disclosure. Threat actors are constantly tracking flaws which they can weaponize; conversely, threat researchers are constantly working to uncover and secure product vulnerabilities. By partnering with researchers and responding quickly, vendors have a unique opportunity