Insecure Authorization Scheme for API Requests in DBD+ Mobile Companion Application for Megafeis Smart Locks

An authorization issue was discovered in the HTTP API used by the DBD+ mobile companion application, which is used to manage Megafeis branded smart locks. An authenticated user that is able to forge request signing keys can utilize this vulnerability to perform arbitrary API requests. This would grant them the ability to enumerate, transfer ownership of, and unlock any Megafeis smart lock within physical proximity using only the lock's MAC address, which it broadcasts over Bluetooth.

As of this advisory's publishing date, there has been no response from the manufacturer, nor is WithSecure aware of any remedial action taken.

Additional information on this issue, along with related issues discovered by the researcher, can be found in the following locations:

• The Megafeis-palm: Exploiting Vulnerabilities to Open Bluetooth SmartLocks publication
• The associated GitHub repository:  https://github.com/WithSecureLabs/megafeis-palm

Detailed information on this issue's exploitation and discovery can be found at the associated publication, Megafeis-palm: Exploiting Vulnerabilities to Open Bluetooth SmartLocks.

The authorization scheme's weakness can be attributed to two main factors. The first factor is Megafeis' solitary use of a signing key to validate requests sent from the DBD+ application to the backend API server. The second factor is that although session tokens are being sent with each web request to the API, the session tokens do not appear to be used for checking if a user is authorized to make that request.

The signing key was included in a custom HTTP header called "SecSignDest". Version 1.4.2 of the DBD+ application exposed its generation process as being a concatenation of various fixed and dynamic values. They are listed in order below:

• The string "OKLOK"
• The request's timestamp
• Truncated data from the request's body
• The API endpoint to which the request is being sent

After the above information is combined into a single string, a MD5 hash value is generated of that string. The resulting hash value is then used as the "SecSignDest" HTTP header value.

Recreating this formula to forge request signing keys allowed users to send arbitrary authorized requests to the API. Since the server did not perform proper authorization checks, this allowed arbitrary actions to be performed on other users' accounts (i.e. lock ownership reassignment).

To better demonstrate the above, WithSecure modified the source code of the DBD+ application to also add two additional HTTP headers with each web request.

• The first header, "AbdullahMKey" is the previously mentioned concated string
• The second header, "FinalDigest", is a MD5 hash of the "AbdullahMKey" header value

Below is a sample API request sent from the modified application, showing the additional headers mentioned. Note that the "FinalDigest" and "SecSignDest" header values are the same:

WithSecure also put the "AbdullahMKey" header value through a MD5 hash tool, which outputed the same hash value as "FinalDigest" and "AbdullahMKey", as shown in the image below. This demonstrates that the application generated the "SecSignDest" value using the method discovered by the researcher.

WithSecure created a proof of concept script that can be used to fully exploit this issue and take over any Megafeis-branded smart lock. The script requires the MAC address of the target smart lock as well as the attacker's DBD+ account username and password. The script was successfully tested on Megafeis smart lock models FB50S, GS60FB, GS40S, and GQ10FB

The script is available here: https://github.com/WithSecureLabs/megafeis-palm/blob/main/CVE-2022-45636/CVE-2022-45636_PoC.py