AWS System Manager 支援 SSH 的 -L 功能 (Port Forwarding)

AWS System Manager 宣佈支援了 SSH Port Forwarding 的功能 (也就是 OpenSSH 指令裡的 -L):「New – Port Forwarding Using AWS System Manager Sessions Manager」。

以往是連到那台主機上後,再透過 -R 反過來再穿一層,但這必須在那台機器有 Internet 存取權限的情況下才有辦法做... 這次的方法是 AWS System Manager 直接提供了,所以只需要可以連到主機就可以做。

Mac 上讓 SSH 走 Socks5 的方式


不過到 HiNet 看起來應該是有繞到美國之類的地區?

gslin@Gea-Suans-MacBook-Pro [~] [08:16/W4] mtr --report
Start: 2019-04-07T08:16:33+0700
HOST: Gea-Suans-MacBook-Pro.local Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|--                 0.0%    10    1.8   2.0   1.3   3.1   0.6
  2.|-- node-iyp.pool-101-108.dyn  0.0%    10    3.9   3.6   2.7   4.5   0.6
  3.|--              0.0%    10    3.2   4.1   3.2   8.3   1.5
  4.|--             0.0%    10    6.5   5.3   3.9   6.7   1.0
  5.|--             0.0%    10    5.4   4.8   4.0   7.2   1.0
  6.|--             0.0%    10    4.6   6.5   3.0  11.1   2.5
  7.|--                0.0%    10    3.9   4.4   3.1   5.6   0.8
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|--        0.0%    10  355.4 356.9 355.1 365.4   3.0
 10.|--        0.0%    10  215.6 216.6 214.2 225.4   3.4
 11.|--        0.0%    10  219.4 215.9 214.0 221.5   2.5
 12.|--        0.0%    10  218.9 217.2 215.0 218.9   1.4
 13.|--        0.0%    10  212.5 212.9 211.9 214.1   0.6
 14.|-- 210-59-204-229.hinet-ip.h  0.0%    10  213.5 212.7 212.0 213.7   0.6
 15.|--              0.0%    10  214.4 214.5 213.7 216.0   0.7

這樣有些影音服務只吃台灣 IP 就沒辦法用了,所以就得找方法來解決... 想法是透過我在 GCP 上開的機器繞回 HiNet,所以就得找 Mac 上 SSH 要怎麼設定 Socks5。

本來以為要用 tsocks 之類的工具 (i.e. 用 LD_PRELOAD 處理 connect()),但意外的在「SSH through a SOCKS Proxy? (client = OpenSSH OS X)」這邊看到可以用內建的 nc 處理,因為 nc 有支援 Socks5。

所以就變成兩包 ssh 指令:

ssh -D 1081 gcp.server
ssh -D 1080 -o "ProxyCommand nc -X 5 -x %h %p" hinet.server

然後 就是打通的版本了,可以讓瀏覽器直接掛上去使用。

至於後來想起來不需要用 Socks5,可以用 ssh -L 而笑出來又是另外一件事情了 :o

OpenSSH 完全移除 SSHv1 的程式碼

在「OpenSSH Removes SSHv1 Support」這邊看到 OpenSSH 拔掉 SSHv1 程式碼的消息。

In a series of commits starting here and ending with this one, Damien Miller completed the removal of all support for the now-historic SSHv1 protocol from OpenSSH.

在新的 distribution 裡引入新版 OpenSSH 時就不會有 SSHv1 的功能了...

GitHub 決定在 2018/02/01 停用不安全的 HTTPS/SSH 演算法

在「Discontinue support for weak cryptographic standards」這邊訂了日期,2018/02/01 將會關閉:

看起來最苦的應該是 Android 4.3 以及更早的版本,以現在的官方數字來看還有 13%+ (Dashboards),這些版本內建的瀏覽器不支援 TLSv1.2,不過另外裝 browser 就還能過...

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 的實作都中獎...

CVE-2015-7547:getaddrinfo() 的 RCE (Remote Code Execution) 慘案

Google 寫了一篇關於 CVE-2015-7547 的安全性問題:「CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow」。

Google 的工程師在找 OpenSSH 連到某台特定主機就會 segfault 的通靈過程中,發現問題不在 OpenSSH,而是在更底層的 glibc 導致 segfault:

Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting.

由於等級到了 glibc 這種每台 Linux 都有裝的情況,在不經意的情況下發生 segfault,表示在刻意攻擊的情況下可能會很糟糕,所以 Google 投入了人力研究,想知道這個漏洞到底可以做到什麼程度:

Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!

在研究過程中 Google 發現 Red Hat 的人也在研究同樣的問題:「(CVE-2015-7547) - In send_dg, the recvfrom function is NOT always using the buffer size of a newly created buffer (CVE-2015-7547)」:

In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn't immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”

攻擊本身需要繞過反制機制 (像是 ASLR),但仍然是可行的,Google 的人已經成功寫出 exploit code:

Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post.

技術細節在 Google 的文章裡也有提到,buffer 大小固定為 2048 bytes,但取得時有可能超過 2048 bytes,於是造成 buffer overflow:

glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query.

Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated.

另外 glibc 官方的 mailing list 上也有說明:「[PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow」。

OpenSSH client 的重大安全性更新

CVE-2016-0777 與 CVE-2016-0778 安全性漏洞是關於 OpenSSH client 的部分:(USN-2869-1: OpenSSH vulnerabilities)

It was discovered that the OpenSSH client experimental support for resuming connections contained multiple security issues. A malicious server could use this issue to leak client memory to the server, including private client user keys.

這下除了要更新以外,要重新生 ssh key 然後更新一堆機器了...

安全的 SSH (Secure Secure Shell)

Twitter 上看到「Secure Secure Shell」這篇文章,介紹要如何加強 OpenSSH

文章裡分成四個部份討論,從 Key exchange 開始,Authentication、Symmetric ciphers 以及 Message authentication codes。

先把已知有問題的技術都先拿掉 (像是 MD5RC4DES),然後有被 NSA 影響到的技術,而且有不錯的替代方案的也拿掉。

另外還介紹了 Tor hidden service 下的保護。


做 Ubuntu 14.04.1 的 VMware Template

公司有買 VMware license,但一直沒研究要如何做一份 VM template 出來,所以花了點時間研究到底怎麼做才會比較好。

這邊提供的方法是為了之後的通用性 (像是之後有可能用 KVM 堆虛擬機),所以不使用 VMware 獨規的設計,因此有些設定需要手動調整。

首先是先生出一台 Ubuntu 14.04.1 的 VM,在裝完基本系統後有些要先處理的:

  • 可以考慮用 DHCP 或是不開啟網路設定,反正不要設固定 IP address,以免同時裝多台機器時發生狀況。
  • 因為是 VMware 裡面,安裝 open-vm-tools 可以省下一些 puppet 安裝的時間。
  • 砍掉 /etc/ssh/ssh_host_*,每台機器的 host key 應該要不一樣。

做好 VM 後轉成 Template,之後每次在 deploy 完、開起來後,還要做這些事情:

  • /etc/hostname/etc/hosts 裡的機器名稱。
  • /etc/network/interfaces 裡的網路設定。
  • dpkg-reconfigure openssh-server 重新產生 SSH host key。