HTTP身份认证401不同情况下弱口令枚举方法及java代码实现(上篇)
2023-12-18 22:58:55 Author: 渗透安全团队(查看原文) 阅读量:4 收藏

 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协议。

 Part3 总结 

1.  对于HTTP身份验证的弱口令审计,需要仔细分析服务器返回消息头中的WWW-Authenticate字段。

2.  本篇文章对于新手会难以理解,最好是能搭建环境尝试一下,还有更多关于HTTP身份验证的情况,后续ABC_123继续搭建环境给大家分享。


付费圈子

欢 迎 加 入 星 球 !

代码审计+免杀+渗透学习资源+各种资料文档+各种工具+付费会员

进成员内部群

星球的最近主题和星球内部工具一些展示

加入安全交流群

                               

关 注 有 礼

关注下方公众号回复“666”可以领取一套领取黑客成长秘籍

 还在等什么?赶紧点击下方名片关注学习吧!


干货|史上最全一句话木马

干货 | CS绕过vultr特征检测修改算法

实战 | 用中国人写的红队服务器搞一次内网穿透练习

实战 | 渗透某培训平台经历

实战 | 一次曲折的钓鱼溯源反制

免责声明
由于传播、利用本公众号渗透安全团队所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,公众号渗透安全团队及作者不为承担任何责任,一旦造成后果请自行承担!如有侵权烦请告知,我们会立即删除并致歉。谢谢!
好文分享收藏赞一下最美点在看哦

文章来源: http://mp.weixin.qq.com/s?__biz=MzkxNDAyNTY2NA==&mid=2247513015&idx=1&sn=4ad80585ca5f170823fe4c175c589a11&chksm=c0b2473c5124cdf3fbc9d5dbcabdbe58387bfd092de7e7423cf996f258ba752adb5b426d905c&scene=0&xtrack=1#rd
如有侵权请联系:admin#unsafe.sh