[Feature Request] - Ability to disable agent auto-update on the agent side
I've been evaluating PatchMon for wider deployment and so far I'm very impressed, exactly what I've been looking for!
However, there's one concern I have that's preventing me from deploying it in a production setting. With the current implementation, agents can auto update by pulling an updated binary from the PatchMon server. This behaviour can only be disabled within the PatchMon web interface itself.
My concern is what could happen if the PatchMon server were to be compromised. A malicious actor could replace the agent binaries on the PatchMon server with compromised versions and the agents will happily pull them when they next try to auto update. It also appears as though the agents run as root giving these theoretically compromised agent binaries complete control over the machine. The current method of disabling agent auto updates wouldn't help as the attacker could simply re-enable it since they have full control over the PatchMon server.
What I'd like to see would be a way to disable the agent auto update feature directly from the agents themselves (such as through the agent config file and ideally it would be possible to configure as part of the initial agent install process). With this enabled, the "Agent Auto Update" option in the UI would simply be greyed out for these hosts, possibly with wording such as "Disabled".
This would eliminate the risk described in my theoretical situation where the PatchMon server were to be compromised. Of course this now means that the agents would need to be manually updated on all hosts, but that's an inconvenience I'd happily live with in a security critical environment.
Then, as a quick second idea/suggestion that could potentially also help in such a theoretical compromise situation - How about the agent checks the hash of the update binary against the hashes on GitHub directly instead of using a hash provided by the PatchMon server? That way, if the binaries were to be replaced on the PatchMon server, the hash mismatch between the received binary and the "true" hash from GitHub would identify this.
Thanks,
Cameron
3 Comments
I was going to create a similar issue regarding the 'agent update attack vector' but it seems more appropriate to add my thoughts here to contribute to one cohesive plan.
Afaik Patchmon only updates agents after the main hub is updated, which is good and should be kept as it prevents agents automatically updating to a rogue version on their own. Together with the proposed flag on the agent itself to disable updates/reject update requests this seems as safe as we can go to me. Users should then be instructed to only update Patchmon hub when they trust the new version (possibly with a few days wait). The UI should also have an additional note to indicate that agents are never updated unless you update the hub/server.
All the recent supply chain attacks (axios, trivy) have made me re-evaluate my entire stack to identify any spots where code may automatically pull a new version without my intervention and to make sure to notify maintainers about the possiblity of rogue images/supply chain attacks.
Sidenote: agree on the choice for Websockets and no open ports, thats also one of my points for other repos.
Hi Cameron.
Both of your points are totally valid. I feel like I can implement a way to change the auto-update behaviour where it's not going to be influenced by the server and that it can only be initiated from the client side.
One setting we have implemented in the upcoming 1.4.0 release is to have an "ssh-via-proxy" parameter which can only be enabled from the client . This is for the feature of being able to use the websocket connection to actually ssh into the server via the agent. You'll see this in the new update but it requires a manual setting to be entered in the config.yml file which cannot be initiated (or entered) by PatchMon server alone.
So we can implement some logic around this sort of idea for the agents too. I need to see where I would fit and loop it in exactly as there would need to be some modification on the way the GO agent does its checks.
In relation to the hash comparison idea, yes this needs to happen for sure as part of checks. In 1.4.0 we are discontinuing with this Repo and moved it to the main repo instead so things are central)
I will keep these two points in mind but I am going to treat them as a priority because it's something I've thought about before as well.
PatchMon being compromised is always something we as a community need to be very conious of and as a starting point I ensured we don't need to open up any ports on the monitored hosts.
This also reminds me of an earlier issue that was raised in relation to having the option to disable websocket persistent connection, and in the same light of this it needs to be done.
Thank you for raising this.
I'm going to keep this open ...
This is the case where we have a two layered agent update system.
Thank you