GitHub 的 API Token 換格式

GitHub 前幾天宣佈更換 API token 的格式:「Authentication token format updates are generally available」,在今年三月初的時候有先公告要換:「Authentication token format updates」。

另外昨天也解釋了換成這樣的優點:「Behind GitHub’s new authentication token formats」。

首先是 token 的字元集合變大了:

The character set changed from [a-f0-9] to [A-Za-z0-9_]

另外是增加了 prefix 直接指出是什麼種類的 token:

The format now includes a prefix for each token type:

  • ghp_ for Personal Access Tokens
  • gho_ for OAuth Access tokens
  • ghu_ for GitHub App user-to-server tokens
  • ghs_ for GitHub App server-to-server tokens
  • ghr_ for GitHub App refresh tokens

另外官方目前先不會改變 token 長度 (透過字元變多增加 entropy),但未來有打算要增加:

The length of our tokens is remaining the same for now. However, GitHub tokens will likely increase in length in future updates, so integrators should plan to support tokens up to 255 characters after June 1, 2021.

看起來當初當作 hex string 而轉成 binary 會有問題,不過就算這樣做應該也是轉的回來的。

回到好處的部份,這個作法跟 SlackStripe 類似,讓開發者或是管理者更容易辨識 token 的類型:

As we see across the industry from companies like Slack and Stripe, token prefixes are a clear way to make tokens identifiable. We are including specific 3 letter prefixes to represent each token, starting with a company signifier, gh, and the first letter of the token type.

另外這也讓 secret scanning 的準確度更高,本來是 40 bytes 的 hex string,有機會撞到程式碼內的 SHA-1 string:

Many of our old authentication token formats are hex-encoded 40 character strings that are indistinguishable from other encoded data like SHA hashes. These have several limitations, such as inefficient or even inaccurate detection of compromised tokens for our secret scanning feature.

另外官方也建議現有的 token 換成新的格式,這樣如果真的發生洩漏,可以透過 secret scanning 偵測並通知:

We strongly encourage you to reset any personal access tokens and OAuth tokens you have. These improvements help secret scanning detection and will help you mitigate any risk to compromised tokens.

AWS 推出 Amazon Route 53 Resolver DNS Firewall

長久以來的洞總算有比較好的方法補上了,AWS 推出了 Amazon Route 53 Resolver DNS Firewall:「Introducing Amazon Route 53 Resolver DNS Firewall」。

Route 53 Resolver 是 AWS 官方提供的 DNS Resolver,沒有特殊的設定的話通常會在 x.x.x.2 (/24 或是更大的網段),先前一直沒有辦法解決 data leak 的問題,也就是透過 DNS 把敏感資料從 private network 裡丟出去。

以前的作法是透過 security group 擋掉對 Route 53 Resolver 的流量 (或是透過 VPC 的 Firewall 擋),然後自己架設兩台 DNS resolver 過濾,現在 Route 53 Resolver 支援 DNS Firewall,提供 allowlist 與 blocklist 這兩個功能使用,總算是把這件事情解的比較乾淨了:

Route 53 Resolver DNS Firewall lets you create “blocklists” for domains you don’t want your VPC resources to communicate with via DNS. You can also take a stricter, “walled-garden” approach by creating “allowlists” that permit outbound DNS queries only to domains you specify. You can also create alerts for when outbound DNS queries match certain firewall rules, allowing you to test your rules before deploying for production traffic.

另外這次的 DNS Firwall 提供了兩組由 AWS 維護的清單讓人使用,包括了 malware 與 botnet:

Route 53 Resolver DNS Firewall offers two managed domain lists—malware domains and botnet command and control domains—enabling you to get started quickly with managed protections against common threats.

這樣省事多了...

Facebook 5.33 億筆個資外洩,以及 Mark Zuckerberg 的電話...

這兩天應該已經有很多其他媒體報導了 Facebook 5.33 億筆資料外洩的事情:「533 million Facebook users' phone numbers and personal data have been leaked online」。

據稱是用 2019 年的洞撈出來的,不過這份資料看起來也不是完整資料,舉個例子來說,台灣只有 73 萬筆左右,而且也少了很多地區,像是泰國就不在列表內...

另外一個比較特別的是,Mark Zuckerberg 的電話也在這次外洩資料裡面:「Mark Zuckerberg's phone number appeared among the leaked data of Facebook users, according to a researcher」,應該會換號碼了。

這包資料看起來會這陣子會很熱門...

利用 Cloudflare Workers 繞過 Cloudflare 自家的阻擋機制

