Full control over local MQTT server

[EHylands]

Hi @xaf ,
I made the switch to Home Assistant !
I found a way to get full access to local MQTT server running on panel port 8333.
Basically C4 type notifications, Disarm video snapshot, zwave, automations ....
I'm new to mqtt so can't make sense of everything yet.
Let me know if you would like for us to work on this !

PanelEvent 0 b'{"event":"ARMING","arming_type":"DISARM","partition_id":0,"version":1,"requestID":"5d9df298-0ac0-4e74-adb7-f8dc7e5321e8"}'

mastermeid 0 b'{"eventName":"disarmVideo","remotePanelDisarmVideo":"AAAAGGZ0eXBtcDQyAAAAAGlzb21tcDQyAAADJW1vb3YA....

mastermeid 0 b'{"eventName":"ipcCall","ipcServiceName":"zwaveservice","ipcInterfaceName":"zwaveservice","ipcTransactionID":14,"ipcRequest":[{"dataType":"int","dataValue":2},{"dataType":"int","dataValue":106},{"dataType":"int","dataValue":1}....

[xaf]

Hi @EHylands !

I'd completely be interested in knowing how you accessed it and how complicated it was to set that up! (IIRC the issue we were having is that it was using certificates for encryption ?)
Does it also require the C4 setup we're doing today?

It seems that we might be able to access extra information we don't have today, which would allow to improve a lot qolsysgw! I'm wondering what other information you've seen (battery levels for instance ?)

[EHylands]

Since C4 integration is limited and closed with dealer's code requirement, my starting point was to create a virtual IQ Remote device that would pair to panel and gain full control over all accessories as a normal IQ Remote does.

When pairing a physical IQ Remote to the IQ Pannel, the pairing process is the panel and remote exchanging MAC addresses and doing the pki exchange to create a self signed client certificate for the TLS MQTT server on port 8883.

To my understanding, pairing a IQ Remote only needs an installer code rather than full dealer code ?

I'm only at the stage of seeing the MQTT traffic. I don't yet know if commands need to be sent as publications on the mqtt brooker to fully complete the pairing process.

I had trouble seing iq remote traffic on my network router through tcpdump, I am wondering if another command channel is established at unix socket level with MAC addresses.

Will report as soon as I have more info!

[xaf]

This is a pretty neat approach! We would then get full access to the panel the same way a remote panel accesses the main one, this is great! It also does not seem that complicated to implement, but might depend on the libs we can load in appdaemon (specifically for pki and certificate handling)

I'm wondering also if there's extra risks of qolsys changing protocols on us and locking us out in a future update?

[mzac]

This is a pretty neat approach! We would then get full access to the panel the same way a remote panel accesses the main one, this is great! It also does not seem that complicated to implement, but might depend on the libs we can load in appdaemon (specifically for pki and certificate handling)

I'm wondering also if there's extra risks of qolsys changing protocols on us and locking us out in a future update?

Yeah I was thinking about certificates too. If that is the case then the private keys for the remote are stored on the remote and might not be accessable so unless someone hacks into the firmware and extracts the code on the initial handshake and is able to re-produce it, this might not work.

[EHylands]

I tested it:
Remote creates a private key and CSR (certificate signing request) with that key.

While actively pairing remote to panel, remote sends CSR to panel.

Panel answers back with client signed certificate and web server certificate.

Certificate exchange only possible when panel is in active pairing mode to prevent unauthorized access.

Remote can use client signed certificate to connect to tls 1.2 mqtt server on panel port 8883

Self signed pki is on panel.

[EHylands]

@mzac Funny, it's your comment from 5 years ago that put me on track yesterday! I had and established tls connection to port 8883 but didn't know what the panel was expecting !

[xaf]

This is great it's not a static CA but a challenge in terms of security - otherwise it would mean any remote can connect to any panel.

But appdaemon havubg limited capabilities in terms of embedded python packages might make it slightly more challenging. We can see how it goes but worst case qolsysgw could also become its own container...

[EHylands]

This is my first real python project. Learning asyncio basics because pairing process involves sequentially using mDNS, SSL socket the mqtt client.

Currently writing a small controller automatically pairing with panel and establishing mqtt control.

Doing some nice progress in pairing and syncing fake remote to panel !

[xaf]

Are you able to share the process you have so far?
If you can provide your code and/or the detailed process to establish, I could start looking at it too! My time is pretty limited these days, but I could start working on adding support for a second qolsys backend in qolsysgw following the process you got there, and see if there's any dependency that we might require in AppDaemon that are not available for now.

[EHylands]

My IQ2+ panel chose this exact moment to die on me (screen has been flickering for a few months ...) !!
A new IQ4 panel is on the way.

I still have to iron out the key exchange protocol.
There may be a caching mechanism only allowing 1 private key / signed certificate per IQ remote based on mac address.
I want to find out if the network mac address check is stricly enforced by the panel or only based on the value submitted by IQ remote in the key exchange process.

As of now, I was able to gain MQTT protocol dump and send commands for the following actions

