3

I have a telnet port open to my PC using the TCPClient in latest version of .net, it is only used for receiving text then parsing it and adding it into an SQL Database, my telnet server does not reply to the client in anyway.

Apart from an SQL injection attack are there any major concerns I should be worried about regarding the rest of my network being compromised.

Some of our customers are using old legacy systems still that only support telnet so it is needed to be used, but a recent cyber security audit by an external company said it was a massive risk to our business.

EDIT: If any of the data was to be intercepted and read it doesnt contain any confidential information and would pose no security risk for someone to have this data to both us and our clients.

The security audit did not include any network testing all they heard was there was a telnet port open and put down this was a risk without actually testing if it was secure. But my boss doesnt see it that way and thinks we now are at a massive risk.

2
  • 2
    Aside from everyone being able to read the text, modifying it as they wish, it offering no authenticity at all, etc.? If your only concern is that it sometimes works for something, then sure, go ahead. As soon as you put some adversary into that situation, the proverbial excrement will meet the ventilation element.
    – user163495
    Commented Jul 1, 2020 at 17:25
  • You haven't provided enough details about what your system does and how it is used, but if after a professional security audit they said it was a massive risk, I suspect that it's probably a massive risk.
    – reed
    Commented Jul 1, 2020 at 17:41

3 Answers 3

2

One issue with telnet is that there's no protection of the data in any sense. Anyone on the path can copy the data, alter it, and nobody will know. Any data coming from it is untrusted.

The rest of the network being compromised is not the main risk, because this is inherent to any service you have: HTTPS, SSH, NTP, anything. If someone can connect to your service, a bug on said service may lead to compromise. The word may is key here. Some services are stable, secure, and run for years without issues, while others (sendmail, I am looking at you) have a constant stream of issues.

Apart from an SQL injection attack are there any major concerns I should be worried about regarding the rest of my network being compromised.

Here there's a lot of things that may go wrong:

  • Buffer overflows: this depends on how your application manages the incoming data. A buffer overflow, use-after-free, off-by-one and a lot of other memory access issues can lead to code execution and lateral movement on your network. The same applies to any other service.

  • Data leakage: anybody sending data to your service is subject to have their data stolen.

  • Corruption of data: any message can be silently changed in transit.

  • Replay attacks: data can be copied, and re-sent later.

What do you do? You can ask your clients to run an encrypted tunnel between their network and yours, and send the telnet data inside the tunnel. Because asking the clients to upgrade their services is not something they will do. SSH is around since 1995, HTTPS since 1996, and they still use telnet, so I bet they will keep using telnet until the end of the times.

cyber security audit by an external company said it was a massive risk to our business.

Ask them to clarify the massive risk. Most of the time, the massive risk they are talking about is credential theft, as telnet is not encrypted and any credential sent can be stolen. If you tell them that no credential is ever sent, maybe they change the risk assessment.

But even so, create an encrypted tunnel and FORCE your clients to use the tunnel.

1
  • 1
    The audit was only over the phone, heard that a telnet port was open and then listed issues with this without actually testing any of our network but my boss heard the potential risk and has gone off like a bomb. The data coming in isn't an issue to us, the customers are aware of the risk to their security.
    – DSAILE
    Commented Jul 1, 2020 at 19:37
0

That's what is called "low hanging fruit" in a security test. It may not be as massive a risk as the auditor calls it, but for sure it is a big exposure.

It would be nice if the auditor shows how can this one be exploited. Now, an SQL injection attack is already a big one, remember it has been #1 in the last 10 years in the OWASP Top 10 risks. You still think you need something else to worry about?

If you need a PC as some kind of proxy to get data into a database and you receive this data in clear text, it seems to me as a very weak part of your system.

If it is only found in one PC, it may not be as big a risk, but if this particular PC belongs to an Administrator, things change substantially. This old protocol may not be used to subvert the whole network per se, but it can be the entrance point to an important asset like an admin's PC.

Since it has been documented and probably emphasized by the auditor, I would stop trying to explain how it is not so bad and put some energy in replacing it or at least in isolating it (good idea the encrypted tunnel @ThoriumBR).

Truth is: it looks bad.

0

Telnet does not provide any form of security for the information in transit, including credentials if your application uses them, f.e. API keys if those should be secret. This application of yours is used by customers so I'm assuming it has some sort of authentication

it is only used for receiving text then parsing it and adding it into an SQL Database

This only statement gives three possible points of failure:

  • Parsing: Depending on how the parser is made this may lead to binary related vulnerabilities - buffer overflows, use-after-frees, etc -, flaws in the business logic - f.e. unexpected edge cases that result in application not behaving as intended - or even intentionally manipulated data by attackers in the network, a.k.a. man in the middle.
  • Storage: SQL injections may be a vulnerability and a severe enough one to demand your attention, but you should also consider that adversaries may just try to overpopulate your database. If this is a cloud service it will probably involve a monetary cost and if it's yours it may lead to excessive consumption - disk space, processing, etc.
  • Received data: As telnet provides no security, it is perfectly possible for attackers to maliciously manipulate the information provided, this goes from simply invalid or malformed data to other kind of blind payloads - XSS, XXE, etc - that may be intended to attack other applications that consume the information generated by yours

The best approach is to implement a secure communication channel, i.e. TLS. If the customer is incapable of using TLS I'd recommend using a VPN to wrap the unsecure telnet port

Apart from that, it would be great if the security auditors could provide more information on why it was considered a "massive risk"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .