標籤：

解析.DS_Store文件格式

04-29

這篇文章會講解該文件的生成方式以及如何利用其在Alexa Top 1000中的網站中發現我們感興趣的文件，比如：.sql/.db/.swp/.tgz。

介紹

我們先對這一篇文章做一個簡單的介紹以及我是如何看待蘋果公司的文件格式的。如果你想直接閱讀關於技術的部分，請跳過這一板塊，進入到下一部分當中。大概兩年前，在對web伺服器上敏感文件做研究時，我遇到了一個名為.DS_Store的文件。然後我就使用GO語言掃描Alexa Top1000的網站是否存在這一文件，並且從這一文件中發現網站的問題。但是Go語言沒有針對.DS_Store文件的解析器，而python中存在，但是解析器並沒有正常的工作，並且我想要的是在Go語言中調用一個函數或者類去解決這一問題，而不是使用其他語言之外的東西。

因此，我認為在Go語言中實現這一功能是一個不錯的練習機會，會讓我GO語言的功底提升不少，經過努力，終於實現了，最終代碼地址:github.com/gehaxelt/ds_ 。不過有點尷尬的是，我在寫代碼的過程中並沒有加註釋，所以讀起來有點吃力。

在去年萊比錫舉行的34C3大會上，我和一位同事決定再次研究一下這一格式文件。並且目前為止，我們已經完成了，我感覺我應該向大家分享一下我的收穫。由於我不能完全理解我兩年前寫的代碼，於是我又開始深入到了細節當中，並且決定在python環境下實現解析器。

到現在，我仍然記不起來當時得到的一些細節上的東西，但是新的解析器應該具有相同的功能，並且我現在會嘗試去介紹文件格式。

什麼是.DS_Store文件？

在解析.DS_Store文件之前，我先告訴你一些關於它的信息。你能從使用MACOS系統的同事U盤的隱藏文件中發現他，或者在其他的地方你也見過。蘋果的操作系統會在每一個文件夾中產生這個文件記錄這個文件夾中的相關信息。實際上，這一文件包含了文件夾中所有的文件名和子文件夾名。和windows相比，等同於desktop.ini和Thumbs.db兩個文件。

由於.DS_Store這一文件前面包含了一個「.」所以他在文件夾中是以隱藏文件的格式存在的。MacOS用戶也許並沒有發現他的存在。並且在網上並沒有太多關於它的介紹文檔。

如何去解析.DS_Store文件

我不是第一個去寫這一文件解析器的人，所以我不想聲明這一點，我想說的是為它寫解析器是一個很好的學習經驗，我藉助了以下資源去學習它：

https://wiki.mozilla.org/DS_Store_File_Format http://search.cpan.org/~wiml/Mac-Finder-DSStore/DSStoreFormat.podhttps://digi.ninja/projects/fdb.php

我建議閱讀完上方三個資料之後在閱讀這篇文章，這樣會對這一文件有一個粗略的了解。

無論如何，讓我們開始吧，我下面會用一個實例的.DS_Store文件來解釋它的結構，解析器的工作步驟同理。

文件頭部

這是大端格式下的文件頭部佔用的36個位元組:

前四個位元組的整數總是0x01,是用來做對齊方式的，所以他是在文件最頭部的。藍色部分被稱為魔術位元組(0x42756431)。

兩個紅色的部分是四個位元組的整數(0x1000),用來定義文件的根塊的位置(偏移量),根塊是用來去解析其他文件的信息。這兩個偏移量必須是相同的值，否則該文件會被視為無效。之前的綠色的四個位元組整數是表示前面提到的根塊的大小。

剩餘的16個灰色位元組並沒有被反轉，可以被認為是不確定數據，所以解析器可以直接跳過他。

根塊介紹

我們現在了解到了根塊的基本信息:位置和大小。我們可以在0x1004至0x1804之間進行探索。值得注意的是我們使用先前獲得位置時要附加上塊對齊的0x04.

相關文件名的信息存儲在樹狀結構當中，其中根塊包含關於樹以及其他塊的重要元數據，通常元數據可以被分為三個不同的部分：

1. 偏移部分2. 內容表3. 空閑表

偏移部分

偏移部分包含有關文件中樹(葉)塊的偏移量信息，這些塊存儲的都是目錄的實際信息，如文件名。獲得偏移量需要遍歷這個樹。

藍色整數(0x03)告訴我們需要去讀多少偏移量，跳過四個灰色位元組(總是為0)，接下來的12個綠色位元組是三個4位元組整數，構成了偏移量列表:

0x0000100B0x000000450x00000209

這三個數字的順序很重要，因為我們會根據這些變數去索引訪問。這些偏移量是文件中樹的塊位置。該部分的剩餘位元組都是用0進行填充的(紅色位元組)，並且填充到0x140c。

