Firefox 與 Chrome 處理 Intermediate CA 的不同方式

Fediverse 上看到「The recording of my "Browsers biggest TLS Mistake" lightning talk at #37C3」這個,這是出自 37C3 的 lightning talk,影片不長,只有五分鐘,可以在「Browsers biggest TLS mistake」這邊看到。

正常的 HTTPS server 會送出 Intermediate CA certificate 與自己的 TLS certificate:

當伺服器端沒有設定好,通常是只送出自己的 TLS certificate:

這種情況在 Firefox 裡有處理,軟體本身會預載所有的 Intermediate CA 避免這種問題 (當然會需要跟著軟體更新),這點在三年前有提到過:「Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率?」,也就是這張投影片提到的情況:

Chrome 則是去看目前的 cache 資料,找看看是不是在其他地方有看到適合的 Intermediate CA 可以接起來:

這好像可以解釋為什麼之前遇到類似的問題的時候,在 Chrome 上面會需要進 chrome:// 裡面清東西才能重製...

SMTP Smuggling 的安全漏洞 (LF 的問題),以及 Postfix 被無視的問題

Hacker News 上看到「SMTP Smuggling – Spoofing Email Worldwide (」這個攻擊,原文在「SMTP Smuggling - Spoofing E-Mails Worldwide」。

開頭的圖片把大方向解釋出來了,這是利用不同的 SMTP server 實作上對怎麼結束 DATA 的處理方式不同,這個問題會出現在兩組 SMTP server 丟信件時:

更細節的說,是遇到對於非 \r\n.\r\n (非 CRLF) 的處理方式不同時,就會產生出可以攻擊的空間:

這樣的攻擊因為可以偽造所有的 header,加上內部 SMTP server 在 IP 層看不到實際的 IP,就可以讓攻擊者完全繞過 SPF 檢查的部分。

從 SMTP 規格說起,在 SMTP 規格上都是用 \r\n (CRLF) 當作換行,這點從 1982 年 (41 年前) 已經 obsoleted 的 RFC 821 可以看到裡面全部都是使用 \r\n 當作換行。

後來更新的 RFC 2821 (2001,也已經 obsoleted) 與 RFC 5321 (2008,目前的標準) 則是除了描述 \r\n.\r\n 外,有提到禁止把 \n.\n 當作 DATA 的結尾辨識:

In particular, the sequence "<LF>.<LF>" (bare line feeds, without carriage returns) MUST NOT be treated as equivalent to <CRLF>.<CRLF> as the end of mail data indication.

但除了被禁止的 \n.\n 外,這次的攻擊用了其他的排列組合嘗試。

在 GMX、Ionos 以及 Microsoft Exchange Online 的 SMTP server 上發現都吃 \n.\r\n

However, as already mentioned, SMTP smuggling doesn't work for every receiving inbound SMTP server and, in this case, requires inbound SMTP servers to accept <LF>.<CR><LF> as end-of-data sequence.

Same as GMX and Ionos, Exchange Online allowed smuggling via a <LF>.<CR><LF> end-of-data sequence as well, which makes it possible to smuggle from every domain pointing their SPF record to Exchange Online.

而 Cisco Secure Email (Cloud) Gateway 支援 \r.\r

By default, Cisco Secure Email (Cloud) Gateway accepts . as end-of-data sequence, which does not get filtered by the following SMTP servers when sending outbound:

另外看了一下 Postfix 這邊的情況,可以看到「SMTP Smuggling」這份資料,裡面可以看到 Postfix 因為預設支援 \n.\r\n 也受到影響:

One different email service B that does support broken line endings in SMTP such as in <LF>.<CR><LF>.

Postfix is an example of email service B.

然後可以看到作者 Wietse Venema 直接在業面上公開點名 SEC Consult (這次安全漏洞的發現者) 沒有先聯絡的問題:

Unfortunately, criticial information provided by the researcher was not passed on to Postfix maintainers before publication of the attack, otherwise we would certainly have convinced SEC Consult to change their time schedule until after people had a chance to update their Postfix systems.

在 Postfix 的 e-mail 公告「[pfx-ann] SMTP Smuggling, workarounds and fix」裡面講的更硬 (non-responsible disclosure process):

As part of a non-responsible disclosure process, SEC Consult has published an email spoofing attack that involves a composition of email services with specific differences in the way they handle line endings other than <CR><LF>.

從最早的 snapshot (20231218105045 這份) 可以確認他們有發現 Postfix 的問題,但 timeline 上沒有接觸 Postfix 的團隊。

後續的更新把溝通問題推給了 CERTVINCE platform

As documented in the timeline of the blog post, the vulnerabilities were initially identified in June 2023 and after further internal research we contacted the specific, affected vendors (Microsoft, Cisco, GMX/Ionos). GMX and Microsoft fixed the issues promptly. But after receiving some feedback from Cisco, that our identified vulnerability is just a feature of the software and not a bug/vulnerability, we contacted CERT/CC on 17th August to get some help for further discussion with Cisco and involve other potentially affected vendors (such as sendmail) through the VINCE communication platform.

現在 community 這邊則是在醞釀提議取消他們在 37c3 上面的 talk:「」。