OSS PING
If you are interested in the OSS ping list please mail me
Posted on 02/12/2007 10:35:07 PM PST by zeugma
There is a major zero day bug announced in solaris 10 and 11 with the telnet and login combination.
It has been verified. In my opinion NOBODY be should running telnet open to the internet.
Versions of Solaris 9 and lower do not appear to have this vulnerability.
The issue:
The telnet daemon passes switches directly to the login process which looks for a switch that allows root to login to any account without a password. If your telnet daemon is running as root it allows unauthenticated remote logins.
Telnet should be disabled. Since 1994 the cert.org team has recommended using something other then plain text authentication due to potential network monitoring attacks. http://www.cert.org/advisories/CA-1994-01.html
“We recognize that the only effective long-term solution to prevent these attacks is by not transmitting reusable clear-text passwords on the network.“
If remote shell access is required ssh is a better choice then telnet. We have done articles about securing ssh in the past. http://isc.sans.org/diary.html?storyid=1541
The FIX:
To disable telnet in solaris 10 or 11 this command should work.
svcadm disable telnet
The Mitigations:
Limit your exposure if you must run telnet on your solaris system it is recommend that you use firewall(s) to limit what IP can connect to your telnet services.
Change
/etc/default/login add CONSOLE=/dev/console
to limit where root can login from. This only prevents direct access to the root account other accounts can still be compromised.
Another mitigation that works in most cases is this:
inetadm -m svc:/network/telnet:default exec="/usr/sbin/in.telnetd -a user"
We have had one report of someone locking themselves out with this so use at your own risk.
- The Snort signature has been removed at the request of the author.
I am not going to include the site with the exploit. No special tools are required to exploit this vulnerability.
Thanks to Chris and Thomas who notified us of this issue and all the fellow handlers that helped verify, mitigate and review this report.
Nonetheless, this is a good opportunity to issue a reminder to check for those telnet daemons. Disable them. Destroy them. Drive them before you and hear the lamentations of their women!
Seriously... Though this a hack against Solaris versions of the telnet daemons, do what you can to search out and disable telnet wherever you find it.
The only remaining purpose to telnet imo, is if there is absolutely, positively no other way to do it. The telnet client is useful for testing connectivity between computers on various ports, but the servers have no place in the 21st century.
Forward and ping to any tech folks please. This is a biggie for those running solaris.
Conan say use SSH.
Is there any objection to telnet servers that don't allow any sort of shell access? Things like low-security BBS's and such?
OSS PING
If you are interested in the OSS ping list please mail me
Yes, Telnet is VERY bad, ssh should be used instead when possible. I have done as you have in disabling ftp, as it is just as bad as telnet. I have people either use scp or sftp.
As long as no one is logging on.
Telnet passes both username AND password in the clear. These days, this is just asking to get your users hacked.
Absolutely! ftp sucks as bad as telnet for security. It can be useful as an anonymous fileserver (in that it is a more efficient protocol for serving files than http), but beyond that, it shouldn't be used unless there is no other option.
Besides scp is so much more flexible! Want to move a file from A, to B, while you are logged into C...
scp a:file.txt b:.
scp rocks lots more than ftp :-)
IIRC, some of the earliest 'hacks' were merely brute-force telnet login cracking. Telnet daemon has always been a no-no.
Gaaaaaa!
The word is "than", people! THAN!
There, I feel better now. :-)
The only time I ever telnet anymore is to watch Star Wars in ASCII animation. telnet://towel.blinkenlights.nl
LOL. I can relate.
Dude, that's like, so demented!
I wonder how big the file is.
How is that any worse than logging into a non-https: web site?
Not much worse. Problem is, a telnet login is going to give you a shell prompt. Getting shell access is more than half the battle to any hacker, because there are so many programs out there that are vulnerable to local exploits. Sites that may be pretty proactive on processes that listen on sockets are often less proactive about many local programs. This is really not a good idea, as most hacking is done by insiders, but it is more common than you might think.
What sort of shell prompt do you get with telnet:bbsmates.com or any of the other telnet-BBSs out there? I would think that while such sites aren't a lot better than non-https: password-protected sites, they at least divvy the password among different packets in such a way that one can't simply look for packets containing a string like "&password=foobar".
Interesting...
though otoh, the first thing we learned at school when we have to connect into the Unix servers is Thou Shalt Not Use Telnet. For it is unholy.
"Disable them. Destroy them. Drive them before you and hear the lamentations of their women!"
Good point...
That is crazy...
...but interesting.
(even though I'm stuck on a terminal with Slax Frodo, I can still telnet and SSH).
BTW, as an experiment, I managed to program a stateless telnet server on a DSP. It doesn't do much (it echoes back what's sent to it, with a few character translations that show what other processing the DSP is doing) but what's interesting about it is that the DSP neither knows nor cares how many devices are connected to it. Ever seen anything like that?
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.