上周，云服務提供商Linode發布了一篇博文，描述了其云服務客戶PagerDuty的服務器被入侵的過程。
網絡入侵事件已經泛濫，但此事值得關注的是，攻擊者是通過Linode的管理面板進入PagerDuty的服務器的，而想要做到這一點，攻擊者必須繞過安全性極高的雙因子身份驗證(2FA)。
在典型的2FA應用中，用戶身份驗證一般遵循以下過程：
用戶在網站或其他服務器上輸入用戶名和口令時，用戶的終端設備上會運行TOTP算法產生一次性的服務器口令，用戶再將此口令輸入服務器。服務器端也會運行TOTP來驗證輸入的一次性口令，想要驗證成功，用戶設備的時鐘需要和服務器的時鐘大致同步。用于后續所有身份驗證會話的單一密鑰，必須在之前通過安全信道在服務器和用戶設備之間共享。
谷歌認證器TOTP截圖
TOTP算法的安全取決于共享密鑰的保密性。密鑰一旦被盜，無論是從服務器端還是從客戶端流出的，TOTP都會功效全失，因為攻擊者手握密鑰也就擁有了產生一次性密碼的能力。Linode將基于時間的一次性口令(TOTP)作為第二個身份驗證因子。
下面我們來看看攻擊者是怎樣利用Linode上的配置問題入侵該客戶的：
在這起入侵事件中，攻擊者獲取到了一名PagerDuty雇員的Linode憑證，其中就包含有2FA，可以登錄Linode管理界面。通過此界面，攻擊者登入了PagerDuty托管在Linode的服務器。
但怪異的是，PagerDuty確信被盜憑證的源頭并非是客戶端（例如：某些手機惡意軟件），因為該雇員根本就沒有2FA憑證，他的手機在事件發生前幾個月就被清空了。隨后，PagerDuty向Linode通報了被黑事件，并提交了用于攻擊的服務器IP地址。令人驚訝的是，攻擊服務器也托管在Linode，因此，Linode可以對該服務器的完整鏡像做徹底的檢查。
結果最終發現，該服務器上存放有所有用于破解Linode的TOTP算法的工具和數據。其中包括：可用TOTP密鑰產生TOTP口令的軟件，能解密TOTP密鑰防護機制的軟件和密鑰。命令行歷史記錄中還發現了成功產生一次性口令的命令。
使用云服務提供商自己托管的服務器來攻擊通常不是個好主意，因為這樣云服務提供商就能夠徹查攻擊主機了（正如Linode最終所做的一樣）。而如果攻擊者的機器是另一個提供商托管，那這種徹查就不太可能了。因此可以猜測，攻擊者出于某些原因才不得不在Linode托管的服務器上發起攻擊。
一個可能的解釋是：Linode的某個內部漏洞只能從Linode內部被觸發。Linode安全團隊在其Lish Shell的SSH網關中發現了一個漏洞，可能被用于獲取在攻擊者機器鏡像上發現的那些信息。該漏洞詳細情況并未被透露，不過，博文中指出，Linode在被黑事件后做出的第一個改進，就是限制Lish對憑證信息的直接訪問：“我們的很多應用（比如Linode Manager和Lish）都執行用戶身份驗證。之前，這些應用直接訪問數據庫來獲取憑證信息。”
總結一下：Linode/PagerDuty被黑事件的一個合理的技術性解釋就是，攻擊者利用了Lish的直接數據庫訪問功能，獲取到存儲在同一個數據庫中的其他用戶憑證（比如通過SQL注入）。但是，要想利用Lish，攻擊者不得不在Linode系統內部進行操作，從Linode托管的服務器上發起攻擊。
當雙因子合二為一
大多數情況下，管理賬戶憑證是此類安全事件中最弱的一環。Linode雙因子身份驗證只在客戶端有意義，因為它要求客戶腦子里知道的（口令）和手里拿著的（內嵌密鑰的手機App）同時有效。然而，在服務器端，這兩種因子融合成了一個，即口令和TOTP密鑰都可以用單個應用訪問，而且很可能就保存在同個數據庫的同一行里。
云環境引入了機會的同時也引入了風險。云服務提供商必須將安全放在首位，云客戶在購買服務時應將安全作為主要關鍵因素進行考量。
據悉，因為被黑事件，PagerDuty已經更換了另一家云服務提供商。
京公網安備 11010502049343號