前情提要

前段時間，我在一個非公開的 Bug 賞金項目里發(fā)現(xiàn)了一個嚴重的漏洞，這個漏洞可以允許遠程執(zhí)行代碼。在我提交漏洞報告的幾個小時后，我收到了第一封郵件回復，他們說會盡快確認漏洞然后再和我聯(lián)系。到目前為止一切都是正常的。

但是第二封郵件的回復揭開了整個驚心動魄的故事，就像多米諾骨牌效應一樣把更多的問題暴露了出來。

關于這個事故，社區(qū)反應是這樣的：

https://twitter.com/secalert/status/1339640670210945030

線上會談前的郵件往來

我找出了這個遠程代碼執(zhí)行的漏洞，并且在報告里用 5 個命令來演示 POC(Proof Of Concept)。因為我不想在 POC 里造成任何破壞，所以我決定用下面這幾個命令：

第 1 封郵件回復說他們會認真排查報告里說到的問題。

但是第 2 封郵件的回復是這樣的

親愛的 Dave，

感謝你的報告和 POC。因為我們現(xiàn)在人手不足，所以只能讓我們的初級工程師來驗證你提到的遠程代碼執(zhí)行漏洞。但是他在驗證的過程中嘗試用命令 rm -rf * 來看 web 的用戶是否能造成破壞。不幸的是，因為這個命令他把所有東西都刪了。我們會嘗試盡快恢復數(shù)據(jù)來繼續(xù)漏洞修復，當我們的問題解決的時候我們會再讓你幫忙驗證漏洞修復的情況。

我回復他們我隨時可以來幫助他們解決問題。

接著他們第 3 封郵件的回復是這樣的：

親愛的 Dave，

跟你同步一下進度。我們已經(jīng)導入了備份。但是不幸的是，我們發(fā)現(xiàn)本來預計的是通過 cronjob 每 3 天備份一次，但是無意中配置成了每3個月備份一次，這導致我們沒有辦法恢復這幾個星期的數(shù)據(jù)了。我們現(xiàn)在已經(jīng)修復了這個問題，未來也會更加注重在多個工程師之間做結對編程和代碼審查。

最后第 4 封郵件的回復是這樣的：

親愛的 Dave，

感謝你耐心等候。我們已經(jīng)優(yōu)化了備份的流程，也盡可能地導入最新的備份。同時我們開發(fā)部門的同事也修復了你報告里提到的漏洞，現(xiàn)在已經(jīng)熱更放了出去。你現(xiàn)在可以再幫忙驗證一下這個漏洞是否真的被修復了嗎？

確認漏洞修復并且提出線上會談

我確認了他們的漏洞已經(jīng)修復了，接著向他們提出要不要進行一次線上會談來聊聊這個案例，因為這種事情很容易發(fā)生在初學者身上，一起聊一聊的話可以分享這些踩過的坑，來防止其他人再犯同樣的錯誤。讓我很驚喜的是他們答應了。事實證明，無論是他們還是他們的公司都不是徒有虛名。

當事人愿意出來解釋前因后果

首先，我要借這個機會來感謝兩位當事人工程師愿意來和我線上會談，并同意讓我引用之前溝通的內(nèi)容，這樣可以讓其他人更清楚的了解整件事的前因后果。

因為擔心網(wǎng)絡暴力和一些不好的評論，當事人要求匿名。

當然，我尊重他們的要求。下面我會用“工程師老甲”和“初級工程師張三”來指代他們。

線上會談經(jīng)過

@Dave

感謝來到這次線上會談，再次感謝你們的勇氣和無私。如果可以的話我會 @ 特定的人來向他提問，他可以通過評論來回復，如果有什么問題你不想回答的話，我們就直接跳過。

@Dave 問 “初級工程師張三”：

首先得問一下你現(xiàn)在還好嗎，希望你從那件事情發(fā)生后到現(xiàn)在已經(jīng)平靜下來了。你可以從你的角度簡要描述一下當時發(fā)生了什么嗎？

@張三：

好的。

首先我得強調一下，我已經(jīng)吸取了深刻的教訓。我當時看到你提交的遠程代碼執(zhí)行的漏洞很驚訝，因為我認為我們現(xiàn)在用的框架或者防火墻應該可以識別并阻止它。

8 月份的時候，我完成了我作為應用部署 IT 專業(yè)人員的培訓，接著從 11 月份才開始在公司里從事安全相關的事情。因為當時別人問我有沒有興趣去管理一下 bug 賞金計劃，我就答應了。因為新冠疫情的爆發(fā)和隨之而來的節(jié)假日，我們公司人手不足，就有同事問我能不能幫忙回復一下 bug 賞金計劃的郵件，如果我懂郵件里的 bug 的話，看看能不能驗證一下那些 bug。因為我很想幫上忙所以就很愉快地答應了，而且也因為得到別人的賞識感到很高興。

