月初日本曾傳出因一名日本養老金系統的員工操作不當，使相關系統受到黑客攻擊，令約 125 萬份日本人個資被洩露，日本養老管理機構水島藤一郎當時召開緊急新聞發佈會，並於會上表示已組織團隊以查明事件，並會防止再次發生同類型事件。

而日本卡巴斯基就發現，對日本養老金系統發動攻擊的為專門針對日本的 APT 攻擊組織「藍白蟻 (Blue Termite)」，而其目標全針對日本機構：上至政府，下到學院，都無一倖免。

 

Blue Termite 只針對日本機構

日本卡巴斯基指，Blue Termite 對日本的攻擊非只針對養老金系統，目標同時包括日本政府、國防、航空業、重要基礎設施、財政金融、製造業與學術界等多個範疇。

而對雲端服務供應商的分析發現，逾 300 個網站受到 Blue Termite 的感染並散播惡意程式；而 Symantec 更認為，Blue Termite 或與黑客組織 CloudyOmega 有關。

 

是次外洩的訊息包括：基礎年金號碼、姓名、出生日期、住址，合共約 125 萬份。

據研究指，Blue Termite 慣用的攻擊方式為釣魚郵件，大部分郵件中都會附有名為「醫療保險通知」的 Word 文件：但事實上此「Word 文件」為可自動執行的壓縮文件，一旦受害者開啟此「Word 文件」，隱藏於其內部的惡意程式就會自動執行，並感染用戶的電腦，繼而與黑客的 C&C (Command & Conquer) 服務器進行連接，並開始竊取用戶資訊等行為。

 

一旦受害者與黑客成功建立 C&C，黑客首先會分析受害者電腦上的目錄與文件，並評估其數據的價值；若相關數據並沒有太大價值，攻擊就會停止；反之，黑客就會進一步的釋放一系列黑客工具，竊取用戶信息。上述黑客工具更可用於脅持電郵賬戶、瀏覽器等。

 

相信 Blue Termite 的 APT 攻擊與 CloudyOmega 的活動大概會陸續有來：但有趣的是，Blue Termite 現時只對日本展開攻擊，並未對其他的國家造成任何威脅。

Source：INTERNET Watch

 

據「國際地球轉動服務組織」發布的世界時間，7 月 1 日將增加 1 秒，即「閏秒」。短短的 1 秒，眨一眨眼就過去了：但原來此 1 秒對電腦程式、各種系統都為嚴重的問題，工程師、系統管理員等更要花上數以百計的小時及數不盡的額外功夫去應付此特殊情況。

 

何謂閏秒？

探討閏秒對電腦系統的影響前，各位讀者可先了解何謂閏秒。「時間」的度量衡上，分為有以原子鐘為標準計時的「協調世界時」(Coordinated Universal Time，UTC) 與根據地球自轉、公轉，再以地球極軸運動修正的「世界時」(Universal Time 1，UT1)：前者為世界各國依循使用的標準時間，以英國格林威治的時間為基準，香港時間較英國格林威治快 8 小時，亦即 UTC+8。

但由於地球自轉速度會因地質分布及其他星球引力的影響，導致轉速非規律一致，時有快慢，故 UTC 與 UT1 並非同步。而為協調上述兩種時間標準，避免太陽升至正中央、時鐘卻標示為午夜 12 點的問題出現：國際計量大會於 1972 年就決定於原子鐘與世界鐘出現超過 0.9 秒的時差之際就加上或減去 1 秒，令 UTC 可以配合到 UT1，而此 1 秒就稱為「閏秒」(Leap Second)。

而自 1972 年閏秒誕生至今，已出現過 25 次閏秒，而且 25 次均同樣為正閏秒，即將於 7 月增加的 1 秒就因第 26 次。而正閏秒時的方法為於 23:59:59 的下 1 秒記錄成 23:59:60，再下一秒就為另一天的 00:00:00；負閏秒時則為將 23:59:58 的下一秒 (23:59:59) 減去，直接進入下一天的 00:00:00。

 

AWS 解決方案：將閏秒分散出去

對一般人而言，應對閏秒的方法不外乎就為將時鐘、手錶調快或調慢 1 秒；但對於電腦系統而言，由其是需要精準對時的 GPS、通訊設備、金融系統等，就可謂海嘯級的問題。更由於閏秒的出現並毋特定規律，所有是乎所有系統的設計上都未有針對閏秒而設的調整方案。

回顧上一次閏秒出現的 2012 年 6 月 30 日至 7 月 1 日當日，由於各網站底層並無應變此 1 秒，令多間如 Reddit、Mozilla、RedHat、LinkedIn 等網站都紛紛當機，可見閏秒對系統的破壞力非同小可。

而近年雲端的出現與其受歡迎程度令閏秒的「破壞力」不斷上升，作為眾多網站營運人員選用的 Amazon Web Services 就為其中一間需要嚴肅處理閏秒的科企之一：而 AWS 就將「不增加閏秒，但仍保持時間與 UTC 一致」。

更確切一點而言，AWS 並不打算為系統於 23:59:59 後加入 23:59:60：而是將這 1 秒平均攤在閏秒出現前後的 24 個小時，讓每秒的秒數稍微增長一點點，最後補滿 1 秒。

 

此手法的好處為系統時鐘毋需特別為閏秒設計「23:59:60」，仍舊以 60 秒為 1 分鐘的單位，而且除 23:59:60 此閏秒記時與 UTC 不同步以外，其他每秒依舊與 UTC 同步。儘管 UTC 加入閏秒前，AWS 系統時間將較 UTC 快；而加入閏秒後 AWS 又會較 UTC 慢，但總括而言，此差距均不大於 0.5 秒，並不會對系統構成影響。

而除上述如 AWS 「將閏秒分散」的處理手法外，其他方法還有如 Linux Kernels 般將 23:59:59 重複一次、如 Windows time servers 忽略閏秒，在閏秒增加後再讓系統時間與 UTC 同步等多種方式。但與金錢流動攸關的的股票交易市場則對閏秒較為敏感，甚至避開於閏秒出現之時進行交易：如芝加哥商品交易所 (CME) 與洲際交易所就計劃將 6 月 30 日夜間電子開市的時間延後，以避開閏秒。

(本文由 TechNews 授權轉載)