Home » Archive by category "Privacy" (Page 9)

新的 DNS Resolver:9.9.9.9

看到新的 DNS Resolver 服務,也拿到了還不錯的 IP address,9.9.9.9:「New “Quad9” DNS service blocks malicious domains for everyone」,服務網站是「Quad 9 | Internet Security and Privacy in a Few Easy Steps」,主打宣稱過濾已知的危險站台...

由政府單位、IBM 以及 Packet Clearing House 成立的:

The Global Cyber Alliance (GCA)—an organization founded by law enforcement and research organizations to help reduce cyber-crime—has partnered with IBM and Packet Clearing House to launch a free public Domain Name Service system.

也就是說,後面三家都不是專門做網路服務的廠商... 於是就會發現連 Client Subnet in DNS Queries (RFC 7871) 都沒提供,於是查出來的地區都不對,這對使用 DNS resolver 位置分配 CDN 節點的服務很傷啊... (或是其他類似服務)

這是 GooglePublic DNS (8.8.8.8) 查出來的:

;; ANSWER SECTION:
i.kfs.io.               576     IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 21599 IN CNAME TW.kwc.kkcube.com.
TW.kwc.kkcube.com.      188     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 299 IN     A       104.16.244.238
i.kfs.io.cdn.cloudflare.net. 299 IN     A       104.16.245.238

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Nov 18 05:30:23 CST 2017
;; MSG SIZE  rcvd: 181

這是 Quad9 (9.9.9.9) 查出來的:

;; ANSWER SECTION:
i.kfs.io.               1800    IN      CNAME   kwc.kkcube.com.country.mp.kkcube.com.
kwc.kkcube.com.country.mp.kkcube.com. 42702 IN CNAME US.kwc.kkcube.com.
US.kwc.kkcube.com.      300     IN      CNAME   i.kfs.io.cdn.cloudflare.net.
i.kfs.io.cdn.cloudflare.net. 300 IN     A       104.16.245.238
i.kfs.io.cdn.cloudflare.net. 300 IN     A       104.16.244.238

;; Query time: 294 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Nov 18 05:30:27 CST 2017
;; MSG SIZE  rcvd: 181

再來一點是,在科技領域相信政府單位通常都是一件錯誤的事情,我 pass... XD

各家 Session Replay 服務對個資的處理

Session Replay 指的是重播將使用者的行為錄下來重播,市面上有很多這樣的服務,像是 User Replay 或是 SessionCam

這篇文章就是在討論這些服務在處理個資時的方式,像是信用卡卡號的內容,或是密碼的內容,這些不應該被記錄下來的資料是怎麼被處理的:「No boundaries: Exfiltration of personal data by session-replay scripts」,主要的重點在這張圖:

後面有提到目前防禦的情況,看起來目前用 adblock 類的軟體可以擋掉一些服務,但不是全部的都在列表裡。而 DNT 則是裝飾品沒人鳥過:

Two commonly used ad-blocking lists EasyList and EasyPrivacy do not block FullStory, Smartlook, or UserReplay scripts. EasyPrivacy has filter rules that block Yandex, Hotjar, ClickTale and SessionCam.

At least one of the five companies we studied (UserReplay) allows publishers to disable data collection from users who have Do Not Track (DNT) set in their browsers. We scanned the configuration settings of the Alexa top 1 million publishers using UserReplay on their homepages, and found that none of them chose to honor the DNT signal.

Improving user experience is a critical task for publishers. However it shouldn’t come at the expense of user privacy.

掃網域下主機名稱的方式...

原文是講滲透測試的前置作業,需要將某個特定 domain 下的主機名稱掃出來:「A penetration tester’s guide to sub-domain enumeration」。

最直接的還是 DNS zone transfer (AXFR),如果管理者沒設好 DNS server 的話,這會是最快的方式。當沒有這個方法時就要用各種其他方式來掃了。

看了一下有幾種方式:

應該有人可以提到所有的東西再寫成程式 XD

microG 的進展...

留在 tab 上的東西,忘記在哪看到的... microG 發佈了新的專案:「LineageOS for microG」。

microG 是 AndroidGoogle 服務 API 的重新實作 (所以 open source),不像 Open GApps 還是屬於 proprietary software。

這次的事情是 microG 的人 fork 了 LineageOS 專案,因為 LineageOS 專案拒絕 microG 的 signature spoofing patch:

Why do we need a custom build of LineageOS to have microG? Can't I install microG on the official LineageOS?

MicroG requires a patch called "signature spoofing", which allows the microG's apps to spoof themselves as Google Apps. LineageOS' developers refused (multiple times) to include the patch, forcing us to fork their project.

另外也提到了他們覺得拒絕的原因很鳥:

Wait, on their FAQ page I see that they don't want to include the patch for security reasons. Is this ROM unsafe?

