The details below discuss the vulnerabilities found in the following devices:
WAFU Keyless Smart Lock v1.0
An attacker can use a software-defined radio to capture commands sent to the alarm from the remote keyfob. As no rolling code is implemented, it is a simple matter to play back the code and gain full access to the alarm’s functions. As an example, see the following image, comparing subsequent keypresses of the arm/disarm keyfob:
As of 22nd May, 2023, no fix has been released for this issue. Given that this is a vulnerability with the device hardware, we do not believe that this can be rectified with software updates.
All of the devices above demonstrate the same security weakness. An attacker can use a software-defined radio to capture commands sent to the alarm from the remote keyfob. As no rolling code is implemented, it is a simple matter to play back the code and gain full access to the alarm’s functions. As an example, see the following image, comparing subsequent keypresses of the AGSHome Alarm keyfob:
As of 13th May, 2023, none of the devices has been issued with a fix for this issue. Given that this is a vulnerability with the device hardware, we do not believe that this can be rectified with software updates.
Recently I had a chance to look at a number of intruder alarm systems sold via Amazon and eBay. These devices sell for up to £150, and a number are best sellers
Kerui W18 Alarm
Blitzwolf BW-IS22 Smart Home Security Alarm
Digoo DG-HAMB Smart Home Security System
AGSHome Smart Alarm
As discussed in my last post, RF frequency communication can be captured relatively easily, using a software-defined radio (SDR). All four devices use 433MHz RF to communicate between the sensors and the base station. Capturing transmissions from each device proved extremely simple; the following shows the result of triggering one of the door sensors included with the Kerui alarm:
I decided to capture the results of pressing the alarm arm/disarm fob for each device. These are used to remotely enable or disable the alarm. Using SDR# I captured both the AF and IQ transmissions. The results for each are as follows:
Digoo IQ DataBlitzwolf IQ DataAGSHome IQ DataKerui IQ Data
The top line shows keypress 1, and the bottom keypress 2. As you can see, for each device the two are identical. This means that once the code is captured it can be reused by an attacker to arm and disarm the alarm at will. Not something that is desirable for a security system!
It appears that the majority of these generically named devices use 433MHz and non-rolling codes. More expensive devices seem to prefer the 868MHz band, and also rolling codes. These are more secure, but can still be jammed to stop a sensor activation from registering at the base station and triggering the alarm. They are also vulnerable to RollJam-type attacks. The moral of the story? Use something with wires!
The following CVEs are related to this work: CVE-2023-31759, CVE-2023-31761, CVE-2023-31762, CVE-2023-31763.
Have you ever wondered how wireless devices like remote controls or wireless sensors work? Chances are they use 433MHz radio technology. However, as with any technology, 433MHz radio signals can be vulnerable to hacking and exploitation. In this blog post, we’ll take a closer look at how 433MHz radio signals work, the tools and techniques used for hacking them, and the potential risks and benefits of such activities.
To understand how to hack 433MHz radio, it’s important to first understand the basics of how these signals work. 433MHz radio signals operate on a specific frequency range and use various modulation and encoding techniques to transmit information.
Modulation is the process of changing the frequency, phase, or amplitude of a radio signal to carry information. There are several types of modulation that you may encounter when working with 433MHz radio, including amplitude shift keying (ASK), frequency shift keying (FSK), on-off keying (OOK), and phase shift keying (PSK).
If you’re interested in hacking 433MHz radio, you’ll need specialized hardware and software tools like software-defined radios (SDRs), signal analyzers, and decoders. SDRs are radio communication systems that use software to control radio hardware, allowing you to manipulate radio signals and analyze them in real-time. Popular SDRs for hacking 433MHz radio include HackRF One and RTL-SDR. Signal analyzers are devices that can capture and analyze radio signals, helping you to better understand the signals and how to decode them. Popular signal analyzers for 433MHz radio hacking include the RF Explorer and the Signal Hound USB-SA44B. Decoders are software tools that can help you decode and interpret 433MHz radio signals. Popular decoders for 433MHz radio include Universal Radio Hacker (URH) and GNU Radio.
There have been several notable vulnerabilities related to 433MHz radio hacking. For example, researchers have demonstrated how vulnerable wireless home security systems can be to hacking, with some systems using 433MHz radio signals that can be easily intercepted and decoded. Additionally, replay attacks have been used to remotely control garage doors and other devices that use 433MHz radio signals. For further reading on these vulnerabilities, see “Hacking Alarm Systems with an RTL-SDR and RFCAT” and “How to Hack a Garage Door in Under 10 Seconds and What You Can Do About It”.
While hacking 433MHz radio can be a fascinating and powerful tool, it’s important to be aware of the potential risks and ethical considerations involved. By acting responsibly and using the right tools and techniques, you can help ensure that your hacking activities are safe and beneficial. If you want to learn more about 433MHz radio technology, there are many resources available that can help you explore this fascinating area of wireless technology.
With all the hype around ChatGPT, I thought I’d give it a go at writing this next post. So here we are:
The Internet of Things (IoT) has revolutionized the way we live and work, connecting a vast array of devices and enabling them to communicate and share data. However, as the number of IoT devices continues to grow, so too do the challenges surrounding their security. In the coming year, these challenges will only become more pressing, as IoT technology becomes even more deeply integrated into our daily lives.
One of the biggest challenges facing IoT security in 2023 will be the sheer scale of the IoT. As more and more devices are connected to the internet, the potential attack surface for hackers and cybercriminals grows exponentially. This makes it difficult for security professionals to keep up with the latest threats and vulnerabilities, and leaves many IoT devices vulnerable to attack.
Another major challenge will be the diversity of IoT devices. The IoT encompasses a wide range of devices, from smart thermostats and security cameras to industrial control systems and medical devices. Each of these devices has its own unique security requirements and vulnerabilities, making it difficult for security professionals to develop a comprehensive security strategy that covers all of them.
In addition, many IoT devices are designed with convenience in mind, rather than security. This means that they often have weak passwords and lack advanced security features such as encryption and two-factor authentication. As a result, these devices can be easily compromised by hackers, putting the security of the entire IoT ecosystem at risk.
Finally, the decentralized nature of the IoT makes it difficult to implement effective security measures. With so many different devices and systems connected to the internet, it can be difficult to identify and address security vulnerabilities in a timely manner. This makes it harder to prevent attacks and respond to security breaches, leaving the entire IoT ecosystem vulnerable to a wide range of threats.
Overall, the challenges facing IoT security in 2023 are significant and will require a concerted effort from both security professionals and device manufacturers to overcome. By prioritizing security and working together, we can ensure that the IoT remains a safe and secure environment for all.
So, overall not bad. It has captured a lot of pretty generic threats, and the writing is good if a little devoid of colour. Expect to see a lot of “creators” leveraging this sort of shortcut in 2023. An interesting challenge would be to try and fingerprint computer-generated posts…
I thought I’d give some brief references for anyone interested in IoT hacking. My experience here is fairly comprehensive; I have a couple of CVEs already, with a few more in the pipeline. My Masters dissertation was on the topic, and I am writing papers on it as part of my PhD work.
BOOKS:
There are three that should be on any bookshelf. They are:
“The IoT Hacker’s Handbook” by Aditya Gupta
“Practical IoT Hacking” by Fotios Chantzis and Ioannis Stais
“Practical Hardware Pentesting” by Jean-Georges Valle
These three books are a fantastic introduction to both on-board (e.g. JTAG, UART, I2C) and remote (Bluetooth, RFID, Zigbee). I would recommend you read through all three at least once.
HARDWARE:
In terms of hardware, this will depend on what you wish to investigate; the tools required for firmware dumping are wildly different from those needed for Bluetooth attacks. These are the ones I’ve found most useful (prices are approximate in GBP at the time of writing).
RFID:Proxmark3 Easy. This is honestly the best piece of entry level pentesting kit you can buy. It allows you to read and write all manner of RFID tags. There is a big brother version, the RDV4, but you don’t need that when starting out. The Easy should be around £60-70. Pick up some rewritable cards as well for a few pounds and have fun!
Bluetooth: A lot of people swear by the Ubertooth One (about £100 from eBay). Personally I found it really flaky. Instead I would look at a Nordic Semiconductor nRF52840 dongle at around £15. Add to that an Adafruit BlueFruit (based on the nRF51822 chipset) for £25 and that should be enough. If you want to try MitM attacks, then a couple of Raspberry Pi’s and a pair of cheap Bluetooth dongles should be plenty (probably £100 all in)
RF (433/868MHz): A lot of devices still use these reserved bands for communication, and you can capture transmissions using a cheap DVB-T dongle (£15-20). By default these will scan up to about 1.2GHz. For capturing transmissions at higher frequencies then you’ll either need a Yardstick One (about £100) or a HackRF (about £250). The last two have whole ecosystems around them; personally I think they’re more suited to advanced topics.
I have not included anything around Z-Wave and Zigbee as they are not popular protocols in the devices I test (smart locks, mainly). You can find tools to interface with them for a few tens of pounds. I’ve also not included any on-board debugging tools, as that’s not my area of expertise. I would suggest taking a look at the Attify Badge for around £40.
The above should give you plenty to work with. Find some willing test subjects (that you own!); I have found that anything cheap from AliExpress with one or more of these protocols enabled should give you plenty of enjoyment. Same goes for things from eBay and Amazon. I have broken into £10 devices and £310 devices, so take your pick! It’s fun, you get your hands dirty, and IoT hacking is a skill that will be in ever greater demand in the next decade.
So, for the past two years I have been studying for a Masters in Cybersecurity part time, and thankfully managed to pass with a Distinction. Yay! It’s an itch that I’ve been wanting to scratch for a good long while, and I’m glad to have done it.
This leads me on to my next announcement. I’m going to be studying for a PhD in IoT Security part time, alongside my current work commitments. A couple of people have asked me why I’m doing it, so I thought I’d lay out my reasons here:
It sounds like fun! Seriously; I’m a bit of a nerd with this stuff, and the ability to really dig down into the weeds of a topic is really appealing!
I want to discover something new! The thesis has to show originality, and again that appeals. I’m not expecting to discover gravitational waves, or evolution, but having a little bit of the tree of knowledge that I found first is a really cool thought.
I think I’ll be good at it! Having had a 20 year break between undergraduate and Masters study, I wasn’t sure what to expect, but thankfully I managed to pick things up pretty quickly. Speaking to my now supervisor and putting together a proposal, it seems that I have the ability to do this, and that others agree.
I want to be Doctor Allen! Maybe it’s an ego thing, but I like the idea of knowing I can use that title. I’m not going to, but it’s a cool thing, and it’s a validation. So yeah, Dr. Ash!
I’m not doing this for career progression; there are much shorter and cheaper ways of getting qualifications that employers want. I also don’t want to transfer to academia full time – I’ve seen enough to know that I’m happy in my current little niche! So, that’s the announcement. Let’s see what the next six (!) years bring…
The Fortessa FTBTLD smart lock is a fairly bog-standard type of generic smart lock, sold in the UK by CEF for around £100, and available on auction sites for maybe 3/4 of that price.
Fortessa FTBTLD smart lock showing the default device name
As can be seen on the sticker on the left hand portion of the lock above, it is configured with a default device name. The lock offers a variety of features, such as auto-locking, key sharing, and so on, and in the main they work pretty well. It’s never going to win any beauty awards, and the app interface is pretty basic, but in the main it does what it sets out to do. Unfortunately, however, there is an issue with the lock allowing unauthorized updates to config parameters that mean it should not be used anywhere outside of the lab.
The tool of choice for this investigation is HomePwn, an IoT testing suite developed by a group of Spanish researchers. It provides a similar interface to Metasploit, and is able to work with a number of different protocols such as BLE and RFID which means less switching between tools.
HomePwn splash screen
Loading up the Bluetooth Low Energy discovery tool, we can see that amongst a bunch of other devices, our Fortessa lock is detected (2nd from the bottom):
Locally detected BLE devices
We can then look to run the read-characteristics tool, with the various options laid out like so:
ble/read-characteristics options
We can then use the discovered MAC address of the lock, and the local BLE adapter, like so:
ble/read-characteristics configuration
Running the command then returns the following (abbreviated):
Fortessa lock name
Note that at this time we have not had to authenticate, and that is correct; the companion app needs to be able to read these fields. However, this particular service is set to READ WRITE. In general, again, this is not necessarily an issue; it may be perfectly reasonable for an unauthenticated user to write to a particular BLE service. In this case, though, the lock name is likely something that we would not want just anyone updating. Unfortunately, that is how the devices is configured. Using the ble/write-characteristics plugin, we can update the lock name without authentication, like so:
Updating the lock name
Checking again with the ble/read-characteristics plugin, we can see that the device name has been updated:
Updated lock name
It should be noted that you don’t need to use HomePwn to do this; something like the nRF Connect app will let you do this from your phone.
So, what’s the big deal? Your neighbor may be able to give your door lock an obscene name, but this can’t do any damage, right? Right?
Well…
Once the lock name is updated, the app refuses to connect, as seen below:
Fortessa app fails to connect
In fact, it will refuse to connect until the power to the lock is cycled by removing the batteries. If you are locked outside of your house, because the battery compartment is on the inside, you can see the issue! I have reached out to the distributor and manufacturer with this finding, but have had nothing back. Whether this can be patched in a firmware update, I can’t say. It seems like something that would be pretty easy to fix, but who knows. For the moment, though, if you have a Fortessa lock, remember to take your keys with you as well…
In a previous post I discussed the Bluetooth pairing issue that means anyone with a sniffer and access to your lock can open it. However, this is not the most concerning aspect of the device. I’m a big fan of static analysis tools, and use a few when investigating IoT devices; they generally provide useful starting points for further investigation, and so it proved here. In this instance, MobSF produced a report that pointed at a couple of insecure Firebase databases (I’ve redacted some of the information below to casual readers from investigating further; of course, it is perfectly possible to recreate exactly what I have done. I have tried reaching out to the manufacturer on a number of occasions regarding this and the Bluetooth issue but have had no response).
eGeeTouch Firebase Databases
Digging down into the data returned from the URL, I had the (mis)fortune of finding my own details, captured as I tested the lock (redacted, although of course the above applies).
The author’s information
The information captured includes the GPS coordinates and approximate address of where the lock was accessed, the time of access, the email address of the user, and whether the device was locked or unlocked. Nowhere in the EULA is it stated that this information will be collected. Aside from why this information is stored at all (I’m assuming some sort of audit trail), it is clear that this represents a severe privacy intrusion. Not only is the device collecting personally identifiable information (PII) about the user, but it is storing it in a location that can be accessed without requiring any authentication. PII, of course, is subject to GDPR regulation in the UK and other, similar restrictions elsewhere in the world. This would seem to be, then, a significant concern for anyone tempted to buy the lock.
IoT security devices, such as smart padlocks, need to perform at least as well as their non-smart counterparts if consumer trust is to be gained. Unfortunately, many such devices are fundamentally flawed, with poor design meaning they are simple to subvert. Once such device is the eGeeTouch 3rd Generation Travel Padlock.
The eGeeTouch 3rd Generation Travel Padlock
Available in the UK for £19.90 from Amazon, the lock boasts a number of features, including Bluetooth operation via the companion smartphone app, RFID tag support, and a TSA manual override. So far, so good. However, digging deeper, it is clear that the device should be used with extreme caution. Access to the device is handled via a password set in the app:
eGeeTouch app – password management screen
This password is required when initially pairing the lock with the app; without that the two can’t talk to each other. Setting the password to 080379, we can then look to see how the lock communicates with the app, and vice versa. To do so, we can use btlejack, a Python tool that leverages the Bluetooth LE chipset in the BBC micro:bit development board to hijack the connection and dump the output to a Wireshark format dump file (download it here). Looking at output from a successfully captured session, we can see the following in packet 78:
Authentication capture
The capture indicates a write to the 0xfff8 attribute of the letter a plus our secret code, 080379. The lock then replies with a range of other information, for example the Model Number in packet 89 :
eGeeTouch model number
and the firmware revision in packet 92:
eGeeTouch Firmware
Triggering an unlock event via the app sends the following (packet 95):
Unlock event
whilst a lock event sends the following (packet 101):
Lock event
It seems clear therefore that the operation of the lock, at least via the companion app, is controlled by these three commands; an initial authentication, followed by the relevant lock or unlock code. All three use the “secret” code that was set in the app. How much access can we get knowing that?
The app is currently logged in using the following account:
User account
Let’s then log out and try signing up with a brand new account:
Attacker account
Logging in, we can see that no devices are currently registered:
No devices registered
Clicking the Add Lock button brings up the following:
Lock choice screen
Select the correct device and we are asked for the pairing password. Enter that and:
Success!
The user now has full admin rights over the lock, including, crucially, the ability to change the pairing password and so lock the legitimate owner out. No notification is provided to the original user that their password has been used on another account, so they are none the wiser that the lock is compromised.
The exploit relies on the attacker having the ability to capture the data flowing between the device and the companion app. There are a number of different ways of doing this in addition to the btlejack method; for example, the image below identifies the same back and forward communication as in the PCAP, though in this case it was captured using the Gattacker tool:
Gattacker output
The attack does require a small amount of contact with the device, amounting to a push of the power button on the side of the lock. In a busy environment such as a railway station or airport it is not an impossible obstacle to surmount. In short, the eGeeTouch Travel Padlock should be passed over if you are looking for a reliably secure device.
I will be returning to this lock in a later post, as there are a number of other serious issues that greatly impact its desirability as a consumer product.
