Home » Posts tagged "attack" (Page 3)

透過手機螢幕上的餘熱猜測 PIN 碼

利用手機螢幕上的餘熱分析可能的 PIN 碼:「Heat traces left by fingers can reveal your smartphone PIN」,在輸入完 PIN 碼的 30 秒內的準確度都還是很高 (80%):

The report further revealed that if the thermal image is collected within 15 seconds of a PIN being entered, the technique is accurate almost 90% of the time. At 30 seconds, this accuracy decreased slightly to 80%. At 45 seconds or more, the accuracy dropped to 35% and below.

SWEET32:攻 Blowfish 與 3DES

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

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

這次順利打下 Blowfish3DES。這兩個 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

Bitcoin.org 對於接下來的 release 發出警告

Bitcoin.org 發出了有點摸不著頭緒的警告:「0.13.0 Binary Safety Warning」。

Bitcoin.org has reason to suspect that the binaries for the upcoming Bitcoin Core release will likely be targeted by state sponsored attackers. As a website, Bitcoin.org does not have the necessary technical resources to guarantee that we can defend ourselves from attackers of this calibre.

而且直接是點名可能是針對中國區的用戶:

We ask the Bitcoin community, and in particular the Chinese Bitcoin community to be extra vigilant when downloading binaries from our website.

由於 Bitcoin.org 全站走 HTTPS,這是在暗示會出現「不小心發出 Bitcoin.org 的 SSL certificate」的事情?另外官方也建議使用 PGP public key 驗證:

We strongly recommend that you download that key, which should have a fingerprint of 01EA5486DE18A882D4C2684590C8019E36C2E964. You should securely verify the signature and hashes before running any Bitcoin Core binaries. This is the safest and most secure way of being confident that the binaries you’re running are the same ones created by the Core Developers.

來拿板凳蹲著看,順便拉一張目前 certificate 看到的資訊,目前是從 RapidSSL SHA256 CA - G3 簽出來:

前陣子在 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 @_@

hashcat v3.00

hashcat 是個用暴力法拿來計算各種 reverse hash 的的工具,也就是對於 HASH(key) = value 時,給 value 的值,要求得出 key 的值 (被稱為 Preimage attack)。

雖然是暴力法,但還是花了很多力氣加速,尤其在這個 GPU 已經很常見的年代,這套軟體也支援透過 GPU 加速運算。

先前的版本是 CPU 與 GPU 分開兩個版本可以用 (CPU 版本的叫 hashcat,GPU 版本的叫做 oclHashcat),而 GPU 的版本只支援 nVidiaAMD 兩家大廠的顯卡。

而在 v3.00 版,透過 OpenCL 的界面將這些全部都合而為一了:「hashcat v3.00」,所以不只是支援 CPU 與 nVidia + AMD 的 GPU,還包括了:

  • GPU
  • CPU
  • APU
  • DSP
  • FPGA
  • Coprocessor
  • Anything else which comes with an OpenCL runtime

也特別提到,Intel CPU 上內建的 GPU 部份也可以拿來用了:

For example, Intel CPUs will now instantly pop up as an available OpenCL device after you've installed the Intel OpenCL runtime.

也因為透過 OpenCL,如果有多種不同類型的加速方式,新版 hashcat 也可以同時使用。

另外這次效能評估 (與舊版比較) 也做出來了:「hashcat 2.01 / 3.00 performance comparison」,可以看到比較新一點的卡整體都有進步,而舊的卡有可能是對 OpenCL 的最佳化或是 overhead 比較敏感,慢了不少...

OpenSSL 的 DSA 被 Side-channel attack 打爆

在「Make Sure DSA Signing Exponentiations Really are Constant-Time」這篇文章裡面,直接透過 end-to-end 的 timing attack 打爆 (也就是透過 internet 觀察攻擊),而不需要在同一台機器上對 cache 之類的區域攻擊:

A unique feature of our work is that we target common cryptographic protocols. Previous works that demonstrate cache-timing key-recovery attack only target the cryptographic primitives, ignoring potential cache noise from the protocol implementation. In contrast, we present end-to-end attacks on two common cryptographic protocols: SSH and TLS. We are, therefore, the first to demonstrate that cache-timing attacks are a threat not only when executing the cryptographic primitives but also in the presence of the cache activity of the whole protocol suite.

而且次數相當的少,就可以 key recovery:

260 SSH-2 handshakes to extract a 1024/160-bit DSA host key from an OpenSSH server, and 580 TLS 1.2 handshakes to extract a 2048/256-bit DSA key from an stunnel server.

CVE 編號為 CVE-2016-2178OpenSSL 全系列 (包括 fork 出去的版本) 與 OpenSSH 只要是 DSA 的實作都中獎...

關於 Juniper ScreenOS 防火牆被放後門的研究

一樣是從 Bruce Schneier 那邊看到的:「Details about Juniper's Firewall Backdoor」,原始的研究連結在「Cryptology ePrint Archive: Report 2016/376」這邊。

ScreenOS 被放了兩個後門,一個是 SSH 的後門:

Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker.

另外一個是「Dual EC 的 Q 值」被放了後門,而「NIST 所制定的 Dual EC 的 Q 值」本身就是個後門,所以有人把這個後門又給換掉了:

