LWN：怎样防范强大黑客组织攻击软件更新系统？

点击上方蓝色字关注我们~

Protecting update systems from nation-state attackers

By Jonathan Corbet
July 24, 2019

---

OSS Japan

要想让系统保持安全，就必须经常及时进行安全更新。不过，假如更新机制本身也被攻击者控制的话，那就完全没法保证系统安全了。在2019 Open Source Summit Japan会议上，Justin Cappos介绍了Uptane——用于汽车应用场景下的自动更新机制，据他介绍哪怕攻击者拥有一国的全部资源，也无法危害系统更新。不少汽车厂商表示赞同。

Cappos介绍说，已经有很多公司都碰到过对他们的自动更新系统的攻击了。其实这种事发生的特别频繁，通常这些攻击方都有一些政府背景，他列举了几例据称是朝鲜和俄罗斯进行的黑客行动。Stuxnet attack（震网病毒，又称超级工厂病毒）也攻破了Windows的更新服务机制。拥有国家力量的攻击者可以执行非常复杂的攻击行动。如果你期望能抵御这种类型的攻击的话，那你面对的可能是这种情况：一队专职攻击的网络专家，他们都是世界上最顶尖的黑客，拥有大量的资源和力量，专门攻击你一个公司。这种场景非常可怕。

还有更可怕的，如果攻击是针对现代汽车工业基础软件的话。攻击者就可能拿到权限来在汽车上安装新软件来把环境弄的一团糟，甚至进而导致大规模的人员伤亡。因此，我们都非常有必要让我们的车能抵御哪怕是复杂到极致的入侵方式。

Protecting update systems

通常有4类方法来应对这些攻击。Prevention，预防，很显然目的是让攻击非常难以进行；Detection，检测，则是希望能尽快在攻击得逞时得到警报。汽车行业目前已经对这两类方式很关注了，不过还有很大改进空间。

 第三类就是把风险转嫁给其他人，或者说“买保险并且听从专家的所有意见规章”。转移风险在汽车行业里不是一个好的选择，因为一次风险可能就能引入10亿美元甚至更高的代价。他以菲亚特克莱斯勒的例子来说，一次排放量作弊，就让他们赔偿了30亿美元，甚至这个过程中还没有人员伤亡，假如还引起了人命呢？没有保险公司会愿意承担这么高金额的保险。

最后一类，就是mitigation——减少一次攻击所能带来的负面影响，甚至最好能降到接近无影响的程度。这就是Uptane出现的原因。其他的更新系统在被人攻破之后“放弃了一切抵抗”。而Uptane则仍能守住底线，甚至能让已经攻入系统的黑客也无法在系统里加载恶意软件。

 

传统解决方案里，没有提供这方面的抵抗手段。例如，有一个常见的方案是让目标系统来对服务器目录通过TLS认证，通过之后才能接受从它而来的更新版本。不过这种情况下，private key秘钥本身已经在服务器上了。如果这台server被攻破，那么这个安全机制就失去效果了。

另一个常见的方案是对更新的软件本身进行签名，并且让服务器也不知道这个签名秘钥。这就需要让目标系统信任这个秘钥，因为今后所有的更新版本都需要使用它。也意味着这个秘钥会存在于开发商的编译服务器里。如果攻击者进入这个系统，那么就能把恶意更新也进行签名。在过去，某些主流Linux发行版的发布流程里面已经出现过这样的攻击了。

2008年，Cappos创建了The Update Framework (TUF)来解决云服务里的软件分发问题。现在已经在广泛使用了，并被Cloud-Native Computing Foundation所采用。TUF基于一个假设，认为黑客总能进入服务器并且偷到秘钥，它的目的就是希望能在这种情况下减少黑客能造成的损害。TUF的核心观点就是分离出不同的责任人。例如，一个责任人是证明给出的软件更新版本是可靠的，这就需要开发者和测试人员能对它用秘钥签名。不过这跟通知客户端去接收更新是不相干的，也就是还需要另一个发布责任人用他特有的秘钥来进行签名发布。包括秘钥的撤销也是另一个跟其他人不重合的角色。所有这些需要用到的秘钥都不会、也不应该存放在同一个地方，所以攻击者不得不攻破所有相关系统，拿到所有秘钥，才能进行下一步。

TUF还有一个强大的秘钥作废机制。Cappos认为像PGP这些系统上的秘钥作废机制完全是一团乱。设计的时候就没有考虑清楚最终的应用场景。包括X.509的"bolted on"作废机制也是一样。TUF则不同，它设计时就考虑了秘钥作废的功能。它的“implicit revocation”机制能够做到任何一个秘钥如果在指定的刷新时长内没有刷新过的话，就把秘钥收回。它也支持回收指定的秘钥，这样可以在已知某个秘钥泄露之后马上撤销。

Uptane

不过TUF还是针对云上软件分发场景设计的。而汽车行业有些不同。因为想满足这些特定需求，他就创建了Uptane，作为对TUF在汽车应用场景下的改进。服务器端的代码是没有变化的。不过客户端的代码需要能在嵌入式小系统环境下运行，甚至没有办法跟更新服务器直接通信。典型汽车应用上有一个主客户端程序会从服务器下载软件更新版本，然后保存到本地存储空间里。而另一个附属的客户端程序则会从本地存储空间里获取更新，然后进行升级。

汽车的网络连接不一定是安全的。其实通常来说，攻击者很可能能对车内系统有完全的控制。他们可能通过汽车的网络链接，或者是仅仅插入OBD接口来控制汽车。这类攻击行为肯定有可能会发生，因此Uptane一开始就要考虑到这一点。

要想使用Update，可以先从汽车供应商现有的更新机制开始。创建一系列的更新类型，针对每一类都要指明所需要的秘钥的需求，例如指定需要供应商以及OEM的双方签名。车内的程序则会检验签名是否符合所需秘钥。

车内的程序分为“strong”和“weak”两类，只有strong类型的才能使用CPU的算力来完整验证更新包。Weak类型则只能进行一些初级验证，也就是说风险会更加大。Cappos认为哪怕攻击者已经控制了汽车的网络连接，系统仍然是足够健壮的，不会造成严重后果。服务器如果被攻破，可能会带来更大的一些风险，不过应该不可能导致人身伤亡了。唯一可能出现最严重后果的情形，就是当多个离线秘钥都被黑客获取到的情况。

Uptane有多种开源实现，目前也有多家汽车厂商强制要求装载Uptane系统，但是他无权公布具体厂商的名字。目前Uptane已经达到或超过所有关于更新方面的安全要求，以及不久后会公布的抵抗攻击的一些规章制度。关于Uptane，有一个标准化组织，由US Department of Homeland Security赞助，而不是由各家厂商赞助。此系统也经过了一系列的安全审计，Uptane已经被集成进in-toto（一个广泛采用的供应链安全机制，包括Debian, Arch Liux和reproducible builds project都已经包含）。

不久之后，预计美国公路上预计1/3的新车都会运行这部分代码。

Cappos结尾指出，不论他和其他安全工作者多么努力，总有人会使用一些不够安全的设计或者车厂产品，那仍是拿生命在冒险。攻击肯定会发生的，仅仅诉求监管方采取行动是肯定不够的。一有人员伤亡，就会有厂商不愿看到的大规模法律诉讼出现。Uptane这类系统就是希望能把这类情况消弭于无形中。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议上的修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～