當我在你的郵件里讀到“遠程代碼執(zhí)行”的時候，我以為那只是能執(zhí)行一下計算器或者留一張黑客組織圖片的這種小把戲。我根本沒有意識到它可以對操作系統(tǒng)造成任何實質性的破壞。然后我 Google 了一下來看看這個漏洞是不是像你描述的那樣嚴重。接著我從 Google 出來的頁面里復制了幾條可能會造成破壞的命令去執(zhí)行，因為我覺得我們的框架或者防火墻會去阻止它的。最后我發(fā)現(xiàn)了 rm -rf *這條命令，當我意識到壞事了的時候，一切都晚了，我嚇壞了。幾分鐘后，我鼓起勇氣跟同事說了剛剛發(fā)生的事情，問他能不能幫我一起處理一下。我真的很抱歉，我已經(jīng)從中吸取了教訓，以后我會在我操作之前多問問同事。這也是我為什么準備來做這次會談，我希望其他的初級工程師也可以從我的事故中學到教訓，不要再犯同樣的錯誤。

@Dave：

非常感謝張三真誠地跟我們分享他的事故。

@Dave 問 “工程師老甲”：

老甲，你可以從你的角度來聊聊事情的經(jīng)過以及你的第一反應是什么嗎？

@老甲：

好的。

我們不該在這件事上把他單獨推出來。實話實說，當我問他能不能幫忙管理一下 bug 賞金計劃的時候，他立馬就答應了。但老實說，我們每個人在年輕的時候接受一份任務的時候都是很開心的。所以我想保護他，我至少要承擔 50% 的責任。

回到那個問題：當他跑來跟我說那個遠程代碼執(zhí)行的漏洞的時候，我們立即明確了這是一個安全事故并且要重視起來。接著我排查了一下我們的系統(tǒng)，發(fā)現(xiàn)我們的 web 應用已經(jīng)不工作了。然后我 ssh 到我們的服務器，發(fā)現(xiàn)整個應用的目錄都空了，數(shù)據(jù)全被刪除了。因為我們已經(jīng)很久沒有給這個系統(tǒng)導入備份了，所以我們這次導入要花很長時間。然后我讓同事去看看備份，我來回復你郵件，告訴你我們對你提的漏洞很重視，已經(jīng)著手在處理了。

我同事驚訝地發(fā)現(xiàn)備份是幾周前的。我們接著一起看了一下系統(tǒng)和備份，一開始感覺是驚訝，接著是絕望。然后我們又看了 cronjob 的配置，發(fā)現(xiàn)是配錯了，本來應該是每 3 天跑一次，結果配置成了每3個月跑一次。震驚！最后我們丟了幾個星期的數(shù)據(jù)。不幸中的萬幸是，這是我們不太重要的業(yè)務。我們在那天學到了很多，我們已經(jīng)在內(nèi)部討論如何避免這種過失不再發(fā)生。

我們是一個有超過 400 名員工的公司，所以想把我們的業(yè)務拿去測試它的安全性。我們在論壇里聽說了 bug 賞金計劃，當時覺得這個計劃比我們自己組建一支安全隊伍要更好，所以就參與了這個計劃。但是現(xiàn)在我們覺得，自己不組建一支安全隊伍可能還是不行，至少得有人熟悉這方面的問題。因為上面的那個事故，我們會在內(nèi)部再討論一下這個問題。

不掩飾這個故障對我來說很重要，這也是為什么我們可以和你開誠布公地討論這個問題。

另外，我們的開發(fā)團隊也確認并修復了這個 bug，我們網(wǎng)站現(xiàn)在更加安全了。我要感謝你促成了這次訪談，我相信其他人會從我們的事故中學到一些東西。

@Dave

我從心底里感謝你們兩位開誠布公地和我討論這個問題。如果有什么可以幫你的，請隨時給我發(fā)郵件。希望你和你的家人快樂。

最后感想

我曾幻想著那個故障沒有發(fā)生。但是，我們都是普通人，因為我們想幫上忙，所以難免會犯重大的錯。我們每個人都曾在某個節(jié)點犯了這樣那樣地錯。只要我們從中學到了東西，我們就會一直變得更好。

希望這兩位工程師的分享，可以幫助其他人預防此類錯誤。

責任編輯：xj

原文標題：我在服務器上執(zhí)行了 rm -rf *

文章出處：【微信公眾號：Linux愛好者】歡迎添加關注！文章轉載請注明出處。