PVS-Studio enters the battle with hardcoded passwords

PVS-Studio is a static analyzer that allows you to detect many problems hidden in the source code. They also include bugs related to application security. For example, the analyzer has recently learned how to detect the presence of confidential data in the code, such as passwords. This potential vulnerability is on the OWASP Top Ten list and is much more dangerous than it might seem at first glance. What is this danger, and how can a static analyzer protect you from it? Well, this article is written about this (and not only)!

We continue to develop PVS-Studio as a SAST solution and plan to teach the analyzer to find even more security-related errors in C, C ++, C # and Java code. More details about these plans (and not only) can be found in the article “PVS-Studio roadmap for 2021“.

About storing secret data in code

One of the options for the development of SAST support is the addition of new diagnostic rules that implement code compliance checking with various standards. Among the latest innovations in the C # analyzer is the check for confidential data in the source code. Storing such data in code is contrary to clause 2.10.4 of the OWASP Application Security Verification Standard (ASVS):

Verify passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are managed securely and not included in the source code or stored within source code repositories. Such storage SHOULD resist offline attacks. The use of a secure software key store (L1), hardware TPM, or an HSM (L3) is recommended for password storage.

Risks associated with unsafe storage of sensitive data in code are included in the list OWASP Top Ten… The Common Weakness Enumeration (CWE) also contains 2 positions related to this issue: CWE-798 and CWE-259… Despite this, the question may arise – what is the danger?

For open source projects, the answer is obvious – a password or some other data recorded in the code is available for everyone to view and use. An attacker does not even have to perform any complex actions: it is enough just to dig into the repository.

The situation is somewhat better if the application is available only in compiled form. It can even create the illusion of security. After all, the source code, it would seem, is inaccessible, which means that the data recorded in it is also inaccessible. Alas, this is not necessarily the case.

In real practice, it is not uncommon for the system to have hardcoded data that can be used to obtain various rights. Typically, users do not even have the ability to change this data. Attackers can use a variety of methods to obtain them. In some cases, logins, passwords, etc. can generally be seen in the system interface. In others, you will need to study various files, decompile the code, brute force, and so on. One way or another, craftsmen know how to find ways to reveal hard-coded secrets.

The following problem is quite often relevant: an attacker, having received logins and / or passwords stored in the source code of the system, will be able to use them to connect to other systems of this type. For example, he can install the system locally. After conducting research and obtaining logins and passwords for this local version, the attacker will be able to connect to others using the same data.

In addition, the fact that the data stored in the source code is available to all programmers who work with it poses a potential danger. At the same time, a user who has installed this or that system for his own needs is unlikely to be happy to know that the development company at any time can get full control over the system it uses – and, consequently, get various secret data of the user himself, etc. e. Found in the list Common Vulnerabilities and Exposures (CVE) occurrences indicate that such errors are discovered sooner or later. And at the same time, of course, they are put on public display.

As mentioned earlier, vulnerabilities related to hardcoded confidential data are not uncommon: there are many examples among CVEs. One of them – CVE-2012-5862… The system reported in this CVE contained a “login.php” file with the following code present:

$password = mysql_escape_string($_POST['password']);

if (crypt($password,salt)=='satIZufhIrUfk'){
  $sql_pthr_ = "SELECT user,password FROM account WHERE livello = 0";
  ....
}

if ($password=='astridservice' and $stilecustumization=='astrid'){ // <=
  ....
}

if (crypt($password,salt)=='saF8bay.tvfOk'){
  $sql_insert="INSERT INTO account(user,password,livello,nome) VALUES  
               ('sinapsi','sinapsi','0','Amministratore Sinapsi')";
  ....
}

There is a place in this code where the variable containing the password passed by the user is directly compared to a string literal. Obviously, it will not be difficult for an attacker to use this information to perform various operations that are not available to an ordinary user.

PVS-Studio C # analyzer detects storage of confidential data using a diagnostic rule V5601… For example, take a look at C # code that resembles the above example:

string password = request.GetPostValue("password");
....
if (password == "astridservice" && stilecustomization == "astrid") 
....

After analyzing this code, PVS-Studio will generate the following warning:

V5601 Suspicious string literal could be a password: ‘astridservice’. Storing credentials inside source code can lead to security issues.

Thus, a static analyzer will allow you to notice such an error in the code in time and make a correction. Consequently, the security level of your project will also increase.

Note… It is worth noting that V5601 belongs to the OWASP diagnostic rule group. This group will appear in PVS-Studio with the release of version 7.12. By default, OWASP rules will be disabled, but this can be easily changed using, for example, the plugin interface for Visual Studio or Rider, or by directly editing the settings file.

This example is just one of many: hardcoded confidential data can lead to all sorts of problems. During my research, I have found many other CVE positions related to hardcoded confidential data. Below are links to some of them:

• CVE-2004-1920 – a router with super-login and super-password;

• CVE-2004-2556 – access point with super-login (again) and non-super-password “5777364”;

• CVE-2004-2557 – the result of the “fix” CVE-2004-2556 (at least the login is no longer super);

• CVE-2012-1288 – hardcoded administrator account data;

• CVE-2012-2949 – hardcoded password in the Android app

• etc.

Another reason to run the analysis regularly

There is a widespread belief that it is enough to use a static analyzer once every few months – before the release (or even once a year). This is a rather strange position. Fixing problems that have accumulated over a lot of time is much more difficult than fixing the code you just wrote before committing. Moreover, thanks to incremental analysis the check will be much faster.

In many cases, a convenient option would be to configure the analysis of commits and pull requests. This will further increase the security of the developed application. After all, the code containing errors will never get into the main branch of the repository. This will be a real salvation if the developer suddenly forgot to analyze. You can read more about how to set up the check for pull requests. in the documentation (see the section “Deploying the analyzer in cloud CI”).

The new ability to search for confidential data in the code once again confirms the need for regular analysis: both on the computers of programmers and within the framework of CI. After all, even if the programmer puts some passwords in the source code, the analyzer will inform him about it. If necessary, the developer can look at the diagnostic documentation V5601to understand exactly what the danger is.

If the analysis is carried out rarely, then it turns out that the hardcoded data will be stored in the source for a long time. For an open-source project, this is very bad – by the time the analyzer detects the problem, the data can no longer be considered confidential. However, other projects are not protected from a similar situation. What if the user gets, say, a beta version of the app? This can be issued between releases. If regular checks of the sources are not carried out, the code in this version will not be checked by the static analyzer. It turns out that all the data “hidden” in the source code is again in the public domain.

Conclusion

PVS-Studio is constantly evolving: new diagnostic rules are added, some existing mechanisms are being finalized, new directions are opening up. It is also worth noting that in many ways it is the constant dialogue with users that makes the analyzer better. And the diagnostic rule V5601 Is just one of the components that make the analyzer a tool that will improve the security of your projects’ code.

How about trying to use PVS-Studio on your projects? You can do this completely free of charge by going to link and filling out a simple form. Well, that’s all for me, thank you for your attention and see you soon!

If you want to share this article with an English-speaking audience, please use the translation link: Nikita Lipilin. PVS-Studio Clashes with Hardcoded Passwords.