關於 Juniper ScreenOS 防火牆被放後門的研究

一樣是從 Bruce Schneier 那邊看到的:「Details about Juniper's Firewall Backdoor」,原始的研究連結在「Cryptology ePrint Archive: Report 2016/376」這邊。

ScreenOS 被放了兩個後門,一個是 SSH 的後門:

Reverse engineering of ScreenOS binaries revealed that the first of these vulnerabilities was a conventional back door in the SSH password checker.

另外一個是「Dual EC 的 Q 值」被放了後門,而「NIST 所制定的 Dual EC 的 Q 值」本身就是個後門,所以有人把這個後門又給換掉了:

The second is far more intriguing: a change to the Q parameter used by the Dual EC pseudorandom number generator. It is widely known that Dual EC has the unfortunate property that an attacker with the ability to choose Q can, from a small sample of the generator's output, predict all future outputs. In a 2013 public statement, Juniper noted the use of Dual EC but claimed that ScreenOS included countermeasures that neutralized this form of attack.

第二個後門更發現嚴重的問題,Juniper 所宣稱的反制措施根本沒被執行到:

In this work, we report the results of a thorough independent analysis of the ScreenOS randomness subsystem, as well as its interaction with the IKE VPN key establishment protocol. Due to apparent flaws in the code, Juniper's countermeasures against a Dual EC attack are never executed.

也因此團隊確認選定 Q 值的人可以輕易的成功攻擊 IPSec 流量:

Moreover, by comparing sequential versions of ScreenOS, we identify a cluster of additional changes that were introduced concurrently with the inclusion of Dual EC in a single 2008 release. Taken as a whole, these changes render the ScreenOS system vulnerable to passive exploitation by an attacker who selects Q. We demonstrate this by installing our own parameters, and showing that it is possible to passively decrypt a single IKE handshake and its associated VPN traffic in isolation without observing any other network traffic.

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 然後更新一堆機器了...

在攻擊時總是挑最弱的一環:NSA 對 DH 的攻擊

在「How is NSA breaking so much crypto?」這邊提到了 2012 年有文章說明 NSA 有能力解開部份的加密通訊,而後來 Snowden 所提供的資料也證實了這點:

In 2012, James Bamford published an article quoting anonymous former NSA officials stating that the agency had achieved a “computing breakthrough” that gave them “the ability to crack current public encryption.” The Snowden documents also hint at some extraordinary capabilities: they show that NSA has built extensive infrastructure to intercept and decrypt VPN traffic and suggest that the agency can decrypt at least some HTTPS and SSH connections on demand.

但在這之前一直都不清楚是怎麼解出來的,直到最近才猜測應該是 Diffie-Hellman 的強度以及實作問題:「Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice」。


We go on to consider Diffie-Hellman with 768- and 1024-bit groups. We estimate that even in the 1024-bit case, the computations are plausible given nation-state resources. A small number of fixed or standardized groups are used by millions of servers; performing precomputation for a single 1024-bit group would allow passive eavesdropping on 18% of popular HTTPS sites, and a second group would allow decryption of traffic to 66% of IPsec VPNs and 26% of SSH servers. A close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break. We conclude that moving to stronger key exchange methods should be a priority for the Internet community.

作者群給的建議有三個方向,一個是把長度加長到 2048 bits,另外一個是改用 ECDH,而最差的情況 (如果還是需要使用 1024 bits DH) 則是避免使用固定的 prime number。

對 GitHub 的 Public Key 分析

Hacker News Daily 上看到有人針對 GitHub 上的 Public Key 分析:「Auditing GitHub users’ SSH key quality」。

這個分析主要用的是 GitHub 的 .keys 功能取得:

A little known feature of GitHub is the ability to look at the public SSH keys that other users have set to be authorised on their account (for example https://github.com/torvalds.keys)

作者從去年 2014 年 12 月 27 日跑到今年 2015 年 1 月 9 日,共取得了 1376262 把 public key,然後就針對這些 key 分析。

「The Debian bug bites again」這一段講的是 CVE-2008-0166 (可以參考「該換 ssh keys 了」這篇的說明),發現即使是七年後的現在,也還是有問題。

另外還有 256 bits 與 512 bits 的 RSA key,作者自己建立了一把測試,用 i5-2400 只要 25 分鐘就可以解出 256 bits 的 private key:

This risk isn’t only real if someone had gathered together top of the line mathematicians or supercomputers worth of power, the 256 bit key I factored was factored on a i5-2400 in 25 mins.

NSA 應該都摸透了...


[27th December 2014] Key Crawl Started
[28th Feb 2015] Disclosed low bits issue to a peer at GitHub
[1st March 2015] Discovered the weak Debian Keys (and disclosed)
[5th May 2015] Debian keys revoked, emails sent out
[1st June 2015] Weak and low quality keys revoked

破別人的機器然後拿來賣 Proxy 的「雲端服務」

在「Huthos VPS Provider: Totally legit, 1000% not a criminal organization.」這篇文章裡,作者因為平常就有弄密罐 (Honeypot),意外發現這種「業務」:

作者發現有人打進他的 Honeypot 並且留下紀錄,一路追蹤後發現...

安全的 SSH (Secure Secure Shell)

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

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

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

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


用 Shodan 掃台...

在「Using Shodan from the Command-Line」這邊看到跟資安有關的工具,然後跑回去研究 Shodan 這個工具。


而且還包括了目前已經有的 exploit 可以攻擊的對象?喂喂... (超開心?)

然後 port:22 的結果 (需要登入才能查詢),左邊列出全世界的數量排名,台灣居然是第三名?

一堆 Dropbear 看起來是一堆 WAN interface 對 internet 公開的分享器?我看到這些資料後才能理解,為什麼台灣在全世界跳板比率這麼高 XDDD

然後一如預期的,EC2 一堆機器開放全世界存取 ssh XDDDD

做 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。



總算是搞定 Vagrant + Docker...

Docker 最大的好處就是啟動速度,比 VirtualBox 快非常多,但 Vagrant 官方對於 Docker provider 的範例還是太少,踹了老半天才踹出來:



Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
    config.vm.provider "docker" do |docker, override|
        docker.image = "fgrehm/vagrant-ubuntu:precise"
        docker.has_ssh = true

        override.ssh.port = 22

然後用 vagrant up 跑起來,接下來就可以用 vagrant ssh 連進去。

其中 override 是目前的 workaround,可以參考 GitHub 上的「Docker provider: cannot 'vagrant ssh' when not using a Docker host VM · Issue #3799 · mitchellh/vagrant」。

Docker 的 image 不透過 Vagrant 管理,而是 Docker 自己處理。可以用 docker images (列出) 與 docker rmi [repository] (刪除) 操作。