Category: Security

Cloudflare 弄了 time.cloudflare.com，不過 latency 沒有很好...

Cloudflare 提供的 NTP service，使用 time.cloudflare.com：「Introducing time.cloudflare.com」。

官方是號稱所有的機房 (應該就包括台北的點)：

Now, anyone can get time securely from all our datacenters in 180 cities around the world.

但在 HiNet 下測試可以看到是從東京的點服務：

  2.|-- snuh-3302.hinet.net        0.0%    10    9.5  10.5   9.5  12.7   0.8
  3.|-- tpdt-3022.hinet.net        0.0%    10   11.1  10.8  10.1  11.8   0.3
  4.|-- r4103-s2.tp.hinet.net      0.0%    10   27.2  11.9   9.3  27.2   5.4
  5.|-- r4003-s2.tp.hinet.net      0.0%    10   11.3  10.7   9.5  11.6   0.3
  6.|-- xe-0-0-0-3-6.r02.osakjp02  0.0%    10   47.9  48.7  47.6  49.9   0.6
  7.|-- ae-2.a00.osakjp02.jp.bb.g  0.0%    10   44.9  47.3  42.8  66.4   6.9
  8.|-- ae-20.r03.osakjp02.jp.bb.  0.0%    10   43.7  43.2  42.5  44.7   0.3
  9.|-- 61.120.144.46              0.0%    10   69.6  52.4  48.0  69.6   6.8
 10.|-- 162.159.200.123            0.0%    10   48.3  48.8  47.9  49.3   0.0

如果從 APOL (有線電視) 的點則是透過台灣的機房連線：

  3.|-- 10.251.11.6                0.0%    10   19.8  29.6  11.1  80.2  21.7
  4.|-- 10.251.231.5               0.0%    10   25.3  24.9  16.4  43.6   8.0
  5.|-- 10.251.231.1               0.0%    10    8.7   6.3   3.4   9.1   1.9
  6.|-- 10.251.230.34              0.0%    10    4.6   7.4   2.6  14.5   3.2
  7.|-- 10.251.230.29              0.0%    10    3.0   6.6   3.0  11.9   2.8
  8.|-- 202-178-245-162.cm.static  0.0%    10    4.8   7.3   4.8   9.9   1.4
  9.|-- 192.168.100.14             0.0%    10    7.3   8.0   5.4  11.1   2.0
 10.|-- 192.168.100.9              0.0%    10    8.2   8.0   4.9  11.1   1.7
 11.|-- 203-79-250-65.static.apol  0.0%    10    9.1   9.0   6.4  11.3   1.5
 12.|-- 211.76.96.92               0.0%    10    7.8   8.1   4.3  15.8   3.3
 13.|-- 39-222-163-203-static.tpi  0.0%    10    9.9   9.1   6.7  12.4   1.8
 14.|-- 162.159.200.1              0.0%    10    5.0   7.2   5.0   9.7   1.4

看起來又是有東西沒搞定了...

AWS ACM 支援 Private CA

AWS ACM 推出了 Private CA 服務：「How to host and manage an entire private certificate infrastructure in AWS」。

以前需要 Private CA 的話，會找個地方丟 Root CA 的 key，然後有權限的人可以連到那台機器上跑 OpenSSL 指令生出對應的 SSL certificate，現在 AWS 則是利用 HSM 架構提供服務：

主要是因為 HSM 的關係，安全性會比較好... 另外也因為是 AWS 服務的關係，上面可以看到相關的記錄，相較於以前的作法安全不少。

利用 Smart TV 監控的技術也成熟了...

透過 WikiLeaks 公開出來的文件得知 CIA 與 MI5 都已經有能力將後門埋入 Samsung 的 Smart TV 內：「The CIA Spied on People Through Their Smart TVs, Leaked Documents Reveal」。

Hackers at the Central Intelligence Agency, with the help of colleagues from the British spy agency MI5, developed malware to secretly spy on targets through their Samsung Smart TVs, according to new documents published by WikiLeaks.

這個後門在 Fake-Off 模式中仍然可以繼續運作：

The malware was designed to keep the smart TVs on even when they were turned off. This was dubbed "Fake-Off mode," according to the documents.

甚至可以控制 LED 燈，讓被監控人無法得知現在 Smart TV 其實還在運作中：

The CIA hackers even developed a way to "suppress" the TVs LED indicators to improve the "Fake-Off" mode.

突然想到該找時間複習 1984，裡面描述的概念現在在生活週邊愈來愈多了...

