1

We have a local virtual windows 10 server hosting some custom software. This VM is only hosting this service and nothing else. This software is made of:

  • An ASP.Net core web app, public API, only returns data, never writes
  • Custom UDP communication server (with its own reliable implementation), does some CRUD operations but only after authentication is certified
  • FTP server configured a usual, port 21 for authentication, 20 for data transfer. Does only allow file transfer within a given folder and only to users authenticated with the correct email/password.

We want to host this service to the outside world so our customers can use our platform. When I asked the network manager to allow these connections to this specific VM, he said it is very dangerous and that there is a 100% chance that we will get hacked.

I'm wondering if he is right. In my knowledge, it is very unlikely that someone might be able to penetrate my custom software and get something useful out of it, let alone cause any harm with it.

The only weak spot I might come up with is our FTP service, which could be "hacked" and the intruder could potentially transfer malicious files to this certain folder. I could upgrade to SFTP but I'm not very familiar with this service and have no idea if it's a major improvement.

Are there any major security leaks with this setup if we port forward it? Are we, as he states, 100% going to be hacked?

Edit

The UDP Server is used for fast real-time communication. It has an internal state that is shared among all clients but that's view data only. the UDP Server itself does not execute CRUD directly, but talks to a separate layer that implements all logic which then speaks to the database layer.

This logic layer does check for authentication on the server-side, if the host is not authenticated, crucial CRUD operations are not permitted. The authentication is based on a salted hashed password which grants a session token for a limited duration (30min). This connection is not encrypted, but I have not enough knowledge of knowing why it should. This is the part where I doubt myself.

This application is not going to be used by a lot of people. I doubt it would fall into the hands of anyone who knows how to break this. But I just want to be sure.

Improve this question
16
  • 2
    "In my knowledge, it is very unlikely that someone might be able to penetrate my custom software...." - what is this knowledge based on? Is it just gut feeling or was the software actually designed with security in mind and robustness against attacks by someone who is in expert in this and maybe also independently checked for problems? "Are there any major security leaks with this setup if we port forward it?" - there are not enough details in your question which would allow to form a meaningful opinion about the security of your software. – Steffen Ullrich Jun 3 '20 at 17:29
  • The network manager could be 100% right on his "100% probability" if vulnerabilities on his networks are not eliminated at 100% . – elsadek Jun 3 '20 at 17:47
  • 4
    As Steffen mentioned, there's very little information on your question to permit a reasonable response. There's also suggestions of a few bad ideas in your implementation, starting from FTP, using Windows 10 to provide a service, your mention of a "Custom UDP" protocol as well as a web application. It may be the case that none of these are a problem, but they suggest a design that is not security-oriented. – Pedro Jun 3 '20 at 17:49
  • 1
    There are a number of concerning points to your proposal. I won't write an answer as they've generally been pointed out by the existing answers. However, I will concur that what you want to do is highly unusual, and if I were the network manager, while I might not claim that it would definitely cause a hack, I wouldn't think twice before denying the request. – Xander Jun 3 '20 at 20:13
  • 2
    Also, a bit of nit pick: Windows 10 isn't a server product and isn't licensed as a server product, so security issues aside you may run afoul of licensing which may or may not be more damaging to you than a hack of this machine. You should verify it's allowed to be used that way. – Steve Jun 3 '20 at 20:32
3

I see a couple red flags a network administrator would notice:

  • Custom Software

A custom software does not have a security tracking record. If it was an off the shelf software, even a buggy one, a systems administrator would know what they are handling. A custom software don't have it and the network admin must assume it's the most buggy software ever made, with lots of backdoors, shells, and so.

  • Custom UDP service

UDP is not the most network-admin friendly protocol. If you take into account that forging the origin of any UDP packet is trivial, and any service that accepts data on UDP and replies more data than it got will be used in a UDP amplification attack, it's easy to see why your network admin is not willing to allow this. Try to test if you really need UDP for this, and if the timing over TCP is enough. Most of the time, TCP is fast enough.

  • Custom authentication protocol

