LastPass 離職員工的爆料

這次 LastPass 出包搞的蠻大的,在官方的「Notice of Recent Security Incident」的裡面有提到這次的資料外洩包括了使用的 encrypted vault data 也被洩漏了:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

官方一直強調這是 encrypted data,但離職員工爆料加密強度不足的問題:「1606428769731878913.html」,其中這段在講 legacy 版本的加密問題,居然曾經用過 ECB mode

Lots of vault entries may be encrypted with ECB mode AES-256. I worked on supporting unauthenticated CBC mode. But re-encrypting a users vault entries requires having their master key.

這個如同 Hacker News 上的討論「I worked at LastPass as an engineer (twitter.com/ejcx_)」提到的,以 1980 年代的標準就已經知道 ECB mode 的問題了:

> Lots of vault entries may be encrypted with ECB mode AES-256.
Wtf wtf wtf. This would be considered wildly insecure even by the standards of the 80s

其他提到 PBKDF2 的強度是逐步增加,從早期的 5000 到現在預設的 100100,這點倒是可以理解。

要避免依賴廠商的資安,一種方式是用目前成熟的開源 Password Manager,並且使用檔案儲存 (像是 KeePassXC 這類工具),再搭配 file sync 的工具跨機器使用 (像是 Syncthing 這樣獨立確認每個 device 身份的方式),但方便性不會像這些商用方案這麼好用就是了...

這次故事好像還沒結束,遇到西方的長假,反應都比較慢...

Facebook 5.33 億筆個資外洩,以及 Mark Zuckerberg 的電話...

這兩天應該已經有很多其他媒體報導了 Facebook 5.33 億筆資料外洩的事情:「533 million Facebook users' phone numbers and personal data have been leaked online」。

據稱是用 2019 年的洞撈出來的,不過這份資料看起來也不是完整資料,舉個例子來說,台灣只有 73 萬筆左右,而且也少了很多地區,像是泰國就不在列表內...

另外一個比較特別的是,Mark Zuckerberg 的電話也在這次外洩資料裡面:「Mark Zuckerberg's phone number appeared among the leaked data of Facebook users, according to a researcher」,應該會換號碼了。

這包資料看起來會這陣子會很熱門...

Imgur 也漏資料了... (帳號與密碼)

Imgur 官方發佈公告說明他們發現資料洩漏了:「Notice of Data Breach」,資料的洩漏是發生在 2014 年,包括了帳號與密碼:

Early morning on November 24th, we confirmed that approximately 1.7 million Imgur user accounts were compromised in 2014. The compromised account information included only email addresses and passwords. Imgur has never asked for real names, addresses, phone numbers, or other personally-identifying information (“PII”), so the information that was compromised did NOT include such PII.

然後 2014 年用的是 SHA-256

We have always encrypted your password in our database, but it may have been cracked with brute force due to an older hashing algorithm (SHA-256) that was used at the time. We updated our algorithm to the new bcrypt algorithm last year.

以單台八張 GTX 1080hashcat 的速度來看 (出自「8x Nvidia GTX 1080 Hashcat Benchmarks」),是 23GH/z 左右:

Hashtype: SHA256

Speed.Dev.#1.: 2865.2 MH/s (96.18ms)
Speed.Dev.#2.: 2839.8 MH/s (96.65ms)
Speed.Dev.#3.: 2879.5 MH/s (97.14ms)
Speed.Dev.#4.: 2870.6 MH/s (96.32ms)
Speed.Dev.#5.: 2894.2 MH/s (96.64ms)
Speed.Dev.#6.: 2857.7 MH/s (96.78ms)
Speed.Dev.#7.: 2899.3 MH/s (96.46ms)
Speed.Dev.#8.: 2905.7 MH/s (96.26ms)
Speed.Dev.#*.: 23012.1 MH/s

這對於鍵盤可以打出的所有字元來計算 (95 chars),八個字的密碼只要 3.33 天就可以跑完;如果只考慮英文數字 (62 chars),九個字的密碼只要 6.81 天。

這些還不是最新的 GPU,而且是單機計算,對於現在的攻擊應該會用 ASIC,可以考慮多三到四個數量級的數度在算 (看財力才會知道買多少機器)。

不過 Imgur 的帳號主要是參與討論 (因為不用帳號密碼也可以上傳圖片),一般比較不會在上面註冊... 真的有註冊的因為沒有其他個資,主要是怕共用密碼的問題。如果有用 password manager 應該也還好。

以色列黑了 Kaspersky 的系統,然後通報美國機密資料外洩...

前幾天在「俄羅斯政府透過卡巴斯基的漏洞,偷取美國國安局的文件」這邊提到了俄羅斯是透過 Kaspersky 的漏洞取得,後續又有些消息揭露出來了...

這件事情會被抓包,是因為以色列黑進去 Kaspersky 的系統 (???),然後發現美國的機密資料外洩 (??????),於是通報盟友美國後追查出來的 (?????????):「Israel hacked Kaspersky, then tipped the NSA that its tools had been breached」。

這過程是殺小 XDDD

Yahoo! 的資料外洩數量超過之前公佈的十億筆,上升到三十億筆

