Broken lower-case mssql hash validation

[sjanusz-r7]

Hello 👋 It seems like 5bd9489 broke the validation for MSSQL hashes as it is case-sensitive. Output from nmap (below) is not considered to be valid by john.

Manually converting the nmap output to uppercase, john works; hashcat works with lower and upper-case hashes. 🚀

John output

 john --wordlist=words.txt hashes.txt
Using default input encoding: UTF-8
Loaded 1 password hash (mssql12, MS SQL 2012/2014 [SHA512 256/256 AVX2 4x])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
Warning: Only 5 candidates left, minimum 16 needed for performance.
p4$$w0rd1        (testing)     
1g 0:00:00:00 DONE (2024-04-18 17:34) 100.0g/s 500.0p/s 500.0c/s 500.0C/s foo..toto
Use the "--show" option to display all of the cracked passwords reliably
Session completed.

hashcat output

❯ hashcat --force -m 1731 ./hashes.txt ./words.txt
hashcat (v6.2.6) starting

You have enabled --force to bypass dangerous warnings and errors!
This can hide serious problems and should only be done when debugging.
Do not report hashcat issues encountered when using --force.

OpenCL API (OpenCL 3.0 PoCL 5.0+debian  Linux, None+Asserts, RELOC, SPIR, LLVM 16.0.6, SLEEF, DISTRO, POCL_DEBUG) - Platform #1 [The pocl project]
==================================================================================================================================================
* Device #1: cpu-haswell-Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz, 1426/2916 MB (512 MB allocatable), 4MCU

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
Minimim salt length supported by kernel: 0
Maximum salt length supported by kernel: 256

Hashes: 2 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Optimizers applied:
* Zero-Byte
* Early-Skip
* Not-Iterated
* Single-Hash
* Single-Salt
* Raw-Hash
* Uses-64-Bit

ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 0 MB

Dictionary cache built:
* Filename..: ./words.txt
* Passwords.: 5
* Bytes.....: 38
* Keyspace..: 5
* Runtime...: 0 secs

The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.           

