Are You Guilty of Embedding Credentials into Your Source Code?
Everyone fears that their usernames and passwords will be exposed to malicious hackers so why do many developers still use embedded credentials in their software? Also known as hardcoded passwords, embedded credentials are written into source code to make life a little easier for the developer during software development. Hardcoded passwords refer to plain text passwords or other sensitive information such as account passwords, SSH keys, DevOps passwords, and so on. They are often found in hardware, firmware, scripts, applications, software and are used to help developers quickly access the product and generally make life simple especially when setting up new systems during the development stage.
Hackers love embedded credentials and regularly look for them in the applications that they target. In recent years, with industries worldwide embracing the use of open-source software, the security problems caused by hardcoded passwords have emerged in an endless stream. In 2016, the now famous Uber data breach which caused the private information of 57 million customers to be leaked was the direct result of a hardcoded password used in open-source code which was part of Uber’s runtime environment. An Uber employee used a hardcoded password in source code that was uploaded to GitHub which allowed a hacker to obtain and login to Uber’s AWS account. Uber paid a huge price for this error with fines of USD400,000 in the UK, USD660,000 in the Netherlands and more than USD148M in the United States. This huge cost was caused by a known common programming flaw that essentially required security-minded discipline to have been prevented.
When I say it is a known common programming flaw, both OWASP and CWE, which are authoritative projects in the security field, have detail descriptions of hardcoded vulnerabilities with recommendations on how to avoid them.
In the OWASP top 10 list of 2017, sensitive data exposure is ranked at number 3. It clearly points out that in the past few years, the leakage of sensitive information has become a very common type of attack and the most common flaw in the category is the use of hardcoded passwords.
For CWE, the use of hardcoded passwords, CWE-259, is number 19 in the CWE top 25 list. They state that the two most common scenarios are as follows:
a) Inside the software – when the administrator account details are embedded into the code and cannot be modified or deleted after release otherwise leading to the inability to use the product
b) External to the software – where the front-end contains the hardcoded password required for the back-end meaning it can be easily extracted.
Let’s examine some sample code of how credentials are typically embedded. This sample below is a piece of JAVA code to test a database connection. In line 16 of the DEBUG environment, the default account “admin” and password “dbtest” is set for the database connection. Although this code only takes effect in the DEBUG environment, the default account information is hardcoded into the system, through decompilation, it is easy to identify the account information.
The following figure is the result of the decompilation of the class file generated by DBConnect.java. It can be seen that the account and password information are stored as plain text in #10 and #11 of its constant table.
What’s wrong with this? First of all, even if the source code is not shared, the plain text password will eventually be written into the running binary file. Hackers and malware can easily obtain password information through a decompilation tool. Across a system, it’s common for developers to use the same credentials in ancillary applications. Given this, once the hacker has cracked the password, he or she can connect to all related software and devices potentially causing greater damage. Second, once the plain text password is written into the released software or device, it cannot be modified. This is not conducive to product maintenance and breaks the golden rule for the need to frequently change credentials. Third, from the perspective of code programming specifications, the use of embedded plain text passwords will lead to the code logic and data information being coupled together. This works against the principles of a unified data information management model for holistically coordinating teams and integrating tools.
As a developer, you should consider safer ways to manage passwords and implement policies to adhere to. Most security-minded developers should go even further than manual checks. There are automated tools that can detect hardcoded password issues during the implementation phase before the code is compiled. Xcalibyte’s static code analysis tool, Xcalscan, can scan source code to identify vulnerabilities including unencrypted embedded credentials. You can see how this is done in Xcalscan in the scan results image below.
Using a tool like this is a safety net for those developers that hardcode passwords for temporary use but then forget to delete them later. Using SAST tools like Xcalscan can effectively avoid embedded credential vulnerabilities caused by forgetfulness.
Here are some of my password management suggestions for your consideration.
1. Use a unified password management module to handle password encoding, verification etc.
2. Save the credentials information in a separate file or database where the file must have strict access control and cannot be stored in a public location.
3. Do not store the password in the form of plain text, you can use an encryption method (two-way algorithm) or use a hash method (one-way algorithm).
4. Use static code analysis tools designed for defect and vulnerability detection.
Above all change the culture so when writing code, you and your teammates always use a ‘security by design’ approach. Think like a malicious attacker and ask yourself what you would do to gain access to the software. Do not leave the house key in the door or under a plant pot for the hacker to easily find!
Author: Qing Zhu is a software engineer at Xcalibyte. She’s part of the development team for Java based static code analysis working on front-end, back-end and rule implementation.