從網路協議的角度聊一聊最近Github被大規模攻擊事件

• 2020 年 4 月 2 日
• 筆記

3月27日 Github 疑似遭受大規模攻擊， desktop.github.com 、 pages.github.com 、 *.github.io 等多個站點均提示 "您的連接不是私密連接"，並且電信、移動、聯通、教育網均可復現該問題。

這裡我就從網路協議的角度來幫大家分析一下本次攻擊事件，網路永遠是不安全的，攻擊方式多種多樣，以下的分析是我認為可能性比較大的一種方式，大家有什麼問題歡迎後台私信我~

為什麼強制 Https 訪問

你在訪問 http://github.com 的時候，會發現瀏覽器只允許你通過 HTTPS 訪問，這是因為 Github 開啟了 HSTS，它告訴瀏覽器只能通過 HTTPS 訪問。

如果開啟了 HSTS，你可以在控制台看到 Strict-Transport-Security 這個標頭：

這個請求頭可以設置下面幾個屬性：

• max-age=<expire-time>：設置在瀏覽器收到這個請求後的<expire-time>秒的時間內凡是訪問這個域名下的請求都使用HTTPS請求。
• includeSubDomains(可選)：如果這個可選的參數被指定，那麼說明此規則也適用於該網站的所有子域名。
• preload 支援預載入 HSTS。

如果一個網站接受一個 HTTP 的請求，然後跳轉到 HTTPS，用戶可能在開始跳轉前，通過沒有加密的方式和伺服器對話，比如，用戶輸入 http://github.com 或者直接 github.com。

這樣存在中間人攻擊潛在威脅，跳轉過程可能被惡意網站利用來直接接觸用戶資訊，而不是原來的加密資訊。

用戶首次使用HTTPS訪問站點，並返回Strict-Transport-Security標頭時，瀏覽器會記錄此資訊，以便將來使用HTTP載入站點的嘗試將自動使用HTTPS.

當Strict-Transport-Security標頭指定的到期時間過去時，下一次嘗試通過HTTP載入站點的嘗試將照常進行，而不是自動使用HTTPS.

所以，github 開啟了 HSTS 意味著我們只能從用 HTTPS 來訪問它，但是這時候站點的中間某個環節出了問題導致無法建立安全鏈接，所以無法訪問，那麼瀏覽器是如何與服務端建立安全鏈接的呢？

瀏覽器如何建立安全鏈接

客戶端和服務端建立安全連接，一般需要經歷以下幾個步驟：

• 客戶端給出協議的版本號、一個客戶端生成的隨機數和客戶端支援的加密演算法；
• 服務端在客戶端給出的加密演算法列表中選出一種，並給出數字證書和一個服務端生成的額隨機數；
• 客戶端確認數字證書的有效性，然後生成一個新的隨機數，並使用數字證書中的公鑰加密這個隨機數；
• 服務端使用私鑰解密，獲取客戶端發來的隨機數；
• 客戶端和服務端根據約定的加密方法，使用之前的三個隨機數，生成對話密鑰，這個密鑰會用來加密接下來的整個通訊過程。

實際上這裡的過程複雜的多，這裡我只簡要描述一下過程，就不展開講了，看了很多解釋，還是《圖解 HTTP》的解釋最為經典：

那麼，以上任何一個步驟出了問題，瀏覽器都不能建立安全鏈接。

當瀏覽器出現 「您的連接不是私密連接」 這種情況，一般就是瀏覽器校驗證書出了了問題，那麼瀏覽器如何驗證SSL/TLS證書有效呢？

瀏覽器如何驗證SSL/TLS證書有效?

• 檢查證書是否是由瀏覽器中「受信任的根證書頒發機構」頒發

每一張證書都是由上級CA證書籤發的，上級CA證書可能還有上級，最後會找到根證書。最終瀏覽器會驗證證書是否是由瀏覽器中「受信任的根證書頒發機構」頒發。

• 檢查證書中的證書吊銷列表，檢查證書是否被證書頒發機構吊銷

證書吊銷列表(CRL)證書被吊銷後會被記錄在CRL中，CA會定期發布CRL。應用程式可以依靠CRL來檢查證書是否被吊銷了。

• 通過在線證書狀態協議檢測證書是否有效

