Is it safe to use an untrusted server for an SSH jump?

Question

The question is a thought experiment.

Junior works in IT at Finsurance Corporation™. He works from home now, and has to VPN into work but hates it because they've blocked Gmail and Reddit. Junior discovers ssh -J but has a new problem: he's too cheap to set up his own jump. Googling around, he finds free to use SSH servers which could be used as jump hosts.

These servers might be run by adversaries, criminal or also backed by various governments (with values similar or opposite to Junior). Is there any security risk to Junior using these servers presuming he uses SSH as prescribed?

My thoughts are as follows:

1. The adversary gains knowledge of a NAT with SSH port. They may then seek other exploits.
2. The adversary may leverage the jump server for a social-engineering-style attack. For example, they may fool Junior into revealing his private key.
3. The SSH implementations used by Junior may have an unknown exploit.
4. The adversary may be backed by their respective government who may have the resources to brute force their way through. (I understand this is the least probable risk.)

Other than these risks, my immediate thought is it should be fine. The tunnel through the jump host is encrypted after all... but it definitely still feels icky.

Answer 1

I can see several problems with this scenario:

• Generally a jump server not inside the corporate network will have the same access as any other outside host, including the user's home desktop. Therefore, the base scenario here doesn't really make sense. Closest thing that does is that a coworker at the company already has a host with ssh open in the firewall to use as a jump host. The coworker, presumably should be trusted. (If not, there are other insider based issues unrelated to this question.)
• If the corporate firewall is blocking direct ssh access from certain locations, but allowing random untrusted proxy hosts on the internet to ssh in, I question the validity of the protection provided by the firewall rules.
• VPN software commonly messes up routing tables, blocking the source host from accessing internet except through the VPN. This makes sense if you are trying to push all your traffic through the VPN to hide your real location -- which is probably not this case. It might make sense if you are trying to prevent data from being exfiltrated from inside the corporate network directly to some host on the web. There are a number of less sensical reasons. Bypassing this might be a policy violation of some sort, exposing risks the policy is intended to mitigate. Or perhaps the VPN client is misconfigured and the routing change is unintentional.
• Speculations on the results of using an unpatched or outright malicious sshd on the jumphost are about as good as predicting the nature and number of future bugs in ssh. Non-bug related results should be about as dangerous as any other man in the middle attack with ssh -- mostly mitigated if you have a prior secure and clean exchange of ssh host keys with the final destination host. (In other words, ssh should be able to detect tampering.)

Answer 2

The scenario as stated makes little sense.

When Junior uses ssh -J he would be connecting to a machine (destHost) through an intermediate one (jumpHost).

So, in your scenario Junior would connect to a trusted destHost (owned by his grandma, perhaps?) by jumping through an untrusted jumpHust [potentially] owned by an evil third party.

Now, if can ssh to jumpHost, he almost surely can directly ssh to destHost as well, so there is no need for the untrusted intermediary. But let's suppose he does that.

What can a malicious jumpHost do?

As long as the Junior uses the tools properly (and they are updated enough), very little. This includes actually checking the fingerprint of destHost on the first connection (compared to the right fingerprint, provided off-band), and actually using -J (ProxyJump directive), not connecting to jumpHost and then to destHost from a jumpHost shell.

The information that could be gathered by the malicious jumpHost would be that related to traffic. Mainly that would be: origin ip (Junior's), destination ip (destHost's), connection times and amount of traffic exchanged on each direction. The traffic itself would be encrypted, so it shouldn't be able to figure out what gets transmitted (but there might be nasty side-attacks).

If Junior needs to enter some password over the connection, jumpHost might be able to partially guess some typed data based on frequency (CVE-2001-0572), but there are some countermeasures designed to make that hard.

I should note that Junior is unlikely to be visiting Reddit with a console browser over ssh, or reading their mail on destHost using mutt.

Note that if Junior was to use jumpHost as a proxy instead (which would be a far more likely scenario) the analysis would be completely different.

Finally, while a different kind of security risk, the (continuous) connection of Junior machine to a foreign-country-considered-an-enemy (and source of many cyberattacks), may raise some security alarms. And the responding team will not be pleased that what they thought was a compromised machine, an insider, data exfiltration or first step of ransomware attack, turned out to be a silly junior violating company policy (or actually, they will prefer this outcome, but won't enjoy the heart attack he almost caused them).

If Junior wanted to visit Reddit or Gmail during work hours, it would be far easier for him to do so using a different computer than the one used for work, or simply a smartphone. That is likely to still contravene company policy by procrastinating during work time (depending on his actual job and contract), but it wouldn't bypass other security policies that the ssh connection would.