samb的密码认证方式 为什么samb认证会泄露密码？

Windows访问139端口时自动用当前用户、密码连接，造成泄露用户密码，虽然其密码是加密的，但一样可以用来攻击。

下面是SMB的密码认证方式。

WINDOWS的139口的访问过程，箭头表示数据方向：

1.客户端<--------------------建立tcp连接----------------->服务端

2.客户端-------客户端类型、支持的服务方式列表等---------->服务端

3.客户端<---------服务器认证方式、加密用的key等-----------服务端

认证方式就是用户级认证还是共享级认证和密码加密不，key是服务器随机生成的8个字节，WIN2000已经支持16个字节的 key。

4.客户端--------------用户名、加密后密码----------------->服务端

WIN9X、WINNT、WIN2000这有个漏洞，不经过提示等就把当前用户名，密码加密后发过去了，导致密码泄漏。这儿加密是DES的变形，lockedpass=chgdes(key,pass)。这儿的pass是作为DES变形的KEY，key是作为DES变形的待加密数据。

5.客户端<---------------认证成功否-----------------------服务端

WINDOWS客户端第4步有漏洞，显然服务端可以得到username和lockedpass=chgdes(key,pass), 其中key可以自由指定，因为这是服务方提供的，usname、pass是客户端当前访问者用户名和密码。这儿的加密变换不可逆，但已经可以用暴力法破解了，也已经有了这样的程序。其实我们有时并不一定要得到密码明文的，只要能提供连接需要的就可以了。我们来看得到lockedpass有什么用，我们反过去访问看看，telnet、ftp等连接要密码明文我们得到的lockedpass不能提供，那么我们考虑用同样加密算法传密码密文的服务呢?比如就是NETBIOS共享服务。前面是服务端得到东西，那现在就是站在客户端了，再看前面那过程，显然其实我们并不需要提供pass,是不是只需要提供username和lockedpass2=chgdes(key2,pass)就可以了?其中key2是现在的服务端提供的。看看我们有 usname和lockedpass=chgdes(key,pass)其中key我们可以自己指定，大家一看显然只要key=key2那么就需要的我们都有了是不是?所以我们要使得key=key2.

好我们再仔细看看连接过程，别人连接两步1、2：

1.客户端<--------------------建立tcp连接----------------->服务端

2.客户端-------客户端类型、支持的服务方式列表等---------->服务端

下面就该

3.客户端<---------服务器认证方式、加密用的key等-----------服务端

这我们需要提供key,这儿我们不能随便提供key,需要提供key2,那么我们就要得到key2,显然需要连接NETBIOS服务回去。显然这而需要连接回去的11，22，33共3步(为了区分连接回去的步子用重号表示)才能得到key2，显然这2步和3步不需要有先后顺序。所以我们可以得到连接指定IP的NETBIOS服务然后等这用户来访问，这可能有时间超时等处理，或者等到任意IP连接NETBIOS服务后马上连回去，反正怎么处理方便、满足需要就怎么处理。

下面显然就是设置 key=key2返回3，那就等4得到lockedpass了，第5步嘛就你自由处理了，要不返回密码错误，后面就是44、55……

总的来就是1，2，11，22，33，3，4，5，44，55……显然你就是以那机器访问你的用户的身份去访问他的NETBIOS服务了，能干什么那就看那用户的权限了。

注意有兴趣的可以把SAMB包的客户端程序修改加上一点服务的前几步就可以了。显然这主要利用的还是WINDOWS泄露当前用户名、加密密码漏洞。还有这需要别人来访问你的机器，这好办，邮件或者主页等里面来个

IMGsrc”="file://ip/filename" ...

就可以了。我实验了去掉机器139口服务(要不有139口要影响后面端口重定向)，用端口重定向程序把来向139口定向回去，找另一个WINNT机器用

file://ip/访问那重定向139口的机器，结果是没有密码提示就看到WINNT机器本身了。其实这时重定向端口程序那台机器已经用WINNT机器的当前用户访问WINNT了，只是由于没有客户端的处理界面不能操作。