Ps:

    隨著Adobe的源碼被拖,地下應該還流傳著一大批0day用cfm的需謹慎啊~~

    感謝sH牛的深夜指導,么么噠 _: )

    首先不得不提老外的一篇paper,太牛b了.簡直是搞cfm的完美總結,全篇供120+頁. 炸天.

    Go2 – http://www.slideshare.net/chrisgates/coldfusion-for-penetration-testers

    thx2 – Chris Gates

    通常來說,不管怎么樣先搞進CFIDE再說,方法挺多的了,如果你仔細看過上面的paper也能肉眼做web應用的指紋識別了.

    一般說到的方法是通過添加計劃任務引用外部鏈接的code保存到本地來實現拿shell的.具體我?guī)煾档腷log上寫過一篇圖文并茂的科普

    http://hi.baidu.com/justincom/item/1cc8b2f71eb4931ce3e3bd6a

    但是恰恰很多時候 了,比如搞到某dmz,反向壓根不讓你訪問出去,這個思路就無效了.

    話說Getshell的核心思想找可寫可執(zhí)行.依照這個思路結合自己能控制的輸入做了如下幾個嘗試.

    首先引入眼簾的是debug,有調試信息開關意味著我們能獲取到更多信息(如果是和管理員處在相同的工作區(qū)間的話那還是不要打開得好).有debug發(fā)現很快他會記錄到日志的提示.再回到控制臺的日志選項,發(fā)現他是以cfm的某些標簽按格式保存的,以便于后臺查看.試著嘗試做了幾個閉合和寫入的方式,轉換的思路是這樣的.既然他的的添加計劃任務只能訪問localhost的,我們可以通過結合絕對路徑和后臺中的mappings功能將log的絕對地址映射到localhost/xxxx.log來,這樣只要其中包含cfm可解析的代碼就能寫入一個shell了.

    其次,還有可控的地方,那就是database source,在高級設定中有一個log db calls的選項,會將查詢的請求過程記錄到指定路徑,如此可以衍生出兩條思路.

    第一還是依照添加計劃任務的方式來做變通,通過在query中寫入cfm可解析的代碼到log,比如說咱們寫個hello world.

    #a#

    由此可見精通各類語言的hello world是多么的重要.不過這里遇到很 的地方,發(fā)現cf的后臺對請求實際上是有filter的,在查詢的log可以發(fā)現所有的成對出現的尖括號全部被過濾為空了,并且會拋出一個SQL查詢異常.

    于是想嘗試拼RP的方法,所連的庫是msSQL(其他庫也無所謂,有能dump file的函數就拿來用吧),通過cf后臺的Setting Summary能看到是9.0(也就是2005 – 版本對應列表 http://baike.baidu.com/link?url=BAKHdQ6sHg1vrDcUkuDj1L6XAlLy0Kzl-5YzB6UqBpw1IjirWiyGKqZd8LDwJ0gV ),拼RP開始reconfig啟用xp_cmdshell,嘗試echo個txt到wwwroot,很不幸的權限么有那么高.退到db_owner的玩法,log和差異backup都上了,成功寫出了一個txt.這里其實也出了點小問題,因為是黑盒測試,原因到目前為止還沒確定.在log備份中,實際上就只有第一次是成功導出了的,因為web server是IIS,所以最先想到的是寫一個asp,經過多次請求發(fā)現active page的選項其實是關閉的,默認就不解析而返回404.導致之后寫cfm文件的時候都以為是在web server的配置上做了某些策略而導致的404,因其80同時還映射了個tomcat驅動的web應用到另個目錄.經過比對直接將log保存cfm到通過虛擬目錄發(fā)現是可以請求到的,所以最終斷定是dump file的時候出現了某些不明的原因,log中記錄的請求是沒有報神馬異常的.但通常情況下,這種思路的可行性還是有的.

    如果再不幸,你連db_owner都不是,只能讓你select之類的就只能利用他在請求的過程中l(wèi)og到文件來直接寫了.問題似乎又回到了原點,繞過filter的問題,在log備份中,將插入的數據轉成hex再請求是不會報異常的,所以就想著是否能從這點來看他在請求過程中對于最終寫入到log的變化是怎樣的,這里直接引用了老外的poc了,思考問題的方式和方向應該是無誤的.

    在log database calls to file中直接指定以cfm結尾的文件保存路徑.

    同時在query中寫入