SAM Hive decryption problems - encryption

I've been doing a RAM Volatility task in class and I have been asked to decrypt the hashes after the Third colon however when I go to copy and paste these hashes into www.crackstation.net or anywhere else they are unable to be decrypted and I was just wondering if I am doing anything wrong
hashes

Related

Ansible - properly encrypting/decrypting and using file content (not YAML)

So I created encrypted key using ansible-vault create my.key.
Then I use it as var:
my_key: "{{ lookup('file','{{ inventory_dir }}/group_vars/my.key') }}"
And then when running my playbook, like this:
- name: Create My Private Key
ansible.builtin.copy:
content: "{{ secrets.my_key }}"
dest: "{{ secrets_key }}"
no_log: true
It does properly create key on remote host and it is then unencrypted. But I'm thinking if this is the right way to do it? Does it unencrypt at the right time and I am not exposing sensitive data where it should not be?
I thought encrypted variables must also have !vault keyword specified. But if I do this for my my_key, I get this error:
fatal: [v14-test]: FAILED! => {"msg": "input is not vault encrypted data. "}
So this got me worried, that file is unencrypted at the wrong time or maybe message is misleading or something.
Is this the right way to do it? Or I should do it differently?
Firstly, a definitive answer as to whether this approach is appropriate, is directly linked to what you want to achieve from encryption. Therefore all the answers here can do is talk about how Vault works and then you can decide if it is right for your requirements.
Fundamentally what you are doing is a 'correct' usage of Ansible Vault, although I have not previously seen it used in quite this workflow (typically I have seen create used for encrypting YAML files of vars).
Using your method, your secret is turned into ciphertext and stored in my.key (which can be confirmed by using basic text tools such as cat, less or more). You will see the first line of the file, contains a bunch of metadata that allows Ansible to understand the file contents and decrypt on demand.
At runtime, Ansible will then use the password/key for the encrypted file (accessed through a number of methods) to decrypt the file contents into plain text and then store it in the variable my_key for use during the play.
A non-exhaustive list of things to consider when determining if Ansible Vault is the right approach for you:
Ansible Vault encryption is purely designed to protect secrets at rest (i.e. when they are stored on your hard disk)
At run time, the secrets are converted into plain text and treated like any other variable/string data, however the file on disk still contains ciphertext so the plaintext is only accessible within the running Ansible process (i.e. on a multi-user system, at no point can anybody view the plaintext simply by looking inside the my.key file. However, depending on their level of access, skills and what your Ansible tasks are doing, they may be able to access the plaintext from the running process.)
Given inside the process the data is just plain text, it is vulnerable to leakage (for example by writing the contents out into a log file - checkout the Ansible no_log option)
At run time, Ansible needs some way to access the key necessary to decrypt the ciphertext. It provides a variety of methods, including prompting the user, accessing it from a file stored on disk, accessing it from an Env var, using scripts/integrations to pull it from another secrets mgmt tool. Careful thought needs to be given about which option is chosen, relative to what you are looking to achieve from the encryption (e.g. if your goal is to protect your data in the event that your laptop gets stolen, then storing the key in a file on the same system, renders the whole operation pointless). Quite often, with more sophisticated methods, you can still end up in a 'chicken and egg' situation, once more relative to what your goal from using encryption is
I might be talking complete cobblers or be a nefarious individual trying to sow disinformation, so read the docs thoroughly if the value of the secrets if significant to you :)
Unfortunately there is no getting away from generally good security is harder to achieve than the illusion of good security :|

BouncyCastle updated pgp key now getting checksum mismatch error

I have a utility that is using the BouncyCastle.Crypto dll (version 1.7.4, runtime version 1.1.4), in order to decrypt a file that is given to it by another system.
I just updated the pgp key (and provided the encryptor with the new public key). The new key uses 4096 bit RSA encryption and has a 24 character password, which are the only differences I can think of between the new key and the old key. The old key used I believe 2048 bit encryption with a 7 character password.
When I attempt to decrypt a file the process is now failing when calling the PgpSecretKey.ExtractPrivateKey(char[] passPhrase) function, provided by BouncyCastle. The error is "Checksum mismatch at 0 of 20."
The weird part is that the first time I tested it worked fine, then with no changes it began failing. I have tried with multiple encrypted files.
Since it's such an old version of BouncyCastle and this particular permutation of the ExtractPrivateKey function is no longer in use I am finding it difficult to locate relevant information. Any thoughts are appreciated.
I got that error once "Checksum mismatch at 0 of 20." . My issue was due to a wrong pass phrase. Hope this should help someone.

Is brute force the only reasonable approach to detecting encryption?

An old version of an application has some passwords stored in the clear in its database. I have written an updated version that encrypts the passwords when new entries are made, but I don't have direct access to the database to manually encrypt the entries that already exist. When the update goes live, it will try to decrypt the plaintext passwords, and crash.
Short of doing something drastic like deleting all the existing data, the only other approach I can think of is this (wrapper pseudocode called when the password data is used.):
# data refers to the password data, either encrypted or plain
if data length < AES.block_size:
# (Shorter than initialization vector, definitely not encrypted.)
open database and replace password entry with encrypt(data)
login(username, data)
else:
try: # try plaintext first
login(username, data)
except AuthenticationError:
login(username, decrypt(data))
else: #plain text worked, encrypt data for future use.
open database and replace password entry with encrypt(data)
It seems a shame to keep this code around to solve a problem that goes away after it runs once. Is there any other approach that might work to ensure the passwords are encrypted and only decrypt the ones that need it?
In this scenario I do one of the following, depending on the client and the system involved:
Set up the encrypted password code, delete all existing passwords, and make everyone enter a new password. I prefer this because the passwords were plain and over time may have been seen or shared.
Run a one-time script to encrypt every password in the system. This way there is never a mix.
Have newer encrypted passwords prefixed with the encryption method, e.g. "SHA1:". You run the risk of someone having that same text as the start of their password, but it is unlikely.

How to Script Automated Root Password Changes?

Currently our process consists of logging into each *nix server and manually changing the password for each. My question is, what is a good way to automate this? I'm thinking of possibly a couple different ways to do this and would like input from others on what they recommend, use, etc.
One way I was thinking is a text file with a list of servers that need the password change and a script that prompts the user for the new password, stores it temporarily in the script and then remote connects into each server and runs the commands. Having a check to make sure the server is reachable or a timeout on the remote connection would be a good idea. Then have output to the console so the person running the script can see what servers were successful and which ones were not.
I was trying to think of another fully automated solution, but couldn't think of a good way to securely store the new password. Plus it is not a huge deal to me to have some user interaction and have to manually start the script as we only would need to do this 6 times a year.
Any thoughts, help, ideas would be greatly appeciated.
openssl passwd -1 $rootpw
Where $rootpw holds the string that will be your root password.
This will output a crypted string that you can just put in the file or whatever. I use this on a script that sets up virtual server instances that are provisioned from a database. I compute this hash before sending it over the network so the script that sets up the server can just use this hash instead of having to send it plain text.
To answer your question, each server would compute the hash slightly differently and result in a different hash, but all of those hashes would equate to the same password. You could use any one of these hashes and they would be functionally equivalent when used on any server, even though the actual content of the hash is different.
For example, I hashed foobar and these are the results:
rootpw=foobar
openssl passwd -1 $rootpw
$1$6pXamKGD$TKQqON1prArop7DpLOyAk1
openssl passwd -1 $rootpw
$1$4A4Mn16f$P7ap2AqNMRK8m72bG/Bve0
openssl passwd -1 $rootpw
$1$DyhsWEMX$i2wH6JpAqoHNFZ0YOBVHj/
openssl passwd -1 $rootpw
$1$m27FIj5e$LZPxVniAeUoZcuUoNHK8c/
openssl passwd -1 $rootpw
$1$qdX0NKm1$45rzxUj..LCJwWB/.fwGH0
Each of those hashes are different even when computed on the same machine but any of them can be used to equate to the password 'foobar' on any machine.
So just open /etc/shadow and paste that in there where you find the line:
root:$1$qdX0NKm1$45rzxUj..LCJwWB/.fwGH0:14415:0:99999:7:::
In my script I explode it at the :'s and update element [1] then concatenate the array back to a string and replace the string in the file. You can do it differently if you want, especially if you know the old value (which you can get by exploding it into an array).
I know this question is a few months old so you probably figured it out, but I'm putting this out there for any future googler's coming along and finding this.
You should compute whatever hash are your servers computing on a password and send passwords in this secured, hashed form, ready to put into /etc/shadow.
I do not know however how to do that in practice.

