Home » Posts tagged "attack" (Page 5)

Bitcoin 有單一團體超過 50% 計算能力了...

Bitcoin 的安全性是利用「當整個社群夠大時,不會有單一團體擁有超過 50% 的計算能力」的假設上發展演算法及防護機制:(參考「Weaknesses - Bitcoin」)

An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:

  • Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
  • Prevent some or all transactions from gaining any confirmations
  • Prevent some or all other miners from mining any valid blocks

不過讓人噴飯的消息出來了,即使在 Bitcoin 這麼火熱的情況下,仍然有單一團體計算能力已經超過 50%:「Largest Bitcoin Mining Pool Pledges Not To Execute '51% Attack'」。

這應該是當設計時始料未及的... XD

在 HTML 內嵌 JSON object 時要注意的事情...

有時候我們會因為效能問題,在 HTML 內嵌入 JSON object,而不是再多一個 HTTP request 取得。

但「嵌入」的行為如果沒有處理好,就產生非常多 XSS attack vector 可以玩。

首先最常犯的錯誤是使用錯誤的 escape function:

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = "<?= addslashes($str) ?>";
</script>
</body>
</html>

這樣可以用 </script><script>alert(1);// 攻擊 $str。因為 addslashes() 並不會過濾到這個字串,而產生這樣的 HTML:

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = "</script><script>alert(1);//";
</script>
</body>
</html>

而這個字串會造成 DOM parser 解讀上產生不是我們預期的行為:

可以看到在字串裡面的 </script> 被拆開了。

這是因為瀏覽器會先拆解產生 DOM tree,再把 <script></script> 內的程式碼交給 JavaScript engine 處理。所以在一開始產生 DOM tree 的時候,是看不懂 JavaScript 程式邏輯的...

正確的方法是用 json_encode() 處理,因為 PHPjson_encode() 預設會把 / (slash) 變成 \/ (這是 JSON spec 裡合法的轉換):

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = <?= json_encode($str) ?>;
</script>
</body>
</html>

這會產生出:

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = "<\/script><script>alert(1);//";
</script>
</body>
</html>

但上面這段 HTML 與 PHP code 仍然有問題,如果 $str<!--<script 時,你會發現 DOM 又爛掉了:

<!DOCTYPE HTML>
<html>
<body>
<script>
var a = "<!--<script>";
</script>
</body>
</html>

escape.alf.nu 的 Level 15 就是利用這個問題,再加上其他的漏洞而完成 XSS 攻擊。

為了這個問題去 StackOverflow 上問:「Why does <!--<script> cause a DOM tree break on the browser?」,才又發現上面這段 code 並不是合法的 HTML5 (先不管 head & title 的部份,補上後仍然不是合法的 HTML5)。

原因在於 DOM parser 對 <script></script> 的特殊處理:「4.3.1.2 Restrictions for contents of script elements」。(話說這段 ABNF 差點讓我翻桌...)

解法是在 <script></script> 的開頭與結尾加上 HTML 註解:(這剛好是 HTML 4.01 建議的方法)

<!DOCTYPE HTML>
<html>
<body>
<script>
<!--
var a = "<!--<script>";
-->
</script>
</body>
</html>

那段 ABNF 的目的是希望可以盡可能往後找到 --></script> 結尾的地方。

當然你也可以用 json_encode()JSON_HEX_TAG<> 硬轉成 \u003c\u003e 避開這個問題,但這使得呼叫 json_encode() 時要多一個參數 (而非預設參數),用起來比較卡...

這個問題會變得這麼討厭,是因為 DOM parser 與 JavaScript 語法之間有各自的處理方式,然後又有些 pattern 是之前的 spec 遺留下來的包袱 (像是 HTML 4.01 在「18.3.2 Hiding script data from user agents」裡有提到用 <!----> 包裝 <script></script>),變成在設計 HTML5 時都要考慮進去相容...

之前會習慣用 <!--//--> 包裝 <script></script> 倒不是這個原因,而是因為不這樣做的話,jQuery 在 IE 使用 html() 時遇到有 <script></script> 的字串會爛掉,所以後來寫的時候變成習慣了...

反而因為這個習慣而避開了這個問題...

超難搞啊...

利用機器噪音的 Side-channel attack,解 GnuPG 的 RSA key...

Daniel GenkinAdi ShamirEran Tromer 發表的論文:「RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis」。

在維基百科上有「Acoustic cryptanalysis」的條目,不過好像還沒補上這次的事情...

2004 年的 Eurocrypt 時,後面兩位就已經發表過「Acoustic cryptanalysis - On nosy people and noisy machines」,可以針對機器的噪音取得「部份資訊」:

這次攻擊者利用「麥克風」可以對機器的聲音攻擊 (side-channel attack),進而「得到完整的 private key」:

左邊那台機器... 好像是隻手機啊... @_@

收音的設備愈好,效果愈好:

這次直接把 GnuPG 打趴真是太過分了... (被 assign 了 CVE-2013-4576)

Adi Shamir 老人家還是很活躍啊...

法國政府 ANSSI 偽造 Google 的 SSL 憑證被抓到...

GoogleGoogle Chrome 裡面有放一段 SSL 白名單 (transport_security_state_static.json),針對某些特定 domain 只允許特定的 CA 所發出來的 SSL 憑證,另外當發現異常時也會回報。

這個機制可以保證在白名單內的網域比較不容易被 CA 搞到。

前幾天 Google 偵測到法國政府 ANSSI 的一個中介憑證發行單位 (Intermediate certificate authorities) 發出 Google 所擁有網域的 SSL 憑證:「Further improving digital certificate security」。

