Shellshock漏洞那些事兒

        英文原文：Everything you need to know about the Heartbleed SSLbug

        還記得 Heartbleed 漏洞嗎？如果你相信今天這個鋪天蓋地的傳言，那說明 Shellshock 和它是一類的，它的名字也同樣令人畏懼（彈震癥，一種精神疾病），就是缺了個酷點的 LOGO 而已（這些漏洞的市場部的人需要加把勁了）。不過認真來講，它還是有可能成為一個大麻煩的，正如上次 heartbleed 漏洞中我所做的那樣，我希望能匯總出一些資料，這樣對我自己來說，我能知道如何去解決這個問題，也讓別人能在各種傳聞里真正認識到它潛在的風險。

        先做下準備工作，我先分享下 Robert Graham 的博客中的內容，文中對這個漏洞做了很細致的分析。假設有這樣一個 HTTP 請求：

target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html) http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
http-header = Host:() { :; }; ping -c 3 209.126.230.74
http-header = Referer:() { :; }; ping -c 3 209.126.230.74

        簡單來說，Robert 只是將一個專門準備好的請求發到了網上，他精心布置了一批外部的機器來 ping 一下他自己。真正讓人擔心的是，他使得這些機器可以執行任意的命令（盡管這里用的只是一個很友好的 ping 命令），這打開了另一個充滿著無限的可能的世界。下面我來解釋一下。

        什么是 Bash 以及為什么需要它

        這是老生常談了，你可以跳過這段，不過對于那些不太熟悉 bash 的人來說理解這個上下文還是很重要的，因此我還是簡單地介紹下吧。 bash 是*nix 系統上的 shell 也就是說，它是一個能讓你在 Unix 以及 Linux 系統上執行命令的一個解釋器，它通常是通過 SSH 或者 telnet 來連接的。它也可以作為 WEB 服務器上的 CGI 腳本的一個解析器，正如我們平時在 Apache 里面所看到的那樣。從上個世紀 80 年代開始它就已經存在了，它是從早期的 SHELL 實現中演化而來的（名字是從 Bourne shell 衍生出來的），并且非常流行。Unix 家族里還有許多別的 SHELL，bash 的特別之處在于它是 Linux 以及 Mac OS X 系統的默認 SHELL，而它們都是非常流行的操作系統。這個漏洞的風險之所以這么大，這也是一個非常主要的因素——bash 無處不在——它被稱作是"任何 Linux 系統上安裝量最大的工具之一”。

        看一下 Netcraft web 服務器的最近統計你可以感受下 bash 的足跡：

        半數的網站都是運行在 Apache 上的（Linux 上一般都會裝有），這是一塊非常非常大的蛋糕。Netcraft 的同一篇文章中也指出了，在我們剛逛過的 10 億個 WEB 站點中有一大半是用的同一款主機，這就已經有許多 bash 的裝機量了。好吧——這還只是 WEB 服務器而已，別忘了還有許多別的服務器也運行在 Linux 上，很快我們會講到還有哪些設備也會使用到 bash。

        許多常見的管理功能都會用到 bash，比如配置網站，或者控制設備上的嵌入式軟件，比如說網絡攝像頭。本質上來說這些并不是要開放給外部使用的，理論上來講，我們說的是通過認證的用戶在運行一些被授權可以執行的命令。當然了，這只是理論上。

        這個 BUG 是什么？

        我們來看下 NIST 的漏洞數據庫中的 CVE，因為它很好地闡釋了它的嚴重性：

        4. 3 版本之前的 GNU bash 會對環境變量值中函數定義后的字符串進行處理，這使得遠程攻擊者可以精心布局從而執行任意的代碼，已知的途徑包括 OpenSSH sshd 中的 ForceCommand 特性，Apache HTTP 服務器中的 modcgi 以及 modcgid 模塊，未知 DHCP 客戶端所執行的腳本，以及其它在 bash 中設置環境變量的場景中都會出現跨越權限邊界的問題。

        在嚴重性方面，他們給出的評級是 10 分（一共是 10 分），也就是說，非常嚴重。由于攻擊很容易發起，情況就更復雜了（訪問的難度很低），最明顯的就是，通過 CGI 腳本來調用 bash 無需任何認證。上面的描述有點復雜，我們還是來分析下這個 BUG 的原理吧。

        風險主要在于你可以在指定了函數定義的 BASH 中隨意定義環境變量。當 BASH 在處理函數定義后面的 SHELL 命令時，問題就來了，就會出現我們所說的”代碼注入攻擊“。我們來看下 Robert 的那個例子，只看這行就好了：