Netflix 找到的 TCP 實做安全性問題...

這幾天的 Linux 主機都有收到 kernel 的更新，起因於 Netflix 發現並與社群一起修正了一系列 Linux 與 FreeBSD 上 TCP 實做 MSS 與 SACK 的安全性問題：「https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md」。

其中最嚴重的應該是 CVE-2019-11477 這組，可以導致 Linux kernel panic，影響範圍從 2.6.29 開始的所有 kernel 版本。能夠升級的主機可以直接修正，無法升級的主機可以參考提出來的兩個 workaround：

Workaround #1: Block connections with a low MSS using one of the supplied filters. (The values in the filters are examples. You can apply a higher or lower limit, as appropriate for your environment.) Note that these filters may break legitimate connections which rely on a low MSS. Also, note that this mitigation is only effective if TCP probing is disabled (that is, the net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the default value for that sysctl).

Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to 0).

第一個 workaround 是擋掉 MSS 過小的封包，但不保證就不會 kernel panic (文章裡面用語是 mitigation)。

第二個 workaround 是直接關掉 SACK，這組 workaround 在有 packet loss 的情況下效能會掉的比較明顯，但看起來可以避免直接 kernel panic...

iOS 13 與 macOS 10.15 對憑證的限制

在 Slack 上看到同事丟出來的，關於之後要推出的 iOS 13 與 macOS 10.15 會對憑證限制的項目：「Requirements for trusted certificates in iOS 13 and macOS 10.15」。

主要是把不安全的演算法淘汰掉 (RSA 小於 2048 bits，以及 SHA-1 類的 hash algorithm)，這兩個部份相關的新聞應該不少，沒有什麼太大問題：

TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.

TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.

然後是要求憑證使用 SAN (Subject Alternative Name)，舊的標準 CN (CommonName) 將不會再被信任。

