code4thought

SOFTWARE QUALITY

Application Security:
The threat from the inside
that gets ignored

11/04/2023
12 MIN READ  /
Author
Iason Tzortzis
Secure Software Analyst | code4thought
In this article we discuss the risks of hardcoded credentials in source code and potential mitigations that can help eliminate those risks.
The most notable of those being the increase, that hardcoded credentials create in the attack surface of an organization because of possible leakages and also the extent of damages that those leakages can result in regarding financial, reputational and operational costs.
In order to prevent the aforementioned risks, certain processes need to be put in place. Some potential mitigation strategies are the storing of secrets in password vaults that are provided by cloud providers (for example AWS, Azure, etc.) or use of open source alternatives and the store of secrets in configuration files that are separated from the source code in order to minimize the attack surface and the possibility of leakage.
Hence, it is crucial for organizations to set up processes that manage their secrets because of the compounding effect that a leakage can cause.
Introduction:
A significant number of risks arise when secrets are hardcoded in the source code. Their presence in the source code of systems increases the attack surface for organizations, creating the need for extra resources to be able to isolate and secure them. In this article we are going to discuss what hardcoded credentials are, how they can be categorized, what are the risks associated with having them and finally about potential mitigation strategies that can help tackle the aforementioned risks.
The term of hardcoded credentials in source code as described in CWE 798, refers to “Software that contains hard-coded credentials, such as a password or cryptographic keys, which are used for inbound authentication, outbound communication to external components, or encryption of internal data.”[1]
There are two variants that hardcoded credentials can be described with: the inbound variant, where the system checks user supplied credentials against a set of hardcoded credentials in the source code, and the outbound variant, where a system uses hardcoded credentials to communicate with external sources.
Example of exploitation of outbound variation:
The Toyota incident, where a hardcoded key was found in the source code of a public Github repository [2].
Example of exploitation of inbound variation:
Confluence incident where hardcoded credentials were found in the source code of an account that was created by Confluence to help admins migrate data from the Confluence app to the Confluence Cloud.[3]

Risks associated with having hardcoded credentials in source code

In order to talk about the risks we are gonna put them against the CIA acronym [4]:
  • Confidentiality: When it comes to the confidentiality of a system, if an unauthorized party gets access to the source code and finds hardcoded credentials, then it becomes totally compromised and non confidential because of the access that the unauthorized party has to the information flowing through it.
  • Integrity: When it comes to the integrity of a system, if an unauthorized party gets access to the source code and finds hardcoded credentials, it can use those credentials to tamper the data of a database that the system communicates with, thereby wiping away any integrity of the system.
  • Availability: When it comes to the availability of a system if an unauthorized party gets access to the source code and finds hardcoded credentials, it can use those credentials to make an infinite amount of authenticated actions with the intention of causing DoS(Denial of Service) to the system rendering it unavailable.
Below are listed some potential mitigations that can help tackle the aforementioned risks combined with their pros & cons and with an estimated level of effort that ranges from 1-5. With 1 being the least and 5 being the highest amount of effort needed for the mitigation to be implemented.

Potential mitigations:

