对于无线WPA加密环境，在获得了WPA握手验证包后，攻击者会通过暴力破解模式来进行WPA密码破解，同时也可以通过事先建立有针对性的字典，然后再进行字典破解(攻击)。对于大多数无线接入点AP而言，这将会是个行之有效的方法。因为事实证明：绝大部分的管理员、维护人员、家庭用户的安全意识并没有他们自己认为的那么高，至少过去的一年多时间里，笔者已经遇到了无数设置为生日或者简单单词的WPA-PSK密码。
那么，是不是可以说，只要有足够空间、考虑周全的字典，破解WPA实际也就主要是时间的问题了。真的只是这样么?不知道大家仔细留意过没有，按照现在主流单机环境配置，在WPA破解速率上也就维持在100~~300k/s(k/s指的是破解时每秒调用的key数量)，以这样的破解速率，要把一个以小写字母和数字组合的5位WPA密码破开，我们来以基本的概率论知识估算一下：
(26+10)?=
破解所有花费的时间将会是：
00300)~~
00100)，即花费55.987~~167.962小时。
若是换算成天数的话，大概需要2~~7天。这还只是5位数WPA密码，若是采用WPA密码为纯小写字母且长度在10位数以上，则最快需要时间是5446261
天，也就是14921年!!真的是天位数字啊!!若是密码组合采用大小写字母+数字+特殊字符的话，恐怕连看到这里的你都会说：还是不用考虑破解了吧?
所以，前面讲述的获得到WPA握手后，进行的破解实际上只适用于是在对方采用简单密码的情况，也就是说，因为破解速率太慢，所以在对方采用稍微复杂的密码之后，这个常规方法就没有太多的实战能力甚至彻底失去破解意义。
若有人对概率知识稍有欠缺，或者觉得计算破解时间太麻烦的话，可以到下面这个网址上看看，这上面提供一个在线估算密码破解时间的服务，很方便。网址：，可以看到一个明显的Password
Calculator标题，即密码估算。
在下面的栏目中，可以输入要计算密码的可能长度、使用计算机的破解速率、被用于破解的计算机数量、密码的组合可能(大小写字母、数字、通配符或全部)，填写完毕，点击下方的Calculate(计算)，在其下方就可以给出暴力破解的估算时间了。如下图2，可以看到估算出采用小写字母和数字组成的5位数密码，，在单机以30k/s的速率破解需要时间为24天!!
密码估算服务设置内容
看到这里，也许有的读者会想到：可以升级硬件设备啊，比如CPU、内存之类。不错，升级硬件确实可以在一定程度上提升破解，但那也是很有限的，比如就目前而言，普通独立计算机下内存最大也就能升级到4G，CPU无非就是最新的高缓存四核处理器。这样的配置对于刚才我们举例的10位WPA密码，破解时间还是以年来计算的!!
那么，那些高级黑客们又是怎么做的呢?难道只是靠单纯地提升硬件么?这里我们在揭开高速破解之前，先讲述一些概念：
Tables
可以说长期进行密码学研究的人很少有不知道这个的。在很多年前，国外的黑客们就发现单纯地通过导入字典，采用和目标同等算法破解，其速度其实是非常缓慢的，就效率而言根本不能满足实战需要。之后通过大量的尝试和总结，黑客们发现如果能够实现直接建立出一个数据文件，里面事先记录了采用和目标采用同样算法计算后生成的Hash散列数值，在需要破解的时候直接调用这样的文件进行比对，破解效率就可以大幅度地，甚至成百近千近万倍地提高，这样事先构造的Hash散列数据文件在安全界被称之为Table表(文件)。
Rainbow
最出名的Tables是Rainbow
Tables，即安全界中常提及的彩虹表，它是以Windows的用户帐户LM/NTLM散列为破解对象的。简单说明一下，在
Windows2000/XP/2003系统下，账户密码并不是明文保存的，而是通过微软所定义的算法，保存为一种无法直接识别的文件，即通常所说的SAM文件，这个文件在系统工作时因为被调用所以不能够被直接破解。但我们可以将其以Hash即散列的方式提取，以方便导入到专业工具破解，提取出来的密码散列类似于下面：
#p#分页标题#e#
Administrator:500:96e95ed6bad37454aad3b435b51404ee:64e2d1e9b06cb8c8b05e42f0e6605c74:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
user1:c9aaef:d5defa4790129f:::
user2:a9b:da34fcd580:::
若是以传统破解方式而言，无论是本地，还是内网在线破解，效率都不是很高。据实际测试，单机环境下，破解一个14位长包含大小写字母以及数字的无规律密码，一般是需要3~~9小时的，这个时间值会随着密码的复杂度及计算机性能差异提升到几天甚至数月不等。虽然说大部分人都不会使用这样复杂的密码，但对于目前很多密码足够复杂并且长度超过10位的密码比如Y1a9n7g9z0h7e，还是会令黑客们头痛不已。
2003年7月瑞士洛桑联邦技术学院Philippe
Oechslin公布了一些实验结果，他及其所属的安全及密码学实验室(LASEC)采用了时间内存替换的方法，使得密码破解的效率大大提高。作为一个例子，他们将一个常用操作系统的密码破解速度由1分41秒，提升到13.6秒。这一方法使用了大型查找表对加密的密码和由人输入的文本进行匹配，从而加速了解密所需要的计算。这种被称作内存-时间平衡的方法意味着使用大量内存的黑客能够减少破解密码所需要的时间。
于是，一些受到启发的黑客们事先制作出包含几乎所有可能密码的字典，然后再将其全部转换成NTLM
Has***件，这样，在实际破解的时候，就不需要再进行密码与Hash之间的转换，直接就可以通过文件中的Hash散列比对来破解Windows帐户密码，节省了大量的系统资源，使得效率能够大幅度提升。当然，这只是简单的表述，采用的这个方法在国际上就被称为Time-Memory
，即刚才所说的内存-时间平衡法，有的地方也会翻译成时间内存交替运算法。其原理可以理解为以内存换取时间，可由下图3表示：
对Windows账户进行Rainbow
Tables破解
如上图4可以看到，类似于c78j33c6hnws、yemawangluo178、这样的Windows帐户密码几乎全部在180秒即3分钟内破出，最短只用了5秒，个别稍长的密码破解开也没有超过3分钟。
由于这里我们讨论的是无线安全部分，所以本文就Windows下的Tables技术不再深入举例。有兴趣的读者可以从本文后面列出的网址查看更多的相关资料。
WPA-PSK
现在，在理解了内存-时间平衡法和Table的存在意义后，让我们回到无线领域，破解WPA-PSK也是同样的意思。在2006年举行的RECON
2006安全会议上，一位来自Openciphers组织的名为David
Hulton的安全人员详细演示了使用WPA-PSK
Tables破解的技术细节，给与会者极大的震动。
下面所示的为会议上引用的WPA加密以及主密钥对匹配等建立WPA
Tables所需理念的原理图，其中，MK为密码原文，PMK就是通过PBKDF2运算所得出的数值，PTK就是在PMK的基础上进行预运算产生的WPA
Hash，这个Hash将用来和WPA
握手包中的值对照，若匹配即为密码。
针对WPA加密Tables破解的原理图
这种采用了类似Rainbow
Tables原理，通过Pre-Compute即预运算的方式，来进行提前运算以生成WPA-PSK加密Hash，从而建立起来的WPA-PSK
Tables，可以如事先设想般有效地大幅度提升破解效率。一般来说，可以将以前的100~~300
key/s的普通单机破解速率，提升到30，000~~100，000
key/s，提升了近300~~1000倍!!!这才是国内外无线黑客目前使用的破解技术，就一些地下组织而言，甚至个别秉持执著、探求本质精神的黑客通过改进优化代码等方式使得破解速率突破了150，000k/s，而且还有提升空间。这个速度意味着什么，如果再换置成最新的硬件配置呢?聪明的你一定明白。
下图6即为在cowpatty里对获取的WPA握手包进行WPA
Table破解界面，可以看到在导入Table之后，破解速率达到了6，5228
pass/second。
在Cowpatty里进行WPA
Tables破解界面
我想，对于很多无线用户来说，这才是真正的噩梦。古希腊哲学家苏格拉底曾说过这么一句话：
认识你自己。
，但实际上很多时候都是黑客背地猖獗，而很多网络及安全管理人员要么对攻击者的技术仅是略知皮毛，要么就根本一无所知，而且甚至不知道自己在经过所谓安全配置后的网络架构，将实际面临什么样的风险。
虽然说公开一些技术也许反而会引起个别心怀恶意的人注意，不过出于对无线安全理念的普及及深入理解，帮助很多已经完成或者正在进行无线网络规划的军警政机构、大中型企业及特殊部门，更清楚地认识到无线网络的风险，从而尽可能地完善自身的不足，避免不必要的损失，才是本书的出发点。
当然，要说明的是，Tables的建立并没有想象的那么容易，就建立本身而言，其效率非常低下，加上需要指定预攻击AP的SSID，想要建立一套针对所有常见接入点，并采用简单密码的WPA-PSK
Tables，其生成文件占据的硬盘空间最少也要1~~3G。需要深入了解WPA
Table的读者，可以到这个名为The
Wifi的无线黑客组织了解更多内容，该组织官方站点为，该组织在过去的两年里成功建立了庞大的WPA
Table库，并将其简化的WPA-PSK
Table版本提供免费下载，对很多无线黑客而言，这确实是个福音，但遗憾的是，即便是简化版本，其大小也已经超过了30G。
感兴趣的读者可以到:6969去下载这个简化版本的Table种子文件，该Table全部下载回来大小有33.54GB，需要说明的是，生成该Table所依据的字典虽然经过黑客组织的筛选，但是由于国情不同，所以里面部分内容可能并不适合国内情况的使用。比如虽然都会有人使用姓名作为密码，在国外可能是类似于BruceLee这样的英文名称，但是到了国内就可能是Lilianjie这样的拼音了。
Hash下载页面
不过，对于无线网络管理员，并不能因此松一口气，真正的噩梦才刚刚开始，因为这个方法也同样适用于破解WPA2加密。而且，国外一些地下高级黑客组织，也已经建立了高达500G的详尽WPA/WPA2攻击Table库，甚至一些基本完善的WPA-PSK
Tables已经在黑客网站上开始公开出售，只需要支付120美金左右，就会有8张包含WPA-PSK
的DVD光盘通过Fedex直接送到你的手上。
本文章下载来自：温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
活出自己的人生。
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
对于无线WPA加密环境，在获得了WPA握手验证包后，攻击者会通过暴力破解模式来进行WPA密码破解，同时也可以通过事先建立有针对性的字典，然后再进行字典破解(攻击)。对于大多数无线接入点AP而言，这将会是个行之有效的方法。因为事实证明：绝大部分的管理员、维护人员、家庭用户的安全意识并没有他们自己认为的那么高，至少过去的一年多时间里，笔者已经遇到了无数设置为生日或者简单单词的WPA-PSK密码。
那么，是不是可以说，只要有足够空间、考虑周全的字典，破解WPA实际也就主要是时间的问题了。真的只是这样么?不知道大家仔细留意过没有，按照现在主流单机环境配置，在WPA破解速率上也就维持在100~~300k/s(k/s指的是破解时每秒调用的key数量)，以这样的破解速率，要把一个以小写字母和数字组合的5位WPA密码破开，我们来以基本的概率论知识估算一下：(图1所示)
图1 密码可能包含的组合内容
(26+10)?= ;
该5位数WPA密码可能性为：
破解所有花费的时间将会是：
00×300)~~ 00×100)，即花费55.987~~167.962小时。
若是换算成天数的话，大概需要2~~7天。这还只是5位数WPA密码，若是采用WPA密码为纯小写字母且长度在10位数以上，则最快需要时间是5446261 天，也就是14921年!!真的是天位数字啊!!若是密码组合采用大小写字母+数字+特殊字符的话，恐怕连看到这里的你都会说：还是不用考虑破解了吧?
所以，前面讲述的获得到WPA握手后，进行的破解实际上只适用于是在对方采用简单密码的情况，也就是说，因为破解速率太慢，所以在对方采用稍微复杂的密码之后，这个常规方法就没有太多的实战能力甚至彻底失去破解意义。
在下面的栏目中，可以输入要计算密码的可能长度、使用计算机的破解速率、被用于破解的计算机数量、密码的组合可能(大小写字母、数字、通配符或全部)，填写完毕，点击下方的Calculate(计算)，在其下方就可以给出暴力破解的估算时间了。如下图2，可以看到估算出采用小写字母和数字组成的5位数密码，在单机以30k/s的速率破解需要时间为24天!!
图2 密码估算服务设置内容
看到这里，也许有的读者会想到：可以升级硬件设备啊，比如CPU、内存之类。不错，升级硬件确实可以在一定程度上提升破解，但那也是很有限的，比如就目前而言，普通独立计算机下内存最大也就能升级到4G，CPU无非就是最新的高缓存四核处理器。这样的配置对于刚才我们举例的10位WPA密码，破解时间还是以年来计算的!!
那么，那些高级黑客们又是怎么做的呢?难道只是靠单纯地提升硬件么?这里我们在揭开高速破解之前，先讲述一些概念：
Tables
可以说长期进行密码学研究的人很少有不知道这个的。在很多年前，国外的黑客们就发现单纯地通过导入字典，采用和目标同等算法破解，其速度其实是非常缓慢的，就效率而言根本不能满足实战需要。之后通过大量的尝试和总结，黑客们发现如果能够实现直接建立出一个数据文件，里面事先记录了采用和目标采用同样算法计算后生成的Hash散列数值，在需要破解的时候直接调用这样的文件进行比对，破解效率就可以大幅度地，甚至成百近千近万倍地提高，这样事先构造的Hash散列数据文件在安全界被称之为Table表(文件)。
Rainbow Tables
最出名的Tables是Rainbow Tables，即安全界中常提及的彩虹表，它是以Windows的用户帐户LM/NTLM散列为破解对象的。简单说明一下，在 Windows2000/XP/2003系统下，账户密码并不是明文保存的，而是通过微软所定义的算法，保存为一种无法直接识别的文件，即通常所说的SAM文件，这个文件在系统工作时因为被调用所以不能够被直接破解。但我们可以将其以Hash即散列的方式提取，以方便导入到专业工具破解，提取出来的密码散列类似于下面：
Administrator:500:96e95ed6bad37454aad3b435b51404ee:64e2d1e9b06cb8c8b05e42f0e6605c74:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
user1:c9aaef:d5defa4790129f:::
user2:a9b:da34fcd580:::
若是以传统破解方式而言，无论是本地，还是内网在线破解，效率都不是很高。据实际测试，单机环境下，破解一个14位长包含大小写字母以及数字的无规律密码，一般是需要3~~9小时的，这个时间值会随着密码的复杂度及计算机性能差异提升到几天甚至数月不等。虽然说大部分人都不会使用这样复杂的密码，但对于目前很多密码足够复杂并且长度超过10位的密码比如“Y1a9n7g9z0h7e”，还是会令黑客们头痛不已。
2003年7月瑞士洛桑联邦技术学院Philippe Oechslin公布了一些实验结果，他及其所属的安全及密码学实验室(LASEC)采用了时间内存替换的方法，使得密码破解的效率大大提高。作为一个例子，他们将一个常用操作系统的密码破解速度由1分41秒，提升到13.6秒。这一方法使用了大型查找表对加密的密码和由人输入的文本进行匹配，从而加速了解密所需要的计算。这种被称作“内存-时间平衡”的方法意味着使用大量内存的黑客能够减少破解密码所需要的时间。
于是，一些受到启发的黑客们事先制作出包含几乎所有可能密码的字典，然后再将其全部转换成NTLM Has***件，这样，在实际破解的时候，就不需要再进行密码与Hash之间的转换，直接就可以通过文件中的Hash散列比对来破解Windows帐户密码，节省了大量的系统资源，使得效率能够大幅度提升。当然，这只是简单的表述，采用的这个方法在国际上就被称为Time-Memory Trade-Off ，即刚才所说的“内存-时间平衡”法，有的地方也会翻译成“时间—内存交替运算法”。其原理可以理解为以内存换取时间，可由下图3表示：
图3 著名的“内存-时间平衡”法运算原理图
具体算法方面的内容本文就不再涉及，对于想进行更高深层次探究的读者，可以仔细参考2003年的这篇详细文档《Making a Faster Crytanalytical Time-Memory Trade-Off》以及2005年的文档《Time-Memory Trade-Offs: False Alarm Detection Using Checkpoints》，在本节后面会给出链接。
正是由于Rainbow Tables的存在，使得普通电脑在5分钟内破解14位长足够复杂的Windows帐户密码成为可能。
图4 对Windows账户进行Rainbow Tables破解
如上图4可以看到，类似于c78j33c6hnws、yemawangluo178、这样的Windows帐户密码几乎全部在180秒即3分钟内破出，最短只用了5秒，个别稍长的密码破解开也没有超过3分钟。
由于这里我们讨论的是无线安全部分，所以本文就Windows下的Tables技术不再深入举例。有兴趣的读者可以从本文后面列出的网址查看更多的相关资料。
WPA-PSK Hash Tables
现在，在理解了“内存-时间平衡”法和Table的存在意义后，让我们回到无线领域，破解WPA-PSK也是同样的意思。在2006年举行的RECON 2006安全会议上，一位来自Openciphers组织的名为David Hulton的安全人员详细演示了使用WPA-PSK Hash Tables破解的技术细节，给与会者极大的震动。
下面所示的为会议上引用的WPA加密以及主密钥对匹配等建立WPA Tables所需理念的原理图，其中，MK为密码原文，PMK就是通过PBKDF2运算所得出的数值，PTK就是在PMK的基础上进行预运算产生的WPA Hash，这个Hash将用来和WPA 握手包中的值对照，若匹配即为密码。
这种采用了类似Rainbow Tables原理，通过Pre-Compute即预运算的方式，来进行提前运算以生成WPA-PSK加密Hash，从而建立起来的WPA-PSK Hash Tables，可以如事先设想般有效地大幅度提升破解效率。一般来说，可以将以前的100~~300 key/s的普通单机破解速率，提升到30，000~~100，000 key/s，提升了近300~~1000倍!!!这才是国内外无线黑客目前使用的破解技术，就一些地下组织而言，甚至个别秉持执著、探求本质精神的黑客通过改进优化代码等方式使得破解速率突破了150，000k/s，而且还有提升空间。这个速度意味着什么，如果再换置成最新的硬件配置呢?聪明的你一定明白。
下图6即为在cowpatty里对获取的WPA握手包进行WPA Table破解界面，可以看到在导入Table之后，破解速率达到了6，5228 pass/second。
图5 针对WPA加密Tables破解的原理图
这种采用了类似Rainbow Tables原理，通过Pre-Compute即预运算的方式，来进行提前运算以生成WPA-PSK加密Hash，从而建立起来的WPA-PSK Hash Tables，可以如事先设想般有效地大幅度提升破解效率。一般来说，可以将以前的100~~300 key/s的普通单机破解速率，提升到30，000~~100，000 key/s，提升了近300~~1000倍!!!这才是国内外无线黑客目前使用的破解技术，就一些地下组织而言，甚至个别秉持执著、探求本质精神的黑客通过改进优化代码等方式使得破解速率突破了150，000k/s，而且还有提升空间。这个速度意味着什么，如果再换置成最新的硬件配置呢?聪明的你一定明白。
下图6即为在cowpatty里对获取的WPA握手包进行WPA Table破解界面，可以看到在导入Table之后，破解速率达到了6，5228 pass/second。
图6 在Cowpatty里进行WPA Tables破解界面
我想，对于很多无线用户来说，这才是真正的噩梦。古希腊哲学家苏格拉底曾说过这么一句话： “认识你自己。” ，但实际上很多时候都是黑客背地猖獗，而很多网络及安全管理人员要么对攻击者的技术仅是略知皮毛，要么就根本一无所知，而且甚至不知道自己在经过所谓安全配置后的网络架构，将实际面临什么样的风险。
虽然说公开一些技术也许反而会引起个别心怀恶意的人注意，不过出于对无线安全理念的普及及深入理解，帮助很多已经完成或者正在进行无线网络规划的军警政机构、大中型企业及特殊部门，更清楚地认识到无线网络的风险，从而尽可能地完善自身的不足，避免不必要的损失，才是本书的出发点。
当然，要说明的是，Tables的建立并没有想象的那么容易，就建立本身而言，其效率非常低下，加上需要指定预攻击AP的SSID，想要建立一套针对所有常见接入点，并采用简单密码的WPA-PSK Hash Tables，其生成文件占据的硬盘空间最少也要1~~3G。需要深入了解WPA Table的读者，可以到这个名为The Church of Wifi的无线黑客组织了解更多内容，该组织官方站点为http://www.churchofwifi.org，该组织在过去的两年里成功建立了庞大的WPA Table库，并将其简化的WPA-PSK Hash Table版本提供免费下载，对很多无线黑客而言，这确实是个福音，但遗憾的是，即便是简化版本，其大小也已经超过了30G。
感兴趣的读者可以到:6969去下载这个简化版本的Table种子文件，该Table全部下载回来大小有33.54GB，需要说明的是，生成该Table所依据的字典虽然经过黑客组织的筛选，但是由于国情不同，所以里面部分内容可能并不适合国内情况的使用。比如虽然都会有人使用姓名作为密码，在国外可能是类似于BruceLee这样的英文名称，但是到了国内就可能是Lilianjie这样的拼音了。
图7 30G WPA Hash下载页面
不过，对于无线网络管理员，并不能因此松一口气，真正的噩梦才刚刚开始，因为这个方法也同样适用于破解WPA2加密。而且，国外一些地下高级黑客组织，也已经建立了高达500G的详尽WPA/WPA2攻击Table库，甚至一些基本完善的WPA-PSK Hash Tables已经在黑客网站上开始公开出售，只需要支付120美金左右，就会有8张包含WPA-PSK Hash Tables 的DVD光盘通过Fedex直接送到你的手上。
11月7日消息，研究人员日前发现了一种破解WAP（Wi-Fi Protected Access），即Wi-Fi网络安全存取密钥的方法，并且这种方法不需要经过多次尝试，就可以成功突破。有关该方法的技术细节，将与下周在日本东京举行的PacSec大会上公布。据国外媒体报道，研究人员埃里克－陀斯和马丁－班克发现了一种可破解WPA加密方法TKIP的方法，他们甚至可以在15分钟内完成破解。不过此方法只适用于专门针对Wi-Fi适配器的数据，对于从PC到路由器的加密数据并不起作用。 TKIP加密系统在通过大宗数据算法进行破解时其安全性大大降低，这已是为人所共知，此类攻击又称字典攻击。而埃里克－陀斯和马丁－班克使用的并不是上述方法。显然，他们在实施攻击时使用了大量来自WPA路由器的数据，然后结合一种奇怪的算法，最终能突破加密系统。上述方法中的一些元素已被纳入班克的Aircrack-ng Wi-Fi加密黑客工具系统，该工具主要供系统入侵测试者及其他人员使用。事实上陀斯2007年就破解过104-bit WEP （Wired Equivalent Privacy）加密系统。鉴于WEP和WPA两种加密系统均不安全，专家建议无线网络使用WPA2加密系统。 TPIK：TKIP像WEP一样基于RC4加密，但以另一种方式实施，解决了WEP目前存在的脆弱性。它提供了快速更新密钥的功能。利用TKIP，随着各个厂商计划推出TKIP固件补丁，消费者在无线局域网硬件上的投资将得到保护。
阅读(1148)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_085070',
blogTitle:'WPA/WPA2加密高速破解的真相',
blogAbstract:'&WPA/WPA2加密高速破解的真相
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}LM/NTLM验证机制
LM/NTLM验证机制☆ 概述 ☆ 挑战/响应模式 ☆ L0pht文档 ☆ Windows NT身份验证机制的脆弱性 ☆ str_to_key()函数 ☆ 如何从明文口令生成LM Hash ☆ 标准DES加密 ☆ 如何从明文口令生成NTLM Hash ☆ 标准MD4单向哈希 ☆ SMB报文中使用的是DES LM Hash和DES NTLM Hash ☆ 观察一个实例 ☆ negotiate response解码 ☆ session_setup_andx request解码 ☆ 小结 ☆ 参考资源
--------------------------------------------------------------------------
早期SMB协议在网络上传输明文口令。后来出现&LAN Manager Challenge/Response& 验证机制，简称LM，它是如此简单以至很容易被破解。微软提出了WindowsNT挑战/响 应验证机制，称之为NTLM。现在已经有了更新的NTLMv2以及Kerberos验证体系。
微软承认LM Hash的固有特性极大损害了安全性，但他们认为这是最初设计者IBM之过。
☆ 挑战/响应模式
使用明文口令模式时，网络上传输的就是明文口令本身，这很容易被Sniffer捕获。 挑战/响应模式的企图不泄露明文口令本身就能证明客户机确实拥有正确的口令:
1. 服务器随机产生一个8字节的挑战，送往客户机。
2. 服务器、客户机各自使用源自明文口令的DESKEY分别对8字节挑战进行加密。客户 机将计算结果送往服务器，这就是所谓响应(分成三组，总共24字节)。
response = DES( key derived from plaintext password, challenge )
这里使用的就是标准DES算法。任何知道key的人都可以将reponse解密，从而获取 challenge。
3. 如果响应与服务器的计算结果匹配，服务器认为客户机拥有正确的明文口令。
☆ L0pht文档
日，L0pht的Mudge &&对外发布了一份关于SMB通信中身 份验证的文档(参考资源[1])。
+----------------------------+ | 14bytes Plaintext Password | +----------------------------+
+--------------------------------------------------------------------------+ | first 7bytes of Plaintext Password | second 7bytes of Plaintext Password | +--------------------------------------------------------------------------+
+-----------------+ | 16bytes LM Hash | +-----------------+
+----------------------------------------------------+ | first 8bytes of LM Hash | second 8bytes of LM Hash | +----------------------------------------------------+
+-------------------------+ | 16bytes NTLM Hash (MD4) | +-------------------------+
+------------------+ | 8bytes Challenge | +------------------++------------------+ | 24bytes Response | +------------------+
LM Hash的前8字节源自对明文口令前7字节的运算，LM Hash的后8字节源自对明文口 令后7字节的运算。如果明文口令最多7字节，则第二部分LM Hash总是&AA D3 B4 35 B5 14 04 EE&(以后解释这里)。比如以&WELCOME&做为明文口令，则对应的LM Hash是 &CE7665FAAD3B435B51404EE&。
假设服务器B向客户机A发送了一个8字节挑战&0607&
Server B -- 8bytes Challenge --& Client A
A现在有LM Hash，CE7665FAAD3B435B51404EE，在其后增加5个0x00变成 &CE7665FAAD3B435B50000&，然后划分成三组，每组7字节
+----------------+----------------+----------------+ | CE766 | 5FAAD3B435B514 | 04EE | +----------------+----------------+----------------+
每组7字节做为形参传递给str_to_key()函数，最终得到三组DESKEY，每组8字节
+--------------------------------------------------------+ | 8bytes DESKEY1 | 8bytes DESKEY2 | 8bytes DESKEY3 | +------------------+------------------+------------------+ | C21ACCC | 5ED4B47642ACD428 | 0000 | +--------------------------------------------------------+
分别用三组DESKEY对8字节挑战&0607&进行标准DES加密后得到
C21ACCC -对0607进行标准DES加密-& CAD577 5ED4B47642ACD428 -对0607进行标准DES加密-& AB18C764C6DEF34F 0000 -对0607进行标准DES加密-& A61BFA
最终获得一个24字节响应&CAD577AB18C764C6DEF34FA61BFA&， 送往服务器B。在服务器B上进行同样的计算，并将计算结果与来自A的响应进行比较， 如果匹配则身份验证通过。
考虑明文口令不超过7字节的情况。
首先检查明文口令是否少于8字节。用str_to_key()函数处理&04EE&，得 到8字节的DESKEY，&0000&，用它对挑战&0607&进行标准 DES加密，如果结果与网络上传输的&A61BFA&相符，明文口令很可能少于8 字节，当然不能绝对肯定。
接下来用str_to_key()函数处理&??AAD3B435B514&，得到8字节DESKEY，用它对挑战 进行标准DES加密，如果与网络上传输的&AB18C764C6DEF34F&相符，则找到匹配，此 时我们可以绝对肯定明文口令少于8字节。这里&??&由循环产生，穷举256种可能。
由于LM Hash的一些固有特性，穷举运算量已大幅下降。
考虑明文口令为8字节或更多，假设最后的LM Hash如下
+----------------+----------------+----------------+ | CE766 | AC435F2DD90417 | CCD | +----------------+----------------+----------------+
首先检查明文口令是否少于8字节。用str_to_key()函数处理&04EE&，得 到8字节的DESKEY，&0000&，用它对挑战进行标准DES加密，如果结果与 网络上传输的内容不相符，明文口令必然大于等于8字节。
接下来用str_to_key()函数处理&????&，得到8字节DESKEY，用它对挑战 进行标准DES加密，如果与网络上传输的内容相符，则找到匹配。这里&????&由循环 产生，穷举65536种可能。
上面实际在介绍如何根据Challenge/Response暴力破解获取LM Hash。
即使到了NT4 SP3，DES LM Hash Response还是与DES NTLM Hash Response一起发送， 这种情况下NTLM Hash强度再高也是没有意义的。
如果禁用DES LM Hash Response，Windows 95无法与NT进行正常的SMB通信。
如果你所使用的Windows系统支持口令超过14字节，就尽量使用超过14字节的口令。
☆ Windows NT身份验证机制的脆弱性
日，Dominique Brezinski &dominique.&对外 发布了一份关于Windows NT身份验证机制脆弱性的文档(参考资源[8])。
假设有主机B与A
(1) A向B发起连接请求
(2) B向A发送挑战(一组随机数据)
(3) A用源自明文口令的DESKEY对挑战进行标准DES加密得到响应，并发往B
(4) B从SAM中获取A的LM Hash、NTLM Hash，计算出DESKEY，并对前面发往A的挑战进 行标准DES加密
(5) 如果(4)中计算结果与A送过来的响应匹配，A被允许访问B
现在假设一个攻击者C卷入其中
(1) C向B发起连接请求
(2) B向C发送挑战D(一组随机数据)
(3) C等待A向B发起连接请求
(4) 当A向B发起连接请求时，C伪造成B向A发送挑战D
(5) A用源自明文口令的DESKEY对挑战D进行标准DES加密得到响应E，并发往B
(6) C截获到响应E，将它做为针对(2)中挑战D的响应发往B，并声称自己是A
(7) B从SAM中获取A的LM Hash、NTLM Hash，计算出DESKEY，并对挑战D进行标准DES 加密
(8) 如果(7)中计算结果与C送过来的响应匹配，C被允许以A的身份访问B
下面我们详细分析一下这个过程。攻击者C卷入A与B的通信中，C向B建立NBT会话并发 送SMB_COM_NEGOTIATE(0x72)请求报文，指定使用&NT LM 0.12& dialect。在用户级 共享(与之相对的是共享级共享)中&NT LM 0.12&是首选SMB dialect。B将在响应报文 的encryption key(其实应该叫Challenge)字段中返回8字节的挑战。C保存这8字节的 挑战并开始等待，如果B因为超时终止了这次连接，C必须重复前面的步骤。当A试图 连接B时，也会建立NBT会话并发送SMB_COM_NEGOTIATE(0x72)请求报文，就dialect进 行协商。一般最终协商结果都是使用&NT LM 0.12& dialect。C注意到这个协商请求， 于是伪装成B向A发送响应报文，encryption key字段中设置成前面保存下来的挑战。 这个响应报文的源IP设置成B的IP地址，需要分析A送往B的SMB_COM_NEGOTIATE(0x72) 请求报文以设置响应报文的th_ack字段。这个伪造的
响应报文必须抢在B的正常响应 报文之前到达A。如果C本来就扮演着A与B之间路由器一类的角色，这不成问题。来自 B的正常响应报文做为重复数据而被丢弃。此时A生成两组24字节响应，向B发送 SMB_COM_SESSION_SETUP_ANDX(0x73)请求报文。C注意到这个请求，获取了A生成的两 组24字节响应，然后C也构造一个SMB_COM_SESSION_SETUP_ANDX(0x73)请求报文，用 这两组24字节响应分别设置CaseInsensitivePassword、CaseSensitivePassword字段。 同时在AccountName字段设置A的用户名。C将这样一个伪造的0x73请求报文通过最初 建立的NBT会话发往B。至此C将获取一条到B的SMB会话，拥有A用户的权限。
如果C扮演着A与B之间路由器一类的角色，整个攻击过程将大大简化。
☆ str_to_key()函数
前面我们多次提到str_to_key()函数，却未解释这个函数如何实现的，因为用自然语 言描述它比较困难，还是先来看它的C语言描述吧。
-------------------------------------------------------------------------- /* * For x86/FreeBSD 4.5-RELEASE * gcc -Wall -pipe -O3 -o str_to_key_test str_to_key_test.c * * CE7665FAAD3B435B50000 * C21ACCC5ED4B47642ACD0000000 */
#include &stdio.h& #include &stdlib.h& #include &string.h&
/* * 读取形如&AABBCCDDEEFF&这样的16进制数字串，主调者自己进行形参的边界检查 */ static void readhexstring ( const unsigned char *src, unsigned char *dst, unsigned int len ) {
unsigned char str[3];
str[2] = &\0&; for ( i = 0; i & i++ ) { str[0] = src[ i * 2 ]; str[1] = src[ i * 2 + 1 ]; dst = ( unsigned char )strtoul( str, NULL, 16 ); }
} /* end of readhexstring */
/* * from The Samba Team&s source/libsmb/smbdes.c */ static void str_to_key ( const unsigned char *str, unsigned char *key ) {
key[0] = str[0] && 1; key[1] = ( ( str[0] & 0x01 ) && 6 ) | ( str[1] && 2 ); key[2] = ( ( str[1] & 0x03 ) && 5 ) | ( str[2] && 3 ); key[3] = ( ( str[2] & 0x07 ) && 4 ) | ( str[3] && 4 ); key[4] = ( ( str[3] & 0x0F ) && 3 ) | ( str[4] && 5 ); key[5] = ( ( str[4] & 0x1F ) && 2 ) | ( str[5] && 6 ); key[6] = ( ( str[5] &am
0x3F ) && 1 ) | ( str[6] && 7 ); key[7] = str[6] & 0x7F; for ( i = 0; i & 8; i++ ) { key = ( key && 1 ); }
} /* end of str_to_key */
int main ( int argc, char * argv[] ) {
unsigned char buf_0[21]; unsigned char buf_1[24];
if ( argc != 2 ) { fprintf( stderr, &Usage: %s &hexadecimal string&\n&, argv[0] ); return( EXIT_FAILURE ); } memset( buf_0, 0, sizeof( buf_0 ) ); memset( buf_1, 0, sizeof( buf_1 ) ); i = strlen( argv[1] ) / 2; readhexstring( argv[1], buf_0, i ); for ( i = 0; i & sizeof( buf_0 ); i++ ) { fprintf( stderr, &%02X&, buf_0 ); } fprintf( stderr, &\n& ); str_to_key( buf_0, buf_1 ); str_to_key( buf_0 + 7, buf_1 + 8 ); str_to_key( buf_0 + 14, buf_1 + 16 ); for ( i = 0; i & sizeof( buf_1 ); i++ ) { fprintf( stderr, &%02X&, buf_1 ); } fprintf( stderr, &\n& ); return( EXIT_SUCCESS ); } /* end of main */ --------------------------------------------------------------------------
☆ 如何从明文口令生成LM Hash
假设明文口令是&Welcome&，首先全部转换成大写，再做如下变换
&WELCOME& -& D0000
也就是说在明文口令不足14字节的情况下，后面添加0x00补足14字节。有些书上介绍 添加空格(0x20)补足14字节，这是错误的，我不清楚是原作者写错了，还是译者的问 题。
然后切割成两组7字节的数据，分别经str_to_key()函数处理得到两组8字节数据
D45 -str_to_key()-& 56AA 00 -str_to_key()-& 0000
这两组8字节数据将做为DESKEY对魔术字符串&KGS!@#$%&进行标准DES加密
&KGS!@#$%& -& 4B25
56AA -对4B25进行标准DES加密-& CE7665F 0000 -对4B25进行标准DES加密-& AAD3B435B51404EE
将加密后的这两组数据简单拼接，就得到了最后的LM Hash
LM Hash: CE7665FAAD3B435B51404EE
显然，由于明文口令一开始就全部转换成大写，导致多个明文口令对应一个LM Hash。 反过来，在穷举破解LM Hash时，得到的有可能不是原始口令，因为不可能确定大小 写。仔细观察前述SMB身份验证过程，即使这里得到的不是
原始口令(大小写有差别)， 同样可以通过SMB身份验证。这种转换成大写的行为减小了穷举破解强度。
另一个弱点，当明文口令小于8字节时，LM Hash后8字节的计算过程总是这样的
00 -str_to_key()-& 0000 -对4B25进行标准DES加密-& AAD3B435B51404EE
这也将减小穷举破解强度。
IBM设计了这个LM Hash算法，魔术字符串&KGS!@#$%&的意义无从考证。这个算法称之 为&哈希&不怎么妥当，由于是标准DES加密，完全是可逆的。当然，由于要穷举的是 DESKEY本身，与传统所说的可逆有区别。
☆ 标准DES加密
这里不会重复DES的历史，Bruce Schneier所著&&应用密码学(第二版)&&值得一看。 事实上我们在自己编程时使用了书中附录里的DES例子代码。该书英文电子版未在互 联网上正式流传，尤其包含附录代码的配套磁盘被限制在北美地区以外出现，google 还是留下了它们。tombkeeper从google网页快照中恢复了该书英文版全部章节并制做 了一份chm文件，包括所有源代码，只是少了图。我不得不佩服这个变态的精力旺盛， 尽管后来他又从苏联人的地下站点上找到了该书更完整的内容，比如图。
本篇不打算涉及DES算法的C语言描述，microcat(lgx)为我写了这个临时测试程序用 于验证某些概念
-------------------------------------------------------------------------- /* * For x86/FreeBSD 4.5-RELEASE * gcc -Wall -pipe -O3 -o des_test des_test.c -lcrypto * * key : 01 23 45 67 89 AB CD EF * cipher : C9 57 44 25 6A 5E D3 1D * plain : 01 23 45 67 89 AB CD E7 */ #include &stdio.h& #include &stdlib.h& #include &openssl/des.h&
int main ( int argc, char * argv[] ) {
des_key_ /* * typedef unsigned char des_cblock[8]; * typedef unsigned char const_des_cblock[8]; */ const_des_cblock key = { 0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF, }; const_des_cblock plain_0 = { 0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xE7, }; des_cblock plain_1; des_
printf( &key : & ); for ( i = 0; i & 8; i++ ) { printf( &%02X%c&, key, i == 7 ? &\n& : & & ); } des_set_key_unchecked( &key, ks ); des_ecb_encrypt( &plain_0, &cipher, ks, DES_ENCRYPT ); printf( &cipher : & ); for ( i = 0; i & 8; i++ ) { printf( &%02X%c&, cipher, i == 7 ? &\n& : & & ); } des_ecb_encrypt( &cipher, &plain
_1, ks, DES_DECRYPT ); printf( &plain : & ); for ( i = 0; i & 8; i++ ) { printf( &%02X%c&, plain_1, i == 7 ? &\n& : & & ); }
return( EXIT_SUCCESS ); } /* end of main */ --------------------------------------------------------------------------
☆ 如何从明文口令生成NTLM Hash
IBM设计的LM Hash算法存在几个弱点，微软在保持向后兼容性的同时提出了自己的挑 战响应机制，NTLM Hash应运而生。
假设明文口令是&123456&，首先转换成Unicode字符串，与LM Hash算法不同，这次不 需要添加0x00补足14字节
&123456& -&
从ASCII串转换成Unicode串时，使用little-endian序，微软在设计整个SMB协议时就 没考虑过big-endian序，ntoh*()、hton*()函数不宜用在SMB报文解码中。0x80之前 的标准ASCII码转换成Unicode码，就是简单地从0x??变成0x00??。此类标准ASCII串 按little-endian序转换成Unicode串，就是简单地在原有每个字节之后添加0x00。
对所获取的Unicode串进行标准MD4单向哈希，无论数据源有多少字节，MD4固定产生 128-bit的哈希值，16字节
-进行标准MD4单向哈希-& 32ED87BDB5FDC5E9CBAD4
就得到了最后的NTLM Hash
NTLM Hash: 32ED87BDB5FDC5E9CBAD4
与LM Hash算法相比，明文口令大小写敏感，无法根据NTLM Hash判断原始明文口令是 否小于8字节，摆脱了魔术字符串&KGS!@#$%&。
MD4是真正的单向哈希函数，穷举做为数据源出现的明文，难度较大。
问题在于，微软一味强调NTLM Hash的强度高，却避而不谈一个事实，为了保持向后 兼容性，NTLMHash缺省总是与LM Hash一起使用的。这意味着NTLM Hash强调再高也是 无助于安全的，相反潜在损害着安全性。增加NTLM Hash后，首先利用LM Hash的弱点 穷举出原始明文口令的大小写不敏感版本，再利用NTLM Hash修正出原始明文口令的 大小写敏感版本。
Phrack Magazine 50-08(参考资源[10])中提供的源程序根据NTLM Hash挂字典穷举明 文口令。我们推荐LC4。
☆ 标准MD4单向哈希
Ron Rivest设计的MD4算法固定产生128-bit的哈希值。尽管其理论上存在某些弱点， 但那是密码学家、数学家眼中的弱点，或者是NSA(美国国家安全局)所拥有计算能力 下的弱点，当然在分布式计算逐渐盛行的今天，也许还存在其它角度的弱点。除此三 者之外，MD4用来生成NTLM Hash，强度足够了。遗憾的是算法本身的强度不能保证整 个NTLM Hash验证机制的安全性。
Bruce Schneier所著&&应用密码学(第二版)&&中对MD4做了介绍。我们在自己编程时 使用了1999年挖自Tripwire Project的MD4实现代码。本篇不打算涉及MD4算法的C语 言描述，microcat(lgx)为我写了这个临时测试程序用于验证某些概念
-------------------------------------------------------------------------- /* * For x86/FreeBSD 4.5-RELEASE * gcc -Wall -pipe -O3 -o md
4_test md4_test.c -lcrypto * * plain : 31 00 32 00 33 00 34 00 35 00 36 00 * md4 : 32 ED 87 BD B5 FD C5 E9 CB A8 85 47 37 68 18 D4 */ #include &stdio.h& #include &stdlib.h& #include &openssl/md4.h&
int main ( int argc, char * argv[] ) {
unsigned char md4[16]; unsigned char plain[] = { 0x31, 0x00, 0x32, 0x00, 0x33, 0x00, 0x34, 0x00, 0x35, 0x00, 0x36, 0x00, };
printf( &plain : & ); for ( i = 0; i & sizeof( plain ); i++ ) { printf( &%02X%c&, plain, i == ( sizeof( plain ) - 1 ) ? &\n& : & & ); } MD4( plain, sizeof( plain), md4 ); printf( &md4 : & ); for ( i = 0; i & sizeof( md4 ); i++ ) { printf( &%02X%c&, md4, i == ( sizeof( md4 ) - 1 ) ? &\n& : & & ); }
return( EXIT_SUCCESS ); } /* end of main */ --------------------------------------------------------------------------
☆ SMB报文中使用的是DES LM Hash和DES NTLM Hash
大量中英文档在转述L0pht的资料，LC4系列在GUI上没有区分LM Hash、NTLM Hash与 DES LM Hash、DES NTLM Hash，加上转述者表达方式各不相同，引起一些概念上的混 淆。SMB报文中并不直接使用原始的LM Hash、NTLM Hash，而是对之进行了标准DES加 密。
假设有如下原始数据，虽然生成算法不同，但两个Hash值都是16字节长。挑战来自网 络传输，一般出现在SMB_COM_NEGOTIATE(0x72)响应报文的encryption key字段，固 定长8字节。
LM Hash -& 44EFCE164AB921CAAAD3B435B51404EE NTLM Hash -& 32ED87BDB5FDC5E9CBAD4 Challenge -& E439
在LM Hash后添加五个0x00补足21个字节，再用str_to_key()处理成24字节，每8字节 一切割，得到三组DESKEY。利用这三组DESKEY分别对8字节挑战进行标准DES加密
44EFCE164AB921CAAAD3B435B50000 | str_to_key() | V 54E442CA54B47642ACD0000000
DESKEY1 -& 54E442 -对E439进行标准DES加密-& 6DA05CC936C0D9B9 DESKEY2 -& CA54B47642ACD428 -对E439进行标准DES加密-& 37DE DESKEY3 -& 0000 -对E439进行标准DES加密-& F38669E
将所得三组数据简单拼接就得到了24字
节的DES LM Hash(响应)
DES LM Hash -& 6DA05CC936C0D9B937DEF38669E
出现在SMB_COM_SESSION_SETUP_ANDX(0x73)请求报文的CaseInsensitivePassword字 段中。
在NTLM Hash后添加五个0x00补足21个字节，再用str_to_key()处理成24字节，每8字 节一切割，得到三组DESKEY。利用这三组DESKEY分别对8字节挑战进行标准DES加密
32ED87BDB5FDC5E9CBAD | str_to_key() | V DAAEF68AE8E4EA105438DCD00000
DESKEY1 -& DAAEF68A -对E439进行标准DES加密-& 19C4336ACBBB62DD DESKEY2 -& E8E4EA105438DCD0 -对E439进行标准DES加密-& C6903 DESKEY3 -& 186A -对E439进行标准DES加密-& 4BA9D
将所得三组数据简单拼接就得到了24字节的DES NTLM Hash(响应)
DES NTLM Hash -& 19C4336ACBBB62DDCB807F8A9D
出现在SMB_COM_SESSION_SETUP_ANDX(0x73)请求报文的CaseSensitivePassword字段 中。
这实际上是两组24字节响应的生成算法。
☆ 观察一个实例
在192.168.5.150(x86/FreeBSD 4.5-RELEASE)上执行
./smbclient -L &WIN2000-RD& -I 192.168.5.101 -U test (test的口令是123456)
其中&WIN2000-RD&用nbstat -A 192.168.5.101获得
WIN2000-RD &20& UNIQUE Registered
这是来自L0pht/LC4的***信息
DES LM Hash -& 6DA05CC936C0D9B937DEF38669E DES NTLM Hash -& 19C4336ACBBB62DDCB807F8A9D Challenge -& E439
这是来自&pwdump4.exe 192.168.5.101&的输出，先用Administrator建立SMB会话
net use \\192.168.5.101\IPC$ &password& /user:Administrator
test:1014:44EFCE164AB921CAAAD3B435B51404EE:32ED87BDB5FDC5E9CBAD4:::
LM Hash -& 44EFCE164AB921CAAAD3B435B51404EE NTLM Hash -& 32ED87BDB5FDC5E9CBAD4
192.168.5.101是一台x86/PWindows 2000。
LC4和pwdump4.exe在网上很多，用google一搜就出来了，我测试的时候是tombkeeper 提供的。smbclient就是Samba Team的Samba Project中的那个。
☆ negotiate response解码
192.168.5.8(x86/EWindows XP) 192.1
68.5.101(x86/PWindows 2000 SP3) ------------+--------------- --------------+--------------------- | | +------------------------------------+ | | 192.168.5.12(x86/PWindows 2000) | --------------+---------------- | | +------------------------------------+ | ------------+--------------------------------------- 192.168.5.150(x86/FreeBSD 4.5-RELEASE + samba-2.2.5)
网络结构如上，我们从192.168.5.150上执行如下命令
smbclient -I 192.168.5.12 -L RESEARCH12 -U &RESEARCH12\test&
输入明文口令&123456&，成功返回。用Ethereal 0.9.7 For Windows抓包观察
-------------------------------------------------------------------------- TCP层
Source port: 139 Destination port: 1039 Sequence number:
Next sequence number:
Acknowledgement number:
Header length: 32 bytes Flags: 0x0018 (PSH, ACK) 0... .... = .0.. .... = ..0. .... = Urgent: Not set ...1 .... = Acknowledgment: Set .... 1... = Push: Set .... .0.. = Reset: Not set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 17276 Checksum: 0x20ce (correct) Options: (12 bytes) NOP NOP Time stamp: tsval 1357667, tsecr
Message Type: Session message (0x00) Flags: 0x00 .... ...0 = Add 0 to length Length: 119 (0x0077)
SMB层 (Server Message Block Protocol)
SMB Header Server Component: 0xFF SMB SMB Command: Negotiate Protocol (0x72) Error Class: Success (0x00) Reserved: 00 Error Code: No Error Flags: 0x88 1... .... = Request/Response: Message is a response to the client/redirector .0.. .... = Notify: Notify client only on open ..0. .... = Oplocks: OpLock not requested/granted ...0 .... = Canonicalized Pathnames: Pathnames are not canonicalized .... 1... = Case Sensitivity: Path names are caseless .... ..0. = Receive Buffer Posted: Receive buffer has n
ot been posted .... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported Flags2: 0x0001 0... .... .... .... = Unicode Strings: Strings are ASCII .0.. .... .... .... = Error Code Type: Error codes are DOS error codes ..0. .... .... .... = Execute-only Reads: Don&t permit reads if execute-only ...0 .... .... .... = Dfs: Don&t resolve pathnames with Dfs .... 0... .... .... = Extended Security Negotiation: Extended security negotiation is not supported .... .... .0.. .... = Long Names Used: Path names in request are not long file names .... .... .... .0.. = Security Signatures: Security signatures are not supported .... .... .... ..0. = Extended Attributes: Extended attributes are not supported .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response Reserved:
Tree ID: 0 Process ID: 4225 User ID: 0 Multiplex ID: 1 Negotiate Protocol Response (0x72) Word Count (WCT): 17 (0x11) Dialect Index: 7, greater than LANMAN2.1 (索引从0开始，这里对应NT LM 0.12) Security Mode: 0x03 .... ...1 = Mode: USER security mode .... ..1. = Password: ENCRYPTED password. Use challenge/response .... .0.. = Signatures: Security signatures NOT enabled .... 0... = Sig Req: Security signatures NOT required Max Mpx Count: 50 Max VCs: 1 Max Buffer Size: 16644 Max Raw Buffer: 65536 Session Key: 0x Capabilities: 0x0000f3fd .... .... .... .... .... .... .... ...1 = Raw Mode: Read Raw and Write Raw are supported .... .... .... .... .... .... .... ..0. = MPX Mode: Read Mpx and Write Mpx are not supported .... .... .... .... .... .... .... .1.. = Unicode: Unicode strings are supported .... .... .... .... .... .... .... 1... = Large Files: Large files are supported .... .... .... .... .... .... ...1 .... = NT SMBs: NT SMBs are supported .... .... .... .... .... .... ..1. .... = RPC Remote APIs: RP
C remote APIs are supported .... .... .... .... .... .... .1.. .... = NT Status Codes: NT status codes are supported .... .... .... .... .... .... 1... .... = Level 2 Oplocks: Level 2 oplocks are supported .... .... .... .... .... ...1 .... .... = Lock and Read: Lock and Read is supported .... .... .... .... .... ..1. .... .... = NT Find: NT Find is supported .... .... .... .... ...1 .... .... .... = Dfs: Dfs is supported .... .... .... .... ..1. .... .... .... = Infolevel Passthru: NT information level request passthrough is supported .... .... .... .... .1.. .... .... .... = Large ReadX: Large Read andX is supported .... .... .... .... 1... .... .... .... = Large WriteX: Large Write andX is supported .... .... 0... .... .... .... .... .... = UNIX: UNIX extensions are not supported .... ..0. .... .... .... .... .... .... = Reserved: Reserved ..0. .... .... .... .... .... .... .... = Bulk Transfer: Bulk Read and Bulk Write are not supported .0.. .... .... .... .... .... .... .... = Compressed Data: Compressed data transfer is not supported 0... .... .... .... .... .... .... .... = Extended Security: Extended security exchanges are not supported System Time: Jul 26, :52. Server Time Zone: -480 min from UTC Key Length: 8 (指明Server Challenge的字节长度) Byte Count (BCC): 50 (0x32 0x00，SMB层使用little-endian序) Encryption Key: 46B0F8AB (这实际上是Server Challenge) Primary Domain: WORKGROUP Server: RESEARCH12
56 41 42 03 00 10 5a 84 7a f0 08 00 45 00 .PVAB...Z.z...E. 0010 00 af fc 02 40 00 80 06 72 53 c0 a8 05 0c c0 a8 ....@...rS......
00 8b 04 0f dc 5b c4 73 aa 13 a7 38 80 18 .......[.s...8.. c 20 ce 00 00 01 01 08 0a 00 14 b7 63 01 83 C| ..........c.. c 00 00 00 77 ff 53 4d 42 72 00 00 00 00 88 .....w.SMBr.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 01 00 11
07 00 03 32 00 01 00 04 41 ..........2....A
00 00 01 00 00 00 00 00 fd f3 00 00 40 ad ..............@.
47 34 c2 01 20 fe 08 32 00 46 b0 f8 ab 00 +&G4.. ..2.F....
86 57 00 4f 00 52 00 4b 00 47 00 52 00 4f 3P.W.O.R.K.G.R.O 00a0 00 55 00 50 00 00 00 52 00 45 00 53 00 45 00 41 .U.P...R.E.S.E.A 00b0 00 52 00 43 00 48 00 31 00 32 00 00 00 .R.C.H.1.2... --------------------------------------------------------------------------
当使用LM/NTLM验证机制时，negotiate response报文中包含了Server Challenge。
☆ session_setup_andx request解码
-------------------------------------------------------------------------- NBT层
Message Type: Session message (0x00) Flags: 0x00 .... ...0 = Add 0 to length Length: 164 (0x00a4)
SMB层 (Server Message Block Protocol)
SMB Header Server Component: 0xFF SMB SMB Command: Session Setup AndX (0x73) NT Status: STATUS_SUCCESS (0x) Flags: 0x08 0... .... = Request/Response: Message is a request to the server .0.. .... = Notify: Notify client only on open ..0. .... = Oplocks: OpLock not requested/granted ...0 .... = Canonicalized Pathnames: Pathnames are not canonicalized .... 1... = Case Sensitivity: Path names are caseless .... ..0. = Receive Buffer Posted: Receive buffer has not been posted .... ...0 = Lock and Read: Lock&Read, Write&Unlock are not supported Flags2: 0xc001 1... .... .... .... = Unicode Strings: Strings are Unicode .1.. .... .... .... = Error Code Type: Error codes are NT error codes ..0. .... .... .... = Execute-only Reads: Don&t permit reads if execute-only ...0 .... .... .... = Dfs: Don&t resolve pathnames with Dfs .... 0... .... .... = Extended Security Negotiation: Extended security negotiation is not supported .... .... .0.. .... = Long Names Used: Path names in request are not long file names .... .... .... .0.. = Security
Signatures: Security signatures are not supported .... .... .... ..0. = Extended Attributes: Extended attributes are not supported .... .... .... ...1 = Long Names Allowed: Long file names are allowed in the response Reserved:
Tree ID: 0 Process ID: 4225 User ID: 0 Multiplex ID: 1 Session Setup AndX Request (0x73) Word Count (WCT): 13 AndXCommand: No further commands (0xff) Reserved: 00 AndXOffset: 0 Max Buffer: 65535 Max Mpx Count: 2 VC Number: 4225 Session Key: 0x ANSI Password Length: 24 (指明DES LM Hash的字节长度) Unicode Password Length: 24 (指明DES NTLM Hash的字节长度) Reserved:
Capabilities: 0x .... .... .... .... .... .... .... ...0 = Raw Mode: Read Raw and Write Raw are not supported .... .... .... .... .... .... .... ..0. = MPX Mode: Read Mpx and Write Mpx are not supported .... .... .... .... .... .... .... .1.. = Unicode: Unicode strings are supported .... .... .... .... .... .... .... 0... = Large Files: Large files are not supported .... .... .... .... .... .... ...1 .... = NT SMBs: NT SMBs are supported .... .... .... .... .... .... ..0. .... = RPC Remote APIs: RPC remote APIs are not supported .... .... .... .... .... .... .1.. .... = NT Status Codes: NT status codes are supported .... .... .... .... .... .... 0... .... = Level 2 Oplocks: Level 2 oplocks are not supported .... .... .... .... .... ...0 .... .... = Lock and Read: Lock and Read is not supported .... .... .... .... .... ..0. .... .... = NT Find: NT Find is not supported .... .... .... .... ...0 .... .... .... = Dfs: Dfs is not supported .... .... .... .... ..0. .... .... .... = Infolevel Passthru: NT information level request passthrough is not supported .... .... .... .... .0.. .... .... .... = Large ReadX: Large Read andX is not supported .... .... .... .... 0... .... .... .... = Large WriteX: Large Write andX is no
t supported .... .... 0... .... .... .... .... .... = UNIX: UNIX extensions are not supported .... ..0. .... .... .... .... .... .... = Reserved: Reserved ..0. .... .... .... .... .... .... .... = Bulk Transfer: Bulk Read and Bulk Write are not supported .0.. .... .... .... .... .... .... .... = Compressed Data: Compressed data transfer is not supported 0... .... .... .... .... .... .... .... = Extended Security: Extended security exchanges are not supported Byte Count (BCC): 103 ANSI Password: 154E0DE15A54BCE37FD9C8CDE93E (DES LM Hash) Unicode Password: D611B7C5DBE8EA849FDBBAA60A956EB906D509 (DES NTLM Hash) Account: TEST Primary Domain: RESEARCH12 Native OS: Unix Native LAN Manager: Samba
5a 84 7a f0 00 50 56 41 42 03 08 00 45 00 ..Z.z..PVAB...E. 0010 00 dc d9 d5 40 00 40 06 d4 53 c0 a8 05 96 c0 a8 ....@.@..S...... c 04 0f 00 8b aa 13 a7 38 dc 5b c4 ee 80 18 .........8.[....
7f 15 00 00 01 01 08 0a 01 83 93 fe 00 14 ................
00 00 00 a4 ff 53 4d 42 73 00 00 00 00 08 .c.....SMBs.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 01 00 0d ff 00 00 00 ff ff 02 00 81 ................
00 00 00 18 00 18 00 00 00 00 00 54 00 00 .............T..
00 15 4e 0d e1 5a 54 bc 54 00 8d 80 18 8e .g..N..ZT.T..... 0090 37 fd 9c 8c de 93 e6 96 1c 69 15 d6 11 b7 c5 db 7........i...... 00a0 e8 ea 84 9f db ba a6 0a 95 6e 95 07 8d 16 f0 b9 .........n...... 00b0 06 d5 09 00 54 00 45 00 53 00 54 00 00 00 52 00 ....T.E.S.T...R. 00c0 45 00 53 00 45 00 41 00 52 00 43 00 48 00 31 00 E.S.E.A.R.C.H.1. 00d0 32 00 00 00 55 00 6e 00 69 00 78 00 00 00 53 00 2...U.n.i.x...S. 00e0 61 00 6d 00 62 00 61 00 00 00 a.m.b.a... --------------------------------------------------------------------------
当使用LM/NTLM验证机制时，session_setup_andx reque
st报文中包含了DES LM Hash 以及DES NTLM Hash。
根据前面的种种分析，现在我们有如下数据可供研究LM/NTLM验证机制
-------------------------------------------------------------------------- Password : 123456 :
Password DESKEY1 : A8D800 Password DESKEY2 : 0000 Magic String : 4B25 LM Hash : 44EFCE164AB921CAAAD3B435B51404EE NTLM Hash : 32ED87BDB5FDC5E9CBAD4 Server Challenge : 46B0F8AB LM DESKEY1 : 54E442 LM DESKEY2 : CA54B47642ACD428 LM DESKEY3 : 0000 DES LM Hash : 154E0DE15A54BCE37FD9C8CDE93E NTLM DESKEY1 : DAAEF68A NTLM DESKEY2 : E8E4EA105438DCD0 NTLM DESKEY3 : 186A DES NTLM Hash : D611B7C5DBE8EA849FDBBAA60A956EB906D509 --------------------------------------------------------------------------
LM/NTLM验证机制是缺省的、最广泛使用的SMB验证机制。了解这种验证机制有助于拓 展SMB攻击/防御的思路，也为我们后续的SMB DoS、SMB Remote Buffer Overflow研 究做一铺垫。
DES NTLM Hash总是与DES LM Hash一起使用，而且只要这二者之一通过验证即可，这 意味着DES NTLM Hash形同虚设。
NSFocus Security Team的袁哥 &&在2000年曾提出一种新的SMB 攻击思路，充分利用LM/NTLM验证机制本身的脆弱性(直接比较DES LM/NTLM Hash)以 及Windows SMB客户端的一个特性(主动发送本机当前登录用户凭证)。具体技术细节 参看袁哥于2000年在NSFocus技术论坛的发言。在SMB系列的后续文章中我们会就一些 类似的攻击技术做一比较、总结。
NTLMv2验证机制将在SMB系列(6)中做详细介绍。它增加了双向验证机制，使得一些常 规会话劫持攻击、中间人攻击更加难以完成。
Kerberos验证机制在实际环境中应用不广，暂时搁在一旁。
出于某些原因，我们刻意省略了对NTLMSSP协议的解码分析过程，将与NTLMv2验证机 制一并介绍。
就SMB协议分析过程来看，MS Network Monitor不可靠，Sniffer Pro略优，Ethereal 最强。由于Ethereal可以打开前两者生成的CAP文件，因此可以结合起来使用。
本文撰写过程中得到RSAS开发小组中lgx以及NSFocus安全研究小组中tombkeeper、 yuange的大力支持，在此表示万分感谢。向参考资源中文章的各位作者顺致敬意，尤 其是[4]。
☆ 参考资源
[1] L0phtcrack 1.5 Lanman / NT password hash cracker http://www.insecure.org/sploits/l0phtcrack.lanman.problems.html
[2] command line prompts for DES http://mhonarc.
.au/list-jce/msg00380.html
[3] [VulnWatch] SunPCi II VNC weak authentication scheme vulnerability http://www.attrition.org/security/advisory/misc/tf.sunpci_ii_vnc http://www.der-keiler.de/Mailing-Lists/Securiteam/5.html
[4] http://islab.oregonstate.edu/documents/ftpsites/wimsey/DES/triple-DES (cool)
[5] [jcifs] Quick LM Hash question http://lists.samba.org/pipermail/jcifs/2002-April/002094.html
[7] CIFS: Common Insecurities Fail Scrutiny http://signaltonoise.net/library/cifs.htm
[8] BoS: Windows NT authentication weakness http://www.tao.ca/writing/archives/security/0343.html
[9] NT Domain Authentication Protocol http://bugtraq./dir.1997-10/msg00008.html
[10] Phrack Magazine 50-08: Cracking NT Passwords /phrack/50/P50-08
[14] Samba Stuff /samba-stuff.html
[15] SMB authentication when CAP_EXTENDED_SECURITY negotiated http://www.iss.net/security_center/static/3325.php
[21] Ethereal User&s Guide V1.1 for Ethereal 0.9.7 /docs/user-guide/
请各位遵纪守法并注意语言文明
