As the title suggests, username/password/private key is stored in clear text in /cfg/config.json. Can we get this in hash?
Surprised this hasn’t received any attention yet. Why are credentials being stored in clear text?
Alta can you confirm that this is showing in production? If so, This would be a vulnerability that could reach a CVE Database.
You can verify by ssh into the route 10 and confirm.
I can confirm the radius configs are all plaintext, including usernames, passwords, PSKs, and PrivateKeys.
@Alta-Jeff @Alta-Chase Is this at least being worked on?
Team, at the least a basic penetration test needs to be conducted and remediated. Additionally, basic hardening standards need to be applied.
We have a bug bounty program, and have performed security penetration tests internally and externally, and there are no outstanding issues.
The Radius settings are stored in RAM only, and only accessible by the administrator. For access to the /cfg/config.json file, someone would need to have administrator access to the device already. We have considered encrypting the /cfg filesytem at rest, but to reiterate, someone would need to have administrator access to the device to access the contents anyway.
Passwords should NEVER be stored in plain text. Ever.
Radius supports encrypted or hashed password storage in all current implementations.
Also the “requiring admin access to even see this” is not considered valid protections against bad practices like this in any modern compliance or security framework. What if there is a future bug or issue that allows remote privilege escalation or access? Boom, now everything is hosed.
These excuses are, frankly, inexcusable.
That is extremely disappointing to hear. If I deployed even 1 switch at work without it being set to encrypt stored credentials I would be fired.
If you’ve ever implemented a password-authenticated RADIUS Server before, you will know that passwords must be stored in plaintext at some point. There is no way around it, other than to use other, more secure forms of authentication, such as certificates. This is common practice across other enterprise networking vendors, by the way.
Even if a non-administrative task is somehow compromised, the password files themselves are not accessible by non-administrator users. If you believe you have found an actual vulnerability, I encourage you to reach out to security@alta.inc or support@alta.inc to submit a bug report.