SSH Communications Security Addresses a User Impersonation Vulnerability in PrivX (CVE-2024-47857)

 

 

Summary

PrivX versions between 18.0-36.0 implement insufficient validation on public key signatures when using native SSH connections via a proxy port. This allows an existing PrivX "account A" to impersonate another existing PrivX "account B" and gain access to SSH target hosts to which the "account B" has access. 

The vulnerability was discovered via an internal code review process, and we are not aware of public exploitation of this vulnerability.  

The CVE score is 5.5 Medium. The attack complexity is high and requires knowledge of the Secure Shell protocol and on how PrivX is implemented.  

Impact Analysis

An impersonation attack exploiting this vulnerability would require the following conditions: 

• The attacker is PrivX user A or possesses a private key that is registered as an authorized key for PrivX user A 
• The attacker can connect to ssh-mitm through the proxy port (1080) using either the HTTP connect or SOCKS5/4a protocol
• The attacker has knowledge of a public key that is registered as an authorized key for PrivX user B
• The attacker has an ssh client and has specific knowledge 

All of the conditions listed above need to be met for the attack to be possible. If successful, the attacker is able to connect to the ssh-mitm bastion as PrivX user B and through ssh-mitm to access targets available to PrivX user B.  

 

The vulnerability is fixed in PrivX versions 35.3 and 36.1, 37.0 and later. We recommend you upgrade your PrivX to a fixed version as soon as possible.
 

FAQ

  
I cannot upgrade PrivX right now, are there any mitigations available for this vulnerability? 

We recommend you upgrade PrivX as soon as possible. But if you do not use the feature of connecting with native ssh client via ProxyCommand, you can block the proxy port 1080 on PrivX nodes.  
 
Are SSH web client based connections affected? 

No, this vulnerability affects only native SSH connections via a proxy port.  Native SSH client connections that do not use ProxyCommand are also unaffected.