Tag: id

利用 Sensor 校正資訊產生 Device Fingerprint 的隱私攻擊

看到「Fingerprinting iPhones」這篇提出的攻擊，標題雖然是提到 iPhone，但實際上攻擊包括了 Android 的手機：

You are affected by this fingerprinting attack if you are using any iOS devices with the iOS version below 12.2, including the latest iPhone XS, iPhone XS Max, and iPhone XR. You are also likely to be affected if you are using a Pixel 2/3 device, although we hypothesise the generated fingerprint has less entropy and is unlikely to be globally unique. A SensorID can be generated by both apps and mobile websites and requires no user interaction.

目前 iPhone 升級到 12.2 之後可以緩解這個問題，Android 看起來還不清楚...

攻擊的方式是透過手機在出場前會使用外部的校正工具，找出手機內 sensor 所偵測到的值與實際值的差異，然後把這些資訊燒到韌體裡，當呼叫 API 時就可以修正給出比較正確的值。

而因為這些校正資訊幾乎每一隻手機都不一樣，而且不會因為重裝而變更 (即使 factory reset)，加上還可以跨 app 與 web 追蹤，就成為這次攻擊的目標：

In the context of mobile devices, the main benefit of per-device calibration is that it allows more accurate attitude estimation.

資訊量其實相當大，透過 app 分析可以得到 67 bits entropy，透過網頁也有 42 bits entropy，而且不怎麼會變：

In general, it is difficult to create a unique fingerprint for iOS devices due to strict sandboxing and device homogeneity. However, we demonstrated that our approach can produce globally unique fingerprints for iOS devices from an installed app -- around 67 bits of entropy for the iPhone 6S. Calibration fingerprints generated by a website are less unique (~42 bits of entropy for the iPhone 6S), but they are orthogonal to existing fingerprinting techniques and together they are likely to form a globally unique fingerprint for iOS devices.

We have not observed any change in the SensorID of our test devices in the past half year. Our dataset includes devices running iOS 9/10/11/12. We have tested compass calibration, factory reset, and updating iOS (up until iOS 12.1); the SensorID always stays the same. We have also tried measuring the sensor data at different locations and under different temperatures; we confirm that these factors do not change the SensorID either.

目前提出來的解法是加入隨機值的噪音 (iOS 的作法)，不過作者有建議預設應該要關閉 js 存取 sensor 的權限：

To mitigate this calibration fingerprint attack, vendors can add uniformly distributed random noise to ADC outputs before calibration is applied. Alternatively, vendors could round the sensor outputs to the nearest multiple of the nominal gain. Please refer to our paper for more details. In addition, we recommend privacy-focused mobile browsers add an option to disable the access to motion sensors via JavaScript. This could help protect Android devices and iOS devices that no longer receive updates from Apple.

不過當初這群人怎麼會注意到的...

就算關掉 Google 的定位服務也還是會蒐集位置資訊...

就如標題所寫的，Quartz 獨家刊出來的新聞，即使你關掉 Google 的定位服務，Google 還是會蒐集你的位置 (而且跟 Google 發言人確認後也證實)：「Google collects Android users’ locations even when location services are disabled」。

而且是全背景作業，在你沒有開定位服務，沒有插 SIM 卡，也沒有跑任何 app，他就會將定位資訊傳出去：

Many people realize that smartphones track their locations. But what if you actively turn off location services, haven’t used any apps, and haven’t even inserted a carrier SIM card?

從今年年初開始這樣搞的，Google 發言人只宣稱這個資料並沒有被用來整合到「network sync system」，並且會立即丟掉 (所以你還是不知道被用到什麼地方)：

“In January of this year, we began looking into using Cell ID codes as an additional signal to further improve the speed and performance of message delivery,” the Google spokesperson said in an email. “However, we never incorporated Cell ID into our network sync system, so that data was immediately discarded, and we updated it to no longer request Cell ID.”

這句話的意思其實代表著是丟掉 raw data，改以統計的方式轉移存到其他系統。

另外 John Gruber 在「Google Collects Android Users' Locations Even When Location Services Are Disabled」其實寫的更直接：

If they were “never used or stored”, why did they start collecting them in the first place? This is like a kid caught with their hand in the cookie jar saying they weren’t going to eat any cookies. Sure.

白話一點就是「你當我傻逼啊」。

應該會促進 microG 的發展... (參考「microG 的進展...」)

解鎖 iPhone 的 Diper ID...

Twitter 上看到 Diper ID 這個糟糕的東西：

查了資料，操作方式可以從這個影片看到：

這明顯有資安問題啊 XDDD

iOS App 的釣魚

在「iOS Privacy: steal.password - Easily get the user's Apple ID password, just by asking」這邊作者示範了怎麼釣魚：直接模擬 iOS 的系統視窗跟使用者要密碼。

看了只有「操」... 目前想的到的 workaround 只有在看到類似的視窗時跳回主畫面，透過 Settings 裡確認？

Reddit 在處理 Page View 的方式

