Shared Passwords

Discover device local accounts that share a common password and find local accounts that have passwords that are trivially discoverable by an attacker.

Scenario

Local machine accounts that share passwords with other accounts are a security vulnerability. Additionally, local machine accounts that have passwords whose hash can be determined by trivially scanning ‘rainbow tables’ are also a security vulnerability.

Product Pack Notes

Instructions

Questions
  • Which device local accounts share a common password?
  • Which local accounts have passwords that are trivially discoverable by an attacker?
Notes

Question 1
The first question returns a set of cryptographic tokens which, for any password, will be identical. To ensure that good cryptographic practices have been followed, the technical process by which these tokens are created is described below. It is intended that this information be disclosed to customers should they request technical information about the process, so that they can audit it themselves for ‘best practice’.

On the endpoint, a custom executable is used to answer both questions. For question 1 the executable is called with the command line parameter

-n

where is a string supplied by the PowerShell script that launches the executable. In turn, the nonce is obtained from Tachyon via the %environment:now% variable, which is set to the time of day (to the second) when the question is invoked.

All endpoints receive the same value, as this time is server-derived. Each time the question is asked, the time moves forward

The same time is re-used if ‘re-run’ is selected from the Tachyon UI. While this is not ideal, we’ll probably add functionality to Tachyon to provide a unique per-question GUID or something that WILL always change. This will absolutely maximise security.

For each local account, the executable retrieves the local account name and (internally) the NTLM hash of the password. It then computes a password token as follows:-

  • The NTLM hash is hashed, using the SHA512 hash algorithm. This process is repeated one million times.
  • The final hash is then extended by appending the nonce value. It is then hashed, by SHA512, one final time
  • The most significant 8 bytes of the 32 byte hash are then returned as the password token.

Each time the question is re-run, the nonce value changes and hence the exact token values for a given NTLM hash are not constant. However, for two matching passwords the token values will also match.

This design ensures that, if someone were to obtain the Tachyon database by some means, the token values cannot be reverse engineered to obtain an NTLM hash.

The reason for hashing one million times is to protect against a second attack vector. Suppose that the password hash was associated with a weak password, which is trivially guessable. Then an attacker (who has compromised the Tachyon database) and who has computed a rainbow table of hashes might consider computing a rainbow table of password tokens. Although these tokens are only good for one question (since the nonce changes each time), the algorithm is documented here and could be used.

However, because of the high iteration count it takes approximately 1 second per NTLM hash to compute a token. At the endpoint this is not a significant concern as the number of local accounts is small. However an attacker would have to compute tens of millions of tokens to convert their rainbow table. This would take a long time, and at the end of it, the only attackable hash would be one that represented a weak password in any case.

Question 2
The second question is intended to address weak passwords.

You will probably need to increase the maximum download size supported by IIS to upload this instruction. To do this, follow the instructions at the link below

Changing content length restriction in IIS for large Product Pack payloads

The instruction contains a ZIP file which contains tokens associated with weak passwords. You can modify or replace this file if desired. Instructions for doing so can be found later on this page

When this question is run, the same custom executable is invoked at the endpoint but this time with the parameters

-f

where is the uncompressed token list. The wrapper PowerShell script uncompresses the file, which is approximately 250M in size.

The custom executable compares (internally) the NTLM hash of each local account with the token set and returns 1 if the hash matches any token otherwise 0.

When creating the token file, the tokens are computed as follows:-

  • The plaintext password NTLM hash is computed
  • The NTLM hash is then hashed again using the SHA512 hashing algorithm
  • The first 8 bytes of the 32 byte SHA512 hash are then used as the token

 

It is therefore not practical for an attacker to recover the NTLM hash given a token.

If the token list is derived from a publicly known list of plaintext passwords, then of course it is possible to determine what those passwords are by creating a token rainbow table.

Since the token table needs to be efficiently computed and since the plaintext passwords are in the public domain, there is no point in computing the compare tokens using a high hash iteration count.

In any case, since the attacker already had the plaintext passwords, this is a rather pointless attack; all they have done is confirm which passwords are on the token list.

However, suppose a customer adds some additional passwords to the checklist. An attacker who obtains the token checklist cannot reverse engineer the newly-added plaintext passwords, nor their NTLM hash from the tokens. Recall that the tokens represent only 8 bytes from a 32 byte hash, so most of the information has been discarded.

The token size of 8 bytes has been determined to be optimal because (a) it represents a 64 bit integer type which can be very efficiently compared and (b) an 8 byte partial hash produces a Birthday Paradox collision rate of approximately 1 in 1 million for N = 6 million.

A 4 byte partial hash is too small; the collision rate is 1 in 2 at N = 77,000

We expect that the number of accounts N for a large site might be, say, 5 per device X 500K devices = 2.5 million so we can see that ‘false positives’ are unlikely for an 8 byte partial hash. In any event a false positive ‘fails safe’ in that we report a password match when one does not exist, rather than the converse.

See:-

https://preshing.com/20110504/hash-collision-probabilities/

Customising the password checklist

The original list was created using SQL Server. It is extremely simple to produce a custom password checklist

As an example, suppose we retrieve the Rockyou password list from

https://wiki.skullsecurity.org/Passwords

