Home » Posts tagged "ssh" (Page 3)

OpenSSH 降低對 OpenSSL 的相依性

這陣子 OpenSSH 的人努力降低對 OpenSSL 的相依性,目前 (2014-04-29 18:01:49 GMT) 已經拔到把 OpenSSL 拔掉後仍然有數個演算法可用 (離可用還是有一段距離):

make compiling against OpenSSL optional (make OPENSSL=no);
reduces algorithms to curve25519, aes-ctr, chacha, ed25519;
allows us to explore further options; with and ok djm

Curve25519 用在 ECDH,而 AES-CTR 與 ChaCha20+Poly1305 用在對稱加密,Ed25519 用在非對稱加密,其中三個剛好是一整套 djb 大全集 XD

不過缺了 RSA 還是有點痛啊,看看會不會實做出來吧?

OpenSSH 安全性問題...

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 提供的修正吧...

掃整個 Internet 的 Port 22...

平常都是掃 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 的各版本的發行日期分別是:

  • 3.5:2002/10/14 (FreeBSD 4.11)
  • 4.3:2006/02/01
  • 4.7:2007/09/04
  • 5.1:2008/07/21
  • 5.3:2009/10/01
  • 5.4:2010/03/08 (FreeBSD 8.3)
  • 5.5:2010/04/16 (Debian 6)
  • 5.7:2011/01/24
  • 5.8:2011/02/04 (FreeBSD 9.1)
  • 5.9:2011/09/06
  • 6.0:2012/04/22 (Debian 7)
  • 6.1:2012/08/29 (FreeBSD 8.4)

後面的作業系統是就手上有的機器來看,不過 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

對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)

在「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-18 的機會可以解出原文。(CVE-2008-5161,論文是「Plaintext Recovery Attacks Against SSH」)

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)

OpenSSLGnuTLS 所實作的 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 看起來是個還不錯的方案...

把 PEM Private Key 檔轉成 SSH Public Key 格式...

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

把 SSH 換成 Mosh

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 後設計出這些特性:

  • 筆電休眠後再打開電腦就可以直接連上。
  • 登入 VPN 造成 IP 改變後也沒關係。

另外 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 全面支援 64bits,並補上產品線...

之前用 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 這次提供新功能包括:

  • 推出新的 instance 種類 m1.medium,收費是 m1.small 的兩倍,所以規格大致上也是 m1.small 的兩倍,其中記憶體是 3.5GB RAM。
  • m1.small 與 m1.medium 除了可以跑 32bits 以外,也可以跑 64bits。

於是本來的問題可以用不同方向解決:

  • 本來做的 32bits image 當 m1.small 不夠用時也可以先拿 m1.medium 擋著。
  • 既然所有 EC2 instances 都可以跑 64bits,以後只要做 64bits image 就好了。
  • 同樣的,現在用 m1.large 嫌太大台的可以降到 m1.medium 或是 m1.small。

另外這次提供 Java SSH client,可以讓你直接在 Web Console 上面一貫作業,這個就比較用不到了...

GitHub 要求全面檢查 SSH Key

GitHub 被攻擊成功後 (參考 GitHub 官方所說的「Public Key Security Vulnerability and Mitigation」這篇),官方除了把漏洞修補完以外,接下來做了更積極的措施:暫停所有的 SSH key 存取權限,一律等到用戶 audit 確認過後才開放:「SSH Key Audit」。

這次 GitHub 除了修正問題、audit key 以外,另外還提出了新的機制讓用戶更容易發現異常存取行為,包括了:

  • 新增 SSH public key 時要輸入密碼。
  • 新增 SSH public key 成功後會寄信通知。
  • 新增「Security History」頁面可以看到帳戶的安全狀況。

算是很積極補救的作法。

另外說明,要如何 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 出 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 了...

Archives