穿越 Firewall 的作法

先看到「SSH over HTTPS (trofi.github.io)」這篇,原文「SSH over HTTPS」講怎麼利用 HTTPS 加上 CONNECT 指令穿過去。

作者有先介紹背景,他需要在醫院待個幾天,而醫院有免費的 WiFi 可以上網,但限制很多,基本上 TCP 的部分只有 80/tcp 與 443/tcp 會通,另外他有行動網路可以用 (但應該不是吃到飽的?),可以當作在現場直接設定 bypass 機制的工具:

I planned to spend 1-2 days in the hospital and did not plan to use the laptop.But now I am stuck here for the past two weeks and would like to tinker on small stuff remotely. The hospital has free Wi-fi access.

The caveat is that hospital blocks most connection types. It allows you only to do HTTP (TCP port 80) and HTTPS (TCP port 443) connections for most hosts. DNS (UDP port 53) and DoT (TCP port 853) seem to work as well at least for well-known DNS providers.

But SSH (TCP port 22 or most other custom ports) is blocked completely.

I wondered how hard would it be to pass SSH through HTTP or HTTPS. I had a GSM fallback so I could reconfigure remote server and try various solutions.

作者的方法就是在 TLS/SSL connection 上面跑 SSH,以前幹過,但就如同 comment 裡面提到的,Cisco 的 AnyConnect (主要是用 open-source client 的 OpenConnect 以及 open-source server 的 ocserv) 比較彈性,而且 AnyConnect 的協定會自動嘗試 UDP-based 的 DTLS,傳輸效率會比 TCP-based 的協定好,另外在 iOS 上可以直接裝 app store 裡面 Cisco 官方的 client 來用。

但從作者的其他文章看起來應該也是熟門熟路了,會這樣做應該是手上有 HTTPS 的 apache server 可以設定來用。

另外作者雖然沒寫出來,但想法應該是有 SSH 就可以在 command line 透過 -D 生出 SOCKS 服務當 proxy 讓其他程式使用,常見的應用程式大多都支援。

應該就是臨時要在醫院裡面待個一兩天時的暫時性方案,如果常態會遇到的話應該是會架 ocserv 來繞...

CloudFront 支援 4096-bit RSA 的 SSL/TLS certificate 了

CloudFront 總算支援 4096-bit 的 RSA SSL/TLS certificate 了:「Amazon CloudFront now supports 4096-bit RSA TLS certificates」。

翻了一下 AWS ACM,看起來是 2020 年以前就支援 4096-bit RSA SSL/TLS certificate 了,CloudFront 晚蠻多的...

另外查了一下目前的強度,NSA 給出 2048-bit RSA 對到 112-bit strength,而 3072-bit RSA 對到 128-bit strength;至於 4096-bit RSA,目前是估算大約在 140-bit strength,有點微妙的數字。

看起來主要應該是給 compliance 需求使用的,有些舊的 library 未必支援 ECC 類的演算法,還是得透過拉高 RSA key size 來增加安全性。

Amazon RDS 推出 RDS Extended Support

AWSAmazon RDS 推出了 MySQL 5.7 與 PostgreSQL 11 的 RDS Extended Support 服務:「Your MySQL 5.7 and PostgreSQL 11 databases will be automatically enrolled into Amazon RDS Extended Support」。

直接看官方整理的這張表格比較清楚:

基本上都到 2027Q1 左右,差不多再多支援三年。

另外表上的時間有些接不起來的地方,則是在 Note 的地方說明。

其中 MySQL 5.7 的部分分成兩塊,其中 RDS for MySQL 5.7 的部分是比較清楚的:原來的 RDS standard support 到 2024/02/29,後續從 2024/03/01 馬上接付費的 RDS Extended Support。

Aurora MySQL 2 的 RDS standard support 則是直接一路到 2024/10/31,然後 2024/11/01~2024/11/30 的 RDS Extended Support 不收費,從 2024/12/01 開始收費:

RDS Extended Support for Aurora MySQL 2 starts on November 1, 2024, but will not be charged until December 1, 2024. Between November 1 and November 30, all Aurora MySQL 2 clusters are covered under RDS Extended Support.

而 PostgreSQL 11 的部分都一樣 (RDS for PostgreSQL 11 與 Aurora PostgreSQL 11),原來的 RDS standard support 到 2024/02/29,而 2024/03/01~2024/03/31 的 RDS Extended Support 則是免費的,從 2024/04/01 開始收費:

