记一次云安全的安全事件应急响应
傳統(tǒng)的安全應(yīng)急響應(yīng)相信大家都見過,在之前的博文中也有過介紹。上周末我們的一個(gè)客戶發(fā)生的虛擬貨幣丟失事件,我們安全組介入排查,當(dāng)時(shí)很久都沒有頭緒,經(jīng)過某同事的靈光一閃,我們發(fā)現(xiàn)了轉(zhuǎn)機(jī)。一句話而言,云計(jì)算安全我們要考慮云計(jì)算和虛擬化的一些特性,避免被我們常見的應(yīng)急響應(yīng)思路所限制住。下面來說說詳情,由于部分信息敏感,請?jiān)忨R賽克處理:
- 原因:
核心支付代碼邏輯被插入了一個(gè)陌生的區(qū)塊鏈交易地址,每調(diào)用這個(gè)函數(shù)就轉(zhuǎn)走特定的虛擬貨幣到特定地址。
這塊涉及一個(gè)小的應(yīng)急知識點(diǎn),感謝sfish分享,在~/.ssh下存在vim的編輯歷史,我們可以通過這個(gè)小黑科技去分析一下對方篡改的文件。
cat ~/.viminfo- 最百思不得其解也最顯而易見的事兒
最費(fèi)解的來自于這段日志。系統(tǒng)發(fā)生了一次down機(jī)(New seat seat0),說明系統(tǒng)重啟過。然后黑客就登錄到了root權(quán)限,因?yàn)槭孪鹊臋C(jī)器sshd文件都只允許公鑰登錄,且所有賬戶都是強(qiáng)口令。一些都很匪夷所思,為啥重啟了一次系統(tǒng)的配置文件都改變了非常的奇怪,難道黑客手里有什么大狠狠的0day我們不知情?
這次應(yīng)急卡在了這里相當(dāng)久時(shí)間,大約有3個(gè)小時(shí),我們始終難以理解。直到我們同事說了句不經(jīng)意的話,我一般攻擊阿里云都通過ak接口還原鏡像!
對關(guān)鍵就在這里,鏡像!!平時(shí)我們用虛擬機(jī)的時(shí)候覺得沒事做個(gè)快照是很順手的事兒,然而面臨生產(chǎn)環(huán)境的時(shí)候,我們還以傳統(tǒng)的IDC思維去思考問題,造成了卡殼。因?yàn)檫€原鏡像一定會(huì)造成一次down機(jī),所以在考慮云計(jì)算安全事件的時(shí)候鏡像本身也是一個(gè)不能忽略的點(diǎn),我們只考慮到了溢出,弱口令等傳統(tǒng)攻擊方式,卻沒有想到黑客可以通過還原鏡像進(jìn)行相應(yīng)的攻擊。最后我們在客戶非自己打包的鏡像中,發(fā)現(xiàn)了黑客的history記錄。
剩下的事兒,大家看看也就明白了。
- 總結(jié):
這篇文章非常短,但我們踩過的坑卻是無數(shù)的。主要是云計(jì)算條件下,鏡像是一個(gè)非常重要的黑客攻擊點(diǎn)。基于ak接口的攻擊思路,我會(huì)在下片博文中詳細(xì)贅述。由于事件敏感,本文打了大量的馬賽克,希望大家再云安全應(yīng)急響應(yīng)的過程中能夠多學(xué)習(xí)到一種思路。
轉(zhuǎn)載于:https://www.cnblogs.com/Hyber/p/7552264.html
總結(jié)
以上是生活随笔為你收集整理的记一次云安全的安全事件应急响应的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 在windows下安装flex和biso
- 下一篇: codevs1520 回文字符串