讓我意外的是,只有 FreeBSD 10.0-BETA (還沒出 RELEASE 的版本) 有問題,9.2-RELEASE 並不在內:「OpenSSH AES-GCM memory corruption vulnerability」。
本來 9.2 的機器有上 workaround 把 AES-GCM 強制拔掉,看起來可以 revert 回來了...
幹壞事是進步最大的原動力
讓我意外的是,只有 FreeBSD 10.0-BETA (還沒出 RELEASE 的版本) 有問題,9.2-RELEASE 並不在內:「OpenSSH AES-GCM memory corruption vulnerability」。
本來 9.2 的機器有上 workaround 把 AES-GCM 強制拔掉,看起來可以 revert 回來了...
Twitter 上看到 Gasol 轉推的 OpenSSH 安全性問題:「OpenSSH Security Advisory: gcmrekey.adv」。
開頭就直接寫:
If exploited, this vulnerability might permit code execution with the privileges of the authenticated user and may therefore allow bypassing restricted shell/command configurations.
這噴飯了... OpenSSH 的安全性相當強,這次出這種包... XDDD
影響的範圍是 OpenSSH 6.2 與 6.3,並且 OpenSSL 有編 AES-GCM:
OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL that supports AES-GCM.
如果不允許升級到 OpenSSH 6.4,那麼暫時性的解法是不允許 AES-GCM,在 /etc/ssh/sshd_config
內可以設:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc
結果 FreeBSD 9.2 看起來在範圍內中槍,先上 workaround 再來等 freebsd-update 提供的修正吧...
平常都是掃 Port 80/443,然後就有人跑去掃 Port 22:「We scanned the Internet for port 22」。依照原文說的,這次給的數據只是 60% 的 Internet,其他 40% 的資料有問題,他要再想辦法修...
這是 Top 20 的 unique banner 數據:
1730887 SSH-2.0-OpenSSH_4.3 1562709 SSH-2.0-OpenSSH_5.3 1067097 SSH-2.0-dropbear_0.46 824377 SSH-2.0-dropbear_0.51 483318 SSH-2.0-dropbear_0.52 348878 SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1 327841 SSH-1.99-Cisco-1.25 320539 SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze3 318279 SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1 307028 SSH-2.0-ROSSSH 271614 SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze2 233842 SSH-2.0-OpenSSH_5.1p1 Debian-5 225095 SSH-2.0-OpenSSH_5.1 224991 SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901 213201 SSH-2.0-OpenSSH_4.7 209023 SSH-2.0-OpenSSH_6.0p1 Debian-4 195977 SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7 140809 SSH-2.0-dropbear_0.50 135821 SSH-2.0-OpenSSH 132351 SSH-2.0-Cisco-1.25
可以看到 OpenSSH 是最大宗,而 dropbear 應該是各種 box 的量撐起來的...
參考維基百科上 OpenSSH 的條目,OpenSSH 的各版本的發行日期分別是:
後面的作業系統是就手上有的機器來看,不過 4.3 是最多的是怎麼一回事呢... 作者這樣解釋:
Note that these counts are a bit off. Some networks have a router that forwards all connections of a certain port to a single machine. Maybe "OpenSSH_4.3" is most popular banner, or maybe the national ISP of Elbonia just reroutes all port 22 requests.
所以有可能只是個假象?XD
在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史,其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章:「Encrypt-then-MAC」,當時 Colin Percival 寫的時候大家還是不能理解,但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD
SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題:對 128bits CBC mode system (像是 aes128-cbc),任意位置的 32bits 有 2
TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠,不過到了 2011 年時才被拿出來示範,也就是 BEAST attack。(CVE-2011-3389,在 ekoparty Security Conference 上的「表演」:「BEAST: Surprising crypto attack against HTTPS」,連結1、連結2)
OpenSSL 與 GnuTLS 所實作的 DTLS 在 2011 年也被炸到,其中 OpenSSL 是 100% plaintext recovery,GnuTLS 是 4%。(CVE-2012-0390,論文是「Plaintext-Recovery Attacks Against Datagram TLS」)
而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法,而且被證明 Provable security:Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。
附帶一提,其中 Provable security 這個詞,並非表示「可被證明是安全的」,在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低:以 Encrypt-then-MAC 的例子來說,如果 Encrypt 的部份用 DES,或是 MAC 用 CRC32,那麼 Encrypt-then-MAC 並不會提供更強的安全性...
總而言之,MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode),而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式,有些有專利問題,有些演算法看起來就很複雜 (於是就容易出包),其中 Encrypt-then-MAC 看起來是個還不錯的方案...
在 RSA 中,單獨靠 Private Key 是無法算出 Public Key 的,不過在 PEM 檔裡因為都有紀錄,所以可以取出:
openssl rsa -in aws.pem -pubout
不過取出的格式需要再轉一次讓 OpenSSH 可以吃:(參考「Convert pem key to ssh-rsa format」這篇的方法)
ssh-keygen -f aws.pub -i -m PKCS8
雖然 ssh-keygen
不接受 -
當 stdin,但可以利用 /dev/stdin
直接串起來:
openssl rsa -in aws.pem -pubout | ssh-keygen -f /dev/stdin -i -m PKCS8
Mosh 是一個取代 SSH (OpenSSH) 的工具,官方網站上是這樣介紹:
Mosh is a replacement for SSH. It's more robust and responsive, especially over Wi-Fi, cellular, and long-distance links.
Mosh 最大的特性是透過 UDP 加密傳輸 (AES-128 OCB mode),而且不綁定 IP address 後設計出這些特性:
另外 Mosh 模擬了 local echo 機制,就算在 latency 偏高的網路下也還是可以感覺到不錯的反應速度。
不過是到了 1.2 之後支援 --ssh
這個參數才變得好用,在 client 端只要這樣跑 (假設 ssh port 在 1234):
mosh --ssh="ssh -p 1234 -v" gslin@server.example.com --server="env LANG=en_US.UTF-8 mosh-server"
Mosh 就會用 ssh 登入後自動執行 mosh-server 取得 shared key 給 mosh-client 用。如果本來就有使用 public key 機制的話就跟原來沒差了 :p
預設吃 port 60000-61000 其中的一個 UDP port,所以記得開 firewall...
之前用 AWS EC2 的人常遇到的狀況是,t1.micro 記憶體太小會常常 out of memory (用 EBS 硬撐當 swap 效能不好),但 m1.small 只能跑 32bits,為他做完整的 32bits image 維護成本實在不划算,因為等到之後變大後又得改做一份 64bits 的 image,如果從 t1.micro 改用 m1.large 又嫌太大台...
現在這個問題總算是解決了:「Announcing three new Amazon EC2 features」,EC2 這次提供新功能包括:
於是本來的問題可以用不同方向解決:
另外這次提供 Java SSH client,可以讓你直接在 Web Console 上面一貫作業,這個就比較用不到了...
在 GitHub 被攻擊成功後 (參考 GitHub 官方所說的「Public Key Security Vulnerability and Mitigation」這篇),官方除了把漏洞修補完以外,接下來做了更積極的措施:暫停所有的 SSH key 存取權限,一律等到用戶 audit 確認過後才開放:「SSH Key Audit」。
這次 GitHub 除了修正問題、audit key 以外,另外還提出了新的機制讓用戶更容易發現異常存取行為,包括了:
算是很積極補救的作法。
另外說明,要如何 audit key,也就是要如何取得你的 public key fingerprint:
ssh-keygen -lf .ssh/id_rsa.pub
(如果你是用 RSA)
或是
ssh-keygen -lf .ssh/id_dsa.pub
(如果你是用 DSA)
出現的訊息就是你要比對的值。記住!既然是 audit,請一個一個比對確認 fingerprint 全部都正確。
附上原始信件:(好像還沒在 blog 上說明)
A security vulnerability was recently discovered that made it possible for an attacker to add new SSH keys to arbitrary GitHub user accounts. This would have provided an attacker with clone/pull access to repositories with read permissions, and clone/pull/push access to repositories with write permissions. As of 5:53 PM UTC on Sunday, March 4th the vulnerability no longer exists.
While no known malicious activity has been reported, we are taking additional precautions by forcing an audit of all existing SSH keys.
# Required Action
Since you have one or more SSH keys associated with your GitHub account you must visit https://github.com/settings/ssh/audit to approve each valid SSH key.
Until you have approved your SSH keys, you will be unable to clone/pull/push your repositories over SSH.
# Status
We take security seriously and recognize this never should have happened. In addition to a full code audit, we have taken the following measures to enhance the security of your account:
- We are forcing an audit of all existing SSH keys
- Adding a new SSH key will now prompt for your password
- We will now email you any time a new SSH key is added to your account
- You now have access to a log of account changes in your Account Settings page
Sincerely, The GitHub Team--- https://github.com support@github.com
昨天看到 PuTTY 出 0.61 了:「PuTTY version 0.61 is released」,相隔四年多的另外一個新版。
看 New features 裡面,我看到一點還蠻有趣的:
On Windows: the Appearance panel now includes a checkbox to allow the selection of non-fixed-width fonts, which PuTTY will coerce into a fixed-width grid in its terminal emulation. In particular, this allows you to use GNU Unifont and Fixedsys Excelsior. (Thanks to Randall Munroe for a serious suggestion that inspired this.)
這代表可以用各種奇怪的字體嗎?主力系統換成 Ubuntu 後就沒用 PuTTY 了...
今天 AWS EC2 一口氣丟出一堆小功能:
其實這些功能都沒什麼大不了的,Idempotent Instance Creation 可以避免重複產生 instance,而 Resource Tagging 暫時想不到用途,Filtering 則是 describe 的功能加強...
對現在最有幫助的是第四個,ssh
時可以不用指定 -i .ssh/ooxx.pem
算是有直接影響的吧?目前還不能透過 Web Console 匯入,必須用 ec2-import-keypair 指令匯入。