遠程分析IIS設置
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
提起微軟公司IIS web服務器的安全問題,很多人立刻就會聯想到那些為人們所稱頌的致命漏洞: UNICODE , CGI 解析, .ida,idq, .Printer遠程溢出等. 這些偉大的漏洞恐怕是我等scriptskidding的最愛了,利用他們可以很輕松的拿到較高的系統權限。但是這篇文章并非是討論這些致命的漏洞的,只是比較詳細的介紹了如何遠程判斷IIS 服務器的各種設置,如目錄權限,認證方法等等,文中有些東西已經很老了,但是新的東西還是值得一看的。 希望本文能夠起到一個拋磚引玉的作用。好了,廢話少說,Go~!
遠程確定目錄權限 讓我們打開一個IIS服務器來看看。在IIS 服務管理器中,選擇一個目錄,看他的屬性 在目錄屬性項有有這么一些選項(日志訪問和索引此資源不計): 腳本資源訪問: 對網站的腳本可以讀取原文件。 讀取 讀取目錄里面的靜態資源。 寫入 用戶可以建立以及刪除資源 目錄瀏覽 用戶可以瀏覽目錄內容。 應用程序設置的執行許可中有三個選項: 無 只能訪問靜態頁面 純腳本 只允許允許腳本 如ASP腳本 腳本和可執行程序 可以訪問和執行各種文件類型 那么,如何確定服務器上面的這些開關設置呢? 別著急,一個一個來。 執行權限 如何確定某個目錄是否開了執行權限呢?很簡單,向服務器發送一個下面得請求: http://iis-server/dir/no-such-file.dll /dir/為要判斷得目錄,no-such-file.dll是隨便取得一個名字,服務器上面沒有這個文件。 服務器對我們得請求會返回一個信息。如果返回的是一個500錯誤: HTTP 500 - 內部服務器錯誤 (Internal Server error) 那么就說明這個目錄的執行權限是開著的。 對于服務器,能不開執行權限的就不要開。特別是虛擬目錄的執行權限,大家想一想UNICODE和二次解碼漏洞的利用過程就明白了。 如果服務器返回的是一個 404 錯誤: HTTP 404 - 未找到文件 那么就說明這個目錄的執行權限沒有開。 寫權限 測試一個目錄對于web用戶是否具有寫權限,采用如下方法: telnet 到服務器的web端口(80)并發送一個如下請求: PUT /dir/my_file.txt HTTP/1.1 Host: iis-server Content-Length: 10 <enter><enter> 這時服務器會返回一個100( 繼續)的信息: HTTP/1.1 100 Continue Server: Microsoft-IIS/5.0 Date: Thu, 28 Feb 2002 15:56:00 GMT 接著,我們輸入10個字母: AAAAAAAAAA 送出這個請求后,看服務器的返回信息,如果是一個 201 Created響應: HTTP/1.1 201 Created Server: Microsoft-IIS/5.0 Date: Thu, 28 Feb 2002 15:56:08 GMT Location: http://iis-server/dir/my_file.txt Content-Length: 0 Allow: OPTIONS, TRACE, GET, HEAD, Delete, PUT, COPY, MOVE, PROPFIND, PROPPATCH, SEARCH, LOCK, UNLOCK 那么就說明這個目錄的寫權限是開著的,反之,如果返回的是一個 403 錯誤,那么寫權限就是 沒有開起來,如果需要你認證,并且返回一個 401(權限禁止) 的響應的話,說明是開了寫權限,但是匿名用戶不允許。 如果一個目錄同時開了”寫”和“腳本和可執行程序”的話,那么web用戶就可以上傳一個程序并且執行它,恐怖哦%^#$!~ 純腳本執行權限 這樣的目錄就太多了。很多不需要給執行權限的目錄也被管理員給了腳本執行權限,我記得在 shotgun的一篇文章里面他說過:最小的權限+最少的服務= 最大的安全 ; 一點也沒有錯。給目錄任何多余的權限都是沒有必要的。判斷一個目錄是否可以執行純腳本文件也很簡單,發送一個如下一個請求: http://iis-server/dir/no-such-file.asp 返回404文件不存在說明有執行權限,返回403則是沒有開。 瀏覽目錄權限 判斷一個目錄是否允許瀏覽可能需要一點點小技巧,但是,在網站的默認首頁(如:default.asp)不存在的話,那么就再簡單不過了。 在瀏覽器里面輸入: http://iis-server/dir/ 如果權限開著的,那么會返回200響應,并且列出當前目錄里面的內容,反之,沒有列出目錄的話就是關了。 但是,如果默認頁面default.asp存在呢?敲入上面的地址就直接打開這個頁面了。別急, WebDAV 里面有一個請求方法叫:PROFIND。這個方法使得我們可以從服務器資源里面得到一些如文件名,創建時間,最后修改時間等等的信息。利用它我們也可以繞過 default.asp 來判斷目錄瀏覽權限的情況, telnet到IIS-server的web端口,發送如下請求: PROPFIND /dir/ HTTP/1.1 Host: iis-server Content-Length: 0 這時,服務器會送回一個207 Multi Status的響應,如果目錄是允許瀏覽的,那么同時會列出目錄里面的資源以及他們的屬性。如果目錄瀏覽不允許,返回的信息就會少的多。目錄瀏覽一般來說只能算是一個低危險等級的漏洞,比如一個images目錄,里面除了圖片沒有別的東西了,那對于服務器的安全就沒有什么危害,但是,如果目錄里面放了一個管理頁面adminpage.asp或者一些數據庫連接信息文件,可能會導致你的服務器拱手相讓給入侵者。 讀權限 判斷這點很容易,發一個帶 txt文件的請求就可以: http://iis-server/dir/no-such-file.txt 如果返回一個 404 文件不存在的響應,就說明讀權限是開著的,反正,返回403錯誤則說明都權限沒有開。早幾年接觸安全的人一定知道 ::$DATA泄露ASP源代碼的漏洞,其實如果一個目錄里面全是asp腳本的話,那么讀權限也可以不用開的,ASP只需要腳本執行權限就可以了。 IIS 認證方法的判斷 這個漏洞是最近才公布出來的,IIS服務器支持匿名訪問,基本認證和使用NTLM方式的windows集成認證,如果客戶端發送一個包含認證信息的請求,IIS就會強行的嘗試用這些認證信息取認證,并且放回不會的響應。這樣我們就能夠確定IIS的認證的配置。 要確定IIS是否支持基本認證,可以telnet到服務器的80端口,發送如下請求: GET / HTTP/1.1 Host: iis-server Authorization: Basic c3lzdGVtOm1hbmFnZXIA 這是一個基本認證的請求,里面包含了一個base 64編碼的用戶ID和PASS,Basic后面那串字符經過base 64解碼以后就是 system:manager 。如果服務器返回一個401信息,則說明基本認證選項是開著的。如果返回200信息,則有2種可能,基本認證選項沒有開或者是服務器存在一個用戶名是 system的用戶名,并且密碼是manager (猜中的話,行大運啦)。 要確定NTLM選項是否開啟則可以向IIS發送如下請求 GET / HTTP/1.1 Host: iis-server Authorization: NegotiateTlRMTVNTUAABAAAAB4IAoAAAAAAAAAAAAAAAAAAAAAA= 同樣,如果返回401消息,則說明支持NTLM,返回200說明不NTLM認證選項沒有開啟。 對于大多數網站來說,這兩種認證方式都是不需要開起來的,他們有可能泄露一些服務器的重要信息。 泄露內部IP地址信息 如果IIS服務器在一個使用NAT的防火墻里面的話,通常都有個內部地址如10.x.x.x。 如果IIS開啟了基本認證選項,那么發送如下一個簡單的請求就可以得到服務器的內部IP: GET / HTTP/1.1 Host: Authorization: Basic c3lzdGVtOm1hbmFnZXIA 服務器將返回一個如下響應: HTTP/1.1 401 Access Denied Server: Microsoft-IIS/5.0 Date: Fri, 01 Mar 2002 15:45:32 GMT WWW-Authenticate: Basic realm="10.1.1.2" Connection: close Content-Length: 3245 Content-Type: text/html 那個10.1.1.2就是機器的內部ip地址,本來realm的值是客戶端提供給的一個主機頭,但這里它是空的,所以IIS就選擇了本機的IP地址來代替。同樣的,利用PROPFIND,WRITE,MKCOL等請求的返回信息,也能泄露主機的一些信息,如我們向服務器提請下面這樣一個請求: PROPFIND / HTTP/1.1 Host: Content-Length: 0 在IIS配置成使用主機名(見后)的情況下,則不會暴露主機的IP地址,但是會暴露NetBIOS名。事實上我們可以利用IIS的認證獲得更多的信息,如所在域的名字,方法是向服務器發送如下帶NTLM認證的請求: GET / HTTP/1.1 Host: iis-server Authorization: NegotiateTlRMTVNTUAABAAAAB4IAoAAAAAAAAAAAAAAAAAAAAAA 服務器會返回一個信息: HTTP/1.1 401 Access Denied Server: Microsoft-IIS/5.0 Date: Fri, 01 Mar 2002 16:24:58 GMT WWW-Authenticate: Negotiate TlRMTVNTUAACAAAADAAMADAAAAAFgoKgeGvyVuvy67U AAAAAAAAAAEQARAA8AAAAUwBDAFkATABMAEEAAgAMAFMAQwBZAEwATABBAAEA DABTAEMAWQBMAEwAQQAEAAwAUwBDAFkATABMAEEAAwAMAFMAQwBZAEwATABB AAAAAAA= Content-Length: 3245 Content-Type: text/html 那一長串字符就包含了主機名和NT所在域的名字的base 64 編碼。 臨時解決方法:在cmd下進入c:\inetpub\adminscripts或者是adminiscript所在目錄執行一下命令 adsutil set w3svc/UseHostName True net stop iisadmin /y net start w3svc 默認應用程序映射判斷 判斷默認映射是否存在比較簡單,這里只簡單的給出了在映射存在的情況下對于相應請求的響應: 擴展名: .printer 請求: http://iis-server/foo.printer 響應: HTTP 500 - 內部服務器錯誤 擴展名:.idc 請求: http://iis-server/foo.idc 響應: code 500 Internal Server Error 擴展名:.idq 請求: http://iis-server/foo.idq 響應碼:200 OK 響應: 找不到 IDQ 文件 D:\dir\\foo.idq 擴展名:.ida 請求: http://iis-server/foo.ida 響應碼:200 OK 響應: 找不到 IDQ 文件 D:\dir\foo.ida 擴展名:.htr 請求: http://iis-server/foo.htr 響應: HTTP 404 - 未找到文件 擴展名:.htw 請求: http://iis-server/foo.htw 響應碼: 200 OK 響應: QUERY_STRING 的格式無效 擴展名:.stm 請求: http://iis-server/foo.stm 響應: HTTP 404 - 未找到文件 擴展名:.shtm 請求: http://iis-server/foo.shtm 響應: HTTP 404 - 未找到文件 擴展名:.shtml 請求: http://iis-server/foo.ida 響應: HTTP 404 - 未找到文件 判斷操作系統是否為個人版本(Professional/Workstation) IIS安裝在windows2000專業版和NT workstation上面時候,同時進行的連接數最大為10個,利用這一點我們可以簡單判斷操作系統版本:創建10個 HTTP 1.1的持續連接,第11個連接請求將放回403錯誤信息。 該文章在 2011/3/14 16:34:24 編輯過 |
關鍵字查詢
相關文章
正在查詢... |