透過無線 WiFi 的監視器的問題

在「Wi-Fi jamming to knock out cameras suspected in nine Minnesota burglaries (tomshardware.com)」這邊看到的,原報導在「Wi-Fi jamming to knock out cameras suspected in nine Minnesota burglaries -- smart security systems vulnerable as tech becomes cheaper and easier to acquire」。

這個手法是把無線網路的頻寬塞爆 (或是放出干擾),這樣 security camera 就算拍到東西也不會有記錄:

這個應該是已知的問題?從以前 security camera 都是建議走有線 (以及 isolated VLAN),無線的主要還是娛樂用途,而不是 security camera...

以前還有印象有看過防 EMP 的型號,不過那個是軍用...

2014/2015 年的 Smart Home & IoT 裝置?

昨天的「What's that touchscreen in my room? (laplab.me)」這篇頗有趣的,原文「What's that touchscreen in my room?」是在租屋處看到牆上有一片平板,研究這到底是什麼的文章:

作者在一包文件裡找到手冊以後 (應該是屋主當初直接拿給他的一包文件?),知道這是 NetThings 的設備 (看起來已經是歷史了,這邊留個 LinkedIn 上的連結...):

然後連了半天發現連不上,到公共區域發現他還有一台主機要打開,但因為沒有保險絲,所以沒通電:

在裝了保險絲開機之後就是黑這台機器的過程...?

在各種嘗試中得知,port scan 過程發現有 tcf-agent 可以直接對檔案系統操作,首先是試著撈出 root 加密過的密碼來 john 但不順利,後來是發現可以修改 /etc/shadowroot 密碼清空,並且修改 /etc/ssh/sshd_config,就順利連上了這台機器...

這是一台 ARM9 的機器,有大約 118MB 的記憶體,而且 CPU 可以直接跑 Java bytecode (Jazelle)。

另外這台平板是 Android 5 的系統,透過 webview 從主機上拉狀態出來。

然後裡面有不少 (以現在來看) 古董:

Along with the Pulse app, there is the second part of the application. A Node.js app reads CSV files populated with energy usage data and displays them to the user in the web UI. It uses Node.js 0.10.26, Express.js 4.13.3 and Socket.io 1.3.6.

是個 2014/2015 年左右的產品...

Amazon Echo 會「聽」並且將資料送到第三方廣告平台

前陣子看到的研究報告,證實 Amazon Echo 會聽取資訊並且將這些資料送到第三方的廣告平台上 (會送到 Amazon 自家應該不算新聞):「Your Echos are Heard: Tracking, Profiling, and Ad Targeting in the Amazon Smart Speaker Ecosystem」。

先從 abstract 開始看,主要是目前這些 smart speaker 基本上沒有透明度,所以十位作者群們建立了一套評估用的 framework 用來測試各家 smart speaker 資訊蒐集已經影響的情況:

Smart speakers collect voice input that can be used to infer sensitive information about users. Given a number of egregious privacy breaches, there is a clear unmet need for greater transparency and control over data collection, sharing, and use by smart speaker platforms as well as third party skills supported on them. To bridge the gap, we build an auditing framework that leverages online advertising to measure data collection, its usage, and its sharing by the smart speaker platforms.

這次論文裡面提到的目標就是 Amazon Echo 會將聽到的東西分享給第三方的廣告平台,並且讓廣告平台可以調整競價 (賺更多的錢),而且這些資訊並沒有被揭露在 privacy policy 裡面:

We evaluate our framework on the Amazon smart speaker ecosystem. Our results show that Amazon and third parties (including advertising and tracking services) collect smart speaker interaction data. We find that Amazon processes voice data to infer user interests and uses it to serve targeted ads on-platform (Echo devices) as well as off-platform (web). Smart speaker interaction leads to as much as 30X higher ad bids from advertisers. Finally, we find that Amazon's and skills' operational practices are often not clearly disclosed in their privacy policies.

幾個比較重要的資訊,其中一個是「Network traffic distribution by persona, domain name, purpose, and organization」:

另外一個重點是哪些 3rd-party:

就心裡有個底,然後隔壁棚也有類似產品 (主業是做廣告的那家),大概要跑不掉...

透過 DNS 擋 Smart TV 的廣告

Hacker News Daily 上看到「Smart-TV Blocklist for Pi-hole」這個,給 Pi-hole 吃的 blocklist,可以拿來擋 Smart TV 抓一堆廣告亂搞,另外很多自己刷的 WRT 也都支援這個格式,不一定要自己弄 Pi-hole,像是我家裡的 AdvancedTomato 也有支援:

本來馬上想到的是 AdGuard 提供的 DNS 94.140.14.14,結果掃了一下發現都沒有擋掉,難怪會需要另外自己搞...

另外一個想到的搞法是 NextDNS,但 IPv4 的部份要固定 IP 才有辦法 (像是 HiNet 提供的 PPPoE 固一),免費版的 quota 拿來掛 Smart TV 應該夠用...

Hacker News 上的討論在「Smart-TV blocklist for Pi-Hole (perflyst.github.io)」這邊,這年頭要弄台不連網的電視機愈來愈難了...

不使用 Google 服務的 Android 手機

一樣是在 Lobsters Daily 上翻到的,去 Google 服務的 Android 系統搞法:「Lineage with microG on a Sony XA2」。

主要是看關鍵字的部份,TWRP 換掉 recovery image,然後 LineageOS 是系統底,microG 是 open source 版本的 Google 專屬 API 的相容層,Magisk 則是負責 root 相關的事情,F-Droid 是 open source 軟體的 app store,可以用他來裝 Aurora Store,就可以裝 Play Store 裡的 app。

會這樣搞的人主要還是考慮到 privacy,可以預期有不少應用程式是不會動的...

Cloudflare 在 Argo 架構上推出 Tiered Cache Smart Topology

Cloudflare 在 Argo 架構上 (付費功能) 推出了 Tiered Cache Smart Topology:「Tiered Cache Smart Topology」、「Introducing: Smarter Tiered Cache Topology Generation」。

這邊提到的 Argo 是 Cloudflare 在 2017 年時提出來想要降低 Internet 的 routing (像是 BGP) 未必會走到最佳路徑上的問題,透過 Cloudflare 自家的骨幹網路,最佳化 latency & bandwidth & packet loss 產生的問題:「Introducing Argo — A faster, more reliable, more secure Internet for everyone」。

而 Tiered Cache 算是 CDN 行業裡面很常見的技術了,主要是要解決不同 data center 的 edge server 都去跟 origin server 要資料,而造成 origin server 的流量太大。

緩解的方式是在 edge server 與 origin server 中間疊一層 cache server,就可以大幅緩解 origin server 的流量。

origin server 流量問題在一般的應用來說還好:就算是 Windows Update 或是 iOS 更新這種基數超大的量,一開始也許會慢一點,但當 edge server 有 cache 後就不會再吃到 origin server 的頻寬。

另外也可以在公開上線前先 pre-warm,讓 edge server 都有 cache 後再上線,這樣 origin server 就不需要準備太多頻寬。

但在大型影音直播的時候就不一樣了,因為會一直產出新的內容 (之前玩的是走 HLS,所以會一直有新的 .ts 檔生出來),沒辦法先 pre-warm,這時候 origin server 就會需要大量的頻寬才有辦法支撐整個服務,所以需要 CDN 系統在中間疊一層 cache server,這個功能在各家 CDN 業者都有,只是名稱不太一樣。

記得當時用 Akamai 預設的 CDN 走直播時只有 95% 左右的 hit rate,這代表對外服務 20Gbps 就會對 origin server 產生 1Gbps 的量 (20:1),而打開 Tiered Distribution 後可以拉到 98% 甚至 99%+,相對於後端的壓力可以降到 50:1 到 100+:1。

AWSCloudFront 也有類似的架構,叫做 Regional Edge Caches:

不過這兩種架構都有一些缺點,像 Akamai 需要自己指定 cache server 的節點,這樣就不容易動態調整,或是使用者沒有設好導致 latency 偏高。

而像 AWS 這種已經已經先分好群的,就會遇到像是 origin server 與 edge server 都在台灣,但在 Regional Edge Caches 架構下必須先繞到日本 (或是新加坡),產生 latency 與 packet loss 偏高的問題。

這次 Cloudflare 在 Argo 架構推出的 Tiered Cache Smart Topology 的賣點 (Argo 本來就有提供 Tiered Cache),看起來是希望由系統自動選擇最佳的一個 data center 來當作 cache tier,不需要使用者額外設定。

不過一般網站應該還好,主力應該在電商網站與互動性很高的娛樂產業 (i.e. 操作起來要很流暢)...

