Analysis of Linux Backdoor Used In Freenode Hack 37
An anonymous reader writes "A detailed analysis has been done of the Linux backdoor used in the freenode hack. It employed port knocking and encryption to provide security against others using it. This seems a little more sophisticated than your average black-hat hacker.
security methods can be used by both sides (Score:5, Interesting)
So a common method of securing parts of systems (port knocking) was used by nefarious software to protect itself.
"This seems a little more sophisticated than your average black-hat hacker."
From the article... ...
"Whilst the handshake and data security mechanisms are arguably well designed the persistence mechanism isn’t in any sense stealthy. This particular rootkit would be easily detectible using tools as Tripwire and Rootkit Hunter.
While the techniques used are well engineered they are certainly not unique. For example netfilter hooks were discussed in the context of rootkits back in a 2003 Phrack article titled ‘Kernel Rootkit Experiences‘. Similarly port knocking and RC4 encryption for concealment and transport security are not highly sophisticated yet are sound approaches if developing a rootkit."
Doesn't seem so special after all.
Re:security methods can be used by both sides (Score:5, Interesting)
Doesn't seem so special after all.
Well, full marks for that clever little bit of sleight of hand that allowed them to set up persistent connectivity without hard-coding addresses. I like the way they use the combination of port and sequence number to determine the remote address, and packet window size to set the remote port. It was also pretty interesting that the software could take its sweet time between 'magic' packets, allowing it to obscure itself in incoming traffic.
But yeah, it's a clever riff on well-known rootkit tools. And it's nothing that shouldn't have been discovered in a moderately well-run security environment. I mean, we are talking about an altered boot script, new rules running in iptables, and additional new binaries on the system. You would expect that sort of thing to be found before too long.
But one thing I would very much like to know is how this rootkit got installed in the first place. There's nothing about that in TFA.
Re:security methods can be used by both sides (Score:4, Interesting)
They only thing special about this rootkit is that is clearly designed to be installed by an insider. The sort of thing that NSA financially or via extortion corrupted network security types, would install. I'll bet that many foreign countries will not be accepting their version of H1B when they come from the US, in network security jobs.
Re:security methods can be used by both sides (Score:4)
China, Russia, N. Korea, France, England, Germany, Israel, Japan, Brazil, and basically every other country on the planet with indoor plumbing and broadband internet service all contain governmental security services with ability to create an exploit such as this. And that group is probably dwarfed by the criminal enterprises around the world making money hand over fist by creating, selling, and using sophisticated exploits. So that being said where will you find people to fill your network security jobs after ruling out anyone associated with the US?
Re: (Score:3)
But one thing I would very much like to know is how this rootkit got installed in the first place. There's nothing about that in TFA.
That was my question too... how did it get there? I mean, kernel modules don't just magically appear and install themselves... :-P
Re: (Score:2, Troll)
Using any of the endless parade of exploits that constantly emerge for linux, I would imagine. Why does it matter?
1) You get root just one time
2) Then you can install any kind of root kit or do any other kind of goddam random or fiendishly convoluted havoc you can think of
You know the kind of shabby security joke that Windows turned into? The same thing has happened to linux and
Re: (Score:3)
P.S. - for anyone who is bewildered, when I said "now this" I was referring to the SSL 3.0 exploit. The story is close to this one and I was reading both of them. But it all comes together into a giant shitstorm, and it is past the point of criticality.
Either we are going to abandon the whole internet/OS infrastructure hodgepodge that has proved to be unprotectable and replace it with something that is secure by design, or we are going to have to live with everybody getting constantly pwned. I doubt I will
Re: (Score:2)
SSL is not linux or bsd specific.
Re:security methods can be used by both sides (Score:5, Informative)
If you think I've misinterpreted the problem, please tell me exactly where.
Right here:
You know the kind of shabby security joke that Windows turned into? The same thing has happened to linux and BSD
The security problems that afflict Linux, Mac OS X and, to a much lesser extent, *BSD are fundamentally different in the way they manifest.
We have yet to see the systemic infestation that characterised Windows in the late '90s and early '00s. There was a time mid-decade when the time it took to for an unattended, freshly installed Windows box to get pwned was estimated to be 20 minutes.
Heartbleed, Shellshock, the Debian SSH debacle (can't forget that one) and numerous other problems are symptomatic of weaknesses in aspects of the FOSS environment that people used to think (unrealistically) were invulnerable. Instead, what we've discovered is that they're quite susceptible to targeted attack. This difference should not be understated. Windows is an infected system - basically, you can't run it without antivirus. Linux, Mac OS X and numerous other OSes are easily attacked individually, but there are not as yet any exploits that subvert the entire ecosystem.
None of this is to dismiss how serious the potential threat is. I just want to make it clear that, so far, the danger that we see is different from what we are living with in the Windows world. It's different in quantity and quality.
Re: (Score:3)
At least not until the next version of systemd is released.
Better than most (Score:2)
The most common black-hat software is pretty dumb, e.g. brute force ssh attack, install custom ssh client, attack other machines' ssh with brute force. By comparison this is pretty savy. It sounds like someone was targeting freenode specifically.
Re: (Score:3)
Which channels? There are channels in which what your describe is accurate (duh, it is irc), but the vast majority in freenode is quite normal. Dont fuck freenode, fuck specific channels.
Re: (Score:3, Insightful)
I punched one #physics op's buttons so hard, he still bans me on sight in #physics. Even though I trolled him in #philosophy, a channel in which he didn't have ops. This is the calibre of the discourse on freenode's #physics and other channels with academic disciplines for their titles: ops ban based on whims. It's stupid and it reduces the knowledge content of the chat.
If you troll #philosophy, why would you be expected to behave any better in #physics? You are the same person in both channels. I dont see the problem here, really.
All moderated channels. There used to be a channel that aksis owned, several years ago, that had a policy of no kicks/bans. It was a great libertarian experiment in absolute freedom of speech. It was the best channel ever. We fought our battles on a level playing field, with our words (or our bots!).
There was another channel, ##politics, which was moderated like all the other channels on !freenode. You had a choice: you could go to #politics for absolute freedom of speech, or ##politics for same old same old. #politics was by far the more popular, because it was fun. Freedom is a heady feeling.
But freenode got scared of the fun we were having in that channel. The little old ladies that run freenode shut it down, made it like all the other channels.
Freenode is not 4chan. Expecting freenode to be like 4chan is a foolish. If you are in a channel in freenode, you must comply with both channel rules and network rules. Freenode will not hesitate to enforce their network rules in channels if the channel ops are not enforcing them.
Re: (Score:1)
You are arguing with a narcissist. Good luck with that!
Re: (Score:2)
Yeah because proprietary operating systems and software aren't also riddled with holes.
I smell a skid (Score:1)
All the features listed can be found part of the open source rootkit named jynx 2.0 programmed in C which has been around for years. It employs socket hijacking for a backdoor access on any outbound service, SSL encryption for communications, root shell access, file and socket hiding from root users, as well as loading into every running application via LD_preload. The only detection is looking at which libraries are attached to your processes in which a live CD needs to be used to remove the files.
Sheldon did it! (Score:2)
He totally did.
http://warrior.logicalnetworki... [logicalnetworking.net]
Sensationalistic title and wording used in OA (Score:5, Informative)
The OA uses the term "Linux backdoor," but then goes on to describe it as a add-in kernel module. It's not a backdoor, but rather a rogue kernel module someone has written. The module in question, ipt_ip_udp, isn't part of the Linux kernel. It's merely a module some black hat wrote to provide remote access to an already compromised system. This is just FUD and self-promotion by NCC Group to make what they found sound much more important than it really was, no doubt to increase their client base. What crap.
To sum up, it isn't a Linux back door and it isn't a vulnerability in the Linux kernel source code. It's merely a rootkit.
Re: (Score:1)
Thank you, a bit more accurate and informative than the main article
Detailed analysis of Linux backdoor .. (Score:2)