Stealthy Linux Trojan May Have Infected Victims For Years 129
An anonymous reader writes: Researchers from Moscow-based Kaspersky Labs have uncovered an extremely stealthy trojan for Linux systems that attackers have been using to siphon sensitive data from governments and pharmaceutical companies around the world.
The malware may have sat unnoticed on at least one victim computer for years, although Kaspersky Lab researchers still have not confirmed that suspicion. The trojan is able to run arbitrary commands even though it requires no elevated system privileges.
The malware may have sat unnoticed on at least one victim computer for years, although Kaspersky Lab researchers still have not confirmed that suspicion. The trojan is able to run arbitrary commands even though it requires no elevated system privileges.
systemd hasn't been around that long, has it? (Score:5, Funny)
I thought that the systemd infection of Debian was much more recent than that. Like within the past year. But maybe I'm wrong, and it has been longer?
Re: (Score:2)
It is just that these things evolve and eventually move into the light ;-)
Re: (Score:1)
As long as your sig is under construction it will not be ready to move into the light. Personally I prefer tailor made sigs.
Re: (Score:2)
I had one of those. But I found out my tailor was too limited for my tastes, so I upgraded to ultimate flexibility! ;-)
Re:Security through Obscurity (Score:5, Insightful)
With closed source there are also no guarantees the bad guys won't see the source either. And it's far better to make the code visible to all then to wait for the exploit to be found in the usual ways while everyone was in the dark about it.
Security through obscurity is just like peril-sensitive sunglasses. Having the code visible makes you nervous for some reason? Well we'll just keep you from seeing it! Problem solved!
Re: (Score:3)
And it's far better to make the code visible to all then to wait for the exploit to be found in the usual ways while everyone was in the dark about it.
That is quite a strong claim to make without providing evidence to back it up.
Re: (Score:2)
What evidence would you find convincing? (I can't assess this, as I'm already convinced.)
Re: (Score:2)
I've also seen non-FOSS systems that I've trusted. One of them read paper tape.
You are asking for evidence that is guaranteed to not be available. I'm sorry, but it's impossible. Some of the users who are sabotaged will refuse a subpoena rather than admit that they had been penetrated. And the software that they are using is irrelevant to their opinion. Their opinion is driven by image.
OTOH, let me point out that it is irrelevant what the average FOSS user does. It's that any FOSS user who chooses CAN
Re: (Score:2)
Did you actually try doing that? Because IIS is doing quite well on that score, last I checked.
Re: (Score:1)
I assume you meant "than" rather than "then" in your second sentence; it changes the meaning of the whole sentence in this case...
Re: (Score:2)
Yep my mistake.
Re: (Score:3)
Linux certainly isn't obscure, or you're being sarcastic and suck at it ...
Re: (Score:2)
A valid point, but this *is* an unusual case. OTOH, we don't necessarily know that a bug isn't being exploited just because nobody had noticed it happening.
FWIW, in my viewpoint Linux gave up a lot of it's security when it allowed files that were expanded from archives to have the executable bit set. And that's a long time ago. (OTOH, even without the executable bit set, you could always execute a file from an explicit shell command [usually "sh"].)
"Running arbitrary commands" is irrelevant (Score:5, Informative)
The privilege system does not protect commands, it protects data. You can always run any command on any data that belongs to you. But when you want to access data of others or the system, you need elevated privileges and same for attacking to privileged network ports.
Re: (Score:3)
Well, the other thing is that you cannot run commands on arbitrary data without privilege escalation, unless you are already root. It is simply conceptually impossible. Any process that allows you to access data above your privilege level includes a privilege escalation by definition.
My take is just that the article sound sensationalist and not very competent with regards to technology.
Re: (Score:2)
Well, the other thing is that you cannot run commands on arbitrary data without privilege escalation, unless you are already root. It is simply conceptually impossible. Any process that allows you to access data above your privilege level includes a privilege escalation by definition.
My take is just that the article sound sensationalist and not very competent with regards to technology.
But if you run Linux from disk on a system, and you create a user with the same ID as the user data you're trying to access on that system, you can read all the data from that user. That is not privilege escalation, as far as I can see.
Re: (Score:3)
The process that allows you to create that user already requires privilege escalation as non-root users are not allowed to create new users.
Re: (Score:2)
There are a number of tools that give non-root users root access. It might be "just" sudo, or it might be some GUI tool to allow graphical administration. All it takes is a program that can hijack one of those, or just passively wait until the user issued a sudo command (so their password and access is cached), then it could jump in, grab root, stuff a module in the kernel, and all bets are off from there.
Long term, what Linux really should have is the ability to have either signed executables or a manife
Re: (Score:3)
"There are a number of tools that give non-root users root access."
Yes. And all of them restort to already having root-level access so it is still a privilege scalation issue.
"Long term, what Linux really should have is the ability to have either signed executables or a manifest list that can whitelist or blacklist."
You are not too savvy about what Linux can and can't do, right?
Re: (Score:2)
There are a number of tools that give non-root users root access. It might be "just" sudo, or it might be some GUI tool to allow graphical administration. All it takes is a program that can hijack one of those, or just passively wait until the user issued a sudo command (so their password and access is cached), then it could jump in, grab root, stuff a module in the kernel, and all bets are off from there.
True, but those tools also require the user to have permissions to use them. For instance, sudo requires the user to be part of a group - root, sudo, wheel - that group is configurable so you can call it whatever you want. Even then it usually requires the user's password (which is also required to change the password, so you can't just change the password to be able to use sudo in your script).
Long term, what Linux really should have is the ability to have either signed executables or a manifest list that can whitelist or blacklist. This could be something like Solaris's elfsign or AIX's trustchk, where an admin can make a self-signed key and sign all executables. With this in place, on a production system, if an executable, script, or library isn't signed, it doesn't run. Virtually every other OS has this functionality in place. This doesn't have to rely on an "official" signing key either, and could just be a manifest list generated after install, similar to tripwire's database, and if some executable's signature is different, it doesn't get to run until an admin updates the signature DB.
Check out AppArmor, SELinux, etc - they have the ability to do very fine grain management of the system that reall
Re:"Running arbitrary commands" is irrelevant (Score:5, Insightful)
I';m personally aware of thousands of systems on which database data, backups, and system logs are not read protected from local users. They're left this way on the grounds that "if someone has local access, we're screwed anyway". They pass pass commercial security audits because the security companies do a handful of known external attacks, which giver a small set of tasks to fix the issue and do not address such fandamental issues.
This is particularly aggravated on systems with have password free sudo access for developers, which is very common on development environments, on systems with password free SSH keys casually stored with system wide access, and software systems that store passwords in clear text by default, such as Subversion HTTPS access. It's also compounded when home directories on which such information is stored is NFSv3 mounted and shared with all clients on the network. The concept of "data which belongs to you" breaks down quickly with NFS or CIFS without authentication in most environments. NFSv4 or Kerberized CIFS access can be helpful in restricting this, but I know very few partners or clients who go to the extra steps needed for this.
Re: (Score:3)
I do not disagree. But that is a property of the target system, not of the attack.
Re: (Score:3)
In general, there has been a trend away from both local protection privilege escalation (from user to root.) Mainly the focus has been keeping people out of the box proper, although this does go against the defense in depth concept since once the box gets breached somehow (a security bug that commandeers a Web browser, for example), an attacker can gain a lot by running just with that user's context [1], or even using exploits to get root. Once root, burying kernel modules becomes quite doable.
There needs
Re: (Score:2)
You can only restrict what can be executed from disk, and that is just a form of restricting read access. A user can still execute things in other ways. Sure, it gets a bit more challenging, but you are mistaken about the type of protection you get. As soon as you have some facility that can interpret commands from other sources than files (shell, Perl, etc.) your idea fails. You also need to be very careful about other tools, as for example TCC can compile and execute C code without writing it to disk firs
Liar (Score:2)
Reading from disk is only one portion of a process and process protection, the actual execution occurs in memory and is _ALSO_ protected in *nix.. An easy example is to open a socket on a specific port as a user. A non privileged user can not open a port below 1024 because this is in protected space, but you can open a socket on 1025->64K without issues.
There is no point in attempting to explain SUID/SGID in addition to normal execution, because you don't even have the normal execution correct. I will
Liar (Score:2, Interesting)
If a user can read a file on a *nix system, and can write to even a *single* location, that user can execute that file.
1) Copy the file to the location where I can write.
2) Set the execute flag on the file.
3) Execute the file.
Permissions will prevent you from accessing data you don't have permission to, but will only prevent you from running an application if you can't even see it.
Re: (Score:2)
And while that is convenient and simple to do, it is not even necessary. It is however a situation that is basically impossible to prevent (a very, very careful SELinux config might be able to do it), so it serves well to prove the point.
Re: (Score:3)
No they can't, and I gave the example. A socket is a file, so go ahead and open up a socket on port 99 as a user. After you figure out you are wrong come back and tell me so. I don't want to rub your nose in you being incorrect, I want others to see that you are incorrect.
If you want another example, go ahead and write and compile a piece of code that executes a shell with UID=0. This is 2 system calls, yet you won't be able execute the shell by running your code without root access, even though you can
Re: (Score:2)
The original answer was to a post that claimed to have a filesystem "non-executable", which pretty much means nothing. Also, a socket does not reside on a file system (at least not a regular one). At last, a shell with UID=0 *can* be executed by at least one user. The original claim was for a "non-executable" filesystem.
The claim that was answered to implied that you can store any binary (say, gzip) on a "non-executable" filesystem and that would prevent users from ever running it. Which is moronic.
Context
Re: (Score:2)
You also need to be very careful about other tools, as for example TCC can compile and execute C code without writing it to disk first. The point is that the privilege system is concerned with read and write access, execution restrictions are just a side-effect of that and an imperfect one.
I was not defending the original post, but attempting to correct the bad response. Sockets are files, and I can create a socket in any directory I have write access to. /tmp is a safe "default" location because all users can write to /tmp, but there is no restriction on where I can create a socket in *nix by default.
I agree that the original logic is bad, but the explanation is wrong for why that logic is bad. As written, it claims that the only protections in *nix are at the file level.
Re: (Score:2)
You can stuff your patronizing attitude up you backside. I actually know very well what I am talking about, but you do not seem to have the first clue what a standard Linux protection model gives you and what not. For example, you seem to have no idea that a process is free to write as much code as it likes into the heap or onto the stack and execute it there.
Re: (Score:2)
Bullshit! You stated if you can read it, you can execute it and that statement is patently false.
Your claim of a process being free to write memory fails to consider a process that already has claimed memory and it's protections. Yeah, forty fucking years ago I had to worry about a user reading and writing to my memory space as a Kernel, but that has been fixed for decades. I can also easily set limits to prevent you from having free reign to wipe a system out of memory because of memory protection built
Re: (Score:2)
Let's say you remove the executable flag on the GZIP binary, but leave me with read access to said binary. You think I won't be able to run GZIP on your box with a guest account and a writable home directory? (let's assume I can't bring in some other binary of my own, I just have access to your system)
Re: (Score:2)
Protecting commands (data goes without saying as well) is handled by a MAC/MIC system like AppArmor or SELinux.
What I don't get is how this Trojan could sit around for so long and not be caught by a competent admin. Between process accounting, Tripwire/Aide, mounting home directories with noexec, and finally a sane IDS/IPS [1] that does active protection, this should have been caught by someone and reported. Even a Linux based antivirus product like McAfee that uses the latest 2.6 kernel hooks to do realt
Re: (Score:2)
Indeed. But most Linux installations do not have those or only have a generic config, as doing them right is pretty hard. I have some experience in that area. You run into things like Acrobat reader doing and needing code execution on the stack and other "fun" stuff.
As to your second point, you already said it: It needs a competent admin. Often that one is missing. It also needs a competent admin with the right to decide what to put on the machines and how to configure it. In large enterprises that is usual
Re: (Score:2)
Not necessarily true. If the comman resides in a directory that is read protected then you need to have the appropriate privileges to execute it. I've got an early version of Red Hat in a virtual machine where "shutdown" is protected in precisely that way.
kinda makes you wonder (Score:2)
just how many botnets the NSA is actually running?
Re: (Score:3)
Because obviously all the world's problems are always and only caused by government.
It's a pretty good first approximation ....
Re: (Score:2, Insightful)
Because obviously all the world's problems are always and only caused by government.
It's a pretty good first approximation ....
It's not "the government" that's the problem, it's the Military-Industrial complex, big business, land owners, capitalists, those with inherited money and privilege, and the wealthy self-serving elite generally.
A proper democratic government is the only real protection against these powerful interests.
Re: (Score:3)
A government, like any other entity, has a tendency to grow and expand its powers and perimeter. The problem is that the government also makes the laws, which makes it the worst and most dangerous of all entities, because if it doesn't have the absolute powers it's pretty damn close.
Re: (Score:3)
Re: (Score:1)
Why should anyone trust these "labs" who seem to be always just a little behind the curve in releasing their dramatic security findings? Usually long after the security breach has fulfilled it's purpose. If they are so skilled at finding these complex security breaches they are certainly capable of creating the problems in the first place. And the skills attributed to the NSA or any government agency do not belong to any GS12 salaried government employee. They use highly paid contractors who, judged by the
Re: (Score:2)
From TFA:
The unknown attackers--who are probably backed by a nation-state, according to Symantec
Even Symantec thinks it's a government operation. We're just starting to see them, but I think there's a lot more government-run botnets out there that haven't been outed yet. These sophisticated, highly targeted malware like Stuxnet are all government-run botnets.
They either made them, or as you suggested, took them over for their own use. (that's actually a good idea, and I'd bet the more common option outside of say china or NK... those t
Re: (Score:2)
This one appears to be a Russian Regin, looking at the Language Artifacts section of the securelist.com article.
"requires no elevated system privileges"?? (Score:2, Insightful)
If you are establishing a raw socket, you have to have privileges...
Re: "requires no elevated system privileges"?? (Score:1)
... which is the definition of "privilege escalation," no?
Hello spooks (Score:2)
Re: (Score:2)
It seems to be anyone else.
It seems too obvious, that is. I shouldn't post when tired.
Stripped binaries, statically linked libraries, magic numbers in packets and so on. I'm sure there are a few shell vulnerabilities that we don't know about and certainly there are plenty of commands that can be exploited to escalate priviledge levels if required.
Re: (Score:2)
Re: (Score:2)
Hate being several clicks away from the actual inf (Score:5, Interesting)
It's an ordinary piece of malware.
It talks home to a hard-coded URL.
It has to have a secret "knock" before it will talk back to you (port-knocking has uses both ways, it seems!).
It contains easily-greppable strings.
Quite what distinguishes this from other malware, I'm not too sure. Just that nobody had seen it before?
FUD (Score:4, Informative)
Re: (Score:2)
Re: (Score:1)
What this is even doing as an article on slashdot is beyond me, apart from giving Kaspersky some free advertising space.
Re: (Score:1)
If you honestly think anyone with a brain or in any position of repute has ever claimed those three things, then you're a bigger idiot than posting that on Slashdot makes you appear.
Re: (Score:2, Insightful)
Re: (Score:3)
Re: (Score:1)
Pity the article is more concerned with fear mongering than providing technical details.
I read through both articles and it read as "The sky is falling! The sky is falling! Everyone panic!" but they did not really provide any technical details.
/(^o^)\
Oh the horror
Re: (Score:2)
There has been plenty of people here who have claimed that Linux and open source provide an architecture which is by design more resilient against malware than proprietary solutions.
It is. That is why a Linux malware get to be news whereas yet another Windows malware does not register above the noise as news because there are so damn many of them. The same thing with the Bash, GnuTLS, OpenSSL etc vulnerabilities. "More resilient" does not mean immune - claiming immiunity would just be silly. News of Critical Vulnerabilities in Windows are about as frequent as every Patch Tuesday.
Re: (Score:2)
RAW sockets without escalation? (Score:2)
Something does not compute here. The SecureList blog post says that the port knocking works by getting a raw socket from pcap and looking at the ack. On any Linux system I've ever used, this DOES require root privileges. And yet, they also claims it does not need any special privileges?
Re: (Score:2)
Something does not compute here. The SecureList blog post says that the port knocking works by getting a raw socket from pcap and looking at the ack. On any Linux system I've ever used, this DOES require root privileges. And yet, they also claims it does not need any special privileges?
From what I gather from the linked articles from the summary link, you need root and command line access to install it, but after it is installed, it doesn't take root to activate it. That said, if somebody has access to root or the command line, you need a new security administrator.
Re: (Score:2)
Err so that just describes SUID. Nothing magical or unintended, it still can't operate on a system without root.
And it being on a single computer for years just means it has been found on one single computer, with an admin who didn't look.
Re: (Score:2)
Err so that just describes SUID. Nothing magical or unintended, it still can't operate on a system without root.
And it being on a single computer for years just means it has been found on one single computer, with an admin who didn't look.
I don't disagree. Plus, from the article, it hasn't been found in the wild on any linux installations. It speculates that it could be a problem, but, without either root access or direct access to the box, I don't see how.
Re: (Score:2)
It's because the Article is 100% FUD. Read it carefully, notice how there are zero details at all and a lot of things just dont add up about it.
Then look at the source and realize it's a PR piece.
Click-bait (Score:2)
From the article link to from the article in the summary:
Although Linux variants from the Turla framework were known to exist, we haven't seen any in the wild yet.
It might be because you need root and command line access to install it. After that, however, it can be activated without root.
Kaspersky Labs discovers port knocking .. (Score:2)
'To activate the real remote access service (the attached code starts an inetd to listen on port 5002, which will provide a root shell), one has to send several packets (TCP SYN) to ports on the target system' link [phenoelit.org]
How exactly does this 'Linux trojan' get onto the computers in the first place, without the end user going to a site and downloading the malware and explicidly running it and enteri
Re: (Score:2)
First two Links are Backwards (Score:1)
Speaking of links, the descriptive texts in the first two links in this post are backwards. The reference to the "siphon data from governments and pharmaceutical companies" links to the stealthy trojan link and the "stealthy trojan..." link, links to the "siphon data ..." article.
Re: (Score:1)
Group hug!
Re:give Peace a Chance (Score:4, Insightful)
There are costs involved in all decisions. I can't drive a car without contributing to the cost of a road. I can't keep warm in a snowstorm without buying shelter. I can't prosper, or even live long, without paying for defense.
Do not rail against war and its expenses, but rather oppose those who use force to achieve their ends.
Re: (Score:1, Offtopic)
Unless you want to do the latter, why spend so much money on preparing for it?
Re: (Score:1)
But the old days of raising armies only when needed has gon
Re: (Score:1)
Submit. The thug prospers, I suffer and probably die early. If nearly all people do this, thugs find it an easy way to live, and the class of thugs expands until it dominates the whole world. The whole world becomes a cesspool like North Korea.
Arm myself to resist the thug, and on a national scale arm to resist thug-states. At the cost of defending myself, I can prosper in relative freedom. One of the worse costs is listening to ignorant tools like you advising me to let my throat be cut.
Here is where your black-and-white, false dichotomy fails. You can "arm" yourself to resist the thug by hiring your own gang of thugs, by buying your own gun, or by buying armor. You can arm yourself against the worst thug your imagination can conjure, or against thugs that actually exist. You can prove the strength of your arms by walking into every dark alley, kicking down the doors of hovels and speakeasies, loudly proclaiming your invincibility, or you can follow open, well-lighted paths without offe
Re: (Score:1)
However, consider the consequences. My country's armed forces are clearly for defense, and your country's are to potentially attack me. This means that, when I decide we need to spend more on defense, you feel threatened, and spend more on defense, meaning from my point of view you're preparing an attack, and I need more defense, etc.
This produces an arms race that can lead to war, when one side decides that its best chance to survive is to attack now.
There are ways to defuse this sort of arms race,