不是好兆頭，接著在WSCRIPT組件前打鉤，再次執(zhí)行NET USER.
提示倒是換了，但是結(jié)果一樣。接著偶想到了上傳CMD.EXE，但是Windows 2003的上傳在默認(rèn)時(shí)是有限制的，不能大于200K，于是我上傳了經(jīng)典的Serv-U本地溢出程序，使用在Windows 2000下沒有禁用WSCRIPT時(shí)的無敵調(diào)用提權(quán)大法。
其實(shí)就是在調(diào)用CMD的地方寫上本地溢出程序的路徑及參數(shù)，一般在沒有禁止WSCRIPT組件時(shí)，此法的成功率很高。但是結(jié)果依然是“禁止訪問”，看來Windows 2003在默認(rèn)情況下，安全性比Windows 2000默認(rèn)時(shí)要強(qiáng)許多。失望之余，想到干脆去首頁掛個(gè)馬吧，最近正在玩PcShare，嘿嘿。跑到首頁，加入偶的木馬代碼，點(diǎn)保存，“沒有權(quán)限”，偶倒！太BT了吧？連修改首頁的權(quán)限都沒？管理員一定是把IIS用戶降低到了GUEST組，或者給IIS目錄單獨(dú)設(shè)置了一個(gè)GUEST組的用戶，并去掉了修改文件的權(quán)限。上帝太不公平了，怎么說都是偶辛辛苦苦搞來的Shell啊，現(xiàn)在一點(diǎn)用都沒有！
沒辦法，看看服務(wù)器里有啥好東西吧。翻來翻去，忽然眼前一亮：在某個(gè)目錄里發(fā)現(xiàn)了congif.aspx文件。寫到這里各位以為偶是要使用SA賬號(hào)，通過SQLROOTKIT執(zhí)行系統(tǒng)命令吧？錯(cuò)，偶看過了，賬號(hào)不是SA權(quán)限的，是PU權(quán)限，什么都不能做，而且也不屬于本文的介紹范圍。偶注意的“ASPX”這個(gè)后綴，在默認(rèn)安裝情況下，IIS 6.0是支持。net的，也就是ASPX文件，但是在IIS 6.0里，ASP和ASPX兩個(gè)擴(kuò)展使用的卻是2個(gè)不同的用戶角色，ASP使用的是IUSER用戶，管理員一般都比較注意這個(gè)賬號(hào)，害怕被提升權(quán)限，所以把權(quán)限都降低到了GUEST，所以在ASP的WebShell里什么也不能做了。但是網(wǎng)管往往忽略了ASPX！由于。net使用的系統(tǒng)賬號(hào)是ASPNET，而在默認(rèn)情況下，這個(gè)賬號(hào)是屬于USER組的，這樣我們上傳一個(gè)。NET的后門上去，會(huì)以USER組的用戶ASPNET執(zhí)行命令，權(quán)限會(huì)有很大的提高，就可以提權(quán)了！
說做就做，立即上傳了一個(gè)ASPX的后門上去，打開CMD模塊執(zhí)行NET USER.
哇哈哈，果然不出偶所料，終于可以執(zhí)行CMD了！來看看權(quán)限，輸入“net localgroup guests”。
看到了吧？剛才我們?cè)贏spWebShell中使用的賬號(hào)是IUSER_WEBSITE，屬于GUESTS組，難怪什么權(quán)限都沒有呢。再來看一下USERS組。
ASPNET就是現(xiàn)在我們的AspxShell使用的賬號(hào)，權(quán)限是USERS，比Guest大好多，嘿嘿！
其實(shí)這并不算是什么漏洞，只是由于管理員粗心大意造成的隱患而已。算是提升權(quán)限的一個(gè)思路吧。如果管理員把ASPNET也降低權(quán)限，或者刪除ASPX這個(gè)擴(kuò)展，本文的方法就不管用了，不過這樣的管理員到目前我還沒遇到過。總之，整體安全才是最重要的。不要放過每一個(gè)細(xì)節(jié)。
