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