Looking At The New Linux Trojan

Da Schmiz writes: "Security firm Qualys discovered a new Linux trojan on Saturday ... details can be found on their website.. Vnunet picked up the story earlier today, and then followed up with more details. They're comparing the potential impact to Code Red or worse, since more servers run Linux / Apache than NT / IIS. I don't think it's that bad, since the infection can be easily detected, but it certainly isn't good." Update: 09/08 11:58 AM GMT by H : Of course, as Kurt Siefried pointed out in e-mail: "The trojan has nothing to do with Apache. The virus attaches itself to an executable, which you must run to infect other binaries (i.e. you must run this as root). This means that infection vectors include, but are not limited to email attachments, but you must of course save the binary, then set it executable, and then run it, as root, to do any real damage. Alternatively you must download binary software and run it (again as root to do any real damage). In other words someone must run binaries of unknown origin as root, and if this is common practice then you have larger policy and education problems to deal with." So - comparing it to Code Red is a bit dubious.

Technical detail:

[AMuse]

It installs a backdoor which listens for incoming connections on UDP port 5503 or higher, and allows remote attackers to connect to, and take control of, an infected system.

Unless it also reconfigures my firewall to allow incoming traffic to port 5503 and higher and fiddles with my hosts.allow file, I'm not particularly concerned. Anyone who fails to have more than one layer of precaution on their system has a bit more to worry about.

Partial isinformation

[sigwinch]

Unless it also ... fiddles with my hosts.allow file, I'm not particularly concerned.

Whoa, cowboy! /etc/hosts.allow only affects friendly programs that bother to parse it (e.g., inetd, or programs that use tcpwrappers). An unfriendly program is free to ignore it.

However, your advice to use kernel firewalling is sound. 'Defense in depth' is the only way to go.

Don't worry, this is no Linux Code Red

[Xenna]

For starters to get infected with this animal requires activity on the part of a user on the Linux box.

Code Red required no user activity at all. A typical orphaned Linux box standing around in a corner would not be at risk, the same machine running IIS would have been a sitting duck for CR. There are a lot of orphaned servers out there with standard Redhat or IIS installs. These are the real danger. Any remote-root security holes on these popuplations are cause for real concern.

I don't know if I'm typical or not, but where I work, Linux is used on servers (yup, I'm responsible for that) but we hardly ever read our mail on a Linux box. We use a Windows platform for that. So -> no risk.

I'm thinking a Linux desktop user would be a better victim for this. Fortunately, hardly anyone uses Linux on the desktop so we're all safe!

Regards,
Xenna

I don't have much faith in the analysis

[phaze3000]

It also installs a backdoor in the infected host, listening on UDP port 5503 or higher. An attacker could connect to this port via TCP

Wait, so it listens on a UDP port, but it can be compromised using TCP? Do the people that analysed this actually bother proof-reading, or do they simply not understand what they write??

Re:I don't have much faith in the analysis

[Lord Bitman]

it listens on UDP. When it recieves the UDP request which contains the IP address and Port of the attacker, it will open a TCP connection to that IP & port. So it listens on a UDP port and the system gets compromised using TCP.

Re:What file did they find did this trojan infect?

[gimpboy]

that would imply that the debian servers were some how compromised. this is not impossible, but fairly unlikely.

that would be like installing a patch from microsoft that was infected with a virus.

most people have to trust someone and for those who dont there is always the sourcecode.