如果是公開簽發的憑證應該都沒問題 (像是 Let's Encrypt，或是花錢買的那些)，主要的問題應該會出現在自己建立的憑證，網路上蠻多舊資料還是產生 CN...

TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

另外是 2019/7/1 之後發出的憑證，有額外兩個規範要注意，第一個是強制要透過 EKU 指定 id-kp-serverAuth，這是出自 RFC 5280：

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.

再來是時間的限制，接下來的憑證最長只認得 825 天 (大約 27 個月多一些)，以前都惡搞 -days 3650，現在得兩年簽一次了：

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

整體看起來主要是影響自己簽的部份...

Let's Encrypt 的 ACMEv1 將在今年十一月進入日落階段

Let's Encrypt 推出 ACMEv2 後要終止 ACMEv1 的計畫，是今年三月發的消息，但一直沒注意到，剛剛翻到「acme-client(1) moves to Let's Encrypt v02 API」時才看到的：「End of Life Plan for ACMEv1」。

日落分成幾個階段，第一個階段是今年十一月終止透過 ACMEv1 註冊新帳號：

In November of 2019 we will stop allowing new account registrations through our ACMEv1 API endpoint. Existing accounts will continue to function normally.

第二個階段是明年六月終止透過 ACMEv1 申請新的 certificate：

In June of 2020 we will stop allowing new domains to validate via ACMEv1.

第三個階段是 2021 年會開始測試關閉 ACMEv1 的 renew 功能，一個月不會超過一次，每次大約 24 小時，這是讓 client 有機會丟出錯誤訊息：

Starting at the beginning of 2021 we will occasionally disable ACMEv1 issuance and renewal for periods of 24 hours, no more than once per month (OCSP service will not be affected).

最後的階段是 2021 年的六月，會完全關閉 ACMEv1 所有的服務：

In June of 2021 we will entirely disable ACMEv1 as a viable way to get a Let’s Encrypt certificate.

目前在用的都支援 ACMEv2 了，應該是 ok...

Apple 新的「Find My」帶來的隱私問題

這次 WWDC 推出的新功能，已經有人在討論機制與隱私問題了：「How does Apple (privately) find your offline devices?」。

前一代的「Find my iPhone」需要透過網路與 GPS 資料才能在系統上看到，這一代則是加上 BLE beacon，然後任何一台 iOS device 收到後就回傳回給蘋果：

Every active iPhone will continuously monitor for BLE beacon messages that might be coming from a lost device. When it picks up one of these signals, the participating phone tags the data with its own current GPS location; then it sends the whole package up to Apple’s servers.

幾個隱私問題在於，代傳的 iOS device 也會暴露位置資訊給蘋果，另外收到 BLE beacon 的 iOS device 本身是否可以解讀遺失機器的資訊？而商家看起來也可以利用這個方式主動發送攻擊而得知不少資料 (像是文章裡提到先前蘋果透過 randomize mac address 加強隱私的問題，這邊又多開了一個洞)，現在蘋果給的資訊還不夠清楚，需要真的逆向工程確認才知道...

在 AWS 強制使用 MFA 的情況下，透過 CLI 操作

AWS 可以設定 IAM 使用者強制使用 MFA (包括 API 的操作)，在這種情況下如果要使用 AWS Command Line Interface 就得透過 AWS STS (AWS Security Token Service) 產生另外一組 key + secret + session key，然後這組通行時間預設是 12 小時。

相關的文章可以參考「How do I use an MFA token to authenticate access to my AWS resources through the AWS CLI?」這篇，然後我就寫了一段 shell script 來做這件事情。

首先是在 ~/.aws/config 內放入 MFA 的 ARN，像是這樣：

[profile mycompany]
mfa = arn:aws:iam::012345678901:mfa/gslin
region = us-east-1

然後就可以用 aws.mfa mycompany 指令產生出一個會把 key + secret + session key 包進去的 shell：

function aws.mfa() {
    local MFA_ARN
    local MFA_TOKEN
    local PROFILE="$1"
    local STSDATA

    MFA_ARN="$(python3 -c "import configparser; import os; c=configparser.ConfigParser(); c.read('{}/.aws/config'.format(os.environ['HOME'])); print(c['profile ${PROFILE}']['mfa'])")
"
    echo "Reading ${PROFILE} and going for token ${MFA_ARN} ..."

    echo -n 'MFA Password: '
    read -r MFA_TOKEN

    STSDATA="$(aws --profile "${PROFILE}" sts get-session-token --serial-number "${MFA_ARN}" --token-code "${MFA_TOKEN}")"
    export AWS_ACCESS_KEY_ID="$(echo "${STSDATA}" | jq -r .Credentials.AccessKeyId)"
    export AWS_SECRET_ACCESS_KEY="$(echo "${STSDATA}" | jq -r .Credentials.SecretAccessKey)"
    export AWS_SESSION_TOKEN="$(echo "${STSDATA}" | jq -r .Credentials.SessionToken)"

    echo 'Running an independant shell...'
    ${SHELL}
}

很明顯的裡面用到了 Python 3 與 jq，這兩個應該都可以直接裝系統的版本就可以了。

後續的操作就跟原來的用法都一樣，像是 aws --region=us-east-1 s3 ls 這樣的指令。

Salesforce 弄了一個新的玩意出來...

然後在 Hacker News 上被酸爆了：「Open-sourcing the Lightning Web Components framework (salesforce.com)」。引用的原文在「Introducing Lightning Web Components Open Source」這邊。

主要還是大家已經厭倦前端一直丟東西出來，但是速度一直都沒什麼改善... 用傳統的 server rendering 反而省了不少 client 端的 CPU resource。

話說回來，前幾天的伺服器爆炸好像沒看到什麼後續新聞... (參考「Salesforce enables modify all in all user profiles」、「Salesforce系統更新意外造成權限擴張，用戶服務被迫中斷」)。

Amazon EBS 的預設加密機制

EBS 有選項可以預設開加密了：「New – Opt-in to Default Encryption for New EBS Volumes」。

不算太意外的，這個選項要一區一區開：

Per-Region – As noted above, you can opt-in to default encryption on a region-by-region basis.

也不太意外的，無法完全公開共用：

AMI Sharing – As I noted above, we recently gave you the ability to share encrypted AMIs with other AWS accounts. However, you cannot share them publicly, and you should use a separate account to create community AMIs, Marketplace AMIs, and public snapshots. To learn more, read How to Share Encrypted AMIs Across Accounts to Launch Encrypted EC2 Instances.

然後有些服務有自己的 EBS 設定，這次不受影響。而有些底層其實是用 EC2 的服務 (然後開 EBS) 就會直接套用了：

Other AWS Services – AWS services such as Amazon Relational Database Service (RDS) and Amazon WorkSpaces that use EBS for storage perform their own encryption and key management and are not affected by this launch. Services such as Amazon EMR that create volumes within your account will automatically respect the encryption setting, and will use encrypted volumes if the always-encrypt feature is enabled.