美國正在立法禁用大疆的產品

在「DJI ban passes the House and moves on to the Senate (dronedj.com)」這邊看到的,原文在「DJI ban passes the House and moves on to the Senate」這邊。

目前眾議院已經過過了,裡面提到 H.R.2864 (Countering CCP Drones Act):

One of these sections, H.R. 2864, or the Countering CCP Drones Act, was added to the bill and can be found under Section 1722. For those who are just hearing about this for the first time, it would remove DJI’s ability to get approval from the FCC, banning any future drones from being imported and possibly grounding current drones.

在官方的官面上則是直接列出大疆 (DJI):

Countering CCP Drones Act

This bill requires the inclusion of telecommunications and video surveillance equipment or services produced or provided by Shenzhen Da-Jiang Innovations Sciences and Technologies Company Limited (a Chinese drone maker commonly known as DJI Technologies) on a list of communications equipment or services determined by the Federal Communications Commission (FCC) to pose an unacceptable risk to U.S. national security. Current law prohibits the use of federal funding available through specified FCC programs for purchasing or maintaining listed equipment or services.

現在是在聯邦禁用,看起來打算提升警戒列為國安等級,打算全國禁用?

OpenSSH 要內建阻擋系統了

在「OpenSSH introduces options to penalize undesirable behavior」這邊看到 OpenSSH 要內建阻擋系統了,算是取代了 fail2ban 的一些功能?

還蠻... 特別的?不知道為什麼現在這個時間點會想要實作這個功能?

這個功能在 OpenBSD 7.6 上面預設會開啟,這點不確定其他 distribution 會怎麼安排:

So now we know: starting with OpenBSD 7.6, PerSourcePenalties will be enabled by default, and admins who do not themselves run PF or other network translation mechanisms will need to keep the consequences of inconsiderate NAT use in mind.

超長網域名稱會遇到的 TLS certificate 問題

在「L(O*62).ONG: Make your URL longer (looooooooooooooooooooooooooooooooooooooo...)」這邊看到的有趣東西,網站是「L(o*62).ong - Make your URL longer」,網站的主人還在搞事就被貼到 Hacker News 上,所以他就上來說明一下發生了什麼事情...

id=40543697 這邊提到網域名稱過長導致撞到 TLS certificate 中 commonName (CN) 欄位長度限制的問題:

The longest segment of a domain name is 63 characters. The maximum length of an HTTPS certificate commonName is 64 characters.

This caused Cloudflare, Vercel, and Netlify to be unable to use Let's Encrypt to sign HTTPS certificates (because they used the domain name as the commonName), but Zeabur can use Let's Encrypt to sign HTTPS certificates.

Finally, the Cloudflare certificate was switched to Google Trust Services LLC to successfully sign.

不過後面有人提到 commonName 在網頁用的 TLS certificate 已經 deprecated 很久了,而 Let's Encrypt 在 2023 年的時候已經支援 commonName 留空,改用 Subject Alternative Name,可以到 255 chars。

留言裡面所連結的 Let's Encrypt 公告上面也提到了類似的事情:「Simplifying Issuance for Very Long Domain Names」。

Additionally, the CN is limited to at most 64 characters, while SANs can be significantly longer. This means that the CN is not only redundant, but actively restrictive: a certificate which has a Common Name cannot contain only very long domain names, because none of them would fit in the CN. For these reasons, the BRs state that for Domain Validated certificates, the Common Name field is "not recommended".

