+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Support (https://hashcat.net/forum/forum-3.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-45.html)
+--- Thread: IIS http digest (/thread-7965.html)
IIS http digest - tecxx - 11-19-2018
Hello,
i am trying to crack a HTTP DIGEST capture i have done on my lan, between a client and a IIS webserver.
this post specifically has helped to construct a well formed hash file
https://hashcat.net/forum/archive/index.php?thread-7054.html
so everything looks good, hashcat processes it, but i cannot crack the hash even when i specify the correct password explicitely.
can i post the hash here so someone can help me understand what i am doing wrong?
thxs
RE: IIS http digest - royce - 11-19-2018
If it's a test hash that you created yourself and has a known plaintext, then it's OK to post the whole hash (as long as you also include the plaintext).
RE: IIS http digest - tecxx - 11-19-2018
everything is from my lab domain, where i test things.
This is the wireshark capture:
GET / HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
Accept-Language: de-DE
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
If-Modified-Since: Mon, 19 Nov 2018 14:49:06 GMT
If-None-Match: "83216451780d41:0"
Host: 10.10.66.4
Connection: Keep-Alive
Authorization: Digest username="User1",realm="Digest",nonce="+Upgraded+v1d95f0252b2c97add7c3d19f0b23275be01fec8711880d4019975d3e5dd89fc7cd707d6f562d73635ad8a08c702778c3f9bdc20e7cc9d65d0",uri="/",cnonce="+Upgraded+v174d4365dd37172c6f972d3719175bd4cc5d776b973f0cf6060b43e1c3dfefa0c",nc=00000001,algorithm=MD5-sess,response="95e42ef615f178300e863c767724cc0c",qop="auth",charset=utf-8,hashed-dirs="service-name,channel-binding",service-name="HTTP/10.10.66.4",channel-binding="00000000000000000000000000000000"
The password for the user is "P@ssw0rd"
the file i constructed for hashcat is as follows:
$sip$***User1*Digest*GET**/**+Upgraded+v1d95f0252b2c97add7c3d19f0b23275be01fec8711880d4019975d3e5dd89fc7cd707d6f562d73635ad8a08c702778c3f9bdc20e7cc9d65d0*+Upgraded+v174d4365dd37172c6f972d3719175bd4cc5d776b973f0cf6060b43e1c3dfefa0c*00000001*auth*MD5*95e42ef615f178300e863c767724cc0c
is "hashed directives" the missing piece to my puzzle? or what is wrong?
RE: IIS http digest - philsmd - 11-19-2018
I think the MD5-sess "algorithm" could be a problem here, afaik we currently only support the "normal" "MD5" one.
see the differences here:
https://en.wikipedia.org/wiki/Digest_access_authentication#Overview
Quote:If the algorithm directive's value is "MD5-sess", then HA1 is
HA1 = MD5(MD5(username:realm:password):nonce:cnonce)
since the calculation of HA1 involves the password, this needs to be done within the kernel
btw. I didn't really troubleshoot if the remaining parts are okay, but it's quite easy to find out with some code snippets like the ones that can be found in test.pl etc (if you know all the parts and "only" the HA1 calculation is incorrect, we know the reason for sure: i.e. it's MD5-sess vs MD5)
RE: IIS http digest - tecxx - 11-20-2018
thanks for the info, very helpful.
my understanding of this is, that the implementation of digest auth in IIS is therefore currently not crackable with hashcat "out of the box". it's fine, i am just trying to understand the technology, don't need to get it actually working.
RE: IIS http digest - philsmd - 11-20-2018
yeah, there are basically 2 different algorithms, namely "MD5" vs "MD5-sess", and currently only MD5 is supported by hashcat.
The difference is basically that MD5-sess includes the nonce and client nonce also within the HA1 calculation.
Furthermore, because of the fact that nonce and cnonce are used by MD5-sess also for HA1, we need to do a second layer of hashing i.e.
Code:
$tmp = $username . ":" . $realm . ":" . $password
$HA1 = md5 ($tmp) // this is all we need to do for the algorithm "MD5"
$HA1 = md5 ($HA1 . ":" . $nonce . ":" . $cnonce) // MD5-sess needs to include nonce & cnonce; additional MD5 hashif you want to verify your hash, it should work something like this in perl:
Code:
#!/usr/bin/env perl
# Author: philsmd
# Date: 20th November 2018
# License: public domain (credits are always nice !)
use strict;
use warnings;
use Digest::MD5 qw (md5_hex);
# Constants:
my $PASS = "P\@ssw0rd";
#
# Parameters:
#
my $directive = "MD5-sess";
my $user = "User1";
my $realm = "Digest";
my $nonce = "+Upgraded+v1d95f0252b2c97add7c3d19f0b23275be01fec8711880d4019975d3e5dd89fc7cd707d6f562d73635ad8a08c702778c3f9bdc20e7cc9d65d0";
my $nonce_count = "00000001";
my $nonce_client = "+Upgraded+v174d4365dd37172c6f972d3719175bd4cc5d776b973f0cf6060b43e1c3dfefa0c";
my $qop = "auth";
my $method = "GET";
my $URI_prefix = "";
my $URI_resource = "/";
my $URI_suffix = "";
# not needed information
my $URI_server = "";
my $URI_client = "";
#
# Start:
#
my $URI = "";
if (length ($URI_prefix) > 0)
{
$URI = $URI_prefix . ":";
}
$URI .= $URI_resource;
if (length ($URI_suffix) > 0)
{
$URI .= ":" . $URI_suffix;
}
my $HA2 = md5_hex ($method . ":" . $URI);
# "MD5" HA1 (wrong in our case):
# my $HA1 = md5_hex ($user . ":" . $realm . ":" . $);
# "MD5-sess" HA1:
# HA1 = MD5(MD5(username:realm:password):nonce:cnonce)
my $HA1 = md5_hex (md5_hex ($user . ":" . $realm . ":" . $PASS) . ":" . $nonce . ":" . $nonce_client);
my $tmp_buf;
if (($qop eq "auth") || ($qop eq "auth-int"))
{
$tmp_buf = $nonce . ":" . $nonce_count . ":" . $nonce_client . ":" . $qop;
}
else
{
$tmp_buf = $nonce;
}
my $hash_buf = md5_hex ($HA1 . ":" . $tmp_buf . ":" . $HA2);
my $tmp_hash = sprintf ("\$sip\$*%s*%s*%s*%s*%s*%s*%s*%s*%s*%s*%s*%s*%s*%s", $URI_server, $URI_client, $user, $realm, $method, $URI_prefix, $URI_resource, $URI_suffix, $nonce, $nonce_client, $nonce_count, $qop, $directive, $hash_buf);
print $tmp_hash . "\n";That said, it wouldn't be impossible to implement this in hashcat. There are only 3 "problems", the selection/branch within the kernel between "MD5" vs "MD5-sess" might slow the kernel down a little bit (maybe it should be implemented in a separate kernel or kernel function), we need to add the double MD5 hashing (instead of the single MD5), the nonce and client nonce need to be passed as salt/esalt to the kernel (a new struct field etc) since currently the nonce is not used in HA1 and therefore not used within the kernel.
Well, it's possible, but we didn't get many requests for this MD5-sess algorithm in the past. We can still consider opening a issue on github if we think this is important.