APT (Advanced Persistent Threat)

維基百科對 APT (Advanced Persistent Threat) 的定義是:

Advanced Persistent Threat (APT) APT is a set of stealthy and continuous computer hacking processes, often orchestrated by human(s) targeting a specific entity.

針對特定個人或團體進行攻擊,這邊的 entity 通常是指有權限存取系統,或是手上握有機敏資料的人,這些人的帳號密碼,或是系統權限是有價值的。

這幾年因為行動裝置普及,再加上行動裝置上驗證起來會比較麻煩,成為 APT 攻擊的首選。

下面就原文照登:

微軟的 IE6+ 安全性更新

即使 Windows XP 在上個月就已經停止安全性更新,但這次的 CVE-2014-1776 影響層面還是太廣,微軟還是提供 Windows XP 用戶相關的 patch (透過 Windows Update 發送):

Use-after-free vulnerability in VGX.DLL in Microsoft Internet Explorer 6 through 11 allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption) via unspecified vectors, as exploited in the wild in April 2014.

在「Security Update Released to Address Recent Internet Explorer Vulnerability」也可以看到說明。

看到 use-after-free 這個詞就想到 OpenSSL 前陣子也來一發 CVE-2010-5298 (居然是 2010 年的 CVE),讓人... 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

RAID 卡的電池維護

實際的世界都是由 workaround 疊 workaround 解決問題的...

MySQL 資料庫一般都用 RAID 10,利用 RAID 1 的特性保護資料,並且利用 RAID 0 的特性提昇 IOPS 能力。

而這些 RAID 卡通常都會提供 cache,預設應該都會開 read cache,可以大幅增加 random read 的速度。而另外也可以打開 write cache (也就是 write-back),寫入時先寫到 cache 裡,RAID 卡馬上就會跟作業系統回報完成,藉以加速 random write 的速度。

但這樣就會有風險,當資料還沒寫入硬碟就斷電時就會遺失資料。所以在設定 write-back 的 RAID 卡上安裝電池就變成解法之一。

而電池會有壽命問題,所以配電池的 RAID 卡會每隔一陣子就放電測試電池可以撐多久,但在放電測試時,如果斷電就有可能造成資料遺失,於是又冒出很多方法解決。

也就是在「Learning to Deal With Learning」這篇提到 RAID 卡電池維護的事情。

每一層都是 workaround 想辦法解決問題,然後再用 workaround 解決前面造成的問題...

Anyway,有幾種解法,其中仍然對上層作業系統與應用程式透明的解法是:

  • 雙電池架構,很明顯的可以一次只測一顆。
  • 改用 NVRAM,就不需要電池了,不過速度以及成本會是另外一個問題。

另外,對上層作業系統與應用程式有影響的方式:

  • 放電測試時將 write cache 關閉,切回 write-through。這點在原文裡也有提到,效能其實會受到蠻大的影響。
  • 不放電測試了,但這樣的缺點就是拿安全性交換,當斷電時不知道能不撐過去。
  • 或是自己控制放電測試的時間,這可以配合上面切回 write-through 的方式,挑負載比較輕的離峰時間做。

看了下來雙電池架構還不錯,增加的成本還算可以接受,而且因為效能不受到影響,也確保資料安全性,整體維護起來比較簡單。而之後在規模更大的時候,應該就會直接考慮跳到自己放電測試的方式來處理電池問題...

檢查大小時要注意的問題

Buggy Security Guidance from Apple」這篇再次說明了 C 語言因為 undefined behavior 而讓 coding 需要注意的事情變多...

這段 code:

size_t bytes = n * m;
if (n > 0 && m > 0 && SIZE_MAX/n >= m) {
    ... /* allocate "bytes" space */
}

問題在於 C 語言裡對 overflow 並沒有定義行為 (undefined behavior),所以 size_t bytes = n * m; 這段 code 並不保證當 overflow 後 bytes 的值會是多少,於是就很容易造成各種意外。

原文有提到更多資訊,以及提出的解法,這邊就不提了...

OpenBSD 的 OpenSSL 清理工作