RDS Extended Support for PostgreSQL 11 starts on March 1, 2024, but will not be charged until April 1, 2024. Between March 1 and March 31, all PostgreSQL 11 instances on Aurora and RDS are covered under RDS Extended Support.

然後費用的部分也查的到了,是用 vCPU-hour 計算的,四條產品線的價位在 us-east-1 的計價是相同的,前面兩年是 $0.1/vCPU/hr,而第三年是 $0.2/vCPU/hr。

由於 RDS 的機器最少是 2 vCPU,所以一台機器至少要多付 $0.2/hr 的費用,這個費用基本上會比 RDS 費用還貴。

這邊給個比較的數字,同樣在 us-east-1 上,2 vCPU + 8GB RAM 的 db.t4g.large 要 $0.129/hr,而一樣 2 vCPU + 8GB RAM 如果是 db.m7g.large 則是 $0.168/hr,都還沒有 RDS Extended Support 貴;要到 r7g.large 這種以記憶體導向的 $0.1071/hr 才差不多跟上一樣的價錢。

另外一個方法應該就是改成自己在 EC2 上架設?這樣成本會因為 RDS 轉 EC2 的下降,整體大約會降到 1/4...

不過應該也會有公司就是用下去,在上面跑的好好而且很賺錢的東西就不想亂動...

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

Beeper 宣佈新的手機號碼註冊方式,另外後續應該不會再更新了

Beeper 連續兩篇更新:「iMessage and Phone Registration Are Back - Kinda」、「Beeper - Moving Forward」。

第一篇提到新的手機號碼註冊方式,需要用舊的 iPhone 手機 jailbreak (iPhone 6iPhone X):

📱 Have an old iPhone (6/6s/SE1/7/8/X) and a Mac or Linux computer (Raspberry Pi works) - you’re in luck! Follow our instructions (takes only 10-15 minutes) to jailbreak your iPhone, install a Beeper tool to generate iMessage registration code, then update to the latest Beeper Mini app and enter your code. Phone number registration will now work! Leave the iPhone plugged into power, at home, connected to wifi.

從「How To - Register Phone Number With iMessage」可以看到是用 jailbreak 的方式取得對應的 token (code) 再丟進 Beeper Mini:

第二篇則是提到貓與老鼠的競賽中不太可能贏:

As much as we want to fight for what we believe is a fantastic product that really should exist, the truth is that we can’t win a cat-and-mouse game with the largest company on earth.

然後後續會把力氣放到新的 IM 開發:

In the new year, we’re shifting focus back to our long-term goal of building the best chat app on earth.

故事差不多就到這邊...?

microsoft.com 的 DNS 出包

Hacker News Daily 上的「Tell HN: Microsoft.com added 192.168.1.1 to their DNS record」這邊看到的,看起來是某種 misconfiguration 造成 microsoft.comA record 除了給正常的 IPv4 address 外,還給出了 192.168.1.1192.168.1.0 的 IPv4 address。

不過裡面比較有趣的是 id=38704301 這個,提到他反而查不到,看 log 發現被 dnsmasq 認定是 DNS rebinding 的攻擊而擋下來不回應任何 IP address:

I was getting an empty answer for microsoft.com. Turns out my dnsmasq is blocking it:

  $ dig microsoft.com. | grep EDE
  ; EDE: 15 (Blocked)

  resolver.log:Dec 20 00:43:57 router dnsmasq[8172]: possible DNS-rebind attack detected: microsoft.com

翻了 dnsmasq 的 manpage,可以看到這個功能:

--stop-dns-rebind

Reject (and log) addresses from upstream nameservers which are in the private ranges. This blocks an attack where a browser behind a firewall is used to probe machines on the local network. For IPv6, the private range covers the IPv4-mapped addresses in private space plus all link-local (LL) and site-local (ULA) addresses.

id=38704159 這邊也有類似的情況,不過這邊是提到 OpenWrt

microsoft.com is currently IPv6-only on my network, because OpenWrt's DNS rebinding protection filters out the A records:

  $ ping -4 microsoft.com
  ping: microsoft.com: Address family for hostname not supported

  $ ping -6 microsoft.com
  PING microsoft.com(2603:1030:c02:8::14 (2603:1030:c02:8::14)) 56 data bytes
  64 bytes from 2603:1030:c02:8::14 (2603:1030:c02:8::14): icmp_seq=1 ttl=112 time=68.4 ms

