幹壞事是進步最大的原動力
在 Hacker News Daily 上看到的，LastPass 的 Android App「LastPass Password Manager」裡面引用了大量的 SDK，引起不少人的資安疑慮：「LastPass Android app has got 7 trackers in it (eu.org)」。
裡面有七個 tracker，看了一下大概知道想要做什麼，但如果以一個資安為主打的 app，其中的 Google Tag Manager 讓人不怎麼舒服，基本上就是個 Remote code execution 的後門，光就這點能不要用就不要用...
我自己還是儘可能不要依照這些 vendor，繼續用 KeePassXC 加上同步機制，不過這對於一般人來說麻煩了不少...
在 2017 年的時候 18F 推出了美國政府的 SSO 服務 login.gov：「Government launches login.gov to simplify access to public services」，當時只支援聯邦政府的系統。
這幾天看到了新的公告，宣佈 login.gov 的服務範圍打算擴大到州政府與地方政府的計畫：「Login.gov to provide authentication and identity proofing services to a limited number of federally funded state and local government programs.」。
翻了一下開發網站「Welcome to the login.gov developer guide | login.gov」，可以看到使用的技術應該是 OpenID 與 SAML：
Select between OpenID Connect (OIDC) or SAML protocol implementation protocols. Please note that we recommend OIDC.
難得看到 OpenID 被拿出來用，記起來好了...
先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。
因為上新聞所以才動了起來 (本來都沒什麼在動)，後來提供的方法是變成可以設定的選項，但預設是關閉的，這樣一來就可以改善 Root name servers 的壓力：「Add multi-state DNS interception policy - functionality piece.」。
而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出)，在繼續觀察幾個月後，上個禮拜 Verisign 的人在 APNIC 這邊更新了消息：「How Chromium reduced Root DNS traffic」。
這是去年八月時丟出來的資料，可以看到趨勢往上：
這是後續的資料，從 87 版釋出後開始往下：
另外我覺得比較好玩的是這個，在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明：
看起來沒什麼問題，先 merge 再說... 是這樣玩嗎 XDDD
Sudo 這次的安全性漏洞頗痛的：「CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit)」。
依照 Sudo Security Alerts 這邊的說明，這次的漏洞只要是本機有執行權限的人都有機會打穿，不需要有 sudo 帳號權限：
A potential security issue exists in sudo that could be used by a local user to gain root privileges even when not listed in the sudoers file. Affected sudo versions are 1.8.2 through 1.8.31p2 and 1.9.0 through 1.9.5p1. Sudo 1.9.5p2 and above are not affected.
不限於本來就有 sudo 帳號 (但可能可執行指令受限) 就比較麻煩了，這代表從 web 之類的管道打進去以後 (可能是 www-data 身份)，就可以用這個洞取得 root 權限，另外一條路是透過資料庫打進去後 (像是 mysql 身份) 取得。
該來把一堆機器更新了...
在 Hacker News Daily 上看到「Screensaver lock by-pass via the virtual keyboard」這篇，裡面這邊題到了 screensaver lock 的有趣話題。
先講嚴肅一點的，這個 bug 被編號為 CVE-2020-25712，問題出在 xorg-x11-server 上：
A flaw was found in xorg-x11-server before 1.20.10. A heap-buffer overflow in XkbSetDeviceInfo may lead to a privilege escalation vulnerability. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
比較有趣的事情是，這個 bug 是小朋友在亂玩時拉出 virtual keyboard 觸發的：
A few weeks ago, my kids wanted to hack my linux desktop, so they typed and clicked everywhere, while I was standing behind them looking at them play... when the screensaver core dumped and they actually hacked their way in! wow, those little hackers...
然後他說他自己搞不出來：
I tried to recreate the crash on my own with no success, maybe because it required more than 4 little hands typing and using the mouse on the virtual keyboard.
另外一個人也說他家小朋友也弄出 segfault 了：
My kids came upon a similar cinnamon-screensaver segfault! I've emailed details of how to reproduce the problem to root@linuxmint.com.
小朋友超強 XDDD
Firefox 也打算放棄 ESNI，改推 ECH 了：「Encrypted Client Hello: the future of ESNI in Firefox」。
目前的 85 版 (目前的 beta) 支援了 ECH draft-08，想要玩看看的人就可以測試了：
Firefox 85 replaces ESNI with ECH draft-08, and another update to draft-09 (which is targeted for wider interoperability testing and deployment) is forthcoming.
另外一個要看的當然就是 Google 家的 Chromium 了，不過這個協定對 Google 的誘因應該是超大，有機會直接穿入中國市場... 只是不知道會不會自己搞一套 protocol。
在 Hacker News Daily 上看到「Visa Advertising Solutions (VAS) Opt Out (visa.com)」這篇講 Visa 的 Visa Advertising Solutions (VAS) Opt Out，本來以為是在討論企業賣資料的問題 (下面的討論的確是有在討論這個)，但最上面的討論居然是在討論 timing attack，像是這篇：
morpheuskafka 2 days ago [–]
Checked and the Mastercard one someone posted below doesn't seem to be vulnerable to this. My real card number and a dummy mastercard number with valid prefix and check digit both returned a 200 OK in around 1.01s. A random 16digit number without valid check digit returned 400 Bad Request in about 800ms. Decided to check that one since they have a completely useless machine-readable catchpa.
For Visa it was 835ms for valid, 762ms for dummy, prefix and check digit appears to be checked client side.
我印象中這類方式已經發展很久了 (透過網路反應時間的 timing attack)，討論裡面有提到「Exploiting remote timing attacks」這篇，也是十多年前的資料了... 不過官方網站玩起來總是有中特別爽的感覺 XDDD
不過 Visa 的這個網站前面用了 Cloudflare，用機器人掃感覺很容易被擋，這又是另外一回事了...
先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrust 幫 Let's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期，而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證，造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。
文章出來過了一個多月後，剛剛看到 Let's Encrypt 發佈消息，IdenTrust 願意再交叉簽名三年：「Extending Android Device Compatibility for Let's Encrypt Certificates」，當時猜測發文是要讓 IdenTrust 表態，看起來目的達成了...
話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣，之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...
也是個大家等蠻久的功能，AWS 總算在 Amazon Route 53 上推出 DNSSEC 了：「Announcing Amazon Route 53 support for DNSSEC」。
他需要掛 AWS KMS，這部份會有一些費用在裡面，不過應該是還好...
不過 web console 目前有個明顯的缺點：透過 Route 53 註冊的網域，又用 Route 53 自家服務的情況下，設定 DNSSEC 的整合沒有做的很好，不能直接快速設定。
現在得自己設定演算法，然後複製 public key 到另外一邊，當你有一堆網域要設定的時候就會覺得很煩了...
Cloudflare 本來在推的 ESNI 現在變成 ECH 了：「Good-bye ESNI, hello ECH!」。
上面這張圖是 ESNI，下面這張是 ECH：
可以看出來 ECH 最主要的差異是把本來的 ClientHello 都加密包起來了，伺服器會先試著解內層的 ClientHelloInner，失敗的時候會用外層的 ClientHelloOuter：
The server completes the handshake with just one of these ClientHellos: if decryption succeeds, then it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter.
看得出來 ECH 的其中一個目標是讓他看起來跟一般的 TLS 連線一樣，這樣就能順便解掉 censorship 的問題...
其中一個原因應該也是因為之前中國與俄國的直接封掉 ESNI：
In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic.
In October 2020, Russian ISPs such as Rostelecom and its mobile operator Tele2 started blocking ESNI traffic.
不過仍然還有分析 HTTPS pattern 的方式可以抓 (就是文章裡提的 traffic analysis)，目前看起來只處理了 ClientHello 本身，現在還是有機會分析 handshake 過程來擋，必須繼續改善 ECH 的協定，讓整個流程看起來都跟一般的 TLS 一樣...
可以等著看，到時候在中國的效果如何了，會不會讓國外的各大服務直接打進去呢...