說個這幾天在安全圈里發(fā)酵的事Nacos 的 Derby 組件被曝出遠(yuǎn)程命令執(zhí)行漏洞。如果你所在公司用了 Nacos 做配置中心和注冊中心我建議先把手頭的事放一放認(rèn)真看完這篇。Nacos 在微服務(wù)體系里太常用了它管著配置、管著服務(wù)發(fā)現(xiàn)一旦本身出問題影響往往不是單臺機器而是一整片業(yè)務(wù)。這個漏洞的名字也很直白——Nacos Derby 遠(yuǎn)程命令執(zhí)行漏洞攻擊者有機會通過 Nacos 內(nèi)嵌的 Derby 數(shù)據(jù)庫做到在服務(wù)器上執(zhí)行命令。這篇文章不聊花哨的利用技巧重點講清楚它是什么、怎么自查、怎么修復(fù)以及我在實際排查中踩過哪些坑。讀完你至少能知道自己要不要應(yīng)急。1. 漏洞背后的基礎(chǔ)Nacos 與 Derby 各是什么1.1 Nacos 在微服務(wù)架構(gòu)里的定位Nacos 是很多團隊搭建微服務(wù)時繞不開的基礎(chǔ)組件核心職能是兩個配置管理和服務(wù)發(fā)現(xiàn)。配置管理解決的是“配置改一處所有服務(wù)生效”的問題服務(wù)發(fā)現(xiàn)解決的是“哪個服務(wù)實例在哪個地址、健康狀態(tài)如何”的問題。簡單說Nacos 就像整個系統(tǒng)里的“信息中樞”各個服務(wù)啟動時找它拉配置運行中找它拿服務(wù)地址。正因為這個定位Nacos 在安全體系里的重要程度往往被低估。很多人覺得它不過是一個 Java 服務(wù)最多就是配置中心但實際上一旦 Nacos 被攻破攻擊者能看到所有服務(wù)的配置信息包括數(shù)據(jù)庫連接串、緩存地址、各類密鑰和接口開關(guān)。這些東西的價值不亞于直接拿到一臺跳板機。這也是為什么當(dāng) Nacos 出現(xiàn)高危漏洞時安全團隊通常都會按照最高優(yōu)先級處理。我在實際接觸過的一些項目里甚至見過開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境共用同一套 Nacos 的情況。安全團隊明明只暴露了測試環(huán)境的入口但因為三套環(huán)境沒隔離生產(chǎn)配置全部可以被讀取。所以理解 Nacos 的定位再看這個漏洞你會發(fā)現(xiàn)它真正可怕的不是漏洞本身而是 Nacos 在架構(gòu)中聚集了大量敏感信息。1.2 內(nèi)嵌 Derby默認(rèn)數(shù)據(jù)庫的角色Derby 是一個純 Java 編寫的關(guān)系型數(shù)據(jù)庫體積小、部署簡單不需要單獨安裝數(shù)據(jù)庫服務(wù)。Nacos 之所以默認(rèn)選擇 Derby很大程度是為了降低初次使用門檻單機模式下載解壓就能啟動配置存儲這些事由內(nèi)嵌 Derby 自動完成用戶不用管數(shù)據(jù)庫。簡單理解一下這兩層關(guān)系Nacos 是一個 Web 服務(wù)它需要一塊地方保存配置數(shù)據(jù)。在單機模式下這塊地方就是內(nèi)嵌的 Derby 數(shù)據(jù)庫。Derby 不是一個獨立部署的進(jìn)程而是跟著 Nacos 進(jìn)程一起跑數(shù)據(jù)落在本地文件里。所以很多運維人員排查時下意識會看 8848 端口、看 Nacos 應(yīng)用本身卻忽略了應(yīng)用內(nèi)部還掛著一個數(shù)據(jù)庫引擎。這里要澄清一個常見誤解內(nèi)嵌數(shù)據(jù)庫不等于安全。Derby 雖然沒有獨立的網(wǎng)絡(luò)監(jiān)聽端口但 Nacos 會通過自己的 HTTP 接口把數(shù)據(jù)庫操作能力暴露出來。凡是能訪問 Nacos 管理端口的人理論上都有可能觸碰到后面的 Derby 操作入口。端口不獨立不代表接口不暴露這是很多人栽跟頭的地方。1.3 漏洞為什么會落在 Derby 身上Derby 本身不是什么“易攻破數(shù)據(jù)庫”問題出在組合方式上。Nacos 為了管理配置提供了一些和數(shù)據(jù)庫相關(guān)的操作能力這些能力在正常情況下應(yīng)該被嚴(yán)格鑒權(quán)。但在某些版本和默認(rèn)配置下訪問控制不到位攻擊者只要構(gòu)造特定請求就可能讓 Derby 去執(zhí)行任意的 SQL 語句。更麻煩的是Derby 作為功能完整的數(shù)據(jù)庫支持一些高級特性包括動態(tài)執(zhí)行 Java 代碼、調(diào)用系統(tǒng)命令等。這些能力本是給數(shù)據(jù)庫管理員在特定場景下用的可一旦攻擊者能控制輸入它們就變成了從 SQL 注入升級到遠(yuǎn)程命令執(zhí)行的橋梁。整個過程像什么呢就像一把多功能的瑞士軍刀正常使用沒問題但如果入口沒人看管任何路過的人都能拿起來用危險程度自然成倍上升。所以看這個漏洞時不要只盯著“Derby”三個字要看到它背后的三層結(jié)構(gòu)暴露在外的接口、不嚴(yán)格的鑒權(quán)、過強的數(shù)據(jù)庫能力。后續(xù)修復(fù)和加固也要從這三層分別下手才能做到真正有效。2. 漏洞原理與影響遠(yuǎn)程命令執(zhí)行是如何發(fā)生的2.1 攻擊鏈路拆解不涉及潛在利用代碼雖然官方?jīng)]有公布所有技術(shù)細(xì)節(jié)但從多個公開分析和漏洞報告來看攻擊鏈路大致可以拆成四步。第一步攻擊者找到 Nacos 對外暴露的管理入口。Nacos 默認(rèn)監(jiān)聽 8848 端口如果這個端口能通過網(wǎng)絡(luò)觸達(dá)攻擊者就有了接觸機會。第二步由于鑒權(quán)未開啟或者鑒權(quán)存在繞過攻擊者能夠調(diào)用原本應(yīng)該受保護(hù)的管理接口。第三步攻擊者向這些接口提交惡意的 SQL 語句而該語句會直接進(jìn)入 Derby 執(zhí)行。第四步攻擊者利用 Derby 允許執(zhí)行 Java 特性的能力進(jìn)一步調(diào)用系統(tǒng)命令。這里特別想強調(diào)很多人在分析漏洞時只看最后一步的命令執(zhí)行覺得那是核心其實漏洞成立的前提是前面的訪問控制失效。我們做修復(fù)時網(wǎng)絡(luò)層面收口、開啟鑒權(quán)、升級版本每一步都是在切斷攻擊鏈路中的某一環(huán)。如果只升級不收斂網(wǎng)絡(luò)風(fēng)險依然存在如果只封網(wǎng)絡(luò)不開鑒權(quán)內(nèi)部橫向風(fēng)險依然存在。分層防護(hù)的價值就在這里。2.2 遠(yuǎn)程命令執(zhí)行的危害到底有多大說說“遠(yuǎn)程命令執(zhí)行”這六個字的真實含義。攻擊者一旦能在服務(wù)器上執(zhí)行任意命令接下來能做的事簡直太多了讀取文件、創(chuàng)建賬號、安裝后門、下載惡意程序或者直接關(guān)閉安全服務(wù)。這些操作不需要多高深的技術(shù)只要權(quán)限允許順手就能做?？紤]到 Nacos 進(jìn)程的運行身份如果部署時用的是 root 或高權(quán)限賬號那攻擊者拿到的就是 root 權(quán)限整臺服務(wù)器就徹底淪陷了。就算不是 root攻擊者也能以 Nacos 運行用戶的身份讀取配置數(shù)據(jù)、篡改服務(wù)注冊信息進(jìn)而影響業(yè)務(wù)系統(tǒng)。另一個容易被忽略的點是內(nèi)網(wǎng)橫向移動。很多時候攻擊者并不是沖著 Nacos 本身來的而是把 Nacos 當(dāng)跳板先拿下一臺主機再通過內(nèi)網(wǎng)訪問其他系統(tǒng)。Nacos 這類基礎(chǔ)組件往往部署在網(wǎng)絡(luò)的核心位置周圍連著大量業(yè)務(wù)服務(wù)一旦被突破后面就是一馬平川。所以這類漏洞的影響范圍絕對不能按一臺機器來評估。2.3 哪些部署形態(tài)最危險結(jié)合行業(yè)里常見的部署方式和這次漏洞的觸發(fā)條件我把風(fēng)險等級分成三類大家可以對照自查。部署場景風(fēng)險等級說明單機內(nèi)嵌 Derby未開啟鑒權(quán)可公網(wǎng)訪問高攻擊者不需要任何憑據(jù)入口直接暴露單機內(nèi)嵌 Derby僅內(nèi)網(wǎng)訪問但鑒權(quán)弱或使用默認(rèn)密鑰中外部攻擊難度高但內(nèi)網(wǎng)失陷后橫向移動容易集群部署使用外部數(shù)據(jù)庫已嚴(yán)格鑒權(quán)網(wǎng)絡(luò)有白名單低攻擊面小但還要確認(rèn)接口是否仍然開放這不是一個絕對的標(biāo)準(zhǔn)只是基于常見情況的判斷。不同版本、不同配置下實際暴露面會有差異。我想表達(dá)的是不要因為自己“在公司內(nèi)網(wǎng)”就覺得萬事大吉。內(nèi)網(wǎng)橫向滲透是攻擊者的慣用手段一臺員工電腦被釣魚、一臺測試服務(wù)器被攻破都可能成為通向 Nacos 的跳板。3. 自查與排查先判斷自己有沒有踩中3.1 快速確認(rèn)版本和部署模式排查的第一步是搞清楚兩件事Nacos 是什么版本以及存儲模式是不是內(nèi)嵌 Derby。版本信息可以從幾個地方看部署目錄下的pom.xml、conf/application.properties、啟動日志里的版本行或者登錄控制臺后底部顯示的版本號。如果是在發(fā)布平臺部署的看發(fā)布記錄也行。拿到版本號以后對照官方安全公告確認(rèn)是否在受影響范圍內(nèi)。存儲模式也要確認(rèn)。在conf/application.properties里找到配置數(shù)據(jù)源相關(guān)的內(nèi)容如果沒有配置db.url、db.user等外部數(shù)據(jù)庫參數(shù)大概率就是單機內(nèi)嵌 Derby 模式。如果配置了外部數(shù)據(jù)庫連接說明存儲已經(jīng)切換但還要看 Derby 相關(guān)接口是否依然對外開放。這一步很快但不要靠記憶判斷我見過不少團隊負(fù)責(zé)人說“我們用的是 MySQL”結(jié)果一查MySQL 只是用了某個業(yè)務(wù)模塊Nacos 本身還是 Derby。3.2 觀察網(wǎng)絡(luò)暴露和訪問日志確認(rèn)了版本和部署模式以后再看網(wǎng)絡(luò)暴露面。登錄服務(wù)器檢查 Nacos 進(jìn)程監(jiān)聽的地址和端口。如果監(jiān)聽地址是0.0.0.0:8848說明所有網(wǎng)卡都能訪問能否從公網(wǎng)訪問還要看云安全組和防火墻規(guī)則。如果綁定的是內(nèi)網(wǎng)地址相對好一些但要繼續(xù)確認(rèn)防火墻是否只對可信來源放行。接著看訪問日志。Nacos 的日志目錄通常會有訪問日志和nacos.log檢索一些可疑特征比如包含derby、exec、shell、syscs等關(guān)鍵字的請求。如果發(fā)現(xiàn)來自非業(yè)務(wù)網(wǎng)段的 IP 頻繁訪問管理端口或者請求頻率明顯異常就要立刻警惕。注意在沒有確認(rèn)日志完整性的情況下不要指望日志里一定有攻擊痕跡。日志被清理、日志級別沒開全都是常見問題。日志排查是輔助手段不是唯一依據(jù)。3.3 判斷有沒有可能已經(jīng)被攻擊這里想提醒所有準(zhǔn)備“直接打補丁”的同學(xué)如果主機已經(jīng)失陷光升級版本相當(dāng)于給房子換了把新鎖小偷可能還在屋里。應(yīng)急之前先快速判斷有沒有被入侵的痕跡主要包括幾個方面。第一檢查最近被修改的可疑文件重點看/tmp、/var/tmp、Nacos 目錄下有沒有來歷不明的腳本、壓縮包、二進(jìn)制文件。第二看系統(tǒng)計劃任務(wù)有沒有新增條目很多后門是通過定時任務(wù)維持的。第三檢查進(jìn)程列表看有沒有不認(rèn)識的 Java 進(jìn)程、搶占 CPU 的挖礦程序、連接外部 IP 的可疑進(jìn)程。第四看系統(tǒng)用戶列表和登錄記錄有沒有新增的陌生賬號有沒有凌晨時段的異常登錄。上面這些檢查不需要復(fù)雜工具用幾條命令就能完成。如果發(fā)現(xiàn)異常不要猶豫先把主機從網(wǎng)絡(luò)上隔離保留現(xiàn)場證據(jù)再進(jìn)入應(yīng)急響應(yīng)流程。安全問題的處置順序很重要先止損再排查最后修復(fù)。4. 修復(fù)與加固從應(yīng)急到常態(tài)化4.1 首要動作升級到修復(fù)版本針對這個漏洞最徹底的修復(fù)方式還是升級到包含修復(fù)的 Nacos 版本。升級時不要只看版本號“比較新”而要對照官方安全公告確認(rèn)該版本確實修復(fù)了 Derby 相關(guān)的命令執(zhí)行問題。升級前一定要做配置備份尤其是application.properties和外部數(shù)據(jù)源配置。升級后先在測試環(huán)境驗證配置推送、服務(wù)注冊、服務(wù)發(fā)現(xiàn)這些核心功能再推向生產(chǎn)。Nacos 這類組件一旦升級出問題影響的是所有依賴它的服務(wù)所以不要圖快按變更流程走。如果暫時無法升級可以先把相關(guān)管理接口臨時禁用比如通過防火墻規(guī)則或反向代理屏蔽可疑路徑作為臨時緩解措施。但臨時緩解一定要設(shè)定到期時間問題拖久了就會變成常態(tài)這是運維上最常見的坑。4.2 網(wǎng)絡(luò)層收斂別讓 Nacos 裸奔無論是否升級網(wǎng)絡(luò)層面的收斂都建議馬上做。Nacos 是給內(nèi)部服務(wù)用的組件正常情況下不需要對公網(wǎng)開放。在云安全組和防火墻上把源 IP 限制到運維網(wǎng)段、辦公網(wǎng)網(wǎng)段或需要拉取配置的服務(wù)網(wǎng)段其他來源一律拒絕。同時檢查 Nacos 進(jìn)程的實際監(jiān)聽地址如果綁定的還是0.0.0.0試著改為具體內(nèi)網(wǎng) IP。這里要提醒一點修改監(jiān)聽地址后要確認(rèn)服務(wù)消費者還能正常連接。因為有些跨網(wǎng)段的服務(wù)如果走公網(wǎng)或特殊路由改了綁定地址可能導(dǎo)致大面積連接失敗。建議在測試環(huán)境先驗證再在生產(chǎn)執(zhí)行。很多漏洞攻擊得手不是攻擊手法多高明而是管理端口真的裸奔在公網(wǎng)上。把網(wǎng)絡(luò)入口收住攻擊者連敲門的機會都沒有這是性價比最高的安全措施。4.3 開啟認(rèn)證與修改默認(rèn)密鑰升級和封網(wǎng)之后還有一個容易遺留的問題鑒權(quán)配置。Nacos 支持開啟認(rèn)證但不少團隊因為歷史原因一直沒開或者開了認(rèn)證卻沿用默認(rèn)密鑰這樣的鑒權(quán)形同虛設(shè)。開啟認(rèn)證時需要設(shè)置一個足夠復(fù)雜的隨機密鑰并且妥善保存不要提交到 Git 倉庫不要寫在部署文檔里。同時修改默認(rèn)管理員密碼改成強密碼并且定期輪換。更高安全等級的環(huán)境可以考慮接入統(tǒng)一的認(rèn)證系統(tǒng)用公司現(xiàn)有的賬戶體系做登錄認(rèn)證。配置完成后實際測試一下未登錄狀態(tài)是否真的無法訪問管理接口不要只看配置文件里寫著enabledtrue就覺得萬無一失。安全配置以實際驗證結(jié)果為準(zhǔn)不以配置文件為準(zhǔn)。4.4 審計與監(jiān)控盡量在攻擊過程早期發(fā)現(xiàn)安全加固做得再好也不能保證百分百不被突破所以監(jiān)控和審計不能少。至少要覆蓋三個層面。第一Nacos 訪問日志要留存管理端口的登錄嘗試、配置變更記錄、接口調(diào)用記錄至少保留 90 天以上具體留存周期按公司合規(guī)要求來。第二對異常行為設(shè)置告警比如短期內(nèi)大量登錄失敗、陌生 IP 訪問管理端口、配置批量變更、Nacos 進(jìn)程啟動可疑子進(jìn)程等。第三在主機側(cè)部署安全 Agent 或文件完整性監(jiān)控重點盯 Nacos 安裝目錄、配置文件、臨時目錄的變化。監(jiān)控的意義在于即使攻擊者真的突破了第一道防線安全團隊也能在較早階段發(fā)現(xiàn)并處置避免攻擊者在內(nèi)網(wǎng)里慢慢打洞、擴大戰(zhàn)果。我見過不少安全事件明明日志里九天前就有異常登錄但因為沒人監(jiān)控直到數(shù)據(jù)被加密勒索才發(fā)現(xiàn)。監(jiān)控不是成本是保險。5. 實操總結(jié)我的排查經(jīng)驗與踩坑清單5.1 三個容易被忽略的坑第一個坑是以為內(nèi)嵌數(shù)據(jù)庫沒有獨立端口就安全。Derby 確實沒有獨立監(jiān)聽端口但它的操作入口在 Nacos 的 HTTP 接口上端口不獨立不等于接口不暴露。很多團隊在應(yīng)急時只檢查了 8848 端口是否對外開放卻忽略了那些和 Derby 操作相關(guān)的管理接口排查范圍一開始就窄了。第二個坑是升級后配置丟失或服務(wù)注冊異常。我遇到過不止一次升級時圖省事直接拷貝舊版的application.properties覆蓋到新版本目錄結(jié)果舊配置里既有外部數(shù)據(jù)庫連接又殘留了 Derby 相關(guān)配置啟動后行為變得很奇怪。正確的做法是升級前 diff 配置逐個參數(shù)核對保留該保留的去掉該去掉的不要無腦覆蓋。第三個坑是只給 Nacos 打了補丁沒有盤點相關(guān)組件版本。Nacos 使用的客戶端、內(nèi)置的依賴庫也可能存在其他已知漏洞。建議建一個資產(chǎn)臺賬把 Nacos 服務(wù)端、客戶端、運維腳本、依賴組件全部登記在冊定期對照漏洞情報排期修復(fù)。單點修復(fù)只是頭痛醫(yī)頭系統(tǒng)性地治理才能避免下次再被同一個問題絆倒。5.2 一份可直接執(zhí)行的排查命令清單下面這份命令清單是我在實際排查時常用的適合在沒有專業(yè)掃描平臺的情況下快速摸底。# 查看 Nacos 進(jìn)程信息 ps -ef | grep nacos # 查看 8848 端口監(jiān)聽地址和對應(yīng)進(jìn)程 ss -lntp | grep 8848 # 查看系統(tǒng)最近登錄記錄 last -n 20 # 查看是否有可疑新增用戶 grep -E nacos|admin|test /etc/passwd # 查看近期計劃任務(wù) crontab -l crontab -u root -l # 檢查臨時目錄下的可疑文件 find /tmp /var/tmp -name *.sh -mtime -7 2/dev/null # 搜索 Nacos 日志中的可疑關(guān)鍵字 grep -iE derby|syscs_util|exec|shell|runtime /data/nacos/logs/nacos.log | tail注意這些命令只是輔助排查不能覆蓋所有攻擊痕跡。如果公司有條件建議直接把 Nacos 主機接入漏洞掃描平臺和安全審計系統(tǒng)做一次針對性的安全檢查。5.3 一個典型的處置案例某公司安全團隊收到告警說配置中心存在高危漏洞。我協(xié)助排查時先通過堡壘機登錄 Nacos 服務(wù)器查看版本確實在受影響范圍。接著檢查安全組規(guī)則發(fā)現(xiàn)管理端口對所有內(nèi)網(wǎng) IP 開放雖然還沒發(fā)現(xiàn)公網(wǎng)攻擊但內(nèi)網(wǎng)橫向移動風(fēng)險非常高。當(dāng)天先做了隔離在防火墻加白名單只允許運維網(wǎng)段的幾臺機器訪問 Nacos。隨后安排升級版本升級前備份了application.properties升級后驗證配置推送和服務(wù)注冊都正常同時修改了管理員密碼。整個過程大概花了一個下午。復(fù)盤時我們發(fā)現(xiàn)這臺 Nacos 已經(jīng)上線兩年多中間多次提示版本過舊但一直因為“線上穩(wěn)定不敢動”被推遲升級。這次事件以后團隊才真正把基礎(chǔ)組件的版本維護(hù)提上日程。這個案例給我的感觸很深技術(shù)漏洞往往不是最可怕的可怕的是長期無人維護(hù)帶來的“歷史欠賬”。我個人在處理這類漏洞時體會最深的一點是不要只盯著“打補丁”這一步。先把資產(chǎn)摸清楚再按“網(wǎng)絡(luò)收斂、開啟鑒權(quán)、升級版本、持續(xù)監(jiān)控”這個順序推進(jìn)?；A(chǔ)安全配置到位的情況下哪怕漏洞通告晚看到幾天被利用的概率也會低很多。希望這篇關(guān)于 Nacos Derby 遠(yuǎn)程命令執(zhí)行漏洞的文章能幫你先把應(yīng)急方向理清楚少走一些彎路。