HashiCorp 的 Vault 也有 fork 了:OpenBao

當初 HashiCorp 宣布改 license (可以參考之前寫的「HashiCorp 將放棄 Open Source License,改採用 BSL 1.1」),用的最多的 Terraform 就馬上有人 fork 出來:「OpenTF 宣佈從 Terraform 最後一個 Open Source 版本 fork 出來」、「OpenTF (Terraform 的 fork) 改名為 OpenTofu」。

Vault 也受到影響,當時花了一些時間找看看有沒有人 fork,沒找到後就改用 etcd (然後搭配 etcd-adminer 以及 oauth2-proxyGoogle Workspace 的 SSO),後來就沒有追這個問題了...

剛剛才看到 fork 的消息出來了:「OpenBao – FOSS Fork of HashiCorp Vault (github.com/openbao)」,專案在「OpenBao」這邊,要注意目前只有 development branch 有東西,main branch 目前是空的,而且 Hacker News 上討論也有提到現在還在 early stage,很多東西都還在整理。

之後有機會再回來看看...

蘋果的衛星 SOS 服務對 iPhone 14 用戶免費延長一年

去年十二月蘋果對 iPhone 14 開通了衛星 SOS 服務:「iPhone 14 的 Emergency SOS via satellite (衛星求救服務) 在北美開通」,然後蘋果決定延長一年:「Apple extends Emergency SOS via satellite for an additional free year for existing iPhone 14 users」。

而且看起來已經開放到十六個區域了:

Now also available on the iPhone 15 lineup in 16 countries and regions, this innovative technology — which enables users to text with emergency services while outside of cellular and Wi-Fi coverage — has already made a significant impact, contributing to many lives being saved. Apple today announced it is extending free access to Emergency SOS via satellite for an additional year for existing iPhone 14 users.

在「Use Emergency SOS via satellite on your iPhone」這邊有找到目前開放的地區,算了一下的確是十六個:

Emergency SOS via satellite is available in Australia, Austria, Belgium, Canada, France, Germany, Ireland, Italy, Luxembourg, the Netherlands, New Zealand, Portugal, Spain, Switzerland, the U.K., and the U.S.

北美洲 (美加) 與大西洋洲 (紐澳) 沒什麼問題,不過歐洲那些區域看起來偏西歐,有點像是衛星訊號的涵蓋性,另外可能還有當地法規的問題?不然以義大利與奧地利的涵蓋範圍,摩納哥與斯洛維尼亞看起來應該也是可以被涵蓋的...

FreeBSD 14.0 釋出

FreeBSD 14.0-RELEASE 的公告也出來了:「FreeBSD 14.0-RELEASE Announcement」,比較完整的 release notes 在「FreeBSD 14.0-RELEASE Release Notes」。

先從官方列的 highlight 來看,首先比較重要的是 GENERIC kernel 支援 1024 cores:

FreeBSD supports up to 1024 cores on the amd64 and arm64 platforms.

看了一下 commit log 是從 256 變成 1024

先就 x86-64 這邊來看,目前「家用」最多的應該是 AMD7995WX (96 cores),舊版的 256 限制應該也還能撐住,但看 commit log 有提到,主要是預期這幾年應該會有更暴力的機器出現。

另外一塊是伺服器端,Intel 這邊有 8 sockets 的版本 (參考「Intel Xeon Sapphire Rapids to Scale to 4 and 8 Sockets」),如果都是接 8490H 的話就是 480 cores 了。

ARM 的話好像也可以堆,但不熟...

另外一個提到的重點是 TCP 預設的 congestion control 改成 CUBIC

The default congestion control mechanism for TCP is now CUBIC.

翻 commit log 可以看到是從 NewReno 換成 CUBIC 的,這樣就跟 Linux kernel 預設值一樣了。

再來比較重要的是在 release notes 裡面提到的,FreeBSD 15.0 將會拔光 32-bit 環境的支援,只留 armv7,這代表 Raspberry Pi 第一代的 armv6 也被淘汰掉了:

FreeBSD 15.0 is not expected to include support for 32-bit platforms other than armv7. The armv6, i386, and powerpc platforms are deprecated and will be removed. 64-bit systems will still be able to run older 32-bit binaries.

