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

• 原因：

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

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

cat ~/.viminfo

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

　　最費解的來自于這段日志。系統發生了一次down機（New seat seat0），說明系統重啟過。然后黑客就登錄到了root權限，因為事先的機器sshd文件都只允許公鑰登錄，且所有賬戶都是強口令。一些都很匪夷所思，為啥重啟了一次系統的配置文件都改變了非常的奇怪，難道黑客手里有什么大狠狠的0day我們不知情？

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

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

　　剩下的事兒，大家看看也就明白了。

• 總結：

　　這篇文章非常短，但我們踩過的坑卻是無數的。主要是云計算條件下，鏡像是一個非常重要的黑客攻擊點。基于ak接口的攻擊思路，我會在下片博文中詳細贅述。由于事件敏感，本文打了大量的馬賽克，希望大家再云安全應急響應的過程中能夠多學習到一種思路。

　　

　　

轉載于:https://www.cnblogs.com/Hyber/p/7552264.html

總結

以上是生活随笔為你收集整理的记一次云安全的安全事件应急响应的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。