Did I give up on telnet too easily?

Discussion in 'Linux Networking' started by Jem Berkes, Sep 21, 2003.

  1. Jem Berkes

    Jem Berkes Guest

    Those of us paying attention will have surely noticed that SSH daemons are
    proving to be rather buggy; OpenSSH has had several remote exploits
    discovered including some major root exploits. And lsh -- suggested by many
    as a replacement to OpenSSH -- is itself vulnerable to a remote exploit
    http://www.securityfocus.com/archive/1/338210/2003-09-18/2003-09-24/0

    If ssh is to be considered 'more secure' than telnet, I think one has to
    take into account how often the admin is able to patch the machine. In an
    organization that employs a full time network techie, applying the ssh
    patches is an easy enough task.

    But on a machine that sits unattended for long periods of time (a router,
    etc.) I think a better approach would be to use telnet for remote access.
    In such a circumstance, with long periods between remote logins I think the
    likelihood of being exploited by an ssh vulnerability might outweigh the
    likelihood of passwords being sniffed on the wire.

    Thoughts?
     
    Jem Berkes, Sep 21, 2003
    #1
    1. Advertisements

  2. Jem Berkes

    Bit Twister Guest

    The first thing for you to consider, was the exploit found in the wild
    or in a code review.

    Second, you putting only_from = trusted_ip_here in
    /etc/profile.d/sshd-xinetd would keep a whole bunch of exploits from
    happing now and in the future.

    For the telnet consideration, how patient is the password sniffer listening
    on either end of the telnet session.
     
    Bit Twister, Sep 21, 2003
    #2
    1. Advertisements

  3. If you're using Kerberized telnet on your intranet, maybe.
    For remote logins, I like setting up ssh to accept only public key
    authentication. Then if someone wants to guess my "password," he's got
    to guess my public/private key pair. I'm willing to get hyperactive
    about patching ssh to keep that.
     
    Allen Kistler, Sep 21, 2003
    #3
  4. Jem Berkes

    erik Guest

    And do not forget that also telnet has its occasional exploit. There is
    no added value in using telnet instead of ssh. None at all. On the
    contrary.

    EJ
     
    erik, Sep 21, 2003
    #4
  5. Jem Berkes

    Travis Casey Guest

    Or in an organization using one of the distributions which issues patches on
    a timely basis, and has a network method for getting patches. At work, I
    have a mixture of Debian, Red Hat, Trustix, Tru64 Unix, and HP-UX machines.
    Debian was easy -- "apt-get update; apt-get -u upgrade" (using the -u to
    check what else is being upgraded). On our Red Hat machines, we have a
    subscription to Red Hat Network, so running the up2date command did it. On
    Trustix, the swup utility did the same thing. It took less than half an
    hour to do a dozen machines, with one person doing the work.

    The Tru64 machines we had didn't come with SSH (Tru64 5.1B does come with
    it; theirs isn't OpenSSH based, so it wouldn't have needed updating). We
    had to download the source, compile it on one machine, tar up the compiled
    binaries, distribute to all the machines, and untar and install on them.
    It took about two hours to do all that across about a dozen machines, with
    one person doing the work.

    Lastly, the HP-UX machines use an SSH derived from OpenSSH. Last I checked
    (on Friday), HP hadn't made a statement or provided a patch. Since there
    also wasn't an exploit reliably reported, and our firewall doesn't allow
    incoming SSH connections, we felt that leaving them unpatched for now was
    an acceptable risk.

    We probably could have spread out doing the Tru64 machines more, since
    exploits are less likely to appear quickly for the Alpha architecture than
    for the Intel-32 architecture, and none of the Tru64 machines were outside
    the firewall.

    If you don't have a full-time admin, I'd suggest staying with a
    low-maintenance configuration, with something that puts out patches on a
    timely basis and makes it easy to put them on. Heck... with Debian, you
    could easily set up a cron job to either automatically patch every night,
    or to notify you of which packages have upgrades available every night.
    If you don't need people outside your organization to access it, then don't
    allow SSH to it from outside. If you're more paranoid, only allow SSH
    access from a few selected IPs. Both will help limit your vulnerability.
     
    Travis Casey, Sep 21, 2003
    #5
  6. SSH/lsh/etc. don't have to try *at all* to be more secure than telnet.
    Since telnet sends everything across the net in the clear, it so vastly
    insecure and so liable to having passwords stolen that there's no point
    in reviewing it any further for comparison.
    I think you're making an infortunately common mistake in evaluating the
    relative risks.
     
    Nico Kadel-Garcia, Sep 21, 2003
    #6
  7. Jem Berkes

    Jem Berkes Guest

    I think you're making an infortunately common mistake in evaluating
    I think not. Not everybody's on ethernet ;) One has to take into account
    what type of connection you have to the server. Different situations have
    different eavesdropping risks.

    My server is connected via ADSL (point to point) to my ISP. I sure as hell
    wouldn't telnet into my server from my University LAN, but if I'm at my
    workplace -- which also uses DSL, I would be relatively comfortable doing a
    telnet login.
     
    Jem Berkes, Sep 21, 2003
    #7
  8. You *shouldn't* be. Telnet should be blocked at the firewalls, because
    of exactly this sort of man-in-the-middle attack of sniffing passwords.
    And a lot of institutions, big ISP's included, use really poor security
    on their switches. (Old and never-changed passwords, never resetting
    default passwords, etc.). This leaves the switches vulnerable to having
    someone reconfigure them to echo, say, all the telnet port traffic
    through that gateway to a remote box that just sniffs the packets for
    passwords.

    Is this done commonly by crackers? *OF COURSE* it is, because it's very
    difficult to detect but easy to do and they can reap a *lot* of
    passwords from people who are careless.
     
    Nico Kadel-Garcia, Sep 22, 2003
    #8
  9. Jem Berkes

    Jem Berkes Guest

    Is this done commonly by crackers? *OF COURSE* it is, because it's
    Why go to all this trouble and harvest a bunch of users passwords, when you
    can run a well established exploit and instantly root pretty much any
    university, small web site or clueless company using an ancient but
    unpatched BIND, wu-ftp, sendmail, or (my favourite) RPC install?

    Passwords are a dime a dozen.
     
    Jem Berkes, Sep 22, 2003
    #9
  10. Jem Berkes

    Tim Haynes Guest

    (`Uses DSL' strikes me as a naff reason to be trusting of telnet, but I
    can't quite pin down why...)
    So if we were to start talking kerberos or some kind of s/key auth instead
    of plaintext password, would that be any better? Yes, I know it would mean
    the *content* of the data-stream would still be plaintext, of course.


    I'm more or less of the opinion that for anything more than a simple
    `GET'-type request, plaintext is out of the question. That means anon-FTP
    is OK (good thing, too), HTTP is ok for GET requests, but as soon as you
    start interacting (telnet for shell access) it's Bad.

    ~Tim
     
    Tim Haynes, Sep 22, 2003
    #10
  11. Jem Berkes

    Bit Twister Guest

    Because script kiddies can sniff passwords a lot easier than having
    the knowledge to write an exploit.
    They only need the password for the time needed to instal a root kit
    or other malware.
     
    Bit Twister, Sep 22, 2003
    #11
  12. Jem Berkes

    Sasha Guest

    Perhaps an alternative would be "two-factor" authentication. Even if your
    password is compromised it is only good once, and it expires every 60
    seconds. The only disadvantage is that the session is still sent over clear
    text, so if the information you are transmitting/receiving is confidential
    then you still have a problem. I am looking into this for edge router
    configuration that do not support SSH.
     
    Sasha, Sep 22, 2003
    #12
  13. Because they *are* a dime a dozen with unencrypted services like telnet
    for all servers, ftp for non-anonymous users too dumb to use a different
    password, and HTTP servers too dumb to use SSL, especially compared to
    writing and leaving yourselves more traceable by running remote
    exploits. In almost all cases, it's Just Safer(tm) to sniff them than
    break into a remote machine that *may* be running a vulnerable version
    but may *also* be running good log checkers to trace your little weasel
    attack back the source machine.
     
    Nico Kadel-Garcia, Sep 22, 2003
    #13
  14. Yes, that would be superior. Unfortunately, many foolish mortals use
    their initial session to their remote server to connect onwards to
    *other* telnet sessions for other internal services, to systems such as
    routers, filters, or other less conscientiously administred machines.

    And many people refuse to use different passwords for insecure protocols
    like FTP and telnet from their passwords for more secure ones like HTTPS
    or SSH: so once the cracker has sniffed your telnet login name and
    password, he can often use it against your SSH gateways or servers.
    Agreed.
     
    Nico Kadel-Garcia, Sep 22, 2003
    #14
  15. Jem Berkes

    Jem Berkes Guest

    Perhaps an alternative would be "two-factor" authentication. Even if
    There's an interesting optional feature of POP3 called APOP; it mixes the
    password with a server-supplied random seed and hashes the result, creating
    a plaintext string that the server can identify as the correct password --
    but which is useless to an eavesdropper, because the server will never
    reuse the seed.

    But the eavesdropper could still read your email :)

    I'm just bringing this up because simple features like this, which are
    EXTREMELY simple to code (as opposed to a complex crypto/key
    implementation) would go a long way to protect passwords.
     
    Jem Berkes, Sep 22, 2003
    #15
  16. Jem Berkes

    Alan Connor Guest

    Yeh. Use netcat.
     
    Alan Connor, Sep 22, 2003
    #16
  17. That is assuming sshd is run by xinetd which may not be the case.
    Firewalling off anyone that shouldn't have access would work in all cases.
    (Unless the attacker is one that has access, in which case he'd probably
    be better off logging in and trying some local root exploit)
     
    Nils Petter Vaskinn, Sep 22, 2003
    #17
  18. Jem Berkes

    Tim Haynes Guest

    It's also assuming there's nothing exploitable in xinetd. Unfortunately I
    know this not to be the case - there was a bug I found when all my exim
    sessions were suddenly being handled by a process called "leafnode" after
    recovering from rate-limitation, and a memory-overflow vulnerability a few
    months ago.

    ~Tim
     
    Tim Haynes, Sep 22, 2003
    #18
  19. : Those of us paying attention will have surely noticed that SSH daemons are
    : proving to be rather buggy; OpenSSH has had several remote exploits
    : discovered including some major root exploits. And lsh -- suggested by many
    : as a replacement to OpenSSH -- is itself vulnerable to a remote exploit
    : http://www.securityfocus.com/archive/1/338210/2003-09-18/2003-09-24/0
    :
    : If ssh is to be considered 'more secure' than telnet, I think one has to
    : take into account how often the admin is able to patch the machine. In an
    : organization that employs a full time network techie, applying the ssh
    : patches is an easy enough task.
    :
    : But on a machine that sits unattended for long periods of time (a router,
    : etc.) I think a better approach would be to use telnet for remote access.
    : In such a circumstance, with long periods between remote logins I think the
    : likelihood of being exploited by an ssh vulnerability might outweigh the
    : likelihood of passwords being sniffed on the wire.
    :
    You have several issues:

    . Bugs and vulnerabilities in server software
    . Secure versus plain-text authentication
    . Tradeoffs among different forms of security

    Bugs -- all software has them, so bugs are not a deciding factor.

    The first mistake everybody makes in the ssh-vs-telnet-or-ftp discussion
    is that ssh is secure and telnet and ftp are inherently insecure. Secure
    versions of both Telnet and FTP have been available for years, as IETF
    standard fully open protocols, e.g. over Kerberos IV, Kerberos V / GSSAPI,
    SSL/TLS, or Stanford SRP.

    The tradeoff between SSH versus Kerberos or SSL/TLS is ease of installation
    versus manageability. Most sites go for ease of installation -- "set and
    forget".

    Having standardized on SSH, the site and all its users, wherever they may
    be, begin to create public/private key pairs so they can log in without a
    password. These are files that can be stolen -- especially when stored on
    the millions of totally unprotected Windows 95/98/ME machines that are still
    out there. Even if the key files are encypted they can be cracked offline,
    and might open up access to many hosts, some of them at other sites. How do
    you clean up a mess like that?

    Kerberos and SSL/TLS, on the other hand, are more difficult to set up, but
    once you have them, it's much easier to clean up after security incidents: in
    the Kerberos database, or by revoking certificates or whatever -- the classic
    tradeoff of central versus distributed management.

    Kerberos or SSL/TLS are ideal for use within a large organization with a
    professional staff who can administer the KDC or the certificate tree. They
    also allow for finer grained control -- who has access to which services,
    etc. SSH is good for cross-realm connections, where you can't easily set up
    the needed certificates or Kerberos identity. It's also used where the
    required management expertise or bodies are simply are not available.
    Public/Private key pairs, however, can be a risk; it might be safer to use
    password authentication.

    Plain-text Telnet and FTP were designed for trusted environments and worked
    well for decades. They still work well in trusted environments and there is
    no reason not to use them when you know it's safe. Sometimes you have to
    anyway, to access older hosts or services, specialized equipment, etc.

    You can read more about security methods and secure Telnet and FTP servers
    and clients here:

    http://www.columbia.edu/kermit/security.html

    - Frank
     
    Frank da Cruz, Sep 22, 2003
    #19
  20. Kerberized or SSL encapsulated telnet is not telnet: SSH and its cohorts
    have done a long, hard job of actually integrating terminal control into
    a secure set of tools. Simplay slapping SSL on top of telnet does not
    address these issues.

    And frankly, I've dealt with Kerberized tools and trying to integrate
    them into an environment. They're founded on a "we have an *absolutely
    secure*, fully maintained key manager" model that's just very difficult
    to support in the real world. For small shops, it's much cheaper to
    clean up after crackers than try to run Kerberos.

    No, I'm not kidding. Been there, done that, spent hours having to patch
    source code to port the stuff and turn off the stupid "your compilation
    of the final binary failed so you have to spend the next six hours
    recompiling from scratch, because you'd *never* have a bug and we'd
    write in a stupid dependency such as insisting that your FQHN be listed
    first in your /etc/hosts. Nope, we'd never do that!"
    Kerberos is its own ballgame. See above. Most SSL/TLS setups have a
    separate issue the key signature problem of having to pay one of the
    root key owners to sign your key. Bugger *that*, especially for a small
    shop.
    Even quite trivial passwords take quite a lot of CPU to brute force
    attack. But I do agree that people leave their SSH keys around quite
    carelessly and inappropriately. This is a problem with *any*
    authentication system that uses software keys of any kind.
    And you have to support trust and arrange lines of trust for that
    central manager, which is often prohibitively expensive.
     
    Nico Kadel-Garcia, Sep 23, 2003
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.