Windows系统网络邻居的内幕(3)

　　四、共享技巧

　　1.有些人给共享名加个$，以达到隐藏的效果，可这用DOS下的net share是可被看到的；

　　这种隐藏只是微软Windows标准客户端net view的限制，不是服务端的限制，网络传输过程中是一视同仁的，所以直接修改客户端解除这种限制或者使用第三方客户端软件均可看到所谓的隐藏共享，比如smbclient就是典型代表。

　　2.有些人给共享加上密码，可听说这也是有办法破解的

　　这个破解要看是什么层面上的，纯暴力破解的就不必说了，那当然总是可以的。而9598另有漏洞，就是他那个著名的vredir.vxd，服务端验证密码时所用长度居然是客户端提供的，这就意味着至多猜测256次(事实上没这么多，考虑可打印字符范围)即可进入。当初N多人用这种办法非法浏览别人的机器。2000年报告微软，现在已修补。

　　http://security.nsfocus.net/index.php?act=advisory&do=view&adv_id=6

　　顺便说一句，利用该漏洞可以快速穷举出原始口令，虽然在攻击中这是不必要的。

　　3. 因而我只能根据自己的理解结合netxray的实践来测试，细节部分难免有错，推荐www.ethereal.com提供的Ethereal，这是我所见过的对SMB解码最强的免费软件，有Unix/Windows版，提供源码。

　　4. 在2000中，SMB可以直接运行在tcp/ip上，而没有额外的NBT层，使用TCP 445端口。因此在2000上应该比NT稍微变化多一些。

　　事实上正相反，在ssaxh_capabilities字段中指明不使用"扩展安全验证"，此时使用原有身份验证机制，只需去掉NBT层的Session Request，将139/TCP改成445/TCP，一样可以成功建立空会话，并且成功打开\\IPC$。

　　至于更高层的RPC Over SMB，更是不必作任何变动。换句话说，从139/TCP换到445/TCP，整个通信过程中减少了一对NBT Session Request/Response，后面的报文对于两者来说是完全一致的。

　　而所谓的NBT层，即使在445通信中也未去掉，一直存在着，区别只是上面这段话。

　　5. 如果客户端启用了NBT，那么连接的时候将同时访问139和445端口，微软并没有让139/TCP与445/TCP公平竞争。发起连接的SYN包在宏观上是同时发出的，具体起来，有时是先向139/TCP发起连接请求，有时是先向445/TCP发起连接请求，有点随机性。

　　在向139/TCP发送三次握手的最后一个ACK报文时，Windows顺手携带了数据，这里以一个刻意弄错的NetBIOS名(*SMBSERV<00...(8)>做了一次NBT Session Request。而445/TCP不需要NBT层的会话。

　　由于刻意弄错的NetBIOS名，139/TCP很难竞争过445/TCP。服务端返回Negative NBTSession Response，并且执行了close()操作。这使得必须重新建立到139/TCP的连接(传输层的TCP连接)。

　　可以看出，那个刻意弄错的NetBIOS名仅仅是为了给445/TCP制造抢先的机会。遗憾的是，445/TCP不争气，这个端口上的任务繁重、负载较高，即使在这种不公平竞争的情况下，139/TCP仍有可能重新抢在445/TCP之前建立NBT会话(注意，不是TCP连接)。于是445口会回送RST，后续SMB会话建立在139/TCP连接之上。

　　微软自己的操作系统不认"*SMBSERV<00...(8)>"，但是Samba Server 2.2.5认，居然返回Positive Session Response。这成为精确识别Samba Server的方法之一。

　　微软在<>中不会提这些的，只是说139/TCP、445/TCP公平竞争，优先使用最早返回的响应报文。不要相信它的鬼话。

　　话说回来，如非需求所致，完全不必关心这种差别。有需求的时候，这种差别是致命的。

　　6. 最明显的就是空会话可以很方便地连接到其他的域，枚举用户、机器等。这也就是扫描软件进行探测的原理。

　　XP、2003缺省禁止在空会话上进行PolicyAccountDomainInformation查询，可以看到LsarOpenPolicy2(44)失败，权限否定。如果事先指定有效帐号、口令建立SMB会话，而非空会话，LsarOpenPolicy2(44)将成功返回。