Linux backdoor squirts code into SSH to keep its badness buried

Security researchers have discovered a Linux backdoor that uses a covert communication protocol to disguise its presence on compromised systems. The malware ‪was used in an attack on a large (unnamed) hosting provider ‬back in May. It cleverly attempted to avoid setting off any alarm bells by injecting its own communications …

[hplasm]

Let the whining

commence.

[Destroy All Monsters]

Re: Let the whining

NO!!

(slaps commenter)

We FIGHT!

[Roo]

Re: Let the whining

Far from it... It looks like a nifty bit of work from the teeny amount of info I've managed to dig up on it.

Actually I do have a whine: I'd like to know a bit more about what vulnerabilities were exploited to get it installed...

[BrentRBrian]

Re: Let the whining

... the most common vulnerability ... the one HOLDING THE MOUSE.

[sisk]

Re: Let the whining

I'd like to know a bit more about what vulnerabilities were exploited to get it installed...

Usually Linux malware gets out (in the rare instance that it does actually get out) through compromised repositories, though that doesn't seem to be the case here since it only infected one host.

[hplasm]

Re: Let the whining

Blimey!

I stand, pleasantly surprised!

Keep up the high standard of well reasoned commenting - the bridge dwellers slumber on, it seems...

[Adam 1]

Re: Let the whining

Let the WINE-ing commence.

[Anonymous Coward]

This is what happens when you use Linux.

Should've used *BSD

[vagabondo]

Re: Should've used *BSD

Was that openBSD as in the originators of openSSH?

If you have root access to any Unix type system you can install anything you like. The unexplained problem is gaining unauthorized root access to any system that has not already been weakened by ignorance or stupidity.

[Anonymous Coward]

Re: Should've used *BSD

>>> Goalposts shall not be moved <<<

Doesn't matter where OpenSSH originated, it's the OS that's the problem.

[JEDIDIAH]

Re: Should've used *BSD

> Doesn't matter where OpenSSH originated, it's the OS that's the problem.

Until the exploit vector is identified, you can't claim that.

[Tom 13]

Re: >>> Goalposts shall not be moved <<<

There are no fixed points in computer security, not even the goal posts. Everything is constantly evolving, even the maxims by which we determine what our current measurements of security are.

That's what makes it such a challenging environment in which to work.

[Radbruch1929]

Re: Should've used *BSD

I politely disagree with the first bit: E.g. for linux, grsecurity and/or SELinux come to mind as a possibility to harden your systems against attacks that comprise your root account. Of course, this does not mean that anything is "completely safe".

But the idea that attaining root status on a Unix system is akin to hitting the jackpot is no longer generally valid and in fact may constitue a trap in a properly secured system.

[NinjasFTW]

Infection Vector?

I get how it hides itself in a shared library once its installed but how does it get there in the first place?

Presumably you would need root permissions install the shared library. Is there an update system compromised or could it be a rogue sysadmin?

[Destroy All Monsters]

Re: Infection Vector?

That is the true question here.

[Anonymous Coward]

NSA Trojan installed by other malware

Norton from June:

http://www.nortoninternetsecurity.cc/2013/06/linuxfokirtor.html

Symantec from June:

http://www.symantec.com/security_response/writeup.jsp?docid=2013-061917-4900-99

It's trojan installed by some other malware. It seems to be a pure backdoor. Lets the remote attacker grab files and send commands.

Looks like the work of a certain $10 billion dollar guerrilla in the room, and it's pet monkey side kick.

Who was the ISP targetted? And have they found the initial installation yet?

Also what distro? What version?

[Anonymous Coward]

Re: NSA *BACKDOOR* installed by other malware

Excuse my slack terminology it's a *Backdoor*, hanging off the SSH port, it shouldn't be called a trojan.

Q1. Can this command sequence ":!;." be spotted in the SSH connection logs?

Q2. Is there more than one instance found?

Q3. Is the blowfish key *different* for each instance?

Q4. Why blowfish? Why encrypt rather than obfuscate or simply XOR? Someone wanted to put a backdoor in but secure it with a proper key??? What key length?

[Anonymous Coward]

Re: Looks like the work of a certain $10 billion dollar guerrilla in the room

You're posting AC, why not just name it?

[Paul Crawford]

Re: AC 09:45

"You're posting AC, why not just name it?"

They did - read the title of their post.

[Anonymous Coward]

TAO or MyNoc

Nobody is anonymous on elReg, all elReg traffic is present in the GCHQ logs because the pages all reference non-UK content and are thus logged and monitored by GCHQ. Clicking 'post anonymously' was simply to remind them of the right to privacy laws they're breaking. Equivalent to David Cameron hiding his old speeches.

