This thread onn the LinkedIn Forums references an article from Symantec on a Linux backdoor exploit.

http://www.symantec.com/connect/blog...ion-protocol#!

Thanks for sharing. Apart from thoughts about the time line (the breach apparently happened in May of this year, so even if it was the end of May it still took Symantec about twenty days to share this nfo publicly in June and what's the use of web logging about it five months afterwards in November?..) and the web log post itself (it perfectly "protects" Symantecs assets by sharing absolutely nothing like not even a hash or shared library name) this shared library injection would still require an infection vector (the linked write up says "The Trojan may be installed by another threat.") meaning investing in prevention (hardening and auditing) should still pay off.

I don't think it can be done without the help of someone from the inside. Anyone can't just pipe in to the SSH, and when its written over there that THEY analysed the protected environment over there, why did't the IDS or firewall detected anything, how is it possible ? I mean how can some one gains the root access(in a protected network) and then modifies the SSH library. Apart from this, there is not much evidence that explains it perfectly.

I posted the link here precisely to illuminate the scaremongering of Symantec. Remember, Linux is a threat to their business model - and this is a major reason why retailers don't want to sell computers pre-configured with Linux. They make little profit on the hardware, most of it comes from the add-ons needed for Windows - none of which are needed by us.

I think my previous post, in a way, justifies what you have said.

Regards,
nm

Well, as they describe the exploit, attackers modified sshd to accept a particular escape-sequence.

Personally, I doubt this story. And, if it is true, it strongly implies to me "an inside job."

Sure, Symantec made its fortune by selling tools to (deliberately) non-secured Windows computers which tell you ex post facto "well, somebody just stole your horse ... again." But they do provide a fairly easily-go-to summary of known exploits (which they simply reap from other sources and then claim credit for). And, if they at least raise awareness of these issues, I guess they do some good to somebody.

"And, if they at least raise awareness of these issues, I guess they do some good to somebody."

Well and good but what, exactly is the issue that they are raising here? They don't say because they are scaremongering - that being their stock-in-trade

I just read this article describing a new SSH attack.
Matthew

Nov 18, 2013
Joe Casad

Innovative back door looks like normal SSH traffic.

Security experts have announced the discovery of a Linux back door attack that they have pronounced "more sophisticated than we have seen in the past." This attack apparently breached a large hosting provider, providing access to usernames, passwords, email, financial records, and other personal information. Although some of this information was encrypted, investigators could not rule out the possible theft of encryption keys.
The attack was unique in its ability to conceal its own communication within SSH. According to the report, "...the back door did not open a network socket or attempt to connect to a command-and control server. Rather, the back door code was injected into the SSH process to monitor network traffic and look for the following sequence: colon, exclamation mark, semi-colon, period (:!;.)
The back door watches for this pattern and parses any traffic after the traffic is received. Hidden commands are encrypted using Blowfish and Base64 encoding.
According to the report, once the code is activated, the attacker can submit any command using the following syntax:
exec sh -c '[ATTACKER_COMMAND]'>/dev/null 2>/dev/null
The backdoor also supports several pre-configured commands and lets the attacker extract SSH connection data from the system.To detect the attack, search the traffic for presence of the initiation string (:!;.). The report at the Symantec site also describes a way to detect the attack through an SSHD process dump.

I've merged yours with the current thread on the same topic.