2014-11-03 By jimmy
這算是使用Drupal 9年以來，我碰過最嚴重的漏洞。因為漏洞是匿名使用者可以直接攻擊資料庫，在 Drupal.org 公佈這個安全漏洞後，等於是 0 Day 攻擊最好的時機。
沒想到後續還真的由 Drupal.org 發布「發現大規模的自動化攻擊」，只要在發佈時間7小時內沒升級 Drupal 7 或 Patch 漏洞，都可能被自動化工及掃到，進而埋藏後門。
更悲劇的是，因為後門可以輕易埋藏在資料庫（執行PHP）、程式碼（網站任何資料夾沒有做PHP執行防護）、系統資料夾（如果Server權限沒有設好，可以開新Script來Listen Port），因此最安全的方式，就是找回台北時間 10/16 早上 7:00 前的備份，進行網站程式碼及資料庫回復。
萬一沒有 Patch 並未在時間前套用，難道就完了嗎？好在有人把整起災害的損傷評估，製作了一張非常完整的流程圖：
Made by Bevan
This flowchart is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
除了強烈建議進行上述災害損傷評估外，以下幾個Tip，或許對此災情有所幫助：
- Drupal 6 雖然不受影響，但如果有用 DBTNG 模組 for Drupal 6，一樣會受到此損害
- 在恢復備份的網站之前，建議可以用 Hacked! 模組掃描一下Code，看看是否被埋入精彩的Script（掃不到不代表沒有後門）
- 針對核心檔案竄改紀錄的手工版 script
- drush dl drupal-7.xx （需要同樣的 Drupal 版本）
diff -uZbwrq <舊drupal網站> <剛剛下載的drupal>
- drush dl drupal-7.xx （需要同樣的 Drupal 版本）
- 針對 File modify time，查看過去被變更的檔案
- find . -mtime -start -mtime -end
example:
find . -mtime -3 -mtime -4
- find . -mtime -start -mtime -end
想針對未來防範未然，有以下幾個策略可供減低後門執行風險：
- md5check 模組: 將所有程式碼保護，檢測是否被竄改（注意僅適用在Production Env）
- 將 Database 可執行 PHP 的模組關閉，例如 PHP filter
- 分離web server execute owner 和 website file owner，確保被滲透進入時，網頁檔案不容易被竄改（hacker僅能新增檔案）
- 禁止非法的 PHP 透過網頁直接執行，nginx for Drupal from perusio ，就有預帶這個防護
以上，希望各個Drupal網站都能安然渡過此難關...
