Slashdot Mirror

← Back to Stories (view on slashdot.org)

Worm Exploiting Solaris Telnetd Vulnerability

Posted by Zonk on from the beware-of-rotten-fruit dept.

MichaelSmith writes "Several news sites are reporting that a worm is starting to exploit the Solaris Telnet 0-day vulnerability. By adding simple text to the Telnet command, the system will skip asking for a username and password. If the systems are installed out of the box, they automatically come Telnet-enabled. 'The SANS Internet Storm Center, which monitors Internet threats, has noticed some increase in activity on the network port used by Solaris' telnet feature, according to an ISC blog posted on Tuesday. "One hopes that there aren't that many publicly reachable Solaris systems running telnet," ISC staffer Joel Esler wrote.'"

8 of 164 comments (clear)

  1. Telnet for transparency? by Anonymous Coward · · Score: 4, Interesting

    A while ago I found a strange comment here about why telnet was still used, even by security-knowledgeable IT department. The comment was saying this:

    Large financial institutions in Europe use telnet, as use of encryption is restricted on their trusted networks, for reasons of transparency to the stock regulating authorities. (Googling for this phrase should get you the /. comment)

    If this is true (and not the post of a random troll), can anyone shed some light on this? For it seems very strange... There are many other way to provide transparency to the financial authorities without having to compromise your network no!?

    1. Re:Telnet for transparency? by Anonymous Coward · · Score: 1, Interesting

      You're right with that. Not only financial sector - many large companies do that.

      I work for a small company that does some support jobs in several larger companies - mostly over VPN or ISDN - and on some companies external access via SSH is forbidden by policy. Reasons I was told were:
      * We can't monitor you if your traffic is encrypted
      * SSH has too many features (i.e. port forwarding)

      And yes, I do know how lame those reasons are and easy to circumvent. But try to convince an IT-Department standardizing vor 30000+ empoyess if your own company barely reaches 40. I really would like to meet one of those decision makers once....

      Interesting thing is, some other clients forbid telnet (cheers to them!) and push towards SSH.

      For us it's simply annoying, as you might be stumped when you try to login and get 'connection refused' and after five minutes realize: "aaah this client forbid SSH".

  2. Re:A new box won't have this problem... by Anonymous Coward · · Score: 1, Interesting

    Check again. In update 3, you have to choose the checkbox other than the default
    to disable services!

  3. Re:Yep. by ray-auch · · Score: 2, Interesting

    But the real question is, should systems be shiped with telnet enabled? Obviously the answer is "no", but vendors seem to be slow to get this message.

    This is Sun. Remember "+" in hosts.equiv ? They deliberately shipped with a known insecure default config in order to reduce support costs / complaints ("ease-of-use" was allegedly considered more important than security).

  4. Correction by Megane · · Score: 2, Interesting

    Correction: that's one of the first things any good distro never turns on.

    Linux and BSD had it for a long time before Solaris had it in the standard install. And you can't even enable telnetd on OS X since about 10.2 or so, unless you know how to edit the right config files in /etc.

    --
    #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
  5. Re:Computer Security by SanityInAnarchy · · Score: 2, Interesting

    It's such a joke that every one claims to be more secure then the next guy. But really they mean if you turn everything off and patch your system every day.

    Which is the default, these days.

    That's what a 0 day exploit means. You have to patch every day or you could be at risk.

    No, a 0 day exploit means even if you patch every day, you're still at risk. But you know what? You're at risk every day simply by being alive. You could be hit by a meteor the next second! Oh noes!

    Grow up and stop fearmongering. There's plenty of real security threats without saying "Everyone's insecure!"

    Having a patch isn't even that great of a deal. The patch usually provides the problem and then it's off to the races.

    I'm sorry, what? The patch provides the problem... I think I know what you mean, but this just makes you sound like an idiot. The patch fixes the problem. It may provide new problems, but it fixes the ones it's meant to fix.

    How long to patch X number of systems versus how long to write an exploit. Even if you are 1% of the market, it's a losing race for the patchers.

    How do you figure? Got any numbers to show me, or is this just blind speculation?

    Here's a hint: If you've got an open source system, someone who finds an exploit is much more likely to send in a patch than to release said exploit into the wild. I know that's the case with me -- given the choice between patching Linux and exploiting Linux, I'll patch it. Given the choice between waiting six months for MS to patch something and exploiting it myself, I'll exploit it. And if you've got everyone's system updating every day, then it truly does become a losing race for someone to find the patch, develop an exploit, and begin using it before my system automatically patches itself.

    Then there are all of the poor orphaned systems out there that don't have any one to maintain them. Who will patch these poor unfortunates?

    Who relies on these poor unfortunates? Not anyone who cares about security. I mean, yeah, if you're running Win98, you're better off leaving the thing unplugged, but...

    The only time a computer is secure these days is when the network cable is unplugged and/or the on/off switch is off.

    I hate hearing this. Not only is it simply wrong (I can still pick the computer up and carry it off), but it's often used as some sort of excuse for computer security being as bad as it is.

    I think Linux and the BSDs are pretty secure. I'm still annoyed at how frequently exploits are found.

    But notice how you took two examples: A zero-day exploit, and old, unmaintained systems. Everything else you mentioned is basically saying the sky is falling because no one is secure, and therefore we can't say anyone is more secure than anyone else? How twisted is that?

    Obviously, if I post my root password and IP address here, I AM less secure than everyone else. So, obviously, there are degrees of security.

    And maybe everyone does become vulnerable at some point. It doesn't mean we're all doomed -- security is entirely based on economics. You're not 0wned unless it's worth it for you to be, and it's just not worth it if I'm running a custom-compiled Linux kernel and Gentoo system, all kinds of stuff tweaked by hand, and no particular reason they'd want me except CPU cycles and bandwidth. As long as there's dozens of Windows boxes they can 0wn automatically, they aren't going to get me.

    Still, if you're so convinced the exploiters will always beat the patchers, go ahead and try. Crack my box, and leave me an email from myself explaining the situation. Until then, I'll reamin convinced you know nothing about security except that old "Nobody's secure" bullshit.

    --
    Don't thank God, thank a doctor!
  6. Re:It's been a long day... by dknj · · Score: 2, Interesting

    Judging by your UID, i will assume you are new here and new to IT in general. In The Real World(tm), patches are not applied as soon as they are released. You must test them, most managers are clueless to OS level patches and require the same testing process that, say, application testing goes through. I have seen patches take a week to be approved and put into production and I have worked with companies that have a 30 day delayed patch release schedule.

    With that said, no one should be running any insecure applications in production..... but people/organizations do. X servers running as root with all hosts allowed to connect. Passwords with abc123. This is entirely the fault of the admin, but sometimes cannot be altered without beauratic hoopla (all you can do in this case is CYA and make it visible to upper management).

    Lastly to quell all these "ZOMG SOLARIS IS TEH SUX0R" comments.. Solaris 10 only enables telnet when the admin specifically requests it during installation. Let me say it again, the admin has a choice to install telnet and enable it during installation. Plus who installs Solaris by hand when you have Flash Archives/Jumpstart to do the work for you?>

  7. Hahaha, Sun network apparently got hit by the worm by Anonymous Coward · · Score: 1, Interesting

    According to this blog entry (see http://zetarace.blogspot.com/2007/03/dont-use-teln et.html), his honeypot network caught one of the worm attempt.

    [**] [1:10136:3] TELNET Solaris login environment variable authentication bypass attempt [**]
    [Classification: Attempted Administrator Privilege Gain] [Priority: 1]
    03/01-13:44:29.556771 192.18.17.206:1134 -> 192.168.0.34:23
    TCP TTL:46 TOS:0x0 ID:52835 IpLen:20 DgmLen:86 DF
    ***AP*** Seq: 0xED89493C Ack: 0x9D57147C Win: 0xC4E0 TcpLen: 20
    [Xref => http://www.securityfocus.com/bid/22512%5D

    However, looking at the source ip attacking his honeypot machine.. seems it's coming directly
    from Sun network range:

    whois 192.18.17.206

    OrgName: Sun Microsystems, Inc
    OrgID: SUN
    Address: 4150 Network Circle
    City: Santa Clara
    StateProv: CA
    PostalCode: 95054
    Country: US

    NetRange: 192.18.0.0 - 192.18.194.255
    CIDR: 192.18.0.0/17, 192.18.128.0/18, 192.18.192.0/23, 192.18.194.0/24
    NetName: SUN1
    NetHandle: NET-192-18-0-0-1
    Parent: NET-192-0-0-0-0
    NetType: Direct Allocation
    NameServer: NS1.SUN.COM
    NameServer: NS2.SUN.COM
    NameServer: NS7.SUN.COM
    NameServer: NS8.SUN.COM
    Comment:
    RegDate: 1985-09-09
    Updated: 2003-10-10

    RTechHandle: IS189-ARIN
    RTechName: Sun Microsystems, Inc.
    RTechPhone: +1-303-272-7000
    RTechEmail: Netmaster@sun.com

    OrgTechHandle: IS189-ARIN
    OrgTechName: Sun Microsystems, Inc.
    OrgTechPhone: +1-303-272-7000
    OrgTechEmail: Netmaster@sun.com

    It seems to me that Sun is spreading the Worm.^H^Hd.