8 ms·
Bypassing Authentication on SSH Bastion Hosts
- pmoriarty 7y agoAny way to read this article without Javascript?
- inetknght 7y agoUse Firefox. Then prepend the url with `about:reader?url=` to force it into Reader Mode.
- auiya 7y agoAlternately, press F9.
- pmoriarty 7y agoHmm.. So how would that work exactly? The source for that page only has Javascript in it. Anyway, when I try to load that page in Firefox while blocking scripts with uMatrix, I get this error: "The website you are visiting is protected and accelerated by Incapsula. Your computer may have been infected by malware and therefore flagged by the Incapsula network. Incapsula displays this page for you to verify that an actual human is the source of the traffic to this site, and not malicious software." And then it tells me it wants me to click a "I am not a robot" checkbox.. but, of course, there isn't one, because I'm not allowing Javascript.
- inetknght 7y agoI also use uMatrix and probably with stricter settings than you do (* * * block) and also NoScript. I don't know what you're doing wrong; I load it just fine by following the exact instructions I said: prepend the URL with `about:reader?url=` and go. Page loads fine.
- emj 7y agoNot 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.
- inetknght 7y agoIt's also about how users should be aware of malware injecting themselves by use of an alias.
- vertex-four 7y agoOf 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=100515 https://devblogs.microsoft.com/oldnewthing/20181219-00/?p=10...
- oil25 7y agoWorks fine here, even over Tor - Firefox 70.0.1 with javascript.enabled=false in about:config.
- pmoriarty 7y agoIf I curl the article's URL, all I get is: <html> <head> <META NAME="robots" CONTENT="noindex,nofollow"> <script src="/_Incapsula_Resource?SWJIYLWA=5074a744e2e3d891814e9a2dace20bd4,719d34d31c8e3a6e6fffd425f7e032f3"> </script> <body> </body></html> And then if I curl: https://www.nccgroup.trust/_Incapsula_Resource?SWJIYLWA=5074a744e2e3d891814e9a2dace20bd4,719d34d31c8e3a6e6fffd425f7e032f3 https://www.nccgroup.trust/_Incapsula_Resource?SWJIYLWA=5074... Then I get an obfuscated Javascript blob: http://dpaste.com/2H519EP http://dpaste.com/2H519EP I can't understand how this page could work on any browser that doesn't enable Javascript. The only possible explanation I can think of is that it must be sending different content based on user agent, or something, though messing around with sending different user agents via "wget -U" gets me more or less the same thing.
- oil25 7y agoI tried again and now get the Incapsula crap - maybe related to IP address (which changes often on Tor)? Edit: the page loads for the first time after assigning a new IP in Tor, but subsequent loads throw the captcha. Odd system.
- sm4rk0 7y agoI've just tried disabling Javascript in Firefox Klar/Focus (a built-in option) and the article loads, while this page says 'No': https://www.whatismybrowser.com/detect/is-javascript-enabled https://www.whatismybrowser.com/detect/is-javascript-enabled
- theamk 7y agoAre 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.
- hackcasual 7y agoSSH bastions fall victim to feature creep like a lot of products
- steventhedev 7y agoEven 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.
- wolf550e 7y agoWhy not a patch to openssh to disable multiplexing on the server? At least as an option.
- mercora 7y agodont 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 7y agoNot 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".
- oil25 7y agoCharacterizing 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.
- mercora 7y agoadditionally you would need to be able to execute code as the targeted user account. I think its acceptable to call this kind of use an attack or backdoor but not the feature itself. I use this feature daily while considering the risks.
- deleted 7y ago[deleted]
- tingletech 7y agoI think this helps the attacker piggy back on the connection of a user who has the MFA device and is able to get deeper into the network than the bastion can w/o MFA?
- zaroth 7y agoFirst, the article doesn’t characterize the feature as an attack or a backdoor at all. It describes how a perfectly valid feature can be exploited to achieve deeper network penetration. I believe this technique was actually used to target Coinbase a few months back, as I recall from a post in HN a while back. It’s useful in pivoting from a foothold attack at the boundary (e.g. Chrome zero-day) into the crown jewel backend which could be totally isolated to reduce the attack surface, but if you connect into it from a compromised host, this provides a convenient and hard to disable vector to piggyback onto the connection. If there was no way to piggyback the session, even owning the developer’s terminal doesn’t gain you access to a secure system which has multi-factor authentication using a hardware token.
- agwa 7y agoIf the developer's terminal is owned the attacker can always find a way to piggyback the session, such as by attaching a debugger to ssh and injecting malicious commands as if the user had typed them (and hiding the echo so the user doesn't even know it is happening).
- hhii 7y agoIn 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__ 7y agoI 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 7y agoYou are correct. SSH multiplexing sockets use no authentication whatsoever: the assumption is "if it's up, the user already did that before."
- kerng 7y agoSeems similar to SSH Agent Hijacking - mostly useful for red teaming only - because you need to compromise the Engineer/SRE/DevOps person first.