Category: Security

前陣子爆出「不保留記錄的 VPN」保留了大量的客戶與連線資訊

前陣子 comparitech 發現了宣稱不保留記錄的 VPN 廠商 UFO VPN 有 Elasticsearch 伺服器沒有設定好，造成外部可以直接存取，然後發現裡面包含了大量記錄：「“Zero logs” VPN exposes millions of logs including user passwords, claims data is anonymous」，這篇文章的小標把重點先說完了：

UFO VPN exposed millions of log files about users of its service, including their account passwords and IP addresses, despite claiming that it keeps no logs.

目前還是建議在有能力的情況下都自己架，一般常見就是用 OpenVPN，但設定上會比較麻煩一些。如果要方便的話可以用 Openconnect VPN Server (ocserv) 架 server，然後在手機上可以直接用 Cisco 官方提供的用戶端接，像是 Cisco AnyConnect (iOS) 與 AnyConnect (Android)，在桌機上一般則是用 OpenConnect 自家的軟體連接。

家裡有 HiNet 的網路的話，可以申請一個固定 IP (透過 PPPoE 的)，然後用一台 Raspberry Pi 之類的設備架設。

倒不是說這些 VPN 廠商的服務不能用，只是你必須認知這些 VPN 是拿來繞過地區限制的，而不是為了安全性或是隱私，所以如果是人在外面使用網路，想要避免被商家或是外面的 ISP 看到流量內容，透過自己架設的 VPN 應該會好不少。

TLS 憑證的最長時效將從 825 天降到 398 天

在「Reducing TLS Certificate Lifespans to 398 Days」這邊看到才想起來沒寫這篇，這邊發生了一些有趣的事情...

提案是降低 TLS 憑證的有效時效，這件事情一開始是在 CA/B Forum 討論，但經過投票後沒有通過：「Ballot SC22 - Reduce Certificate Lifetimes (v2)」。

從投票記錄可以看到所有的憑證使用方 (包括了許多瀏覽器的廠商) 都贊同，但有大約 2/3 的憑證發行方都反對：

7 votes total including abstentions:

  • 7 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360
  • 0 No votes:
  • 0 Abstain:

33 votes total including abstentions

  • 11 Yes votes: Amazon, Buypass, Certigna (DHIMYOTIS), certSIGN, Sectigo (former Comodo CA), eMudhra, Kamu SM, Let’s Encrypt, Logius PKIoverheid, SHECA, SSL.com
  • 20 No votes: Camerfirma, Certum (Asseco), CFCA, Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy, Izenpe, Network Solutions, OATI, SECOM, SwissSign, TWCA, TrustCor, SecureTrust (former Trustwave)
  • 2 Abstain: HARICA, TurkTrust

然後幾個比較大的憑證使用方 (Apple、Google、Mozilla) 在提案被否決後就決定放到自家的規則了：「Apple strong-arms entire CA industry into one-year certificate lifespans」。

從 2020/09/01 開始，如果發出來的憑證超過 398 天就當作是無效憑證，也就是 2020/08/31 是最後一天可以發有效期限為 825 天的憑證，會落在 2022/12/05 失效：

$ date --date='Sep 1 2020 GMT+0000 +825days'
Mon Dec  5 08:00:00 CST 2022

這三家搞下去，就等於是強制性讓這些 CA 到九月就不能賣兩年的憑證了 (雖然還沒看到 Microsoft)，這些 CA 一定是在心裡幹爆... XD

Onion Service 第二版的退場計畫

Tor 這邊給出了 Onion Service v2 的退場計畫：「Onion Service version 2 deprecation timeline」，關於 v2 與 v3 的差異，可以參考之前寫的「下一代的 Tor Hidden Service」，裡面有提到 v3 的 spec。

v2 與 v3 最大的差異就是本來 v2 的 hostname 是 16 個英數字 (大約是 80-bit security)，現在 v3 變成是 56 個英數字 (大約是 280-bit security)，大幅降低 collision 的機會。

目前公佈的時間表是在 2020 年九月先拋警告出來，2021 年七月拔掉 server 支援，2021 年十月拔掉 client 支援：

1. September 15th, 2020
0.4.4.x: Tor will start warning onion service operators and clients that v2 is deprecated and will be obsolete in version 0.4.6.

2. July 15th, 2021
0.4.6.x: Tor will no longer support v2 and support will be removed from the code base.