這也是繼一年前 TURKTRUST 發出的 *.google.com 以來再次被這個機制抓到的案例:「這次 TURKTRUST 誤發 *.google.com SSL 憑證...」。

同時,這也是首次政府機關相關的 CA 搞 MITMA (Man-in-the-middle attack)。

ANSSI 官方的說法是「誤發」:「Revocation of an IGC/A branch」,不過可信度... XD

Google 後來在 12/12 再次更新公告文章,決定把 ANSSI 的 CA 信任範圍限縮到法國相關的網域,共 13 個。(*.fr*.gp*.gf、...)

另外可以參考 Mozilla 在收到 Google 通知後的公告:「Revoking Trust in one ANSSI Certificate」。

NTP server 放大攻擊的防治...

一樣是在 Zite 上看到的,有人提到對 NTP server 的放大攻擊:「Re: Public ntp-server and reflection-attacks」。

攻擊者送一個封包,就會產生約 100 個封包的回應... (於是就被放大了)

This means, the attacker sends _one_ packet and gets _100_ packets to his target.

像是這樣的指令就會傳回很多資訊:(剛好也學到 ntpdc 這個指令...)

gslin@colo-p [~] [04:18/W4] ntpdc -c monlist
remote address          port local address      count m ver code avgint  lstint
===============================================================================
localhost              36284 ::1               443425 7 2      0     27       0
sun.stu.edu.tw           123 112.121.80.241      7891 4 4      0   1027     197
clock.stdtime.gov.tw     123 112.121.80.241      7821 4 4      0   1024     838
59-124-196-84.HINET-IP   123 112.121.80.241      7856 4 4      0   1024     920

在信件裡,建議的修正方式是:

restrict default noquery nomodify notrap nopeer
restrict -6 default noquery nomodify notrap nopeer

新的 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.

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

SSL/TLS 的問題...

這篇與「對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)」這篇相關,建議可以一起看一看。

TLS (Transport Layer Security),前身是 SSL (Secure Sockets Layer),是目前 HTTPS 所使用的加密協議。發展的順序上是 SSLv2、SSLv3、TLSv1、TLSv1.1、TLSv1.2。

然後有兩篇文章可以看:

第一篇文章講 Padding oracle attack,第二篇文章是酸 SSL/TLS 的修正愈修愈歪... XD

AES 這類的 block cipher 在加密或解密時會要求切齊 block size,以 AES 的要求就是 128bits (16 bytes)。

而對於不齊的資料要怎麼加密呢?其中一個方法是 PKCS#7:(圖片取自第二篇文章)

Padding

要想辦法補齊 128bits (16bytes),如果像上圖需要補 7bytes 進去,就都補上 \x07 (剛好就是補上長度),另外在最後面會補上 padding 的長度,而問題出就出在這個設計先天就有缺陷:在 SSL/TLS 所使用的 MAC-then-Encrypt 中,MAC 只計算原文的值,沒有保護到 padding 的部份,於是就可以針對 padding 的部份想辦法找到洞鑽。

pseudo code 可能是這樣:

// Decrypt to plaintext + mac + padding
$plaintext_mac_padding = decrypt($ciphertext);
if (NULL != $plaintext_mac_padding) {

    // Now decode padding part
    $plaintext_mac = decode_padding($plaintext_mac_padding, $padding_length);
    if (NULL != $plaintext_mac) {

        // Now check MAC part
        $plaintext = check_mac(plaintext_mac);
        if (NULL != $plaintext) {

            // Now it's okay
        }
    }
}

攻擊者亂改 $ciphertext 會導致解出來的 padding 也亂掉,但早期的 SSL 會回傳「padding error」這種對攻擊者有利的資訊,而導致攻擊者可以利用這個資訊想辦法得知更多內容。

而 TLS 並沒有從根本改善,而是試著加上機制補西牆:當遇到錯誤時就跳過,不要傳回錯誤資訊。

但因為攻擊者亂改封包造成 decode_padding() 會失敗,而沒有呼叫到 check_mac()。這導致了大量的計算時間差與能量差,而使得攻擊者可以藉由這些資訊而得知是否成功。而官方在 TLSv1.2 的建議是再補上機制來補洞:

In general, the best way to do this is to compute the MAC even if the padding is incorrect, and only then reject the packet. For instance, if the pad appears to be incorrect, the implementation might assume a zero-length pad and then compute the MAC.

而官方認為雖然這樣還是有 timing channel,但已經小到會被雜訊覆蓋,所以「應該」可以解決問題:

This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.

於是,只要覺得「應該安全吧」,就會「應該會被破」:「Lucky Thirteen: Breaking the TLS and DTLS Record Protocols」:

The attacks apply to all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. They also apply to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to previous padding oracle attacks. Variant attacks may also apply to non-compliant implementations.

這 SSL/TLS 的設計讓人補到快起笑了... XD

資安的東西通常是愈複雜就愈容易被抓問題出來,在 SSL/TLS 的歷史包袱下,不知道什麼時候才想換 Encrypt-then-MAC 來改善底層問題...

虛擬機內的 Side-channel attack...

前陣子在其他地方看到,不過剛剛在「Stealing VM Keys from the Hardware Cache」看到利用 Side-channel attack 的攻擊:「Cross-VM Side Channels and Their Use to Extract Private Keys」。

實際攻擊的項目是 libgcrypt 實做的 ElGamal 演算法,長度是 4096bits。環境是 Xen,限制是在同一台實體機器上。

對抗 side-channel attack 的幾個方法:實體隔離 (效果最好) 或是改善演算法 (通常是犧牲一些演算法效率,換取難以被外部預測的保護)。前者也就是 AWS 為了符合美國政府要求所建立 AWS GovCloud (US) 的原因之一。

Archives