Reddit 說明了他們如何處理 pageview：「View Counting at Reddit」。

以 Reddit 的規模有提到兩個重點，第一個在善用 Redis 的 HyperLogLog 這個資料結構，當量大的時候其實可以允許有微小的誤差：

The amount of memory varies per implementation, but in the case of this implementation, we could count over 1 million IDs using just 12 kilobytes of space, which would be 0.15% of the original space usage!

維基百科上有說明當資料量在 109 這個等級時，用 1.5KB 的記憶體只有 2% 的誤差值：

The HyperLogLog algorithm is able to estimate cardinalities of > 109 with a typical error rate of 2%, using 1.5 kB of memory.

第二個則是寫入允許短時間的誤差 (pageview 不會即時反應)，透過批次處理降低對 Cassandra cluster 的負荷：

Writes to Cassandra are batched in 10-second groups per post in order to avoid overloading the cluster.

可以注意到把 Redis 當作 cache 層而非 storage 層。

主要原因應該跟 Redis 定位是 data structure server 而非 data structure storage 有關 (可以從對 Durability 的作法看出來)，而使用 Cassandra 存 key-value 非常容易 scale，但讀取很慢。剛好兩個相輔相成。

用 Amazon Elasticsearch 看 VPC Flow Logs

在「How to Visualize and Refine Your Network’s Security by Adding Security Group IDs to Your VPC Flow Logs」這篇雖然是講特定功能，但還是把怎麼架設從頭到尾都講了一次...

比較特別的幾張圖：

然後再回來看怎麼串：

配合 Touch ID 的 sudo

大概是新的 Macbook 出來後想出來的點子？透過 Touch ID 驗證 sudo 權限：「A fork of `sudo` with Touch ID support.」。

sudo-touchid is a fork of sudo with Touch ID support on macOS (powered by the LocalAuthentication framework). Once compiled, it will allow you to authenticate sudo commands with Touch ID in the Terminal on supported Macs (such as the late 2016 MacBook Pros).

這點子好像還不錯 XDDD

PGP 短 ID 的安全問題

PGP 短 ID 的安全問題出來了，不見棺材不掉淚啊：「Fake Linus Torvalds' Key Found in the Wild, No More Short-IDs.」。

重點在這段，已經有人發出攻擊了：

Search Result of 0x00411886: https://pgp.mit.edu/pks/lookup?search=0x00411886&op=index
Fake Linus Torvalds: 0F6A 1465 32D8 69AE E438  F74B 6211 AA3B [0041 1886]
Real Linus Torvalds: ABAF 11C6 5A29 70B1 30AB  E3C4 79BE 3E43 [0041 1886]

Search Result of 0x6092693E: https://pgp.mit.edu/pks/lookup?search=0x6092693E&op=index
Fake Greg Kroah-Hartman: 497C 48CE 16B9 26E9 3F49  6301 2736 5DEA [6092 693E]
Real Greg Kroah-Hartman: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 [6092 693E]

另外作者給了還蠻重要的觀念：

DO NOT TRUST ANYTHING SHORTER THAN THE FINGERPRINTS.

Facebook 上貼的所有的連結都是公開的

tl;dr：Facebook 認為這個功能是 feature，不是 bug。

在「Why you shouldn’t share links on Facebook」這邊作者發現在 Facebook 上貼的「任何一個連結」都會產生 object id，而任何一個 object id 都可以直接取得 url，無論權限設定，像是這樣：

而 Facebook 認定這是 feature 而非 bug：

可以想像 NSA 之類的單位與地下組織開始狂掃...

PostgreSQL 對 Vacuum 效能的改善

在「No More Full-Table Vacuums」這邊提到了 PostgreSQL 在 vacuum 時效能的大幅改善，尤其是大型資料庫在 vacuum 時需要對整個表格從頭到尾掃一次以確保 transaction id 的正確性：

Current releases of PostgreSQL need to read every page in the database at least once every 2 billion write transactions (less, with default settings) to verify that there are no old transaction IDs on that page which require "freezing".

這動作在資料量大的機器上就會吃大量資源導致各種討厭的現象：

All of a sudden, when the number of transaction IDs that have been consumed crosses some threshold, autovacuum begins processing one or more tables, reading every page. This consumes much more I/O bandwidth, and exerts much more cache pressure on the system, than a standard vacuum, which reads only recently-modified page.

而作者送了 patch 改成只會讀還沒搞定的部份：

Instead of whole-table vacuums, we now have aggressive vacuums, which will read every page in the table that isn't already known to be entirely frozen.

要注意的是，agreesive vacuum 相較於 vacuum 會多吃很多資源，但可以打散掉 (有點像一次大 GC 導致 lag 與多次 minor GC 讓程式反應時間變得比較順暢的比較)：

An aggressive vacuum still figures to read more data than a regular vacuum, possibly a lot more. But at least it won't read the data that hasn't been touched since the last aggressive vacuum, and that's a big improvement.

這個功能預定在 PostgreSQL 9.6 出現，不知道會不會變 default...