在線證書狀態協議(OCSP)。除了證書吊銷列表離線文件，證書頒發者也會提供實時的查詢介面，查詢某個特定證書目前是否有效。實時查詢的問題在於瀏覽器需要等待這個查詢結束才能繼續TLS握手，延遲會更大。以上是站點在證書頒發者的角度說明會提供的兩種判斷方式，實際情況下瀏覽器究竟會選擇哪種方式判斷。

• 檢查此證書是否過期

證書中會包含證書的有效期的起始時間和結束時間，取其中一個即可判斷。

• 檢查部署此證書的網站的域名是否與證書中的域名一致
• IE7瀏覽器會到欺詐網站資料庫查詢此網站是否已經被列入欺詐網站黑名單

瀏覽器需經過以上幾個方面的檢查後，才會在頁面顯示安全鎖標誌，正常顯示部署了SSL/TLS證書的加密頁面。

如果這期間任何一個流程驗證出錯，那麼瀏覽器就無法建立安全鏈接，最終提示 "您的連接不是私密連接"。

打開這個不受信任的證書，顯示該證書的頒布者是[email protected]。

查詢該QQ號碼，顯示其昵稱為心即山靈，地址為黑龍江哈爾濱。打開他的QQ空間，發現他發了一條動態說自己的QQ被盜了，這裡很明顯有點掩盜鈴的感覺，因為攻擊者要生成CA證書的話，隨便填個郵箱都可以，還需要盜你的號么？

從攻擊者自簽名證書留下的QQ號可以在網上搜尋到部分資訊，資訊顯示此前這名攻擊者正在學習加密技術。這名攻擊者還曾在技術交流網站求助他人發送相關源程式碼，從已知資訊判斷攻擊者可能是在學習後嘗試發起攻擊。看了看這老哥的留言，已經火了。。

很顯然，這個證書被劫持了，而且這個證書肯定是不會被瀏覽器信任的，這才會導致瀏覽器無法建立安全鏈接，從而訪問失敗。

然而問題又來了，三大運營商紛紛中招，什麼樣的攻擊能控制如此大的範圍呢？

BGP 劫持

BGP 表示邊界網關協議，它是 Internet 的路由協議，它提供了方向，以便流量儘可能有效地從一個 IP 地址傳播到另一個 IP 地址。換句話說，它幫助我們高效地查找 A 伺服器到 B 伺服器的最佳路由路徑。DNS（域名系統）伺服器提供 IP 地址，但是 BGP 提供了最有效的方法來訪問該 IP 地址。粗略地說，如果 DNS 是 Internet 的通訊簿，則 BGP 是 Internet 的路線圖。

AS 指的是一個區域中大量電腦組成的網路，中國各家運營商管理著相應的 AS。

BGP 劫持就是某些 AS 通過宣稱自己擁有某個 IP 地址，而將對該 IP 地址的請求引向一些惡意伺服器。

這裡參考下一位知乎網友的圖，畫的很清晰：

用戶知道 github.com 的 IP 地址後，從 AS 1 出發，正常來說，應該訪問在 AS 4 的 Github 伺服器，但是 AS 5 與 AS 6 欺騙 BGP 它擁有 github.com 的 IP 地址並且誤導 BGP 的路徑經過它，於是用戶變成訪問 AS 6 伺服器，但是用戶還以為自己連接的是正確的伺服器（根據 IP 地址）。萬幸的是，由於 AS 6 的伺服器無法提供正確的 Github 證書。所以 HTTPS 連接無法正確建立。

攻擊者使用 BGP 劫持將 github.com 的 IP 指向了使用 [email protected] 自簽名的證書的伺服器，由於瀏覽器無法信任該證書，導致頁面訪問失敗，這就是整個事件的原因了。。

因為 BGP 提供了最有效的方法來訪問該 IP 地址，所以BGP劫持幾乎是不可能停止的，想像一下，如果沒有人在看高速公路標誌，唯一的方式告訴如果他們被惡意更改是通過觀察，很多汽車最終在錯誤的社區。然而，為了使劫持發生，攻擊者需要控制或破壞連接一個自治系統(AS)和另一個自治系統(AS)的啟用了BGP的路由器，因此不是每個人都可以執行BGP劫持。

這樣的事情早就不是第一次發生，2008 年巴基斯坦的 ISP 運營商就使用 BGP 劫持屏蔽用戶瀏覽 Youtube。2018 年，黑客通過 BGP 劫持將重定向了亞馬遜 DNS 伺服器的流量，然後盜取加密貨幣。

以上就是我的分析了，大家有什麼問題歡迎在後台私信我。