encryption/decryption with multiple keys

Is it possible to encrypt data, such that it can be decrypted with several different keys?
Example:
I've encrypted data with key1, but I want to be able to decrypt with keys 2, 3, and 4.
Is this possible?
GnuPG does multi-key encryption in standard.
The following command will encrypt doc.txt using the public key for Alice and the public key for Bob. Alice can decrypt using her private key. Bob can also decrypt using his private key.
gpg --encrypt --recipient alice#example.com \
--recipient bob#example.com doc.txt
This feature is detailed in the user guide section entitled "Encrypting and decrypting documents"
Yes it's possible
Yes encryption for multiple recipients is possible. Also it seems logical when you think that you might want to be able to read what you've sent to someone and to do so you need to be in the recipients list.
Command line
Here is how to do it through gpg command line (as described in David Segonds' answer):
gpg --encrypt \
--recipient alice#example.com \
--recipient bob#example.com \
clear-message.txt
GUI client
Your GUI must provide a way to encrypt for several people
Mechanism
There is a question on Information Security, GPG File size with multiple recipients?, that explain the encryption mechanism:
GPG encrypts the file once with a symmetric key, then places a header
identifying the target keypair and an encrypted version of the
symmetric key.
[...] When encrypted to multiple recipients, this
header is placed multiple times providing a uniquely encrypted version
of the same symmetric key for each recipient.
GnuPG and PGP clients in general usually encrypt the actual data with a symmetric key called a "session key". The session key is then encrypted with each "recipient key" (i.e. the ones you specify with -r/--recipient). This is sometimes referred to as a hybrid cipher. Right now, I believe GnuPG by default uses an 256 bit session keys and AES to encrypt the plaintext data to that AES-256 session key, and your recipient keys are your RSA/DSA/ECDSA/etc. assymetric key in this case.
One reason for doing it this way is that symmetric cryptographic algorithms like AES are generally a lot faster than asymmetric ones like RSA. GnuPG thus only has to encrypt ~256 bits (the session key) with RSA, and can use AES to encrypt the data (as large as you want it to be!) with that session key. Intel machines even have a built in instruction, AES-NI, to do some steps of the algorithm in hardware, which makes GnuPG extra snappy at encrypting/decrypting data.
Another reason for doing it this way is that it allows PGP-encrypted documents to be encrypted to multiple parties without having to double the size of the document. Notice that when you specify multiple recipients for an encrypted document (e.g. gpg -ea -r Alice -r Bob -o ciphertext.asc), the encrypted document that gets stored (ciphertext.asc) is not 2x as large as if you had just encrypted it to Alice.
See also the --show-session-key parameter in the gpg man page to be able to decrypt just the session key, for example to allow a third party to decrypt a document that is encrypted to you without having to transfer to them your private key or the plaintext data.
Yes, it's possible. Google "multiparty encryption" for a start.
AFAIK, there are no drop 'em in and use 'em packages for it though.
-- MarkusQ
P.S. For a sketch of how it could be done, consider this. The encrypted message consists of:
the payload, encrypted with a one-time pad
the one time pad, encrypted with key1
the one time pad, encrypted with key2
...
the one time pad, encrypted with keyN
The recipient who hold key i just decrypts their copy of the pad with their key, and then decrypts the payload.
However, this is just a proof that it could be done and would suck as an actual implementation. If at all possible, you should avoid rolling your own encryption. If you don't understand why, you should definitely avoid rolling your own encryption.
-----Edit ------------
If I'm wrong and the Gnu tools do that, use them. But I can't seem to find any information on how to do it.
Multiple (more than two) key RSA is maybe like this - well i'm not a mathematician, so this algorithm is not necessarily secure, i just want to give an idea with it.
m=p*q*r; p,q,r are big prime numbers
fi(m)=(p-1)(q-1)(r-1)
d==(e1*e2*e3*...*ei)^(-1) (mod fi(m)); e1...ei are arbitrary numbers, d is calculated to fulfill the equation
y1==x^e1 (mod m)
y2==y1^e2 (mod m)
y3==y2^e3 (mod m)
...
x==yi^d (mod m)
This algorithm could be used for example to increase the speed of The Onion Router.

Resources