To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (an extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
RUB
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
>
PVS-Studio clashes with hardcoded passw…

PVS-Studio clashes with hardcoded passwords!

Mar 02 2021

PVS-Studio is a static analyzer that allows to find many problems hidden in the source code. Among them there are also errors related to application security. For example, the analyzer has recently learned to identify the presence of confidential data such as passwords in the code. The OWASP Top Ten list includes this potential vulnerability. It is much more dangerous than it may seem at first glance. What makes it so dangerous? How can a static analyzer save us from it? That's what you'll know about (and more) in this article!

0805_Hardcoded_Passwords/image1-080f75966954776eb703c07c20c53c1c.png

We are continuously developing PVS-Studio as a SAST solution. We plan to improve the analyzer skills in finding even more security-related errors in C, C++, C#, and Java code. You can read up on these plans in detail (and find more information) in PVS-Studio Roadmap 2021.

Sensitive data stored in your code

One of the options for SAST developing support is the addition of some new diagnostic rules. They implement code compliance checks for various standards. A check for sensitive data in source code is among the latest innovations in the C# analyzer. The storage of such data in code is contrary to #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.

The OWASP Top Ten list includes risks related to insecure storage of sensitive data in code. The Common Weakness Enumeration (CWE) also contains 2 items related to this question: CWE-798 and CWE-259. Even so, one might wonder – why is it dangerous?

For open source projects, the answer is obvious. Everyone can view and use a password or some other data in code. That's an easy task for an attacker. They just delve into the repository to get some data.

The situation is slightly better if the application is available only in a compiled form. This can even create the illusion of security. After all, the source code is seemingly unavailable, which means that the data in it is also unavailable. Alas, that's not necessarily the case.

In practice, it's not uncommon for a system to contain hardcoded data that can be used to obtain various rights. As a rule, users can't even change this data. Attackers may use different methods to obtain them. In some cases, the system interface can generally contain logins, passwords, etc. In other cases, you'll need to examine various files, code decompilation, brute force, and so on. Anyway, malicious hackers are good at finding ways to uncover hardcoded secrets.

Quite often, the following problem comes up: an attacker, having received logins and/or passwords stored in the system sources, will be able to use them to connect to other systems of this type. For example, they can install the system locally. After scanning and obtaining users' logins and passwords for this local version, the attacker will be able to connect to other versions using the same data.

In addition, the fact that all programmers have access to the source code data poses a danger. At the same time, a user who has installed a particular system for their own needs won't be happy to know that a software company can get full control over the used system at any time. Therefore, the company will get various secret data of the users themselves, etc. The vulnerabilities found in the Common Vulnerabilities and Exposures (CVE) list show that such errors are found sooner or later. And at the same time, they are surely put on display.

As mentioned earlier, vulnerabilities related to hardcoded confidential data are pretty common. There are many examples among CVEs. CVE-2012-5862 is one of them. This record describes the system, containing the login.php file. There is the following code in this file:

$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')";
  ....
}

In this code, there's a place where the variable containing the password, passed by the user, is directly compared with a string literal. Obviously, an attacker will have no trouble using this information. It will help the intruder to perform various operations unavailable to an ordinary user.

The PVS-Studio C# analyzer finds the storage of sensitive data using the V5601 diagnostic rule. Take a look at the C# code sample that resembles the example above:

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

After reviewing this code, PVS-Studio will emit the following warning:

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

Thus, the static analyzer will help you to find a similar error in the code at a moment's notice. Then, you just need to resolve the error. Therefore, the security level of your project will increase.

Note. It is worth mentioning that V5601 belongs to the OWASP diagnostics group. This group will appear in PVS-Studio with the release of 7.12 version. By default, OWASP rules will be disabled. However, you can easily change this, for example, with the help of the Visual Studio plugin or Rider. You can also directly edit the settings file.

