ABUS Secvest is a wireless alarm system that is marketed at consumers and small businesses. It is usually deployed by a specialised company. A Secvest FUAA50000 controller costs about EUR400. A typical deployment with motion sensors, a siren and door/window sensors can cost thousands of euros. In this article I will describe how more than 10.000 internet-connected alarm systems could be hacked and deactivated remotely.
ABUS has released a fixed version of the Secvest software, so if you use this system we recommend you install version V3.01.21 (or later). You will need ‘installer’ access to do so. If you did not install the system yourself, help from the company that installed the system may be required. As a temporary fix you could remove the port forward to port 4433 in your router. This would however prevent you from using the smartphone app or web interface to control the system.
The alarm system can be controlled via the alarm panel, web interface or via the Secvest app (iPhone or Android). To control the system via an app or web interface, the alarm system needs to be connected to the internet and a HTTPS port (4433 by default) needs to be forwarded to the system.
Based on this information, we did a quick investigation to see how popular the system is. For this we used publicly available HTTPS scans from Rapid7:
| Country | Count |
|---|---|
| Germany | 10.184 |
| Switzerland | 445 |
| Austria | 426 |
| Netherlands | 376 |
| Luxembourg | 89 |
| France | 37 |
| Belgium | 35 |
| Other | 87 |
| Total | 11.679 |
As you can see, the system is mostly used in German-speaking countries and the Benelux. According to ABUS, Secvest is the most widely sold wireless alarm system in Germany. Because we only surveyed the ports covered by the Rapid7 data, the actual number of exposed systems is probably a bit higher, due to people changing the default port.
Once in the app, you can see the status of your alarm system and turn it on and off.
I like the fact that this setup allows us to control the alarm system without the dependency of a cloud-based system. It does however create some risks: as the alarm system is connected to our IP address, it may allow criminals to survey interesting targets on the internet. Based on your IP address, in some cases they may be able to trace this information back to an actual location. This makes it an interesting target for criminals targeting high-end houses or businesses.
Security researchers at German security company SySS GmbH already did a good job looking at the wireless side of the system and found some issues, as described in this article and this video. I decided to look at the IP-based connectivity of the system and found some serious issues as well.
To authenticate to the web interface, you need a username and a 4-digit alarm PIN. In later firmware versions, the option of a 6-digit pin was added. There are three user levels: installer, admin and regular user. Once authenticated you can change the configuration, manage users or (de)activate the system, depending on your user role. Later firmware versions added a fourth user level for firmware updates. I would have preferred a separate password instead of reusing the PIN, as 4 digits could be brute forced in about five minutes. The panel does sound the alarm after too many failed attempts and the username would have to be guessed as well.
What I found is that although the HTTPS request to deactivate the system requires authentication, many other requests do not. For example the sec_about_panel.cgi script can be accessed without logging in, giving a summary of the system including the number of sensors, locks etc. The sec_virtkeypad_raster.bmp file gives an attacker a live view of the alarm system screen, allowing him to see the system name and if the alarm is on or off.
We can also run a test of the internal siren using a HTTP POST request, as seen in the following curl command:
curl -kv https://192.168.99.230:4433/<redacted> -d 'events={"panelTest_intSirensState":1}'
Luckily, we can also turn it off by changing the last ‘1’ to ‘0’, because the sound gets annoying very quickly. I did not buy an external siren but we could probably test that as well (waking up the entire neighbourhood in the process). Imagine an attacker ‘testing’ the sirens of 10.000 alarm systems, resulting in a lot of annoyed people (mostly Germans).
Even more serious, we can download a copy of the configuration of the alarm system, by requesting the file without any form of authentication. This hex-encoded binary file contains the usernames and passwords of all users, allowing us to authenticate to the web interface and fully control the alarm system. Below is an excerpt of a hexdump of my configuration file:
0000f870 03 13 37 ff 01 73 03 70 69 63 6f 62 65 6c 6c 6f |..7..s.picobello|
0000f880 62 76 00 01 74 c3 05 00 00 00 00 00 01 75 c3 01 |bv..t........u..|
0000f890 0f 01 76 02 00 01 00 09 45 02 01 01 01 00 00 d2 |..v.....E.......|
0000f8a0 05 02 01 01 00 02 72 c3 03 13 38 ff 01 73 03 31 |......r...8..s.1|
0000f8b0 33 33 38 00 01 74 c3 05 00 00 00 00 00 01 75 c3 |338..t........u.|
0000f8c0 01 0f 01 76 02 01 01 00 09 45 02 01 01 01 00 00 |...v.....E......|
0000f8d0 d2 05 02 02 01 00 02 72 c3 03 12 34 ff 01 73 03 |.......r...4..s.|
0000f8e0 61 64 6d 69 6e 00 01 74 c3 05 00 00 00 00 00 01 |admin..t........|
0000f8f0 75 c3 01 0f 01 76 02 01 01 00 09 45 02 01 01 01 |u....v.....E....|
0000f900 00 00 d2 05 02 03 01 00 02 72 c3 03 99 99 ff 01 |.........r......|
0000f910 73 03 6e 69 65 6c 73 00 01 74 c3 05 00 00 00 00 |s.niels..t......|
I have four users: picobellobv (the installer), 1338, admin and niels. The installer has a code of 1337, which can clearly be seen in the hex dump, at 6 bytes before the username. The codes for two other users (1338, 1234, and 9999) can also clearly be seen.
This is really the only vulnerability we need. By extracting the configuration file we can obtain all usernames and passwords and login to the system. We now have the same privileges as the owner (or installer) of the alarm system. An attacker can now reconfigure or deactivate the system, view the logs to establish a pattern-of-life or look for clues to find the physical location of the system (such as the owner's name, which installers often enter as the system name).
Also included in the configuration file are plain text passwords for connected systems. If a user has connected cameras to the system, we will be able to access the video feed using the passwords from the configuration file.
Also in the configuration file is the password for ‘ABUS Server’. This is a free dynamic DNS service provided by ABUS. As many providers don't provide users with dynamic IP addresses, ABUS offers this solution. Instead of configuring the Android/iOS app with a static IP address, the user can configure a DNS name, such as 'secvest.u12345.abus-server.com'. For an attacker, this creates interesting opportunities. By taking over the dynamic DNS, we can redirect the users to our own IP address and start manipulating information. We could for example tell the app that the alarm system is active, while in reality it is turned off. Also, if the user has cameras, we could manipulate the video stream. We can now record a bit of video and play it over and over, so for the end-user everything looks normal while we are breaking in.
At this time, about 10% of Secvest systems are running the latest version of the software. Which means that 90% of systems on the internet are running a version that is vulnerable.
Disclosure timeline:
2020-10-30: Contacted ABUS via web form, requesting a security contact.
2020-11-04: Received support email address for ABUS Security Centre. Sent email requesting security contact.
2020-11-06: Received contact details of Technical Director and sent advisory via email.
2020-11-08: ABUS confirms receipt of advisory.
2020-11-20: Eye asked via email if ABUS was able to reproduce the findings.
2020-11-20: ABUS confirms they were able to reproduce the findings and that the next release will include a fix.
2020-11-23: Eye requested CVE and sent the obtained CVE-number to ABUS.
2020-11-24: ABUS acknowledges receipt of CVE.
2020-12-16: Eye asks for an update, ABUS responds they expect to release a new firmware by mid-January.
2021-01-22: ABUS publishes software version V3.01.21, which fixes the reported vulnerability.
2021-04-20: Eye publishes this blogpost.