There is no warrant protecting you here, the warrant was signed days ago and is a blanket one. Nothing stops a GCHQ operative from running any query on that data on you, Brit or not. Do *not* use anonymous posting on any British site in the belief you are not monitored by GCHQ and NSA because you are.

It will be NSA's hacking division TAO (Tailored access operations) or MyNoc the GCHQ hacking division that did Belgacom I suspect.

What did the Mexico hack look like? The hack of the presidents email server? What did Merkels hack look like?

http://www.theguardian.com/world/2013/oct/21/mexico-condemns-us-nsa-hacking-presidents-emails

"According to Der Spiegel, the NSA succeeded in hacking a central server in the network of the Mexican presidency that was also used by other members of Calderon's cabinet, yielding a trove of information on diplomatic and economic matters."

That's a central server hack too, what did the backdoor look like???? Release the details so we can connect the dots and catch this 'hole in the donut gang'.

[Chemist]

Re: NSA Trojan installed by other malware

From the Norton link in June

Risk Level 1: Very Low

Linux.Fokirtor Threat Assessment

Component Severity

Wild Level Low

Number of Infections 0 - 49

Number of Sites 0 - 2

Geographical Distribution Low

Threat Containment Easy

Removal Easy

Damage Level Medium

Distribution Level Low

[Vociferous]

Re: NSA Trojan installed by other malware

> Looks like the work of a certain $10 billion dollar guerrilla in the room, and it's pet monkey side kick.

State sponsored perhaps, but not necessarily US. There's at least four vassal allied countries who could do this. Then there's China and Russia, which rival the $10B gorilla when it comes to cyber warfare, and Iran, which, ah, tries its best. That Norton reports the malware suggests it was found on a western computer, so I'd guess China made it.

[Anonymous Coward]

Re: Infection Vector?

Place your bets:

Unpatched Apache flaw or zero day Apache flaw ?

[Tom 38]

Re: Infection Vector?

Place your bets:

Unpatched Apache flaw or zero day Apache flaw ?

Do you even know how little of httpd executes with enhanced credentials? I would very much doubt that that is the vector.

[Captain Save-a-ho]

Re: Infection Vector?

Wouldn't sendmail or bind represent a far more likely avenue?

[vagabondo]

Re: Infection Vector?

As this has only been reported as occurring at a hosting company; I would put my money on a buggy and/or poorly configured HTTP(S) ISP control panel.

[vagabondo]

Re: Infection Vector?

> ... it hides itself in a shared library ...

But unless it was part of the original base OS installation, I would expect it to be pickeded up by rkhunterd or somesuch.

I have not seen anything to suggest that this malware could be installed and remain undetected on a system with a reasonably alert sysadmin.

[Anonymous Coward]

Re: Infection Vector?

The infection vector is probably nothing exciting or 0-day. A hosting company has the added problems of it's customers installing all kinds of vulnerable software.

1) Find ANY vulnerability on the netblock of the hosting provider

2) Privilege escalation if needed

3) Install wireshark/other network analyser

4) Stop the webserver service

5) Wait for hosting admin to login to investigate

6) Retrieve sniffed login details from wireshark

7) SSH to other servers on the internal IP using admin login

8) Install what you want, including obfuscated back doors so you can enter any time at will

9) Get bored doing this manually so write a script that logs in to every IP on the netblock and automatically installs your custom software

[Anonymous Coward]

Re: Infection Vector?

"Retrieve sniffed login details from wireshark"

Load of disinformation here. Properly used SSH will authenticate both sides (server and client) before even txmitting a single payload bit. SSH will bail out as soon as the counterparty cannot cryptographically vouch for the posession of an SSH secret key. YOU CANNOT INTERCEPT ANYTHING from a properly set up SSH link. Short of breaking RSA, SHA1 and AES/3DES/RC4 and the like. Neither can you insert or replay a single fucking bit in a proper SSH connection.

The client will warn you "server key has changed" or something to this effect. Or the connection will simply not be established because of the MITM antics of sombody. Including the antics of GCHQ, as we now know.

This displays the power of Open Source: Commercial parties now go around spreading disinformation on the military-grade security that is openSSH, because it is just so perfect and it's free.

You can get similar security from SSL/TLS/HTTPS, if you sign your own keys and run your own CA. The USAF, Army and Navy do this on a regular basis. TLS and SSH have been specifically designed to thwart any MITMing.

If I talk like a seargeant here, it's because this comment section is full of dumb-o-matics from some "PR" company.

[Oh Homer]

Re: Infection Vector?

