<dfn id="hx5t3"><strike id="hx5t3"><em id="hx5t3"></em></strike></dfn>

    <thead id="hx5t3"></thead><nobr id="hx5t3"><font id="hx5t3"><rp id="hx5t3"></rp></font></nobr>

    <listing id="hx5t3"></listing>

    <var id="hx5t3"></var>
    <big id="hx5t3"></big>

      
      

      <output id="hx5t3"><ruby id="hx5t3"></ruby></output>
      <menuitem id="hx5t3"><dfn id="hx5t3"></dfn></menuitem>

      <big id="hx5t3"></big>

        黑客自述:我是如何侵入蘋果、微軟和數十家其他公司的...

        王治治

        黑客的工作在我們普通人看來,更像是一門看不懂的“玄學”。但這項玄學的背后,很多看起來高深莫測的網絡攻擊,使用的都是非常簡單卻有效的方法。

        最近,一位名叫 Alex Birsan 的黑客,正式通過一種非常簡單卻實用的方法,發現了 30 多家科技公司存在的漏洞,并因此獲得了高額的漏洞賞金。

        下面是這位黑客在個人博客中的自述,我們可以通過這篇文章了解一下玄學背后的故事。


        作者:Alex Birsan
        原文鏈接:https://medium.com/@alex.birs...

        自從我開始學習如何編程以來,我一直對這一句簡單的代碼指令有些疑惑:

        pip install package_name
        

        某些編程語言(例如 Python)使用一種簡單的官方方法來為項目安裝依賴項。這些安裝程序通常與公共代碼存儲庫綁定,在那里任何人都可以自由上傳代碼包供他人使用。

        當下載和使用其他來源的安裝包時,我們基本上是信任其發行者在我們的機器上運行代碼。那么這種盲目的信任會被惡意行為者利用嗎?

        答案是當然可以。

        任何程序包托管服務都無法保證其用戶上傳的所有代碼均不含惡意軟件。過去的研究表明,「域名搶注(利用包名稱的錯字版本進行的攻擊)」在獲得對全球隨機 PC 的訪問方面非常有效。

        其他眾所周知的依賴項攻擊路徑包括使用各種方法來破壞現有軟件包,或以不再存在的依賴項名稱上傳惡意代碼。

        image.png

        想法

        在 2020 年夏季嘗試與我入侵 PayPal 時,Justin Gardner(@Rhynorater)分享了在 GitHub 上發現的有趣的 Node.js 源代碼。

        該代碼是供內部 PayPal 使用的,并且在其 package.json 文件中似乎包含公共和私有依賴項的混合 —— 來自 npm 的公共軟件包以及非公共軟件包的名稱,這些很可能是 PayPal 內部的私有軟件包,由 PayPal 內部托管。因為這些名稱當時在公共 npm 注冊表中不存在。

        image.png

        這個邏輯會引起一些問題:

        • 如果以這些名稱將惡意代碼上傳到 npm 會發生什么?PayPal 的一些內部項目是否有可能開始默認為新的公共軟件包而不是私有軟件包?
        • 開發人員或者一些自動化系統會開始在庫中運行這些軟件包嗎?
        • 如果這種方法行得通,我們可以借助這個方式從科技企業獲得漏洞賞金嗎?
        • 這種攻擊還會對其他公司起作用嗎?

        事不宜遲,我開始制定計劃來回答這些問題。

        這個想法是將我自己的“惡意” Node 程序包以所有無人認名的名稱上載到npm注冊表中,這將從安裝它們的每臺計算機上“打電話回家”。如果最終將任何軟件包安裝在 PayPal 擁有的服務器上,則其中的代碼會立即通知我。

        在這一步中,我覺得很重要的一點是,必須明確指出,在此研究過程中所針對的每個組織都已允許通過公共漏洞賞金計劃或通過私人協議來對其安全性進行測試。未經授權,請勿嘗試這種測試。

        “總是 DNS”

        值得慶幸的是,npm 允許在安裝軟件包時自動執行任意代碼,這使我可以輕松創建一個 Node 軟件包,該軟件包收集有關通過其 preinstall 腳本安裝在其上的每臺計算機的一些基本信息。

        為了在基于數據識別組織的能力與避免收集太多敏感信息之間取得平衡,我決定只記錄用戶名,主機名和每個唯一安裝的當前路徑。與外部 IP 一起使用的數據就足夠了,可以幫助安全團隊根據我的報告確定可能受到攻擊的系統,同時避免將我的測試誤認為是實際的攻擊。

        現在剩下的一件事 —— 如何將這些數據還給我?

        知道大多數可能的目標都將位于受良好保護的公司網絡內部,我認為 DNS 滲透是解決之道。

        image.png

        通過 DNS 協議將信息發送到我的服務器對于測試本身能否正常工作不是必不可少的,但它確實確保了在出站時不太可能阻止或檢測到流量。

        數據經過十六進制編碼,并用作 DNS 查詢的一部分,該 DNS 查詢直接或通過中間解析器到達了我的自定義名稱服務器。服務器配置為記錄每個接收到的查詢,實質上記錄了下載軟件包的每臺計算機的記錄。

        多多益善

        有了攻擊的基本計劃,現在是時候發現更多可能的目標了。

        第一個策略是尋找類似的生態系統進行攻擊。因此,我將代碼移植到了 Python 和 Ruby 上,以便能夠分別將相似的軟件包上傳到 PyPI(Python 軟件包索引)和 RubyGems。

        但是可以說,該測試最重要的部分是找到盡可能多的相關依賴項名稱。

        在搜索了一些目標公司的私有軟件包名稱的整整幾天后,發現可以在 GitHub 以及主要軟件包托管服務(偶然發布的內部軟件包內部)甚至內部的主要軟件包托管服務中找到許多其他名稱,或者各種互聯網論壇上的帖子。

        但是,到目前為止,找到私有程序包名稱的最佳位置竟然是在各家公司或平臺的的 javascript 文件中。

        顯然,package.json 包含 javascript 項目依賴項名稱的內部文件在其構建過程中會嵌入到公共腳本文件中,從而暴露內部包名稱,這是很常見的。同樣,require() 這些文件中泄漏的內部路徑或調用也可能包含依賴項名稱。蘋果、Yelp 和特斯拉只是以這種方式公開內部名稱的公司的一些例子。

        image.png

        在2020年下半年,由于@streaak的幫助和他出色的偵察技能,我們能夠自動掃描屬于目標公司的數百萬個域,并提取數百個尚未在 npm 注冊表中聲明的 javascript 程序包名稱。

        然后,我將代碼上傳到所有找到的名稱下的包托管服務中,并等待回調。

        結果

        成功率簡直是驚人的。

        從開發人員在自己的計算機上犯下的一次性錯誤,到內部或基于云的構建服務器配置不當,再到系統易受攻擊的開發管道,一件事很明顯:搶占有效的內部軟件包名稱幾乎是一種不會失敗的方法。一些最大的科技公司的網絡,可以遠程執行代碼,并且可能允許攻擊者在構建過程中添加后門。

        迄今為止,我已經在超過 35 種組織中的所有三種經過測試的編程語言中檢測到了這種類型的漏洞,我將這種漏洞稱為「依賴混淆」。絕大多數受影響的公司屬于 1000 多名員工類別,這很可能反映了大型組織內部使用內部軟件庫的普遍性。

        由于更容易找到 javascript 依賴項名稱,幾乎所有已記錄的回調中有 75% 來自 npm 軟件包 —— 但這并不一定意味著 Python 和 Ruby 不太容易受到攻擊。實際上,盡管在我的搜索過程中只能識別出屬于八個組織的內部 Ruby 名稱,但事實證明,其中有四家公司很容易通過 RubyGems 造成依賴混淆。

        加拿大電子商務巨頭 Shopify 是這樣的公司之一,其構建系統 shopify-cloud 僅在我上傳 Ruby 幾個小時后自動安裝了一個名為 Ruby 的 Ruby gem ,然后嘗試在其中運行代碼。Shopify 團隊在一天之內準備好修復程序,并為發現問題的我提供了 30,000 美元的漏洞賞金。

        在我于 2020 年 8 月上傳到 npm 的 Node 包中的代碼在其網絡內的多臺計算機上執行之后,蘋果也提供了 30,000 美元的獎勵。受影響的項目似乎與 Apple 的身份驗證系統(外部稱為 Apple ID)有關。

        當我提出這個漏洞可能允許威脅者向 Apple ID 注入后門的想法時,Apple 并不認為這種影響水平可以準確地表示問題所在,而是說:

        在運營服務中實現后門需要更復雜的事件序列,并且這是一個帶有附加含義的非常特定的術語。

        但是,Apple 確實確認使用此 npm 軟件包技術可以在 Apple 服務器上執行遠程代碼。根據軟件包安裝的流程,該問題在我報告的兩周內得到解決,但僅在發布此帖子之前不到一天就授予了賞金漏洞。

        image.png

        在針對其他公司的其他幾次成功攻擊中,可以看到在內部服務器和個人開發人員的 PC 上都安裝了相同主題的 npm 軟件包,其中一些安裝通常是在軟件包上載后數小時甚至數分鐘進行的。

        實際上,大多數已授予的 Bug 賞金都設置為每個程序的策略所允許的最高數額,有時甚至更高,這證實了依賴混淆 bug 的嚴重性通常很高。其他受影響的公司包括 Netflix,Yelp 和 Uber。

        “這不是一個錯誤,這是一個功能”

        盡管有大量的依賴混淆的發現,但一個細節在某種程度上仍然是(現在仍然是)尚不清楚:為什么會這樣?此類漏洞的主要根源是什么?

        可以理解,大多數受影響的組織都不愿透露有關其根本原因和緩解策略的更多技術細節,但是在我的研究過程中以及與安全團隊的溝通中確實出現了一些有趣的細節。

        例如,Python 依賴關系混亂的罪魁禍首似乎是錯誤地使用了“設計不安全”命令行參數 --extra-index-url。使用此參數 pip install library 指定您自己的包索引時,您可能會發現它可以按預期工作,但是 pip 幕后的實際操作是這樣的:

        • 檢查指定(內部)包索引上是否存在庫
        • 檢查公共包索引(PyPI)是否存在庫
        • 安裝找到的任何版本。如果兩個軟件包均存在,則默認從具有更高版本號的源進行安裝。

        因此,library 9000.0.0在上面的示例中,上傳名為 PyPI 的程序包將導致依賴關系被劫持。

        盡管這種行為已經廣為人知,但僅在 GitHub 上搜索 --extra-index-url 就足以找到一些屬于大型組織的易受攻擊的腳本 —— 包括一個影響 Microsoft .NET Core 組件的錯誤。不幸的是,該漏洞可能允許向 .NET Core 添加后門程序,但該漏洞在 .NET Bug 賞金計劃中未被發現。

        Ruby 的 gem install --source 工作方式也與此類似,但是我無法確定其用法是否是我發現的根本原因。

        當然,更改 --extra-index-url--index-url 是一種快速而直接的解決方法,但是事實證明,依賴混淆的其他一些變體很難得到解決。

        與此同時,Microsoft 還提供了類似的名為 Azure Artifacts 的程序包托管服務。根據我的一份報告,對該服務進行了一些小的改進,以確保它可以為依賴項混淆漏洞提供可靠的解決方法。有趣的是,沒有通過測試 Azure Artifacts 本身發現此問題,而是通過成功攻擊 Microsoft 自己的基于云的 Office 365 來發現此問題,該報告得到了 Azure 可能獲得的最高獎勵 40,000 美元。

        未來的研究?

        盡管許多大型科技公司已經意識到這種漏洞,并已在其基礎架構中對其進行了修復,或者正在努力實施緩解措施,但我仍然感到還有很多發現的感覺。

        具體來說,我相信找到泄漏內部程序包名稱的新方法將揭示更多易受攻擊的系統,而尋找替代的編程語言和目標存儲庫將揭示依賴混淆錯誤的其他攻擊面。

        話雖這么說,無論您的經驗水平如何,我都竭誠鼓勵您花一些時間在腦海中嘗試一下該想法 —— 無論它是否與依賴項管理安全性相關。

        image.png

        閱讀 1.1k

        SegmentFault 行業快訊
        第一時間為開發者提供行業相關的實時熱點資訊
        avatar
        王治治
        SegmentFault 技術編輯

        學者所志至大,猶恐所得淺。

        1.1k 聲望
        5.2k 粉絲
        0 條評論
        avatar
        王治治
        SegmentFault 技術編輯

        學者所志至大,猶恐所得淺。

        1.1k 聲望
        5.2k 粉絲
        宣傳欄
        一本到在线是免费观看_亚洲2020天天堂在线观看_国产欧美亚洲精品第一页_最好看的2018中文字幕