內容表

在偏移部分結束後，內容表部分就會呈現出來。他通常存在只有一個名為DSDB的表,並且值為1。這個特殊的表通常引用了我們將要遍歷的第一個塊的ID。

紅色位元組來自偏移量部分的填充，並且TOC從0x140c開始，四個藍位元組表示要解析的TOC的數量。在我們的例子中，只有一個。後面跟著一個綠色的位元組，表示TOC(tables of content)的名稱長度為0x04個位元組。TOC名稱可以通過黃色標記的自己的作為ASCII字元串來檢索。在名稱後面，紫色的四個位元組就是TOC存儲的值。

綜上，可以將TOC表示為:

[DSDB]=0x01

空閑表

最後一部分是空閑表，也就是在樹中還有哪些地方是沒有使用的或者是空閑的模塊。在實踐中，我沒有使用空閑表中的任何一個變數，但是在其他情況下可能會有用。

它包含了通過2^n（0，31）定義的字典變數，在上圖的例子中，空閑表的開端是0x1419。藍色的四個位元組整數代表一個部分已經被讀取。這個整數代表著我們需要讀取的偏移量。

在上圖hexdump界面中，前五個部分的地址是0x1419到0x142d，其中存了0個元素。在0x142d之後的第六個部分的值是0x02,所以我們讀出兩個元素:0x00000020和0x00000060。

在進行相同的步驟之後，我們得到了空閑隊列類似於:

{1: [],2: [],4: [],8: [],16: [],32: [32, 96],64: [],128: [128],256: [256],512: [],1024: [1024],2048: [2048, 6144],4096: [],8192: [8192],16384: [16384],32768: [32768],65536: [65536],131072: [131072],262144: [262144],524288: [524288],1048576: [1048576],2097152: [2097152],4194304: [4194304],8388608: [8388608],16777216: [16777216],33554432: [33554432],67108864: [67108864],134217728: [134217728],268435456: [268435456],536870912: [536870912],1073741824: [1073741824],2147483648: []}

解析完這三個部分之後，我們關於根塊的工作已經完成，接下來就是解析關於樹的工作了。

樹

正如我之前所說的，信息在文件當中成樹狀排列。我們需要遍歷這個樹來獲取在文件中存儲的文件名和其他信息。

塊號和偏移量

在之前，我已經說過內容表中是存在塊號的，特別是DSDB內容表中通過它的塊號對第一個塊進行引用，然後對內容表進行遍歷。在我們這個例子中，塊號是0x01.

我們通過塊號作為索引從我們之前的列表中獲取地址，比如：

offsets[0x01] => 0x00000045

但是我們無法利用0x00000045這個位置簡單的計算出我們想要得到的數據，因為真正的偏移量以及塊的大小是通過這一個值進行編碼的:

1. 2^k 其中k是5個最低有效位，表示塊的大小。應該小於32個位元組2. 當5個最低有效位全部設置為0時，表示塊的偏移量。

使用實例地址0x00000045進行計算，我們得到了下面的結果:

1. 偏移量: int(0x00000045) >> 0x5 << 0x5 = 0x402. 大小:1 << (int(0x00000045) & 0x1f) = 0x20

於是，塊號為1的塊起始位置為0x40+0x4=0x44,大小為0x20位元組。

解析樹

為了得到文件名，我們需要從樹的根塊去解析。在之前的描述中，DSDB內容表中記錄的是第一個根塊的塊號，並且它開始於0x44位置。

這個塊包含了五個整數，其中紅色部分是最有趣的，因為它包含了具有實際數據的第一個塊的塊號。其他顏色的整數意思是：

綠色:內部塊的級別(0x00)黃色:樹中存在多少記錄(0x06)藍色:樹中的塊數(0x01)棕色:不變的值(0x1000)

於是對0x02這個塊進行解析，然後遍歷整個樹就可以得到文件名。

數據塊的地址是

offsets[0x02] => 0x00000209

通過解析,可以獲得:

1. 偏移量:int(0x00000209) >> 0x5 << 0x5 = 0x200

2. 大小:1 << (int(0x00000209) & 0x1f) = 0x200

得到數據塊的起始位置是0x204,繼續通過hexdump追蹤：

塊中包含了兩個重要的整數:

紅色：塊模式（0x00）綠色：記錄數量(0x06)

如果模式為0x00，則緊接著是計數記錄。否則，跟隨下一塊ID的記錄對，其中遍歷函數可以通過下一個塊的塊號進行遞歸調用。

因為我們的實例塊處於模式0x00,因此只需要解析0x06記錄。

記錄

現在讓我們看看在塊中的記錄是什麼樣子的。