No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services.
The signature spoofing could be an unsafe feature only if the user blindly gives any permission to any app, as this permission can't be obtained automatically by the apps.

Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users.

於是就 fork 了新的專案... 就觀察看看吧。

IEEE P1735 漏洞,又是 Padding Oracle Attack...

在「IEEE P1735 Encryption Is Broken—Flaws Allow Intellectual Property Theft」這邊看到 US-CERT 發表的「IEEE P1735 implementations may have weak cryptographic protections」,裡面提到的主要漏洞:

The methods are flawed and, in the most egregious cases, enable attack vectors that allow recovery of the entire underlying plaintext IP.

主要應該是第一包:

CVE-2017-13091: improperly specified padding in CBC mode allows use of an EDA tool as a decryption oracle.

又是 CBCpadding oracle attack 啊... 看起來是標準沒有強制定義好造成的?

The main vulnerability (CVE-2017-13091) resides in the IEEE P1735 standard's use of AES-CBC mode.

Since the standard makes no recommendation for any specific padding scheme, the developers often choose the wrong scheme, making it possible for attackers to use a well-known classic padding-oracle attack (POA) technique to decrypt the system-on-chip blueprints without knowledge of the key.

去年 Cloudflare 寫的「Padding oracles and the decline of CBC-mode cipher suites」這邊有提到 padding oracle attack 的方式,比較一般性的解法是避開要自己決定 Encrypt-then-MAC (IPsec;也是數學上證明安全性) 或 Encrypt-and-MAC (SSH) 或是 MAC-then-Encrypt (SSL),而是用 AEAD 類的加密元件直接躲開 padding oracle attack 的某些必要條件 (像是 AES-GCM 或是 ChaCha20-Poly1305)。

不過這也是這幾年大家才了解這樣做的重要性,當年在訂規格的時候都比較沒在在意這些...

下一代的 Tor Hidden Service

Tor 公佈了下一代的 Hidden Service (Onion Service):「Tor's Fall Harvest: the Next Generation of Onion Services」。

三年前 Facebook 自己暴力算出 facebookcorewwwi.onion 這個很特別的名字 (參考「Facebook 證明 Tor 的 Hidden Service 不安全」),這陣子連紐約時報也能暴力算出 nytimes3xbfgragh.onion 這個好名字 (參考「紐約時報網站上 Tor 的 Hidden Service (i.e. Tor Onion Service)」,這讓只有 16 chars 的 hostname 的 hashed-space 不夠大的問題愈來愈明顯 (只有 80 bits 的空間)。

如果你也想要找出一個有趣的 hostname 的話,可以用 lachesis/scallion 這樣的工具,這程式用 CPU 產生出 RSA key 後,再用 GPU 算 SHA-1

The inital RSA key generation is done the CPU. An ivybridge i7 can generate 51 keys per second using a single core. Each key can provide 1 gigahash worth of exponents to mine and a decent CPU can keep up with several GPUs as it is currently implemented.

也因為如此,Facebook 與紐約時報在上線時並不是直接在 Hidden Service 上裸奔,而是上了 HTTPS 作為 workaround,以避免資料外洩。

但這畢竟是 workaround,Tor 的人還是希望協定本身就可以提供一個夠安全的架構,而花了四年多發展出下一代的 Hidden Service,也就是這次提到的成果了。

最大的改變就是 hostname 變長很多了,從本來的 16 chars 變成 56 chars:

And finally from the casuals user's PoV, the only thing that changes is that new onions are bigger, tastier and they now look like this: 7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion.

hostname 變長主要是因為把整個 256 bits public key 放進去,可以從 spec 看到:

6. Encoding onion addresses [ONIONADDRESS]

   The onion address of a hidden service includes its identity public key, a
   version field and a basic checksum. All this information is then base32
   encoded as shown below:

     onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion"
     CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2]

     where:
       - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service.
       - VERSION is an one byte version field (default value '\x03')
       - ".onion checksum" is a constant string
       - CHECKSUM is truncated to two bytes before inserting it in onion_address

  Here are a few example addresses:

       pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion
       sp3k262uwy4r2k3ycr5awluarykdpag6a7y33jxop4cs2lu5uz5sseqd.onion
       xa4r2iadxm55fbnqgwwi5mymqdcofiu3w6rpbtqn7b2dyn7mgwj64jyd.onion

   For more information about this encoding, please see our discussion thread
   at [ONIONADDRESS-REFS].

這是因為在 ECC 的安全性被廣泛認可後,ECC 的優點就被拿出來用在這次設計上了:

  • 256 bits 的 ECC key 強度大約是 3072 bits RSA key (以現在最好的攻擊演算法來估算)。
  • 直接放 public key 不需要經過 hash function 計算,可以避免掉 hash function 被找到 collision 時的風險。

