記一次雲安全的安全事件應急響應

　　傳統的安全應急響應相信你們都見過，在以前的博文中也有過介紹。上週末咱們的一個客戶發生的虛擬貨幣丟失事件，咱們安全組介入排查，當時好久都沒有頭緒，通過某同事的靈光一閃，咱們發現了起色。一句話而言，雲計算安全咱們要考慮雲計算和虛擬化的一些特性，避免被咱們常見的應急響應思路所限制住。下面來講說詳情，因爲部分信息敏感，請原諒馬賽克處理：

• 緣由：

　　核心支付代碼邏輯被插入了一個陌生的區塊鏈交易地址，每調用這個函數就轉走特定的虛擬貨幣到特定地址。

　　這塊涉及一個小的應急知識點，感謝sfish分享，在~/.ssh下存在vim的編輯歷史，咱們能夠經過這個小黑科技去分析一下對方篡改的文件。

cat ~/.viminfo

• 最百思不得其解也最顯而易見的事兒

　　最費解的來自於這段日誌。系統發生了一次down機（New seat seat0），說明系統重啓過。而後黑客就登陸到了root權限，由於事先的機器sshd文件都只容許公鑰登陸，且全部帳戶都是強口令。一些都很匪夷所思，爲啥重啓了一次系統的配置文件都改變了很是的奇怪，難道黑客手裏有什麼大狠狠的0day咱們不知情？

　　此次應急卡在了這裏至關久時間，大約有3個小時，咱們始終難以理解。直到咱們同事說了句不經意的話，我通常攻擊阿里雲都經過ak接口還原鏡像！

　　對關鍵就在這裏，鏡像！！平時咱們用虛擬機的時候以爲沒事作個快照是很順手的事兒，然而面臨生產環境的時候，咱們還以傳統的IDC思惟去思考問題，形成了卡殼。由於還原鏡像必定會形成一次down機，因此在考慮雲計算安全事件的時候鏡像自己也是一個不能忽略的點，咱們只考慮到了溢出，弱口令等傳統攻擊方式，卻沒有想到黑客能夠經過還原鏡像進行相應的攻擊。最後咱們在客戶非本身打包的鏡像中，發現了黑客的history記錄。

　　剩下的事兒，你們看看也就明白了。

• 總結：

　　這篇文章很是短，但咱們踩過的坑倒是無數的。主要是雲計算條件下，鏡像是一個很是重要的黑客攻擊點。基於ak接口的攻擊思路，我會在下片博文中詳細贅述。因爲事件敏感，本文打了大量的馬賽克，但願你們再雲安全應急響應的過程當中可以多學習到一種思路。