While it's important to openly and honestly recognise security vulnerabilities, in many cases what's implied as "software insecurity" often has bugger-all to to with the security of the actual software, certainly in the realm of generally secure operating systems like GNU/Linux and *BSD, and is more likely to be due to a password compromised by social engineering, then used to gain full access, at which point it's game over and no amount of "software security" could possibly defend against it.

That's also true of most of what passes for "malware" on Android, nearly every example of which is actually a rogue application that must be deliberately downloaded, installed, granted permissions and run by the user. Again, that has exactly zero to do with "software security", it's PEBKAC, and I'm afraid there's no software on earth that can mitigate stupidity.

Genuine software insecurity is far more likely to be found in the realm of proprietary operating systems and applications, where the lack of public scrutiny of the sources means bugs, and consequently security vulnerabilities, are rife, and typically remain unaddressed for extended periods, long enough to be widely exploited.

So I doubt this latest scare has anything to do with the security of GNU/Linux or Free Software in general, at least there's been no evidence to support that theory. But those who despise the principle of intellectual freedom will nonetheless use any excuse to attack Free Software.

I still recall the retarded comments made by Ashley Highfield, former director of "Future Media and Technology" at the BBC, who infamously claimed; "It’s almost a contradiction in terms, if you have DRM how can you have it open source? Because open source people will be able to find out how it works and get round it."

Highfield seemed blissfully ignorant of the fact that the sources for things like PGP were (and still are) available for decades, without its encryption being compromised. The same is true of most encryption software, so there's no reason DRM, or any other kind of software, should be any different.

Ironically (but unsurprisingly) Highfield went on to work for Microsoft, where he was responsible for such things as the proprietary MSN, Hotmail and Windows Live/Instant Messenger services, all of which have have a long track record of security issues.

I find it odd that whenever there's a security breach involving GNU/Linux passwords being compromised by (typically) social engineering, much is made of the fact that it's Linux, and that Linux is Open Sauce®, but whenever genuine software insecurities are exposed in proprietary software, there's an eerie silence on the subject of closed sources.

[Werner McGoole]

Backdoor or Trojan?

I'd describe it as a backdoor if someone writing the official software sneaked in some unofficial code. If it sneaked itself in, then it'd be a Trojan. Injecting code into an already present file isn't exactly news, though. That's what viruses do, hence their name.

[Charles 9]

Re: Backdoor or Trojan?

No, it's properly called a backdoor. Any program that surreptitiously opens another way to access the system is by definition a backdoor. A program can be BOTH a trojan and a backdoor (it's the flow that determines if it's a backdoor or not--if the malware waits for a C&C to connect to it, it's a backdoor. If it actively seeks the C&C and connects to it, it's just a trojan).

As for how it got in, I would wager it piggybacked on another trojan that carried a privilege escalation exploit.

[Robert Carnegie]

It's not a backdoor. It's a door.

If every Linux server running SSH has this vulnerability, THAT'S a backdoor - an alternative access mechanism that bypasses the authentication on the front door.

This is a botnet. Of one machine.

[ChrisM]

This wouldn't have happened if they were using Linux!

Err. .. oh bugger.

Seriously though the malware in this story seems to be of a level way above the usual windows effort. Guess the malware merchants have stopped looking at userland for their id theft needs..

[Anonymous Coward]

Re: This wouldn't have happened if they were using Linux!

the malware in this story seems to be of a level way above the usual windows effort.

That is what worries me. What I want to know is if this is someone clever, or someone with a Very Large Budget, i.e. government. Some people have very correctly asked how that code got to where it was because it requires fairly deep access, which is another thing I really don't like about it.

The traffic cloaking idea itself is not new, but it's impressive that they managed to inject it into an SSH stream - that's a serious notch beyond your average hack because it counters classic IT monitoring.

[Nigel 11]

Re: This wouldn't have happened if they were using Linux!

That is what worries me. What I want to know is if this is someone clever, or someone with a Very Large Budget

"or"??

[NP-Hardass]

Re: This wouldn't have happened if they were using Linux!

Didn't say "xor"

[sabroni]

Re: The malware in this story seems to be of a level way above the usual windows effort.

Well it'd have to be, it infected a linux box and we all know they are secure by design!

[Chemist]

Re: The malware in this story seems to be of a level way above the usual windows effort.

Well I'm going to downvote you because although mostly correct in your statement you missed out 'rather secure' or better 'exceptionally secure'

[sabroni]

Re: The malware in this story seems to be of a level way above the usual windows effort.

Actually I was totally taking the piss.

[Chemist]

Re: The malware in this story seems to be of a level way above the usual windows effort.

"Actually I was totally taking the piss."

Yes, I know. I enjoyed it all the more !

[Anonymous Coward]

A million eyes look at the source

