Category: Security

Cloudflare 提供 Certificate Transparency 的通知服務

Cloudflare 推出了 Certificate Transparency 的通知服務，當有任何新的 SSL certificate 發出時就會通知：「Introducing Certificate Transparency Monitoring」。

基本上就是一組 crawler 去各家記錄挖資料回來：

Business 與 Enterprise 版本的可以設定要通知誰，Free 與 Pro 版本則是固定會通知網域的擁有人 (這邊指的是 Cloudflare 上的)：

If you’re on a Business or Enterprise plan, you can tell us who to notify. Instead of emailing the zone owner (which we do for Free and Pro customers), we accept up to 10 email addresses as alert recipients. We do this to avoid overwhelming large teams.

剛剛把掛在上面的 domain 都開起來了，這樣在 Let's Encrypt 自動 renew 的時候應該會收到通知...

另外一個同名的工具則是 2016 年底時 Facebook 推出的 (需要登入才能使用)，可以搜尋有哪些 domain：「Certificate Transparency Monitoring」。

JSON Canonicalization

這篇是講 JSON object 上的簽名，但實際上就是在討論 JSON Canonicalization 的前因後果：「How (not) to sign a JSON object」。

在處理 JSON 資料時，「判斷兩個 JSON object 是否相同」是一個不怎麼簡單的問題，其中一個想法是找一個機制可以把意義相同的 JSON object 都轉成相同的 (byte)string representative，這也就是 JSON Canonicalization。當你可以確保意義相同的 JSON Canonicalization 後，你就可以對 string 本身簽名。

這件事情其實在 XML 就有過同樣的歷史故事 (yeah，總是有人愛在某種資料格式上面疊上簽名)，也就是「XML Signature」這個方式。

在 XML 這邊不幸的是，還不少標準選用 XML Signature，像是當年為了實做 Google Apps (現在叫做 G Suite) 的 SSO，而需要接 SAML...

回到原來的 JSON Canonicalization，可以馬上想到的變化包括了空白與 object 裡 key 的順序，也就是這兩個：

{"a":1,"b":2}
{
  "b": 2,
  "a": 1
}

但不幸的是，還有 Unicode 來一起亂，也就是下面這個跟上面有相同的意思：

{
  "\u0062": 2,
  "\u0061": 1
}

另外還有其他的地雷是平常不會想到的，如果你因為複雜而決定用 library 來做，那也代表 library 必須面對這些複雜的情境，未必沒有 bug...

所以文章作者在最後面才會請大家不要再來亂了 XDDD

Maybe you don’t need request signing? A bearer token header is fine, or HMAC(k, timestamp) if you’re feeling fancy, or mTLS if you really care.

Canonicalization is fiendishly difficult.

Add a signature on the outside of the request body, make sure the request body is complete, and don’t worry about “signing what is said versus what is meant” – it’s OK to sign the exact byte sequence.

Amazon SES 過 HIPAA 了

因為 Amazon SES 算是很基本的服務，一直以為 AWS 早就把 Amazon SES 過 HIPAA 了，剛剛看到 AWS 的公告 Amazon SES 過了 HIPAA 才發現並不是這樣：「Amazon SES Achieves HIPAA Eligibility」。

Anyway，這次是所有區域的 SES 都過了：

Amazon SES is now a HIPAA Eligible Service. HIPAA eligibility applies to all AWS Regions where Amazon SES is available.

然後翻了一下市場的情況，看起來 SendGrid 與 MailChimp 也沒過，但 Mailgun 有過... 所以是本來就有方案可以用。

透過把 .git/safe/../../bin 加到 $PATH 執行程式

