Brute-forcing ButterflyMX Virtual Keys and Hacking Time Limits

Recently, I discovered two vulnerabilities in the ButterflyMX system which were responsibly disclosed to the vendor. The vendor has mitigated the highest-risk vulnerability, which enabled unauthorized attackers to gain access to buildings equipped with the ButterflyMX Access Control System by employing a brute-force technique, typically requiring only a few hundred attempts to successfully guess virtual keys. Now that ButterflyMX has concluded their investigation, I'd like to share details about the vulnerabilities and how the cooperation between ButterflyMX and Trustwave Spiderlabs has made buildings equipped with this system more secure.

Below is a summary of the vulnerabilities that will be covered in this blog post.

Virtual Keys Brute-Force via Web Application ButterflyMX

A potential criminal could brute-force virtual keys to gain access to the properties or obtain information about the owner.

Bypass Restrictions of ButterflyMX Virtual Key Time Duration

The ButterflyMX application allows residents to generate a virtual key. The front-end app allows a resident to generate a virtual key for a maximum of 1 year. This verification is performed on the Android/iOS mobile application instead of the backend API. This is considered to be a low-risk vulnerability.

Diving into the Details

For those unfamiliar with the ButterflyMX system, it is a web-based intercom and access control system that allows residents of multi-unit buildings, such as condominiums and apartments, to grant access to their guests without the need for physical keys. It is used in 10,000+ buildings. The system allows residents to generate virtual keys for guests, which can be sent via text message or email. Guests can then use these virtual keys to gain access to the property by entering a PIN code, holding their phone up to the camera, or using the screen to call their contact.

Figure 1. ButterflyMX Video Intercom

In the scenario that a resident would like to grant guests or their dogwalker access to the building, the resident is able to generate a virtual key using the Android or iOS app and send it via text message or email. The guest would receive a text message such as the one in figure 2.

Figure 2. Example of Virtual Key Text Message

At the end of the text message, there is a shortened URL with only five lowercase alphanumeric characters. For demonstration purposes, an example of the shortened URL could be https://user.butterflymx.com/urls/sp3dr. Note that this shortened URL does not link to a valid virtual key, but it represents a sample that meets the required format. This allows the ability to interchange lowercase letters and numbers to guess a potential valid virtual key. Then, by performing a GET request to that page, the HTML code can be analyzed to determine if the guess was valid or not.

One solution to programmatically check if a virtual key is valid or not is by developing a regular expression that we can test against the source code such as ‘/Virtual\sKey<\/title>/is’. Figure 3 shows a screenshot when there is a match, versus figure 4 where the virtual key is invalid, and the URL is redirected to https://accounts.butterflymx.com/login/new.

Figure 3. Regular Expression Match of HTML Content

Figure 4. No Regular Expression Match of HTML Content

In the event there is a valid response, the contents in the HTML page include the PIN codes, the QR code, the property address including unit number, resident name, and the dates/times the virtual key is valid. Figure 5 provides a screenshot of the content available in the shortened URL. Note that this specific virtual key was not brute-forced and was generated for demonstration purposes.

Figure 5. Virtual Key

As shown in figure 5, there is an option to download the virtual key to your Apple Wallet. By adding it to your wallet and accessing it, you can also obtain the name of the key that was created by the owner. For example, the owner may provide a specific name for the virtual key, such as who the key is for. This could be the specific name of the person, or the naming of the virtual key could be more generalized. Let’s say the owner calls a specific key "Dog Walker Service". In this case, it provides context about who is using this virtual key and potentially when they are accessing the property. Upon creation of the virtual key, you can provide recurring access for specific days and times.

Let's imagine that you use a dog-walking service every Monday and Thursday and generate a virtual key for them to access your property on those days. If an attacker gains unauthorized access to this information, they can learn about the habits of a specific unit owner, potentially enabling them to know when they are away. This information could also be useful for a social engineering campaign. Figure 6 shows a screenshot of an Apple Wallet pass that illustrates this scenario. Please note that the recurring virtual keys generated in the application are only valid for up to one year.