Oath (Y! 的新東家,Verizon 持股) 發表了新的通報,外洩數量直接上升到 3 billion 了:「Yahoo provides notice to additional users affected by previously disclosed 2013 data theft」。

也就是當時所有的使用者都受到影響:

Subsequent to Yahoo's acquisition by Verizon, and during integration, the company recently obtained new intelligence and now believes, following an investigation with the assistance of outside forensic experts, that all Yahoo user accounts were affected by the August 2013 theft.

在「Yahoo says all 3 billion user accounts were impacted by 2013 security breach」這邊的報導則是寫的比較清楚,把當時的使用者數字翻出來:

Yahoo today announced that the huge data breach in August 2013 affected every user on its service — that’s all three billion user accounts and up from the initial one billion figure Yahoo initially reported.

2013 這包用的是 MD5 hash,以現在的運算能力來看,可以當作沒有 hash...:

The stolen user account information may have included names, email addresses, telephone numbers, dates of birth, hashed passwords (using MD5) and, in some cases, encrypted or unencrypted security questions and answers.

已經是 "all" 了,接下來要更大包只能是其他主題了...

完全關閉 HTTPS 的 gzip

在「Perceived Web Performance – What Is Blocking the DOM?」這邊看到 Google PageSpeed Insights,突然發現我的 nginx 設定還是有打開 gzip,而目前因為 BREACH 攻擊的關係,有 cookie 的 SSL/TLS 下不應該開 gzip:

gzip off;

目前好像沒有比較好的解法可以對抗 BREACH...

這次的 Ashley-Madison 資料外洩

在「Notes on the Ashley-Madison dump」這邊給了這次婚外情約會網站 Ashley Madison 資料外洩的註解,甚至還包括 BitTorrentmagnet:// 下載連結...

將近四千萬筆資料的資料外洩 (實際約三千六百萬),男性為大宗,約 28 million 是男性,5 million 女性 (依據 gender 欄位),有 2 million 無法確認。不過如果交叉比對信用卡資料,會發現只有男性付費:

It's heavily men. I count 28-million men to 5 million woman, according to the "gender" field in the database (with 2-million undetermined). However, glancing through the credit-card transactions, I find only male names.

另外是密碼儲存方式是 bcrypt

Passwords hashed with bcrypt. Almost all the records appear to be protected with bcrypt. This is a refreshing change. Most of the time when we see big sites hacked, the passwords are protected either poorly (with MD5) or not at all (in "clear text", so that they can be immediately used to hack people). Hackers will be able to "crack" many of these passwords when users chose weak ones, but users who strong passwords are safe.

整包是 9.7GB 的壓縮資料... FreeBuf.COM 也整理了一篇:「七夕将至,婚外情网站数据终于裸奔了」。

Facebook 在對抗 BREACH Attack 的方法

在「Facebook Takes Tougher Stand Against BREACH Attack」這篇提到 Facebook 在 2012 年對抗 BREACH attack 的方法:

在文章最後面有提到當時一般建議的 migrate 方式 (關閉 TLS 的壓縮) 不適用於 Facebook:

Turning off compression is not an option for large dynamic sites such as Facebook because it would hinder performance dramatically.

而且就算關掉 TLS 的 compression,也還是有疑慮:

Even if TLS-level compression is disabled, it is very common to use gzip at the HTTP level. Furthermore, it is very common that secrets (such as CSRF tokens) and user input are included in the same HTTP response, and therefore (very likely) in the same compression context,

節錄幾段 migrate 的重點:

Facebook disclosed how it’s mitigating BREACH attacks by changing the frequency in which it rotates CSRF tokens from daily to each time a Facebook session is started.

本來 CSRF token 變更的頻率是好幾天一次,把頻率拉高...

After a new token is issued, the previous tokens still remain valid for a couple days, resulting in multiple tokens being permissible simultaneously.

然後舊的 token 還是會保持一段時間有效。

因為現實因素而沒辦法在 TLS 層關閉,後面在 application level 的 workaround 相當費功... (而且要多花不少資源?)

新的 HTTPS 攻擊:BREACH Compression Attack

也是一個禮拜前的消息,在 Slashdot 上看到對 HTTPS 的新攻擊,目前沒有好解法,NSA 應該開心到爆炸:「BREACH Compression Attack Steals SSL Secrets」。

說明可以參考「Vulnerability Note VU#987798 BREACH vulnerability in compressed HTTPS」這篇。

假設你的 ISP 想要抓出你的 Facebook (HTTPS) session id 或是 CSRF token (只要是有能力在中間攔截封包並修改資料的團體都可以,這邊以 ISP 為例),作法是針對 HTTP 頁面值入 script,讓你的瀏覽器對 https://www.facebook.com/ 發出大量 request,藉由觀察這些 HTTPS 的長度就有機會取得 session id (或 CSRF token)...

CERT 的 security advisory 上是寫:

With a token of length 32 and a character space of size 16 (e.g. hex), the attacker needs an average of approximately 1,000 request if no recovery mechanisms are needed. In practice, we have been able to recover CSRF tokens with fewer than 4,000 requests. A browser like Google Chrome or Internet Explorer is able to issue this number of requests in under 30 seconds, including callbacks to the attacker command & control center.

四千次就搞定了... 太!歡!樂!了!