Tag: security

SWEET32：攻 Blowfish 與 3DES

最新的攻擊算是實戰類的攻擊，理論基礎以前都已經知道了，只是沒有人實際「完成」。算是近期少數直接對演算法的攻擊，而這些演算法剛好還是被用在 TLS 與 OpenVPN 上，所以嚴重性比較高：「SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN」。

攻擊的條件是 block cipher 的 block size，而非 key length，所以就算是 256 bits 的 Blowfish 也一樣也受到影響。

這次順利打下 Blowfish 與 3DES。這兩個 cipher 的 block size 都是 64 bits，所以對於 birthday attack 來說只要 232 就可以搞定：

This problem is well-known by cryptographers, who always require keys to be changed well before 2n/2 blocks. However it is often minimized by practitioners because the attacks require known plaintext, and reveal only little information. Indeed, standard bodies only recommend to change the key just before 2n/2 blocks, and many implementations don't enforce any limit on the use of a key.

在 OpenVPN 打 Blowfish 的部份 (Blowfish 是 OpenVPN 預設的 cipher)：

In our demo, it took 18.6 hours and 705 GB, and we successfully recovered the 16-byte authentication token.

以及 HTTPS 打 3DES 的部份 (為了相容性問題)：

Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.

都是有可能的等級。也該來拔掉對 IE8 的支援了... orz

NIST 新的密碼規範

由 NIST 所提出來的規範 (Special Publication 800-63-3: Digital Authentication Guidelines)，雖然還在 Draft 階段，但可以看出目前密碼規範的趨勢跟以前的不同：「NIST’s new password rules – what you need to know」。

整份規範可以在 GitHub 上讀到，不過 markdown 好像沒處理好，直接在 GitHub 上看到的有點亂，不過還算看得懂就是了...

在 NIST 網站上有 html 版本「Digital Authentication Guideline: Public Preview」可以讀，應該會好一些。

整份 guideline 很長，密碼的部份主要是在「DRAFT NIST Special Publication 800-63B Digital Authentication Guideline」這份裡面關於「Memorized Secrets」的部份。

先講對一般業者最不能理解的事情：

  • 有「安全問題」反而會讓系統安全變弱。
  • 要求使用者有大小寫、特殊符號這種讓使用者更難記密碼的限制，反而會讓使用者選出更差的密碼。讓使用者自由選擇密碼，同時用黑名單機制把常見的密碼擋下來會是比較好的選擇。
  • 定期換密碼反而會讓使用者選擇更差的密碼 (因為要花力氣記，所以會選擇簡單的密碼)，不如讓使用者選一個強一點的密碼一直用。同時要合理設計限制登入錯誤的機制。
  • 絕對不可以存明碼。

下面開始 copy & paste 然後給簡單的註釋...

首先是對最低長度的定義，至少要八碼。而對最大長度的限制是「至少你要讓使用者可以輸入 64 碼」：

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHALL permit user-chosen memorized secrets to be at least 64 characters in length.

密碼不應該限制特殊字元，只要可以印出來的 ASCII 與空白都應該被允許，而 Unicode 也應該要被允許：

All printing ASCII [RFC 20] characters as well as the space character SHALL be acceptable in memorized secrets; Unicode [ISO/ISC 10646:2014] characters SHOULD be accepted as well.

空白可以被濾掉來判斷，但其他的字元都應該被當作強密碼的一部分來判斷：

Verifiers MAY remove space characters prior to verification; all other characters SHALL be considered significant.

要注意的是，為了強度，每一個 Unicode 應該只算一個有效字元：

For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

當密碼是隨機被系統設定時，可以是六個字元的強隨機數字：

Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters in length and SHALL be generated using an approved random number generator.

另外很重要的是，不應該有提示存取的功能，也就是「安全問題」不安全，所以要被禁止：

Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

然後針對已知的弱密碼 (像是字典單字，以及之前被洩漏出來的密碼) 都應該擋下來：

When processing requests to establish and change memorized secrets, verifiers SHOULD compare the prospective secrets against a dictionary of known commonly-used and/or compromised values. This list SHOULD include passwords from previous breach corpuses, as well as dictionary words and specific words (such as the name of the service itself) that users are likely to choose. If the chosen secret is found in the dictionary, the subscriber SHOULD be required to choose a different value. The subscriber SHOULD be advised that they need to select a different secret because their previous choice was commonly used.

另外不應該要求使用者要特殊字元或是大小寫這種限制，而且也不應該要求使用者定期換密碼 (除非確認被破了)：

Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change.

另外禁止用明碼存密碼，必須用 PBKDF2 這類可以防禦快速離線計算的演算法：

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in [SP800-132]. The salt value SHALL be a 32 bit (or longer) random value generated by an approved random number generator and is stored along with the hash result. At least 10,000 iterations of the hash function SHOULD be performed. A keyed hash function (e.g., HMAC), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

Cisco 與 Fortinet 防火牆的 RCE 漏洞