1- IQ remote pairing process with panel
2- IQ remote ping event to panel
3- Panel database sync with IQ remote
4- List Zones description and states
5- List Partitions descriptions
6- List zwave thermostats, switches and outlets descriptions and states
7- List other zwave devices description and states
8- Get panels updates for zones and partitions event (mostly like C4 interface)
9- Send partition arming commands
10- Send zwave ip commands to devices
11- Partition chime event
12- Disarm photos event

Will report back !

[xaf]

No code / howto to share for now to get all these?

[EHylands]

I've made significant progress with the code and documentation.
I still need to purchase Z-Wave devices to fully understand the raw Z-Wave device management process and the abstraction layers for thermostats, lights, and locks.

Qolsys - RemotePlugin: Configuring Plugin
Qolsys - RemotePlugin: Found Pairing Data
Qolsys - RemotePlugin: Using PluginMac f2:16:3e:08:81:a7
Qolsys - RemotePlugin: Panel is Paired
Qolsys - RemotePlugin: Starting Plugin Operation
Qolsys - RemotePlugin: Checking PKI
Qolsys - PKI: Found KEY
Qolsys - PKI: Found CER
Qolsys - PKI: Found CSR
Qolsys - PKI: Found Signed Client Certificate
Qolsys - RemotePlugin - MQTT: Connecting ...
Qolsys - RemotePlugin - MQTT: Client Connected
Qolsys - RemotePlugin - MQTT: Sending connect command
Qolsys - RemotePlugin - MQTT: Sending pingevent command
Qolsys - RemotePlugin - MQTT: Sending timeSync command
Qolsys - RemotePlugin - MQTT: Sending acStatus command
Qolsys - RemotePlugin - MQTT: Sending syncdatabase command
Qolsys - RemotePlugin - MQTT: Sending dealerLogo command
Qolsys - RemotePlugin - MQTT: Sending pair_status_request command
Qolsys - RemotePlugin - MQTT: Updating State from syncdatabase
Qolsys - State: *** Information ***
Qolsys - State: Partition0 (partition1) - ARM_AWAY
Qolsys - State: Zone1 (Panel Motion) - Closed
Qolsys - State: Zone2 (Panel Glass Break) - Open
Qolsys - State: Zone3 (iPhone Eric) - Closed
Qolsys - State: Zone4 (IQ Remote 1) - Open
Qolsys - State: Z-Wave1 (Light) - Light
Qolsys - State: Z-Wave2 (Front Door) - Door Lock
Qolsys - State: Z-Wave3 (Thermostat) - Thermostat
Qolsys - RemotePlugin - MQTT: Sending ui_delay command
Qolsys - RemotePlugin - MQTT: Sending disarm command
Qolsys - State: Partition0 (partition1) - DISARM

However, there's a potential concern:

At boot time, IQ Remote devices download a local copy of user PIN code hashes.
When an IQ Remote attempts to disarm the system or securely arm a partition, it is expected to verify the user PIN locally using its hash database. It then sends an unauthenticated MQTT command to the main panel.

Regarding the plugin I’m developing:

The installer code is required to pair the virtual device with the panel.

The plugin will download a signed client certificate and use it to connect to the panel’s local MQTT server.

Once connected, the virtual device can send disarm commands over MQTT without performing any PIN code verification.

Do you think this behavior would be considered a significant security vulnerability, or is this actually the intended design?

[gresrun]

@EHylands re: security vulnerabilities-- What is the threat model you're considering? At this point, the virtual remote would already be paired with the panel, which requires physical access to the system to initiate. If your library does the verification of the PIN, then you're doing exactly what the real remote would do and I'd say this is WAI.

Very interested in your work! Can you share your WIP code for us to read & understand the approach?

[EHylands]

@EHylands re: security vulnerabilities-- What is the threat model you're considering? At this point, the virtual remote would already be paired with the panel, which requires physical access to the system to initiate. If your library does the verification of the PIN, then you're doing exactly what the real remote would do and I'd say this is WAI.

Very interested in your work! Can you share your WIP code for us to read & understand the approach?

I did'n mentionned this previously.

Once you unpair the IQ Remote, the signed client certificate doesn’t get revoke on the main panel. Someone could pair a rogue virtual device with default installer code, download a signed client certificated and delete the rogue device from the paired devices list. With the signed client certificate the rogue device would keep full control without pin code validation and without showing any pariring state on the panel. Changing the default installer and dealer code ont the panel is the main mitigation solution.

I’m working on finding the custom pin code hashing scheme in the panel database to enable local pin code validation in the library. It looks to be a homemade md5 hashing and pseudo random salting (IMEI, MAC, … etc). Actively looking for the answer :P

I still have some rough edges to fix, but will publish WIP ASAP

[EHylands]

🚀 Demo Release Available
I’ve streamlined the pairing process and published a demo release of the MQTT plugin:

👉 [QolsysController on GitHub](https://github.com/EHylands/QolsysController)

If you have a Qolsys panel, please give it a try and let me know if the plugin successfully pairs with your system!

⚠️ Certificate Warning
During pairing, the main panel issues only one signed client certificate per virtual IQ Remote. If any key files are lost or deleted, re-pairing may become impossible.

Important:
Immediately back up the following files from the keys/ directory after initial pairing:

.key (private key)
.cer (certificate)
.csr (certificate signing request)
.secure (signed client certificate)
.qolsys (qolsys panel public certificate)

Store these files securely.