In 1977 Digital Equipment Corporation (Digital) released the VAX computer. The system shipped with the VMS operating system that included multiple default accounts with default credentials. Digital expected system managers to change the passwords for these default accounts when they set up the system. Many systems never had these credentials changed, creating an easy way for attackers to get privileged access on these systems. Default passwords are still a problem today.
When discovered, default passwords expose a large number of devices at once. While the problem they create is well known and documented, avoiding them is not an easy task. Recently I have been examining ways to mitigate the risk from the vendor perspective of support accounts that ship with devices. I have come up with three suggestions for vendors that have a need for support accounts and want to still limit the risk they add to their products. I suggest having support accounts disabled by default, limiting the risk caused by the exposure of any credentials, and limiting access to any access logs that reveal information about failed logon attempts.
One way to lower the risk created by support accounts while still enabling a vendor to sign in would be to have them disabled by default. The method for enabling the support account will still have a large impact on the risk it creates. If an attacker is capable of enabling the support account then this will only add a step to their intrusion. Our goal here is to put as many barriers in front of an attacker while still providing a simple process for support staff. I suggest requiring customers to take some action to enable the support account. This will be easier to justify for products being marketed to IT professionals than consumer devices. I also suggest that when support teams have finished using the account that they disable it for the end-user. Suggesting the customer disable the account themselves will lead to many devices keeping the account enabled.
Anytime there is a password for a system you should create a mechanism for changing it. If there is not a mechanism for changing the password then credential exposure will likely require an update to prevent credential misuse. There are some situations were shared credentials will be hard to avoid. Shared credentials provide auditing challenges when trying to attribute log entries to individuals. If those credentials are deployed globally across all deployments an exposure will not only affect one device but all of them. For both of these reasons and others, shared credentials should be avoided. When shared credentials are used the ability to change the password becomes even more important.
If a support account is enabled on a product then any entity with access to the product can freely try to brute force the credentials. The availability of access logs can decrease the amount of time needed to brute force the credentials. This is because many access logs include the username tried and whether the password was wrong or if the user does not exist. I have used this before to identify the username for an account. This information can be used to conduct a simple discovery scan for legitimate user accounts. An attacker can then use this information to focus their brute force attempts on only those users. There is a legitimate use for access logs however they need to be integrated into the devices alerting capabilities; otherwise, they will only provide forensic value for defenders and reconnaissance value for attackers.
I wrote this because I had trouble finding material to read when I was starting to work through the challenge of securing support accounts. Many articles can be quickly found stating problems with default credentials but few offering suggestions and those that did were hard to apply to the use case of support accounts. This advice is not designed to be comprehensive or used alone when designing a security strategy. I hope you find this to be useful and that it helps you start thinking about how to properly secure accounts that ship with your systems.