NSA 使用這些漏洞來大量監聽企業的流量：「Leaked Exploits are Legit and Belong to NSA: Cisco, Fortinet and Snowden Docs Confirm」。

Cisco 已經確認這個安全性漏洞了，全系列包括已經停產的 Cisco PIX、上個世代的 Cisco ASA 5500 (但還有些型號還在賣)，以及目前主力的 Cisco ASA 5500-X，另外還包括了安全模組系列也中獎：「Cisco Adaptive Security Appliance SNMP Remote Code Execution Vulnerability」。

  • Cisco ASA 5500 Series Adaptive Security Appliances
  • Cisco ASA 5500-X Series Next-Generation Firewalls
  • Cisco ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
  • Cisco ASA 1000V Cloud Firewall
  • Cisco Adaptive Security Virtual Appliance (ASAv)
  • Cisco Firepower 4100 Series
  • Cisco Firepower 9300 ASA Security Module
  • Cisco Firepower Threat Defense Software
  • Cisco Firewall Services Module (FWSM)*
  • Cisco Industrial Security Appliance 3000
  • Cisco PIX Firewalls*

標星號的是目前已經沒有在維護的產品，這次只確認受到影響，但不會更新：

Cisco Firewall Service Modules and Cisco PIX Firewalls have passed the last day of software support milestone as stated in the published End of Life (EoL) documents. Further investigations into these devices will not be performed, and fixed software will not be made available.

這次 Cisco 的安全性問題是 SNMP 的洞造成的：

Administrators are advised to allow only trusted users to have SNMP access and to monitor affected systems using the snmp-server host command.

這個洞被 NSA 用來寫 exploit 植入系統：

This flaw was included inside two NSA exploits, dubbed EPICBANANA as well as JETPLOW, which is an enhanced version of EPICBANANA, but with better persistence capabilities, Cisco's Omar Santos said in a blog post.

在 NSA 洩漏出來的文件裡可以看到 ace02468bdf13579 這個特殊辨識字串，而在受感染的樣本上也找到了這個痕跡：

而且不只是 Cisco，其他幾家也中獎了，可以參考「The NSA Leak Is Real, Snowden Documents Confirm」這邊更多的資訊 @_@

Facebook 用哪些資訊來決定投放給你的廣告

華盛頓郵報整理出來了 Facebook 的廣告所使用的 98 個個人資訊：「98 personal data points that Facebook uses to target ads to you」。

基本的個人資訊 (甚至是朋友的)，以及使用什麼瀏覽器都可以預期；而 Like 或是參加的 Group 都會被計算也是意料中的事情，不過連信用卡的種類也都在內就頗特別的...

來檢視一下自己的防禦機制有哪些... 瀏覽器預設擋下第三方 cookie：

用 Ghostery 預設把所有外部元件擋下來，再用白名單開想要看的部份。用 uBlock Origin 擋下所有廣告。

另外用「Force Facebook Most Recent」強制 Facebook 轉到 Most Recent 的 Timeline 上。

不知道這樣夠不夠用...

最後來列出這 98 個條件：

  1. Location
  2. Age
  3. Generation
  4. Gender
  5. Language
  6. Education level
  7. Field of study
  8. School
  9. Ethnic affinity
  10. Income and net worth
  11. Home ownership and type
  12. Home value
  13. Property size
  14. Square footage of home
  15. Year home was built
  16. Household composition
  17. Users who have an anniversary within 30 days
  18. Users who are away from family or hometown
  19. Users who are friends with someone who has an anniversary, is newly married or engaged, recently moved, or has an upcoming birthday
  20. Users in long-distance relationships
  21. Users in new relationships
  22. Users who have new jobs
  23. Users who are newly engaged
  24. Users who are newly married
  25. Users who have recently moved
  26. Users who have birthdays soon
  27. Parents
  28. Expectant parents
  29. Mothers, divided by “type” (soccer, trendy, etc.)
  30. Users who are likely to engage in politics
  31. Conservatives and liberals
  32. Relationship status
  33. Employer
  34. Industry
  35. Job title
  36. Office type
  37. Interests
  38. Users who own motorcycles
  39. Users who plan to buy a car (and what kind/brand of car, and how soon)
  40. Users who bought auto parts or accessories recently
  41. Users who are likely to need auto parts or services
  42. Style and brand of car you drive
  43. Year car was bought
  44. Age of car
  45. How much money user is likely to spend on next car
  46. Where user is likely to buy next car
  47. How many employees your company has
  48. Users who own small businesses
  49. Users who work in management or are executives
  50. Users who have donated to charity (divided by type)
  51. Operating system
  52. Users who play canvas games
  53. Users who own a gaming console
  54. Users who have created a Facebook event
  55. Users who have used Facebook Payments
  56. Users who have spent more than average on Facebook Payments
  57. Users who administer a Facebook page
  58. Users who have recently uploaded photos to Facebook
  59. Internet browser
  60. Email service
  61. Early/late adopters of technology
  62. Expats (divided by what country they are from originally)
  63. Users who belong to a credit union, national bank or regional bank
  64. Users who investor (divided by investment type)
  65. Number of credit lines
  66. Users who are active credit card users
  67. Credit card type
  68. Users who have a debit card
  69. Users who carry a balance on their credit card
  70. Users who listen to the radio
  71. Preference in TV shows
  72. Users who use a mobile device (divided by what brand they use)
  73. Internet connection type
  74. Users who recently acquired a smartphone or tablet
  75. Users who access the Internet through a smartphone or tablet
  76. Users who use coupons
  77. Types of clothing user’s household buys
  78. Time of year user’s household shops most
  79. Users who are “heavy” buyers of beer, wine or spirits
  80. Users who buy groceries (and what kinds)
  81. Users who buy beauty products
  82. Users who buy allergy medications, cough/cold medications, pain relief products, and over-the-counter meds
  83. Users who spend money on household products
  84. Users who spend money on products for kids or pets, and what kinds of pets
  85. Users whose household makes more purchases than is average
  86. Users who tend to shop online (or off)
  87. Types of restaurants user eats at
  88. Kinds of stores user shops at
  89. Users who are “receptive” to offers from companies offering online auto insurance, higher education or mortgages, and prepaid debit cards/satellite TV
  90. Length of time user has lived in house
  91. Users who are likely to move soon
  92. Users who are interested in the Olympics, fall football, cricket or Ramadan
  93. Users who travel frequently, for work or pleasure
  94. Users who commute to work
  95. Types of vacations user tends to go on
  96. Users who recently returned from a trip
  97. Users who recently used a travel app
  98. Users who participate in a timeshare

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 再重新生一把...

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.