所以看起來是各家系統還沒有跟著改 (因為 Let's Encrypt 先前需要 CN 有值),但如果是自己申請的應該是可以自己避開了 (生 csr 的時候就改用 SAN)?

讓系統 (root) 的 Vim 可以用 securemodelines

自己帳號下 Vim (甚至是 Neovim) 要裝什麼都很簡單,但動到系統的時候基本上儘量維持原狀,除非是利遠大於弊的項目。

這次遇到的問題是用 sudo vimnginx 設定檔時無法判斷出正確的 filetype=nginx,這點通常可以在檔案開頭放個 # vim: typefile=nginx 解決,這個功能叫做 modelines

但這也代表在開任意檔案的時候很危險,因為他可以任意設定 Vim 的變數,所以就有了 securemodelines 這個套件,只允許某些參數被 override。(不過後來好像名稱變成有 dash 的 secure-modelines)

所以問題就變成要怎麼讓 root 吃這個 plugin... 我研究一輪後決定這樣搞:

先在 Ubuntu 上安裝 vim-scripts,這個套件裡面就有 secure-modelines,從 dpkg -L vim-scripts 裡面可以看到:

/usr/share/doc/vim-scripts/html/secure-modelines.html
/usr/share/vim-scripts/secure-modelines
/usr/share/vim-scripts/secure-modelines/plugin
/usr/share/vim-scripts/secure-modelines/plugin/securemodelines.vim
/usr/share/nvim/site/pack/dist-bundle/opt/secure-modelines
/usr/share/vim/vimfiles/pack/dist-bundle/opt/secure-modelines

接著就是到 /etc/vim/vimrc.local 裡面放設定,因為這個檔案會被 /etc/vim/vimrc 自動呼叫:

set runtimepath+=/usr/share/vim/vimfiles/pack/dist-bundle/opt/secure-modelines
packadd! secure-modelines

這樣避免了裝 package manager...

API 不該自動 HTTP 轉到 HTTPS

在「API Shouldn't Redirect HTTP to HTTPS (jviide.iki.fi)」這邊看到的,原始文章在「Your API Shouldn't Redirect HTTP to HTTPS」這邊。

仔細想一下沒錯,API 應該要一開始就被正確設定,所以要 fail fast。

另外在 id=40505525 這邊還提到了透過 HTTP 的 token 會自動被 revoke 掉,這個作法也很漂亮:

The Stack Exchange API used to revoke API keys sent over HTTP (and return an error message), which is my favorite way to handle this.

另外一個想法是直接不聽 port 80,不過這點在 Endpoint 的 IP 不是自己專用的情況下不一定能做到 (像是大多數的 CDN 環境)。

的確有戳中我手上預先準備好的 nginx config,來想看看怎麼改會比較好... 也許改成整個傳回 403,只開 /.well-known/acme-challenge/ACME (Let's Encrypt) 的 HTTP-01 認證可以過。

Internet Archive 被 DDoS 攻擊

在「The Internet Archive is under a DDoS attack (archive.org)」這邊看到 Internet ArchiveDDoS 貓,原始連結在 https://mastodon.archive.org/@internetarchive/112513905401989149 這邊:

現在是有感覺到 loading 的速度不快 (不過以前就不快了),然後 traceroute 看起來有輕微的 packet loss...

記得 Internet Archive 的頻寬一直都是滿的 (翻到 2020 年時有提到的「Internet Archive 的頻寬...」),對於以灌流量的 DDoS 攻擊是沒什麼抵抗力的。

以他們家的情況來看,大概只能請上游幫忙擋?

Slack 要拿使用者資料訓練 AI

在「Slack AI Training with Customer Data (slack.com)」這邊看到的,原公告在「Privacy Principles: Search, Learning and Artificial Intelligence」這邊。

預設會被丟進去訓練,Opt-out 無法直接設定,需要透過 e-mail 寫信找 feedback@slack.com (yeah,dark pattern):

Contact us to opt out. If you want to exclude your Customer Data from Slack global models, you can opt out. To opt out, please have your Org or Workspace Owners or Primary Owner contact our Customer Experience team at feedback@slack.com with your Workspace/Org URL and the subject line “Slack Global model opt-out request.” We will process your request and respond once the opt out has been completed.

拿企業資料來搞事嗎... 這應該已經不只是 privacy 議題而是 security 層面了,PR 層面鐵定很難看,來看後面會不會轉彎?

Amazon S3 改變 403 的收費方式

這算是一連串的故事,首先是四月底的時候「How an empty S3 bucket can make your AWS bill explode」這篇,提到了他一個晚上收到了 US$1,300 的帳單,因為有人 (沒有權限的人) 對他的 S3 bucket 狂打了 100M requests (一億筆),雖然都是 403 的 access denied,但還是得付 request 與頻寬的費用。

對於想要搞的人來說,us-east-1 的 Amazon S3 費用是 $0.005/1K requests (PUT, COPY, POST, LIST requests),換算大一點的單位是 $5/1M requests,拿個 ab 之類的工具超級簡單就可以打出破千 reqs/sec,如果是 k6 之類的工具,其實一台電腦就蠻容易打爆?

作者聯絡 AWS 客服後,客服回答你需要付這筆費用 (「這不是 bug,是 feature」):

Yes, S3 charges for unauthorized requests (4xx) as well[1]. That’s expected behavior.

然後這件事情就在社群傳開了,傳到 Jeff Barr 後直接公開提到他認為客戶不應該付 unauthorized request 的 cost (應該是先跟內部其他高層討論過了),等於是宣佈了會改掉:

不過這件事情之前應該就有人提過了,結果 Colin Percival 直接戳,他在 2006 年 Amazon S3 剛出來的時候就提過了:

Anyway,兩個禮拜過去後,剛剛看到宣佈收費方式修改:「Amazon S3 will no longer charge for several HTTP error codes」。

針對從不屬於自己帳號所產生的 403 不收費 (包括 request 與頻寬費用):

With this change, bucket owners will never incur request or bandwidth charges for requests that return an HTTP 403 (Access Denied) error response if initiated from outside their individual AWS account or AWS Organization.

然後多了一頁「Billing for Amazon S3 error responses」專門說明這件事情,這邊列的比較完整,除了 403 以外也包含了其他的 HTTP response code 是不收費的:

The current page shows a full list of HTTP 3XX and 4XX status codes that won't be billed.

補了一個 18 年的洞...

XZ 的後門事件,以及 OpenJS Foundations 也遇到類似的問題

XZ 的後門事件從暴發出來也已經一個多月了,大多數的證據也都分析的差不多了,是差不多可以回顧一下... 然後發現維基百科上面也已經有條目了:「XZ Utils backdoor」,中文版也有:「XZ实用程序后门」。

這次是 open source community 遇到社交工程 (social engineering) 的攻擊,攻擊者順利透過社交手法取得 maintainer & developer 的身份,接下來是慢慢埋 backdoor 的過程。

目前看起來後門是判斷特定的 SSH key 就放行,所以屬於 RCE 類的漏洞,CVSS 給了 10.0 的最高威脅分數。

另外隔壁棚 OpenJS Foundations 也遇到類似的問題:「Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects」,在「Failed Credible Takeover Attempt」這段有提到因為 OpenJS Foundations 是因為 security working group 擋下這次的 social engineering。

這是 xz 因為是 backdoor,所以在 performance profiling 時異常而被抓出來,如果是 exploitable 的話就難抓了... 這次的 social engineering 之後有看到一些不同的討論,有些是技術上把 security auditing 拆出來一起做,另外一種是要確保參與的 maintainer & developer 的真實身份。

已經可以看到影響了...

Route 53 Resolver DNS Firewall 的 chain 處理

在「Stop the CNAME chain struggle: Simplified management with Route 53 Resolver DNS Firewall」這邊看到的新功能。

說實話... 我早就忘記 Route 53 Resolver DNS Firewall 這個產品了,我查資料才發現我在 2021 年的時候寫過:「AWS 推出 Amazon Route 53 Resolver DNS Firewall」。

這個產品的用途是避免透過 DNS 將敏感資訊打出去,不過先前的產品的條件很死,遇到 CNAME 或是 DNAME 的情況,你必須事先把可能後續的 record 也放進白名單才行,所以如果遇到類似於 X (Twitter) 用的 pbs.twimg.com 的情況就很麻煩了:

;; ANSWER SECTION:
pbs.twimg.com.          300     IN      CNAME   cs196.wac.edgecastcdn.net.
cs196.wac.edgecastcdn.net. 3409 IN      CNAME   cs2-wac.apr-8315.edgecastdns.net.
cs2-wac.apr-8315.edgecastdns.net. 110 IN CNAME  cs2-wac-us.8315.ecdns.net.
cs2-wac-us.8315.ecdns.net. 110  IN      CNAME   cs45.wac.edgecastcdn.net.
cs45.wac.edgecastcdn.net. 725   IN      A       117.18.237.70

理想上是你放行 pbs.twimg.com 就好,但因為 CNAME 的關係,你可能會需要多放行 *.edgecastcdn.net 以及 *.ecdns.net

可是這是第三方的服務,你無法控制對方怎麼切換 (沒有 API contract 的概念),像是有時候他會跳到 Fastly

;; ANSWER SECTION:
pbs.twimg.com.          290     IN      CNAME   dualstack.twimg.twitter.map.fastly.net.
dualstack.twimg.twitter.map.fastly.net. 290 IN A 151.101.40.159

如果之後又跑出 Akamai 或是 CloudFront 的話就沒完沒了。

另外一種常見的情況是第三方的 API endpoint,對方有可能有多個不同的點做 DR 切換,有可能 CNAME 到 AWSELB 或是 GCPCloud Load balancing 上。

所以為了「保險」,這個方式通常都是開整個 CDN 的服務,但這麼一來攻擊者可以透過租用這些服務 (像是 *.cloudfront.net),搭配一些其他比較鬆的 rule 鑽出來。

這次的這個功能有點 stateful firewall 的概念,第一個啟動的 record 是被放行的,那 CNAME 或是 DNAME 延伸出來的 record 也跟著放行,這樣算是補強了這個問題...