Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Mystery Malware Affecting Linux/Apache Web Servers

Posted by Zonk on Thu Jan 24, 2008 02:46 PM
from the duck-and-cover-like-tommy-the-turtle dept.
Security Software Apache
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."'"
+ -
story

Related Stories

Submission: Mystery malware affecting Linux/Apache Web servers by lisah (987921)
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Mystery Malware Affecting Linux/Apache Web Servers 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • 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.

  • 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!

  • 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.

  • 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.)

  • 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) <convivialdingo@@@yahoo...com> 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: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:ssh + bad password (Score:5, Informative)

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

        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.

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

              by Panaflex (13191) <convivialdingo@@@yahoo...com> on Thursday January 24 2008, @07:05PM (#22175552)
              Sorry, I wasn't clear:

              I've had admins on my network simply copy both pub & private ssh keys from server to server (they're in the same directory). They leave the private keys on the machine and forget or don't know what they've done. An attacker with root on that machine can then su into the account and access other machines.

  • 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.

    • Re:Ubuntu as well? (Score:4, Insightful)

      by PrescriptionWarning (932687) on Thursday January 24 2008, @02:53PM (#22171862)
      "the current thinking is that the malware authors gained access to the servers using stolen root passwords"

      so basically its most likely they used the traditional means of gaining access (not through holes, but merely through bad personal security practices regarding passwords and password management). And it only affects windows clients. So how is this problem not your typical someone cracked your machine? Oh wait, I smell Microsoft FUD... ewwwwww

      • Re:Ubuntu as well? (Score:5, Insightful)

        by nicklott (533496) on Thursday January 24 2008, @03:35PM (#22172588)
        Microsoft? This story is on posted on linux.com and being hyped on a OSDN site, where do microsoft come in? They must have a pretty deep mole to get this one planted...

      • Re:Ubuntu as well? (Score:4, Insightful)

        by Christianfreak (100697) on Thursday January 24 2008, @04:20PM (#22173284) Homepage Journal
        Exactly. Also this gem from the article:

        Other than using and safeguarding secure root passwords, not much can be done at this time to be proactive in preventing servers from being compromised,

        Turn off root's log in and get rid of cPanel and similar programs as well. I understand the need for an easy to use remote admin tool (as much as I'd love people to actually learn the shell), but can't we do better than a web-based program for this stuff?

        • Re:Ubuntu as well? (Score:5, Insightful)

          by stuntpope (19736) on Thursday January 24 2008, @04:55PM (#22173806)
          His main point was insightful. There are two parts to the story - one, Linux servers running Apache have been compromised. Two, these servers are infecting Windows clients through vulnerabilities in those clients. This exploit does not affect non-Windows computers.

          If the current thinking is indeed that the Linux servers were inappropriately accessed through stolen passwords, how is that a security flaw of Linux or Apache? Like he asked, how is using a legitimate password equal to cracking the server?

          On the other hand, turning Windows clients into bots *IS* an example of that software's (and QuickTime's and Yahoo! Messenger's) insecurity and vulnerability!

    • Re:Ubuntu as well? (Score:4, Insightful)

      by symbolset (646467) on Thursday January 24 2008, @03:19PM (#22172304) Journal

      It's possible to install software on a Linux webserver that exploits vulnerabilities in Windows clients. This is news?

      Here's a shocker: it's possible to exploit Windows boxes with services hosted on a Commodore64.

      Windows has more malware packages than legitimate software packages. They've really solved that ease of installation problem.

    • Re:Funny (Score:5, Insightful)

      by Undead Ed (1068120) on Thursday January 24 2008, @02:57PM (#22171922)
      According to the story (did you read it), it appears to be a situation where the root password has been compromised, not the applications or operating system.

      Problems with IIS were as a result of vulns in the application and/or Windows operating system - totally different problem.

      Would you blame a lock company if the user left his keys in the lock?

      Ed

      • Re:Funny (Score:5, Insightful)

        by plague3106 (71849) on Thursday January 24 2008, @03:02PM (#22172042)
        I read it, here's what it said: "One great unknown thus far is how the servers come to be infected. Absent any forensic evidence of break-ins, the current thinking is that the malware authors gained access to the servers using stolen root passwords."

        In other words, they have no idea how the servers were compromised. Because they can't find out how, they're guessing it was a root password that was stolen. In other words, its still just as likely a flaw in some software.

        • Re:Funny (Score:5, Insightful)

          by Undead Ed (1068120) on Thursday January 24 2008, @03:11PM (#22172182)
          "they're guessing it was a root password that was stolen"

          A pretty good guess, otherwise we could expect to see millions of Apache web servers compromised (there are over 75 million Apache web servers in active service) and anticipate a much greater number of Windows clients infected.

          The significance of this story is not that Windows clients are the target, the significance is that the infecting agent is originating from Apache/Linux servers.

          Ed

      • Re:Funny (Score:5, Funny)

        by studpuppy (624228) on Thursday January 24 2008, @03:15PM (#22172240)
        Would you blame a lock company if the user left his keys in the lock?"

        Depends. How good is my lawyer?

    • Re: (Score:3, Informative)

      by Vellmont (569020)

      I think it's funny that Apache is affected by the same drama that affected IIS all those years ago.

      Except IIS had security hole after security hole.

      There's been no such security hole found in apache yet. So I'd wait before making comparisons to IIS.

    • Re:Software sucks. (Score:5, Insightful)

      by vux984 (928602) on Thursday January 24 2008, @03:18PM (#22172292)
      It's high time for better software, and the only way to get that is to apply market pressure. Software liability is the answer.

      1) If the market really wanted extensive 'software liability' then we'd already have it. Customers would demand it, suppliers would figure out how much it would cost to provide it, and prices would sort themselves out. Turns out the prices go WAY up, and customers (most of them) don't want to pay them.

      2) What happens to Linux in a world with mandatory software liability? Who is liable? The company providing install and support? The volunteer contributor who wrote that line of code? The project maintainer who accepted the patch? ... And you wonder why your post was modded flaimbait?

    • Re:Software sucks. (Score:5, Funny)

      by Schraegstrichpunkt (931443) on Thursday January 24 2008, @03:24PM (#22172398) Homepage
      Yeah. People should be held liable when they know full well that Microsoft has a track record for bad security, but choose Microsoft products anyway.

    • Re:Software sucks. (Score:5, Insightful)

      by mlwmohawk (801821) on Thursday January 24 2008, @04:01PM (#22173012)
      Software has to suck because the market can't afford software that doesn't suck. Kids out of high school and collage or fresh out of joe's web school. aren't qualified to write good software, yet this is what companies hire over more experienced people.

      Even then, there is no ability to develop your skills because you spend 99% of your time learning new environments.

      Software is HUGELY complex these days and it takes a log of study, knowledge, and skill to be any good at it. Companies don't want to hear that. They want to increase productivity by "KLOC." (Un)fortunately, there is a lot of "art" and "creativity" in software development and without well defined product specs, rigid test plans, and quality assurance which adds delays and cost to a project you won't get better code.

      Standard business upside potential vs downside risk. Upside potential: first to market, profit!!! Downside risk: blame some hacker.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.