A million eyes looking at the source are only any good if they're looking in the right place and comprehend what they're seeing, otherwise you end up with attack vectors to allow insertion of malware like this.

[Anonymous Coward]

Re: A million eyes look at the source

No source code I think. The original attack vector isn't known (or at least the articles I find don't mention it).

And it may not be a Linux vector at all. Belgacom was likely a Windows Browser exploit, that infected a PC, captured passwords and logins which in turn captured servers.

So suppose a certain agency (e.g. MyNoc the GCHQ hacking agency) infected the ISP's sysadmin's computer by intercepting Slashdot, or Linked In and injecting the zero day exploit, spied on their PC, obtained the SSH password to the server, from that they can install the backdoor.

What did Belgacom backdoor look like? Was *it* a blowfish encrypted protocol? Was it hanging off a public port like SSH?

http://www.computing.co.uk/ctg/news/2306175/gchq-used-fake-linkedin-pages-bearing-malware-to-attack-belgacom

"Comfone, Syniverse and Starhome Mach were all targeted by GCHQ for this information."

"The research into targets that worked at Belgacom and telecoms billing companies included not just LinkedIn profiles, but also Skype user names, home IP addresses, tablet computer use, Gmail addresses and any other social profiles that could be used to help compromise targets."

Man, that "be nice and encrypt the backdoor we just installed with a proper key" just *screams* government malware. You wouldn't want anyone with a supercomputer cracking your key after all, so better to use a decent crypto algorithm.

[Anonymous Coward]

Re: A million eyes look at the source

If you can slipstream non SSH data into the SSH datastream, I'd say that was a pretty serious vulnerability.

[Peter Gathercole]

@AC re slipstream SSH datastream

Yes it would be, especially if it could be done from outside the SSH client/server communication stream. But this does not appear to be what has happened. This is hijacking one end or the other, and intercepting/injecting the data at one end of the secure pipe as it were.

Just to point out that SSH is *NOT* part of Linux. It's not in the kernel, nor part of the GNU toolchain, and although it is in the repositories of most distributions, it's also available for most UNIX systems, and also for Windows and probably any other network enabled operating system as well. It's a cross-platform tool. What is important is how and by what vector it was compromised.

So there is a vector (possibly OS specific) that was used to break into SSH, and SSH itself is a vector to compromise whatever OS is being used. Which may be Linux.

[Tom 38]

Re: @AC re slipstream SSH datastream

So there is a vector (possibly OS specific) that was used to break into SSH, and SSH itself is a vector to compromise whatever OS is being used. Which may be Linux.

No-one has suggested that sshd was broken in to, only that once the server was broken in to with enhanced credentials, that allowed them to install a backdoor that hooked itself in to sshd.

[Anonymous Coward]

Re: @AC re slipstream SSH datastream

@Peter Gathercole - To all intents an purposes, SSH is part of Linux, give over with the tedious "Linux is the kernel" drivel. Everyone knows that there are certain packages which make up what is known by anyone except the most pedantic as Linux. SSH is one of those packages, I am not aware of any Linux distro which doesn't come with SSH by default. So to make semantic arguments like "it's not a Linux problem because this package isn't the Kernel" just serves to suggest that you can't accept that there may be a problem in the first place.

[wheelybird]

Re: @AC re slipstream SSH datastream

Hmm. Well Ubuntu desktop doesn't come with SSH installed by default. Certainly not LTS anyway.

And as someone else above pointed out, Linux *is* the kernel. You can't bang on about Linux being inherently insecure etc. when talking about an SSH server originally developed for another UNIX variant and which is available for almost every operating system you can name.

On top of that, not every distribution that includes SSH by default will necessarily use OpenSSH (which I assume is the server that was affected).

[Peter Gathercole]

Re: @AC 14:58

I'm not doing the GNU/Linux 'drivel' as you call it. I'm just pointing out that SSH is as much a part of Linux as Audacity or LibreOffice, or a host of other Open Source projects. They're part of most distros, sure, but not a part of Linux itself. I suggest that you just don't understand what a Linux distribution is.

As an analogy, would you claim that Apache or VMWare player or even Skype is part of Windows if a particular machine vendor chooses to pre-install it on the systems that they sell?

It's not even the case that OpenSSH is the only SSH implementation out there. F-Secure have their own completely separate SSH implementation, as have SSH Communications Security, and there are also other free SSH implementations like LSH and Putty (client).

[Anonymous Coward]

Re: @AC re slipstream SSH datastream

> To all intents an purposes, SSH is part of Linux, give over with the tedious "Linux is the kernel" drivel. Everyone knows that there are certain packages which make up what is known by anyone except the most pedantic as Linux.

