文件泄露, 根據泄漏的信息敏感程度, 在WEB漏洞中可以算是中危甚至高危的漏洞, 本篇文章就來
介紹下一些常見的泄漏, 主要分爲由版本管理軟件導致的泄露, 文件包含導致的泄露和配置錯誤導致的泄露.
版本管理軟件造成的泄露
git
git可以說是當今最受歡迎的版本控制/版本管理軟件了, 很多基於git的雲端託管倉庫都提供了
免費的託管服務, 甚至有不少還支持免費私有倉庫, 如bitbucket和國內的gitosc(開源中國)等.
關鍵文件
git在初始化項目的時候, 會在項目的根目錄(可用git rev-parse --show-toplevel查看)創建一個名爲
.git的隱藏文件夾, 裏面包含了本地所有commit的歷史記錄. 如果無意間將這個目錄置於WEB的路徑下讓用戶可以訪問,
那麼也就泄露了幾乎所有的源代碼和其他其他敏感信息.
泄露內容
- 所有該項目的源代碼
- 私有倉庫的地址
- 私密的配置信息
- 所有commiter的郵箱帳號信息
- (可能)內部的帳號和密碼
- ...
利用方法
常規的利用方法就是下載整個目錄, 然後用git命令回滾整個項目:
wget -r --no-parent --mirror http://www.example.com/.git
cd www.example.com && git reset --hard
當然也有一些自動化利用的腳本:
- dvcs-ripper: 基於perl的工具,除了git還支持很多版本管理系統
- GitHack
修復建議
一般基於MVC的現代WEB框架都不會直接掛載文件, 但如果是基於PHP,ASP等語言的項目, 還是會存在安全隱患,
雖然可以通過配置WEB服務器(apache/nginx等)來拒絕對.git路徑的訪問, 但也會出現被意外繞過的風險.
最好的辦法就是在項目新建一個www目錄來存放源代碼文件.
hg/Mercurial
Mercurial的意思是水銀, 所以縮寫成hg(汞), 也是一個版本管理軟件. 用法和git有點類似, 但也保留了svn命令簡明的特點,
而且原生地支持Windows/MacOS/Linux三大平臺, 不像git需要MinGW才得以運行, 所以當今也有不少人偏向於用hg做版本控制.
關於他們有一些討論, 如爲什麼要用hg,
爲什麼選hg而不是git等等, 我認爲也是值得了解的.
關鍵文件
與git類似, hg在初始化項目時, 會在項目的根目錄下創建一個名爲.hg的隱藏文件夾,
裏面包含了代碼和分支的修改記錄和開發人員的相關信息.
泄露內容
- 項目源代碼
- 項目倉庫地址
- (可能)倉庫的用戶名
- 其他
利用方法
手動利用, 下載+回滾:
wget -r --no-parent --mirror http://www.example.com/.hg
cd www.example.com && hg revert
也可以用上面提到的dvcs-ripper工具來利用
修復建議
同git
svn/Subversion
svn, 即Subversion, 在github之前曾經也是炙手可熱的版本管理工具, 雖然已經日漸式微, 但在很多國企,
研究院等地方依然是作爲版本管理的主要工具. 對於一些歷史悠久的項目, 比如LLVM, 出於歷史原因,
也是主要使用svn管理源代碼.
關鍵文件
svn同樣在項目根目錄下會創建一個名爲.svn的隱藏文件夾, 包含了所有分支commit信息和代碼記錄.
泄露內容
- 所有該項目的源代碼
- svn倉庫的地址
- svn倉庫所屬用戶的用戶名
- ...
利用方法
同樣是先下載目錄, 然後回滾:
wget -r --no-parent --mirror http://www.example.com/.svn
cd www.example.com && svn revert --recursive .
工具&腳本:
- dvcs-ripper: 支持舊版和新版的svn
- Seay-Svn: 法師的工具,基於Windows平臺
修復建議
同git
bzr/Bazaar
bzr也是個版本控制工具, 雖然不是很熱門, 但它也是多平臺支持, 並且有不錯的圖形界面,
所以也有一些人認爲bzr比git要好用,
只是對於滲透測試人員來說, 其實都無所謂就是了.
關鍵文件
bzr在初始化項目時(bzr init/init-repo), 會在項目根目錄產生名爲.bzr的隱藏目錄, 同樣暴露了源代碼和用戶信息.
泄露內容
- 源代碼
- 倉庫地址
- 開發者的信息
- ...
利用方法
沒用過bzr工具, 不過查詢文檔得知可用bzr revert命令來進行回滾:
wget -r --no-parent --mirror http://www.example.com/.bzr
cd www.example.com && bzr revert
當然dvcs-ripper工具也是可以的.
修復建議
同git
cvs
CVS是一個年代比較久遠的版本控制系統, 通過它可以追蹤源代碼的歷史變化記錄.
但是因爲功能比較簡單, 而且不支持分支, 所以很早前就被上面提到的svn替代了.
關鍵文件
cvs項目在初始化(cvs checkout project)的時候, 會在project目錄下創建一個名爲CVS的目錄,
其中保存了各個文件的修改和commit記錄. 通過此目錄可以獲取代碼的歷史版本. 其中兩個關鍵文件爲:
CVS/Root和CVS/Entries, 分別記錄了項目的根信息和所有文件的結構
泄露內容
因爲是純客戶端的工具, 所以只會泄露源代碼
利用方法
下載CVS文件夾然後通過cvs命令獲取源碼信息, 不過似乎沒有直接的回滾操作, 需要做點額外的處理.
wget -r --no-parent --mirror http://www.example.com/CVS
cd www.example.com && cvs diff *
或者直接用工具dvcs-ripper
修復建議
如果你還在用CVS, 沒準你還在用perl寫cgi吧? ...
其他
版本管理工具有很多, 除了上面提到的這些, 還有曾經比較知名的如BitKeeper, 現在已經很少用了,
不過偶爾還是會在CTF比賽中炸屍.
文件包含導致的泄露
除了上述版本管理工具所導致的泄露外, 配置不當也是導致信息泄露的重要原因之一.
.DS_Store文件泄露
.DS_Store(Desktop Services Store)是macOS目錄下的隱藏文件, 包含了當前目錄結構和一些的自定義信息,
如背景和圖標位置等, 在windows下類似的文件爲desktop.ini. 暴露了.DS_Store文件也就相當於暴露了該目錄下的所有內容.
可以說是比較嚴重的泄露.
利用方法
.DS_Store的格式爲二進制, 內部數據結構爲Proprietary格式,
可以自行解析並遞歸下載所有文件, 參考lijiejie的ds_store_exp.
修復建議
使用macOS開發的同學, 可以把.DS_Store加入忽略列表中(如.gitignore), 但本質上其只是泄露目錄結構, 就算刪掉.DS_Store,
文件也依然存在於web服務器可以訪問得到的地方, 所以治本的方法還是不要將敏感信息放在web路徑中.
WEB-INF泄露
在Java的Servlet 文檔中,
說到WEB-INF目錄"包含了所有web應用會用到但是不處於web路徑中的資源", 也就是說, WEB-INF目錄下的內容是不屬於公開頁面的.
web應用可以通過getResource等API在servlet的上下文中訪問到這些資源.
通常開發者會把許多JSP文件,Jar包,Java的類文件放在該目錄下. 一般目錄的內容都是可以預測的:
WEB-INF/web.xml : Web應用程序配置文件, 描述了servlet和其他的應用組件配置及命名規則.
WEB-INF/database.properties : 數據庫配置文件
WEB-INF/classes/ : 一般用來存放Java類文件(.class)
WEB-INF/lib/ : 用來存放打包好的庫(.jar)
WEB-INF/src/ : 用來放源代碼(.asp和.php等)
利用方法
通過web.xml文件推測應用組件相關類的名字, 然後在src目錄下查找代碼, 如果沒有源代碼可以直接下載class文件反編譯即可.
修復建議
發佈前確認WEB-INF目錄是禁止訪問的, 或者在server設置好對於的過濾規則.
備份文件泄露
備份文件泄露又分爲兩種情況, 一種是運維人員偷懶地直接在網站根目錄用類似tar -czvf bakup.tgz *的命令將網站進行備份,
這樣整站的源代碼都能直接被用戶打包下載了； 另一種是開發或者運維人員使用的編輯器修改文件時自動備份了所編輯的網頁內容,
如vim的.swp, 從而泄露了該網頁的源代碼.
利用方法
對於打包文件而言, 滲透測試人員可以用{常用文件名}+{常用壓縮包後綴}的方式掃描網站, 說不定會有意外驚喜.
對於網頁的臨時備份文件, 可以掃描對應頁面的.swp或者.bak等後綴, 說不定也能找到有用的信息.
修復建議
做好版本管理, 並利用版本管理工具過濾掉這些類型的文件, 同時不要直接在生產環境中修改或者添加文件.
配置文件泄露
現代WEB開發往往不會重新造輪子, 而是基於成熟的框架進行配置, 如果滲透測試人員知道該網站是基於什麼類型的框架,
就可能通過該框架的文檔獲得重要配置文件的路徑, 如果是開源框架, 同時也能獲得源代碼, 因此配置文件泄露的嚴重性也是不言而喻的.
利用方法
通過識別網站指紋得知其框架類型, 然後手工測試重要的配置文件是否可以獲取. 如果是批量測試, 則可以事先準備好
常見的配置文件路徑, 如wordpress的/wp-config.php等, 組織成字典然後用腳本進行批量測試. 可以參考豬豬俠的字典.
修復建議
修改配置文件的默認路徑, 同時在服務器端阻止對這些路徑的訪問.
配置錯誤導致的泄露
Windows IIS / Apache 目錄穿越
目錄穿越漏洞原理比較簡單, 程序在實現上沒有充分過濾用戶輸入的../之類的目錄跳轉符, 導致惡意用戶可以訪問web根目錄的上級從而遍歷服務器上的任意文件.
雖然web服務器本身會禁止訪問web文件夾以外的地方, 但如果是智障開發引入的動態頁面, 又沒有過濾好用戶輸入, 就可能會出現穿越甚至目錄遍歷.
甚至web服務器本身也曾經有類似的漏洞, 比如Apache Tomcat的UTF-8解析漏洞, 具體利用和繞過可以參考其他網上的文章, 這裏限於篇幅就不展開了.
Nginx配置安全
Nginx的配置選項之多,並不是所有人都能熟悉,但不表示隨便百度一下複製粘貼就配置了,最好還是先看下官方文檔對應選項的作用和用法,
可以避免許多致命的錯誤. 例如Nginx在代理靜態文件時, 如果不小心在配置文件中寫錯了一個字符:
location /static {
alias /home/web/static/;
}
就會導致訪問http://example.com/static../時可以訪問上級目錄, 從而訪問到敏感的信息.
關於nginx配置安全, 離別歌的這篇文章其實寫得很不錯, 值得每個開發和運維人員仔細瞭解.
後記
敏感信息泄露時有發生, 而且通常會造成不可預知的危害. 本文討論了一些文件泄露的例子, 可以說是信息泄露的一個子集.
文件泄露很大程度上是由於人的粗心導致, 因此最好的預防辦法就是規範開發部署流程, 儘量減少人爲操作引入的失誤.
引用豬豬俠的一句話:"我們面對的對手都是信息挖掘和資源整合的高手,他們只要贏一次,我們就永遠輸了."
參考文章:
歡迎交流, 轉載請保留出處.
博客地址: https://evilpan.com/