Bash漏洞那些事兒
還記得Heartbleed漏洞嗎?如果你相信今天這個鋪天蓋地的傳言,那說明Shellshock和它是一類的,它的名字也同樣令人畏懼(彈震症,一種精神疾病),就是缺了個酷點的LOGO而已(這些漏洞的市場部的人需要加把勁了)。不過認真來講,它還是有可能成為一個大麻煩的,正如上次heartbleed漏洞中我所做的那樣,我希望能匯總出一些資料,這樣對我自己來說,我能知道如何去解決這個問題,也讓別人能在各種傳聞裏真正認識到它潛在的風險。
先做下準備工作,我先分享下 Robert Graham的博客中的內容,文中對這個漏洞做了很細致的分析。假設有這樣一個HTTP請求:
1 |
target = 0.0 . 0.0 / 0
|
2 |
port = 80
|
3 |
banners = true
|
4 |
http-user-agent = shellshock-scan (http: //blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
|
5 |
http-header = Cookie:() { :; }; ping -c 3 209.126 . 230.74
|
6 |
http-header = Host:() { :; }; ping -c 3 209.126 . 230.74
|
7 |
http-header = Referer:() { :; }; ping -c 3 209.126 . 230.74
|
當它經過一係列易受攻擊的IP地址後,結果會是這樣的:
簡單來說,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服務器中的mod_cgi以及mod_cgid模塊,未知DHCP客戶端所執行的腳本,以及其它在bash中設置環境變量的場景中都會出現跨越權限邊界的問題。
在嚴重性方麵,他們給出的評級是10分(一共是10分),也就是說,非常嚴重。由於攻擊很容易發起,情況就更複雜了(訪問的難度很低),最明顯的就是,通過CGI腳本來調用bash無需任何認證。上麵的描述有點複雜,我們還是來分析下這個BUG的原理吧。
風險主要在於你可以在指定了函數定義的BASH中隨意定義環境變量。當BASH在處理函數定義後麵的SHELL命令時,問題就來了,就會出現我們所說的”代碼注入攻擊“。我們來看下Robert的那個例子,隻看這行就好了:
1 |
http-header = Cookie:() { :; }; ping -c 3 209.126 . 230.74
|
這個函數定義是 () { :; }; 而SHELL命令是ping語句以及它的參數。當它在一個bash SHELL的環境中執行的時候,它可以執行任意的命令。在WEB中,可以通過一個類似CGI腳本的機製,不一定非要是在請求頭裏。讀一下seclists.or中的建議還是很有必要的,裏麵介紹得詳細一些,還提到了路徑及查詢串也是攻擊的潛在目標。
當然了,修複這個攻擊途徑的一個方法就是禁用會調用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裏運行一下這個命令就可以了:
1 |
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要嚴重多了。
現在時間還很短,從它首次被披露受到攻擊到現在寫這篇文章才隻有半天時間——結果會怎樣,我覺得我們隻是看到了一點表麵現象而已。
最後更新:2017-05-23 16:02:42