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」。

Gmail 宣佈支援 MTA-STS

Gmail 宣佈支援 MTA-STS:「Gmail making email more secure with MTA-STS standard」。這邊提到的 MTA-STS 是透過某些設定,讓 SMTP 送信時強制使用 TLS 的機制,可以參考「SMTP 的強加密連線機制」這篇。

可以看到有 TXT,也有 .well-known 檔案:

;; ANSWER SECTION:
_mta-sts.gmail.com.     300     IN      TXT     "v=STSv1; id=20171114T070707;"

$ curl https://mta-sts.gmail.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: gmail-smtp-in.l.google.com
mx: *.gmail-smtp-in.l.google.com
max_age: 86400

如果要自己設定的話可以參考 Google 提供的「About MTA-STS and TLS Reporting」這篇,不過目前中文版文件還沒有更新,請切到英文版...

SMTP 的強加密連線機制

RFC 8461 成為正式標準 (Standards Track),描述 Mail server 到 mail server 之間的強加密連線機制:「SMTP MTA Strict Transport Security (MTA-STS)」。

Policy 設定的方法有好幾種:

第一種是透過 _mta-stsTXT record 設定,這點通常會配合 DNSSEC 確保 DNS 的查詢沒有被改。

第二種是透過 HTTPS 在某個特定的 host (mta-sts) 取得 policy 檔案。像是對 example.com 的資料會從 https://mta-sts.example.com/.well-known/mta-sts.txt 取得。

第三種是透過 HTTPS 的 certificate 裡面帶 mta-sts 資訊出來。

不只有 DNS 可以設定,使得整個架構變得有點複雜...

DHS 要求郵件系統都必須使用 STARTTLS、DMARC,並且全面禁用 RC4 與 3DES

Twitter 上看到 18F 貼了 DHS 的新規定:「Enhance Email and Web Security」。

郵件系統的部份,要求要有 STARTTLS,並且設定 SPFDMARC。另外禁用 SSLv2 SSLv3,以及 RC43DES

網站的部份,則是要求 HTTPS 以及 HSTS。另外也與郵件系統一樣禁用 SSLv2、SSLv3,以及 RC4 與 3DES。

不只 18F 一個單位在推動,這樣整體的速度才會加快...

Amazon EC2 會對 Port 25 的連線數量限制

起因於一台 ap-northeast-1 的機器 (東京) 會使用 us-west-2 的 SES (美西,奧勒岡),然後發現信延遲的有點嚴重,看 mail log 發現是因為連線 timeout。

查了以後發現在「Amazon SES SMTP Issues」這邊就有提到 EC2 instance 對 port 25 有限制:

You are sending to Amazon SES from an Amazon EC2 instance via port 25 and you cannot reach your Amazon SES sending limits or you are receiving time outs—Amazon EC2 imposes default sending limits on email sent via port 25 and throttles outbound connections if you attempt to exceed those limits. To remove these limits, submit an Amazon EC2 Request to Remove Email Sending Limitations. You can also connect to Amazon SES via port 465 or port 587, neither of which is throttled.

按照建議,直接走 port 587 就可以解決,另外一個方法是開 support ticket 請 AWS 解除:「How do I remove the throttle on port 25 from my EC2 instance?」。

Amazon EC2 throttles traffic on port 25 of all EC2 instances by default, but you can request that this throttle be removed for your instance at Request to Remove Email Sending Limitations (you must sign in with your root account credentials). Provide a description of your use case for sending email, and then choose Submit.

還是改走 port 587 比較簡單一點...

Gmail 要開始導入 SMTP Strict Transport Security 了

SMTP MTA Strict Transport Security 算是 SMTP STARTTLS 裡的 HSTS 機制,而 Google 的人在 RSA Conference 上提出要開始用了:「SMTP STS Coming Soon to Gmail, Other Webmail Providers」。

Elie Bursztein, the head of Google’s anti-abuse research team, said at RSA Conference that SMTP STS will be a major impediment to man-in-the-middle attacks that rely on rogue certificates that are likely forged, stolen or otherwise untrusted. Google, Microsoft, Yahoo and Comcast are expected to adopt the standard this year, a draft of which was submitted to the IETF in March 2016.

補上去後對於 SMTP 的隱私保護就會更好了...

自建 Mail System 的難度

Hacker News 上的「Ask HN: Is it possible to run your own mail server for personal use?」這篇道出了現在自建 mail system 的難度。作者遇到信件常常被各大 mail 服務歸類成 spam:

The problem is making sure my mail is not marked as spam by the major MTAs out there, gmail and hotmail both mark my mails as spam.

整理一下現在自己建 mail system 要做到哪些事情:

  • 確認 IP (包括 IPv4/IPv6) 沒有列入任何 Open Relay 清單中。
  • 確認 IP 的反解可以查出對應的正解。
  • 確認 SPF 設定。
  • 確認送出去的信件有 DKIM 簽名,而且 DNS 也有設上對應的設定。
  • 確認 TLS 的發送與接收都正常。
  • 確認 DMARC 機制正確運作。

如同「Exercising Software Freedom in the Global Email System」這邊講的,現在要自己搞 mail system 超累...

Gmail 的 SMTP 將拔掉對 SSLv3 與 RC4 的支援

Gmail 的 SMTP 決定在近期內拔掉 SSLv3 與 RC4 了:「Disabling support for SSLv3 and RC4 for Gmail SMTP in 30 days」。

Gmail 的 SMTP 應該是 Google 少數還支援 SSLv3 與 RC4 的服務?總算是要拔了...

Gmail 將會提示沒有支援 STARTTLS 的信箱

Gmail 界面將會提示不支援 STARTTLS 的信箱:「Making email safer for you」。

先確認 msa.hinet.net 的 MX record:

;; ANSWER SECTION:
msa.hinet.net.          86174   IN      MX      0 msa-smtp-mx1.hinet.net.
msa.hinet.net.          86174   IN      MX      0 msa-smtp-mx2.hinet.net.

以及不支援 STARTTLS (在 EHLO 後不會出現 STARTTLS 選項):

$ t msa-smtp-mx1.hinet.net 25
Trying 168.95.6.53...
Connected to msa-smtp-mx1.hinet.net.
Escape character is '^]'.
220 msa.hinet.net ESMTP Sendmail 8.14.2/8.14.2; Thu, 11 Feb 2016 04:52:16 +0800 (CST)
EHLO localhost
250-msa.hinet.net Hello 114-32-152-63.HINET-IP.hinet.net [114.32.152.63], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
QUIT
221 2.0.0 msa.hinet.net closing connection
Connection closed by foreign host.

打開 Gmail 在收件人的地方輸入 test@msa.hinet.net 後,就會跳出紅色鎖頭表示不支援 STARTTLS。