滲透-svn源代碼泄露漏洞綜合利用

SVN是Subversion的簡稱，是一個開放源代碼的版本控制系統，相較於RCS、CVS，它採用了分支管理系統，它的設計目標就是取代CVS。互聯網上不少版本控制服務已從CVS遷移到Subversion。

不少網站都使用了svn版本控制系統，可是不少網站安全意識不足，致使svn殘留，所以咱們可使用這個工具來下載網站源碼。

一旦網站出現SVN漏洞，其危害遠比SQL注入等其它常見網站漏洞更爲致命，由於黑客獲取到網站源代碼後，一方面是掠奪了網站的技術知識資產，另外一方面，黑客還可經過源代碼分析其它安全漏洞，從而對網站服務器及用戶數據形成持續威脅。

更嚴重的問題在於，SVN產生的.svn目錄下還包含了以.svn-base結尾的源代碼文件副本(低版本SVN具體路徑爲text-base目錄，高版本SVN爲pristine目錄)，若是服務器沒有對此類後綴作解析，黑客則能夠直接得到文件源代碼。

---

1、.svn 目錄

使用svn checkout後，項目目錄下會生成隱藏的.svn文件夾（Linux上用ls命令看不到，要用ls -al命令）。

svn1.6及之前版本會在項目的每一個文件夾下都生成一個.svn文件夾，裏面包含了全部文件的備份，文件名爲  .svn/text-base/文件名.svn-base 

svn1.7及之後版本則只在項目根目錄生成一個.svn文件夾，裏面的pristine文件夾裏包含了整個項目的全部文件備份

 

下面我以svn1.7及以後版本爲例，講解如何利用此漏洞下載整個網站源代碼

2、分析.svn目錄內容

咱們看到的是一個名爲 wc.db 的文件，用文本編輯器打開看到第一行有寫  SQLite format 3  ，能夠知道，這是一個SQLite數據庫的文件，後面包含的信息，文本編輯器就先不看了。咱們下載一個正經的SQLite查看軟件來慢慢看－－SQLite Studio 。

在軟件下載完以前，再看看此文件夾裏的其餘內容：

entries和format文件裏面，只有個數字12，沒什麼參考意義；wc.db-journal文件是空的，也沒什麼價值；tmp目錄裏面也是空的；

pristine裏面內容就多了，一堆00~ff的文件夾，每一個文件夾裏有若干個 .svn-base文件；用文本編輯器打開看一下，有些文件是代碼，有些文件是亂碼（大概是圖片文件吧）。看來這個文件夾是整個項目文件的一份備份，只是一堆哈希過的文件名，彷佛有點難下手啊。

畢竟是無規律的這一堆文件名，40位的哈希（36^40）這樣的暴力窮舉下載的話，即使是N多線程，時間成本上也是很是大的啊。並且獲得是一堆無序文件，要整理成原來代碼項目的樣子，還得費好一陣功夫。

這樣看來，是否是說.svn漏洞利用的價值不多？然而非也，少年，還記得剛纔說的 wc.db 文件嗎。如今SQLite Studio軟件應該下載好了，咱們就打開看看這裏有什麼來頭吧

3、wc.db文件，有你想要的一切

用SQLiteStudio軟件打開 wc.db文件，咱們看到 NODES 表，看到 local relpath欄 和 checksum欄，明白了嗎（滑稽.jpg）。checksum欄裏的$sha1$後面的那串數字就是pristine文件夾裏的那堆文件的文件名，pristine裏的00~ff文件夾，實際上是文件名的前兩位，而local relpath就是原始的文件名。

如今，咱們根據這個 wc.db 的NODES表，遍歷這個表裏的每一行，就能夠下載到整個項目裏的代碼了，並且還能獲得對應的真實文件名，可謂豈不快哉？

（下面截圖爲我本身的項目，僅做參考）

除了NODES表之外，還能夠看到一個 REPOSITORY表，裏面存儲了svn的項目路徑和 uuid，若是沒有作訪問IP限制的話，你能夠直接使用此信息取得此項目的SVN權限（下載、提交等）…

4、漏洞修復

方案1、不要使用svn checkout和svn up更新服務器上的代碼，使用svn export（導出）功能代替。

方案2、服務器軟件（Nginx、apache、tomcat、IIS等）設置目錄權限，禁止訪問.svn目錄

不僅svn，git或者其餘版本管理軟件也存在相似的問題