Note: 1E does not endorse or affiliate with any external source of password information. Since this information is freely available both to ‘white hat’ and ‘black hat’ security protagonists, it must be considered as a resource both for offence and defence.

1. Use the 7z utility to decompress the file

(you can download a command line copy of the 7z utility or use the 7z.exe and 7z.dll files which together provide this functionality – they are in the product pack share location)

7z x rockyou.txt.bz2
2. Create a database in SQL Server using the Sql Server Management Studio tool
3. Create a table
create table passwordlist
 (
 password nvarchar(1000)
 )
4. Now bulk insert the password list. Note that in this example the decompressed file was at e:\downloads\rockyou.txt

The RockYou password list is delimited with line feeds after each line. If the file is delimited with the standard Windows carriage return + linefeed delimiter you can omit the rowterminator option

bulk insert passwordlist from 'e:\downloads\rockyou.txt' with (rowterminator='0x0a')
5. Ensure no empty rows are in the table
delete from passwordlist where password is null
6. Add a column for the token
alter table passwordlist add token binary(8) null
7. Compute the tokens
update passwordlist set token=convert(binary(8),hashbytes('SHA2_512',hashbytes('md4',convert(nvarchar(1000),password))))
8. Now from a command window, use the following command to create an uncompressed token file

Substitute with the name of the database you created and with the server name (and SQL Server instance name if not the default instance)

bcp "select token from passwordlist order by token" queryout tokens.txt -d  -T -S  -c  >NUL:
9. Compress the tokens.txt file by sending it to a zipped archive from Windows file explorer
10. Replace the resource (tokens.zip) in the instruction using TIMS.

Adding additional entries to an existing password list

You can then add more plaintext passwords to the list by:-

  1. Creating a text file (from whatever source you prefer)
  2. Creating a new table e.g passwordlist1, as in step 3.
  3. bulk inserting your list into the new table
  4. Inserting the rows into your existing passwordlist table as follows
INSERT passwordlist(password, token) SELECT password,
convert(binary(8),hashbytes('SHA2_512',hashbytes('md4',convert(nvarchar(1000),password)))) token from passwordlist1

Then repeat steps 8 onward to create a new master check file and upload it to Tachyon.

Be sure to keep your passwordlist table secure since it contains your plaintext passwords. However of course these are ‘weak’ passwords and presumably you will be using this list to ensure no endpoint local account uses any of them, so this is not a significant security issue.

You can delete the plaintext passwords from the passwordlist table if you wish since once the tokens are computed you no longer require the information. To do this

UPDATE passwordlist set password = NULL

also drop any new passwordlist tables that you created when staging your new checklists, if you don’t want to keep a record of the plaintext passwords you added.

An attacker who gains access to the check token list cannot determine the plaintext passwords that you added. At best, they can only determine whether a pre-existing public list of plaintext passwords corresponds to any tokens in the checklist. Since they already had the plaintext passwords this is not a vulnerability; all they know is that you’re checking these.

Cached Domain Accounts

You may recall that a previous credentials product pack was able to report on cached domain accounts.

It is possible to retrieve the hash of a cached domain account. However this product pack does not address domain accounts because this hash is not computed in the same way as an NTLM hash for a local account.

Whereas the NTLM hash for a plaintext password is simply the MD4 hash of the password, and thus is trivially computable e.g in SQL Server

select hashbytes('md4',N'Passw0rd')

shared-passwords

The hash of a domain account is stored as an “MS Cachev2” hash

The algorithm takes TWO arguments, not one as for an NTLM hash. They are the account name (without the domain) and the plaintext password

This means that the MS Cachev2 hashes for two different domain accounts with the same password will not be the same.

The MS Cachev2 algorithm is also computationally expensive so you cannot compute them very quickly (whereas you can compute millions of NTLM hashes per second)

For a rainbow table of 14 million common passwords, it could take an hour or so per account to compute a rainbow table, which would be specific to that account

Note that the password tokens used in Q1 are much more expensive to compute than even the MS Cachev2 algorithm and it would take around 6 months approximately to compute the tokens for one run of the question. Assuming an attacker has somehow compromised your Tachyon database, this still only reveals weak publicly-known passwords, in any case, which you will have eliminated following the use of Q2.

Note: The endpoint does not retain the password tokens after they are computed.

Note that the account name does NOT contain the domain, so common domain accounts such as ‘administrator’ are very vulnerable to attack as a rainbow table is effective for any organisation with a domain account of that name.

Because the MS Cachev2 hash is account-specific, answering the above PP questions for a domain account would require further work.

It would not be possible to implement question 1 for domain accounts, since at the endpoint the hashes will differ.

Question 2 can be implemented but it requires that a rainbow table be computed for each account that you wish to check. This could be time-consuming. The PP would also have to then download the appropriate rainbow table(s) based on the cached domain accounts that were found on the endpoint.

Alternative password lists

Some comprehensive password lists can also be downloaded from

https://mega.nz/#F!xaghyJQb!3EDbm5Mcz2pD0HVqyE8rJQ

Use caution when accessing material from external file sharing sites. 1E does not endorse any such sites, and we recommend that you scan any downloaded material carefully. As these lists ought to be plain text password lists, they should be simple to safely verify.

Reviews

You must log in to submit a review.Click here to login.

Details

Author

1E Product Pack Creator

Published

Downloads

20

Categories

Compatible Versions