3. October 15th, 2021
We will release new Tor client stable versions for all supported series that will disable v2.

差不多是十五個月的計畫...

雞肋功能：AWS 推出 Managed Prefix Lists 管理 IP 列表

AWS 總算推出可以管理 IP 列表的功能 Managed Prefix Lists，就不需要自己在 security group 裡面針對一堆 IP 設重複的設定：「Amazon Virtual Private Cloud (VPC) customers can now use their own Prefix Lists to simplify the configuration of security groups and route tables」。

目前這個功能在大多數的區域都開放使用了：

There is no additional charge to use the Prefix Lists. Support for Prefix Lists is available in all public regions with support in Africa (Cape Town), Europe (Milan), China (Beijing), and China (Ningxia) coming soon. For more information on prefix lists, visit our public documentation.

但實際測試後發現在 web console 的操作上不算好用，主要是因為這個功能還是會受到「How do I increase my security group limits in Amazon VPC?」這邊提到的限制影響，如果沒有開 support ticket 調高限制，預設值是：

  • 每個 network interface 可以設定 5 個 security group。
  • 每個 security group 可以設定 60 條規則。

在建立 prefix list 時，需要設定「裡面會包含的最大數量」(可以到 1000)，是一個你不知道為什麼要設定的東西，然後我就很開心設了 1000...

接下來開了一個純測試用的 security group (裡面是空的)，結果這個 prefix list 掛不上去...

後來測了幾次後發現 prefix list 在 security 內不是吃一條 rule，而是直接照剛剛設定的「最大數量」去展開。

所以重新砍掉建一個新的 prefix list，改成 15 條後，就可以在 security group 上面掛四次 prefix list (不同的 port)，剛好吃完 60 條規則，第五個設定就完全掛不上去... (無論是用 prefix list，或是設定 CIDR)

所以這些限制讓 prefix list 在 web console 上變得很不怎麼好用：

  • 一開始就要設計好 prefix list 內的最大筆數，如果不幸用完是沒辦法修改的。
  • 在 security group 裡不是吃一條規則，而是以最大筆數佔用，prefix list 內沒有射到最大筆數也還是得佔用。

但如果變成 Terraform 之類的工具用的話就還馬馬虎虎，因為你可以設計機制，改 prefix list 時可以開新的 prefix list (最大上限設成實際的數量，不會有浪費)，然後再把 security group 裡面的 prefix list reference 換掉。

不過又想到，都已經用 Terraform 這種工具了，加上你又不是只佔一條規則，我就自己展開就好了啊... 不需要這個功能就能處理了。

「雞肋」XD

把 SSH Key 放進 Secure Enclave 裡保護

看到 Secretive 這個專案，是利用蘋果的 Secure Enclave 機制，把 SSH private key 放進去在裡面進行運算，避免 private key 檔案被惡意程式讀取就洩漏出去了。

從 Secure Enclave 的介紹頁面可以看到這個需要有 T1 或是 T2 晶片才有 Secure Enclave 功能：

Mac computers that contain the T1 chip or the Apple T2 Security Chip

而從 Apple Silicon 這邊可以看到 Apple T1 chip 是 2016 年後的機種引入的：

The Apple T1 chip is an ARMv7 SoC (derived from the processor in S2 SiP) from Apple driving the System Management Controller (SMC) and Touch ID sensor of the 2016 and 2017 MacBook Pro with Touch Bar.

然後對於沒有 Secure Enclave 的古董機，可以透過有支援 smart card 的硬體掛上去，像是 YubiKey：

For Macs without Secure Enclaves, you can configure a Smart Card (such as a YubiKey) and use it for signing as well.

照著他講的建議去翻了「YubiKey Smart Card Deployment Guide」這邊的資料，看起來 YubiKey 在 4 系列之後就有產品支援 Smart Card 了，不過要注意純 U2F 的版本沒支援。

阻擋網站透過瀏覽器掃 localhost

五月的時候，DuckDuckGo 的 Charlie Belmer 發了一篇關於網站透過瀏覽器掃 localhost 的文章，引起了不少重視：「Why is This Website Port Scanning me?」。

這個月陸陸續續看到一些反制方式了，比較簡單的是透過像 uBlock Origin 這類可以擋特定 url 的方式，像是 EasyPrivacy 裡面把一些大站台的 javascript script 擋下來：「uBlock Origin ad blocker now blocks port scans on most sites」。

