利用信件裡面的 CSS,讓文字只在轉寄後才出現

在「Kobold letters: HTML emails are a risk (lutrasecurity.com)」這邊看到的 security advisory (算... 是吧?),原文在「Kobold Letters」這邊,如同標題寫的,方法其實意外的簡單...

Thunderbird 是透過 .moz-text-html>div> 指定就可以達到效果:

Outlook on the web (i.e. 雲端版本) 則是有在 id 上面增加隨機的 prefix 避免,但可以用 body>div> 避開,另外有些眉眉角角的地方會稍微複雜一點,但還是可行的:

Gmail 則是直接用個簡單的 css selector 掛上 display: none; 就 OK 了:在 sender 端 (轉寄者) 看不到,在 receiver 端則可以 (效果更好?):

比較慘的是目前大家都沒有想到比較好的解法,就算這次提到的方法被補上了,應該還是很容易被繞過去:

Unfortunately, for the foreseeable future, it is sadly not realistic to expect email clients to implement robust mitigation. This means that it is up to the users to be aware of the dangers of HTML emails and to take the necessary precautions.

另外文章裡面提到了 Can I email 這個網站,看起來如果要自己處理 email 內容的話是個不錯的資源...

Martti Malmi 與 Satoshi Nakamoto 一些早期關於 Bitcoin 的信件

Martti Malmi 把早年與 Satoshi Nakamoto 的信件公佈出來:「Satoshi - Sirius emails 2009-2011」。

主要是因為作證而整理出來的:

I did not feel comfortable sharing private correspondence earlier, but decided to do so for an important trial in the UK in 2024 where I was a witness. Also, a long time has passed now since the emails were sent.

另外這些是有備份到的部分,在改成 @aalto.fi 的部分就沒備份到了:

The archive is incomplete and contains only emails from my address @cc.hut.fi. My university email addresses changed to @aalto.fi in early 2011, and I don't have backups of those emails.

這次公開的看起來共 260 封,從 2009 到 2011 的信件,算是新出土的史料... (?)

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

Hacker News 上看到「SMTP Smuggling – Spoofing Email Worldwide (sec-consult.com)」這個攻擊,原文在「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:「https://gay-pirate-assassins.de/@moanos/statuses/01HJ8D8XQ7ZJ89HN4TZFZZ9AS8」。

Nextcloud 吃下 Roundcube

Nextcloud 官方的公告在「Open source email pioneer Roundcube joins the Nextcloud family」這邊,然後有新聞整理:「Roundcube Open-Source Webmail Software Merges With Nextcloud」,以及 Hacker News 上對應的討論:「Roundcube open-source webmail software merges with Nextcloud (phoronix.com)」。

居然看到 Roundcube 的新聞,這是個用 PHP 寫的,頗老牌的 Webmail 系統了,翻了 Wikipedia 上的資料,第一個 stable 居然是 2008 年?我以為應該更早,因為印象中當年交大的 D2 E-mail 系統在後來有用到...?

後來的情況有點微妙,2015/2016 年的時候 Roundcube 搞了 crowdfunding 結果變成一場災難:

On 3 May 2015, Roundcube announced, in partnership with Kolab Systems AG, that they planned to completely rewrite Roundcube and create Roundcube Next. A crowdfunding campaign was set up to finance the project. The goal of $80,000 was reached on June 24. The final amount raised was US$103,541.

Roundcube Next was intended to include additional features like calendar, chat and file management. This was to be implemented using WebRTC and connectors from popular services like Dropbox and OwnCloud.

However, Kolab Systems and Roundcube stopped development on the project in 2016, with no information or refunds provided to project backers, leading to a failed crowdfund. A Roundcube developer later claimed Roundcube had no ownership over the Roundcube Next campaign,[10] despite its public engagement and ownership on the crowdfund page.

這次的情況從 Hacker News 上的討論也看得出來,大家對 Nextcloud 沒什麼好感,而且 Nextcloud 本身有個 Nextcloud Mail,沒看懂到底是怎麼一回事...

Amazon SES 寄到 Gmail 受到阻擋的情況

我自己沒遇過,但是 Hacker News 上看到有人有遇到,所以記錄起來:「Tell HN: Gmail rate limiting emails from AWS SES」。

Amazon SES 預設是共用 IP pool,所以遇到這種情況不算太意外,但應該是暫時性的,不過發問的作者有提到後來的解法是花 US$25/mo 使用 Dedicated IP 解決 IP reputation 的問題 (在 id=37177533 這邊):

Thanks you all for comments. I have made a decision to subscribed to dedicated IPs (credits: @slau).

The differentiating factor between our current AWS SES plan and the competitors (mentioned in the comments) is having a dedicated IP. With our current volume, none of the competitors are anyway near AWS SES costs. So, moving to a dedicated IPs thats cost 25$ extra not only solves our issue, but also no change in code/infrastructure.

記得以前另外一個教訓是,寄信還是儘量用 IPv4 address 去寄,因為 IPv6 address 的 reputation 得養頗久... 不過這個也是很久前的事情了。