Another issue is this custom part. It have the same issues as the custom software: no tracking record, no external validation, only the developer assumption that it is secure. Consider using a currently used protocol that is being installed, attacked and patched already.

  • Plain FTP

Stay away from FTP, unless you have a really good reason no other solution would work. If file upload is really necessary, try to upload using HTTPS. Apart from being plain-text, the protocol have some interesting properties, like allowing an external client to connect to internal ports using FTP as a proxy. So stay away from it.

This application is not going to be used by a lot of people. I doubt it would fall into the hands of anyone who knows how to break this.

...as far as you know. Don't count on it.

own reliable implementation...

In my knowledge...

The only weak spot I might come up with...

Those are just assumptions, and you don't have anything to base them on. The problem is that you are the one making the software and at the same time the one vouching for its security. This is not the way to do, you need an external validation.

I don't want to be blunt, but if I went to your house and ask you to plug an unknown device on your internal network, open to the internet, and sending and receiving data, and giving you only assumptions, you would not be much willing to allow me, right?

I would ask you to redesign your application. Use only one interface for everything. Use TLS. Test to see if the latency is really a problem, and if one second of delay is acceptable. Ditch the custom UDP protocol, and custom authentication, and employ a known authentication library. Don't implement your own authentication, and don't even think about implementing your own encryption. Use a known framework for building the software, so you have a solid base to work on. And don't use Windows 10 as a server, it was not made for this.

If your company don't have the budget to pay for an external audit, you need to reduce the attack surface as much as possible, and reduce complexity. As it is designed, there's lots of custom parts, and a lot can go wrong.

Improve this answer
3
  • I have to mention the authentication is not custom. I made a mistake right there. I always thought "custom" was better because it's not something generic that would fall easy for generic hacks. The reason UDP was focused was because of the speed the platform needed to provide (MMO style). As of today, I noticed none of this is really used and if it really is such a security issue, it might be better to throw it away and expand on an HTTPS API. – Nick Peelman Jun 3 '20 at 21:28
  • Thanks for your answer, you've provided me with straight and direct solutions even with the few details I could give. – Nick Peelman Jun 3 '20 at 21:30
  • I can't upvote yet :( – Nick Peelman Jun 4 '20 at 5:02
3

We have a local virtual windows 10 server hosting some custom software.

Windows 10 might not be a good choice for hosting an Internet service, performance and security wise.

Custom UDP communication server (with its own reliable implementation)

Peer reviewed and pen-tested? Shouldn't be called reliable otherwise.

FTP server configured a usual

FTP needs to be secured with TLS, by itself it's insecure.

When I asked the network manager to allow these connections to this specific VM, he said it is very dangerous and that there is a 100% chance that we will get hacked.

He's likely correct unless your service was specifically hardened for Internet use. Any service available from the Internet will be attacked and when there's a security problem it will be found, sooner or later.

In my knowledge, it is very unlikely that someone might be able to penetrate my custom software

Based on what premise?

and get something useful out of it, let alone cause any harm with it.

It's quite enough to pass a not fully filtered parameter as SQL query, for instance, to allow SQL injection. That opens the door to steal your data or manipulate it, including user passwords.

The only weak spot I might come up with is our FTP service, which could be "hacked" and the intruder could potentially transfer malicious files to this certain folder.

Unless authentication is encrypted, it'd be easy to intercept user credentials, allowing impersonation.

I could upgrade to SFTP but I'm not very familiar with this service and have no idea if it's a major improvement.

SFTP uses mandatory encryption and is generally accepted as being more advanced and reliable.

Are there any major security leaks with this setup if we port forward it?

We can't really tell unless your code is properly reviewed and tested.

The authentication is based on a salted hashed password which grants a session token for a limited duration (30min). This connection is not encrypted, but I have not enough knowledge of knowing why it should.

