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