Slashdot Mirror

← Back to Stories (view on slashdot.org)

Speedy Attack Targets Web Servers With Outdated Linux Kernels

Posted by Soulskill on from the update-your-junk dept.

alphadogg writes "Web servers running a long-outdated version of the Linux kernel were attacked with dramatic speed over two days last week, according to Cisco Systems. All the affected servers were running the 2.6 version, first released in December 2003. 'When attackers discover a vulnerability in the system, they can exploit it at their whim without fear of it being remedied,' Cisco said. After the Web server has been compromised, the attackers slip in a line of JavaScript to other JavaScript files within the website. That code bounces the website's visitors to a second compromised host. 'The two-stage process allows attackers to serve up a variety of malicious content to the visitor,' according to Cisco."

13 of 93 comments (clear)

  1. No Details by OverlordQ · · Score: 4, Insightful

    So the webserver was compromised and JavaScript was inserted and their first thought is it's the kernel?

    --
    Your hair look like poop, Bob! - Wanker.
    1. Re:No Details by X0563511 · · Score: 4, Insightful

      You clearly don't understand the lifecycle of a production OS.

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    2. Re:No Details by number6x · · Score: 4, Insightful

      Age of the code and the level of patches are two different things

      Older code has had more time for vulnerabilities to be found and patched.

      Newer code is, well, newer and has had less time for vulnerabilities to be patched.

      In general if you want to maximise vulnerability, run the oldest code, but apply no patches. The next most vulnerable general case would be to run the newest code because you are playing with untested fire and risking zero day exploits.

      In production systems it is usually best to run code that is old enough to be stable, well tested and well patched.

      There are counter examples when a long unknown exploit is discoverd, but the same kind of exploits could live in brand new code as well. However new code could contain some really simple exploits that will be patched pretty quickly. You don't want your production system to be the system opening up the tickets with support that find the exploit is the root cause. Because that means you've got to explain to your customers why their credit card numbers have all been stolen.

    3. Re:No Details by Nimey · · Score: 4, Funny

      Spot the guy who's never done professional IT.

      --
      Hail Eris, full of mischief...

      E pluribus sanguinem
    4. Re:No Details by Penguinisto · · Score: 3, Insightful

      You clearly don't understand the lifecycle of a production OS.

      ...nor does he understand the concept of back-porting patches, apparently.

      --
      Quo usque tandem abutere, Nimbus, patientia nostra?
    5. Re:No Details by markdavis · · Score: 3, Insightful

      You clearly don't understand what it means to run real-world business IT infrastructure. Just because something is oldler doesn't mean it is "outdated" or "insecure". RHEL/CentOS update the packages for a long time making them relevant and still secure through backporting and patches.

      Sometimes stability and reliability are far more important and efficient than constantly ripping everything out and starting over again every year or two. Besides, the more bleeding edge like Fedora and Ubuntu and Mint are more likely to have NEW security holes with less manpower behind them to fix it quickly.

      There is a reason that RHEL and CentOS are so popular for servers and "utility" boxes.

  2. Slashdot continues its decline by Nimey · · Score: 4, Informative

    All the affected servers were running the 2.6 version, first released in December 2003.

    Not even wrong. I guarandamntee you that none of the affected computers were actually running 2.6.0, and it wouldn't have been /that/ long ago that such an obviously stupid and ill-researched claim wouldn't have been posted.

    Soulskill, you /do/ understand that there were forty different versions of Linux in the 2.6 series, do you not? You do understand that the final 2.6 release was in August 2011 and it was numbered 2.6.39.4, which I know because I did 5 minutes of basic Googling?

    --
    Hail Eris, full of mischief...

    E pluribus sanguinem
    1. Re:Slashdot continues its decline by Bacon+Bits · · Score: 3, Insightful

      You didn't read the article, did you? TFS is vague, but so is the article. The article contains no details about the vulnerability. It only contains information about the severity and locations of the attacks. Comments on the article add "Version 2.6.18 appeared to be particularly prevalent." The article is shockingly limited on details.

      Slashdot's editors are often appear to be asleep at the wheel, but this time the editors weren't adding anything that wasn't in the original article.

      --
      The road to tyranny has always been paved with claims of necessity.
  3. Re:where's the door? by Anonymous Coward · · Score: 5, Informative

    I think its pretty unfair to refer to kernel 2.6, subversions of 2.6 were in use in one form or another from 2003 to 2011, 3.0 was brought about because Linus randomly decided to up the version number one day, not because of any single significant change. Plenty of old distros that still have security support are running 2.6 kernels that are regularly patched and completely up to date security wise.

  4. horrible article, author has no idea about 2.6 by Gothmolly · · Score: 5, Insightful

    "All of the affected web servers that we have examined use the Linux 2.6 kernel."

    Right, because RHEL (and Centos) run 2.6.... so sampling ANY number of servers is likely going to show that they run 2.6.

    Is Slashdot just a click redirector these days? Do 'editors' remotely 'edit' anything?

    --
    I want to delete my account but Slashdot doesn't allow it.
  5. Re:where's the door? by hermitdev · · Score: 3, Interesting

    While it is supported, and RH claims backwards compatibility, they do have an annoying habit of breaking things. I remember going from a point minor version of RHEL 5 (I think it was 5.5 to 5.6; it might have been an earlier release) to the next, and they broke the behavior of semaphores. In the prior version, a "sem_wait" would block until the semaphore was signaled, in the next version, it'd indicate errno EAGAIN. This was an unexpected change and required code changes for my company's apps at the time to busy wait when trying to acquire a semaphore.

  6. Worse than No Details: by Penguinisto · · Score: 5, Informative

    It gets worse (or IMHO, less competent):

    Author Comment FTFA (bottom of page - emphasis mine):

    "We haven’t identified the initial attack vector. We have no reason to suspect that the attack isn’t via http. I’d be very interested to hear from any affected sys admins if they identify how the attackers gain access."

    In other words, they don't even know if it's the effing kernel at this point -all they know is that 2,000 some-odd websites have been bit, and they all use the absolute most common kernel version for webservers on the planet (2.6.x).

      Hell, for all we know it could be some commonly-shared crappy PHP script getting popped. :/

    --
    Quo usque tandem abutere, Nimbus, patientia nostra?
  7. Read the comments first. by shipofgold · · Score: 3, Interesting

    The comments at the end of the CISCO article flush out the fact that they noticed a line of malicious javascript at the end of a large number of .js files but they have no idea how it got there.

    In fact the list of JS files given include many that are not even running on Linux servers.

    The author is irresponsible at best, and incompetent at worst...