Please add user authorization to xmlapi usage

[psytester]

At least the xmlapi/exec.cgi is really dangerous, since its allows uncontrolled execution of code from non authorized users nor any blocking by build-in "Firewall":

Firewall-Richtlinie:
Zugriffseinstellungen der Ports: Ports blockiert
Homematic XML-RPC API: Kein Zugriff
Remote Homematic-Script API: Kein Zugriff
Mediola-Zugriff: Kein Zugriff
Port-Freigabe: Keine Einträge in der Liste
IP-Adressen für den eingeschränkten Zugriff: Keine Einträge in der Liste

You may get in touch with jens maus about some more details which are not for public here.

[psytester]

Hello,
I don't want to stress you. Really! I know its a hobby project and no business behind.
But are you planing to secure the AddOn somehow in the next weeks?

I will follow the guidlines of well known vulnerability disclosure policies.
That means after 45 days of really no feedback (16 days left) or a fix is provided (maybe this takes more time than 45 days) I will publish some CVE-2019-xxxx.
One is for the XML-API AddOn and another one for the CUxD AddOn (for sure not in your responsibility).
The combination of them (and some more in pipeline) makes it really bad for the CCU owner but nice for the attacker.

I don't know, but hopefully you will be contacted from eQ-3 side in the next few days with same request and maybe some details, because of some tumult behind the scene I have triggered.

@uwe111 Uwe Langhammer: Same issue for the CUxD as stated in CUxD issue 22. Since you have switched of the issue tracker of CUxD in Github, I hope you are getting this info due to watching this repository, too.

I'm not the bad guy, just someone who points to security issues!

[jens-maus]

@psytester Of course you are not the bad guy. But you overestimate the importance of this add-on as well as CUxD. Both are third-party addons not developed by eQ3. And especially this XML-API Add-on is an open source project which eQ3 has no control of. Feel free to publish your CVEs, but the time would probably better invested in actually contributing to actually close these security issues. So please don't get me wrong. I am all for closing these security issues, but IMHO you should better invest your time in proposing a fix for them rather than writing any CVEs.

[psytester]

In a first step the AddOn(s) should be integrated into existing user session management.
Only valid and logged in users are allowed to use them. In some more detail, I would prefer to deny the Guest or User Level at all, only the Admin Level can use the "special" functions here. User level accounts should be restriced to read out something only, but not starting/executing something or changing any device state or internal script to switch it off.

Overestimating is relative.
How many users have installed one of both AddOns?
How many users have setup a CCU based alarm system or just controlling or automating something or have a Keymatic on the front door?
How many users want to be hacked? One, two, ten or 90% saying no matter, I'm safe?
Who wants to be a volunteer for an example? Me not!

[ultrah]

This has been discussed multiple times, with the common agreement being that the CCU should not be treated as secure environment anyway and the network it is in should be secured instead as much as reasonably possible. Obviously this is far from perfect, but this is what he have.

In any case, as Jens has mentioned, adding authorization to a CCU addon is a lot of work and understabely no one has stepped up to do it for free on a small open source project like this.

Are you up for it?

[jens-maus]

@psytester It is clear and already known and had been already discussed that a security improvement would be great. So please step forward and implement it! This is an open source project, so everyone is invited (and requested!) to contribute what he sees fit.

[psytester]

