关于java:我在服务器上执行了-rm-rf

1次阅读

共计 2898 个字符，预计需要花费 8 分钟才能阅读完成。

前段时间，我在一个非公开的 Bug 赏金我的项目里发现了一个重大的破绽，这个破绽能够容许近程执行代码。在我提交破绽报告的几个小时后，我收到了第一封邮件回复，他们说会尽快确认破绽而后再和我分割。到目前为止一切都是失常的。然而第二封邮件的回复开始了整个触目惊心的故事，就像多米诺骨牌效应一样把更多的问题裸露了进去。

社区对于这个故事的反馈是这样的：

https://twitter.com/secalert/…

我找出了这个近程代码执行的破绽，并且在报告里用 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