1) Store of credentials in encrypted configuration files that are separated from the source code with the use of strong algorithms like AES, combined with a decent sized key >= 128 bits and secured from unauthorized access. When it comes to inbound authentication, use strong one way hashes combined with randomly assigned salts and then compare the hash of the password supplied with the hardcoded hash.
Estimated effort: 3
Pros
By separating the credentials from the source code in encrypted configuration files, we reduce the attack surface to only a single location and we add an additional layer of protection by encrypting them. In the case of inbound authentication the hashing of the credentials combined with the randomly assigned salt add a substantial computation cost to the malicious actor if they want to obtain the credential.
Cons
The setup of the aforementioned solution is difficult to implement, because it creates the need for encryption key rotation and management which creates the possibility of human error in the key management process, resulting in operational costs that will be used to resolve the issue and also the existence of hardcoded hashes in source code when it comes to inbound authentication.
2) Store of credentials in a secure database that has its data encrypted and is protected from outside access that communicates with the application securely during startup to deliver those credentials.
Estimated effort: 3
Pros
By storing the credentials in a secure database that has its data encrypted we reduce the amount of credentials that need to be managed in the source code, down to only the ones that are needed for the connection with the database and the encryption key used and also by having the data in the database encrypted we add an additional layer of security. Also, we reduce the attack surface to a single location which can be managed easier because of monitor mechanisms that can be implemented on the database.
Cons
The system depends on the uptime of the service because if the service for some reason goes down, the system cannot function properly and it also creates the need for a new service that communicates with the system in a secure way (using HTTPS with TLS 1.2 or higher) thereby adding maintenance and operation costs. Lastly, there is the existence of hardcoded credentials in the source code that are used for the connection with the database.
3) If encryption of the configuration file is not possible, restrict access to it as much as possible and when it comes to inbound authentication use strong one way hashes combined with randomly assigned salts and then compare the hash of the password supplied with the saved hash.
Estimated effort: 2
Pros
As mentioned in the first mitigation, by separating the credentials from the source code in configuration files, we reduce the attack surface to only a single location and also in the case of inbound authentication the hashing of the credentials combined with the randomly assigned salt add a substantial computation cost to the malicious actor if they want to obtain the credential.
Cons
Existence of hardcoded hashes in source code when it comes to inbound authentication and in case of leakage, all the credentials will be in plaintext.
Remark:
For credentials that are on the front-end of an application that are used for communication with the backend, the solution is to restrict their access and available actions to only necessary ones for the frontend functionality.
To be able to understand the above, let’s take the example of an application that uses a Google Maps API key that is included in the frontend html to communicate with the backend to be able to perform certain actions. In some cases, the Google Maps API key can be shared with other Google services which would increase its sensitivity.
In this situation, the API Key is exposed to the user and can be easily intercepted. Therefore, it is crucial to put restrictions on it via the Google API Console, so it can’t be used for malicious actions that may cause financial or operations damages in the organization.
4) Use of password vaults, which are basically a centralized service in an organization which through API interfaces gives the ability for authorized actors to get access to the secrets they have permission to access. Those services are usually provided by the popular cloud providers, AWS, Azure etc. In case of the aforementioned not being available there are also open source alternatives like Confidant [5].
In case of using password vault of popular cloud provider:
Pros
By storing secrets in a password vault we achieve the elimination of hardcoded credentials from source code. Also the secrets will be encrypted and stored in a secure location that is hard to access and easier to manage from an organization’s perspective, because of the unified interface most password vaults provide in regards to secret management and logging & monitoring capabilities.
Cons
Possible breach if the account of an authorized actor gets compromised.
Estimated effort: 1
In case of using open source alternative:
Pros
By storing secrets in a password vault we achieve the elimination of hardcoded credentials from source code. Also, the secrets will be encrypted and stored in a secure location that is hard to access and easier to manage from an organization’s perspective, because of the unified interface most password vaults provide, in regards to secret management and logging & monitoring capabilities.
Cons
Possible breach if the account of an authorized actor gets compromised. It also creates the need for the upkeep of a new service and if the service goes down, all the systems that are reliant on it cannot function. Finally, it is susceptible to MITM, if the communication channels are not properly configured and secured.
Estimated effort: 5

Conclusion:

The exploitation of hardcoded credentials has contributed to a huge number of incidents in the past few years. To realize how big their potential threat surface is when they get exploited by malicious actors, we only have to consider the habit of humans of reusing credentials across different places on the internet or throughout their organization and also the effort it takes to change a credential that is hardcoded.That being said, it is crucial for organizations to set up processes that manage their credentials, to be able to deal with the increase of attack surface that derives from their presence in the source code of systems.
So, when it comes to the organization level the most ideal solution would be the use of password vaults. This conclusion derives from the benefits the password vaults provide, in regards to management capabilities and how secure they are when configured properly.
Sources: