[jira] [Closed] (GUACAMOLE-2291) TOFU for RDP certificates not persisted when running guacd in Docker in its default config

["Nick Couchman (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GUACAMOLE-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Couchman closed GUACAMOLE-2291.
------------------------------------
    Resolution: Implemented

Thanks [~pv2b] !

> 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: Improvement
>          Components: Documentation
>            Reporter: Per von Zweigbergk
>            Priority: Major
>
> 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)