Smart TV 與遊戲主機的 DNS 經常是設死的

Hacker News Daily 上看到「Your Smart TV is probably ignoring your PiHole」,裡面提到了很多遊戲主機並不會依照從 DHCP 拿到的 DNS 設定使用,而是直接設死:

Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

裡面提到的論文是「Characterizing Smart Home IoT Traffic in the Wild」這篇,裡面分析了不同種類的裝置 DNS 的狀況,以及 HTTP/HTTPS 的比率:

回到原來的文章,裡面提到了用 NAT 的方式把 1.1.1.1 的 TCP/UDP Port 53 導到 Pi-hole 上面過濾,這樣看起來還行,下面的 DNS over TLSDNS over HTTPS 因為走其他特定的 TCP port,應該是不受影響...

把 SSH Key 放進 Secure Enclave 裡保護

看到 Secretive 這個專案,是利用蘋果的 Secure Enclave 機制,把 SSH private key 放進去在裡面進行運算,避免 private key 檔案被惡意程式讀取就洩漏出去了。

從 Secure Enclave 的介紹頁面可以看到這個需要有 T1 或是 T2 晶片才有 Secure Enclave 功能:

Mac computers that contain the T1 chip or the Apple T2 Security Chip

而從 Apple Silicon 這邊可以看到 Apple T1 chip 是 2016 年後的機種引入的:

The Apple T1 chip is an ARMv7 SoC (derived from the processor in S2 SiP) from Apple driving the System Management Controller (SMC) and Touch ID sensor of the 2016 and 2017 MacBook Pro with Touch Bar.

然後對於沒有 Secure Enclave 的古董機,可以透過有支援 smart card 的硬體掛上去,像是 YubiKey

For Macs without Secure Enclaves, you can configure a Smart Card (such as a YubiKey) and use it for signing as well.

照著他講的建議去翻了「YubiKey Smart Card Deployment Guide」這邊的資料,看起來 YubiKey 在 4 系列之後就有產品支援 Smart Card 了,不過要注意純 U2F 的版本沒支援。

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

透過 WikiLeaks 公開出來的文件得知 CIAMI5 都已經有能力將後門埋入 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,裡面描述的概念現在在生活週邊愈來愈多了...

Ethereum Smart Contracts 裡的 PRNG

現代密碼學的安全性有很大一塊是基於亂數產生器 (RNG) 非常難被預測。如果這個前提不成立的話,利用亂數產生器產生出來的各種資訊都會被預測出來 (尤其是 Private Key)。

但真正的 RNG 需要靠硬體支援,而且產生速度很慢,一般都會使用 PRNG (Pseudorandom number generator) 產生。也就是「看起來」很亂的亂數產生器。

PRNG 通常是指在統計學上通過許多測試,像是在多種測試都是 Discrete uniform distribution,不需要防止有惡意人,可以從產生出的 PRNG 的值而推導出後續結果的用途。

在「Predicting Random Numbers in Ethereum Smart Contracts」這篇裡面,作者列出了一堆實做 Ethereum Smart Contracts 卻誤用 PRNG 的行為。

文章裡提到的問題都是因為 PRNG 拿著可被預測的資訊當作 entropy source (e.g. seed),而且提出來的範例都是拿 block 本身或衍生的資訊 (像是 block 的 hash) 來用:

  • PRNGs using block variables as a source of entropy
  • PRNGs based on a blockhash of some past block
  • PRNGs based on a blockhash of a past block combined with a seed deemed private
  • PRNGs prone to front-running

然後列了大量的程式碼當例子,建議有需要接觸的人看過一次,或是有時間的人都值得看這些負面範例... XDDD

不過作者在文章裡面也給了一堆有問題的方法,像是從外部網站取得亂數之類的 XDDD

正確的方法是使用 CSPRNG (Cryptographically secure pseudorandom number generator),這是專門設計給密碼學用的 PRNG。

CSPRNG 有幾種方法可以取得:

  • 在大多數的程式語言內都有對應的 library 可以用,另外在比較近代的瀏覽器內 (如果問 IE 的話,是 11+),可以透過 RandomSource.getRandomValues() 得到。
  • 如果打算自己搞底層而需要直接取得 CSPRNG 的產出,在 Unix-like 的環境下可以透過 /dev/urandom 取得,在 Microsoft Windows 下則可以透過 CryptGenRandom 取得。

別學作者那邊奇怪方法啊 XDDD