Introduction – We’re not very good at this!
Local Admin Passwords are arguably one of the most important pieces of information on a computer system. The only thing as an attacker that you would desire more is Domain Administrator credentials. However these are usually much harder to come by. But with them you can take control of a single computer and leverage it to nearly anything you want. So if it sounds like something you’d want to keep good control of, you’d be right.
So to most outside the industry it may come as something of a surprise to find that in many businesses the Local Admin password is shared across all the machines in a company. Why? Many companies rely on Scripts or Automated tools to build and maintain their machines as they don’t have the time or patience to manually build each machine. If you automate on this scale, its highly likely that you’ll need an administrator account with a password you know so everything can be updated. Many of us are guilty of this. The need to have everything working usually trumps the need for security.
Clearly, this isn’t great, and it does mean that if an attacker can get one administrator password, they will potentially have administrator access to all the devices in the business. From a security standpoint, that’s not great.
Working on a better solution
So what can we do? Clearly we need a solution. So during my time commuting to and from work, I developed something of my own.
Now clearly, there will be many other methods available to do this task. However, many of these are primarily designed for server installations and usually require purchasing expensive licences, deploying additional servers or virtual machines. Also these solutions usually have features outside of password management which can have unwanted interactions with other existing systems.
Instead I wanted to produce something that would be both easy to deploy and use in a practical environment that can be used in procedures that already exist.
I used the following criteria when working out a solution based on my previous experience with these deployments:
- It needs to regenerate different passwords for each computer.
- The generated passwords should be the same if the program is provided with the same information. So someone in support can generate a password and login.
- It needs to run in a batch file or Command Prompt.
- Can be used on an estate of any size.
- The password generation shouldn’t add too much extra time to support staff.
With those requirements in mind, I turned to Python in order to create something that would meet those following criteria. From that came “pwgen” which can be found below with the source code on GitHub.
https://github.com/4chtung/pwgen
It’s still in development but in its current incarnation, pwgen is a python file currently running in an exe created by Pyinstaller. (Hence the large size for a simple application as it has to have the python runtime packed within the exe as well.)
Pwgen takes one or two inputs and runs them through a SHA hashing algorithm and takes the first ten characters in order to create the administrator password. Because we’re using a hashing algorithm it should mean that provided the inputs are the same we should always get the same password. In its current state, it’s worth bearing in mind that pwgen doesn’t write special characters or anything else that may fall foul of password complexity rules. These will be added as optional arguments in further versions.
Usage
Firstly let’s look at how pwgen works. Here is an example of the standard usage of pwgen:
pwgen -i ProCheckUp -s Security
The -i argument is required as it’s the input that pwgen will hash. This can even be a system variable if required. (%computername% is usually an excellent idea as that is something that you’ll always know)
The -s argument isn’t required but it used to add a salt to the Hash to make it a little more difficult to crack. This is probably a good place for your current administrative password.
Running this command will give you the following string:
a3c847cae0
With this, you’ll be able to use to change the administrator password. Or use to login to a system where the password has already been generated.
Using pwgen In the Real World
So it’s all well and good having a possible solution but you’re probably going to want to know how to apply it to the real world therefore, I’ll use an example based on my own experience.
As a better example we’ll implement pwgen for a fictional retailer who currently uses the same administrator password for all the tills in the business. They also use Batch files to automate some of the build process after the till has been imaged. For this example, their current administrator password is “Passport”. As it can be used both as a Command Line tool as well as in Batch Scripts Service Desk personnel will be able to use the pwgen executable file so they can regenerate passwords and connect to tills if required.
Ideally we’d introduce pwgen as the last stage of the build process. That way we don’t need to change too much of the build process but the administrator password will be changed at the end. So we’d include the following batch script at the end of the build script. The company then gives each till its own computer name for identification which we’ll use to generate the password as we’ll always know the computer name in future. In this example we’ll be building “Till0031”
The following code is an example of a code block that could be added to the end of a batch script:
::pwgen Code Block for Build
::
:: Change the working directory to the PWGEN folder.
cd C:\Temp\buildfiles
:: Generate the new administrator password and then change the administrator password to the new value.
for /f %%i in ('pwgen -i %computername% -s Passport') do net user Administrator %%i
:: Delete the pwgen file so an attacker cannot find it!
DEL /F pwgen.exe
:: Rest of the code goes here
TIMEOUT 10
At this point, the administrator password has now been changed. Now let’s imagine that the service desk has been called from the shopfloor. The till we built earlier isn’t working correctly and needs some software installed which requires admin access. The service desk technician can’t use “Passport” as the password as we have run pwgen. However, if the service desk knows the till is ‘Till0031’ and also has a copy of pwgen on their computer (and its added to the PATH or System32, they can run the following command in their command prompt:
C:\Users\venmo\Desktop\pwgen>pwgen -i Till0031 -s Passport
8870dea76d
This will generate the admin password for the technician and they’ll be able to use it to login.
Important Notes to Remember
- Once the pwgen’s been used to generate a password, make sure its removed from the device as you don’t want attackers stumbling across it.
- Always use a Salt. While the program doesn’t require one currently make sure one is used. That way, even if an attacker ascertains you’re using pwgen your generated passwords aren’t immediately vulnerable.
- Only use pwgen for anything automatically built. Pwgen was built with automated scripts in mind. (Such as those found in EPOS Systems or massed PC deployments.)
- Don’t use pwgen for Domain credentials. Pwgen was designed to generate local administrator account passwords. If you also use it for Domain credentials you’re exposing yourself to unnecessary risk.
What Next?
Clearly pwgen doesn’t have much by way of features particularly compared to other commercial offerings. However now the proof of concept is put together, I have plans to hopefully diversify the application. Including but not limited to creating a GUI which should make it easier for support analysts to generate passwords as well as writing the application in C++ rather than using Python which should shrink the size of the application considerably.
I’m also planning on adding extra arguments that will allow for password complexity rules, set the length of password created and allow for further control of generation.
Categories