Hacker News 首頁上看到「How to bypass Cloudflare bot protection (jychp.medium.com)」這則,裡面的文章是「How to bypass CloudFlare bot protection ?」這篇,利用 Cloudflare Workers 繞過 Cloudflare 自家的 CAPTCHA 機制。

這個漏洞有先被送給 Cloudflare,但被認為不是問題,所以作者就決定公開:

Several months ago I submitted what appeared to be a security flaw to CloudFalre’s bugbounty program. According to them, this is not a problem, it’s up to you to make up your own mind.

技術上就是透過 Cloudflare Workers 當作 proxy server,只是看起來 Cloudflare 對自家 IP 有特別處理,在設定妥當後,用 Cloudflare Workers 的 IP address 去連 Cloudflare 的站台,幾乎不會觸發 Cloudflare 的阻擋機制。

不過 free tier 還是有限制,主要就是數量:

The first 100,000 requests each day are free and paid plans start at just $5/10 million requests, making Workers as much as ten-times less expensive than other serverless platforms.

作者也有提到這點:

So let’s enjoy the 100 000 request/day for your free Cloudflare account and go scrape the world !

但這是個有趣的方法,加上信用卡盜刷之類的方式,這整包看起來就很有威力...

Twitter 的 MFA 可以加入多支 YubiKey 了

我手上有好幾隻 YubiKey,目前幾個有在用的服務都有支援同時綁定多組 U2F/WebAuthn 的能力 (像是 FacebookGitHub)。

Twitter 一開始推出的時候也可以支援多組,但在去年 2020 年八月的時候發現這個功能被拔掉,只能放一把進去。

我自己開了一張 ticket 定時回頭看一下有沒有修正,剛剛定期回顧發現這個功能被加回來了,而且官方的文件上也加上去了:「How to use two-factor authentication」。

翻了一下 Internet Archive 上的資料,看起來是 3/113/16 中間更新文件的...

手上有多把 security key 的人也可以處理一下。

還原被碼掉的 PEM 資訊 (SSH RSA key)

在「Recovering a full PEM Private Key when half of it is redacted」這邊看到的,起因是 _SaxX_ 幫客戶做滲透測試時找到客戶公開在網路上的 SSH key,然後他就碼掉一部分貼出來:

原圖是這樣,接下來就開始被還原 XD

首先是 OCR 的過程,被稱為是整個還原過程最難的一部分 (哭爸啊):

Ironically, this was the hardest part of the challenge. It took the longest time of all the steps and was the easiest to make errors in.

接下來就是解讀 PEM 檔的格式,可以藉此得到裡面的參數。

然後是套公式,窮舉運算裡面的值,可以看到迴圈 kp 只算了 365537,就推算出可能的 p

e = 65537
q = 0xc28871e8714090e0a33327b88acc57eef2eb6033ac6bc44f31baeac33cbc026c3e8bbe9e0f77c8dbc0b4bfed0273f6621d24bc1effc0b6c06427b89758f6d433a02bf996d42e1e2750738ac3b85b4a187a3bcb4124d62296cb0eecaa5b70fb84a12254b0973797a1e53829ec59f22238eab77b211664fc2fa686893dda43756c895953e573fd52aa9bb41d22306135c81174a001b32f5407d4f72d80c5de2850541de5d55c19c1f817eea994dfa534b6d941ba204b306225a9e06ddb048f4e34507540fb3f03efeb30bdd076cfa22b135c9037c9e18fe4fa70cf61cea8c002e9c85e53c1eaac935042d00697270f05b8a7976846963c933dadd527227e6c45e1
dp = 0x878f7c1b9b19b1693c1371305f194cd08c770c8f5976b2d8e3cf769a1117080d6e90a10aef9da6eb5b34219b71f4c8e5cde3a9d36945ac507ee6dfe4c146e7458ef83fa065e3036e5fbf15597e97a7ba93a31124d97c177e68e38adc4c45858417abf8034745d6b3782a195e6dd3cf0be14f5d97247900e9aac3b2b5a89f33a3f8f71d27d670401ca185eb9c88644b7985e4d98a7da37bfffdb737e54b6e0de2004d0c8c425fb16380431d7de40540c02346c98991b748ebbc8aac73dd58de6f7ff00a302f4047020b6cd9098f6ba686994f5e043e7181edfc552e18bce42b3a42b63f7ccb7729b74e76a040055d397278cb939240f236d0a2a79757ba7a9f09