Again, we don't really have enough information to comment. Generally, you should be sure that everything's tight.

This application is not going to be used by a lot of people. I doubt it would fall into the hands of anyone who knows how to break this. But I just want to be sure.

If it can be reached from the Internet it's going to be attacked.

Improve this answer
3
  • Thank you for all the answers! What I mean with unlikely to penetrate my software: The packets transferred are serialized and at first sight far from readable. This together with the custom reliability could take some time just to translate. After translation, without proper authentication, you can't read/view sensitive data. Aside from that, I use ORM's and split my DB entities and logic, there is never say never no way a SQL injection can occur. – Nick Peelman Jun 3 '20 at 20:18
  • I am aware of the security leaks my software might get into. What I don't have is a lot of experience with Windows servers and how secure they are when you open something to the outside world. If my server is listening on port x, I can assume nothing else can take over? If they DDoS'ed my server and it crashes, could maybe, another program start listening on that port and leak information or be more vulnerable? – Nick Peelman Jun 3 '20 at 20:21
  • @NickPeelman You're trying to convince security experts that your software is secure, and the more you try, the LESS anyone is convinced. Properly functioning security is peer reviewed. Someone else will come in and try to break it. Any sort of algorithm, security, encryption, etc, are all done like this, in a very vigorous process. If you're serious about your security, you'll hire a reputable security company to look at your server and do an evaluation. What your next step is "I hired company X to look at the software, and they said <report>." – Nelson Jun 5 '20 at 3:33
2

Are we, as he states, 100% going to be hacked?

Likely not. But this is actually the wrong question to ask. The question should not be if the system gets definitely hacked but if there is a realistic chance that it might get hacked, i.e. the probability does not need to be 100% but 10% might be risky enough.

Imagine only what the result might be if the system got hacked. Since you ask for port forwarding I expect your system to be part of the larger network - so somebody compromising your system might try to use your system to compromise this entire network from inside. How well protected is this network against such attacks from inside?

And even if this is an isolated machine: it serves data which by design should only be available when properly authorized. Consider the impact when somebody can bypass this requirement and steal the data or manipulate the data to their own advantage.

In my knowledge, it is very unlikely that someone might be able to penetrate my custom software and get something useful out of it, let alone cause any harm with it.

Basically you expect the network manager and us to trust your experience in writing sufficiently secure software just because you say so. I don't know what your experience in this area really is. But it looks like the network manager is not trusting your experience and why should we? If you are really sure that everything is properly done get well respected security experts you have in the company or hire external ones. Provide them with the risk analysis for your setup, design documents which show how you address these risks, implementation details etc. This way it is not only your word that the software is secure enough, but the word of acknowledged experts and the network manager will probably listen to these.

Improve this answer
4
  • I'm afraid that company will not be able to afford such expertise from outside. I can suggest it of course. Unless we do that I don't think we will be 100% sure. The only question I still have is if - and lets assume - my software is 100% secure, port forwarding the server brings other risks with it? – Nick Peelman Jun 3 '20 at 20:33
  • @NickPeelman: Port forwarding to a fixed system is not a risk - the risk starts at the system itself, i.e. a vulnerable application. Port forwarding might have an additional risk if the system on the IP changes (for example because of dynamic IP assignments with DHCP) and suddenly a system is accessible from the internet which should never have been exposed. – Steffen Ullrich Jun 3 '20 at 20:58
  • Ah yes, that is a risk indeed! Thanks for letting me know! – Nick Peelman Jun 3 '20 at 21:02
  • @NickPeelman: "Unless we do that I don't think we will be 100% sure." - there is no 100% security. It is about trying to reduce the risk as much as possible while keeping the costs low. For example if your system is on an isolated network the risk of infecting other internal machines is cheaply mitigated even though your application itself might still be vulnerable. – Steffen Ullrich Jun 3 '20 at 21:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.