SHA3 Hashes (on Windows) - Where Art Thou?
No sooner had posted on doing file and string hashes in PowerShell, when I (again) got asked by Jim - "What about SHA3? Shouldn't we be using Quantum Safe algorithms if we have them?"
Looking around, support for SHA3 is pretty sparse no matter what the OS. For Windows there's a decent solution in bouncycastle (https://www.bouncycastle.org/), but the install is likely more than folks want to tackle, especially if it gets rolled into PowerShell at some future date. Similarly, the SCCM ConfigurationManager module does implement them in some fashion, but that's kind of a dead-end for most of us too.
In a pinch, hashify.net has a public API that supports just about any hashing algorithm you'd care to mention:
curl --location --request GET "api.hashify.net/hash/sha3-512/hex?value=CQCQCQ"
{"Digest":"bcc7a070db5dd926bfbef21c6c5e8081402a79e45f96c4cd7fedc405e1a7fcb6b047cff266235f19f0d1219d2f0fd9299b93cd28d69517d7aefec8cf0c9ffdcc","DigestEnc":"hex","Type":"SHA3-512","Key":""}
The problem with that is - if the information you are hashing (presumably to verify against either now or later) is important or sensitive enough to warrant using one of the fancy SHA3 algorithms, it's likely not data that you want sent to a public website in the clear.
I eventually decided to use the functionality in OpenSSL, with the rationale that anyone who needs this function will likely have OpenSSL already installed locally, at most we'd be asking them to upgrade - you'll need OpenSSL 1.1.1 or better for SHA3-xxx hash support. The syntax is:
echo "some string" | openssl dgst -hashalgorithm
or
type "somefilespec" | openssl dgst -hashalgorithm
where "hashalgorithm" is any of:
blake2b512 blake2s256 md4
md5 md5-sha1 mdc2
ripemd ripemd160 rmd160
sha1 sha224 sha256
sha3-224 sha3-256 sha3-384
sha3-512 sha384 sha512
sha512-224 sha512-256 shake128
shake256 sm3 ssl3-md5
ssl3-sha1 whirlpool
So for implementing this in PowerShell, it's as easy as creating the command in a string, then calling it with "Invoke-Expression" (shortened to "iex" in the examples below).
So for now, until Microsoft rolls better support for SHA3 family of hashing algorithms, my quick-and-dirty implementation for the newer, shinier hash algorithms is below. Note that if OpenSSL isn't in the path, I've got a variable pointed to the path to the binary (update this variable to match your install). In any "real" code you would put this in a config file of course (because we all need more config files in our life right?)
|
$OpenSSLPath = "C:\openssl-1.1.1h\bin\" function Get-StringHash-OpenSSL ( [String] $InputString, $HashAlgo ) { $QT = "`"" $cmd = "echo " + $QT + $InputString + $QT + " | " + $OpenSSLPath + "openssl.exe dgst -" + $HashAlgo $callcmd = iex $cmd $callcmd.split(" ")[1] } $hash = get-stringhash-openssl "CQ CQ CQ" "SHA3-256" $hash 5b960a5284843bb23af5e249c8692bd6d831645cc5070d501b4cef3e94d6983e |
|
$OpenSSLPath = "C:\openssl-1.1.1h\bin\" function Get-FileHash-OpenSSL ( [String] $InputFileSpec, $HashAlgo ) { $QT = "`"" $cmd = "type " + $QT + $InputFileSpec + $QT + " | " + $OpenSSLPath + "openssl.exe dgst -" + $HashAlgo $callcmd = iex $cmd $callcmd.split(" ")[1] } $hash = get-FileHash-OpenSSL "c:\windows\system32\cmd.exe" "Sha3-512" $hash 0cacd8c85b44eed57101fee1431434278319dc441aee26354f811b483a30ff7861ecc88f4c90791e941e49dcb124a975d9eb301 |
If you've worked out a way to get these algorithms into PowerShell without IEX or any 3rd party installs, please share using our comment form.
(And yes, I did riff on the title of Mark Baggett's presentation next week - Tech Tuesday Workshop - O Hacker, Where Art Thou?: A Hands-On Python Workshop for Geolocating Attackers https://www.sans.org/webcasts/hacker-art-thou-hands-on-python-workshop-geolocating-attackers-115340 )
===============
Rob VandenBrink
www.coherentsecurity.com
Comments
I have spent way too much time on this trying to figure something out in PowerShell. The intent of the code in the above function is to pass the string as STDIN to openssl (which seems to only accept file input). In DOS, the trivial chop.pl Perl program, "while ( <> ) { chop(); print; }", removes the trailing CRLF from each input line. I am a Powershell neophyte. When I put this program in the PowerShell pipeline, the CRLF magically reappears. Is there a way to send the string (sans CRLF) directly to openssl without creating an intermediate file?
Anonymous
May 28th 2020
4 years ago
There isn't actually a CRLF at the end of $hash, you can verify this with :
foreach($c in $hash.tochararray()) { write-host ([byte][char]$c)}
(you'll only see the ascii values expected)
Or even simpler you can check with:
> $hash.Length
64
> $hash[63]
e
(ie - the last character is an "e")
However, write-host does append a newline return by default, so you'll see it in the output - there is in fact a newline character to kill here. You can remove it as below:
write-host -NoNewline $hash
I'll correct the code in my github (it's not there yet, but should be soon)
ps - if you needed to remove the trailing CR or LF chars from a string that has them, there are more than a few ways to do it. You can use "replace" or "split/join" (in multiple different ways each) - I tend to use replace most often. If anyone else has other methods they're welcome to append to this thread :-)
Anonymous
May 28th 2020
4 years ago
P.S. As a PowerShell neophyte, I am learning some weird things. For example, I can put two "-" characters in the names of functions as in your original diary, but if I put them in a so-called module and import the module, PowerShell squawks. (I have to remove the second "-".) I understand the "why the squawk"; what I don't understand is why it allows the second "-" in a script. Another weird thing is this: once you import a module, if you update the source and then import it again, it does not "take." In my experience I had to remove-module and then import-module again. It's as if PowerShell caches the file and doesn't bother to check if it's been updated. Maybe there's something else going on here, but it confused the heck out of me until I found the "remove-module workaround."
Anonymous
May 28th 2020
4 years ago
$cmd = "cmd /c " + $QT + "echo " + $InputString + "|chop|" + $OpenSSLPath + "openssl.exe dgst -" + $HashAlgo + $QT
This sort of works because DOS pipes do what you want and expect, but PS pipes (or something) don't. Somehow a CRLF always gets inserted in the PS-controlled pipeline resulting in openssl seeing a string with CRLF appended. I can't find a PS way around this, so used DOS. But this has its own pitfalls I won't really go into here (for example, notice there's no trailing space after $InputString).
Finally, here is the guts of a simple Perl chop program that works in DOS. I wrote it this way to help with debug and to see all characters, etc. (Without binmode, Perl would change the CRLF to a LF, i.e., a "\n".)
$CR = chr(13);
$LF = chr(10);
binmode STDIN;
while ( $u = <STDIN> ) {
if ( $verbose ) {
print STDERR ++$ln , ':' , $u;
print STDERR length($u) , ':(' , join( ',' , map( ord($_) , split( '' , $u ) ) ) , '):' , $u;
}
$u =~ s/[$CR$LF]+$//o;
print STDOUT $u;
}
P.S. I started fooling around with the "file" version of the function, and it has the same perceived problem as the "string" version, namely, a CRLF is appended to the file contents. Since "openssl.exe dgst" allows a file parameter, changing the $cmd variable as follows is a fix. I must point out that either I am way off base here and missing something important (anyone?) or there is a real effort to use ECHO and TYPE and pipes in PS in these functions. Why, I don't know. Both original functions are broken, right? I am all ears, as they say. I expect this to be my last follow-up on the subject, although some corroboration would be nice. (BTW, being a neophyte PS programmer, I thought this diary would be a good way to study PS. That's how I got interested in this.)
$cmd = $OpenSSLPath + "openssl.exe dgst -" + $HashAlgo + " " + $QT + $InputFileSpec + $QT
Anonymous
May 29th 2020
4 years ago