1

I was recently asking for the telnet client to be turned on on my Windows install. The devops guy told me it was restricted because it passed people's usernames and passwords through clear text. I assume he is referring to using it to connect to an unsecured telnet server but I won't be using it for that and instead use it just for some quick TCP checks.

I also noticed that OWASP referenced doing exactly that in their documentation.

https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)

So what am I missing, is there a security issue with the client?

JGleason
  • 113
  • 1
  • 3
  • 1
    No, there's no security issue with the client here. Your web browser also "passes people's usernames and passwords through clear text" if you access a website over HTTP. So does FTP. – ceejayoz Jun 15 '18 at 19:11
  • Amen just trying to make sure I am sane, I mean it was SecOps. – JGleason Jun 15 '18 at 19:14
  • In case you hadn’t already considered it, PuTTY supports both SSH and Telnet. – Mike Renfro Jun 16 '18 at 02:38
  • @MikeRenfro thanks for the idea I know there are 100 ways to skin a cat. However, I am working in a controlled environment and I was trying to avoid the overkill of something like putty. I think the Powershell alternative would beat it too. But if someone already has a machine with it installed I agree it is a viable solution. – JGleason Jun 18 '18 at 13:24

2 Answers2

2

There are no direct security issues with just having the client installed. The problem here is the combination of the client and the user using it to access servers with unencrypted connections. It's easier to make technical limitations than alter human behaviour.

Is removing the client software the only way to mitigate this problem? Certainly not, and for example blocking unencrypted protocols on a firewall might work even better and also against running own executables or using own devices to circumvent this limitation. But still, it's a reasoned company policy, probably based on experience.

Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
  • Right to me this should be handled by firewall rules or TCP filters. Not by a blanket policy (which I still can't find). As for managing executables I completely agree this is sound policy. However, there should be a way for people with a need to apply for permission to have considered use of such an app (and it should be easy). I would think a bunch of people hacking a way at Powershell scripts would be a larger security vector. – JGleason Jun 18 '18 at 13:22
0

There are ways to do basic connection checks that don't speak an unencrypted protocol: In Windows, using the command line, how do you check if a remote port is open?

Of those, I like that Test-NetConnection is included in PowerShell. nmap is more powerful but is third party.

I say this having used telnet to bang out test SMTP emails on UNIX boxes. Which is stupidly low level, but I see what is going on. Never used for login, telnet service always disabled.

John Mahowald
  • 30,009
  • 1
  • 17
  • 32
  • Yeah this is basically what I ended up doing but I was hoping to avoid needing to maintain a power shell script when there is a simpler way. Thanks for the advice. – JGleason Jun 18 '18 at 13:18
  • Portqry.exe is one of the options there. From Microsoft, and not designed to send anything over the wire, but requires a download. – John Mahowald Jun 20 '18 at 12:54