Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Software Apache

Mystery Malware Affecting Linux/Apache Web Servers 437

Posted by Zonk from the duck-and-cover-like-tommy-the-turtle dept.
lisah writes "Reports are beginning to surface that some Web servers running Linux and Apache are unwittingly infecting thousands of computers, exploiting vulnerabilities in QuickTime, Yahoo! Messenger, and Windows. One way to tell if your machine is infected is if you're unable to create a directory name beginning with a numeral. Since details are still sketchy, the best advice right now is to take proactive steps to secure your servers. 'We asked the Apache Software Foundation if it had any advice on how to detect the rootkit or cleanse a server when it's found. According to Mark Cox of the Apache security team, "Whilst details are thin as to how the attackers gained root access to the compromised servers, we currently have no evidence that this is due to an unfixed vulnerability in the Apache HTTP Server." We sent a similar query to Red Hat, the largest vendor of Linux, but all its security team could tell us was that "At this point in time we have not had access to any affected machines and therefore cannot give guidance on which tools would reliably detect the rootkit."'"
This discussion has been archived. No new comments can be posted.

Mystery Malware Affecting Linux/Apache Web Servers More

Mystery Malware Affecting Linux/Apache Web Servers

Comments Filter:

  • Should have used IIS (Score:5, Funny)

    by Anonymous Coward on Thursday January 24, 2008 @02:51PM (#22171832)
    This is why serious businesses choose a serious web server: Microsoft Internet Information Services running on Microsoft Windows Server.

  • Something's fishy! (Score:5, Funny)

    by linumax ( 910946 ) on Thursday January 24, 2008 @02:54PM (#22171876)
    Last night I discovered a directory named 53 4B 59 4E 45 54 in my home folder.

  • Hummm, no ahah ?! (Score:2, Interesting)

    by DirtyFly ( 765689 )
    I do believe tht if this story was with IIS it would be tagged ahah :)

  • press release?? (Score:2, Insightful)

    by Anonymous Coward
    "According to a press release issued earlier this month ..."

    Yawn.
    • "According to a press release issued earlier this month ..."
      Yawn.

      Interesting.

      Someone posts a story about compromised Apache servers and all it rates from the Geek is a yawn.

  • Does this rootkit work on a hardened Gentoo install with no LKM support on SPARC64? :P

    -:sigma.SB

  • mkdir 1 (Score:5, Insightful)

    by hey ( 83763 ) on Thursday January 24, 2008 @02:58PM (#22171968) Journal
    I can see thousand of people trying to make numeric directories :)
    Yes, also if you can run your tummy while patting your head you aren't infected also.
    I think.... this crazy idea is the virus!
    • I rushed off to try it myself. I used to be on a shared hosting service (hostreflex) that had their servers pwned once. Something would go out in the header of every PHP file that would get the browser to run the virus. Luckily my virus scanner blocked it. I'm not sure if anybody's computers got infected, but my site is pretty low traffic anyway. As soon as I found out the problem, I replaced my home page with a plain text file. No more problem. Needless to say I switched hosting companies pretty fas

    • Well... (Score:2, Funny)

      by Anonymous Coward
      I did a mkdir 09F911029D74E35BD84156C5635688C0 and all I got was a DMCA rm -f 09FA* request.
    • Yes, also if you can run your tummy while patting your head you aren't infected also.

      Uh oh. I have no idea how to run my tummy. Crap, I must be infected!

    • Re: (Score:2)

      by mblase ( 200735 )
      I can see thousand of people trying to make numeric directories :)
      Yes, also if you can run your tummy while patting your head you aren't infected also.

      I heard that if you can spread your fingers and your hand covers your entire face, your server is infected.

    • Re: (Score:2, Informative)

      by grub ( 11606 )

      I can see thousand of people trying to make numeric directories :)

      I just mkdir'd a numeric directory then remembered I run OpenBSD on my net-facing servers. :P

    • Are your R's and B's "Crossover" keys, or Virtual Keys, or VirtualBox keys?

      Run your tummy makes me think of being run over, or loosing a hot bowel of a lahar surmounting, umm, surpassing even Mt. Pinatubo.

    • Re: (Score:2)

      by garcia ( 6573 )
      From the linked article:

      This isn't always the case in older variants of the rootkit. To be certain your server isn't compromised, it's best to sniff packets for a brief 3-5 minute period. You can do this using the command below:
      tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'"

      That's another way to check apparently.

      • Re: (Score:3, Informative)

        by padyer ( 453675 )
        That regex is b0rken. It matches any file of at LEAST 5 chars that ends in .js. The story at cPanel says that it is exactly 5 random chars and then the .js. Should be changed to

        tcpdump -nAs 2048 src port 80 | grep "/[a-zA-Z]\{5\}\.js'"

        Note the / at the beginning of the grep regex.

    • Re: (Score:2)

      by ls671 ( 1122017 )
      I just tried it and damn I think I am infected since the system won't let me create the directory named "1".

      $ mkdir 1
      mkdir: cannot create directory `1': File exists

  • Read it careful people... (Score:3, Informative)

    by cbart387 ( 1192883 ) on Thursday January 24, 2008 @03:01PM (#22172024)
    The servers are linux (because of an access issue. The computers being hurt by this are windows. At least that's how I read the article (see quote from article below).

    According to a press release issued earlier this month by Finjan, a security research firm, compromised Web servers are infecting thousands of visitors daily with malware that turns their Windows machines into unwitting bots to do the bidding of an as yet unidentified criminal organization. Security firms ScanSafe and SecureWorks have since added their own takes on the situation, though with varying estimates on the number of sites affected. All reports thus far say the compromised servers are running Linux and Apache.

  • Can't be malware (Score:3, Funny)

    by Anonymous MadCoe ( 613739 ) <maakiee@NoSpam.yahoo.com> on Thursday January 24, 2008 @03:04PM (#22172076) Homepage
    It's for Apache/Linux so it must be well crafted code written with the best intention....

    Isn't that always the case with FOSS. If it was for Microsoft then it would be _real_ malware....

  • What are the common factors? (Score:5, Insightful)

    by Arrogant-Bastard ( 141720 ) on Thursday January 24, 2008 @03:07PM (#22172122)

    To figure out what the compromise vector is, it's probably going to be necessary to figure out what the compromised servers have in common -- and how that differs from uncompromised servers. (Keeping in mind that currently-uncompromised servers may have the same vulnerability, and that attackers or their software just may not have gotten to them yet.)

    I'd suggest enumerating factors such as OS, OS version, remote access methods (ssh, ftp, etc.), Apache versions, Apache modules, add-ons like CPanel, network/ASN, and so on -- anything could be a culprit at this point.

    And that includes things that have nothing to do with Linux or Apache: for example, it's possible that the attackers acquired root passwords by infecting Windows systems used by administrators -- then just waited for them to initiate ssh sessions to their servers. It'd probably be best to leave all possibilities open and consider them equally likely until evidence starts accumulating in favor of/against them. (In re-reading that last statement, I suppose it sounds a bit trite. I'm just trying to discourage premature conclusions that anything is at fault until somebody can produce evidence to support saying so.)

    • Re:What are the common factors? (Score:5, Insightful)

      by whoever57 ( 658626 ) on Thursday January 24, 2008 @03:27PM (#22172440) Journal

      To figure out what the compromise vector is, it's probably going to be necessary to figure out what the compromised servers have in common -- and how that differs from uncompromised servers. (Keeping in mind that currently-uncompromised servers may have the same vulnerability, and that attackers or their software just may not have gotten to them yet.)
      Perhaps this is the end result of all those dictionary attacks against SSH servers that we have seen for the past 2-3 years. Inevitably, some of those attacks will have been successful. Perhaps the successful logins have not ben exploited until now.

      • Re: (Score:3, Insightful)

        by Arrogant-Bastard ( 141720 )

        That (use of data harvested from ssh attacks) is entirely possible. Some of those attacks had to successful against some hosts.

        So maybe one possible line of investigation would be to see if any hosts which defended against ssh dictionary attacks (say, by throttling back or denying connections from hosts that made too many ssh tries) were compromised. (I suppose it'll also be necessary to assess the strength of their root passwords; sufficiently weak ones might not require a concerted ssh attack to be com

    • Re:What are the common factors? (Score:4, Informative)

      by imipak ( 254310 ) on Thursday January 24, 2008 @04:13PM (#22173188) Journal
      Apparently it's not Cpanel.

      Other info as of last week:

      Various discussions:
      http://www.webhostingtalk.com/showthread.php?t=651748 [webhostingtalk.com]
      (useful discussion starts on page 3 or so)
      http://www.theregister.co.uk/2008/01/11/mysterious_web_infection/ [theregister.co.uk]
      (describes the inability of ScanSafe to work out what's happening)
      Trend have a piece on their blog:
      http://blog.trendmicro.com/e-commerce-sites-invaded/ [trendmicro.com]
      SANS/ISC
      http://isc.sans.org/diary.php?storyid=3834&rss [sans.org]

    • Re: (Score:3, Informative)

      by Alioth ( 221270 )
      It's quite possibly due to buggy PHP scripts. I've seen it before; what happens is the attacker goes for some unpatched vulnerability in PHPnuke, PHPbb or similar software. This gets them non-root access. They use this to 'wget some-hack.c' to the /tmp directory, build this hack then execute this to exploit a local root exploit.

      This is why I treat all local root exploits as seriously as remote root exploits. All it takes is one buggy PHP script and then the attacker can try local root vulns.

  • The register's older writeup on this ... (Score:5, Informative)

    by chris.dag ( 22141 ) on Thursday January 24, 2008 @03:07PM (#22172126) Homepage
    The Register has been on this for a while and although the story is older it is better written and has more interesting details: http://www.channelregister.co.uk/2008/01/16/mysterious_web_infection_continues/ [channelregister.co.uk]

    my $.02 of course

  • ssh + bad password (Score:5, Informative)

    by Panaflex ( 13191 ) <[moc.oohay] [ta] [ognidlaivivnoc]> on Thursday January 24, 2008 @03:11PM (#22172170)
    I see this type of attack all the time, the fact that someone automated it and gave it a zombie machine is not surprising.

    * Don't allow root to ssh into your machine.
    * Disable ssh1.
    * Limit sudoers.
    * Have good passwords.
    * ???
    * PROFIT!!

    Seems like a formula everyone should know.

    • Re: (Score:2, Informative)

      by whoever57 ( 658626 )

      * Don't allow root to ssh into your machine.
      Dangerous if you don't have easy physical access to your machine. It is possible to screw up a machine in such a way that a normal user cannot log in, but root can. It is better to:

      * Disable password authentication in SSH -- require key-based authentication

      • Re: (Score:3, Informative)

        by Panaflex ( 13191 )
        That's a good idea - but be careful!

        Attackers can trampoline onto other machines in the network if they share the same key. If you're going to do then be careful about which machines can freely contact each other, and use separate keys for each server.

      • Re: (Score:3, Insightful)

        by PinkPanther ( 42194 )
        If someone is going to render there machine usable only by root, then I strongly doubt they've taken the time or have the knowledge to implement security precautions listed above. If they know how, they likely should and likely won't render their machine useless.

        In addition, if they really might render the machine useless, they likely shouldn't have it on the 'net.

      • Re: (Score:3, Interesting)

        by mi ( 197448 )

        * Don't allow root to ssh into your machine.

        Dangerous if you don't have easy physical access to your machine.

        No, it is not. On *BSD family of Operating Systems root can only login on the local console anyway.

        If you screw something up badly, you ssh in as yourself first, and then perform `su' — something, that only members of the wheel-group (gid 0) are allowed to do.

        My FreeBSD machines all run a crude log-watcher [virtual-estates.com], which blocks-out machines, from where root- and similar logins are attempted, i

    • Re: (Score:3, Interesting)

      by ScouseMouse ( 690083 )

      * Don't allow root to ssh into your machine.


      I was most surprised when I found that Redhat (Our cooperate Linux of Choice) appears to allow this as the default. Certainly, The Debian box i use as a home server never used to allow that, however, checking i see that since I upgraded from Woody, it does allow remote SSH as root. Thats worrying.
      Well have to fix that.

    • Re: (Score:3, Interesting)

      by mandelbr0t ( 1015855 )

      Allow me to insert one step before ???

      * Follow-up on your SSH logs. If you see a phishing attack, do something about it!

      That something could be:

      - Report the IP to the owner of the netblock who can be found at ARIN [arin.net]. All netblock owners must have an IP-admin address or an abuse address. Unfortunately, my experience is that most of these go to /dev/null. There are those who actually have responsible NOC staff, and they will act on your complaint if you send them a copy of the relevant logs.

      - Block furth

    • Re:ssh + bad password (Score:5, Interesting)

      by ls671 ( 1122017 ) on Thursday January 24, 2008 @03:44PM (#22172718) Homepage
      You should also have some process that completely blocks ssh login attempts from a given IP after so many failed login attempts instead of letting the hi-jacker poll your machine for as long as he wishes.

      • Re: (Score:3, Informative)

        by Crimsonjade ( 1011329 )
        I personally use http://www.fail2ban.org/wiki/index.php/Main_Page [fail2ban.org]

      • Re:ssh + bad password (Score:5, Informative)

        by Niten ( 201835 ) on Thursday January 24, 2008 @05:42PM (#22174512)

        I'll see your good point, and raise you a pf.conf snippet:

        ### MACROS AND TABLES SECTION
        table <wan_bruteforce> persist

        ### PACKET FILTERING SECTION
        block in quick on $if_wan inet from <wan_bruteforce>
        # ...
        pass in on $if_wan inet proto tcp from any to ($if_wan) \
        port ssh flags S/SFRA synproxy state \
        (max-src-conn-rate 3/30, overload <wan_bruteforce> flush global)

        That's how you can block non-massively-distributed password dictionary attacks on the BSDs, anyway. Sadly, the fact that OpenBSD's firewall can perform this task on its own means that we probably won't see this feature worked into OpenSSH itself any time soon -- so on Linux you'll need a third-party script such as DenyHosts [sourceforge.net], as others have already pointed out.

        (And yeah, unlike this PF configuration, DenyHosts lets you synchronize your table with a sort of universal blacklist of blocked hosts, so some might choose to run it on BSD anyway. It sounds like a good idea on paper, but boy does it suck when your home IP address keeps inexplicably winding up on the blacklist due to what turns out to be a single site's massively misconfigured server.)

        But I think the most important lesson to be learned here, assuming that this thing does turn out to be an ssh attack, is that allowing single-factor, password-based administrative logins to a highly connected host is never a good idea. If you have the luxury of complete control over the site and its users (or are simply a highly empowered BOFH), disable password-based logins entirely and force the use of ssh public keys:

        # /etc/ssh/sshd_config
        PubkeyAuthentication yes
        ChallengeResponseAuthentication no
        PasswordAuthentication no
        KerberosAuthentication no
        GSSApiAuthentication no
        UsePAM no

        As a concession, if you want to ensure access without having to carry around an encryption key on a USB dongle, on Linux you can use PAM and libpam-opie to set up secondary access using a dual-factor combination of an S/Key one-time password and your regular login password (S/Key [wikipedia.org] is like Steve Gibson's much-trumpeted "Perfect Paper Passwords [grc.com]" system, which is ingenious in its own right, except that S/Key is designed so that you don't need to keep your secret key stored unencrypted on the very server you're worried about protecting):

        # /etc/ssh/sshd_config
        PubkeyAuthentication yes
        ChallengeResponseAuthentication yes
        PasswordAuthentication no
        KerberosAuthentication no
        GSSApiAuthentication no
        UsePAM yes

        # /etc/pam.d/ssh
        auth requisite pam_opie.so
        auth required pam_unix.so nullok_secure

        With the above configuration you can still log in seamlessly using your ssh private key. But if you get stuck somewhere without access to your private key, you just pull your S/Key passwords list out of your pocket and enter the next password in the sequence, as prompted, followed by your login password. This PAM configuration has the nice property that if you enter the correct S/Key password but then an incorrect Unix password, you will be asked for the next one-time password in the sequence before you can continue: so unless your attacker is exceptionally good at plaintext attacks on large cryptographic hashes, a successful brute-force attack becomes impossible.

        Wow, this post got a lot longer than I wanted it to... I'm, um, going out to get some fresh air or something.

  • More details are available... (Score:4, Informative)

    by Anonymous Coward on Thursday January 24, 2008 @03:38PM (#22172634)
    ... though a solution has not been yet:

    http://blog.trendmicro.com/e-commerce-sites-invaded/ [trendmicro.com]

    If you happen to have one of these compromised systems, I am sure that Trend would like to talk to you about it...

  • I'm not sure I buy it (Score:5, Insightful)

    by mlwmohawk ( 801821 ) on Thursday January 24, 2008 @03:40PM (#22172676)
    There is something suspicious about this report. Some things can't happen the way people say they happen, and when that is the case we have to look at more likely scenarios.

    I would bet the path of the TCP/IP packets route through compromised providers who have an injection strategy. Remember a few months ago how IPSs were injecting their own java script and ads into the pages of other sites?

    http://ars.userfriendly.org/cartoons/?id=20070703 [userfriendly.org]

    This is the most likely scenario I can think of.

Slashdot Top Deals

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Close