前几天渗透了某大型网站，高兴中。拿到WebShell后，第一个念头就是提升权限，把偶亲爱的后门挂到系统里。熟练的打开CMD，输入NET USER。 不是好兆头，接着在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这个扩大，本文的方法就不管用了，不过这样的管理员到目前我还没遇到过。总之，整体安全才是最重要的。不要放过每一个细节。