Figure 6. ButterflyMX Apple Wallet Pass

It would be difficult to guess a specific virtual key. However, knowing that the identifier in the shortened URL is weak, this allows an attacker to develop a simple script to brute-force virtual keys for all buildings that use the ButterflyMX system. Parsing the HTML body within the shortened URL allows filtering buildings in the area, a specific address, or both. Nowadays, there are AI platforms, such as ChatGPT, that can generate code effortlessly, demonstrating the ability for anyone to exploit this vulnerability. Figure 7 provides a screenshot of script generated with ChatGPT.

Figure 7. PoC generated with ChatGPT

Let's dig into a bit of math. As mentioned earlier, there are 10,000+ buildings that use this system. For demonstration purposes, let’s say there are 20 virtual keys for each building. This would mean there would be a total of 200,000 virtual keys hosted on the ButterflyMX website. It is believed that this is a lower estimate than the exact number of virtual keys out there.

Going back, we know that a shortened URL includes 5 lowercase alphanumeric characters (26 lowercase letters and 10 numbers), meaning that there are 36 choices for each character. So, the number of combinations available is 36 to the 5th power (60,466,176). If there are 200,000 virtual keys, then it would be probable to get a valid virtual key after about every 303 HTTP GET requests.

Now that ButterflyMX has implemented enhanced timeout restrictions and increased the number of characters to 8 case-sensitive alphanumeric characters, based on our findings, this prevents the likeliness of guessing a valid virtual key before it expires. With this enhancement, the number of possibilities increase to 62 to the 8th power (218,340,105,584,896).

In conjunction with the security issue mentioned above, it was found that the Android/iOS front-end application, which was designed to restrict the use of virtual keys to a 1-year limit, could be bypassed by making direct calls to the API. The below video demonstrates the inability to generate a virtual key for longer than 1 year using the iOS application.

Video Link: https://www.youtube.com/watch?v=aXvRzsZxrv0

However, if we capture the authentication token, we can perform a POST request containing any timeframe of our choosing, as shown in Figure 6, where a virtual key is generated for the year 2999.

Figure 8. Bypassing Virtual Key Timeframe Restrictions

Since this issue requires authentication details, it is considered low risk. One scenario in which this functionality could be abused is if a resident accesses the application on an untrusted network and an attacker is able to obtain the authorization token via a man-in-the-middle attack. The attacker could then generate a virtual key on the account for any duration of time.

Responsible Disclosure

Anyone who has worked Responsible Disclosure on either side understands the frustrations that often come with the process. That’s why it’s a pleasure to work with vendors like ButterflyMX. They instantly understood the scale and scope of the issue and worked with our team through regular updates and status checks. In turn, ButterflyMX fixed these issues before bad actors discovered them. This should be a lesson for all organizations that produce software or services. Security reports from third parties are not threats. They are free audit reports that directly protect your business and your customers.

Remediation

As of December 16, 2022, ButterflyMX announced the successful resolution of a critical vulnerability related to the use of short key lengths in newly generated virtual keys. Additionally on April 28th, the vendor implemented a fix to eliminate the inclusion of Personal Identifiable Information (PII) in the web page linking to the virtual key and within the URL itself.

However, it is important to note that these issues persisted in virtual keys generated prior to the deployment of the fixes. More recently, on June 7th, ButterflyMX provided an update, informing us that they have generated new virtual keys to replace the remaining vulnerable ones. These newly generated keys address the issues that we reported to them.

Although the ability to bypass key expiration dates by accessing the API directly was identified as a vulnerability, ButterflyMX has classified it as low risk. The vendor has shared this information in their response to us:

“ButterflyMX is introducing new features for virtual key management later in 2023. These will include, among other enhancements, building-specific virtual key time limits, which will allow individual buildings to control the valid time period for virtual keys. This is in response to customer feedback regarding unique needs across different use cases; this feature will include validation of time limits against the building-specific settings when virtual keys are created. This will close this issue, as keys submitted via the API will be evaluated on the backend for compliance before creation.”