TL;DR The U-Tec Ultraloq UL3 can be unlocked via BLE GATT characteristic writes from an unauthorized user due to weak encryption.

This video shows the script in action and unlocking the lock.

Background:

Spanalytics regularly surveys the IoT security space for published protocol and protocol implementation vulnerabilities. The U-Tec Ultraloq BLE vulnerability published in June 2019 by PenTest Partners was one such vulnerability that caught our attention. We purchased a lock for research and then put it aside until August 2020 when Tripwire Research published a report on the vulnerabilities they had found in the Ultraloq. At the time, Spanalytics was preparing for an upcoming demo scheduled for RIot Virtual Developer month in September. The demo was titled “What to look for in your Bluetooth traffic,” and that seemed like a good reason to get out the Ultraloq and see if we could replicate Pen Test Partners’ success in breaking into the lock over BLE. This blog post will detail the work and results of the Ultraloq BLE testing.

Testing:

Pen Test Partners’ blog post on the lock vulnerability gave us a starting point.

This blog post gave us the BLE GATT characteristic UUID. So first, we tried to connect to the lock and read the characteristic.

Figure 1 Successful gatttool connection and UUID characteristic read

The lock accepted our connection request and responded with the GATT characteristic value. So the next question was how to use that value to unlock the lock?

The Pen Test Partners blog post told us that there is an AES key made of the token concatenated with the string ‘Anviz.ut.’ That was helpful, but we still needed to know the unlock command and some more details about the AES encryption. Then we pivoted to look at the app. We knew that the Pen Test Partners post had been out for over a year, and according to the blog post, there was no fix for the obtainable BLE encryption key, so we guessed that the current version of the app was going to be obfuscated to make it difficult to reverse engineer. A quick look at the results of running the Android app u-tec apk through jadx confirmed that to be the case.

Figure 2 Output of utec apk from JADX

Then we sought out an older version of the apk. Older versions were easy to find with a quick google search, and we selected a version with a release date before the Pen Test Partners blog post. Running the apk through JADX to get the java gave better results and a lot of code to look through.

This looks promising

Figure 3 Output of the ultraloq app from JADX

A search on the string ‘Anviz.ut’ or the UUID of the token returned some useful results. The slide below shows some code excerpts which show the formation of the key.

Figure 4 App code showing the formation of the key from a fixed string and token read over BLE

Next, we captured the Bluetooth traffic between the app and the lock using Panalyzr.

Figure 5 Spanalytics Panalyzr

Figure 6 Panalyzr captured BLE data between the app and the lock

Looking at the Bluetooth traffic captured by Panalyzr, we see the following message sequence in the traffic between the app and the lock.

Figure 7 App and Lock message sequence

After another look at the decompiled app, we determined the AES encryption settings and wrote a script to decrypt the sniffed traffic. The decompiled app code showed that the first byte of the frame is the max value of a byte. This provided a way to verify that we got the decryption right. From the decompiled app, we knew that a frame should start with 7f, followed by the frame length and the command value. The decompiled app also told us the unlock command value, so we knew what to look for in the fourth byte.

Figure 8 Code for BLE data formation from the app

After verifying that we had correctly decrypted the commands, we used the same encryption settings to encrypt the commands and unlock the lock. Here is a screenshot of the Panalyzr capture of commands sent to the lock.

Figure 9 Panalyzr captured data between our script and the lock

And here is a screenshot of the script output (with a different token than the captured data since it was taken at a different time).

Figure 10 Unlock script output

A demo of this Ultraloq vulnerability in a live presentation can be seen in “What to look for in your Bluetooth traffic” presented as part of Week 3 of RIot Virtual Developer month. The Spanalytics presentation starts at 26:30 in the video, and the lock demo starts at 1:09: https://youtu.be/H7nB_wkgLBQ

The Ultraloq has vulnerabilities beyond BLE as documented by Pen Test Partners and Tripwire Research in the following blog posts:

Pen Test Partners: The Not So Ultra Lock

Tripwire Research: IoT Smart Lock Vulnerability Spotlights Bigger Issues

And what about this statement from the Pen Test Partners blog? “As the code for the lock is a six-digit integer, this makes it possible to attempt a brute force attack against the lock through the BLE interface.”

Our testing was limited to proving that we could unlock a lock after an example of communication between the lock and the app was captured. It seems like a plausible attack, but we did not attempt to test a brute force attack on a lock where the communication was not previously captured.

Thanks for reading!

Please contact us for more information or to get in on the PANalyzr beta program.