http-header = Cookie:() { :; }; ping -c 3 209.126.230.74

        當然了，修復這個攻擊途徑的一個方法就是禁用會調用 SHELL 的 CGI 功能，的確有人也是這么建議的。盡管在許多情況下，它會導致非常嚴重的破壞，至少來說，需要進行更廣泛的測試以確保它不直接導致網站出現問題，而很多時候，這的確會發生的。

        上面的 HTTP 的證子雖然很簡單，卻很有說服力，它只是一個常見協議上的一個實現而已。一旦你使用了 Telnet 或者 SSH，尤其是 DHCP，風險就會直線上升，因此這里我們不僅僅是在講如何利用 WEB 服務器進行攻擊。

        需要注意的是潛在在破壞遠不止 Robert 那個例子中只是隨意 ping 了個地址而已，他只是演示了可以操作一臺機器來執行一個 shell 命令。問題來了：攻擊者可以在他們的選擇的肉雞上執行 shell 命令會選成什么破壞？

        潛在的后果是什么？

        潛在的影響是巨大的——對攻擊者而言，奪取了 shell 一般來說就已經很成功了，因為控制了它，就相當于控制了目標環境。你可以訪問內部數據，重新配置環境，將他們的惡意代碼發布上去，等等。它無所不能，而且 是自動化的。有許多許多利用這個的例子，很多機器都會輕易中招。

        不幸的是，由于它可以在互聯網上幾乎半數的網站的 SHELL 中執行任意代碼，后果實在難以預料。最明顯的一個就是將內部文件允許公開訪問。密碼文件以及配置文件首當其沖，可以想像到還有系統上的其它文件。

        類似的，同樣的方法還可以用于往系統中寫文件。這是我們能看到的最簡單的攻擊網站的途徑之一了，更別說它可以很容易發布一些惡意代碼。

        那這個呢：我見到的一個最多的詞就是：“蠕蟲“：

        我正在 2014 年的病毒公報的會議中，我們在打賭什么時候會看到有蠕蟲利用 Shellshock 在進行傳播。

        當提起計算機中惡意的蠕蟲病毒的時候，我們指的是自我復制型的攻擊，惡意的攻擊者會編寫可以在不同機器間傳播的惡意代碼。比如說，Samy 這個 Myspace 上的 XSS 蠕蟲就是一個令人印象非常深刻的一個例子，這段精心編寫的 JavaScript 會在不到一天時間內感染許多受害者的網頁。

        Shellshock 存在的擔心就是類似的攻擊能夠迅速地復制，尤其是早期許多機器仍然存在風險的時候。理論上來講，它會利用受感染的機器去掃描其它可以傳播并進行攻擊的目標。這絕不僅僅只限于可以公開訪問的機器，企業防火墻背后的機器也無法幸免。

        有許多人正在利用這一 BUG 進行攻擊。這也是最早的這幾天之所以有意思的地方，這是那些在抓緊時間修復補丁的人和那些正在抓緊時間進行攻擊的人之間的裝備競賽。

        哪些版本的 Bash 會被影響？

        標題里說了，4.3 之前的版本都會受到影響，也就是說，這 25 年來的 Bash 版本。既然大家都喜歡拿它和 Heartbleed 比，考慮到 OpenSSL 受影響的版本只發布了僅僅兩年，這和 Shellshock 相比簡直是小巫見大巫。是的，大家會升級自己的版本，但他們不會一直更新，Shellshock 中潛在風險的機器的數量都要遠遠多于 Heartbleed 的。

        不過這個風險可能還不止 4.3 版本。因為我們看到報告稱這個補丁并不能完全修復所有的問題,不過考慮到這個補丁推出的速度，這也并不奇怪。那些受它影響的人應該時刻關注下這個，而不只是“修復一下就忘了這茬了”。

        我們首次發現它是什么時候，這個風險已經存在了多久了？

        從公共媒體上能找到的首次報道是 seclists.org 上的這段簡短的摘要，它是 GMT 時間周三 18：00 左右（對于澳大利亞西部的人來說大概是今天早上 2 點）。詳細的介紹在我前面提到的那份報告中有指出，大概是一個小時之后，大概是歐洲時間的周三下午或者美國時間的中午。這還是個很新的消息，現在充斥著大量的媒體的推測，就如一窩小雞在嘰嘰喳喳，要想看到大規模的攻擊現在還為時過早，不過如果這一漏洞的潛力充分發揮之后那也很快了。

        再看下之前已經發布出來的消息，這個 BUG 似乎上周就被英國的一個”Unix/Linux，網絡通信專家“Stéphane Chazelas 指出了。在 Akamai 關于這個 BUG 的文章上提到，他們認為它已經”存在了相當長的時間“，當然這個易受攻擊的 Bash 版本已經存在了一二十年了。正如 Heartbleed 那樣，問題在于是否有惡意的攻擊者已經獲知這個 BUG 并且已經在利用它了。

        我的東西有被影響到嗎？

        這正是有意思的地方——我們有很多東西都在運行 Bash。當然我這么說指的是越來越流行的”物聯網（IoT)“，它將一個 IP 地址以及一個無線適配器植入到了我們許多的東西里面，從餐具到門鎖再到我們的電燈。

        許多物聯網的設備都運行著帶有 Bash 的 Linux 發行版。我們已經看到，其它領域的這些設備是存在非常嚴重的安全問題的，比如數月前 LIFX 的電燈就被發現會泄露 WIFI 證書。雖然并不是像 Shellshock 這樣的 Bash 漏洞，它也讓我們看到了，將我們的物品連接到網絡將我們原本安全的地方帶入了一個充滿風險的新世界。

        它還帶來了許多新的挑戰：比如說，誰會總想著說給自家的電燈打個補丁的？再想想這個設備它的使用壽命又很長，你是否會管理它上面的軟件。像數年前 Trendnet 攝像頭那樣的漏洞， 毫無疑問，現在仍有許多這樣的攝像頭還暴露在網絡上，因為打補丁這個事，很容易左耳進右耳出。事實上在這個例子中，有一個 T witter 帳號仍在不停地廣播它所抓到的被攻擊版本的用戶的圖片。這是個不太容易修復的大問題，在相當長的一段時間內，它還會一直伴隨著我們。

        同樣，Bash 在許多常見的設備上都會裝有，比如我們家里的路由器，它們一般都是面向網絡的。還記得你上次給固件打補丁是什么時候了么？好吧，如果你會讀到這篇文章說明 你還是個技術人員，還是會去給自己的路由器打補丁的，但是假設你自己是那些普通的消費者，你再想想看。就是這樣。

        我用的全是微軟系的，會有風險嗎？

        簡單來說，”沒有“，確切來說，”有的“。我先說下簡單的這個吧——原生的 Windows 是沒有 Bash 的，但是有 Windows 版本的 Bash，當然這并不常見，在一般消費者的 PC 上不太可能會有。現在還不清楚，像 win-bash 這樣的產品是否也會受到 Shellshock 漏洞的影響。

        確切來說的話，雖然你使用的是占主導地位的 Windows 平臺，但這并不意味著你的機器不會由于別的原因在運行著 Bash。當我在寫 Heartbleed 的文章的時候，我引用了 Nick Craver 的一篇文章，將 Stack Overflow 遷移到 SSL，下圖能夠說明他們的架構：

        在微軟應用棧前面還有許多非微軟的組件，流量得先經過它們才能傳遞到 WEB 服務器中。還有一些組件是在防火墻后面的，擁有較高的權限——如果 Shellshock 攻擊了這些組件的話怎么辦？這個影響會很大，這正是這里我要說的：Shellshock 有可能會影響到除了帶有風險的 Bash 實現以外的東西，因為它存在于一個更廣泛的生態系統當中。

        我是系統管理員——我該怎么做？

        首先，看下自己是否也存在這個風險，這個很簡單因為它很容易復現。the register 上面推薦了一個簡單的測試方法，只用在你的 shell 里運行一下這個命令就可以了：