在同一篇文章的 comment 處也有人提到 uBlock Origin 可以做的更廣泛：「Block access to 127.0.0.1/localhost and LAN address from the internet #4318」，裡面有人已經整理好丟出來了：「lan-block.txt」，看起來也可以擋一些...

要擋得比較完整的還得考慮 scan.example.com IN A 127.0.0.1 這種方式繞過去的情況？這可能需要用 extension 了...

Google Chrome 又要對 URL 搞事了...

上個禮拜鬧的頗兇的話題，Google Chrome 又要對 URL 搞事了：「Google resumes its senseless attack on the URL bar, hides full addresses on Chrome 85」。

這次是打算把整個 path 藏起來：

A few new feature flags have appeared in Chrome's Dev and Canary channels (V85), which modify the appearance and behavior of web addresses in the address bar. The main flag is called "Omnibox UI Hide Steady-State URL Path, Query, and Ref" which hides everything in the current web address except the domain name. For example, "https://www.androidpolice.com/2020/06/07/lenovo-ideapad-flex-5-chromebook-review/" is simply displayed as "androidpolice.com."

來繼續等 3rd-party browser 成熟...

Zoom 最後決定所有使用者都有 End-to-end encryption 了

先前在「Zoom 不提供 End-to-end Encryption 給免費版用戶」這邊提到的事情，剛剛看到 Zoom 宣佈改變策略，變成無論是付費還是免費的使用者都會提供 End-to-end encryption：「End-to-End Encryption Update」。

Free/Basic 的使用者要認證才能用這個功能：

To make this possible, Free/Basic users seeking access to E2EE will participate in a one-time process that will prompt the user for additional pieces of information, such as verifying a phone number via a text message.

還是很怪，繼續觀望...

Intel 的 RDRAND 爆炸...

在正妹 wens 的 Facebook 上看到的，Intel 的 RDRAND 因為有安全漏洞 (CrossTalk/SRBDS)，新推出的修正使得 RDRAND 只有原來的 3% 效能：

從危機百科上看，大概是因為這個指令集有 compliance 的要求，所以這個安全性漏洞必須在安全性上修到乾淨，所以使用了暴力鎖硬解，造成效能掉這麼多：

The random number generator is compliant with security and cryptographic standards such as NIST SP 800-90A, FIPS 140-2, and ANSI X9.82.

不過畢竟這個指令不是常常被使用，一般使用者的影響應該是還好：

As explained in the earlier article, mitigating CrossTalk involves locking the entire memory bus before updating the staging buffer and unlocking it after the contents have been cleared. This locking and serialization now involved for those instructions is very brutal on the performance, but thankfully most real-world workloads shouldn't be making too much use of these instructions.

另外這個漏洞早在 2018 九月的時候就通報 Intel 提了，但最後花了超過一年半時間才更新，這算是當初在提 Bug Bounty 制度時可能的缺點，在這次算是比較明顯：

We disclosed an initial PoC (Proof-Of-Concept) showing the leakage of staging buffer content in September 2018, followed by a PoC implementing cross-core RDRAND/RDSEED leakage in July 2019. Following our reports, Intel acknowledged the vulnerabilities, rewarded CrossTalk with the Intel Bug Bounty (Side Channel) Program, and attributed the disclosure to our team with no other independent finders. Intel also requested an embargo until May 2020 (later extended), due to the difficulty of implementing a fix for the cross-core vulnerabilities identified in this paper.

回到原來的 bug，主要還是 Intel 架構上的問題造成大家打得很愉快，現在 Intel 這邊的架構對於資安研究員仍然是個大家熱愛的地方... (因為用的使用者太多)

Zoom 不提供 End-to-end Encryption 給免費版用戶

Zoom 解釋免費版將不會有 End-to-end encryption 的時候，大家都傻翻了：「Zoom's Commitment to User Security Depends on Whether you Pay It or Not」，這邊 Bruce Schneier 引用了 Bloomberg 對 Zoom 的 CEO 袁征的訪談：「Zoom Transforms Hype Into Huge Jump in Sales, Customers」。

Corporate clients will get access to Zoom’s end-to-end encryption service now being developed, but Yuan said free users won’t enjoy that level of privacy, which makes it impossible for third parties to decipher communications.

“Free users for sure we don’t want to give that because we also want to work together with FBI, with local law enforcement in case some people use Zoom for a bad purpose,” Yuan said on the call.

繼續看隔壁棚的發展...