Telnet/FTP Security Question

Viewing 28 reply threads
  • Author
    Posts
    • #2798
      dirtmaster88
      Participant

      Hello All,

      This is my very first post here.

      I’ve started my own project here at work to give hard proof to others that protocols such as ftp and telnet are very insecure. I am having a hard time trying to give real life examples of what could happen because any sort of sniffing I’ve done has been inside the network. I’ve taken a beginner’s course on security which we touched a few basic parts of wireshark and cain/abel. I’ve been able to sniff my telnet/ftp traffic on my workstation and see everything in clear text but I just cant seem to figure out how I could sniff the traffic of a remote machine (on a switched network). What would be ideal is if I could somehow sniff the traffic from my house and show that everything is in complete clear text. Could someone point me in the right direction? I know many tools require command line and I am very familiar with that as I am the *NIX administrator here.

      Thank You!

    • #19564
      Don Donzal
      Keymaster

      First of all, welcome to EH-Net.

      Secondly, here are a few things to go on:

      1. Cain & Abel for man-in-the-middle attacks to be able to grab switched traffic. See video from our very own Brian Wilson.

      2. One could always get in through a wireless AP, and therefore then be on the same network segment as others in your company. This would also allow sniffing directly or via MITM.

      3. Client-side attacks are the biggest thing right now. Get someone to click on a “bad” link in a browser, install some kind of malware, capture local traffic with a sniffer or keylogger, send passwords back to the bad guy.

      Hope this helps,
      Don

    • #19565
      Kev
      Participant

      “Inside” the network is where sniffing is done.  Well unless you hack the server of the ISP or intercept the traffic before it reaches the destination modem, but good luck doing that. 

    • #19566
      unicityd
      Participant

      There are two things that I think you need to impress on your employers.

      1) Someone can eventually find a way in.  An attacker only needs one misconfiguration or unpatched vulnerability to get access to some system.  Even if you have good security practices and are patched up-to-date, a new exploit could be released tomorrow that leaves you vulnerable to every script kiddie who decides to take a poke at you.

      2) Once an attacker gets in, he usually wants to keep his access and move to other systems within the network.  The primary means of expanding his access are cracking passwords, or otherwise stealing credentials from the first machine, and sniffing the network to get other credentials.  Many people don’t believe that it’s possible to sniff switched networks, but many also think the Earth is flat.  Tools such as Cain and Abel, and Dsniff have made sniffing on switched networks relatively easy.

      Good security isn’t only about keeping the bad guys out, it’s also about containing the damage once they get in.  If an attacker gets into one machine and can then sniff FTP, telnet, POP, LM/NTLM, you’re wide open.  If he gets in but has limited network access (due to firewalls, VLANs), is unable to crack the passwords on the system, and can’t sniff any useful traffic, he has a much more difficult task ahead of him.  That’s not to say that he can’t still own the whole network, but it raises the bar significantly in terms of skill and time.  Increased time is increased risk for the attacker; the longer he is logged in and putzing around on your systems, the more likely he is to get caught (especially if you have good logging and some IDS in place.)

      Cheers.

    • #19567
      KrisTeason
      Participant

      nice first post unicityd. very nice indeed.

    • #19568
      vijay2
      Participant

      Very nicely said indeed,

      I will just add –

      The key to security these days is the buzz word “Defense in Depth”, layered security. It is all about protecting your crown jewel “the data” with multiple layers of protection and having some good ways to monitor yr defenses for breaches. Its not the question of “if” your network will be breached but “when” it will be breached. Patching, Anti virus, good password policies are great start but there is a zero day for something everyday, mostly with the client and application softwares and i guess there are no protections for “zero days” yet. In that case the layered enclaves are only way to slow down the attacker and protecting your most precious day.

      Ummm .. I guess thats what we all need to emphasize to our employers

    • #19569
      dalepearson
      Participant

      Some good information in this topic, so well done all.
      The next challenge comes in securing the funding for these improvements.

      Businesses want to make money (dont we all), and when you make recomendations to be pro-active, they often want to know the ROI. It can be a battle to make a company understand how security plays a part in loss prevention, and being less reactive.

      Keeps us guys and gals of the streets though 🙂

    • #19570
      Michael J. Conway
      Participant

      We test systems all the time and always find FTP or telnet in use. The good thing for us is that the systems are on a closed system, but because telnet and ftp transmit user names and passwords in the clear, any one on the network with a sniffer can get them. So even on the inside, don’t discount the threat posed by another insider. They already have physical access to your network, it is just a matter of gaining greater access. Most people are lazy about user names and passwords and often use the same for multiple accounts.
      Lets say you have a sysadmin with user name jdoe and a password of passwd for his system. Lets then say he uses it for and ftp session and that gets picked up by some one else on the network with a sniffer that does not have complete admin rights. That person could then try jdoe’s credentials to gain greater access to the system. The moral here is that whether a person is on the outside or inside, clear text protocols like ftp and telnet are a bad idea.

    • #19571
      vijay2
      Participant

      To take your discussion further, agreed that the clear text protocols are threat from insiders on a closed network, but, what if a client is compromised by the attacker and then all he has to do is wait and sniff the traffic “inside” to get the user name and password to either escalate his privileges or pivot to other systems with the sniffed user name and passwords.

    • #19572
      Grendel
      Participant

      FTP itself may or may not be a threat, depending on the contents of the FTP files and exploitability of the FTP app from within.  You can also set up FTP to be anonymous, in which case this argument is dead.

      Telnet itself isn’t necessarily a threat – it’s the use of telnet to log into a system (ok, technically, it’s the transmittal of username and password in cleartext, but you get the idea).  If you intend to allow remote logins, you might as well dictate in the corporate policy that ssh be used.  And if you go that route, you might as well require putty to be used for file transfers.

      FTP and telnet (for logging in) are obsolete protocols in 90% of the cases today, and the alternatives are certainly not difficult to implement.  Also, on a tangent, I am baffled why people continue to use telnet in the first place – netcat is much more powerful, and doesn’t have the problem of data manipulation that telnet has (…steps off soap box).

    • #19573
      vijay2
      Participant

      Well I tend to disagree that FTP and telnet are dead protocol, i still find about 80% of environment use these in some form or other, Agreed that netcat is more powerful than telnet but there are certain limitation using netcat (shell) over telnet (terminal).

      VJ

    • #19574
      Grendel
      Participant

      @vijay2 wrote:

      …there are certain limitation using netcat (shell) over telnet (terminal).

      I’m curious what you see as the advantages telnet have over netcat.

    • #19575
      Anonymous
      Participant

      The argument that a person should use netcat over telnet or ftp is absurd. Think AV. Most will flag and quarantine it.

      Also, to answer the original question:

      1. You will not be able to sniff traffic from your home without access to the network directly (vpn, etc…)

      2. MITM is generally layer 2. Arp spoofing/cache poisoning will allow the attack you are thinking of. Ettercap or scapy can do that for you if you prefer *nix.

      3. If it’s just sniffing a switched environment look at a tool like Yersinia to manipulate the switch port accordingly.

      Telnet and FTP are unfortunately not dead protocols. I’m in environments all the time where they are the only way to access and manage legacy applications/devices/etc…

      Implementing SSH as an alternative can become a problem when you have thousands of devices in multiple locations requiring code upgrades or firmware upgrades. Not to mention the issue of change control and management. Does that make it acceptable? I don’t know. Look at the risk associated with it and then decide. 

    • #19576
      geekyone
      Participant

      The argument that a person should use netcat over telnet or ftp is absurd. Think AV. Most will flag and quarantine it.

      If you were using Netcat as an administrative tool this wouldn’t be a problem because you could exclude Netcat from the AV.

    • #19577
      Grendel
      Participant

      @dean wrote:

      The argument that a person should use netcat over telnet or ftp is absurd. Think AV. Most will flag and quarantine it.

      As geekyone posted, netcat can be excluded from anti-virus rules.  Plus, I think symantec is the only av company that’s put it on it’s default quarantine list (I may be wrong on that one).

      The argument still stands, though, that netcat is a better tool than telnet, especially with the ability to process raw traffic.

    • #19578
      Michael J. Conway
      Participant

      Symantec puts a lot of our tools on the auto-quarentine list. I had all kinds of problems with getting Cain & Able on more work computer. The guys who handle our AV (Symantec) had to set up a group, make me a member of that group, and I still had to place the tools to not be scanned in that location. Of course, I have not had this problem at home with my AV. Go figure????

    • #19579
      Kev
      Participant

      The argument that netcat shouldn’t be used or doesn’t have value in a network environment because its detected by AVs is specious to say the least. I agree completely with the statement that FTP and Telnet are dead protocols, if what was meant that they are dated and there are better solutions.

    • #19580
      Grendel
      Participant

      @sgt_mjc wrote:

      Symantec puts a lot of our tools on the auto-quarentine list. I had all kinds of problems with getting Cain & Able on more work computer.

      Yeah, so did I – my solution was to use a VM to get around the AV.

    • #19581
      Anonymous
      Participant

      @geekyone wrote:

      If you were using Netcat as an administrative tool this wouldn’t be a problem because you could exclude Netcat from the AV.

      I still fail to see why you would want to add an administrative overhead to an environment and I highly doubt that there is value to be gained by managing a switch or device using netcat over telnet.  Unless you are security I highly doubt that a tool commonly associated with an attacker would be used by the network group and to then whitelist that tool you are now opening up the potential for that tool to go unnoticed in your environment.

      When would I need to process raw traffic using netcat in the context of this discussion? I though the idea was to replace telnet using netcat?

      The only thing in this case that netcat may be better for is wrapping in a script and at that point you’d be better off in cleaning up your environment and using ssh.

    • #19582
      Grendel
      Participant

      I still fail to see why you would want to add an administrative overhead to an environment and I highly doubt that there is value to be gained by managing a switch or device using netcat over telnet.  

      I would rather use the best tool for the job, and if that means going through hoops, so be it.

      When would I need to process raw traffic using netcat in the context of this discussion? I though the idea was to replace telnet using netcat?

      Telnet has a nasty habit of intercepting characters it considers to be commands intended for the telnet application, thus corrupting the data stream.  Also, it will inject data into the stream as well.  With netcat, none of this happens – what you see is unadulterated.

      When dealing with a switch, you won’t see much difference using telnet over netcat.  However, once you proceed pass simple shell account access activities, netcat really shines.  As to the use of netcat within the context of this topic, I did state outright that the use of netcat was a tangent to this discussion.  Sorry if you thought I implied it was related to the discussion… my bad.

      The only thing in this case that netcat may be better for is wrapping in a script and at that point you’d be better off in cleaning up your environment and using ssh.

      If all we’re talking about is shell access, than I will definitely fall back to the original argument that ssh should be implemented.

    • #19583
      Anonymous
      Participant

      Why would a person condone the use of a tool that is known to be used by attackers on a network? I don’t disagree that it is a great tool, I’ve written about it’s uses and still use it a lot, but to allow a tool like that to be used outside of the context of security then that is irresponsible especially in a large environment where managing those tools and their use becomes more difficult.

      Again i don’t disagree that SSH should be used for device management tasks but in most large organizations, regardless of the industry, you will find that due to the number of legacy apps and the sheer number of devices that it’s no small task to even attempt an upgrade of that sort throughout an organization.

      This goes back to my original point that while Telnet is not ideal it is sometimes a necessary evil and if the risk posed by having it in use is one that is acceptable…

      As vijay2 said defense in depth is standard procedure in most places. It’s often easier to limit telnet access to a management ip range and vlan or to implement ACLs at the edge or even in the distribution layer to prevent certain protocols or to implement and ids/ips than it is to move to using a more secure protocol. If the attacker is on the network and has access to the management network then other controls would have had to have failed first.

    • #19584
      Kev
      Participant

      I agree completely with Grendel’s thoughts on this.  To disregard a tool because its either too much trouble to implement or it sets off an AV or OMG it’s known to be used by hackers is not a valid approach in my humble opinion.  I know a number of very skilled admins that use netcat in their network environment as well as other  scary “hacker” tools like nmap, nessus, etc… without any issues what so ever. Why?  Well, they are really on top of their security and have everything locked down very tight.  Any extra activity from a dreaded hacker tool will be discovered quickly.  Obviously an AV is not the only thing in place to monitor activity.  However, making generic statements regarding the security of any network can be dangerous. Each situation is different as well as the level of skill of those that have the responsibility of maintaining the flow of the network.  Having said that, if tomorrow I get a call from one of these admins saying he got breached because he allowed the use of netcat (I highly doubt it), then I will obviously change my opinion, lol. 

    • #19585
      Anonymous
      Participant

      While your tone leaves a lot to be desired i don’t disagree with either you or Grendel but the fact remains that implementing certain replacement protocols can be a logistical nightmare in large organizations. Most of my clients are orgs with 10k-40k employees and i often see in their environments what this whole thread has been about. When asked why it’s left that way I find that the answer is generally the same. Resources need to be allocated to projects and projects are prioritized according to risk and based on the additional controls in place the risk is not severe.

      As for the ‘scary’ tools you mentioned. Yes, they have a place in any environment and do bring value. But to propose a tool that is detected by AV over one that is not and your answer to that is to whitelist it in the AV?? I fail to see the logic. i have a problem with a blanket statement like that. I’m going to assume that he meant that the enterprise AV in use was configured so that only his and a few other select systems were whitelisted or perhaps he runs it in a vm. Either way perhaps qualifying that statement would have saved some time.

      As to the admin being owned. My argument was not that the admin using the tool would be owned but that if such a tools use was commonplace in the network then perhaps its use would be overlooked when it was not legitimate.

    • #19586
      vijay2
      Participant

      Well, again I would point out that with this whole discussion for netcat and telnet in my humble opinion is we are comparing apples to oranges, the 2 tools are great in their own right but they are functionally different. All you can get with netcat is a shell access not and a terminal access. And there is a huge difference between shell access and terminal access.

      With only shell access you cannot run editors like vi, or you cannot pivot to another machine using ssh or telnet to another machine from a shell or  ftp or sftp or scp for that matter from a shell. These basic things might be small things but for me I would like to have the ability to do these basic stuff when i have access to that machine.

      Also, if i own a machine the first thing i would look for on that machine is netcat, which is not installed by default on windows and most Linux versions have limited functionality. Therefore, i would not want to leave a copy of netcat on my machines and give the attacker one up on me, specifically on my admin machines.

      Agreed that netcat is a wonderful and most powerful utility, but has its limitations.

      Just my 2 cents

      VJ

    • #19587
      Kev
      Participant

      Yes, I agree with both the above posts and I was attempting to acknowledge environmental variables. I just have a problem with blanket statements like “The argument that a person should use netcat over telnet or ftp is absurd.”  Every network will be different and might be subject to different regulation. For instance, if an admin feels his network is too unwieldy or perhaps his skill level isn’t up for the challenge then perhaps the only safe solution is a more generic approach.

      I am sure we would all agree that in some environmental circumstances the use of tools like netcat would be acceptable and in others it might not be appropriate.  If we claim to be hackers as well as network admin and not some “cant think outside the box” corporate suit , being intelligently flexible is a desirable quality and this approach reflects that. Just my 2 cents.

    • #19588
      Michael J. Conway
      Participant

      Why don’t you just use ssh? Forget telnet/ftp and netcat. Any thoughts?

    • #19589
      Don Donzal
      Keymaster

      I think dean has brought this up several times:

      Again i don’t disagree that SSH should be used for device management tasks but in most large organizations, regardless of the industry, you will find that due to the number of legacy apps and the sheer number of devices that it’s no small task to even attempt an upgrade of that sort throughout an organization.

      Don

    • #19590
      Michael J. Conway
      Participant

      Next to users, legacy apps are the next best thing for the death of security. I guess we can’t win them all….

    • #19591
      Anonymous
      Participant

      There was a fantastic tool called ‘hunt’ which would sniff for telnet sessions and then hijack them. Great fun for typing stuff into other peoples terminal windows! This was in the days of shared network media and easy to guess TCP sequence numbers (windows 95 on 10BASE2 coax). If telnet was outdated and insecure then it sure as hell is now.

      Jimbob

Viewing 28 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2020 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.

Sending

Sign in with Caendra

Forgot password?Sign up

Forgot your details?