It is not "drivel" and it is not "pedantic", mate. For those in the trade, using the right terminology *does* make a difference, in the same way as a physicist will differentiate between mass and weight in a technical setting, while he may use them interchangeably at the grocer's.

This is an IT website, so get used to it.

[Chemist]

Re: @AC re slipstream SSH datastream

"This is an IT website, so get used to it."

In your case it merely serves as a spotlight on your own ignorance. Of course it's drivel - it's like saying a vuln in Firefox is a fault of Linux. Goodgrief, have your prejudices but try and behave rationally.

[Anonymous Coward]

Regarding the BelgaCom GCHQ MITM Hack

As far as I understand it, GCHQ wrote or acquired some exploit for Firefox. Then they somehow figured a Belgacom management computer+user id would be used by the wetbag to both administer Belgacom systems and to surf Slashdot then and now.

So they intercepted Belgacom traffic to Slashdot, inserted malicious html/javascript, and pwned Firefox on Linux. That's the fault of Mozilla and I would not at all be surprised they are paid and/or forced by means of NSL into doing so. Their Rust Language effort speaks volumes. C and C++ might simply be too dangerous for a large codebase like firefox.

If Belgacom were a super-high security operation, they would have banned the use of the same user account for surfing and administering. Then GCHQ would have pwned only the "use-this-account-for-surfing" Linux user. Now we know a cyber war is on-going and GCHQ is a party in it. The enemy is just accross the channel and its Belgium.

Also, firefox could have been locked down using AppArmor and SE Linux. You SHOULD do this if you handle "big" secrets, nuclear reactors, chemical processes and the like.

Very nice indeed, GCHQ muppeteers.

[Anonymous Coward]

Re: A million eyes look at the source

> And it may not be a Linux vector at all. Belgacom was likely a

> Windows Browser exploit, that infected a PC, captured

> passwords and logins which in turn captured servers.

Phew, all's ok then! :-/

I don't think smug complacency around GU/Linux security is quite the right response in circumstances such as these.

[qwertyuiop]

Re: A million eyes look at the source

This kind of thing makes me wonder about the whole "open source is inherently safe 'cos anybody can look at the code" thing.

I would question whether anybody actually does look at the code. I rather suspect that because it requires (a) a very high level of understanding and (b) a lot of time and effort, very few people (if any) actually do. How many actually download the code for the latest release, review it, and then compile it for their own machine? Doesn't everybody just dowload the latest update from a site they believe they can trust.

This is an honest question - I have no angle and am not trying to make any point. I would genuinely like to know.

[Anonymous Coward]

Re: A million eyes look at the source

Trouble for Linux is that it's codebase moves too fast for an audit to be completed in a sensible timeframe. Whether that's a positive or negative is entirely up to you.

[ricegf]

Re: A million eyes look at the source

"Trouble for Linux is that it's codebase moves too fast for an audit to be completed"

No, what happens is that a Linux adopter (distro maintainer or hardware manufacturer or whoever) picks a stable baseline to "freeze", then does whatever audits and analysis and testing is needed. This is why new products usually ship with a version of the kernel that is several months old. Nobody *has* to use the latest code - pick a baseline. It's not going anywhere! :-)

[Rob Fisher]

Re: A million eyes look at the source

It's not so much that having the source code solves all problems. It's that hiding the source code solves no problems and creates new ones.

If no-one can see the source code then it is very easy to make programs do things other than their advertised purpose. If anyone can see the source code, then you can try putting malware in your program, but you might get caught, so you are less likely to try. You might think that no-one will look at the code, but you can't be sure.

I think you're right that most code is not looked at, or not looked at in the right places by the right people. But exploits *are* found and fixed in widely used open source programs, so at least we can see something is working.

There are no certainties, only tradeoffs. A malware writer trades effort needed to make malware against expected value of information stolen. An end user trades effort spent attempting to prevent or detect malware against value of the information that needs protecting. Open source definitely increases the effort a malware writer needs to make to hide their work. Whether it reduces the effort you need to spend on prevention and detection probably depends on what you are doing.

[Christian Berger]

Re: A million eyes look at the source

Yes, but when you have the source code you have a decent chance of "hardening" your system. While it is hard to fully understand a code base, it's comparatively simple to just throw out all functionality you don't like. This reduces the code base and the chance for errors in there.

[Primus Secundus Tertius]

Re: A million eyes look at the source

@qwertyuiop

I once worked for companies that were certified for ISO 9000 Quality Assurance. So that meant we had to do code reviews. Very few of these actually picked up any bugs in the software; all we got was nitpicking about variable names, presence or absence of comments, or similar.

So I totally agree with your points a and b.

