Password authentication has been used for centuries, long before computers existed. In Roman times sentries would challenge whoever wanted to gain access to a restricted area or place by asking them to supply a password or watchword.
Over history, and specifically during war times, passwords have been used to restrict access to information, and to identify individuals.
In more current times, passwords are commonly used by applications to uniquely identify users and enforce access control rules based on the authentication outcome.
Early UNIX operating systems were designed to have a password file containing all the plaintext passwords of all the users. Security relied on the protection of such file, to ensure that it was not accessible to any users apart from the administrator of the host. This approach was proven to be vulnerable to a very wide number of attacks and temporary loss of protection was prone to happen while the file was being updated.
Unix System v3, released in 1972 – 50 years ago! - firstly introduced the crypt function which allowed the encryption of plaintext passwords. It is a function that it is nowadays considered weak and obsolete, especially with modern computational power, but it was a milestone in security architecture design.
Fast-forward 50 years. One could assume that the experience accumulated over half of a century would help in the improvement of the design of information systems. In many cases that’s the case, and modern operating systems, directory services, applications, etc. would not store clear-text credentials for authentication. Storing encrypted passwords is so overwhelmingly better that there’s very little reason to store clear-text credentials.
Even in modern day people still make silly mistakes, it's human nature, however as security researchers its our job to capitalise on these mistakes to inevitably lead to them being fixed.
CVE-2022-20942 – sensitive information disclosure
Cisco runs a proprietary operating system called AsyncOS, originally based on a modified FreeBSD kernel. According to Cisco, “The Cisco IronPort AsyncOS operating system lets Cisco IronPort appliances process mail more than 10 times more efficiently than traditional UNIX systems do, providing extremely high capacity and availability.”
Cisco Email Security Appliance (ESA), Cisco Secure Email and Web Manager, and Cisco Secure Web Appliance, formerly known as Cisco Web Security Appliance (WSA) all run Cisco AsyncOS. They are all affected by a security issue whereby an authenticated attacker can disclose sensitive information by accessing legacy functionality that was intended to be removed due to its lack of security controls. The issue does not only directly affect the security of the software, but also shows a non-optimal design of the products, when it comes to password management and authentication.
Cisco AsyncOS Version 14.1 and earlier are affected by this issue.
On AsyncOS Version 11, Cisco introduced a change whereby users would not be allowed to download or save configuration files with clear-text passwords on them.
This seems to be a very sensible measure, but it didn’t address the root cause of the issues, which is the fact that plain-text passwords should not be stored by the AsyncOS operating system in the first place.
During a security assessment, it was identified that although the feature was aesthetically removed from the web UI and the CLI, it was indeed possible to disclose such information, as the functionality was still present on the application.
In essence, it is possible to modify a parameter in the HTTP request from the web UI to the back-end, to successfully disclose the sensitive information.
The following steps can be followed to replicate the issue:
- Ensure you have the web proxy of choice set up ready to intercept traffic
- Log in using an account with Admin or Operator privileges via the web interface/portal
- Navigate to ‘System Administration’ > ‘Configuration File’
- Download the configuration file either as masked or encrypted but intercept the requests
- Upon intercept, modify the parameter ‘password_config’ value to ‘plain’ e.g. password_config=plain
- You will then be met with a second request, again you need to modify the same value to ‘plain’
What is the impact of this?
The CVE score for this issue is medium. This is largely due to the fact that the issue can only be exploited by authenticated attackers with some level of administrative access to the device.
However, the issue opens an opportunity for an attacker to target an administrator and conduct additional attacks (such as Cross Site Scripting, for example) to gain access to the password, without having to authenticate first. In such situation, the impact of the issue can be rather substantial.
Exposure of configuration content to an attacker operating in a network can potentially lead to:
- direct compromise of other network devices
- attacker’s understanding about the network routes and structure
- exposure of login information
In fact, when the issue was discovered, it was possible to extract LDAP / FTP credentials, private keys and other network information which allowed the compromise of other systems and to move to other segments within the network.
Conclusion:
SECFORCE discovered and subsequently responsibly disclosed said issue in July 2022. The issue outlined in this post illustrates the importance of tackling the root cause of security issues effectively, and implement a secure by design approach when engineering solutions or features. Strong security foundations allow software engineers to build functionality on top of safe and tested principles, and therefore minimising the number and impact of security issues down the line.
References
https://www.profsandhu.com/cs6393_s13/p594-morris-1979.pdf
https://en.wikipedia.org/wiki/Password
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-20942
