iPhone 5S 又拿到安全性更新了:iOS 12.5.7 (2023/01/23)

Apple 又針對 iOS 12 釋出安全性更新了:「About the security content of iOS 12.5.7」。

Available for: iPhone 5s, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch (6th generation)

Impact: Processing maliciously crafted web content may lead to arbitrary code execution. Apple is aware of a report that this issue may have been actively exploited against versions of iOS released before iOS 15.1.

Description: A type confusion issue was addressed with improved state handling.

這次的更新是 backport 去年十二月在 Safari 16.2 上修正的 CVE-2022-42856

A type confusion issue was addressed with improved state handling. This issue is fixed in Safari 16.2, tvOS 16.2, macOS Ventura 13.1, iOS 15.7.2 and iPadOS 15.7.2, iOS 16.1.2. Processing maliciously crafted web content may lead to arbitrary code execution.

所以這包跟上次一樣 (參考先前寫的 「iOS 12.5.6」這篇),也是在修正 RCE 類的漏洞,這樣對於 iPhone 5S 等於是進入第九年的支援了。

之前在網路上有看到有人在猜是因為海外有很多異議人士拿這隻手機,所以美國政府「希望」Apple 能夠針對一些高危險性的安全漏洞提供更新?

Git 在 SHA-256 支援上遇到的問題

在 Hacker News 首頁上的「Whatever happened to SHA-256 support in Git?」這篇,大概半年前,今年六月的文章,在講 GitSHA-256 支援上遇到的問題。

最大的問題還是沒有 transition plan:

Bjarmason pointed out that there is still no interoperability between SHA-1 and SHA-256 repositories, and that none of the Git hosting providers appear to be supporting SHA-256.

這點導致了目前場上看的到的服務與 open source 軟體都沒有支援的計畫,這點算是一個超級失敗的 transition plan。

另外乾脆請 OpenAIChatGPT 幫忙寫:

Git是一種源代碼管理系統,它使用散列函數將每個對象(例如文件的每個版本)和每個提交都轉換為一個數值,用於存儲該對象。散列函數的安全性是整個倉庫完整性的重要組成部分。如果攻擊者可以用具有相同散列值的另一個提交替換提交,他們可能會在不冒檢測風險的情況下將惡意代碼植入倉庫中。這種前景令任何依賴 Git 倉庫中代碼安全性的人感到擔心,也就是所有人。

Git 項目早已選擇 SHA-256 作為 SHA-1 的替代品。Git 最初是使用 SHA-1 寫成的,但是這些代碼已被重構,並且可以處理多種散列類型,其中 SHA-256 是第二種支持的類型。現在可以使用 SHA-256 創建 Git 倉庫(只需使用 --object-format=sha256 標誌),大多數本地操作都會正常工作。Git 中支持替代散列算法的基礎是2020年發布的2.29版本的一部分,並且似乎很穩定。

然而,自從2021年3月發布的2.31版本中出現了修復程序以來,2.29版本是最後一個在任何重大方面支持替代散列的版本。專

續寫前文,Git 專案在支持 SHA-256 之前一直使用 SHA-1 作為散列算法。然而,由於 SHA-1 的終極破解,Git 項目被迫尋找替代方案。Git 原本的代碼是深深地嵌入 SHA-1 的,但是這些代碼已經被重構,並且可以處理多種散列類型,其中 SHA-256 是第二種支持的類型。因此,現在可以使用 SHA-256 創建 Git 倉庫(只需使用 --object-format=sha256 標誌),大多數本地操作都會正常工作。

然而,目前尚不存在 SHA-1 和 SHA-256 倉庫之間的相互操作性,並且 Git 托管提供商似乎都不支持 SHA-256。這種支持(或缺乏支持)很重要,因為無法推送到 Git 熔爐的倉庫對許多人來說將是無用的。此外,使用 SHA-256 的較長散列可能會破壞 Git 項目以外開發的工具,這種風險也無法完全消除。整體而言,這是一種尚未準備好用於現實世界的功能。

雖然如此,值得注意的是,迄今為止完成大部分散列轉換工作的 brian m. carlson 對 Bjarmason 的評估持不同看法。在他看來,目前唯一“可以辯解

的”使用 SHA-1 的原因是與 Git 熔爐提供商的相互操作性。否則,他認為 SHA-1 已經過時,並且使用 SHA-256 的性能可能“大幅提升”。但是,他同意所需的相互操作性目前尚不存在,且沒有人表示它即將在短期內到來。

