Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Security Unix IT Linux

New Mayhem Malware Targets Linux and UNIX-Like Servers 168

Bismillah writes: Russian security researchers have spotted a new malware named Mayhem that has spread to 1,400 or so Linux and FreeBSD servers around the world, and continues to look for new machines to infect. And, it doesn't need root to operate. "The malware can have different functionality depending on the type of plug-in downloaded to it by the botmaster in control, and stashed away in a hidden file system on the compromised server. Some of the plug-ins provide brute force cracking of password functionality, while others crawl web pages to scrape information. According to the researchers, Mayhem appears to be the continuation of the Fort Disco brute-force password cracking attack campaign that began in May 2013."
This discussion has been archived. No new comments can be posted.

New Mayhem Malware Targets Linux and UNIX-Like Servers

Comments Filter:
  • Too bad TFA doesn't mention this.

    • by AHuxley ( 892839 )
      Antivirus software for Linux might help over time for some issues?
      http://en.wikipedia.org/wiki/C... [wikipedia.org]
      • by sjames ( 1099 )

        Only as a last resort. AV software mostly excels at bringing a system to it's knees and making itself impossible to remove.

        What is needed is to close the hole that let it in.

        Meanwhile, most of the products in that list actually scan for Windows virueses!

    • by Anonymous Coward

      Not only that there is no mention of a vulnerability that cases a machine to get infected in the first place. There's nothing in there about how to prevent, or detect this.

    • Re: (Score:3, Informative)

      by dan_linder ( 84060 )
      From reading TFA, they mention some possible names:

      and drops a malicious shared object named 'libworker.so'


      After that, the PHP dropper creates a shell script named '1.sh',

      And for each of those, they present some example contents that could be used to verify it is part of this infection.

      • by mlts ( 1038732 )

        Sometimes I wonder if Linux should have functionality similar to AIX's trustchk.

        This command on AIX can make a list (signed with an OpenSSL key), then either warn when something runs that isn't on that list, or block it entirely. Functionality can be turned on to watch libraries as well, so if a library was changed, execution stops or a syslog entry is generated. In fact, it can be locked down so a reboot into another OS instance would be required to modify the trustchk settings.

        If someone has static scri

    • by Anonymous Coward

      Too bad TFA doesn't mention this.

      SHA256 hashes are provided for all the code analyzed.

    • one other thing it doesn't mention is "how" they detected the numbers of "affected" systems out there
  • "a very interesting and sophisticated piece of malware that has a flexible and complicated architecture." as linked.
    What do the plug ins offer?
  • by jones_supa ( 887896 ) on Friday July 18, 2014 @09:10AM (#47481785)
    The code snippets have too many colors [virusbtn.com] which in my opinion make them hard to read. What do you think?
  • by stewsters ( 1406737 ) on Friday July 18, 2014 @09:12AM (#47481797)
    For those who don't read articles, this appears to happen if you don't auto-update your software and are running php. Not to many details on what versions of software they are using, but it may be a time for a sudo apt-get upgrade.
    • For those who don't read articles, this appears to happen if you don't auto-update your software

      So it's like Windows?
      • It's like any system where abusing a known system weakness leads to profit.

        For reference, see politics and lobbying.

      • For those who don't read articles, this appears to happen if you don't auto-update your software
        So it's like Windows?

        In the sense that both are made by man and imperfect, yes. In the sense that patches come rapidly, no.

    • by Gothmolly ( 148874 ) on Friday July 18, 2014 @09:18AM (#47481851)

      And for those of you who DO auto-update blindly and destroy your app or your server when a bad version comes out, well, at least you can smugly assert that you were "secure".

      • No, you weren't. If that happens to you, your backup policy sure as hell was lacking!

        • A backup policy isn't going to help you here. The machine still needs to be re-installed via whatever method you choose along with the associated downtime and disruption - and then you do your restores. No one with any experience at all does 'auto' updating. Updates are scheduled in if they are needed.
          • Updates are scheduled in if they are needed.

            They are always needed. Sometimes eventually, sometimes quickly, and sometimes right fucking now. But you can never just be OK with old versions for long.

      • You can smugly assert that you were "secure", but everyone else can smugly assert that "you're doing it wrong!" by not testing or having any kind of backups to rollback any unwanted changes.
  • by Anonymous Coward

    The article seems to go in depth to the operation, commands, and purpose of the various shared libraries and scripts run by this malware, but it seems to skip out on the point of how these servers get infected in the first place....... Or maybe I skipped it - I was just perusing.

    • by raymorris ( 2726007 ) on Friday July 18, 2014 @09:39AM (#47481993) Journal

      Most of what we see in the wild is caused by improperly written PHP scripts which don't validate their input and then use crud like fopen_url. That provides the crackers the METHOD to put files on the server and execute them. SuExec gives web visitors PERMISSION to ad and modify files.

      Unfortunately, the folks at Plesk didn't read the first paragraph of the SuExec documentation before deploying it by default, so hundreds of thousands of DIY web servers are running with SuExec. (SuExec means allow visitors to modify files, but don't allow other clients hosted on the same shared server to do so).

      What the Plesk and DirectAdmin folks should have read, from the Apache SuExec page:

              Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run
              private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and
            possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the
              security issues they present, we highly recommend that you not consider using suEXEC.

      That last sentence bears repeatings. "If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC." Plesk, and DirectAdmin - your customers are not familiar with managing setuid programs and the security issue, so they should not even CONSIDER running suexec, much less have that foisted on them as the default.

      • by Anonymous Coward

        It provides a way to put files on the system... IF and ONLY IF the system is not using mandatory access controls.

        These attacks don't work then. Files can only be written to directories with permissions... and those permissions don't (or should not) include "execute". Thus the libraries are non-executable. The binaries dropped become non-executable... And they cannot access files/directories that do not have permissions for access by the web server... and can't drop files into directories that are not permit

        • It's very, very tricky (impossible?) to set that up right with the newer suckurity checks in recent version of SuExec, especially now that SELinux has removed *_disable_trans. Previously you could do it with httpd_suexec_disable_trans. Now mostly people resort to running Apache as a permissive context - effectively castrating the mandatory access controls in order to run soemthing that castrates the discretionary access controls (standard permissions).

          Also, before the new checks were added, SuExec could be

  • So this only works if you have /usr/bin/host installed?

  • Still old-school (Score:4, Insightful)

    by bluefoxlucid ( 723572 ) on Friday July 18, 2014 @09:32AM (#47481931) Homepage Journal

    I was going to release an RFC several years back that detailed malware communications protocols, but it was out-of-scope for an RFC and I figured it would be bad when people started using it. Plus IETF might not take that as an April 1 RFC.

    I had suggested that the malware be modular, and that it have a communications protocol using PKI, and an evolutionary module loading framework. It would take code for modules shipped across the network and try to compile them locally for various systems, then ship the binaries around. It would also divide when it got a new module: a kill module would just kill the weak strain. The proposal included detecting remote OS and shipping the correct primary executable code, as well as support code for cross-infection.

    The whole thing was a big argument for why we need a non-executable stack and strict rules preventing in-memory transitions between non-executable and executable pages. Data written in memory should never become code. Of course, people want to use JIT compilers, so...

    Modern malware still bores me.

  • Attack Vector (Score:5, Insightful)

    by Anonymous Coward on Friday July 18, 2014 @09:53AM (#47482091)

    "A lack of anti virus, and missing auto update features leave machines vulnerable"

    It astounds me the lengths the article writers go too while avoiding the attack vector:

    The admin must:
    1. allow a method to upload files
    2. allow php files to be up loaded
    3. Allow execution of these uploaded scripts
    4. Allow system / exec calls (disabled by default since forever ago)
    5. Allow the user to write their own crontab

    At that point, you might as well just install the infection through yum or apt.

    Seriously, there's a reason that the article numbers are less than 1% of the size of the average windows server infection..

    • Or, to put it another way, you can't fix stupid.


    • So, Plesk then... :)
    • Re: (Score:2, Insightful)

      by StormReaver ( 59959 )

      Seriously, there's a reason that the article numbers are less than 1% of the size of the average windows server infection..

      There are clearly many more Windows servers on the Internet than there are Linux servers. After all, if Linux had anywhere near the deployment of Windows, then Linux would experience the same rate of infection, right?


Money can't buy love, but it improves your bargaining position. -- Christopher Marlowe