[Marshalltown]

Inherently _safer_

Open source is not inherently safe, just safer. For instance, no matter how clean the code is, a back door could be inserted into the compiled executable through the compiler or assembler, if they were compromised before being compiled. It could even be lurking in the code in the hardware on the compiling system.

[Anonymous Coward]

Re: A million eyes look at the source

It depends on what part of the code you're working on, but generally, when you submit a patch, it is reviewed and signed off by the maintainer of that particular module or bit of code that you have worked on--he or she will have had a good look at your code or ask someone else to do so since his (her) reputation depends on it, more likely than not they're also being paid to do this so a double incentive. If patches are overly complicated, too long, or not well understood, they (IME) tend to be rejected and you are told what it is that the maintainer did not like about them so you can correct it--it may be nothing wrong with the code itself, but for example a patch that is poorly documented or fixes more than one unrelated thing is very likely to be rejected.

Latter on, your changes and everyone else's are forwarded up the chain to someone who looks after a whole section of the kernel, e.g., all video drivers, who will take a second, more high-level look--at this point it is more likely that attention will focus on the commit comments rather than the code itself, but critical, novel, or interesting parts of it may get glanced over. Finally, one of the big bosses will commit to the main tree. Afterwards, vendors may reverse the process somewhat, incorporate their own changes, etc., before the thing gets fed to the compiler.

In short, kernel code does get looked at by a very many pairs of eyes--it's just that, as you may expect, not every pair of eyes looks at every line of code.

Nothing of the above is meant to imply that this backdoor is a result of a kernel breach of security. As other, I am also curious to know what the infection vector was, if any (the Symantec website claims 0-2 infected systems).

[Al fazed]

Re: A million eyes look at the source

er, maybe not everyone .....

[Anonymous Coward]

Surprise!