前陣子在 Black Hat 上發表的 HEIST 攻擊 (對 HTTPS 的攻擊)

又是一個對 HTTPS 的攻擊：「HEIST attack on SSL/TLS can grab personal info, Black Hat」、「New attack steals SSNs, e-mail addresses, and more from HTTPS pages」。

一樣是 Compression 產生的 side-channel attack，只是這次是結合 TCP window size 的攻擊。投影片可以在「HTTP Encrypted Information can be Stolen through TCP-windows (PDF)」這邊看到。

這次的攻擊只需要在瀏覽器上插入 HTTP 產生 HTTPS 的流量，然後從旁邊看 HTTPS 連線的 TCP packet 就可以了，而且對 HTTP/2 也很有效：

而且很不幸的，目前沒有太好的解法，因為所有的攻擊手法都是照著使用者無法發現的路徑進行的 @_@

對於使用者，大量使用 HTTPS (像是 HTTPS Everywhere 這樣的套件)，能夠降低政府單位與 ISP 將 javascript 插入 HTTP 連線，產生 HTTPS 的行為。

而對於網站端來說，全站都隨機產生不同長度的 HTTP header 可能是個增加破解難度的方式 (而且不會太難做，可以透過 apache module 或是 nginx module 做到)，但還是可以被統計方法再推算出來。

不知道有沒有辦法只對 HTTPS 開 javascript，雖然攻擊者還是可以用 <img> 攻擊...

也許以後 HTTP/3 之類的協定會有一區是不壓縮只加密的，避開這類 compression-based attack @_@

Google 的 www.google.com 要上 HSTS 了

Google 宣佈 www.google.com 要上 HSTS 了：「Bringing HSTS to www.google.com」。

雖然都已經使用 EFF 的 HTTPS Everywhere 在跑確保 HTTPS，但這個進展還是很重要，可以讓一般使用者受到保護...

Google 的切換計畫是會逐步增加 HSTS 的 max-age，確保中間出問題時造成的衝擊。一開始只會設一天，然後會逐步增加，最後增加到一年：

In the immediate term, we’re focused on increasing the duration that the header is active (‘max-age’). We've initially set the header’s max-age to one day; the short duration helps mitigate the risk of any potential problems with this roll-out. By increasing the max-age, however, we reduce the likelihood that an initial request to www.google.com happens over HTTP. Over the next few months, we will ramp up the max-age of the header to at least one year.

Debian 提供 Tor Hidden Service 更新 Apt

Debian 與 Tor Project 都宣佈了這個消息，兩邊的稿子都一樣：「Debian and Tor Services available as Onion Services」、「Debian and Tor Services available as Onion Services」。

站台列表在 https://onion.debian.org/ 這邊可以看到，當你有安裝 apt-transport-tor 時，可以透過 Tor 更新：

deb tor+http://vwakviie2ienjx6t.onion/debian jessie main
deb tor+http://vwakviie2ienjx6t.onion/debian jessie-updates main
deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security jessie/updates main

Tor Hidden Service 本身就有一定的安全強度，而透過 APT 抓 Debian 套件的安全性還有 GnuPG 驗證把關，這樣看起來頗不賴...

讓 Tor 的流量變大也是讓 Tor 的隱私性變得更好的一種方法 (因為目前看到新的攻擊都是靠分析 traffic pattern，所以流量變大有機會讓雜訊變多一些)。

不知道 Ubuntu 有沒有機會也上一份...