於是因為 hostname 放的下,就硬塞進去了 XDDD

不過如果要玩的人需要裝 alpha 版本,目前的 stable 版本還沒有這個功能:

Tor as of version 0.3.2.1-alpha supports the next-gen onion services protocol for clients and services! As part of this release, ​the core of proposal 224 has been implemented and is available for experimentation and testing by our users.

Savitech (盛微) 的 USB 音效驅動程式會安裝 Root CA (被發了 CVE-2017-9758)

Hacker News 上看到 CERT 的「Savitech USB audio drivers install a new root CA certificate」提到 Savitech USB audio driver 會安裝自己的 Root CA:

Savitech provides USB audio drivers for a number of specialized audio products. Some versions of the Savitech driver package silently install a root CA certificate into the Windows trusted root certificate store.

出自「Inaudible Subversion - Did your Hi-Fi just subvert your PC? (原網站已經無法訪問,參考備份連結 https://archive.is/K6REr)」,CVE 編號是 CVE-2017-9758,最初是由 n3kt0n 提出的:「某單位 drivers silently install certificate in trusted root certificate authorities store [CVE-2017-9758]」:

Mitre assigned this exposure the identifier CVE-2017-9758, but was initially tracked by HITCON ZeroDay project as ZD-2017-00386.

有兩把 CA public key 被塞進去。雖然目前還沒有徵兆 private key 有外洩,但還是建議儘快移除:

There is currently no evidence that the Savitech private key is compromised. However, users are encouraged to remove the certificate out of caution. The two known certificates are:

SaviAudio root certificate #1
‎Validity: Thursday, ‎May ‎31, ‎2012 - ‎Tuesday, ‎December ‎30, ‎2036
Serial number: 579885da6f791eb24de819bb2c0eeff0
Thumbprint: cb34ebad73791c1399cb62bda51c91072ac5b050

SaviAudio root certificate #2
Validity: ‎Thursday, ‎December ‎31, ‎2015 - ‎Tuesday, ‎December ‎30, ‎2036
Serial number: ‎972ed9bce72451bb4bd78bfc0d8b343c
Thumbprint: 23e50cd42214d6252d65052c2a1a591173daace5

另外 Savitech 也放出了新版的 driver,不包含 Root CA:

Savitech has released a new driver package to address the issue. Savitech drivers version 2.8.0.3 or later do not install the root CA certificate. Users still must remove any previously installed certificate manually.

看了一下說明,看起來是當時為了支援 Windows XP 而做的,但微軟已經不提供驅動程式的數位簽章了,所以就只好這樣搞...

CloudFlare 也要提供 Certificate Transparency 的 Log 伺服器了...

看到 CloudFlare 請求加入 Chromium (Google Chrome) 的伺服器列表:「Certificate Transparency - Cloudflare "nimbus2017" Log Server Inclusion Request」。

對照之前的「Chromium 內提案移除 HPKP (HTTP Public Key Pinning)」以及「Let's Encrypt 的 Embed SCT 支援」,這樣看起來是瀏覽器內會有一份白名單,只有在這白名單上的 Embed SCT 才會被信任...

但弄到這樣的話,log server 是不是也要有稽核機制?

好像哪邊搞錯了方向啊...

HAProxy 1.8 多了好多東西...

雖然大家都在用 nginx,但 HAProxy 還是在努力:「What’s New in HAProxy 1.8」。

這個版本多了好多東西...

  • 支援 HTTP/2。(終於...)
  • Multithreading 架構。(health check 總算是一隻了 XD 不會開八隻就打八次...)
  • DNS 的 Service Discovery。
  • TLS 1.3 0-RTT。(居然支援了...)

有種突然醒過來的感覺...

The DUHK Attack:因為亂數產生器的問題而造成的安全漏洞

Bruce Schneier 那邊看到的:「Attack on Old ANSI Random Number Generator」,攻擊的網站在「The DUHK Attack」,論文在「Practical state recovery attacks against legacy RNG implementations (PDF)」。

攻擊的對象是 ANSI X9.31 Random Number Generator:

DUHK (Don't Use Hard-coded Keys) is a vulnerability that affects devices using the ANSI X9.31 Random Number Generator (RNG) in conjunction with a hard-coded seed key.

然後攻擊的對象是 FortinetFortiOS

Traffic from any VPN using FortiOS 4.3.0 to FortiOS 4.3.18 can be decrypted by a passive network adversary who can observe the encrypted handshake traffic.

如果照說明的只到 4.3.18,那麼去年 11 月更新的 4.3.19 (參考「FortiOS 4.3.19 Release Notes」) 應該是修正了?不過裡面沒翻到類似的資料,是剛好把 RNG 換掉了嗎?

Archives