在「One week of OpenSSL cleanup」這篇提到了 OpenBSD 的 committer 最近花了不少時間在清理 OpenSSL (OpenBSD 內的 OpenSSL)。

All combined, there've been over 250 commits cleaning up OpenSSL. In one week.

清理的過程主要是針對 OpenBSD 所支援的平台,所以其他平台的支援都被拔乾淨了。即使如此,清過後的版本重新 porting 到各 Unux-like 平台應該是還蠻有希望的。

BSD Commit Log Search 這邊則可以搜尋到 OpenSSL 被清的情況:「http://freshbsd.org/search?project=openbsd&q=libssl」。

花些時間翻一翻,會可以看到 OpenSSL 很多習慣並不好 (尤其是在資安領域)。

像是 OpenSSL 預設居然沒有把所有的 code 都上 -Wall,這點讓人有點... 呃... 要怎麼說呢...:「58c7f6cb678b7e31b80d290b5823b16d70760801」。

然後看到大量的 potential double free fix,呃...

繼續看下去吧,看起來 OpenBSD 這一波 cleanup 應該會再爆出一些安全問題 (多冒出幾個 CVE 出來)。

AWS 上資安產品試用...

前幾天 AWS 公佈了「Evaluate Security Products With no Software Charges by Using AWS Marketplace」,在 5/15 前有六個資安產品可以試用 120 小時。

有 WAF、Firewall,也有 UTM,另外還有 data encryption 的方案。找機會來測試看看好了,不知道是擋在哪一層...

使用 SSL 連上 Freenode IRC server

ijliao 長輩的 blog 上看到「weechat」這篇才想起來 Freenode 有提供 SSL 連線。

可以在「About freenode: IRC Servers」這頁看到 SSL port 的連線資訊:

All freenode servers listen on ports 6665, 6666, 6667, 6697 (SSL only), 7000 (SSL only), 7070 (SSL only), 8000, 8001 and 8002.

其中 port 6698/7000/7070 是 SSL only,所以就拿這幾個用。由於我是在 Ubuntu 上跑 ppa 版的 WeeChat,所以基本上只加上這三行就可以了:

/set irc.server.freenode.address chat.freenode.net/6697
/set irc.server.freenode.ssl on
/set irc.server.freenode.ssl_dhkey_size 1024

連上後應該會看到類似的訊息:

gnutls: connected using 1024-bit Diffie-Hellman shared secret exchange
gnutls: receiving 2 certificates
 - certificate[1] info:
   - subject `OU=Domain Control Validated,OU=Gandi Standard Wildcard SSL,CN=*.freenode.net', issuer `C=FR,O=GANDI SAS,CN=Gandi Standard SSL CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2014-01-13 00:00:00 UTC', expires `2015-01-14 23:59:59 UTC', SHA-1 fingerprint `2df8bb8922e69f781ef5abcd234fffde0490be21'
 - certificate[2] info:
   - subject `C=FR,O=GANDI SAS,CN=Gandi Standard SSL CA', issuer `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', RSA key 2048 bits, signed using RSA-SHA1, activated `2008-10-23 00:00:00 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `a9f79883a075ce82d20d274d1368e876140d33b3'
gnutls: peer's certificate is trusted

然後在 status line 裡,server[freenode] 的部份變成綠色的。

用 XML External Entity 取得 Google 伺服器內的資料

前幾天有人成功利用 XML External Entity 安全問題,取得 Google 伺服器內的資料:「How we got read access on Google’s production servers」。

可以看到上圖是 /etc/passwd 的內容...

XML Parser 預設有太多功能是根本不會想要用到的,沒有注意到而忘記關掉就會中獎...

OpenSSL 的 Heartbleed 漏洞不限於 Server,也包含 Client...

Heartbleed 是惡意的 client 可以利用 OpenSSLHeartbeat Extension 漏洞取得 server 的機敏資訊。

而在「Testing for "reverse" Heartbleed」這篇說明 (並且 PoC) 這組漏洞也適用於反向的操作,也就是惡意的 server 可以取得 client 的資訊。

exploit 相較起來比正向的難一些,但還是可行並且成功做出來了。文章裡有描述怎麼實做的...

換句話說,反正手上的 OpenSSL 都趕快升級...