Windwos 2003下的权限提升

信息来源:古典辣M°的书房

前几天渗透了某大型网站,兴奋中。拿到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这个扩展,本文的方法就不管用了,不过这样的管理员到目前我还没遇到过。总之,整体安全才是最重要的。不要放过每一个细节。

作者: 放手
来 源: 《黑客防线》