駭客可獲假 HTTPS 認證 Let’s Encrypt 採取緊急措施

網頁應用程式安全自動掃瞄服務 Detectify 安全研究員近日 Frans Rosén 發現,TLS-SNI-01 以及 TLS-SNI-02 在特定的情況下,允許駭客取得他人網站的 HTTPS 認證。

證書頒發認證機構 Let’s Encrypt 表示,由於太多共享託管以及基礎設施服務違反 TLS-SNI 驗證,即日起停止通過 TLS-SNI 驗證取得認證,並對通過的驗證進行更新,Let’s Encrypt 鼓勵使用者,儘量更換成 HTTP 或是 DNS 驗證。

Frans Rosén 發現後,1 月 9 日已向 Let’s Encrypt 報告的 TLS-SNI-01 驗證存在風險,同時被視為其繼任機制的 TLS-SNI-02 驗證也具有同樣問題,Let’s Encrypt 也隨即停用 TLS-SNI 驗證。

TLS-SN I 是 Let’s Encrypt 3 個自動化認證管理環境(Automatic Certificate Management Environment,ACME)請求 TLS 認證協定的方法之一。而 Frans Rosén 發現,TLS-SNI-01 和 TLS-SNI-02 在特定的情況下,允許駭客取得他人的網站 HTTPS 認證。

駭客可以找到指向託管服務的獨立網域名稱,為該域名添加未授權的認證,以假亂真。例如一間擁有fakecert.com 網域的公司,將其位置指向一個位置非 fakecert.com 的雲端服務,而黑客就有機會在該雲端服務啟用一個全新的帳號,並用新帳號為 fakecert.com 添加 HTTPS 伺服器,再使用 Let’s Encrypt 的 TLS-SNI-01 驗證服務認證 HTTPS,讓假網站看起來跟真的一樣。

而這個風險發生的原因並非是 TLS-SNI 驗證程式上的漏洞,而是流程控制問題。不少託管服務不驗證網域的所有權,尤其是託管服務提供多個使用者共用同一 IP 時,更可能讓有心人士利用 Let’s Encrypt,並通過TLS-SNI-01 驗證機制取得他人的網站認證,無論是 AWS 的 CloudFront 或是 Heroku 都存在這樣的風險。

Frans Rosén 建議 3 個方法減少相關的風險,首先便是停用 TLS-SNI-01,再來是設置 .acme.invalid 入黑名單,最後為使用取得其他驗證的方法。Let’s Encrypt 目前也停止通過 TLS-SNI-01 機制發放認證,要求使用者轉而使用 HTTP-01 或是 DNS-01。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *