Web 有 Path Traversal,Firmware 也有屬於自己的 Archive Path Traversal (!
Zip Slip 類型的漏洞來源是解壓程式沒有確認最終寫入位置位於預期的解壓目錄內,導致攻擊者可以透過控制壓縮檔中的 entry name 直接覆蓋到非預期的資料夾或檔案中,甚至有可能進一步造成任意檔案寫入和 RCE 的風險(見
[1])
舉個例子,假設Firmware 程式把檔案解壓到 /tmp/upload/,而壓縮檔裡面有normal.txt、../../../../tmp/pwned兩個檔案。
經過沒有前處理的解壓器,把 extraction directory 與 entry name 組合:/tmp/upload/../../../../tmp/pwned
正規化後會變成 /tmp/pwned
原先僅能寫入 /tmp/upload/,現在卻逃逸出解壓縮的資料夾,達到類似 path traversal 的效果
舉個簡單的案例說明:
snprintf(dst, sizeof(dst), "%s/%s", extract_dir, entry_name);
write_file(dst, data);
此處的 entry_name 若是完全由 archive 控制,而且沒有額外驗證,就很容易出現 traversal
可以延伸去看的還有:
snprintf / sprintf / strcpy
open / fopen / creat
可以簡單測試像是以下類型的路徑遍歷,或是簡單一點,拿 Payload All the Thing 的腳本去測試
../../tmp/test
..\..\tmp\test
不過其中再 URL Encoding 的部分不一定在 Zip Slip 中可用 e.g., ..%2f..%2ftmp/test
url 相關的payload成立前提只有 entry name 後續還會經過 URL decode,因為一般 ZIP/TAR extractor 不會自動把 %2f 解碼成 /
或是看看絕對路徑 e.g., /etc/config、/tmp/pwned
除了 Path Traversal 類型的處理,Zip Slip 還有一種較為隱蔽的 Symlink Traversal。
即使 entry 本身沒有路徑遍歷的漏洞,也可能透過 symlink 把後續寫入導向 extraction root 之外
例如:
在解壓縮的時候有些rootfs會帶有symlink導向
許多 IoT / embedded Linux 的 rootfs 本身就大量使用 symlink,例如:
若 extractor 允許建立或跟隨 symlink,攻擊者可以建立指向敏感目錄的 symlink,後續 entry 透過該 symlink 寫入,甚至是較核心的 www/、bin/、etc/init.d/ 等位置,可能造成任意檔案寫入,甚至串連其他漏洞達到 RCE。
e.g.,
Entry 1 x -> ../../../../tmp
Entry 2 x/pwned,字串上看起來是 /tmp/extract/x/pwned
但如果 x 是 symlink,實際指向會是 /tmp/pwned)
明天一樣來復現相關的漏洞,前幾天買的二手router到了,不知道有沒有機會搞點實機POC ;)
[1] https://www.cnblogs.com/wh4am1/p/17201960.html
[2] https://github.com/snyk/zip-slip-vulnerability