env X="() { :;} ; echo busted" /bin/sh -c "echo stuff”

        如果你的系統中存在這個漏洞，則會輸出“busted"。

        當然了，現在該做的就是給這個存在風險的系統打補丁了，這個補丁本質上用一句話來說就是確保在 Bash 函數后邊不會再執行代碼。Red Hat 等 Linux 版本都發布了修復這個風險的指南, 因此優先試一下那個。

        我們肯定也會看到有一些入侵檢測系統，當然這里也有一些常見的可檢測的模式。對大多數機構而言這可能是一個簡單有效的方法，尤其是有些公司在打補丁之前還得進行大量的檢測工作。Qualys 希望能快速實現攻擊檢測的定位，當然其它的 IDS 提供商也在馬不停蹄地忙著這個。

        更激進的方法就是用一個別的 shell 實現來替換掉 bash，或者在存在風險的系統上進行隔離，這兩者的影響都會比較大，因此，要下這個決心可不太容易。不過可能對很多人來說這個 BUG 就是這么處理的——能切實地改進業務的艱難決定是為了避免潛在的更嚴重的后果。

        還有一個大家很關心的問題就是自己的機器上 Shellshock 這個漏洞是否已經被人利用了。如果沒有攻擊的日志的話這個很難確認（如果是通過 HTTP 請求的頭或者請求體傳入進來的話一般都沒有日志），不過這個比 Heartbleed 要容易發現一些，后者的網絡包幾乎不太可能會輸出到日志里。不過對于“我是否已經被 Shellshock 攻擊了”的最常見回答就是：

        不幸的是，并沒有“沒有，我們已經證實這決無影響”這樣的回答，相反的，“從這個漏洞出現的這段時間來看，并沒有確切證據表明你被攻擊了”。我相信許多人都是這么回答的——這會讓系統負責人感到很不快，因為他并不知道自己的系統發生了什么，如果真的發生過什么的話。

        我們來猜測下國家安全局是否會介入此事吧。。

        我是個普通用戶——我能做些什么？

        這就得看情況了。Shellshock 會影響到 Mac 系統，因此如果你使用的是 OS X 的話，眼下看起來很危險，一方面因為 Mac 很流行所以情況不太妙，但另一方面，由于它的更新機制這個也很容易修復。（蘋果可以遠程推送更新到這臺機器上）。

        如果你使用的是 Mac, 照 Stack Exchange 上的那個回復所說的那樣做可以很容易檢測下自己是否中招了：

        這個很容易測試，不過我懷疑一般的 Mac 用戶看到這個要重新編譯 bash 的修復建議時會不會感到不爽(注：我是覺得很不爽)。

        更麻煩的是有些設備可能不太容易修復，比如說你的路由器。除了到廠商的網站上看看有沒有固件更新外，真是沒啥容易的辦法了。一般來說 ISP 提供的路由器是上鎖的，因此用戶無法修改配置或者固件，一般也說也沒有什么可以觸發的遠程更新。考慮到有許多設備都已經在外邊了，想修復它們的話還是有點 難度的。當然了，要你這樣的普通消費者來修復這個，你肯定會感到很不滿的。

        簡而言之，對消費者而言我建議這樣：關注安全更新，尤其是 OS X 上的用戶。同時關注你從 ISP 那拿到的設備，或者別的運行嵌入式軟件的設備。尤其小心那些請求你的信息或者引導你運行軟件的那些郵件——像這類的事件總是會伴隨著許多網絡釣魚，它們利 用了消費者恐懼的心理。最近的惡作刷病毒讓用戶將他們的 iPHone 放到微波爐里,因此千萬別以為他們不會運行那些發送給他們的”修復"Shellshock 的郵件。

        總結

        我們對這個漏洞的了解只是皮毛而已。當然了，會有很多人將它和 Heartbleed 進行比較，從這之中我們也會汲取到許多的經驗。一個就是我們花了點時間來了解到我們有多依賴 OpenSSL。另外一個就是它還遠沒有結束——幾個月過后，還有數不清的知名站點還是沒有修復。

        不過從某個意義上來講，拿它和 Heartbleed 來比不太公平——shellshock 可能要更糟糕。Heartbleed 允許你遠程訪問到被影響機器的內存中的一小部分數據。而 Shellshock 可以遠程注入代碼來執行任意的命令而無需認證，這估計會更為杯具。因此，我很同意 Robert 說的那句話：

        順便提一句，'bash'這個 BUG 可比 Heartbleed 要嚴重多了。

        現在時間還很短，從它首次被披露受到攻擊到現在寫這篇文章才只有半天時間——結果會怎樣，我覺得我們只是看到了一點表面現象而已。