微軟的 Outlook 系統會自動點擊信件內的連結

前幾天在 Hacker News Daily 上翻到的,微軟的 Outlook 系統 (雲端上的系統) 會自動點擊信件內的連結,導致一堆問題:「“Magic links” can end up in Bing search results — rendering them useless.」,在 Hacker News 上的討論也有很多受害者出來抱怨:「“Magic links” can end up in Bing search results, rendering them useless (medium.com/ryanbadger)」。

原文的標題寫的更批評,指控 Outlook 會把這些 link 丟到 Bing 裡面 index,這點還沒有看到確切的證據。

先回到連結被點擊的問題,照文章內引用的資料來看,看起來是 2017 年開始就有的情況:「Do any common email clients pre-fetch links rather than images?」。

As of Feb 2017 Outlook (https://outlook.live.com/) scans emails arriving in your inbox and it sends all found URLs to Bing, to be indexed by Bing crawler.

在 Hacker News 上的討論也提到了像是 one-time login email 的機制也會因此受到影響,被迫要用比較費工夫的方法讓使用者登入 (像是給使用者 one-time code 輸入,而不是點 link 就可以登入)。

先記起來,以後在設計時應該會遇到,要重新思考 threat model...

ARC (Authenticated Received Chain)

標題的 ARC 是指 Authenticated Received Chain,是前陣子在 Hacker News 上看到「Gmail accepts forged YouTube emails (john-millikin.com)」這篇才發現的東西,原文在「Gmail accepts forged YouTube emails」這邊。

作者發現 Gmail 收了從不是直接從 YouTube 發出來的信件:

主要的原因是,Gmail 除了使用標準的 SPFDKIM 判斷外,還吃上面提到的 ARC。

查了一下 ARC,標準是 RFC 8617,目前還是被標成 experimental,主打是解決 forwarding 的問題,看了一下作者群是 LinkedIn (Microsoft)、GoogleValimail

ARC 這東西與之前 Google 在強推的 AMP (然後被罰) 以及現在在推的 Signed HTTP Exchanges 都有相同的味道,無視 security & privacy concern 的東西...

Ptt 信件伺服器 node.ptt.cc 查不到反解的問題

就如同標題所說的,Ptt 對外寄信的伺服器 node.ptt.cc 查不到反解的問題:

$ host node.ptt.cc
node.ptt.cc has address 140.112.172.16
$ host 140.112.172.16
Host 16.172.112.140.in-addr.arpa not found: 2(SERVFAIL)

情況大概是這樣,Ptt 使用的 140.112.172.0/27 這個網段 (尾碼從 0~31) 不是 /24 以上的範圍,而 140.112.172.0/24 是台大計中管轄範圍,所以台大就把 140.112.172.x 這段的反解 PTR record 用 CNAME 的方式指到 x.0-31.172.112.140.in-addr.arpa,像是 140.112.172.16 這樣:

;; ANSWER SECTION:
16.172.112.140.in-addr.arpa. 86400 IN   CNAME   16.0-31.172.112.140.in-addr.arpa.

然後再針對 0-31.172.112.140.in-addr.arpa 設定 NS RR 到 ns0.ptt.ccns1.ptt.cc 兩台 NS server:

;; AUTHORITY SECTION:
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns1.ptt.cc.
0-31.172.112.140.in-addr.arpa. 86400 IN NS      ns0.ptt.cc.

但是 ns0.ptt.ccns1.ptt.cc 都不見了:

$ host ns0.ptt.cc
Host ns0.ptt.cc not found: 3(NXDOMAIN)
$ host ns1.ptt.cc
Host ns1.ptt.cc not found: 3(NXDOMAIN)

導致反解查不到對應的資料 (會是 SERVFAIL):

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58463

猜了一下,看起來 ns0.ptt.cc 還活著,只是 Cloudflare 上面的 DNS record 沒設定過去:

$ dig ns0.ptt.cc @140.112.172.16

;; ANSWER SECTION:
ns0.ptt.cc.             300     IN      A       140.112.172.16

不過 ns1.ptt.cc (140.112.172.10) 看起來就沒服務了,但至少在 Cloudflare 上補個 DNS record 上去應該就會動了 (只是沒有兩台互相備援)。

關於自己架設 E-mail server 的事情

自己架設 E-mail server 的難處算是每過一陣子在 Hacker News 上就會冒出來討論的題目:「Ask HN: Why can't I host my own email?」。

收信只要有固定 IP,加上 ISP 沒有擋 TCP port 25 就倒不是問題,整個最難的點在於怎麼送信,因為會常常被標成 spam...

最基本要設定的東西大概是 SPF,但通常還是建議連 DKIM 一起搞定。另外 DMARC 也弄一下會比較好。

然後依照經驗,Gmail 擋信的機率低不少,微軟家擋信的情況就多很多 (包括免費的 E-mail 服務與付費的 Microsoft 365)...

目前一般建議是自用就過 Amazon SES,沒有低消所以個人用起來不貴...