信用卡的先天缺陷造成盜刷問題

在「Guessing Credit Card Security Details」這邊看到的攻擊手法,基本上無解,除非信用卡的網路交易也全面改成使用晶片...

手法其實很簡單,就是先算出一個合法的卡號,然後分兩階段攻擊取得資訊:

  • 先去找數家只需要「卡號 + 日期」的網站,用暴力法踹出日期 (假設五年就是 60 次)。
  • 再去找數十家需要「卡號 + 日期 + CVV2」的網站,用暴力法踹出 CVV2 (1000 次)。

所以 1060 次就擺平了... 就算所有網站都需要 CVV2,也是 60000 次的嘗試而已 (找數千個網站來踹),算是完全可行的方案。而目前只能靠 workaround 來防止,像是需要多輸入姓名與地址之類的資訊來擋...

Libgcrypt 與 GnuPG 的安全性問題

在「Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316]」這邊看到這個歷史悠久的 bug:

Felix Dörre and Vladimir Klebanov from the Karlsruhe Institute of Technology found a bug in the mixing functions of Libgcrypt's random number generator: An attacker who obtains 4640 bits from the RNG can trivially predict the next 160 bits of output. This bug exists since 1998 in all GnuPG and Libgcrypt versions.

就這樣的行為,對於自己用的機器應該是還好... 不過得到 4640 bits 後就可以預測接下來的 160 bits,這個 RNG 有點囧 @_@

官方目前是認為應該還好:

A first analysis on the impact of this bug in GnuPG shows that existing RSA keys are not weakened. For DSA and Elgamal keys it is also unlikely that the private key can be predicted from other public information. This needs more research and I would suggest _not to_ overhasty revoke keys.

不過如果你有絕對的安全需求的話還是可以考慮 revoke 再重新生一把...

Google 對國際電話號碼格式常見誤解的說明

Google 對於國際電話號碼格式常見誤解的說明:「Falsehoods Programmers Believe About Phone Numbers」。

先看最後一個:

15. Phone numbers are always written in ASCII
In Egypt, it is common for phone numbers to be written in native digits.

電話號碼不是 ASCII 可以搞定的喔!!!然後你就可以理解沒什麼是不可能的 XDDD

這個系統是靠各種 backward compatible workaround 堆出來的,你覺得的假設通通會被推範 XDDD

四位數密碼的分佈

分析信用卡四位數密碼的分佈:「PIN number analysis」。

透過已經外洩的資料分析:

Obviously, I don’t have access to a credit card PIN number database. Instead I’m going to use a proxy. I’m going to use data condensed from released/exposed/discovered password tables and security breaches.

19xx 那邊特別高,拉出來看可以看到分佈:(很像是出生年 XDDD)

相同的 abab (前兩碼與後兩碼相同) 也可以看出特別高,而 aaaa (四碼都一樣) 的特別亮:

當不只四碼時,也有一些數據:

另外是特別高的 1004 的原因:

Many people also asked the significance of 1004 in the four character PIN table. This comes from Korean speakers. When spoken, "1004" is cheonsa (cheon = 1000, sa=4).

"Cheonsa" also happens to be the Korean word for Angel.

V8 Engine 的 Math.random() 在新版被重寫了...

先前在「V8 的 Math.random() 亂度不足的問題」提到 Math.random() 因為使用 MWC1616 (Fast random number generation using 128 bit multimedia extension registers on Pentium class machines) 而不夠亂的問題。

這個問題在新版 V8 Engine 提出改善了:「There's Math.random(), and then there's Math.random()」。

Untitled drawing

新實作的方法是 xorshift128+,擁有極長的 period length:

This has been pointed out to us, and having understood the problem and after some research, we decided to reimplement Math.random based on an algorithm called xorshift128+. It uses 128 bits of internal state, has a period length of 2128 - 1, and passes all tests from the TestU01 suite.

將會在 Google Chrome 49 (目前是 47) 引入:

The new implementation landed in V8 4.9.41.0 within a few days of us becoming aware of the issue. It will become available with Chrome 49. Both Firefox and Safari switched to xorshift128+ as well.

同時還是再次提醒,這不是 CSPRNG,要用在密碼學相關應用還是要用專門的 library 來產生 pseudo random number:

Make no mistake however: even though xorshift128+ is a huge improvement over MWC1616, it still is not cryptographically secure.

V8 的 Math.random() 亂度不足的問題

在「TIFU by using Math.random()」這篇看到作者踩到地雷,於是在討論 V8 EngineMath.random() 的亂度不足。

其實這個問提早在 2012 年就有人在 StackOverflow 上詢問:「Why is Google Chrome's Math.random number generator not *that* random?」,而且也回答得很清楚。

而 Mozilla 這邊在 2006 年也被提出了類似的問題:「Bug 322529 - Upgrade Math.random() to a better algorithm, such as Mersenne Twister」。

文章中間花了許多篇幅講 PRNG 的介紹,以及 cycle length 的說明,重點其實在結論的部份。

主要是因為 V8 Engine 的 Math.random() 實作的是 MWC1616 演算法 (Fast random number generation using 128 bit multimedia extension registers on Pentium class machines),而這個演算法用起來也綁手綁腳:

If you’re only using the most significant 16 bits it has a very short effective cycle length (less than 2³⁰).

有兩個方向可以改善 (不衝突的方向),一個是使用 CSPRNG (保證有極長的 cycle length),另外一個請求 V8 Engine 把 Math.random() 的演算法換掉,像是 MT19937 這類 cycle length 超級長的演算法。

不知道後續有沒有機會改善...

利用 WPS 實做上的問題攻擊,而取得 WPA 密碼

在「Wi-Fi Router Attack Only Requires a Single PIN Guess」這邊看到利用 WPS 實做上的弱點攻擊而取得 WPA 的密碼。

投影片取自「Offline bruteforce attack on WiFi Protected Setup」這邊:

利用各種方法攻擊,像是不夠安全的 PRNG (Pseudo Random Number Generator)。

作者的建議是,關掉 WPS 會比較安全 XD

利用 Facebook Notes 對圖片 cache 的特性發動 DDoS 攻擊

在「Using Facebook Notes to DDoS any website」這篇文章裡提到了利用 Facebook Notes 允許使用者嵌入 <img> 標籤時的特性,利用 Facebook 的 server 進行 DDoS...

在 Notes 一般的 <img> 會被 Facebook 的伺服器 cache 起來,但如果是帶有 query string 的 <img> 就不會 cache (因為不同的 query string 表示不同的 url 是合理的),於是就可以利用這個特性打出超高的流量:

這個問題被 Facebook 認為不是問題,不會也不打算修正...

文章後提到的指令還蠻有趣的,要抓出某個 AS number 有哪些 IP address,可以用這樣的指令抓出來:

whois -h whois.radb.net — '-i origin AS32934' | grep ^route

試著抓了 AS9916 與 AS18185,的確是蠻有趣的東西 XD

NSA 付錢給 RSA 放後門的事件...

Edward Snowden 再次丟出 NSA 內部文件,表示 NSA 付錢給 RSA 在演算法裡面放後門:「Exclusive: Secret contract tied NSA and security industry pioneer」。

RSA 的回應則是完全不想提到這筆錢是做什麼用的:「RSA Response to Media Claims Regarding NSA Relationship」。

現在一般在猜測,這個後門應該就是 RSA BSAFE 的預設偽隨機數產生器 Dual_EC_DRBG

對於 Dual_EC_DRBG 的攻擊,2006 年的「Cryptanalysis of the Dual Elliptic Curve Pseudorandom Generator」就這樣寫:

Our experimental results and also empirical argument show that the DEC PRG is insecure. The attack does not imply solving the ECDLP for the corresponding elliptic curve. The attack is very efficient.

在 2007 年,Bruce Schneier 寫了一篇「Did NSA Put a Secret Backdoor in New Encryption Standard?」,提到這個弱點並沒有大到使得這個演算法不堪用,但看了總是不爽:

Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias. The problem isn't large enough to make the algorithm unusable -- and Appendix E of the NIST standard describes an optional work-around to avoid the issue -- but it's cause for concern. Cryptographers are a conservative bunch: We don't like to use algorithms that have even a whiff of a problem.

並且建議不要用 Dual_EC_DRBG:

My recommendation, if you're in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.

現在回頭看這件事情... hmmm...