A vulnerability researcher and company from the red team Rapid7 recently discovered a a pair of security risk bugs in a digital home security product.
The first bug reported in May 2021, called CVE-2021-39276, means that an attacker who knows the email address against which you registered your product can effectively use it as a password to issue commands to the system, including spinning. the whole alarm is off.
The affected product comes from the company Fortress security shopwhich sells two branded home security settings, entry level S03 Wifi security system, which starts at $ 130, and more expensive S6 Titan 3G / 4G WiFi security systemstarting at $ 250.
The fearless researcher, Arvind Vishwakarma, acquired the S03 launch system, which includes a control panel, remote controls, a door or window sensor, a motion detector and an internal siren.
(The company also sells additional tricks and sensors, external sirens that are probably stronger, and motion-protected motion detectors that we assume are less sensitive than usual.)
Unfortunately, Vishwakarma didn’t have to compromise the system much and figure out how to control it without permission, both locally and remotely.
RESTfulness explained
Like many modern Internet of Things (IoT) products, Fortress Security products use cloud servers on the Internet for control and monitoring purposes, accessing the Fortress cloud through what is known in the jargon as the web API, abbreviated to application programming interface.
Like most modern web APIs, Fortress uses a programming style known as REST, short for representative state transferwhere the data is sent to the API via HTTP POST commands and extracted using GET commands using a set of static, well-defined URLs that act programmatically as web-based “function calls.”
In the old days, web APIs often embedded the data they wanted to send and receive into the URL itself, along with all the necessary data, including passwords or authentication tokens, attached at the end as parameters such as this:
GET /functions/status?id=username&password=W3XXgh889&req=activate&value=1 HTTP/1.1 Host: example.com
However, creating a unique URL is a concern for servers each time and tends to leak sensitive data into logs, as URL access history is often stored for troubleshooting or other purposes and therefore specific code encoding should be avoided. for the query data.
(Firewalls and security-friendly web servers do their best to edit sensitive information from URLs before registering them, but it’s best to have no confidential data in the URL at all.)
RESTful API, as they are commonly called, use a sequential list of URLs to trigger specific functions, and usually package their uploaded and downloaded parameters in the body of the HTTP request itself, thus keeping the URLs free of potentially confidential data.
For example, if you use Sophos Intelix (free accounts available!) to search for live threats, you must first verify with your username and password, which gives you a password for a session called access_token which runs for the next 60 minutes.
There is only one RESTful authentication URL and your username and password (Intelix only accepts HTTPS requests to ensure that data is shared securely) is sent to the request, for example:
POST https://api.labs.sophos.com/oauth2/token HTTP/1.1 Host: api.labs.sophos.com Authorization: [REDACTED - username and password supplied here] Content-Type: application/x-www-form-urlencoded', Connection: close grant_type=client_credentials
The Fortress API works in a similar way, but Vishwakarma quickly discovered that it didn’t need to go through a front-end authentication stage.
Instead, he was able to send a request as follows:
POST https://fortress.[REDACTED].com/api? HTTP/1.1
Host: fortress.[REDACTED].com/api?
Content-Type: application/json
Connection: close
{ cmd=GETINFO [...], user_name="XXXXXX" }
Although it only supplies a user_name in the request, he received a response that contained a JSON string labeled IMEI, an acronym commonly used in the context of mobile phones and an abbreviation of international identity of mobile equipment.
Every phone, whether it has a SIM card or not, has an IMEI that is saved in the device by the manufacturer (dial the magic phone number *#06# to view yours), and mobile phone operators use it to track your physical device on the network and block stolen phones.
IMEI is considered harmful
Because the IMEI is unique to your device, it is strongly recommended that you do not disclose it to anyone else.
You certainly shouldn’t use your IMEI as if it were a username or public ID, and mobile apps in select online markets, such as Google Play and the Apple App Store, aren’t allowed to collect them because apps that capture IMEIs are considered malicious. default.
Although the entry-level home security product S03 does not accept a SIM card and only works over a Wi-Fi network, Fortress still seems to uniquely identify any digital code device that is IMEI-related.
(We assume that this is so that the S03 can share the source code with the more expensive S6 Titan product, which has a SIM card slot and therefore a built-in own IMEI.)
Unfortunately, this IMEI is used not only as a username, which in itself would be bad, but as a full-fledged password that can be used as a permanently validating token for future requests to Fortress web APIs.
In other words, just knowing your fortress user_name, Vishwakarma can acquire the IMEI of your device and then just knowing your IMEI, it can issue authenticated commands to your device, for example as follows:
POST https://fortress.[REDACTED].com/api? HTTP/1.1
Host: fortress.[REDACTED].com/api?
Content-Type: application/json
Connection: close
{ cmd=ACTIVATE [...], imei="KNOWNVALUE", op=0, user_name="XXXXXX" }
In the above command, the data element op seems to mean operand, the name that is usually given to the data provided to a computer function or machine code instruction. (In the assembly line code of an assembler such as ADD RAX,42, the values RAX and 42 are the operands.)
The zero given as an operand to the ACTIVATE command, as shown above, does exactly what you would expect: it turns off the alarm!
Of course, to find out KNOWNVALUE the IMEI / password for your account, the attacker must first know the values of XXXXXX.
Unfortunately, as Visvakarama realized, XXXXXX is simply your email address, or more precisely the email address you used to set up the system.
In short: I guess email address ==> get a permanent authentication code ==> deactivate the alarm remotely if desired.
Fobs also defeated
Vishwakarma also looked at the security of keychains (buttons on the remote control, such as the button that opens the garage door or unlocks your car) that come with the system.
Vishwakarma uses a funky but increasingly accessible setting known as SDR, short for software defined radio, a reprogrammable transmission and reception system that can be adapted to operate on a huge range of different frequencies and to emulate any different radio systems.
You’ll need to set up a high-end SDR to work with many high-frequency devices like Wi-Fi (5GHz and 2.4GHz), but a hardware key priced below $ 50 has enough performance to “listen” on 433MHz transmissions. the frequency band often used by remote control devices, such as keychains.
In theory, a properly configured SDR can reliably and easily record the exact radio signal emitted by a keychain when it locks or unlocks your car, garage, or home security system.
The same SDR can play an identical transmission later.
In that sense, the SDR works like a wax block or a bar of soap with an old-school key, where an attacker (or a private detective in a crime novel) could impress your key from the door today and then throw his own copy to use. tomorrow.
However, the digital keychain has one significant advantage over the traditional key, namely that it can “shift the shape” between each press of a button.
Using a cryptographic algorithm to change the actual data it transmits each time, similar to those ever-changing 2FA codes produced by mobile phone security applications, a well-designed keychain must be resistant to what is known as re-attack.
This type of dynamic code recalculation, usually based on a digital secret that is securely shared between the key fob and the control unit when the keychain is configured, means that the radio code recorded today will not be useful tomorrow or even after two minutes.
Unfortunately, as you probably already guessed, Vishwakarma found that Fortress S03’s fobers did not produce one-time codes each time they were pressed, but simply exploited the same thing over and over again, a vulnerability now called CVE-2021-39277.
In short: keep close to someone’s home ==> shoot the keychain transmission “alarm off” once ==> deactivate the alarm later if desired.
What to do?
According to Rapid7, Fortress decided not to respond to these errors by closing the report as early as May 2021, and did not object to the company’s proposed disclosure at the end of August 2021.
So it seems that the company is not planning any firmware update, whether for its control units or keychains, and therefore these vulnerabilities will not be patched, at least in units that have already been sold.
So, if you have one of these systems or a similar type of system under a different brand that you suspect may be obtained from the same original equipment supplier, you can use two workarounds:
- Use an email address that the attacker is unlikely to already know or guess. Webmail services like Outlook and Gmail, for example, allow you to have multiple email aliases for your primary account simply by adding text such as
+ABCDEFGat the end of the usual email name. For example, if you usenickname@example.comas a simple email address, then messages tonickname+uniqeuid@example.commust be delivered to the same mailbox, although the two addresses do not match. Note that this is an example of security through ambiguityso it’s not an ideal solution, but it makes things harder for an attacker or a bad-tempered friend or family member. - Avoid using the remote control at all. This means that you will always have to have your laptop or mobile phone on hand, or do everything directly from the control panel, but if you never set your keychains to work with your own control unit, they can’t reveal any secrets that the attacker could be used in subsequent re-attacks.
Call all encoders
Once again, as we seem to say so often when we talk about IoT security: if you’re a programmer, do not make shortcuts who you know will return to pursue both you and your customers.
As mentioned many times, device identifiers such as MAC addresses, UUIDs and IMEIs are not suitable as cryptographic secrets or passwordsso do not use them for this purpose.
And cryptographic material that you transmit or display unencrypted, whether it is a 2FA code from an authentication application, an initialization vector for an encrypted file, or a radio link from a key fob, should never be reused.
In cryptography, there is even a slang term for this type of data: it is known as nons, abbreviated from number used once, and that word means exactly what it says.