想象一下，如果有个建筑工程师突然发现，我们盖楼用的钉子随时都会断裂，而几乎每栋楼都使用了这样的钉子时，会是怎样的场面？在过去的一个月里，软件行业就经历了一场这样的危机。
撰文"索菲·布什威克（Sophie Bushwick）
编译|郑昱虹
审校|王昱
2021年11月24日，Apache软件基金会收到了一封邮件，发件人是阿里云安全团队的程序员Chen Zhaojun。他在邮件中指出，由Apache维护的一个软件存在重大的安全漏洞，黑客可以利用这个漏洞，对他人的电脑进行远程操控。
这个软件是Log4J，它是一个用于记录日志的JAVA库。因为其开源的性质，Log4J遍布整个软件行业，被广泛用于记录用户名、密码和信用卡交易等细节。所以苹果iCloud、亚马逊云服务、Minecraft（我的世界）游戏、推特等商业公司，以及一些政府机构，全部受到了这个之后被命名为“Log4Shell”的漏洞的影响。
因此，12月9日Log4Shell面向社会公布时，整个软件行业都为之震动。由于危害大且波及范围广，Apache对这个漏洞给出了10分的CVSS（通用漏洞评分系统）评分，而10分是表示“严重”的最高分。
自发现该漏洞以来，网络安全工程师争分夺秒地保护应用程序、服务、基础设施和物联网设备，但犯罪分子已经在利用这个漏洞了。部分Minecraft用户受到了勒索软件攻击，微软检测到了下载和运行“挖矿”软件、窃取身份信息等行为，比利时国防部因受到攻击而关闭了部分计算机网络……
“对网络罪犯来说，这就像是提前到来的圣诞节礼物。他们没有底线，限制他们的只有他们自己的技术水平。”前白宫首席信息官、网络安全咨询公司Fortalice Solutions的首席执行官特蕾莎·佩顿（Theresa Payton）说。
在Log4J维护者团队几乎无偿的紧急工作下，Apache于2021年12月6日针对Log4Shell进行了修复，但没能完全解决问题，又在12月13日、17日和27日分别针对新发现的问题发布了新版本。但是，这场风波造成的影响很可能仍未平息。
Log4J作为互联网基础设施的一个关键组成部分，一些数百万乃至数十亿体量的公司依赖它获利，然而它只是一个志愿者建立的，并且很大程度上是免费运行的项目。如果进展顺利，开源就是合作的胜利；而一旦出了问题，就会产生深远的危险。这次的危机揭示了开源软件的困境，暴露了整个互联网行业的供应链安全问题。
去年12月15日，《科学美国人》发布了对佩顿的采访，她谈到了Log4J的功能、黑客将如何利用漏洞Log4Shell、以及如何修复这个漏洞。以下是经过编辑的采访文字记录。
Log4J是什么？它被用在什么地方？
技术和网络安全团队需要“日志”功能。日志可以用于审计追踪（audit trails），比如出于监管考虑，在发生勒索软件事件时进行取证。而Log4J就是一个用于记录日志的Java程序。它可以记录任何数量的、任何类型的事件，比如某人使用某种类型的信用卡，或某人今天登录了，等等。
但是，Log4J存在一个严重的安全漏洞。
这个漏洞的存在，使得有人可以向日志中添加指令，让日志执行任何操作。研究人员在12月初发现了这个漏洞（Apache得知这个漏洞的时间是11月24日，但是向公众公开在12月9日），谢天谢地。大体来说，这个漏洞允许攻击者在未经身份验证的情况下，通过远程代码访问服务器。他们可以发送指令、执行指令，并且可能完全不被发现。
已经有攻击者利用Log4J的漏洞，在机器的主人不知情的情况下，给一些机器安装了挖掘加密货币的恶意软件。回想一下物联网被Mirai僵尸网络占领的经历，Mirai僵尸网络看起来也在试图利用物联网。
网络罪犯还可以利用这个漏洞做什么？
网络罪犯可以在日志中添加一条指令：“当记录用户的登录凭据时，也将它们发送到我这里。”这样一来他们就能获取用户的登录凭据。他们可以创建个性化的指令，对日志进行操控。
日志记录着几乎所有的内容，比如登录信息、信用卡信息、支付信息。所以就看开发人员决定如何利用日志的特性和功能了——日志中有什么类型的数据，以及这些数据是否被加密。
问题是，对日志有没有保护？是否有任何方式监控日志本身是否有异常行为？如果一个组织不去主动寻找异常行为，他们就不会注意到用户名和密码不仅被记录在日志中，也被发送到了其他地方。
在安全团队争分夺秒地寻找漏洞、打补丁、修复、观察、记录并试图解决问题的时候，网络罪犯则利用这些漏洞，分享信息并制造不同的攻击。很有可能会出现一种犯罪软件服务，供网络罪犯和非技术人员使用。
对于不从事网络安全工作，但日常使用应用程序和服务的普通人来说，这意味着什么？
普通人的身份可能会被盗窃。你尝试登录某个网站的时候，可能会发现他们暂停服务了，那他们可能正在处理这个问题。比如你可能无法联系政府机构核实退款或缴税，因为有人通过Log4J的漏洞损害了这些功能。
现在还很难说事态会如何发展，因为我们尚未完全理解这个问题。这个漏洞可能会影响很长时间，并不是说“周末打好所有补丁，然后我们就可以回家过圣诞节了”。
如何化解这次的危机？
类比一下，房屋、大厦、桥梁等建筑物上都用到了某种钉子。如果有人说：“我们刚刚意识到，这种钉子存在弱点，它们可能会随时失效”，不过建筑使用的钉子有很多种，我们必须弄清楚“这种”钉子都用在了哪里，并要求建筑公司在钉子失效之前找到并更换它们。
大公司和大量互联网基础设施现在必须在他们的系统中排查Log4J。由于代码通常没有一幅详细的蓝图，所以要想准确地知道其中都在哪里用到了某个日志功能，无异于大海捞针。
通常，当我们发现安全漏洞时，网络安全工程师可以全权负责修复，但这次的漏洞不同，它是整个供应链的问题：很多人在代码中使用了开源的、第三方提供的和离岸开发的系统，而所有的系统都有可能使用了Log4J。
以某种物联网设备为例（如Alexa或Google Home），它的供应链可能涉及10到50至60家不同的公司，分别负责固件、操作系统和应用程序的开发。所以仅仅为一款产品修复漏洞，就可能是一项极其艰巨的任务。
我们能从这次的漏洞中学到什么？
2020年末我们遭遇了SolarWinds的供应链事故，那时很多人觉得自己不使用SolarWinds就没事。但事实上，只要处在一个使用了SolarWinds的生态中就存在风险，你需要向内部、离岸、近岸和外包的开发者了解他们是否使用了SolarWinds的软件生成的清单。
我们通过惨痛的教训明白了，编译软件和对软件进行质量保证，是非常复杂和困难的事情，并且我们并非每次都能跟进其中的重要细节。
我们可以从这些事故中学到的是，我们的供应链存在、并且会继续存在弱点，所以这不会是最后一次出问题。当问题出现时，你需要知道该把哪些人召集到一起，评估这个问题对你们来说是非同小可的，还是无足轻重的。
从业者还需要思考的是，你们建立了哪些自动防故障装置？例如，如果攻击者在你打补丁之前就利用了你的日志和日志中的信息，你能发现他们的踪迹吗？
这些都是我学到的教训，而且都是艰难的教训。我是说，如果这些问题容易解决，企业和政府早就解决了，不过纸上谈兵容易，在实际操作中却很难。
原文链接：
https：//www.scientificamerican.com/article/the-log4j-software-flaw-is-christmas-come-early-for-cybercriminals/
参考链接：
https：//www.bloomberg.com/news/articles/2021-12-13/how-apache-raced-to-fix-a-potentially-disastrous-software-flaw
https：//theconversation.com/what-is-log4j-a-cybersecurity-expert-explains-the-latest-internet-vulnerability-how-bad-it-is-and-whats-at-stake-173896
https：//mp.weixin.qq.com/s/Yq9k1eBquz3mM1sCinneiA
https：//vop.jd.com/notice/cc0f8162-1927-45bb-9828-3a00cf59c1dc
https：//nvd.nist.gov/vuln/detail/CVE-2021-44228
https：//www.crn.com/news/security/ransomware-gang-hijacking-log4j-bug-to-hit-minecraft-servers
https：//venturebeat.com/2021/12/12/microsoft-log4j-exploits-extend-past-crypto-mining-to-outright-theft/
https：//www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/
https：//logging.apache.org/log4j/2.x/changes-report.html
https：//logging.apache.org/log4j/2.x/security.html
https：//www.dynatrace.com/news/blog/what-is-log4shell/
https：//www.technologyreview.com/2021/12/17/1042692/log4j-internet-open-source-hacking/
