Welcome back to CVE Wednesday! Today we are going to look at the following three CVEs:
We are going to take a less technical approach this week than usual to focus on some of the higher level topics in triaging vulnerabilities.
Below is a write up of my thoughts on whether or not these reported vulnerabilities are “CVE-worthy”.
I did not have access to a vulnerable host or the vulnerable firmware for these CVEs, so this post is not going to focus on the technical aspects of the vulnerability. I am going to make the assumption for this blog post that the Proof-of-Concept scripts work as intended, which does not seem to be disputed by any parties involved, vendor included.
All three of these CVEs are command injections in Ubiquiti EdgeRouter X 2.0.9-hotfix.6. The NVD entries for all three vulnerabilities link to vuldb advisories which contain the proof of concept python code for exploiting each vulnerability. While the proof of concept scripts seem well written, the authors do not introduce any novel techniques for exploiting command injection vulnerabilities via HTTP requests. Kudos to the authors for discovering and reporting these issues, though.
In reality, the aspect of these CVEs I find the most interesting is the vendor response.
Attached to each of these CVEs in NVD is this bit of verbiage:
NOTE: The vendor position is that post-authentication issues are not accepted as vulnerabilities.
Now it is my opinion vendors are well within their rights and responsibilities to “accept the risk”
of a reported security issue when deciding whether or not to fix it. Presumably this is what happened in this case; the vendor decided not to fix a reported vulnerability because exploitation requires authentication and as such rejected the report. It feels like there should be additional clarification on why post-authentication issues are not accepted.
But the question becomes, does “accepting the risk” of a vulnerability mean it should not receive a CVE?
Since I do not have intimate knowledge of how the affected product is administered, there are a few questions I need to pose before determining whether or not a CVE is warranted.
1) Is the web administration interface the only way the product can be administered? If the answer is yes, then these are definitely CVE-worthy vulnerabilities as they demonstrate an attacker can escalate from Authenticated Web Request to Operating System Command execution (CLI access). If the answer is no and there is some sort of CLI access available as part of the product, then we move to question 2:
2) Are the same administration credentials that allow web access to exploit the vulnerability used for the baked-in CLI shell access over SSH (or Telnet)? If that is true, then there is very little point in exploiting the command injection vulnerability as the same credentials could be used to access the underlying host operating system. This is the case if SSH on the product exposes a general purpose operating system shell like bash.
According to https://dl.ui.com/datasheets/edgemax/EdgeRouter_X_DS.pdf (page 3):
Configuration by CLI
The CLI provides quick and flexible configuration by command line and features the following: • For power users, configuration and monitoring of all advanced features
• Direct access to standard Linux tools and shell commands • CLI access through SSH, Telnet, and the graphical user interface
3) Even if there is baked in CLI access, are there common deployment scenarios where an attacker would have access to the web-administration interface and not the CLI interface? A lot of times Web admin interfaces are left exposed on ports 80 or 443 and then ports 22, 23, etc usually used for CLI access are blocked or dropped by an upstream firewall. While this is heavily deployment-specific, if this is a common deployment pattern, then these vulnerabilities should have CVEs despite baked-in CLI access being available - even if it is with the same authentication credentials.
My take is that if the proof of concept scripts demonstrate what they claim to demonstrate, these are legitimate security vulnerabilities - albeit of a reduced impact due to the authenticated nature of the attacks. It is totally possible that the scripts don’t actually work, but this is not what the vendor response claims. The vendor response specifically calls out post-authentication issues.
However, if the same web admin credentials provide access to the CLI, then these vulnerabilities are probably not CVE-worthy as the vendor allows access to Linux CLI utilities via the baked-in CLI.
I believe each of these vulnerabilities deserves a CVE despite the vendor not accepting the issue as a vulnerability so long as web admin credentials are not equivalent to CLI credentials. Vulnerabilities like this are often chained with other vulnerabilities (like an authentication bypass) to achieve full system compromise. This means that these CVEs may not be as useful until another, authentication-related vulnerability is discovered. Sometimes it takes years before a new vulnerability can be found to make use of vulnerabilities like these.
As an attacker without CLI port access, I want to know about vulnerabilities such as this so I know where I can target my efforts if evaluating a specific piece of software or product. In this case, I would narrow my search to vulnerabilities in the web-based authentication and authorization subsystems of the product, since I know once I have that I can easily use one of the headline CVEs to escalate to a shell on the host. Also, I now have an incentive as an attacker to target these types of products since I know the vendor is most likely not going to fix the post-auth security issues; that means they will be there years from now when an authentication bypass is discovered.
As an attacker with CLI port access, I just want to know the credentials to authenticate as (assuming the web admin credentials are the same as the CLI authentication credentials).
There are certainly instances when it is appropriate for a vendor to dispute a CVE. However I find the reasoning of “post-authentication issues are not vulnerabilities” not to be sufficient in and of itself as a reason to dispute a CVE. Yes post-authentication vulnerabilities are not as exciting as unauthenticated vulnerabilities, and yes the impact is much lower. However, even if they do not end up being fixed, CVEs serve as documentation that the vulnerability exists in a specific product for a specific version(s) - not whether or not the vendor accepts post-authentication “issues” as vulnerabilities or not. At the same time, if the web credentials allow the same level of access necessary to access the CLI, then these are not CVE-worthy because the same command could be run from the CLI instead of the “vulnerability”.