攻擊者通過被攻陷的分發系統
，向數千台Linux伺服器推送了偽裝成cPGuard更新的惡意程式，並以root權限運行。
軟體供應鏈中的漏洞再度暴露，此次攻擊者將矛頭對準了OpsShield的更新流程。
本周，威脅行為者利用竊取的憑證，向cPGuard客戶推送了惡意更新。隨後，他們訪問了儲存在該廠商伺服器及其計費門戶帳戶中的數據，並複製了至少三台OpsShield雲伺服器的內容。
該公司在一份安全公告中表示，已經"將攻擊者從所有已知被入侵的系統中清除，並正在重建那些無法完全信任的系統"。公司同時發布了更新檔，並敦促客戶升級到cPGuard最新版本、修改密碼、重新生成SSH密鑰。
歸根結底，此次未經授權訪問的廣度凸顯出軟體供應鏈持續存在的脆弱性，也暴露出安全工具自身同樣存在風險這一事實。
攻擊全過程解析
OpsShield專注於伺服器保護和網站安全軟體領域。其cPGuard產品是一套面向Linux網站託管伺服器的安全套件，集成了惡意軟體掃描和防火牆功能。
該公司披露，在11月1日至2日期間，攻擊者未經授權訪問了OpsShield的更新分發基礎設施，並在大約70分鐘內推送了一個惡意更新。
威脅行為者首先探測了OpsShield的計費門戶，以虛假身份註冊了一個客戶帳戶，並申請了cPGuard的免費試用。隨後，他們發送精心構造的請求，獲得了在伺服器上執行命令以收集數據的能力。他們利用竊取的訪問密鑰發布虛假更新，該更新以root權限（最高級別的管理員權限）運行，並藉此複製敏感文件以及三台OpsShield雲伺服器的內容。
據OpsShield報告，約有2950台客戶伺服器運行了這一虛假更新，導緻密碼哈希值、root SSH密鑰、MySQL root密碼及shell歷史記錄等資訊外泄。攻擊者還訪問了約7900個計費門戶帳戶，其中包含客戶姓名、地址、電子郵件及哈希密碼。
OpsShield表示，目前仍在審查攻擊者具體是通過何種請求獲得訪問權限的，並已修補了兩個可能的入侵點，同時對相關廠商組件進行了逐行驗證。公司已關閉攻擊者帳戶，吊銷被盜的更新儲存密鑰，以及"帳戶下所有的雲API令牌和訪問密鑰"。
該公司還移除了攻擊者的安全外殼（SSH）訪問權限；刪除了攻擊者創建的伺服器克隆及任何快照；啟用了更強的登錄保護機制，並替換了所有SSH密鑰和密碼；重置了所有計費門戶登錄會話並輪換了所有密鑰；同時開始以更嚴格的PHP和防火牆設置重建其計費、授權及內部管理伺服器。
該公司還發布了乾淨版本的更新：v5.88.26版本移除了隱藏的root shell；後續更新則清除了攻擊者留下的計劃任務。此外，公司開始重新簽發所有cPGuard授權私鑰和公鑰，以使攻擊者獲取的密鑰副本失效。
該公司建議管理員採取以下措施：
將cPGuard更新至最新版本，然後確認/etc/cron.d/i93677、/var/tmp/.i93677/以及/var/tmp/.cpg91511_sh等文件已被清除；若未清除，應手動刪除；
修改root密碼以及伺服器上每個本地用戶的密碼；
生成新的root SSH密鑰，並從所有信任舊密鑰的伺服器上移除舊密鑰；在密鑰更換完成前，應將相關伺服器視為已被入侵；
修改MySQL root密碼及任何資料庫密碼，並輪換root shell歷史記錄中存在的任何密碼、API密鑰或令牌；
重置OpsShield計費門戶密碼並啟用雙因素認證。
最後，公司表示："如果我們告知您攻擊者曾手動登錄過您的伺服器，請使用11月1日之前的乾淨備份重建系統。"
OpsShield保持透明，但影響依然真實存在
Dickson Research的弗蘭克·迪克森表示："坦白說，很少有廠商會如此坦誠地披露安全事件。OpsShield在這方面值得高度肯定。"
然而，他指出，最糟糕的攻擊類型，恰恰是由安全工具本身引發的攻擊。更新通道本就被刻意設置為開放狀態，而安全工具之所以以root權限運行，是因為它們需要監控一切，"因此這個虛假更新也同樣以root權限運行"。
對於一家託管服務提供商而言，一台伺服器可能承載著數百個客戶網站和資料庫。一個MySQL root密碼就能打開所有這些資料庫的大門，一個root SSH密鑰則能授予訪問所有信任該密鑰的其他伺服器的權限。此外，shell歷史記錄中往往還包含手動輸入的密碼和令牌資訊。
迪克森指出，下遊客戶可能受到的衝擊最為嚴重，但他們對此卻知之甚少，因為大多數網站所有者根本不知道自己的託管服務商運行的是哪款安全代理程序。每一台自動更新的伺服器，實際上都在信任廠商的分發渠道。
迪克森表示，OpsShield將自身定位為一家向中小型託管商提供低價服務的小團隊，而這恰恰揭示了供應鏈中一個令人不安的現實："你所面臨的風險敞口，是由在你伺服器上擁有root權限的最小廠商決定的，而非最大的廠商。"
Infotech技術顧問埃里克·阿瓦基安對此表示認同，他認為這次事件提醒人們，企業軟體供應鏈的安全性，取決於其背後的系統、身份管理及流程的安全性。"即便你竭盡全力保護自身基礎設施，仍可能因為一個你所信任的第三方供應商而遭到入侵。"
他指出，此次事件尤其令人擔憂的一點在於，攻擊者無需逐一攻破數千名客戶，只需攻陷單一的分發機制，就能將廠商自身可信的基礎設施，轉化為攻擊其客戶的武器。
他表示，第三方會擴大風險敞口，而這一事實目前仍被企業所低估。"企業需要在第三方及供應鏈風險管理方面投入更多關注。"
零信任已成必備策略
阿瓦基安還指出，此次事件對下遊客戶的影響可能遠不止於最初的入侵，因為被竊取的憑證還可能被用於發起進一步的攻擊。企業應採取零信任方法，將軟體供應商及其提供的更新也納入零信任管理範疇。
他表示："即便某個更新來自可信來源，也不意味著你可以默認它是安全的。"企業應更仔細地審視供應商風險，保護特權憑證，並對軟體完整性進行檢查。此外，還應在更新完成後持續監控異常行為，一旦出現問題，要能夠迅速隔離受影響系統。
他強調："你必須為'即便是可信供應商也可能遭到入侵'這種可能性做好預案，並需要將此類場景的應對演練，納入定期的桌面推演項目中。"
迪克森建議企業首先從資產盤點入手，清楚掌握每一個以root或管理員權限運行的廠商代理程序，因為每一個這樣的程序都是一條潛在的更新通道。客戶應向供應商詢問更新發布密鑰存放在何處，以及這些密鑰與面向客戶的系統之間採取了哪些隔離措施，同時應監控伺服器的出站流量，避免在shell歷史記錄中保留敏感資訊，並將SSH密鑰視為具有有效期的憑證來管理。下遊客戶應直接向其託管服務商詢問是否使用了cPGuard，並應主動修改自己的密碼。
他表示："你伺服器上最危險的軟體，或許恰恰是你所信任、用來自動更新自身的那款軟體。選擇這些供應商時應格外謹慎，因為它們實際上掌握著你系統的root權限。"