For sure, if I would know how TCL scripting works, how to use in own AddOns the given internal eQ-3 scripts like session.tcl, verifysid.cgi and login.cgi to add a login possibility, session creation & check and finally an user level check with if {[session_requestisvalid 8] > 0} then {.... it's really easy.
But I never used TCL and I don't know the overall internal design. It's a blackbox, I can find and point to issues only.

[psytester]

Seen in RaspberryMatic issue 332 jens-maus/RaspberryMatic/issues/332

Mit den Methoden die es in der 3.41.x gibt können CUxD, XMLAPI usw. nun entsprechende Methoden einbauen damit deren Webseiten auch via authentifizierung abgesichert werden. Das müssen aber momentan die Addon Entwickler selbstständig tun denn RaspberryMatic/CCU kann ja nicht wissen ob das erwünscht ist oder nicht.

This is what I would expect, the core CCU part is providing some methods which can be used by AddOn developers.

[uwe111]

@psytester
CUxD has web authentification already implemented since the beginning.
I'm still waiting for a response to my email that I send to you last week.

[jens-maus]

@uwe111 Uwe, du könntest natürlich nun prinzipiell trotzdem den seit der 3.41.x Version existierenden ReGa Web Authentification Port (UDP 1998 via 127.0.0.1) nutzen und darüber die Nutzer-Authentifizierung durchführen statt eine separate web authentifizierung mit eignem nutzername+passwort nur für CUxD vorzuhalten. Kann ich dir gerne in einer privaten Email zukommen lassen die Infos wenn du Interesse hast.

[psytester]

@uwe111
I checked my e-mail account, there is nothing in inbox nor probably spam folder from you.

What I mean it the access to internal devices usage. This needs to be protected with an user session, especially CUxD.CUX2801001:1.CMD_EXEC

If you mean the Basic Authentication provided by INI property USERLOGIN=Username:PassWord_In_Plain_Text
it is not forced nor set by default during installation, the PW is in readable plain text and new AddOn users are not aware of securing they GUI access at this point. And finally it protects the web interface / GUI only. :-(

I belive at least 70% are using the same user / password combination for CCU WebUI and CUxD UI access and since the /usr/local/addons/cuxd/cuxd.ini contains the access data in plain text, this is a new attack vector. "Thank you".

I'm really not the penetration tester expert, but I can combine (simple) attack vectors and finally the system is under full control.
But for sure 90% of the issues are at eQ-3 side ;-)

[uwe111]

@jens-maus
Ja, da hätte ich Interesse und würde mir das gerne mal ansehen.

@psytester
Well, I don't know how you want to protect xmlrpc/binrpc by user sessions. Just because you always mention CUxD.CUX2801001:1.CMD_EXEC. But of course you can configure, which IP address in your network has access to the RPC port of your CCU.

For the CUxD UI access I'm already working on a simpler solution.

Besides that, you can easily avoid your "attack vectors" if you put your CCU in a secured network with controlled access rules only. That also means no direct port forwarding to the Internet. I think that's the best solution.

[psytester]

That also means no direct port forwarding to the Internet. I think that's the best solution.

It's not me, who needs to be protected. Two weeks before there were more than 10000 systems listed to be accessible via port forwarding. Today it's "only" 8470 on shodan.io
Insecure local WLAN without guest seperation are not included on that search engine.
It's a mix of technical non-experienced users, gullibility, innocence meet Firmware with default "Auto Login" feature, no GUI Password enforcement, outdated software, .....

CUxD.CUX2801001:1.CMD_EXEC is the promoted replacement of non-documented but known ReGaHss internal system.Exec()

How to remotly access the CCU / OCCU I can not write here publicly. I can give you details on a private channel or get in contact with Jens Maus, he got those details already 3 weeks before.
A disclosure of all new identified or already known attacks and they combination will come in some weeks. Hopefully after fixes were offered.

That a lot of users are not updating they systems, is another bad story :-(

[uwe111]

@psytester
Since my email didn't reach you, can you please send your details to me with email?
My address you'll find on the first page of the CUxD documentation.

[uwe111]

@jens-maus

@uwe111 Uwe, du könntest natürlich nun prinzipiell trotzdem den seit der 3.41.x Version existierenden ReGa Web Authentification Port (UDP 1998 via 127.0.0.1) nutzen und darüber die Nutzer-Authentifizierung durchführen statt eine separate web authentifizierung mit eignem nutzername+passwort nur für CUxD vorzuhalten. Kann ich dir gerne in einer privaten Email zukommen lassen die Infos wenn du Interesse hast.

Jens, lässt Du mir das bitte noch per Email zukommen?

[hobbyquaker]

Someone willing to host this repository under his Github account? I would like to get rid of it. I don't use it, I don't like it, I will not do anything for it in future. So volunteers please, would like to move it asap! :-)

[hobbyquaker]

@uwe111 here is a javascript implementation of authentication against the Rega: https://github.com/rdmtc/RedMatic/blob/master/addon_files/redmatic/lib/rega-auth.js

[jens-maus]

@hobbyquaker Feel free to move the repository to my account ;)

[hobbyquaker]

transfer request created.

[psytester]

Just for traceability only, this issue was published last year as CVE-2019-14984

[Michael-K-at-GitHub]

(I know this issue is old, but it is still open, so...)

Adding mandatory authentication would break many third party solutions, some of them out of active development. If you consider this issue, please make authentication at least optional.

[jens-maus]

This has been implemented into XML-API v2 now. Thus, closing.