不是好兆头，接着在WSCRIPT组件前打钩，再次执行NET USER。

　　提示倒是换了，但是结果一样。接着偶想到了上传CMD.EXE，但是Windows 2003的上传在默认时是有限制的，不能大于200K，于是我上传了经典的Serv-U本地溢出程序，使用在Windows 2000下没有禁用WSCRIPT时的无敌调用提权大法。

　　其实就是在调用CMD的地方写上本地溢出程序的路径及参数，一般在没有禁止WSCRIPT组件时，此法的成功率很高。但是结果依然是“禁止访问”，看来Windows 2003在默认情况下，安全性比Windows 2000默认时要强许多。失望之余，想到干脆去首页挂个马吧，最近正在玩PcShare，嘿嘿。跑到首页，加入偶的木马代码，点保存，“没有权限”，偶倒！太BT了吧？连修改首页的权限都没？管理员一定是把IIS用户降低到了GUEST组，或者给IIS目录单独设置了一个GUEST组的用户，并去掉了修改文件的权限。上帝太不公平了，怎么说都是偶辛辛苦苦搞来的Shell啊，现在一点用都没有！

　　没办法，看看服务器里有啥好东西吧。翻来翻去，忽然眼前一亮：在某个目录里发现了congif.aspx文件。写到这里各位以为偶是要使用SA账号，通过SQLROOTKIT执行系统命令吧？错，偶看过了，账号不是SA权限的，是PU权限，什么都不能做，而且也不属于本文的介绍范围。偶注意的“ASPX”这个后缀，在默认安装情况下，IIS 6.0是支持.net的，也就是ASPX文件，但是在IIS 6.0里，ASP和ASPX两个扩展使用的却是2个不同的用户角色，ASP使用的是IUSER用户，管理员一般都比较注意这个账号，害怕被提升权限，所以把权限都降低到了GUEST，所以在ASP的WebShell里什么也不能做了。但是网管往往忽略了ASPX！由于.net使用的系统账号是ASPNET，而在默认情况下，这个账号是属于USER组的，这样我们上传一个.NET的后门上去，会以USER组的用户ASPNET执行命令，权限会有很大的提高，就可以提权了！

　　说做就做，立即上传了一个ASPX的后门上去，打开CMD模块执行NET USER。

　　哇哈哈，果然不出偶所料，终于可以执行CMD了！来看看权限，输入“net localgroup guests”。

　　看到了吧？刚才我们在AspWebShell中使用的账号是IUSER_WEBSITE，属于GUESTS组，难怪什么权限都没有呢。再来看一下USERS组。

　　ASPNET就是现在我们的AspxShell使用的账号，权限是USERS，比Guest大好多，嘿嘿！

　　其实这并不算是什么漏洞，只是由于管理员粗心大意造成的隐患而已。算是提升权限的一个思路吧。如果管理员把ASPNET也降低权限，或者删除ASPX这个扩展，本文的方法就不管用了，不过这样的管理员到目前我还没遇到过。总之，整体安全才是最重要的。不要放过每一个细节。