for kp in range(3, e):
    p_mul = dp * e - 1
    if p_mul % kp == 0:
        p = (p_mul // kp) + 1
        if isPrime(p):
            print(f"Possible p: {p}")

後面就是跑驗證確認,就被打出來了...

PHP 的 Git Server 被打穿,決定把整個 Git 系統搬到 GitHub 上

就如同標題說的:「Changes to Git commit workflow」,Hacker News 上的討論也可以看一下:「PHP's Git server compromised, moving to GitHub (php.net)」。

Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how exactly this happened, but everything points towards a compromise of the git.php.net server (rather than a compromise of an individual git account).

While investigation is still underway, we have decided that maintaining our
own git infrastructure is an unnecessary security risk, and that we will
discontinue the git.php.net server. Instead, the repositories on GitHub,
which were previously only mirrors, will become canonical. This means that
changes should be pushed directly to GitHub rather than to git.php.net.

不知道發生什麼事情,要等事後的報告出來...

FreeBSD & pfSense 上的 WireGuard 問題

FreeBSDpfSense 上的 WireGuard 實做問題前幾天被 Ars 的人整理出來:「Buffer overruns, license violations, and bad code: FreeBSD 13’s close call」,文章有點長度,但整個劇情有種在看八點檔的感覺... 在 Hacker News 上的「Buffer overruns, license violations, and bad code: FreeBSD 13’s close call (arstechnica.com)」與後續的「In-kernel WireGuard is on its way to FreeBSD and the pfSense router (arstechnica.com)」都值得翻翻。

目前 FreeBSD 與 pfSense 都已經把現有的 WireGuard 實做拿掉,主要原因是實做本身的品質很差 (以及安全性問題),而且沒有將 WireGuard 的功能實做完整。

文章裡面有提到兩個組織面上的問題 (還有攻擊個人的部份,這邊就不提了),第一個是 FreeBSD 的 review process,看起來比較像是系統面的問題,目前還是缺乏人力。

另外一個是 Netgate 本身 (pfSense 後面的公司),本來沒有太多背景知識,但這次事件發生後跑去翻了一下資料,發現原來之前就有一些「記錄」了,像是註冊競爭對手的產品 OPNsense 沒有註冊的網域 opnsense.com,然後導去 pfSense 家的事情,最後使得 Deciso (OPNsense 後面的公司) 到 WIPO 上搶回來:「WIPO Domain Name Decision: D2017-1828」。

可以花些時間來看看替代方案...

讓 Tor 的 .onion 支援 HTTPS

看到 Tor 官方的「Get a TLS certificate for your onion site」這篇,查了一下發現先前漏掉一些資訊...

首先是 2020 年二月的時候 CA/Browser Forum 就已經在投票是否有開放 v3 .onion 的憑證:「[Servercert-wg] Voting Begins: Ballot SC27v3: Version 3 Onion Certificates」,而結果也順利通過:「Ballot SC27v3: Version 3 Onion Certificates - CAB Forum」。

而一直到今年才有消息,希臘的 Harica CA 在月初時正式支援 v3 .onion:「Harica CA now supports issuance of DV .onion certificates」,不過拿 SSL Lab 的工具翻了一下,發現不是所有的平台都有認 Harica CA:「SSL Report: www.harica.gr (155.207.1.46)」,裡面可以看到 Java 的 trust store 裡面沒有 Harica CA:

實際測了一下流程,Harica CA 的網站會等到認證完後收費,看起來可以透過信用卡,但我就沒走下去了:

想要看看的人可以看 Kushal Das 的 kushaldas.inkushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion 就可以了。

另外查了一下 Certificate Transparency,可以看到我自己的 onion server 先被簽出來了:「5g4ukauwohjqjpydwqnkfkxxtcxkgtusr5twji53stfdzbz54xrmckid.onion」。

Let's Encrypt 出來後再說吧,目前看起來「Support for FQDNs under .onion」這邊沒有什麼進度...

Firefox 87 推出 SmartBlock 阻擋 3rd-party tracking

Firefox 87 推出了 SmartBlock,試著阻擋各種追蹤器:「Firefox 87 introduces SmartBlock for Private Browsing」,不過這不是一般的預設值,而是只有 Strict 模式與無痕模式會用到。

對於追蹤的問題,最早的作法是直接擋掉 3rd-party tracking javascript 的載入,但有很多網站會因為對應的變數沒有初始化而造成 javascript error。

這次的 SmartBlock 其實就是在各家阻擋套件實做很久的方式,插入一小段客製化的 javascript 讓網站裡的 javascript 可以呼叫,但實際上不會送任何資料出去,像是 uBlock Origin 的「unbreak.txt」。

不過 Firefox 重複搞這麼多東西,要不要考慮直接把 uBlock Origin 內建進來啊...