Scripts and Passwords

As the first topic for the new iteration of the technical blog, I chose passwords and their use in scripts and programs. This is partly an extension of a topic from Cyberstarter, where a password was used in one of the scripts, but the original script was simplified for presentation purposes. Now, I will show the original solution along with an explanation. I want to focus on this topic because I have seen many passwords stored directly in source codes, which is never a good idea. In this tutorial, I focus on Windows solutions, but they can easily be adapted to Linux with minor changes. If there is interest, I can write another tutorial on that.

Before diving into the details, let's pause for a moment to discuss the problem itself. Why shouldn't passwords (or other authentication components) be stored in code? It seems obvious, but I have heard arguments that it's not a big deal because only the administrator has access to the script. The question is, does only the administrator have access to the backup or the repository where the script is stored? And what if we accidentally send the script to someone, forgetting that it contains sensitive data? I have seen solutions that try to hide the password in some way. Such security through obscurity is not the best approach because even if we use our own complicated cryptography (which is never a good idea), the decryption solution must also be hidden in the code. A better solution is to store the password somewhere within the system where the script is executed. Sometimes it's an additional file, sometimes an environment variable, and sometimes, in my opinion the best solution, a software keychain that provides limited access to the necessary data. Such a solution is part of the Windows operating system, probably in all versions, and is called Credential Manager. Since we have this solution available, why not use it?

Preparations

Before we start querying the system for the password, it's good to prepare. For the purposes of this tutorial, let's imagine a resource called secretResource. This could be a database, some REST API, or anything else that requires password authentication. On such a resource, it's good to create a special user with limited access, so that they can only perform what we require in the script. This is quite important because things can always go wrong. For example, we might mess up the script and allow additional commands to be injected. It's also good to create different users for different solutions. A universal service user is not a good idea. If our solution is temporary, it's good to set an expiration date for this account or even limit the login capabilities to the time when the script is executed. If this is ready, we add the credentials to the Credential Manager.

The password can also be set using the built-in console command:

cmdkey /generic:tajnyZasob /user:specuser /pass:dupa.8

In both cases, the result should look something like this:

It's important to note that the password will only be available to the account on which it was added. However, the script may not always be run by the same user. Therefore, the password should ultimately be added to the Credential Manager of the user who will execute the script. There is one special case, but I'll discuss that later. Now, it's time to retrieve the password at the script level.

Scripts

powershel

We will need the CredentialManager module.

Install-Module -Name TUN.CredentialManager

With the module installed, retrieving the password will no longer be a problem.

getcreds.ps1:

$po = Get-StoredCredential -target 'tajnyZasob' -AsCredentialObject
echo $po.Password

The result of the script will be:

python

Similar to PowerShell, here we also need to install an additional module, this time it's keyring.

pip install keyring

Keyring will also work on Linux and macOS, but there you will need additional software to act as the keychain. This could be, for example, KWallet for KDE, but as I mentioned at the beginning, that's a completely different story.

getcreds.py:

import keyring
password = keyring.get_password("tajnyZasob", "specuser")
print(password)

The result of this script will be the same as in the case of PowerShell.

Node.js

Node.js may not be entirely about administrative scripts, but I have also encountered situations where Node.js or Electron.js applications needed passwords for some resources. For example, a desktop application built in Electron needs to query some service using REST, but the service requires authentication first. Using the Credential Manager creates a situation where only the user with the previously added credentials can correctly use the application. The module we need in this case is Keytar

keytar = require 'keytar'
const secret = keytar.getPassword('tajnyZasob', 'specuser');
secret.then((result) => {
    console.log("result: "+ result);
});

System Account

Finally, the special case. Scripts that require special access to system resources are not run as a normal user to whom we can easily add credentials. For example, let's look at the Windows Task Scheduler.

The option "Run with highest privileges" selected here causes the script to be run under the system account, and this account does not have special credentials added. Here, the PSTools package, specifically the psexec command, will come to our aid. This command is usually used to execute commands on remote systems, but in this case, we will execute the command locally but under the system account.

psexec -S cmdkey /generic:tajnyZasob /user:specuser /pass:dupa.8

psexec -S must be run as administrator

This ensures that the system account has access to the appropriate credentials to execute the script.

Conclusion

Remember that this solution, like any other, has its drawbacks. There are many attack methods, and gaining access to the system with the permissions of a given user gives us access to their credentials. What this solution protects against is primarily the accidental disclosure of credentials in the source code. This solution ensures that obtaining the script or application does not guarantee full access to the resources. I am not completely dismissing other solutions. In the presentation at cyberstarter the database password was passed as a parameter to the Nagios command. Sometimes that's enough. In Linux, keys to various APIs are often stored in the environment variables of the user running the script. That can also work. There are many solutions, and their level of security varies, but storing passwords, even obfuscated, in the source code is not a solution. With this thought, I leave you for the coming new year. Stay safe.

Until next time!