記錄以藍色位元組(文件名長度)以及黃色位元組(文件名)開始。文件名之後是一個四個位元組整數(棕色)，代表著結構號(現在我還不確定這個是幹啥的)，之後表示的是結構類型(紅色)。根據結構的不同，在到達當前塊末尾之前，需要跳過不同數量的位元組。可以在search.cpan.org/~wiml/M找到不同結構類型對應的數量。

一旦解析完成，六個文件名就會呈現出來:

favicon.icoflagstatictemplatesvulnerable.pyvulnerable.wsgi

代碼

我會給大家分享我這幾年寫的代碼，不過並不能保證代碼不存在bug，也不能保證這是一份完美的代碼。我之前也提到過，這不是我第一次寫這一類型的解析器，以及代碼也是基於工作研究的成果，並且功能也許不是很完整。非常歡迎大家提出問題和進行修復！

如果你想挑戰一下，你可以在下面兩個鏈接找到相應的版本:

https://github.com/gehaxelt/ds_storehttps://github.com/gehaxelt/Python-dsstore

如果你只是想簡單的解析一下文件，你只需使用web版本進行解析：

labs.internetwache.org/

已知的問題

在開發代碼和寫博客的過程中，發現了我在實現代碼和解析邏輯上面的一些問題。我想在這簡單的討論一下。也許你會找到解決辦法！

根塊偏移量

我遇到過一個.DS_STORE文件，其中根塊與最初的頭部解析的偏移量向後推了4個位元組。這就導致後面的步驟出錯。這是一個非常罕見的事情，我不知道它是由於什麼原因發生的。

文件名長度不正確

我遇到的另一個問題就是記錄中文件名長度有錯誤，例如，它顯示的長度為0x0a(10*2個位元組)，但是UTF-16文件名實際上大於20個位元組。通常這會導致無法匹配結構類型，然後產生錯誤。使用hexeditor修改為正確的長度就可以修復這一錯誤。但是我還是不確定這種很明顯的錯誤是如何發生的。

儘管如此，我已經採用了類似暴力破解的方式解決這一問題:重新讀取文件名的後兩個位元組，知道出現已知的結構號。雖然採用這種方法解決了這個問題，但我覺得它並不是一個好方法。

它會帶來什麼安全影響?

到目前為止，我們只討論了.DS_Store文件的結構和內容，但是這是一個關於安全的博客，所以我下面要說的是他會帶來什麼安全影響。當這一文件上傳到了web伺服器時，往往會帶來一定的危害。

在我看來，它帶來的危害是他包含的文件名。MacOs在幾乎所有文件夾都創建了一個.DS_Store文件。

信息泄漏(敏感文件)

通過我參與的Internetwache.org網站項目，對Alexa Top 1000的網站的根目錄進行掃描，證明在有的網站中的確存在這一文件，導致信息泄漏。通過解析這一文件，我們發現了資料庫備份，配置文件，以及一些緩存文件，甚至是密鑰。

你可以在en.internetwache.org/sc這裡查看具體的信息。

如何檢測並且保護好自身呢？

需要澄清的一個事實是存儲在.DS_Store文件中的文件名僅代表本地MacOS系統上的目錄內容。這就意味著解析出來的文件列表中有些文件可能不存在。

你可能會在以下幾種情況下上傳這一文件:

1. 將文件提交給版本控制系統(git/svn/etc)2. 未刪除這一文件，就使用rsync/sftp上傳到伺服器中。3. 伺服器系統也許就是MACOS

如果你想現在檢測你的伺服器是否處在危險當中，你可以執行以下命令（linux）:

cd /var/www/ #wherever your webservers document root is find . -type f -iname "*.DS_Store*"

這一命令就是在/var/www/文件夾下找到.DS_Store文件，然後列印出他們的位置。

如果你沒有找到任何文件，說明你的伺服器是安全的。如果你找到了文件，那麼你可以對他們進行刪除。

另外，你可以通過設置你的伺服器去禁止這些文件訪問:

Apache下，在http.conf文件中加入以下代碼:

<Files ~ ".DS_Store$"> Order allow,deny Deny from all</Files>

Nginx下，在server block中添加以下代碼：

location ~ .DS_Store$ { deny all;}

本文翻譯自：0day.work/parsing-the-d 如若轉載，請註明原文地址： 4hou.com/technology/107 更多內容請關注「嘶吼專業版」——Pro4hou

推薦閱讀：

※看我如何打造Android滲透測試環境
※探索影響Android的6個內核漏洞
※SRC們
※惡意軟體Ursnif的隱蔽進程注入技術分析
※Masuta : Satori開發者的第二個殭屍網路，利用新的路由器漏洞實現武器化

TAG:信息安全 |