Per von Zweigbergk created GUACAMOLE-2291:
---------------------------------------------
Summary: TOFU for RDP certificates not persisted when running
guacd in Docker in its default config
Key: GUACAMOLE-2291
URL: https://issues.apache.org/jira/browse/GUACAMOLE-2291
Project: Guacamole
Issue Type: Bug
Components: guacamole-docker
Reporter: Per von Zweigbergk
I would like to bring to attention a potential security vulnerability in guacd,
when deployed in Docker in accordance with official instructions.
The [Installing Guacamole with
Docker|https://guacamole.apache.org/doc/gug/guacamole-docker.html] page
documents how to run guacd. To summarize, it expects you to run guacd and not
perform any mounts or attach any volumes, effectively treating guacd as a
stateless application.
Unfortunately, this isn’t exactly true when running guacd in an environment
that uses RDP connections and uses the cert-tofu option. In this mode, guacd
will perform TOFU (Trust On First Use) certificate validation when connecting
to the backend RDP server. It appears that this is stored as a flat file in the
path /home/guacd/.config/freerdp/known_hosts2 inside the Docker container. (It
is very similar in concept to the “known_hosts” file used by OpenSSH.) This
means that the file ends up only being stored inside of the container itself,
and it not persisted if the container is re-created.
The risk here is that, if the guacd container is re-deployed for any reason,
such as a software upgrade, either of guacd itself, or updating the container
image to update any dependencies, the known_hosts2 file will be non-existent or
empty, which means that there is an opportunity for a MITM attack to happen if
an attacker is in the position to redirect the connection to the back-end RDP
server. This could lead to compromise of user credentials, session hijacking,
session sniffing, etc.
There are a few possible approaches here:
# The Docker container documentation could be updated to support mounting
/home/guacd/.config/freerdp/known_hosts2 as a volume or similar, in order for
this to persist across container re-deployment.
# The known_hosts2 file could be backed up by guacamole-server and persisted
in the postgres database.
# Guacd running in the docker container, or an appropriate startup script,
could try to detect if the known_hosts2 is externally mounted or not (perhaps
by checking mtab), and throw up a warning or an error message if it’s not
connected to an external volume.
Since this is issue has security implications, including a MITM risk, I
initially raised this to the private security e-mail list, and I received the
following response from Nick Couchman:
{quote}Per,
Thanks for raising this issue with security implications privately to the
security@ list. We appreciate your following responsible disclosure practices
for this.
I definitely see your point, here, and agree that the documentation should be
updated to document the potential of mounting a FreeRDP known_hosts2 (and
possibly equivalent files for SSH) so that those known identities persist
across updates of containers. It may also be worth just putting some stronger
overall warnings on the TOFU method of certificate/identity trust. This isn't
necessarily a Guacamole-specific issue - any situation where you have the
potential to wipe out a known_hosts file and have to start from scratch
represents a risk that you'll end up connecting to a host that isn't the one
you think it is. It may be easier in a containerized environment as with guacd,
but certainly is not limited to it.
Finally, in order for an attacker to use this to compromise a system, they
would either have to time things just right, knowing the timing of a swap of
the container, they'd have to have some knowledge of the system(s) to which the
users are connecting, and they'd have to be able to effectively redirect the
guacd instance to a MITM system. Certainly these things are _possible_, it just
becomes very difficult to line up all the required pieces in a window without
raising suspicion and have several things fall perfectly into place.
Overall, I'd say it is safe to just open a Jira issue for the changes and then
open a pull request against the manual to update the dumentation.
-Nick
{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
