我在服务器上执行了 rm -rf *

前段时间，我在一个非公开的 Bug 赏金项目里发现了一个严重的漏洞，这个漏洞可以允许远程执行代码。在我提交漏洞报告的几个小时后，我收到了第一封邮件回复，他们说会尽快确认漏洞然后再和我联系。到目前为止一切都是正常的。

但是第二封邮件的回复揭开了整个惊心动魄的故事，就像多米诺骨牌效应一样把更多的问题暴露了出来。

关于这个事故，社区反应是这样的：

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

线上会谈前的邮件往来

我找出了这个远程代码执行的漏洞，并且在报告里用 5 个命令来演示 POC(Proof Of Concept)。因为我不想在 POC 里造成任何破坏，所以我决定用下面这几个命令：

1. uname -a
2. id
3. df -h
4. ls -alF
5. cat /etc/hosts

第 1 封邮件回复说他们会认真排查报告里说到的问题。

但是第 2 封邮件的回复是这样的

亲爱的 Dave，

感谢你的报告和 POC。因为我们现在人手不足，所以只能让我们的初级工程师来验证你提到的远程代码执行漏洞。但是他在验证的过程中尝试用命令 rm -rf * 来看 web 的用户是否能造成破坏。不幸的是，因为这个命令他把所有东西都删了。我们会尝试尽快恢复数据来继续漏洞修复，当我们的问题解决的时候我们会再让你帮忙验证漏洞修复的情况。

我回复他们我随时可以来帮助他们解决问题。

接着他们第 3 封邮件的回复是这样的：

亲爱的 Dave，

跟你同步一下进度。我们已经导入了备份。但是不幸的是，我们发现本来预计的是通过 cronjob 每 3 天备份一次，但是无意中配置成了每3个月备份一次，这导致我们没有办法恢复这几个星期的数据了。我们现在已经修复了这个问题，未来也会更加注重在多个工程师之间做结对编程和代码审查。

最后第 4 封邮件的回复是这样的：

亲爱的 Dave，

感谢你耐心等候。我们已经优化了备份的流程，也尽可能地导入最新的备份。同时我们开发部门的同事也修复了你报告里提到的漏洞，现在已经热更放了出去。你现在可以再帮忙验证一下这个漏洞是否真的被修复了吗？

确认漏洞修复并且提出线上会谈

我确认了他们的漏洞已经修复了，接着向他们提出要不要进行一次线上会谈来聊聊这个案例，因为这种事情很容易发生在初学者身上，一起聊一聊的话可以分享这些踩过的坑，来防止其他人再犯同样的错误。让我很惊喜的是他们答应了。事实证明，无论是他们还是他们的公司都不是徒有虚名。

当事人愿意出来解释前因后果

首先，我要借这个机会来感谢两位当事人工程师愿意来和我线上会谈，并同意让我引用之前沟通的内容，这样可以让其他人更清楚的了解整件事的前因后果。

因为担心网络暴力和一些不好的评论，当事人要求匿名。

当然，我尊重他们的要求。下面我会用“工程师老甲”和“初级工程师张三”来指代他们。

线上会谈经过

@Dave

感谢来到这次线上会谈，再次感谢你们的勇气和无私。如果可以的话我会 @ 特定的人来向他提问，他可以通过评论来回复，如果有什么问题你不想回答的话，我们就直接跳过。

@Dave 问 “初级工程师张三”：

首先得问一下你现在还好吗，希望你从那件事情发生后到现在已经平静下来了。你可以从你的角度简要描述一下当时发生了什么吗？

@张三：

好的。

首先我得强调一下，我已经吸取了深刻的教训。我当时看到你提交的远程代码执行的漏洞很惊讶，因为我认为我们现在用的框架或者防火墙应该可以识别并阻止它。

