|
前几天渗透了某大型网站兴奋中拿到WebShell后第一个念头就是提升权限把偶亲爱的后门挂到系统里熟练的打开CMD输入NET USER 不是好兆头接着在WSCRIPT组件前打钩再次执行NET USER 提示倒是换了但是结果一样接着偶想到了上传CMDEXE但是Windows 的上传在默认时是有限制的不能大于K于是我上传了经典的ServU本地溢出程序使用在Windows 下没有禁用WSCRIPT时的无敌调用提权大法 其实就是在调用CMD的地方写上本地溢出程序的路径及参数一般在没有禁止WSCRIPT组件时此法的成功率很高但是结果依然是禁止访问看来Windows 在默认情况下安全性比Windows 默认时要强许多失望之余想到干脆去首页挂个马吧最近正在玩PcShare嘿嘿跑到首页加入偶的木马代码点保存没有权限偶倒！太BT了吧？连修改首页的权限都没？管理员一定是把IIS用户降低到了GUEST组或者给IIS目录单独设置了一个GUEST组的用户并去掉了修改文件的权限上帝太不公平了怎么说都是偶辛辛苦苦搞来的Shell啊现在一点用都没有！ 没办法看看服务器里有啥好东西吧翻来翻去忽然眼前一亮在某个目录里发现了congifaspx文件写到这里各位以为偶是要使用SA账号通过SQLROOTKIT执行系统命令吧？错偶看过了账号不是SA权限的是PU权限什么都不能做而且也不属于本文的介绍范围偶注意的ASPX这个后缀在默认安装情况下IIS 是支持net的也就是ASPX文件但是在IIS 里ASP和ASPX两个扩展使用的却是个不同的用户角色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这个扩展本文的方法就不管用了不过这样的管理员到目前我还没遇到过总之整体安全才是最重要的不要放过每一个细节 |
