nats-server
nats-server copied to clipboard
nats-io
According to OWASP Top10, we should be able to hide Nats & Go version from the response of nats server
Feature Request
Being able to hide software versions from the response of the nats server
INFO {"server_id":"XXX","server_name":"XXX","version":"2.1.8","proto":1,"git_commit":"c0b574f","go":"go1.14.8","host":"0.0.0.0","port":443,"auth_required":true,"tls_required":true,"max_payload":1048576,"client_id":255989,"client_ip":"X.X.X.X","nonce":"XXX"}
Use Case:
When doing business with Pentesters, it ends up in the report, according to Owasp top10 "Security Misconfiguration".
Proposed Change:
I think it should be by default is there is no usage of those versions ? Or simply a configuration setting.
Who Benefits From The Change(s)?
Every customers
Alternative Approaches
N/A
If we are addressing this type of info, may also want to consider masking cluster as well.
@aricart I don't understand, I don't see any "cluster" property in that json response ?
Depends on your cluster configuration. On some setups, it is visible.
On Thu, Feb 18, 2021, 8:04 AM Jean-Michael Cyr [email protected] wrote:
@aricart https://github.com/aricart I don't understand, I don't see any "cluster" property in that json response ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nats-io/nats-server/issues/1919#issuecomment-781365612, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH4GECCOIILLV2JIHRYWZ3S7UM6PANCNFSM4XZA3EHA .
Not always that simple, we have identifying names we cannot remove - advertise urls for clients, clusters etc - and others that we may not be able to do in future - cluster name might be required.
To really address this we'd have to revisit considerably the purpose of the INFO header and what we negotiate after authentication and begore authentication.
Is it reasonable to start by hiding the pieces which are not required for clients to connect? I can't imagine that the clients require the go version, git commit or possibly even the nats verison.
We now require version for some clients to know which features etc.
Is there any reason outside of the pen testing issue above? Why would we want to do this?
The only reason to hide it is to prevent an easy way to find versions which contain vulnerabilities. For example, if one wanted to find servers which are vulnerable to CVE-2021-3127, they could scan the internet (or someone's private network) on port 4222 and filter on versions 2.0.0 - 2.2.0.
Understood, but I think in this case its more important for properly working clients and identifiable feature sets etc.
We could potentially see this as an opt-out, however, that would mean that many of the new client features would fail to work.
I think an opt out would be fine. Maybe later the clients can become smart enough to check the feature status after login?
Some things are features based like headers etc, but some other functionality is more nuanced and requires certain server versions to work correctly.
What if it was like 2.x.x or 2.6.x, would that help at all?
I think any reduction in detail here is an improvement. If it only shows the major and minor version and git_commit, go removed as well then it reduces the information disclosure significantly. Another red flag that came up in our audit was the client_ip. Could that be optionally removed as well?
So remove patch version only? If they have the git commit they can find out everything they need as well.
Not sure about client_ip, that has been very useful, what does that leak?
I agree git commit would give them everything they need.
I think we should remove the patch version, git_commit & go version. The client_ip exposes internal networking details which could be used along with other attack surfaces.
Depends on your cluster configuration. On some setups, it is visible. … On Thu, Feb 18, 2021, 8:04 AM Jean-Michael Cyr @.***> wrote: @aricart https://github.com/aricart I don't understand, I don't see any "cluster" property in that json response ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1919 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH4GECCOIILLV2JIHRYWZ3S7UM6PANCNFSM4XZA3EHA .
how can we disable this? what's the configuration?
The weakness displayed here leads to an reconnaissance method called banner grabbing. If a random Internet user finds the port and pulls this data the question should be, why are they permitted to see it? One option would be to provide control over which headers are exposed to unauthenticated unauthorised users (i.e. Johnny or Joanne random Internet user / script kiddie / hacker) and provide guidance for the admins on how and why to use this new function. Other options are out of scope and involve security in depth. For example, using MTLS, or a VPN, or an approved source IP list. But this might not be obvious to every administrator and might only again pop up when a security researcher or pen test group finds it and flags it. The security principle being missed here is the principle of least privilege. Provide nothing and grant what is needed. The inverse is difficult if not impossible to manage which is be grant everything and remove what is not needed.
Looping in @philpennock to garner his opinion.
Again, certain parts of the system require exchanging version information, especially between servers. But depending, that could be sent after some level of security and auth has been established. Most clients support multiple INFO block updates so not easy but possible.
Playing devil's advocate, most non-sophisticated attackers simply blitz anyway, meaning instead of saying connect to the port, see if someone is home, if so check version, then try attack, they normally just do step 1 then 3.
We're doing security enhancement all over in our setup (which includes the great nats-server project :grin: ) and we'd appreciate to have the capability to hide this info as well :+1:
Right now its not a top priority our customers are asking for in the security realm. We will of course keep it open but have not scheduled anything yet.