ISP 偽造出合法的 SSL certificate,對放在德國的 xmpp.ru 進行 MITM 監聽

標題有點複雜,先講一下 http-01 認證,這是目前 Let's Encrypt 上最常被使用的認證方式,是透過 HTTP 協定完成認證,你只要能回答 http://www.example.com/.well-known/acme-challenge/XXX 的內容就能過。

一般來說,這個 HTTP 位置只有這台伺服器的 owner 才有辦法提供,也就能確保不是任何人都可以申請。

但因為這邊走的是 HTTP,對於 ISP 這種比較特別的身分來說,他可以從中架設 HTTP 的 MITM Proxy 做到這件事情。

而有了合法的 SSL certificate 之後,中間的 MITM Proxy 就不只能聽 HTTP 了,還可以聽 HTTPS 的內容 (甚至修改內容)。

這次發生的事情就是在德國的 LinodeHetzner 機房內的服務,俄羅斯最大的 XMPP 服務 xmpp.ru 被搞出這件事情 (XMPP 是一個開放協定,不熟的話可以想像成類似 Line 或是 Telegram 的服務,但 XMPP 是開放協定,可以用自己喜歡的軟體連上):「Encrypted traffic interception on Hetzner and Linode targeting the largest Russian XMPP (Jabber) messaging service」。

他們在 Hetzner 的伺服器上有發現 network offline 的訊號:

[Tue Jul 18 12:58:29 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Down
[Tue Jul 18 12:58:48 2023] igb 0000:04:00.0 enp4s0: igb: enp4s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

而在這個 network offline 的時間不久後 Let's Encrypt 發出了 xmpp.ru 與 jabber.ru 的 SSL certificate (crt.sh 上可以查到,在 99976947049997621208):

18 July 2023 issuing time is about the same when Hetzner server has lost network link for several seconds.

這些徵兆符合改接到 MITM Proxy 上的行為。

這次的事情很大條,因為這些伺服器是在德國,不是在俄羅斯... 事情才剛開始被報導出來,後續得繼續追蹤,而且應該也會促成新的機制被引入?

Mitmproxy 7 支援 TLS over TCP 的分析了

Hacker News 首頁上看到 Mitmproxy 7 的消息:「Mitmproxy 7」。

比較重要的功能應該就是可以針對任意的 TLS 連線攔截分析了:

不過像是 STARTTLS 這類先在 plaintext 溝通,然後送出指令進入 TLS 的方式,目前就還沒支援:

Opportunistic TLS (STARTTLS) is not supported yet, but regular TCP-over-TLS just works!

另外是可以分析 WebSocket 內的傳輸資料:

應該是跑個 pip install -U mitmproxy 就可以升級了... (如果先前是用 pip 安裝的話)

重設密碼 + Social Engineering

在「The password reset MitM attack」這邊看到 PRMitM (Password Reset Man-in-the-Middle) 這樣的攻擊,原始論文在「The Password Reset MitM Attack」這邊可以取得。

用圖說明基本版的攻擊方式:

另外列出了各大站台的狀態:

以及各家簡訊的文字,可以發現不是每一家都有把產品的名稱寫上去:

這方法好有趣啊... XD

STARTTLS 的不完整性以及大規模監控電子郵件

在「Don’t count on STARTTLS to automatically encrypt your sensitive e-mails」這邊提到了 STARTTLS 的問題,引用「Neither Snow Nor Rain Nor MITM ... An Empirical Analysis of Email Delivery Security」這篇論文的說明。

SMTP 裡 STARTTLS 的設計雖然可以加密,但仲所皆知,可以阻擋 EHLO 回應結果避免建立 STARTTLS 連線,而讓發送端改用傳統未加密的 SMTP 傳輸。而研究發現其實目前就有大規模的這種監控行為:

可以看到突尼西亞的監控情況遠超過想像...

目前的想法是發展一套類似 HSTS 的 Trust on first use 設計,也許在這份報告出來後可以加速催生...

OpenSSL 安全通報連發...

熱騰騰的「OpenSSL Security Advisory [05 Jun 2014]」:

  • SSL/TLS MITM vulnerability (CVE-2014-0224)
  • DTLS recursion flaw (CVE-2014-0221)
  • DTLS invalid fragment vulnerability (CVE-2014-0195)
  • SSL_MODE_RELEASE_BUFFERS NULL pointer dereference (CVE-2014-0198)
  • SSL_MODE_RELEASE_BUFFERS session injection or denial of service (CVE-2010-5298)
  • Anonymous ECDH denial of service (CVE-2014-3470)

這太熱鬧了,第一個 security issue 可以在 MITM 的情況下,強迫選用比較差的 cipher:

An attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers.

第三個則有可能直接爆破執行程式碼:

A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server.

接下來幾天對 SA 來說又是無止盡的升級地獄...

法國政府 ANSSI 偽造 Google 的 SSL 憑證被抓到...

GoogleGoogle Chrome 裡面有放一段 SSL 白名單 (transport_security_state_static.json),針對某些特定 domain 只允許特定的 CA 所發出來的 SSL 憑證,另外當發現異常時也會回報。

這個機制可以保證在白名單內的網域比較不容易被 CA 搞到。

前幾天 Google 偵測到法國政府 ANSSI 的一個中介憑證發行單位 (Intermediate certificate authorities) 發出 Google 所擁有網域的 SSL 憑證:「Further improving digital certificate security」。

這也是繼一年前 TURKTRUST 發出的 *.google.com 以來再次被這個機制抓到的案例:「這次 TURKTRUST 誤發 *.google.com SSL 憑證...」。

同時,這也是首次政府機關相關的 CA 搞 MITMA (Man-in-the-middle attack)。

ANSSI 官方的說法是「誤發」:「Revocation of an IGC/A branch」,不過可信度... XD

Google 後來在 12/12 再次更新公告文章,決定把 ANSSI 的 CA 信任範圍限縮到法國相關的網域,共 13 個。(*.fr*.gp*.gf、...)

另外可以參考 Mozilla 在收到 Google 通知後的公告:「Revoking Trust in one ANSSI Certificate」。

Nokia 監控使用者連線...

Nokia 被抓到 Xpress Browser 會監控使用者連線,不論是 HTTP 或是 HTTPS:「Nokia Running A Man In The Middle Attack To Decrypt All Your Encrypted Traffic, But Promises Not To Peek」。

兩篇原始發現人的文章,第一篇「Nokia phone forcing traffic through proxy」是講 HTTP 的部份,第二篇「Nokia’s MITM on HTTPS traffic from their phone」是 HTTPS 的部份。

實際運作是類似於 HTTPS proxy 的作法。在「Nokia: Yes, we decrypt your HTTPS data, but don’t worry about it」有詢問 Nokia 後的官方回覆:

"Importantly, the proxy servers do not store the content of web pages visited by our users or any information they enter into them," the company said. "When temporary decryption of HTTPS connections is required on our proxy servers, to transform and deliver users’ content, it is done in a secure manner.

"Nokia has implemented appropriate organizational and technical measures to prevent access to private information. Claims that we would access complete unencrypted information are inaccurate."

GIGAOM 的翻譯簡單多了:

we decrypt your data, but trust us, we don’t peek. (對,我們的確這樣作,不過相信我們,我們沒有監聽。)

你真的相信這鬼話嗎 XDDDDDDDDD

以這張圖結尾: