Mayhem malware ropes Linux, UNIX servers into botnets

Discussion in 'malware problems & news' started by ronjor, Jul 18, 2014.

Thread Status:
Not open for further replies.
  1. ronjor

    ronjor Global Moderator

    Joined:
    Jul 21, 2003
    Posts:
    57,794
    Location:
    Texas
    http://www.net-security.org/malware_news.php?id=2813
     
  2. Umbra

    Umbra Registered Member

    Joined:
    Feb 10, 2011
    Posts:
    2,210
    Location:
    in a remote land :)
  3. ronjor

    ronjor Global Moderator

    Joined:
    Jul 21, 2003
    Posts:
    57,794
    Location:
    Texas
  4. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    Any news on how this thing is installed in the first place? The net-security.org article says something about a PHP script. Would that be delivered by e.g. a code injection vulnerability in a server? If it's actually exploiting a configuration flaw, a web server vulnerability, etc. that would be useful to know about...

    Edit:

    https://www.virusbtn.com/virusbulletin/archive/2014/07/vb201407-Mayhem

    This is actually really interesting. Kind of reminds me of userspace DLL trojans on Windows. Note the very typical use of LD_PRELOAD for nefarious purposes there... OTOH still no idea how that script executes in the first place. I will assume code injection for now.

    Re the conclusions though

    My experience is that sysadmins usually enable cron-apt or such, though I might be lucky there. The major problem IMO comes from third-party software (stuff not found in the distro repositories), and also from dumb corporate policies about never updating things that "work fine."

    As for running proprietary kernel-mode AV software on Linux, I think the less said on that the better.
     
    Last edited: Jul 21, 2014
  5. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    On a related note, this is a case where something like trusted path execution (namely having a trusted library path, and blocking untrusted library loading) would entirely put the kibosh on the malware. See, whitelisting isn't entirely useless. :p

    Edit: I think I have a way of preventing this malware from installing, by making LD_PRELOAD and LD_LIBRARY_PATH empty readonly variables. I will open a discussion of that in the UNIX forum.

    Edit 2: nope, it does not work, never mind. :( Give me a minute, I will see if I can find a way to prevent LD_PRELOAD tampering.

    Edit 3: Googling is not turning up anything, off to Stack Exchange I go...

    Edit 4: now I think of it, restricting LD_PRELOAD would be a very limited approach.

    I need to figure out a decent way of dealing with this. TPE would probably be best, but is hard to implement sanely on Linux; and is impractical on some servers due to the way they're set up... argh.
     
    Last edited: Jul 21, 2014
  6. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,087
  7. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    Charming. Do blackhats ever get tired of this inanity?
     
Loading...
Thread Status:
Not open for further replies.