看我如何繞過Lastpass雙因素驗證機制

在某次紅隊測試中，我發現了一種在Lastpass中繞過雙因素驗證（2FA）的方法。不幸的是，這一發現是在Tavis Ormandy曝光Lastpass遠程命令執行漏洞之前，否則會節省我許多時間。但無論如何，2FA是一層額外的安全防護，主要用來保護用戶帳戶免受那些已經破解了密碼的攻擊者對你發起攻擊。

當你在使用賬號密碼登錄所需要的服務時，往往都會在獲得訪問許可權之前，面臨一個挑戰——一個每30秒更改一組6位數的臨時代碼。比如Google驗證器、Authy和Toopher這些基於RFC6238和RFC4226的2FA方案，Lastpass也同樣支持。

LastPass 2FA的實現方式

/google_auth_qr_code.php?iterations=1&passwordhash=TOKEN

我以前研究過Lastpass，並在Blackhat EU做過演講，因此當看到參數「passwordhash」時我馬上就知道這是什麼了。 passwordhash是LastPass用於認證的登錄哈希，它由用戶密碼加鹽哈希並使用SHA256-PBKDF2保存。Lastpass使用PBKDF2保護保管庫與主密碼的加密密鑰。由於Lastpass不知道你的加密密鑰，所以它們應用了一輪PBKDF2，並將其用作登錄哈希參數。

存在的問題

這是什麼意思呢？ Lastpass將2FA秘密種子存儲在可以將你的密碼導出的URL下了。所以看起來這真的是打破了2FA的真正目的，如上所述，它應該是一種安全防範，用以防範那些已經擁有密碼登錄的攻擊者。但是按這種情況，你試著想想如果自己有一個安全的房子，保存著最寶貴的財物，而門和保險箱擁有同一把鎖是個好主意嗎？門鑰匙如果打開了保險箱怎麼辦？

傳遞URL中的秘密其實是一個非常不好的安全措施，因為URL是由網路伺服器記錄的。 Lastpass可以保護存儲所有用戶數據的資料庫，但是它們對日誌也會應用相同的安全標準，而攻擊者通常會針對性的尋找秘密的日誌。

URL也在緩存、代理、引用標頭甚至瀏覽器歷史記錄中被泄漏。

使用CSRF禁用2FA

事實上，寫這篇文章的原因是因為我想強調將密碼和2FA作為「獨立實體」的重要性。但真相是，我發現另一種更直接的方式是來禁用2FA，但在技術上卻沒啥意思。

真正的長久之計其實是重新生成2FA秘密種子。該功能的實現有3個問題：

重新生成種子不要求你通過要求臨時代碼來驗證設置；

重新生成種子會自動禁用2FA（而不是使其啟用但使用新的種子）；

再生種子的要求容易受到CSRF漏洞的影響；

所有這些問題的結合使得攻擊者有可能禁用受害者的2FA保護。

禁用2FA的請求如下所示：

GET /google_auth_regenerate_key.php HTTP / 1.1

Host：lastpass.com

Cookie：PHPSESSID=REDACTED

典型的CSRF是指在沒有CSRF令牌的狀態改變請求的GET請求，訪問攻擊者控制站點的受害者可能被迫提出請求並禁用2FA。

LastPass修復方案

Lastpass在報告當天就推出了初步修復方案，目前正在努力確定所有CSRF的脆弱性要求（還有更多），並通過添加CSRF令牌來修復通過CSRF漏洞禁用2FA。

時間線

02/07/2017：漏洞報告給Lastpass。

02/08/2017：確認漏洞。 CSRF被修復，添加原點檢查，密碼哈希不再被使用了。

02/10/2017：發放賞金。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！