在「.git/safe」這邊看到的方式，想要方便執行 $GITROOT/bin 想法是：

  • 把 .git/safe/../../bin 放到 $PATH，如果可以順利解出來的話就是 repository 本身的 $GITROOT/bin。
  • 但一般是解不出來的 (因為 .git/ 裡面不會有 safe/ 這個目錄，所以預設是解不出東西的。而對於信任的 repository 則可以 mkdir .git/safe 讓 shell 可以搜尋到。

之所以可以這樣做的是因為：

  • .git 是保留字，從 command line 上你沒辦法塞 .git 目錄進到 repository 內，但不確定直接從 blob layer 塞會怎樣... (也就是得確認 checkout 時檢查的問題)

先寫起來看看好了，不過暫時應該也用不到...

摸進俄羅斯的外包廠商，意外發現的專案：降低 Tor 匿名性的工具

俄羅斯政府的外包廠商 SyTech 被摸進去後，被發現裡面有些「有趣」的軟體：「Hackers breach FSB contractor, expose Tor deanonymization project and more」。

這次被放在標題的軟體叫做 Nautilus-S，透過被加過料的 Tor server 與 ISP traffic 交叉分析，試著找出俄羅斯內的 Tor 使用者：

Nautilus-S - a project for deanonymizing Tor traffic with the help of rogue Tor servers.

這不是新東西，之前就有被提出來，但並沒有這次直接給整包軟體出來：

The first was Nautilus-S, the one for deanonymizing Tor traffic. BBC Russia pointed out that work on Nautilus-S started in 2012. Two years later, in 2014, academics from Karlstad University in Sweden, published a paper detailing the use of hostile Tor exit nodes that were attempting to decrypt Tor traffic.

而且看起來有不少節點正在運行：

Researchers identified 25 malicious servers, 18 of which were located in Russia, and running Tor version 0.2.2.37, the same one detailed in the leaked files.

不知道 Tor 會不會有行動...

AWS Client VPN 支援 Split-tunnel

VPN 的 Split-tunnel 指的是 partial routing，也就只針對部份 IP range 走進 VPN，其餘大多數的流量還是走原來的 Internet。

這個方式的安全性通常會比 full routing 低一些，因為這個方式會使得 internet 流量有機會穿進 VPN 內 (像是透過瀏覽器)，但因為這可以讓使用者避免越洋的 VPN 導致速度下降過多，算是 VPN 常用的功能。

這次 AWS Client VPN 實做了這個功能：「AWS Client VPN now adds support for Split-tunnel」。

不過 AWS Client VPN 相較於自己架設貴不少，目前知道的單位大多也都還是自己架...

Google 公告了 Chrome Extension 對於權限的新規範

是收到信件通知 (因為之前有開發一些 extension)，裡面提到的重點主要是出自「Developer Program Policies」裡的兩項。

第一項是要求權限最小化：

Request access to the narrowest permissions necessary to implement your Product’s features or services. If more than one permission could be used to implement a feature, you must request those with the least access to data or functionality.

第二個是你現在沒有實做的功能就不能要權限：

Don't attempt to "future proof" your Product by requesting a permission that might benefit services or features that have not yet been implemented.

這些新條文將會在 2019/10/15 生效：

Your extensions must be compliant with this policy by October 15th, 2019. You can learn more about these changes and how they may apply to you in our User Data FAQ.

在 Chrome 的 FileSystem API 的漏洞被補上後，偵測私密瀏覽模式的方式

Google Chrome 74 版修掉了一般模式與私密瀏覽模式下 FileSystem API 明顯的不同處後，自然就會有人研究其他的偵測方式：「Bypassing anti-incognito detection in Google Chrome」。

作者提出來的方式是透過 Quota Management API，一般模式與私密瀏覽模式下會得到不同的值，尤其是硬碟夠大的時候上限是不一樣的：

不過這個看起來應該比較好修？

Cloudflare 因為 Regular Expression 炸掉的問題

先前 Cloudflare 就有先說明七月二日的 outage 是因為 regular expression 造成的 (ReDoS)，不過昨天發的文章更完整了，導致爆炸的 regular expression 都給出來了：「Details of the Cloudflare outage on July 2, 2019」。

ReDoS 不算是新的問題，但卻是不太好避免的問題，因為需要有經驗的工程師 (中過獎的工程師) 才比較容易知道哪些 regular expression 是有問題的... 另外就是有花時間研究 regular expression 演算法的工程師也比較容易避開。

也因次，ReDoS 算是這十年來大家在還的債，各家 framework 都因為這個問題改寫了不少 regular expression。

這次的重點在這串式子導致了 ReDoS：

(?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|\`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

通常容易中獎的地方就是無限制字元與 * & + 連發的地方，後面這塊 )*.*(?:.*=.*))) 看起來就不太妙，果然在後面的分析也有提到：

The critical part is .*(?:.*=.*).

以前應該是在 Formal language 裡學到的，在課堂裡面其實會學到不少業界常用工具的基礎理論...

市場上有很多 VPN 都是由中國公司在後面營運

在「Hidden VPN owners unveiled: 97 VPN products run by just 23 companies」這篇分析了 VPN 產業裡面背後的公司。

其中有兩個比較重要的事情，第一個是很多公司 (或是集團) 都擁有多個 VPN 品牌 (甚至有到十個品牌的)，所以如果想要透過多家 VPN 分散風險時，在挑的時候要看一下：

另外一個是後面有多中國人或是中國公司在營運：

We discovered that a good amount of the free mobile-only VPNs are owned by Chinese companies, or companies run by Chinese nationals.

  • Innovative Connecting (10 VPN apps): Director Danian “Danny” Chen is a Chinese national (Chen’s LinkSure is the sole shareholder and shares the same address as Innovative Connecting)
  • Hotspot VPN (5 VPN apps): Director Zhu Jianpeng has a residential address in Heibei Province in China
  • Hi Security (3 apps): the VPN apps are part of Shenzhen HAWK Internet, a subsidiary of the Chinese major company TCL Corporation
  • SuperSoftTech (2 apps): while officially owned by Singapore-based SuperSoftTech, it actually belongs to independent app publisher Jinrong Zheng, a Chinese national based in Beijing.
  • LEILEI (2 apps): by the titles of the VPNs (all written in Chinese characters), it’s likely that this developer is Chinese or based in China
  • Newbreed Network Pte.Ltd (6 apps): again, while it has a Singapore address, the websites for its VPN apps SGreen VPN and NodeVPN are completely in Chinese, while NodeVPN’s site lists the People’s Republic of China as its location.

這些公司與產品都應該要直接避開... 在有能力的情況下，在 public cloud 上自己架設還是會比較保險。