Tag: security

Posted on

aur-malware-check

Detection and analysis tools for the atomic-lockfile supply-chain attack on the Arch User Repository (AUR), generalized to a campaign-based architecture that handles multiple concurrent and historical attack waves (CHAOS RAT 2025, Russian spam packages, and future campaigns declared via campaigns.json).

簡單的說，有人把惡意代碼放到 AUR 已經沒維護的套件裏面，然後上傳 。所以安裝了以後，就被惡意代碼植入了，也因為是 npm 套件的關係，相依性相對複雜，影響層面也較為廣泛。

社群因應此狀況，開了一個 repository 放檢測腳本：https://github.com/lenucksi/aur-malware-check

使用方法如下

# 安裝 uv
pacman -S uv

# 下載代碼
git clone https://github.com/lenucksi/aur-malware-check.git

# 進入目錄
cd aur-malware-check

# 建立 python venv 環境，並安裝模組
uv sync

# 執行
uv run python -m aur_check --refresh --list

其他使用方法可以參考 repository README.md 裡的 quickstart

如果發現了被植入惡意代碼，可以參考 repository 裡的 What to do If I Infected

  • 保留系統：不要關機，改用可信媒體進行鑑識擷取。
  • 重設所有憑證：Discord、GitHub、npm、Slack、Teams、SSH 金鑰、Vault token、雲端供應商金鑰。
  • 檢查持久化：systemctl list-units --type=service --state=running（查看是否有不明服務）。
  • 檢查 eBPF rootkit：ls -la /sys/fs/bpf/hidden_*
  • 使用可信媒體清理：從 Arch ISO 開機，掛載檔案系統，移除惡意的 systemd 單元。
  • 考慮重裝：rootkit 會讓系統失去可信度。
  • 回報發現：https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/
Posted on

Hash Buster

在 Hackin9 看到這篇：Hash Buster – Why crack hashes when you can bust them?

這篇主要是在說 md5/sha1 是不安全的，透過目前電腦的強大能力，已經是可逆的了。用 Hash-Buster 這工具可以很快逆向取得雜湊前的結果。

安裝 Hash-Buster

方法1

git clone https://github.com/s0md3v/Hash-Buster.git
cd Hash-Buster
make install

方法2

wget https://raw.githubusercontent.com/s0md3v/Hash-Buster/master/hash.py -O /usr/local/bin/buster && chmod +x /usr/local/bin/buster

使用

把雜湊值當參數

buster -s "5e8ff9bf55ba3508199d22e984129be6"

把內有雜湊值的檔案當參數

buster -f with_hashed.txt

找目錄下所有內含有雜湊值的檔案

buster -d /somedir

Python 3 產生 md5 雜湊

import hashlib

print(hashlib.md5('sample'.encode('utf-8')).hexdigest())

結語

這工具蠻方便的，而且很小，但使用時必須要注意的一件事情，裡面的程式主要是使用外部的服務，所以是把雜湊值上傳到外部網站，然後取得結果。若是因為不小心遺忘密碼，那麼在取得結果後，要趕緊進行變更，以防萬一。

Posted on

pip-audit

github 會針對套件去做安全檢核並發出通知或是 pull request，如果本地端想要做這件事，該怎麼做呢？

剛好前幾天看到這篇：How to find third-party vulnerabilities in your Python code ，文章裡就介紹了 pip-audit 這個工具。使用這個工具，就可以對使用的套件來做安全檢核，並給予建議。

安裝方法很簡單，用 pip 安裝就可以

pip install --upgrade pip-audit pip

安裝完成後，就可以使用 pip-audit 指令了。

要對使用的套件檢查，可以用

pip-audit -r requirements.txt

檢查需要花一段時間，檢查後的結果大致會類似這樣子：

Found 1 known vulnerability in 1 package                                              
Name    Version ID             Fix Versions
------- ------- -------------- ------------
urllib3 1.25.11 PYSEC-2021-108 1.26.5

你會看到有幾個已知漏洞，套件的名稱跟修正的版本。

若要即時的修正，pip-audit 也可以做修正。

pip-audit --fix

要注意的是，這個修正只是幫你安裝已經沒有漏洞的版本，requirements.txt 裡還是要自己去修正。

後續思考：

  1. 可以在 CI 流程裡使用 pip-audit 來做安全檢核，避免使用到有漏洞的版本。
  2. 使用 poetry 的話，可以把 pip-audit 列為 dev dependencies ，就不需要在正式環境裡也裝上這工具了。
Posted on

CSRF is dead?

前幾天在 Hacker news 上看到 Scott Helme 寫的這篇 CSRF is (really) dead ，一直沒看。這兩天開始看，一開始 Scott Helme 先提，你應該先看這篇 Cross-Site Request Forgery is dead! ，再回頭來看。


我先看了第一段，心裡納悶這樣怎麼會有什麼危險呢？後來找了另外兩篇中文來看 (加快理解)：

我蠻推第一篇 Huli 寫的文章，寫的很清楚。簡單的說，就是利用 cookie ，當別的網頁裡有嵌入對其他網頁的存取時，會因為 cookie 的關係而有存取權，如果網站沒有做適當的檢查，那麼使用者的資料就有可能遭到竊取或被錯誤的存取。這也是為什麼後來幾乎每套 web framework 都會有 CSRF token 的處理。

回頭來講，Scott Helme 會說 CSRF 死的原因很簡單，就是有了 SameSite cookie，在 2019 年6月以後幾乎各家都支援 SameSite cookie 了 – Can I use samesite cookie? 所以現在只要在 Set-Cookie 時，後面多加 SameSite=Strict 或 SameSite=Lax 就可以避免 CSRF 的風險了。

等到真正普及可能還要一到兩年的時間吧。