因此,目前看來,Git 專案在支持 SHA-256 方面的工作似乎已經停止。至於什麼原因導致了這種情況,目前還不清楚。但是,這並不意味著 Git 將永遠不會支持 SHA-256 或其他散列算法。相反,可能是因為尚未解決所有技術問題,或者可能是因為其他原因(例如技術資源有限)。無論原因是什麼,重要的是要記住,Git 項目的開發人員一直在努力使其更強大、更安全,並且將繼續努力。

LastPass 離職員工的爆料

這次 LastPass 出包搞的蠻大的,在官方的「Notice of Recent Security Incident」的裡面有提到這次的資料外洩包括了使用的 encrypted vault data 也被洩漏了:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

官方一直強調這是 encrypted data,但離職員工爆料加密強度不足的問題:「1606428769731878913.html」,其中這段在講 legacy 版本的加密問題,居然曾經用過 ECB mode

Lots of vault entries may be encrypted with ECB mode AES-256. I worked on supporting unauthenticated CBC mode. But re-encrypting a users vault entries requires having their master key.

這個如同 Hacker News 上的討論「I worked at LastPass as an engineer (twitter.com/ejcx_)」提到的,以 1980 年代的標準就已經知道 ECB mode 的問題了:

> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s

其他提到 PBKDF2 的強度是逐步增加,從早期的 5000 到現在預設的 100100,這點倒是可以理解。

要避免依賴廠商的資安,一種方式是用目前成熟的開源 Password Manager,並且使用檔案儲存 (像是 KeePassXC 這類工具),再搭配 file sync 的工具跨機器使用 (像是 Syncthing 這樣獨立確認每個 device 身份的方式),但方便性不會像這些商用方案這麼好用就是了...

這次故事好像還沒結束,遇到西方的長假,反應都比較慢...

讓 Windows 2000/XP/Vista 與 Server 2003/2008 能夠更新的軟體

Hacker News 上看到「Legacy Update」這個網站:

Legacy Update: Fix Windows Update on Windows XP, Vista, Server 2008, 2003, and 2000

對於已經沒辦法跑 Windows Update 的作業系統,至少有個工具可以把現有手上的 patch 都裝進去?

不過網站本身最低只支援 TLS 1.0,所以對於新安裝的 IE6 得手動開 TLS 1.0 後才能連上 (預設是關閉的),但看起來至少是個比較方便的工具了。

如果是跑在虛擬機裡面的話可以先用 host OS 下載下來再透過其他方式丟進去,不過我試著下載檔案,點了半天一直被重導到首頁... GitHub 上面看起來是有檔案,但 GitHub 對於老 OS 來說是無法連線的對象...

另外看了一下 WHOIS 資料,是今年七月才成立的網站,不是那種已經出來好幾年的網站,上面的東西的可信度可以自己斟酌...

GitHub 的 2FA 新計畫

GitHub 決定擴大強制使用 2FA 的範圍:「Raising the bar for software security: next steps for GitHub.com 2FA」。

本來的 2FA policy 是在「Software security starts with the developer: Securing developer accounts with 2FA」這邊提到的,所有的使用者預定在 2023 年年底強制使用 2FA:

GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.

另外針對 npm 熱門套件的維護者,則是在三月 (top 100) 與五月 (top 500) 就強制要使用了:

In February we enrolled all maintainers of the top-100 packages on the npm registry in mandatory 2FA, and in March we enrolled all npm accounts in enhanced login verification. On May 31, we will be enrolling all maintainers of the top-500 packages in mandatory 2FA.

但到 2023 年年底才有動作會有點久,所以這次宣佈在 2023 年三月會插入一個新階段,強制這些人要有 2FA 才能進行變更類的操作:

  • Users who published GitHub or OAuth apps or packages
  • Users who created a release
  • Users who are Enterprise and Organization administrators
  • Users who contributed code to repositories deemed critical by npm, OpenSSF, PyPI, or RubyGems
  • Users who contributed code to the approximate top four million public and private repositories

以 developer 為主的 GitHub 大力在推 2FA,其他的服務不知道之後會不會有類似動作...

NIST 更新了 SHA-1 的淘汰計畫

NISTSHA-1 的新的淘汰計畫出來了:「NIST Retires SHA-1 Cryptographic Algorithm」。

先前 NIST 在 2004 年時是計畫在 2010 年淘汰掉 SHA-1,在「NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1」這邊可以看到當時的宣佈:

The results presented so far on SHA-1 do not call its security into question. However, due to advances in technology, NIST plans to phase out of SHA-1 in favor of the larger and stronger hash functions (SHA-224, SHA-256, SHA-384 and SHA-512) by 2010.

但看起來當時沒有強制性,所以事情就是一直拖一直延期,中間經過了 2017 年 GoogleCWI Amsterdam 展示的 SHA-1 collision:「Google 與 CWI Amsterdam 合作,找到 SHA-1 第一個 collision」。

