upsmon: no notification for login error

[g-v-egidy]

I have a netclient ( MODE=netclient ) and configured upsmon.conf with the correct ups and servername, but a wrong username or password:

MONITOR ups@upsserver.internal 1 nutuser badpasswd slave

When I now start upsmon I get the expected login failure in syslog:

nut-monitor[3426]: Network UPS Tools upsmon 2.8.2.1
nut-monitor[3426]: Could not find PID file to see if previous upsmon instance is already running or not!
nut-monitor[3426]: UPS: ups@upsserver.internal (secondary) (power value 1)
nut-monitor[3426]: Using power down flag file /etc/killpower
nut-monitor[3427]: Login on UPS [ups@upsserver.internal] failed - got [ERR ACCESS-DENIED]

But I would expect to now see a UPS ups@upsserver.internal is unavailable message every NOCOMMWARNTIME seconds, with my notify script called and so on. But this doesn't happen at all, no unavaliable messages appear.

I also did a tcpdump to check what was transmitted over the connection to my upsd:

STARTTLS

ERR FEATURE-NOT-CONFIGURED

USERNAME nutuser

OK

PASSWORD badpasswd

OK

LOGIN ups

ERR ACCESS-DENIED

GET VAR ups ups.status

VAR ups ups.status "OL"

GET VAR ups ups.status

VAR ups ups.status "OL"

GET VAR ups ups.status

VAR ups ups.status "OL"

[...]

This looks like upsmon is still able to regularly get status information about the ups, even though the access was denied.

On the upsd side I have this in upsd.users:

[nutuser]
password = goodpasswd
upsmon slave

That upsd still gives upsmon information about the status of the ups, although the login was denied previously, looks to me like a problem too.

I'm using nut-2.8.2.1-0.el10_1.1.git20240703pr2505.x86_64 from Fedora EPEL for RHEL 10.1.

[jimklimov]

Cheers, thanks for the report. Although the current release is 2.8.5, this logic probably did not change in recent years.

This week I dug a lot into this as I was bringing up other client bindings into same shape as C one.

To clarify, from what I gather: providing the USERNAME and PASSWORD alone is not immediately consequential, as in that GET commands which are normally anonymous remain available. Credentials are checked in commands that need authorization (SET, INSTCMD). The LOGIN one also, as it sets up the SECONDARY level client monitoring of a device (will be waited for to disconnect in case of FSD) and the account needs to have an upsmon role. Then it can elevate with PRIMARY/MASTER to be the one who tells everyone to FSD.

As I worked in the client side recently, I am not sure that the data server even checks and recognizes a wrong credential before handling a command that needs it, as your sniff confirms. Maybe that is also a bug in itself, or a design feature maybe (not expose too easily that an attacker failed)?..

[g-v-egidy]

Thanks for looking into this.

The LOGIN one also, as it sets up the SECONDARY level client monitoring of a device (will be waited for to disconnect in case of FSD) and the account needs to have an upsmon role.

This is the immediate issue for me. I use a relatively early/short time for FSD, but then have set "SHUTDOWNEXIT no" on all the upsmon clients. I want the master to wait for all of them to finish their shutdown, which takes a few minutes.

In case of the login failure this doesn't happen for the affected client: I just verified this with upsc -c and the client with the wrong login doesn't show up there. upsmon should detect this problem and complain properly and loudly.

As I worked in the client side recently, I am not sure that the data server even checks and recognizes a wrong credential before handling a command that needs it, as your sniff confirms. Maybe that is also a bug in itself, or a design feature maybe (not expose too easily that an attacker failed)?..

It was also unexpected to me that upsd allows the "GET VAR" commands at all after a failed login. I would have expected that a successful login, at least at "slave" or "secondary" level, is required to get any variable information at all. I could not find it documented anywhere that most GET commands are anonymous, RFC 9271 contains this paragraph which I understand as being contrary to anonymous access:

 4.2.13. USERNAME

The Attachment Daemon limits access to clients whose credentials match those in the file upsd.users. 
There is no anonymous access. A Management Daemon program or script uses command USERNAME
and its companion command PASSWORD to open a session with the Attachment 

Regarding how to solve this issue - wouldn't changing all "GET" commands in upsd to require a successful login solve the whole issue, as upsmon would then never get a ups status and then complain about that?

[jimklimov]

That is a fair point, the RFC was based on NUT docs but then hammered to pass the RFC reviewers, in particular about security related stuff.

As it stands, I guess NUT is no longer fully compliant, now that the document has taken a step beyond the implementation.

In any case, various hardening is on the plate for future releases, an option (because least surprise to existing deployments) to drop anonymous access could be one of the points. For now, most non-RW stock clients lack even CLI options to know the login/password, and rely on R/O data being always readable. There is a similar issue #3329 that they lack options to set up SSL properly, but in the past couple of months the code base is getting closer to fixing that. Also #3359 tackles a similar area, which may also bring surprises to existing deployments when fixed.

[g-v-egidy]

Thanks for the explanation. I concur that solving these issues independently is the better approach.