Shake yourself! Stop using MS products! (It's pithier but has the same meaning!)

[Tom 7]

No reports in the wild.

According to Norton.

So they've found if they can modify their own source code they can put a virus in? At the place it was discovered I mean.

[Valeyard]

:!;.

that string looks a little like an ascii middle finger to me

no matter how sophisticated these things get there's still a bit of immaturity in there

chances of B16B00B5 in there?

[Nigel 11]

Re: :!;.

chances of B16B00B5 in there?

Or even a DEADBABE? (I Shouldn't have read the BOFH of the week)

[codeusirae]

Fake Linux backdoor ..

"The malware ‪was used in an attack on a large (unnamed) hosting provider ‬back in May. It cleverly attempted to avoid setting off any alarm bells by injecting its own communications into legitimate traffic, specifically SSH chatter."

Makes no mention as to how this unnamed hosting provider was compromised in the first place, just another free advertisement for Symantec ...

[Anonymous Coward]

Re: Fake Linux backdoor ..

In cooperation with DollarSoft inc. of course. Linux threatens Symantec's very business model.

[Anonymous Coward]

Scant on tech detail, I'd like more to check out some hosting providers I use, since their monitoring and security leaves me slack jaw'd at how crap it is at times and I vhost some domains with them and Ive seen the odd unicoded attempt at bypassing mail filters coming down the tube from them into my local mail server.

I would guess the checksum of the ssh binary or libraries change post insertion so something like tripwire in checksum mode would see it, if only the hosts were sharp enough to do that. Ditto rkhunter etc.

This is the problem, we can only really secure well that which is our own, the rest, its a crapshoot. The cloud? do me a favour. However, being open source what that DOES give us is the ability to pull the code for the suspected libraries or binaries and inspect it post news of an infection and find/resolve/get workarounds for the issue much quicker.

As for anon, no your never anon unless you truly need to be, and I'd imagine the reg is closely watched especially in security topics.

[Anonymous Coward]

"the reg is closely watched"

Not that closely. I've been posting for yonks and still haven't been offered a job.

[Bladeforce]

Can we get some windows malware listings please....oh wait theregister doesnt have enough space to list all of them, tens of millions such a bug infested POS

[sabroni]

Yeah!

Well put! It's not ike a little Linux vulnerability means anything. When the year of the linux desktop comes, then we'll have some real security!!!

[Anonymous Coward]

Yes, because that will make every non Windows hack irrelevant.

[Peter Gathercole]

Symantec writeup very poor

I know it's difficult to publish information about a vulnerability without providing a means of using it, but the Symantec write-up is pants! I mean, what does "Rather, the backdoor code was injected into the SSH process " actually mean?

Was it added to the binary before it was run, was it added to one of the run-time libraries, was one of the in-core runtime libraries hacked, or was the running instance of the process altered?

It also does not state whether this is a ssh server attack or an attack via the ssh client.

I can think of several ways of compromising the client side of things (each ssh session has it's own instance of the ssh client process), and these can be attacked using well known PATH and LD_LIBRARY_PATH attacks without needing privileged access to the client system, or the on-disk binary or the libraries can be attacked and altered if you have access to a privileged account.

Once into the client process, you will have access to all of the private key information on the current system (although you may already have access to that anyway), but I can see how you could catch and re-use key and password information as it passes through the compromised client process. You would also be able to subvert any and all stream traffic, including fixed passwords, SSH passphrases, sudo passwords etc. for any session that is run through the SSH client (using the client as a keylogger). About the only thing that you would not be able to do would be to compromise one-shot authentication devices.

Injecting arbitrary commands would be a minor trick, although hiding them is more difficult.

And if the SSH key management is lax (same key used for multiple servers and user identities, especially if some of them are privileged), then you have a recipe for system compromise on a massive scale.

But don't blame this on the Linux security model. Any system with some form of trusted remote execution could be compromised in a similar way.

[Anonymous Coward]

Re: Symantec writeup very poor

Can somebody knowledgable verify these claims ?

Or is this guy simply claiming "Linux non-root user could shoot himself into foot, whithout harming anybody else" ?

[Gorbachov]

Re: Symantec writeup very poor

The attack he mentions is only valid if the attacker has gained shell access to a user and wants to manipulate the legitimate traffic. This attack would require insider knowledge on the target, be very specific and would probably show up in server logs since the attacker doesn't control the server.

The hack we're talking about is probably an attack on the SSH server, where the server has been modified to listen for that special sequence and executes the extra instructions without logging anything.

[Peter Gathercole]

Re: Symantec writeup very poor @Gorbachov

And that is the point of my OP. The writeup is so vague that we're all guessing.

I admit that the client side attack I sketched out requires access as a user on the client system, but that is a lot easier to get than breaking privileged access. All the usual vectors of Java, side-jacking and social manipulation etc could end up with a process owned by the user in question, which would have whatever access the user has on the client system (but no special privilege). This would mean that it could execute a series of shell commands as the user, run an SSH client program itself, read the user's public key and any private keys stored on the client system, and if the keys are passphrase-less keys, use them to gain access to other systems.

Here is a scenario, possibly far-fetched, and I've not worked it all through, but it could set LD_LIBRARY_PATH somewhere like .bashrc so that a local directory appears before some of the system library directories. It then looks at the Linux distro, and fetches a specific hacked SSL or other (including libc, I suppose) library for that distro off of the internet, and puts it in the directory.

Following this, every legitimate program including SSH client sessions that the user starts could be running with malicious code from the bogus library. If it replaced the right routines, you could have a key-logger, and this key-logger will be able to capture the passphrases as they are typed, giving access to all of the user's private SSH keys. It could also capture any passwords that are typed for remote systems.

OK. No breach of privilege required so far. Everything has been done as the user in question.

So, the user is an admin, who foolishly has the private key of a remote account that has some privilege in their keystore. The malicious code then has access to the remote system with privileged to attack that system.

Or, say, the admin has sensibly used a non-privileged account to access the far system, but then uses sudo to issue commands on that system via a compromised SSH session. Compromised client can then capture the password that the user uses with sudo, and again has access to the remote system with privileged to attack that system (unless sudo is really locked down hard).

In both cases, it could inject commands, or even start it's own SSH client session using the captured credentials.

How safe do you feel?

Please note that this attack could be used on almost any OS that allows dynamic binding of libraries at runtime, and provides an over-ride of the default system paths to the libraries. I've sketched it out as a Linux/UNIX attack as that is what I know best, but I seriously suspect that similar attacks are possible on other OSs.

Eternal vigilance is called for, especially for admins, regardless of the platform they are using.

[phil dude]

pushing av software much....?

Like the many others here I went look for a *detailed* explanation of what this executable code was.

After 20 pages of google I surmised they all just wanted you to "run this shiny" download.

I call BS until I see a detailed description.

P.

[jakeroberts]

Patches anybody?

This looks to me like something ptrace exec restrictions (which have been baked into the Linux kernel since 3.4) would stop this. The real news here is that $(company) did not update their stuff as they should have. #NothingToSeeHere.

[Anonymous Coward]

One More Piece of $-Soft Propaganda

As others pointed out - how did these Linux machines get infected ? Maybe by a PHP script at a Dollarsoft "Business Partner" running with UID 0 ?

All the pwnings at the hosting companies during the last few months (like the Hetzner incident) were due to crap GUI/web-based admin tools written in that shite language PHP. You know, the language which provides a ton of "comfort" features (such as interpreting strings for control characters and then doing funny stuff). These "features" make PHP software practically impossible to secure.

But the greasy businesspeople think they "need" stuff like PL$$K to "provide a nice user experuience". ssh/Command line based Linux administration is military-grade, if properly used.

Folks - this is anti-Linux Propaganda bought by the sleazy CommercialWare Vendors.

[Anonymous Coward]

Hmm.

So the injection vector is a subtle "plausible deniability" zero day added to open source[1], make the backdoor ephemeral memory resident only (reasonable on machines which are so rarely rebooted that the manual effort of re-installation is acceptable, like Linux instances)... use the now old fashioned GHCQ/NSA MITM spear fish attack to suck out... well, whatever it is they want.

The control signal shows the that the code version is a few generations old. Better to tap off what one might call steganography in the encrypted stream as a trigger. False triggers are cancelled because the following data doesn't hash out. Of course only perfect forward encryption is used for the keys... the targets are not in the millions so key management isn't hideous, or even difficult, out of the limited router memory.

None of this is a problem really until the crims get the kiddie scripts to do it themselves... GHCQ/NSA/BfV/DGSE/FSB/etc simply don't care about anyone here (well, unless you are a terrorist, bank CEO, or a high ranking politician). But the crims will gladly snark every shekel they can from the rest of us.

[1] probably not by the person whose name is attached to the delta either. By the time you find the PD0Day, all traces are gone off that person's machine.... maybe hang them anyway for lack of security hygiene. Of course they'll say they didn't do it.

[Anonymous Coward]

Incoherent Nonsense

Now you $hills try the "allmighty government malware" message.

Here are the FACTS:

OpenSSH authenticates both the server and the client party by Strong Cryptographic Means. There is NO WAY to "insert" even a single bit into an ssh connection. Or to remove one. All you can do is to destroy the connection completely.

I guess $Redmond$ is really pi$$ed by the prospect of Linux destroying their bu$$ine$, so if they cannot have real arguments, they use the propaganda route.

Here's really good advice: Stop this kind of nonsense immediately or face the wrath of the Internet itself. You know, people who will make you eat your own $hite propaganda. People who know all the $hite you have packaged into the NT kernel, like TIFF parsers, Icon parsers/renderers. Which contain 17 years old bugs, ready for criminal peru$al.

[Charles 9]

Re: Incoherent Nonsense

"OpenSSH authenticates both the server and the client party by Strong Cryptographic Means. There is NO WAY to "insert" even a single bit into an ssh connection. Or to remove one. All you can do is to destroy the connection completely."

Sure there is. One way is to insert it BEFORE the encryption (if a process can subvert either end, they can access the cleartext BEFORE it's encrypted).

I'm putting my money, though, on a SECOND simultaneous session with its own keypair, and running ALONGSIDE the existing session. So on the network, the SSH session packets get shuffled together. To a network monitor will look like another packet of ciphertext, indistinguishable from what's already been passing through. And since it's being run on a server machine, it would be hard to distinguish traffic from the C&C from legitimate traffic.

[John Smith 19]

Lots of negative commenting AC.

I wonder who they work for?

[Anonymous Coward]

Re: Lots of negative commenting AC.

Simple: Burston-Marsteller. And they work for $Redmond$ itself.

Except that it will work as well as sending more American troops to Vietnam.

[Bladeforce]

Hang on...

Isnt this the same Symantec that has tea and biscuits with Microsoft?

[marcus777]

marcusmh777

This article (nonsense) has appeared elsewhere recently, and is completely bogus ...

... do not believe one word of the Symantec report, period.

This is just microesque extortion style FUD in a lame attempt to incite ignorant folks with the mistaken idea that there is a (thousands of icendents) general threat and need for third party protection schemes from corporations like, well, Symantec.

Don't believe it folks... its nonsense.

Now then, it is entirely possible that a "hosting" company run by cyber criminals has setup their system to prey on their "clients," and it might also be possible that a hosting company might be run by inept sysadmins. But the idea that the hosting site was "hacked" ... absolute nonsense.

I would need quite a bit more information about this "case study" before I would believe any of it.

Cheers.

[Andrew van der Stock]

Someone saw Metlstorm's talk

Finally seeing bad guys using the techniques detailed in Metlstorm's talk from linux.conf.au earlier this year. He claimed that most of these techniques are 10+ years old (and in fact, some of his tools, like ssh-jack, he demos don't work on modern Linux AFAIK).

Search for the video of his talk "Ain't no party like a Unix party". Well worth 45m of anyone's time. You can probably find his 2005 Black Hat talk on ssh-jack around the traps as well.

Great speaker, great guy - if only more in infosec were like him.