Worm Exploiting Solaris Telnetd Vulnerability

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.'"

Yep.

[AltGrendel]

That's one of the first things any good admin turns off.

Use SSH.

...oh, and don't forget to wear your raincoat.

Mine is!

[Doctor Memory]

But it's only reachable via ports 80 and 443. And I installed patch #120069-02 a couple of weeks ago. In fact, I already installed the -03 version of that patch. If you keep up with your security patches, it's really not a problem. Of course, this is easy for me to say, I have one workstation; I'm sure that for sites with dozens (or hundreds) of servers, it's more problematic. I also STR that patch 120069 used to require a reboot after installation, which makes it a bit more of a hassle to install (I usually save those for Fridays, when I can install them and then walk away while the box reboots).

It's been a long day...

[Odiumjunkie]

So, just to be clear, this story, posted on March 2nd, is reporting on a worm which has started exploiting a zero day vulnerability that was covered by slashdot on February 12th?

Isn't twenty days long enough to disable a remotely exploitable and totally unnecessery, unsafe service that no admin in his right mind should have enabled on a box connected to the net anyway?

Re:Yep.

[fm6]

Yeah, that was my response when I first heard of this bug/exploit. 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.

And note that this worm is enabled by a bug in Solaris's implementation of telnet, not by telnet itself. A similar bug in ssh would have had the same effect.

Should have happened...

[alexhs]

What about this argument that OSs other than Microsoft ones don't get malware developped for them because they don't have significant marketshare, again ?

Other Telnet vulnerabilities

[Flying pig]

Amazing but true - there are printers on some networks which are accessible over the public Internet and which have their telnet ports exposed. I'm obviously not spelling out the implications here, but some people need the proverbial rocket up the backside.

A new box won't have this problem...

[kenh]

This is not present in the Update 3 of Solaris, released 11/06 - that prompts the user to enable "network services" if they like, but warns that will expose the system to problems. One of those problems is the famously insecure telnetd service. If you say "No" telnetd is not installed/activated - and "No" is the default.

Existing boxes need to fix this, but a patch has been out for a while - are we dealing with the "short bus" hackers that it took this long to actually exploit? Why, oh why, doesn't Solaris warrant better hackers? ;^)

Re:Yep.

[iamacat]

ssh is actually more complex than telnet and more likely to have exploitable bugs - there were a couple featured on slashdot in fact. ssh is for protection of the user, not the host system. It can make intrusion recovery more difficult, as you will not be able to see what the attacker is doing using network monitoring tools. Sun just got sloppy/unlucky with this one by unnecessarily mucking with login. Don't they teach in school to not add command line options/environment variables to a setuid program?

Re:Yep.

[fm6]

Putting ease of use ahead of security is hardly unique to Sun. Actually, this kind of thing isn't even an ease of use issue. Somebody gets a customer complaint, they see a fix, and they implement it without thinking through the security implications. Happens every day — usually several times.

SSHD DOES give you magical powers - real passwords

[wsanders]

- The Solaris telnet authenticates against their login PAM modules, which only uses the first 8 chars of the password for authentication. SSH bypasses /bin/login and passwords can be as long as you want. This is more longtime Solaris silliness that has not been fixed in Solaris 10.

At least they do come with a binch of stuff disabled by default, and with a fairly recent version of SSH.

I *DO* have numerous Solaris hosts happily floating in the effuent of an unfirewalled Internet connection, and they are probed continually for guessable passwords. Since my passwords are something like "2q3cb07rqwpexnbyslgfsdjhg" and I use only ssh for acccess I can sleep at night.

Re:It's been a long day...

[Anonymous Coward]

When someone finds a solaris box, if it's infected, maybe they'll be nice enough to talk about what the worm does in good detail, and post some partial disassembly or something. I've always been fascinated with worms, and although posting binaries or complete source would be akin to handing out loaded guns (at least until most everyone has gotten patched), I'm kinda pissed that the Morris Internet worm is almost two decades old and *still* there's no complete source listing or binaries online to look at for curiosities' sake. I don't think there are *any* vulnerable boxes still running *anywhere* attached to the Internet, but being able to play with an old, live worm in a simulator or an isolated network could be helpful for people writing automated network monitoring / blockading software. For example, if I had a bunch of old windows machines with unpatched IIS on a completely isolated network, I could actually watch Code Red and Code Blue spreading through the network, and see what kind of automated detection and isolation software I could come up with that could be useful for future worms and such. I could experiment with network topologies and layouts and see how to build a good dynamic system that could be deployed in a variety of network configurations. Fortunately for safety's sake, but unfortunately for people who only experiment with security systems as a hobby and aren't notable and thus not trustworthy in the eyes of notable researchers, anti-virus firms and famous security researchers keep a very tight lock on these things, even some very old ones that are effectively harmless toward the Internet at large at this point. I can find sites with live viruses that are only a few years old, but I can hardly find any live worms. I don't think it's a very good idea to put a bunch of open systems out there and wait for them to get infected with something, but it seems like the only potential way of catching one. However... anyone know of any virtual honeypot software that could actually emulate a lot of different architectures and systems? I know it's nearly the same as writing full emulators, but, it could be useful.

Re:Yep.

[Venik]

There is nothing inherently wrong with telnet. It has functional limitations, just as any other method of communication. Telnet can be safely used, when its limitations are accounted in the overall environment. Look at it this way. A company that makes locks accidentally produced a model that can be opened by any key. Oops. You are saying: Hey, everybody knows that locks can be picked, so why are you still using them? Do you see a difference between a design limitation and a production defect?

Re:Yep.

[pclminion]

Yeah, that was my response when I first heard of this bug/exploit. 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.

Why the hell not? Installation of Solaris is not exactly an "end user" type of operations. More likely it would be performed by an IT professional. Having telnet enabled initially makes it easy to setup the system from another location without worrying about making ssh or anything else work.

The real stupidity is the admins who don't care enough to actually do their job and disable telnet. These are the people who should know better. Chances are, Sun has received more calls about why telnet is NOT enabled by default than they have for the opposite. The real lesson is, don't plug a box into an untrusted network with telnet running.