然後有些我自己翻覺得還蠻有趣的。

首先是看到 non-root 的 chroot

The chroot facility supports unprivileged operation, and the chroot(8) program has a -n option to enable its use. a40cf4175c90 (Sponsored by EPSRC)

然後把 OpenSSH 內對 FIDO/U2F 的支援開起來了:

The use of FIDO/U2F hardware authenticators has been enabled in ssh, using the new public key types ecdsa-sk and ed25519-sk, along with corresponding certificate types. FIDO/U2F support is described in https://www.openssh.com/txt/release-8.2. e9a994639b2a (Sponsored by The FreeBSD Foundation)

ASLR 預設開啟:

Address Space Layout Randomization (ASLR) is enabled for 64-bit executables by default. It can be disabled as needed if applications fail unexpectedly, for example with segmentation faults. To disable for a single invocation, use the proccontrol(1) command: proccontrol -m aslr -s disable command. To disable ASLR for all invocations of a binary, use the elfctl(1) command: elfctl -e +noaslr file. Problems should be reported via the problem reporting system, https://bugs.freebsd.org, or posting to the freebsd-stable@FreeBSD.org mailing list. b014e0f15bc7 (Sponsored by Stormshield)

然後先前被罵臭頭的 WireGuard 支援也放回來了:(「FreeBSD & pfSense 上的 WireGuard 問題」)

The kernel wg(4) WireGuard driver has been reintegrated; it provides Virtual Private Network (VPN) interfaces using the WireGuard protocol. 744bfb213144 (Sponsored by Rubicon Communications, LLC ("Netgate") and The FreeBSD Foundation)

然後看到 Netflix 贊助的 kTLS 支援 TLS 1.3:

KTLS (the kernel TLS implementation) has added receive offload support for TLS 1.3. Receive offload is now supported for TLS 1.1 through 1.3; send offload is supported for TLS 1.0 through 1.3. 05a1d0f5d7ac (Sponsored by Netflix)

然後 FreeBSD 長久以來 root 預設用的 /bin/csh 改成 /bin/sh 了:

The default shell for the root user is now sh(1), which has many new features for interactive use. d410b585b6f0

預設的 MTA 變成 dma (Dragonfly Mail Agent),看名字加上翻了一下 manpage,確認是從 Dragonfly BSD 移植過來的:

The default mail transport agent (MTA) is now the Dragonfly Mail Agent (dma(8)) rather than sendmail(8). Configuration of the MTA is done via mailer.conf(5). sendmail(8) and its configuration remain available. a67b925ff3e5

然後 portsnap 被拔掉了,現在就建議直接用 git 拉了,算是功成身退了:

The portsnap(8) utility has been removed. Users are encouraged to fetch the ports tree by using pkg install git and then git clone https://git.FreeBSD.org/ports.git /usr/ports. df53ae0fdd98

而 mergemaster 也被換成 etcupdate 了:

mergemaster(8) has been deprecated. Its replacement is etcupdate(8). 398b12691b4f (Sponsored by The FreeBSD Foundation)

然後支援 tarfs,而且可以用 zstd

The tarfs(5) file system has been added, which is backed by POSIX tar archives optionally compressed with zstd(1). 69d94f4c7608 (Sponsored by Juniper Networks, Inc.) (Sponsored by Klara, Inc.)

好久沒看 FreeBSD 的 release notes...

從 e-mail 取得電話號碼

Hacker News 上看到 2019 年的文章:「From email to phone number, a new OSINT approach (2019) (martinvigo.com)」,原文在「From email to phone number, a new OSINT approach」。

用的原理是每一家在 recovery 時都會透漏電話號碼的不同部位,從截圖可以看到像是 PayPal 給的是區碼地一碼加上後三碼:

然後他整理出來:

Leaks first three and last two digits:
eBay

Leaks first and last four digits:
Paypal

Leaks first and last two digits:
Yahoo

Leaks last four digits:
Lastpass

Leaks last two digits:
Google
Facebook
Twitter
Hotmail
Steam

接著文章裡面介紹了其他的方法再縮小可能性,然後再反過來利用電話號碼查 e-mail,像是 Amazon

後面則是示範了這整套過程可以自動化。

可以確認電話號碼後可以做的事情就很多了,文章裡面提到的也只是一小塊...