The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator's output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack.

第二個後門更發現嚴重的問題,Juniper 所宣稱的反制措施根本沒被執行到:

In this work, we report the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. Due to apparent flaws in the code, Juniper's countermeasures against a Dual EC attack are never executed.

也因此團隊確認選定 Q 值的人可以輕易的成功攻擊 IPSec 流量:

Moreover, by comparing sequential versions of ScreenOS, we identify a cluster of additional changes that were introduced concurrently with the inclusion of Dual EC in a single 2008 release. Taken as a whole, these changes render the ScreenOS system vulnerable to passive exploitation by an attacker who selects Q. We demonstrate this by installing our own parameters, and showing that it is possible to passively decrypt a single IKE handshake and its associated VPN traffic in isolation without observing any other network traffic.

密碼系統的 Monoculture

這篇文章講到最近密碼系統的現象:「On the Impending Crypto Monoculture」。

目前常在用的密碼系統包括了 RSA、DH、ECDH、ECDSA、SHA-2、AES 這些演算法,而最近這幾年大家在推廣使用的演算法都出自於同一個人手裡,Dan Bernstein,也就是 djb:

A major feature of these changes includes the dropping of traditional encryption algorithms and mechanisms like RSA, DH, ECDH/ECDSA, SHA-2, and AES, for a completely different set of mechanisms, including Curve25519 (designed by Dan Bernstein et al), EdDSA (Bernstein and colleagues), Poly1305 (Bernstein again) and ChaCha20 (by, you guessed it, Bernstein).

這些演算法或是定義,包括了 Curve25519、EdDSA、Poly1305、ChaCha20。而這篇文章試著說明造成這樣情況的背景以及原因,以及這樣會導致什麼問題。

當實際分析時會發現,檯面上沒幾個能用的演算法,而看起來能用的那幾個又有專利 (像是 OCB),不然就是看起來被 NSA 放了一些說明不了的參數 (像是 P-256 Curve)。

然後 djb 弄出來的演算法不只看起來乾淨許多,也直接用數學模型證明安全性。而且他的實作也很理論派,像是還蠻堅持要做到 constant time implementation 以避開各種 side channel attack。

就... 理論很強,又很實戰派的一個人啊,檯面上真的沒幾隻可以打的贏啊 XD

最新的 SSL connection 攻擊:DROWN attack

前幾天 OpenSSL 宣佈將在三月一日更新版本,包括了幾項層級被標示為 High 的問題:「[openssl-announce] Forthcoming OpenSSL releases」。

今天看到這個問題了,被稱為「The DROWN Attack」,全名為 Decrypting RSA with Obsolete and Weakened eNcryption,整個 internet 上大約 33% 的伺服器受到影響:

Our measurements indicate 33% of all HTTPS servers are vulnerable to the attack.

包括兩類,第一類是支援 SSLv2 的伺服器,約 17%:

It allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings. Our measurements show that 17% of HTTPS servers still allow SSLv2 connections.

第二類是指那些,雖然 server 不支援 SSLv2,但與第一類共用同一把 key,於是可以拿來攻擊,約 16%:

Its private key is used on any other server that allows SSLv2 connections, even for another protocol. Many companies reuse the same certificate and key on their web and email servers, for instance. In this case, if the email server supports SSLv2 and the web server does not, an attacker can take advantage of the email server to break TLS connections to the web server. When taking key reuse into account, an additional 16% of HTTPS servers are vulnerable, putting 33% of HTTPS servers at risk.

要注意的是這不只包括了 HTTPS,也包括了 POP3S 與 IMAPS,以及其他有用 SSLv2 的 server 都有受到影響。尤其是第二類會發生在小型伺服器上,mail server 與 web server 共用同一份 SSL certificate/key 的時候。

如果手上有使用 SSLv2 的 server,解法是關閉 SSLv2 (目前新的 SSL library 預設應該都是關閉),撤銷並重新申請 SSL certificate。

Linode 的被攻擊報告

Linode 這陣子一直被 DDoS 攻擊,前幾天放出報告:「The Twelve Days of Crisis – A Retrospective on Linode’s Holiday DDoS Attacks」。

其中這段提到了一些數字,Linode 有個小機房有 40Gbps 的能力,但以現在的 DDoS 規模會馬上爆掉:

Linode’s capacity management strategy for IP transit has been simple: when our peak daily utilization starts approaching 50% of our overall capacity, then it’s time to get more links.

This strategy is standard for carrier networks, but we now understand that it is inadequate for content networks like ours. To put some real numbers on this, our smaller datacenter networks have a total IP transit capacity of 40Gbps. This may seem like a lot of capacity to many of you, but in the context of an 80Gbps DDoS that can’t be blackholed, having only 20Gbps worth of headroom leaves us with crippling packet loss for the duration of the attack.

另外把 DNS 整個放上 CloudFlare 讓他們來擋:

Our nameservers are now protected by Cloudflare, and our websites are now protected by powerful commercial traffic scrubbing appliances.

後續的改善應該還要幾個月?完成後應該會再看到 blog post...

Archives