Slashdot Mirror


ESET Discovers 21 New Linux Malware Families (zdnet.com)

In a report published last week by cyber-security firm ESET, the company detailed 21 "new" Linux malware families. All operate in the same manner, as trojanized versions of the OpenSSH client. From a report: They are developed as second-stage tools to be deployed in more complex "botnet" schemes. Attackers would compromise a Linux system, usually a server, and then replace the legitimate OpenSSH installation with one of the trojanized versions.

9 of 67 comments (clear)

  1. Now that you know ... by AlanObject · · Score: 4, Interesting

    Is there anything about this that checking the digital signature of the OpenSSH files wouldn't work? That probably should be done at boot time and then periodically after that.

  2. How is it malware, if you compromise the server... by Anonymous Coward · · Score: 4, Insightful

    How is it malware, if you have to compromise the server first??

    If you manage to compromise a system, then you can just put anything in there. Duh.

    Was this written by somebody from generation "i" again?

  3. On most Linux distributions, that already happens. by Anonymous Coward · · Score: 3, Insightful

    Or at least can happen, if you set it up.

    On Linux, you usually have a package manager. Which keeps the checksums/signatures of every file it installed, so it can do its package managing job. It will complain, when you try to uninstall/reinstall the package, and things have changed behind its back. (Unless it’s a configuration/data file, of course.)
    Want a regular check? Just use your package manager's helper tools in a cron script.
    (On Gentoo, you could query /var/db/pkg and compare the info there to the files. There’s certainly a tool for it, that I can't remember right now.)

    On top of that, you have RBAC systems, that generally disallow even altering such files by anyone, unless authorized. (E.g. the package manager would be authorized.)

    But all of this is utterly pointless. Because, as you can read, the whole thing requires that the server is first compromised, before the "trojan" is installed. (Making it not a trojan.)
    My current explanation is, that the writer must have been utterly clueless about all things computer.

  4. Article Summary by BringsApples · · Score: 4, Insightful
    Last sentence in the article:

    Unless Linux owners go out of their way to misconfigure their servers, for convenience's sake, they should be safe from most of these attacks.

    --
    Politics; n. : A religion whereby man is god.
  5. Re:Stupid by Skuld-Chan · · Score: 2

    Could go the Windows route and deem certain files critical to the system (ie - only trusted publishers are allowed to update the OS files), but then you'd have to have a list of publishers (based on certs) allowed to update the system. I don't think it's an entirely bad idea.

  6. Re:Stupid by whoever57 · · Score: 4, Informative

    Could go the Windows route and deem certain files critical to the system (ie - only trusted publishers are allowed to update the OS files), but then you'd have to have a list of publishers (based on certs) allowed to update the system. I don't think it's an entirely bad idea.

    Furthermore, you could require that the binaries are delivered in collections called "packages" and have the system require a valid signature and only recognize some signatures. Then you could have a distributed system for providing downloads of the signed packages. As long as the signature is valid, it doesn't matter what the source is.

    Oh, wait, every major Linux distribution has done this since almost forever, probably before Windows installers were signed.

    --
    The real "Libtards" are the Libertarians!
  7. Re:Stupid by ctilsie242 · · Score: 2

    SLS was doing this in 1992, Slackware had a better system in 1993, and both Debian and RedHat came out with decent package managers that used PGP/gpg signatures in 1994.

    Modern packaging systems do remember the hash of the files. A "rpm -Va" can easily point out changed binaries, and there are dedicated utilities like Tripwire and AIDE which do better.

  8. Re:APK & hosts files to the rescue (again)... by arth1 · · Score: 5, Informative

    1 botnet used IP address ONLY (unusual as ICANN sinkholes those fast & I've seen an 'uptick' in it lately - perhaps hosts IS making a 'dent' in 'badguys': For that - you need a firewall block rule OR wait out ICANN).

    No, you can easily block individual addresses through the routing table.
    ip route add prohibit N.N.N.N
    This works with networks too, like:
    ip route add prohibit 185.224.136.0/23

    If you have all of the nasties in a file, you can do something like this at startup, in an rc.local file or similar:
    xargs -r -n1 </etc/ipblocklist ip route add prohibit

    Also, while I have you here, many modern distros default to prefer DNS over /etc/hosts and only use /etc/hosts as a fallback, in which case your /etc/hosts list will not have any effect unless /etc/nsswitch.conf is modified.

    Example line in /etc/nsswitch.conf that will not work:
    hosts: dns [!UNAVAIL=return] files
    Example line in /etc/nsswitch.conf that will work:
    hosts: files dns

  9. Re:How is it malware, if you compromise the server by JabrTheHut · · Score: 2

    I noticed the "first breach the server" hand wave. It reminded me of Monty Python and the Holy Grail: "Well, now, uh, Lancelot, Galahad, and I, uh, wait until nightfall, and then leap out of the rabbit, taking the French, uh, by surprise. Not only by surprise, but totally unarmed!"

    --
    Work like no one is watching. Dance like you've never been hurt. Make love like you don't need the money.