0x02001dfee5a5c3ee8c287158e8eb412a08d6a0099d3be0dddbb831d9f8a2c018ade26c747d35248b6288fcfacc15a852f1d6f65bb65b0355539bd3c2b53469ecbe71c19ad847:p4$$w0rd1
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 1731 (MSSQL (2012, 2014))
Hash.Target......: 0x02001dfee5a5c3ee8c287158e8eb412a08d6a0099d3be0ddd...9ad847
Time.Started.....: Thu Apr 18 17:36:46 2024, (0 secs)
Time.Estimated...: Thu Apr 18 17:36:46 2024, (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (./words.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:       75 H/s (0.01ms) @ Accel:256 Loops:1 Thr:1 Vec:4
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 5/5 (100.00%)
Rejected.........: 0/5 (0.00%)
Restore.Point....: 0/5 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: foo -> toto
Hardware.Mon.#1..: Util: 25%

Started: Thu Apr 18 17:36:13 2024
Stopped: Thu Apr 18 17:36:49 2024

nmap output

└─$ nmap -p1433 --script ms-sql-dump-hashes --script-args 'mssql.username=testing,mssql.password=p4$$w0rd1' 192.168.123.138 
Starting Nmap 7.91 ( https://nmap.org/ ) at 2024-04-18 12:25 EDT
Nmap scan report for 192.168.123.138
Host is up (0.0012s latency).

PORT     STATE SERVICE
1433/tcp open  ms-sql-s
| ms-sql-dump-hashes: 
| [192.168.123.138:1433]
|     sa:0x0200892471f29e5502cfe8db9f1d7bb108baad47124e153bb522025dc000066c4d2cdb251505b2c277b3dbaca17536b17098ede0c32f3e519ca24754c5f3626f0dca998bc460
|     ##MS_PolicyEventProcessingLogin##:0x0200fbbda90a5184e0439ece630d1e47d721085df8071d3e436fc96fd1b7ff6214938fe2bedc1a1ac9ba838c87d5eef356f0d53be730288501f461c3b7fdbc9179129bcd477c
|     ##MS_PolicyTsqlExecutionLogin##:0x020043ed60dbb90258894a6a830dfddf1b4d2000149edeb27092ee9d594f71f442b7c78a8ad1369322021f5950a665576e18ea1b335d6a853d4341c51731d9d293ef14e79f25
|     admin:0x020034e0c14a7cc7c2bc49c9ed95002b4094159910209fae561fd0a08479ecaae477413c6fc1c43801fb7bd6281ed71de82342bcde352ca09eb6eb11043ca12a40d3d8de6660
|_    testing:0x02001dfee5a5c3ee8c287158e8eb412a08d6a0099d3be0dddbb831d9f8a2c018ade26c747d35248b6288fcfacc15a852f1d6f65bb65b0355539bd3c2b53469ecbe71c19ad847

Nmap done: 1 IP address (1 host up) scanned in 0.37 seconds

John Version

Not bleeding edge, but latest on Kali and the affected code in the linked PR hasn't been changed since 👍

Version: 1.9.0-jumbo-1+bleeding-aec1328d6c 2021-11-02 10:45:52 +0100
Build: linux-gnu 64-bit x86_64 AVX2 AC OMP
SIMD: AVX2, interleaving: MD4:3 MD5:3 SHA1:1 SHA256:1 SHA512:1
System-wide exec: /usr/lib/john
System-wide home: /usr/share/john
Private home: ~/.john
CPU tests: AVX2
CPU fallback binary: john-xop-omp
OMP fallback binary: john-avx2-non-omp
$JOHN is /usr/share/john/
Format interface version: 14
Max. number of reported tunable costs: 4
Rec file version: REC4
Charset file version: CHR3
CHARSET_MIN: 1 (0x01)
CHARSET_MAX: 255 (0xff)
CHARSET_LENGTH: 24
SALT_HASH_SIZE: 1048576
SINGLE_IDX_MAX: 32768
SINGLE_BUF_MAX: 4294967295
Effective limit: Max. KPC 32768
Max. Markov mode level: 400
Max. Markov mode password length: 30
gcc version: 11.4.0
GNU libc version: 2.37 (loaded: 2.37)
Crypto library: OpenSSL
OpenSSL library version: 0300000b0      (loaded: 030100050)
OpenSSL 3.0.11 19 Sep 2023      (loaded: OpenSSL 3.1.5 30 Jan 2024)
GMP library version: 6.3.0
File locking: fcntl()
fseek(): fseek
ftell(): ftell
fopen(): fopen
memmem(): System's
times(2) sysconf(_SC_CLK_TCK) is 100
Using times(2) for timers, resolution 10 ms
HR timer: clock_gettime(), latency 39 ns
Total physical host memory: 3888 MiB
Available physical host memory: 2740 MiB
Terminal locale string: C.UTF-8
Parsed terminal locale: UTF-8

[solardiz]

Thank you for reporting this, @sjanusz-r7!

We were under impression that tools standardized on uppercase for MS SQL hashes. Since for many other hashes the case of characters in their encodings matters, we do not universally support arbitrary/mixed case.

I've prepared a patch for this issue to have our three MS SQL formats support both upper and lower case, by unifying to upper case for writing to pot files, like we already do e.g. in mysqlSHA1_fmt_plug.c. I'm also setting FMT_SPLIT_UNIFIES_CASE for consistency, even though I think it no longer matters after #4429 as mentioned in #4430. We'll need to clean that up separately.

While at it, I was also interested in how easily crackable your test password is. Turns out our current default settings (no options at all, just the filename) do crack it, but that takes a minute on a laptop CPU. However, putting only the word password in a wordlist file and using -ru=by-rate -rules-stack=by-score cracks it instantly. So our default wordlist rules are powerful enough to crack this given other manglings of this word already present in our default password.lst, but not powerful enough to crack it from just the original word password, for which dual application of our larger rule set is needed. All of this pertains to our latest settings in here, which were replaced in January 2022, so your build from November 2021 probably doesn't have this and would have a harder time cracking this password.