There's a post that will probably make it around every linux/oss news site within a few hours about a Linux trojan. I read the original at the link below, and it's a nice piece of work. This trojan can infect Linux ELF binaries, adding about 2700 bytes of its own code. It doesn't affect the function of the program it infects, but it does change the modified dates and size, which can be spotted by tripwire.
The trojan contacts 212.15.64.41:80 with an HTTP GET request, which can be spotted by a firewall or web proxy. Upon receipt of the http request, the remote site can make requests back to the trojan for a remote shell access. If the infected program is run by a privileged user or, worse, a scheduled SUID program, the remote shell has their privileges. n an infected system, the backdoor process creates a lockfile /tmp/982235016-gtkrc-429249277. The presence of this lockfile is an indication for a potential infection with Remote Shell Trojan. http://www.qualys.com/alert/remoteshell.html This has the potential to be worse than the Lion worm, but it's also identifiable by tripwire and some log monitoring. I think this would make an excellent topic for a LUG, especially while it's fresh. I haven't done tripwire, <blush>but I've skipped over countless magazine articles about how to set it up</blush>. Is there a tripwire guru in the house who'd like to tackle it for us? -- -j P.S. There's an interesting corollary for home users such as ourselves. The returning remote shell request will hit a UDP port at 5503 or higher. Blocking inbound high UDP ports at a firewall prevents attack of infected boxes. It also blocks inbound traffic of most online games. Most simple @home firewalls just masq outgoing traffic and allow all incoming traffic except on specific service ports like 139 and 111. For a gamer to play Quake, running its traffic in and out of the UDP 27900 range, we'd need something like ipmasqadm autofw to 1) monitor OUTgoing udp requests and 2) only accept INcoming replies to those specific requests. It still might leave one open to this remote shell request, if the attacker spots any inbound openings at all up there in the UDP ports. Anyone else have any input here? ================================================ BRLUG - The Baton Rouge Linux User Group Visit http://www.brlug.net for more information. Send email to [EMAIL PROTECTED] to change your subscription information. ================================================
