Vulnerability Details : CVE-2020-3442

The DuoConnect client enables users to establish SSH connections to hosts protected by a DNG instance. When a user initiates an SSH connection to a DNG-protected host for the first time using DuoConnect, the user’s browser is opened to a login screen in order to complete authentication determined by the contents of the '-relay' argument. If the ‘-relay’ is set to a URL beginning with "http://", then the browser will initially attempt to load the URL over an insecure HTTP connection, before being immediately redirected to HTTPS (in addition to standard redirect mechanisms, the DNG uses HTTP Strict Transport Security headers to enforce this). After successfully authenticating to a DNG, DuoConnect stores an authentication token in a local system cache, so users do not have to complete this browser-based authentication workflow for every subsequent SSH connection. These tokens are valid for a configurable period of time, which defaults to 8 hours. If a user running DuoConnect already has a valid token, then instead of opening a web browser, DuoConnect directly contacts the DNG, again using the configured '-relay' value, and sends this token, as well as the intended SSH server hostname and port numbers. If the '-relay' argument begins with "http://", then this request will be sent over an insecure connection, and could be exposed to an attacker who is sniffing the traffic on the same network. The DNG authentication tokens that may be exposed during SSH relay may be used to gain network-level access to the servers and ports protected by that given relay host. The DNG provides network-level access only to the protected SSH servers. It does not interact with the independent SSH authentication and encryption. An attacker cannot use a stolen token on its own to authenticate against a DNG-protected SSH server.