HTTP身份认证401不同情况下弱口令枚举方法及java代码实现

本文链接：https://blog.csdn.net/Javachichi/article/details/135075894

Part1 前言

大家好，我是ABC_123。在日常的渗透测试及红队评估项目中，经常遇到http 401身份认证的情况，具体就是访问一个特定目录的时候，会弹出一个要求输入用户名密码的框框。很多朋友会误以为是与tomcat的http basic认证一样，就是把用户名及密码进行了简单的base64加密，然后使用相应的工具进行弱口令猜解，实际上这里面有各种各样的身份验证算法，非常复杂。接下来ABC_123就搭建IIS测试环境，给大家分享一下相关经验，同时分享一下不同情况下弱口令枚举的关键Java代码实现，网上能用的java代码极少，甚至是搜索不到，ABC_123也是踩了一大堆的坑。

**注：**特别感谢我的APT老大哥的指点，Negotiate协议和Kerberos协议的问题困扰了我好长时间，在老哥的指点下茅塞顿开。

Part2 技术研究过程

基础环境搭建

IIS中间件可以很方便地设置常用的HTTP 身份认证，本地搭建一个IIS环境，对需要身份认证的/fck目录进行权限设置，双击“身份验证”选项。

发现IIS默认情况下有以下这几种身份验证方式，分别是“Windows身份验证”、“基本身份验证”、“匿名身份验证”、“摘要式身份验证”。其中匿名身份验证就是允许任意用户访问，不牵扯到输入弱口令问题，这里就不过多叙述了。

基本身份验证

首先看第一种情况，也就是最常见的Http Basic认证，就是类似于Tomcat后台管理页面的登录方式。如下图所示，开启“基本身份验证”选项，其它的全部关闭。

在这种情况下，以GET请求访问**/fck**目录时返回如下消息头，“Basic” 表示所使用的验证方案是基本身份验证，这是HTTP协议中最简单的一种认证方法。“realm="192.168.237.129"” 指示了受保护资源所属的域，除了IP地址，也可以是一个域环境的域名。

使用burpsuite进行抓包发现，其加密方式就是普通的Base64加密，与大家最常见的Tomcat的后台登录加密方式是一样的，这种的太过常见，这里就不过多叙述。

摘要式身份验证

接下来尝试一下“摘要式身份验证”，IIS中间件下的开启摘要式身份验证需要加入域环境，于是ABC_123安装了一个域控虚拟机，域名为test111.com。接下来选择test111.com之后点击确定，IIS就启用了该认证模式。

此时，以GET请求**/fck目录，发现服务器返回如下消息头：“Digest” 表示所使用的验证方案是摘要身份验证；“qop” 表示质量保护，这里是指定为"auth"，表示使用身份验证；“algorithm” 指定了使用的加密算法，这里是MD5-sess；“nonce” 是一个由服务端生成的随机字符串；realm则给出了域控服务器的域名，就是我们搭建的域环境test111.com**。

根据弹出的提示框输入一个用户名密码，之后使用burpsuite抓包，发现浏览器发送的http请求是如下格式，看起来非常复杂，已经不是使用简单的java代码就能够实现弱口令猜解的。

最后，ABC_123踩了一大堆坑，然后各种搜索、尝试了各种代码，最后给出如下真正可用的java代码。将如下代码改成多线程，就可以实现对此的HTTP 摘要身份验证的用户名密码的暴力破解了。

Windows身份验证（Negotiate+NTLM）

接下来尝试一下“集成Windows 身份验证”方式，勾选相应的选项之后，使用burpsuite对其进行抓包。

此时，以GET请求**/fck**目录，发现服务器返回如下消息头，返回消息头有两个WWW-Authenticate，ABC_123查阅资料发现，这里主要是为了兼容性的考量。如果客户端不支持Negotiate协议，那么我们的浏览器就会选择NTLM认证方式；如果客户端支持并选用了Negotiate协议，又会有两种情况，分别是Kerberos协议及NTLM协议。这时候如果客户端支持Kerberos，会优先使用Kerberos验证；如果不支持Kerberos，则会选用NTLM认证。这里面很绕，如果新手朋友听不明白，可以继续看接下来的实验。

根据提示框的提示，输入用户名密码之后，使用抓包工具进行抓包发现Authorization: Negotiate TlRMTVNTUAADAAAA，base64解码之后发现是Authorization: Negotiate NTLMSSP+二进制数据，说明此时我们的浏览器选择了NTLM认证。

对于这种情况下的HTTP NTLM账号密码猜解，ABC_123又是踩了一大堆的坑，最终给出的真正能用的Java代码如下：

Windows身份验证（Negotiate+Kerberos）

接下来看最后一种情况，就是Negotiate认证下的Kerberos协议过程。本地继续搭建一个虚拟机，新建一个域用户并以域用户身份登录此虚拟机。

此时目标url的/fck目录不能以ip地址形式访问，需要以计算机名的形式浏览，此时发现不需要输入用户名及密码就可以直接访问/fck目录。因为我们以域用户身份登录了当前虚拟机，当前域用户是有权限访问/fck目录的，所以此时浏览器使用了Kerberos认证。此时使用Fiddler抓包，在“认证”选项卡下，发现了通信过程是Kerberos协议。