以及 2020 年時的進展與分析,發現 chosen-prefix collision 已經是可行等級了:「SHA-1 的 chosen-prefix collision 低於 2^64 了...」。

然後 NIST 總算是想起來要更新 phase out 的計畫,現在最新的計畫是在 2030 年年底淘汰掉 SHA-1:

As today’s increasingly powerful computers are able to attack the algorithm, NIST is announcing that SHA-1 should be phased out by Dec. 31, 2030, in favor of the more secure SHA-2 and SHA-3 groups of algorithms.

這次就有一些強制的規範了,包括採購的部份:

“Modules that still use SHA-1 after 2030 will not be permitted for purchase by the federal government,” Celi said.

但 2030 年聽起來還是有點慢...

CloudFront 支援 JA3 資訊 (SSL/TLS fingerprint)

看到 CloudFront 宣佈支援帶入 JA3 資訊了:「Amazon CloudFront now supports JA3 fingerprint headers」:

Details: Amazon CloudFront now supports Cloudfront-viewer-ja3-fingerprint headers, enabling customers to access incoming viewer requests’ JA3 fingerprints. Customers can use the JA3 fingerprints to implement custom logic to block malicious clients or allow requests from expected clients only.

JA3 的頁面上可以看到說明,針對 SSL/TLS 這個複雜的 handshake 過程中,就可以從中得知不同的 client 實做,比起容易偽造的 User-agent 有效:

JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.

像是 Tor 的 SSL/TLS 連線就會有對應的 fingerprint 可以偵測:

JA3 fingerprint for the standard Tor client:
e7d705a3286e19ea42f587b344ee6865

先前在「修正 Curl 的 TLS handshake,避開 bot 偵測機制」裡面提到的 curl-impersonate 就是反制這類偵測的方式。

英國政府開始定時掃描英國內的網路服務

Hacker News Daily 上看到的,英國政府也建立了自己的掃描資料庫:「NCSC Scanning information」。

看起來是類似於 Shodan 這樣的服務,但是範圍限制在英國內的網路服務:

These activities cover any internet-accessible system that is hosted within the UK and vulnerabilities that are common or particularly important due to their high impact.

不過這個東西各國應該都有做,只是有沒有公開講?

在南極洲收銀行 OTP 簡訊的方式

看到「SMS Multifactor Authentication in Antarctica」這篇,講在南極洲收銀行 OTP 簡訊的方式 (one-time password,常見的形式是六碼或是七碼數字)。

很明顯的,南極洲沒有什麼電信商可以讓你漫遊 XD

一開始是試著用 Verizon Messages Plus,這個服務可以在電信商直接把簡訊改成 e-mail 寄出來,但作者發現所有的簡訊都會轉送,就是銀行的不會轉送 XDDD

接著是試著用 Google Voice 的號碼,但銀行會判定為 VoIP 電話而不送。

另外的方式是「Wifi Calling」,看起來應該是 VoWiFi 這個台灣更常見的詞,透過 internet 連到電信商的網路掛進去,而不需要透過電信商的基地台。

McMurdo 的網路目前還是有很多不一樣的限制與問題:

At McMurdo, phones have access to a wifi network only for wifi calling and texting, not for general Internet access. It’s just a prototype at this time. It doesn’t work in all cases or in all areas, and for one reason or another it doesn’t work for some people, even if they’ve followed all the steps for enabling wifi calling.

看起來作者遇到的問題是 latency 過高以及頻寬不穩定的問題:

Also, the protocol assumes terrestrial broadband with reasonable latency and bandwidth. At McMurdo, as of this writing, latency to terrestrial locations is in excess of 700 milliseconds. Usable bandwidth for any given end user can vary widely, down to a few dozen kilobits per second.

然後也很難 troubleshooting:

The protocol also doesn’t expose any useful diagnostic info to the end user in order to troubleshoot. You just have to cross your fingers that the magic “wifi calling” icon lights up.

接下來作者嘗試的是 Voice MFA,但不存在這樣的電話號碼可以轉接之類的:

Direct inward dialing to US Antarctic stations isn’t generally available, so you probably can’t configure your cell phone number to forward to a number you can directly answer on-station. (I’m aware of some exceptions to this.)

作者最後提了兩個方法,第一個是想辦法找一個銀行不會擋的虛擬號碼註冊,但這個方法基本上是個貓抓老鼠的遊戲。第二個是作者實做的方法,自己搞 relay,透過 IFTTT 或是其他類似的工具來轉:

轉出來像是這樣:

也許等基礎建設好一點之後,VoWiFi 應該就有機會通?