8 月份的时候，我完成了我作为应用部署 IT 专业人员的培训，接着从 11 月份才开始在公司里从事安全相关的事情。因为当时别人问我有没有兴趣去管理一下 bug 赏金计划，我就答应了。因为新冠疫情的爆发和随之而来的节假日，我们公司人手不足，就有同事问我能不能帮忙回复一下 bug 赏金计划的邮件，如果我懂邮件里的 bug 的话，看看能不能验证一下那些 bug。因为我很想帮上忙所以就很愉快地答应了，而且也因为得到别人的赏识感到很高兴。

当我在你的邮件里读到“远程代码执行”的时候，我以为那只是能执行一下计算器或者留一张黑客组织图片的这种小把戏。我根本没有意识到它可以对操作系统造成任何实质性的破坏。然后我 Google 了一下来看看这个漏洞是不是像你描述的那样严重。接着我从 Google 出来的页面里复制了几条可能会造成破坏的命令去执行，因为我觉得我们的框架或者防火墙会去阻止它的。最后我发现了 rm -rf *这条命令，当我意识到坏事了的时候，一切都晚了，我吓坏了。几分钟后，我鼓起勇气跟同事说了刚刚发生的事情，问他能不能帮我一起处理一下。我真的很抱歉，我已经从中吸取了教训，以后我会在我操作之前多问问同事。这也是我为什么准备来做这次会谈，我希望其他的初级工程师也可以从我的事故中学到教训，不要再犯同样的错误。

@Dave：

非常感谢张三真诚地跟我们分享他的事故。

@Dave 问 “工程师老甲”：

老甲，你可以从你的角度来聊聊事情的经过以及你的第一反应是什么吗？

@老甲：

好的。

我们不该在这件事上把他单独推出来。实话实说，当我问他能不能帮忙管理一下 bug 赏金计划的时候，他立马就答应了。但老实说，我们每个人在年轻的时候接受一份任务的时候都是很开心的。所以我想保护他，我至少要承担 50% 的责任。

回到那个问题：当他跑来跟我说那个远程代码执行的漏洞的时候，我们立即明确了这是一个安全事故并且要重视起来。接着我排查了一下我们的系统，发现我们的 web 应用已经不工作了。然后我 ssh 到我们的服务器，发现整个应用的目录都空了，数据全被删除了。因为我们已经很久没有给这个系统导入备份了，所以我们这次导入要花很长时间。然后我让同事去看看备份，我来回复你邮件，告诉你我们对你提的漏洞很重视，已经着手在处理了。

我同事惊讶地发现备份是几周前的。我们接着一起看了一下系统和备份，一开始感觉是惊讶，接着是绝望。然后我们又看了 cronjob 的配置，发现是配错了，本来应该是每 3 天跑一次，结果配置成了每3个月跑一次。震惊！最后我们丢了几个星期的数据。不幸中的万幸是，这是我们不太重要的业务。我们在那天学到了很多，我们已经在内部讨论如何避免这种过失不再发生。

我们是一个有超过 400 名员工的公司，所以想把我们的业务拿去测试它的安全性。我们在论坛里听说了 bug 赏金计划，当时觉得这个计划比我们自己组建一支安全队伍要更好，所以就参与了这个计划。但是现在我们觉得，自己不组建一支安全队伍可能还是不行，至少得有人熟悉这方面的问题。因为上面的那个事故，我们会在内部再讨论一下这个问题。

不掩饰这个故障对我来说很重要，这也是为什么我们可以和你开诚布公地讨论这个问题。

另外，我们的开发团队也确认并修复了这个 bug，我们网站现在更加安全了。我要感谢你促成了这次访谈，我相信其他人会从我们的事故中学到一些东西。

@Dave

我从心底里感谢你们两位开诚布公地和我讨论这个问题。如果有什么可以帮你的，请随时给我发邮件。希望你和你的家人快乐。

最后感想

我曾幻想着那个故障没有发生。但是，我们都是普通人，因为我们想帮上忙，所以难免会犯重大的错。我们每个人都曾在某个节点犯了这样那样地错。只要我们从中学到了东西，我们就会一直变得更好。

希望这两位工程师的分享，可以帮助其他人预防此类错误。