This example is just one of many. Hardcoded data can lead to all sorts of problems. During my research, I found many other CVE records, related to highly protected confidential data. Here are the links to some of them:

  • CVE-2004-1920 – router with a "super" username and password;
  • CVE-2004-2556 – access point with a "super" username (again) and not a super password "5777364";
  • CVE-2004-2557 – which is the result of the CVE-2004-2556 "fix"(at least the login is no longer "super");
  • CVE-2012-1288 – hardcoded credentials for an administrative account;
  • CVE-2012-2949 – a hardcoded password for an Android app
  • and so on.

One more reason to run the analysis regularly

0805_Hardcoded_Passwords/image2-73a38447fae9ca4ba3ad7bd7dbfb5626.png

The conventional wisdom is that a static analyzer may be used once every few months, just before the release (or even once a year). That's a rather strange choice. Fixing errors that have been accumulated over a lot of time is much more difficult than fixing the code that you just wrote before committing. All the more, thanks to incremental analysis, the check will run much faster.

In many cases, the analysis of commits and pull requests would be a convenient option. This will increase the reliability of an application under development even more. After all, the code containing errors will not get into the main branch of the repository. This will help the developer who suddenly forgot to run the analysis. To find out more about the configuration of the pull requests check, read the documentation (see section Deploying the analyzer in cloud Continuous Integration services).

A new opportunity to search for sensitive data in code again confirms regular analysis usage. It's handy both on programmers' computers and within CI. Even if a programmer puts some passwords in the source code, the analyzer will warn them about it. If necessary, a developer can read the V5601 diagnostic documentation to see where the danger lies.

If you rarely run the analysis, hardcoded data turns out to be stored in the source code for a long time. It's pretty bad for an open-source project. By the time the analyzer finds a problem, data will no longer be confidential. However, other projects are not secured too. What if a user gets, let's say, a beta version of the app? You may receive such version between releases. If you don't check source codes regularly, a static analyzer won't check code in such a version. All the data hidden in the source code happens to be publicly available.

Conclusion

PVS-Studio is constantly evolving. We add new diagnostic rules, refine some existing mechanisms along with some new development opportunities. It's worth noting that, in a large part, an ongoing dialogue with users makes the analyzer better. The V5601 diagnostic rule is just one of the elements which help the analyzer to improve code security.

How about you try PVS-Studio in your projects? You can get it for free. Just follow the link and fill out a simple form. Well, that is that. Thank you for your attention. See you soon :).

Popular related articles
Trojan Source: Invisible Vulnerabilities

Date: Apr 15 2022

Author: Guest

We present a new type of attack in which source code is maliciously encoded so that it appears different to a compiler and to the human eye. This attack exploits subtleties in text-encoding standards…
Why does my app send network requests when I open an SVG file?

Date: Feb 18 2022

Author: Sergey Vasiliev

You decided to make an app that works with SVG. Encouraged by the enthusiasm, you collected libraries and successfully made the application. But suddenly you find that the app is sending strange netw…
Vulnerabilities due to XML files processing: XXE in C# applications in theory and in practice

Date: Feb 11 2022

Author: Sergey Vasiliev

How can simple XML files processing turn into a security weakness? How can a blog deployed on your machine cause a data leak? Today we'll find answers to these questions, learn what XXE is and how it…
OWASP Top Ten and Software Composition Analysis (SCA)

Date: Oct 22 2021

Author: Nikita Lipilin

The OWASP Top Ten 2017 category A9 (which became A6 in OWASP Top Ten 2021) is dedicated to using components with known vulnerabilities. To cover this category in PVS-Studio, developers have to turn t…
How Visual Studio 2022 ate up 100 GB of memory and what XML bombs had to do with it

Date: Sep 07 2021

Author: Sergey Vasiliev

In April 2021 Microsoft announced a new version of its IDE – Visual Studio 2022 – while also announcing that the IDE would be 64-bit. We've been waiting for this for so long – no more 4 GB memory lim…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept