
Bypassing Authentication on SSH Bastion Hosts - aberoham
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/october/bypassing-authentication-on-ssh-bastion-hosts/
======
oil25
Characterizing this software feature as an "attack" or "backdoor" is pretty
hyperbolic. In order to abuse multiplexing, the adversary needs local code
execution ability, by which point you've already lost.

~~~
LinuxBender
I would classify it as "works as designed". That said, I have argued with the
ssh developers at length about MaxSessions defaulting to 10. There are no
syslog entries created for subsequent authentication and phishing attacks
become incredibly easy. A coworker and I were going to demo how getting a
developer to run a python/ruby script would lead to root access in production
but they stopped the demo for fear they would have to mitigate the scenario.

Some would argue that getting someone to run a script is difficult, but we
found that about 10% of developers want to be helpful and are not cynical
enough to presume malice. They will run the script which will happily drop a
ssh key, fire up sshd as the user, create an outbound connection to a
passwordless shell-less VPS node and then we are that developer and can piggy
back all their connections. Some developers are devops, so they also have prod
access. Some places have passwordless sudo, too. In some places, you don't
even need sudo, as the posix permissions of applications are sub-optimal.

If you try this, the script should have an obvious problem that requires
running it to see. The developer/engineer will feel good that they helped you
solve a trivial problem and you will have whatever access they have. Obviously
get written permission for this type of pen-test with all the steps clearly
documented and approved. Most important, ensure management agree to NOT shame
the victims of the test. Get them to participate in the re-engineering of your
network to harden it properly without adding excessive friction.

~~~
swinglock
But then again, getting someone to run a script is "local code execution" so
it really doesn't matter how SSH is configured, the compromise was already
once the user ran a malicious script. What comes after is not so interesting.

~~~
kerng
What comes after is the interesting part. Because that's where the attacker
will try to gain access to production and the clock for response and blue team
for detection and eviction starts ticking.

Assume Breach mindset that Microsoft developed for instance - in case you are
intersted to learn more. There is an entire domain/world of security
engineering that starts when the initial compromise has happened. And it
does/should not mean the adversary won, just because they have code execution
on one host.

~~~
swinglock
If a malicious user gained access to your machine, how SSH is configured isn't
interesting. If you use that machine to connect to other machines, the
attacker will be able to as well, regardless of how SSH was configured at the
time.

Heck, the attacker prefers a certain SSH config, the attacker could just
change it. Even if you disabled the feature at compile time, the attacker
could just replace the SSH command in your shell with their preferred version.

This is just disabling useful features to maybe cause minor inconvenience. I
find it about as interesting as telling someone to pull out the power cord of
their monitor to increase security of their login prompt screen.

~~~
kerng
How machines are configured is very interesting, as adversaries make mistakes,
and cam trigger detection for suspicious behavior. There is an entire security
field that is concerned about what happens after a breach.

Coinbase recently had a very interesting article/blog post about something
similar, how adversaries gained access to engineering hosts and how they
detected it.

Of course how much you lock something down depends on the critically of an
asset and so forth. E.g. in certain high security facilities slight variations
of your monitor example are applicable.

~~~
swinglock
That's a good point. If the attacker changes configuration or drops binaries,
they make noise instead of living off the land care free, which make them
easier to detect. I see.

------
wolf550e
Why not a patch to openssh to disable multiplexing on the server? At least as
an option.

~~~
aidenn0
TFA mentions the already existent option for doing exactly that.

~~~
wolf550e
so is "MaxSessions 1" the correct fix if you can use it?

~~~
aidenn0
It closes the easiest hole, but there are still plenty of other vectors.

------
hhii
In our team, we always use an ssh-agent, and require it to confirm, via popup,
each use:

[https://en.wikipedia.org/wiki/Ssh-
agent#Security_issues](https://en.wikipedia.org/wiki/Ssh-
agent#Security_issues)

> There is a procedure that may prevent malware from using the ssh-agent
> socket. If the ssh-add -c option is set when the keys are imported into the
> ssh-agent, then the agent requests a confirmation from the user using the
> program specified by the SSH_ASKPASS environment variable, whenever ssh
> tries to connect.

~~~
__david__
I don’t believe ssh multiplexing talks to the ssh agent. That’s the whole
point, really. You just connect through an already authorized ssh connection.
This eliminates the initial key handshake stuff at the beginning and makes
subsequent ssh and scp connections _really_ fast.

If I’m correct, your mitigation doesn’t affect this particular kind of attack.

~~~
Piskvorrr
You are correct. SSH multiplexing sockets use no authentication whatsoever:
the assumption is "if it's up, the user already did that before."

------
mercora
dont people authenticate indiviually using their own credentials on a common
bastion host? that seems quite odd to me and like the actual issue here. if
you got root already on the bastion host there are quite a few ways to obtain
credentials i would guess...

~~~
Piskvorrr
Not all credentials are name+password (in fact, using password over SSH is the
least secure option available): user authenticates using their name+ssh key.
Nothing too useful can be captured from that set of credentials, except to
_confirm_ their identity. If they also use an U2F, there's no way to capture
_that_ : "I am user Piskvorrr...but have no way to prove it."

OTOH, this method captures their _session_ , in other words, "I am user
Piskvorrr and I have already proven it by successfully authenticating".

------
theamk
Are there really ssh bastions which allow arbitrary command execution? This
seems dangerous.

Limiting remote commands to port forwarding only will severely hamper this
kind of attack, and will prevent ForwardAgent hacks as well.

~~~
steventhedev
Even if you disallow command execution on the bastion (good idea), this will
still allow an attacker to pivot to servers behind the bastion. The whole
point being that the strong auth (e.g. MFA) enforced by the bastion is a
roadblock to pivoting.

------
kerng
Seems similar to SSH Agent Hijacking - mostly useful for red teaming only -
because you need to compromise the Engineer/SRE/DevOps person first.

------
pmoriarty
Any way to read this article without Javascript?

~~~
emj
Not sure, but it's basically about how you shouldn't SSH from compromised
machines because those can have "ControlMaster auto" in OpenSSH config to by
pass authentication to the hosts you SSH to. That means the next time you SSH
from that compromised host they will open another connection without having to
use a password.

~~~
vertex-four
Of course, if you SSH from a compromised host, it could also just piggyback on
your terminal session, or steal your credentials, or whatever else. This is
really an instance of being on the other side of the airtight hatchway:
[https://devblogs.microsoft.com/oldnewthing/20181219-00/?p=10...](https://devblogs.microsoft.com/oldnewthing/20181219-00/?p=100515)

