|
|
- 不是好兆头，接着在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这个扩展，本文的方法就不管用了，不过这样的管理员到目前我还没遇到过。总之，整体安全才是最重要的。不要放过每一个细节。
有了实例是不是能看得更懂些了，总之假如想提升权限这些细节是一定要把握的，当然不是要求每个人都做到，只需你有兴趣你就可以去做。
|
|
|
|
|
|
|
|
|
|
