Threat Modelling and Beyond for Cisco ACI · Threat Modelling and Beyond for Cisco ACI Frank Block...

transcript

Threat Modelling and Beyond for Cisco ACI

Frank Block – fblock@ernw.deJan Harrie – jharrie@ernw.de

Motivation

Several customers already approaching this new technology, but yet no public security research available.

#whoami - Jan

o Security Consultant @ERNW GmbH

o Former Security Analyst/Pentester/WebApp-Monkey

o M.Sc. IT-Security TU Darmstadt

o Interests:

o Orchestration Solution,

o Red Teaming/Social Engineering

#whoami - Frank

o Security Researcher @ERNW Research GmbH

o Pentester/Incident Analyst

o Interests:

o Hacking stuff and hunting Hackers

o Memory Forensics

o Party tonight!

Agenda

o ACI WTF!?

o Threat Modelling Cisco ACI

o Deep-Dive into Various Threats

o Technical Attack Surface Overview

Cisco ACI

A short introduction

Physical Layout 1/2

Physical Layout 2/2

Background Knowledge

o Systems

o Cisco APIC Release 4.0(3d) in Feb-19

o Cisco NX-OS Release 14.0(3) in Feb-19

o Market Challenger to VMware NSX

o SDN Solution based on VXLAN

o Application Centric Infrastructure

o Micro Segmentation

VXLAN – RFC 7348

Source: [RFC7348]

Certificates

U.S. Department of Defense – Unified Capabilities Approved Products List (DoD UC APL)

Architecture (1/2)

o Spine-Leaf Hierarchyo Application Policy Infrastructure Controller

(APIC)o Overlay Transport Virtualization (OTV)o Virtual Tunneling Endpoint (VTEP)o Endpoint Groups (EPGs)o Edge devices use IS-ISo Fosters zero-trust model implementationo Inter-EPGs communication whitelisted by

contracts (L3/L4)

Architecture (2/2)

o Traffic whitelisting stateless on Layer 3-4, integration external applications possible (L4-7)

o Authentication, Authorization, and Accounting (AAA) over RBAC with LDAP and Microsoft Active Directory, RADIUS, and TACACS+

o APIC maintains current state of fabric and offers REST API

o ACI Virtual Machine Manager (VMM) with ACI Virtual Edge (AVE)

o VXLAN between ESXi/KVM and leaf switch

Source: [cfilter]

Threat Modelling

Get your hands dirty!

Short recap STRIDE

o Threat model initially developed by Microsoft in the course of their SDLC initiative (~ 2003)

o STRIDE was developed in a specific context (application security) and some of elements might not be easily applicable to infrastructure projects (networks, cloud et al.)

Source: [as09,ms,synops]

Short recap STRIDE

o Threat model initially developed by Microsoft in the course of their SDLC initiative (~ 2003)

o STRIDE was developed in a specific context (application security) and some of elements might not be easily applicable to infrastructure projects (networks, cloud et al.)

o Some categories might not be overly suited for network context or might have a different meaning (for example “tamper ng”).

o etwork secur ty has some spec f c threats (e.g. “sn ff ng”).

o While similar when it comes to overall direction, individual categories might differ as for risk profile, impact, attack methods etc. (Denial-of-Service) Source: [as09,ms,synops]

Potential Sources for Network-Related Threats / Standards

o ISO 27000 series, namely ISO 27033-3

o IETF – RFC 4778 Current Operational Security Practices in Internet Service Provider Environments

o NIST Special Publications

o Others, with more specific contexto GSMA documents

o Book: Router Security Strategies from Cisco

o nd so on …

Source: [as09,ms,synops]

Suggested Adaptions of STRIDE Model, Based on the Above Sources

o Rewording of two existing categories in order to better reflect network security landscapeo Tampering →Interception

o Elevation of privilege →Unauthorized access

o Removal of one categoryo Repudiation (not really suited for network context)

o Addition of one categoryo Sniffing (as this one of main threats on nw level)

h s eads o…

STRIDE Category

DescriptionApplicable

on NW infra layer

Overall Rating

Suggested Approach

Result

Spoofing Provide false identity x medium preserve Spoofing

Tampering Malicious modification of data x high Interception Interception

RepudiationMake sure action was performed by certain party - - remove -

Info disclosure (Sensitive) info is exposed x medium preserve Info disclosure

Denial of service x high preserve Denial of service

Elevation of priv. Get unintended level of access x high Unauthorized access

add Sniffing

Threat Collection

1. VXLAN-Overlay Breakout

2. ACI Filter Mechanism Bypass

3. Switch Spoofing

4. VTEP Spoofing

5. APIC Spoofing

6. EPG Misconfiguration

7. Account Compromise

8. APIC Compromise

9. Switch Compromise

Threat Collection

1. VXLAN-Overlay Breakout

2. ACI Filter Mechanism Bypass

3. Switch Spoofing

4. VTEP Spoofing

5. APIC Spoofing

6. EPG Misconfiguration

7. Account Compromise

8. APIC Compromise

9. Switch Compromise

ACI Filter Mechanism Bypass

o Scenario

o ar ous f lter mechan sms based on …

o VXLAN

o External appliance

o Attacker can bypass filter

o Threat

o Unauthorized access

o Information disclosure

o Counter Measure

o Switch hardening (as far as possible)

o Establishing multiple fabrics

o Network monitoring and anomaly detection

VTEP Spoofing

o Scenarioo Attacker spoofs VTEP and gets access to VXLAN overlay

o Threato Unauthorized Accesso Denial of Serviceo Interception

o Counter Measureo Switch hardening by

o First-Hop-Securityo Dedicated Control Plane Networko Data Plane Securityo Physical isolation of Switches

o Network monitoring and anomaly detection

Switch Compromise

o Scenarioo Attacker compromise Spine-/Leaf-Switch and gets full accesso Manipulation of Control Plane, e.g., Endpoint-Discovery

o Threato Unauthorized Accesso Denial of Serviceo Information Disclosureo Interception

o Counter Measureo Restricted management accesso Classical nw segmentation for sensitive systemso Network monitoring and anomaly detection

Technical Attack Surface Overview

Attack Vectors on the APIC

Source: [dp40]

Management Interface

o Separate Out-of-Band Management Interface on the APIC.

o For IPv4, most TCP ports are blocked, except:

o 22/tcp and 443/tcp

o When looking at IPv6 link-local, the firewall has/had no restrictions (CVE-2019-1690 - Fixed with Version 4.2(0.21c) ):

o 22/tcp, 443/tcp, 12569/tcp and 30865/tcp

isshd – 22/tcp

o “ pec al” H aemon (2.9 vs. 813 )

o Puts connecting user in a chroot environment.

-xinetd-+-isshd---isshd---loginshell---scriptcontainer

o pec al account “adm n” s offered for adm n strat ve tasks.

o This account is not part of the /etc/passwd, but seems only be

made available via a special PAM module.

isshd – 22/tcp

o The module references a hardcoded file, which contains the adm n user’s password hash and wh ch s probably used for the authentication process.

o In general, the SSH service offers a stripped down local access and old school Cisco configuration.o conf t via uWSGI/HTTP (running as root)

POST /decoy/exec/help.cli =>

generated 1211 bytes in 18 msecs

(HTTP/1.1 200)

POST /decoy/exec/cmd.cli =>

generated 0 bytes in 42

msecs (HTTP/1.1 200)

POST /decoy/exec/tab.cli =>

generated 1705 bytes in 1719

Process Process-29:

Traceback (most recent call last):

"/usr/lib/python2.7/multiprocessing/process.py",

line 258, in _bootstrap

self.run()

"/usr/lib/python2.7/multiprocessing/process.py",

line 114, in run

self._target(*self._args, **self._kwargs)

"/mgmt/opt/controller/decoy/apps/execserver/execapp

.py", line 75, in execCommand

raise ex

ValueError: Error: Invalid argument

'autopwn_everything '. Please check syntax in

command reference guide

POST /decoy/exec/cmd.cli => generated 0 bytes in 46

Some Challenge Response Functionality

o /data/challenge.plugin contains a changing string.

o This path is used by the PAM module, mentioned for isshd.

o The library is also loaded by isshd itself and the nginx and might be used to allow some special local/web access.

Nginx – 443/tcp

o Serves the APIC management GUI.

o Moreover, several paths are configured that are forwarded to locally listening HTTP and uWSGI endpoints.

o Most of them, including the nginx itself, are running as root.

REST API

o The APIC implements a REST API, accessible via /api.

o The old school Cisco configuration via SSH and the Management GUI are both based on it.

o The GUI offers functionality to trace requests and responses being made by the GUI.

Device Packages

o Enables easy integration of L4-7 devices.

o A .zip file containing an XML file and Python scripts.

o No signatures/signing.

o Once uploaded, the archive is extracted and the Python script executed.

o So far, only an authenticated user can upload a new device package.

Appliance Director – 12569/tcp

o Seems like a custom service which uses TLS with client certificates.

o Yet no communication observed.

o But at least, also runs as root.

csync2 – 30865/tcp

o Open source software https://github.com/LINBIT/csync2

o Essentially rsync for multiple hosts.

o Simple protocol, which transfers the password as-is for authentication.

o The service is configured with a long password.

csync2 Protocol

Technical Attack Surface Overview

A quick look to the Leaf Switches

Source: [dp40]

OpFlex Control Protocol

o In order to be able to push policies (basically ACI configuration) to Leaf Switches, the OpFlex Control Protocol is used.

o The protocol is based on JSON and supports several RPC methods (JSON-RPC version 1.0).

o There is an IETF Draft from April 2016 which, based on first comparisons, seems to be conform with the actual implementation.

OpFlex Control Protocol

{“ d":["echo",40],"method":"echo","params":[12345678]}.{"id":["echo",40],"result":[12345678]}.

{"id":["send_identity",1],"method":"send_identity", ...}{"id":["send_identity",1],"result":{"name":"10.0.0.1:8009",

"my_role":["endpoint_registry","policy_repository"], …"peers":[{"role":[…],"connect v ty_ nfo":"10.0.0.1:8009"},

{"role":[…],"connect v ty_ nfo":"10.0.0.2:8009"}]}}

{… "method": "policy_update", "params": [… }

IETF Draft – Security Considerations

OpFlex Service

o As far as we have seen, services speaking OpFlex are using TLS.

o The service is accessible in the management network.

o And again, runs as root.

Next Steps

o Attacking/Fuzzing the Protocols.

o Having a closer look at the challenge response functionality!

o Getting our hands on some client certificates (for the Appliance Director).

o Investigating at least the local services for the nginx.

o Assessment of the REST API.

o And, getting remote root might be nice ;-)

Security Considerations

o Restrict Access to the management interface.

o Network monitoring and anomaly detection.

o Watch out for new Updates.

o Do not import Device Packages from Spam/4chan/stackoverflow !

www.ernw.de

www.insinuator.net

Thanks for your Attention!

Open Questions?

fblock@ernw.de

jharrie@ernw.de

@WEareTROOPERS

@NodyTweet

Sources

[RFC7348] https://tools.ietf.org/html/rfc7348

[as09] https://cloudblogs.microsoft.com/microsoftsecure/2009/08/27/the-threats-to-our-products/

[ms] https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=

cs.20)

[synops] https://www.synopsys.com/blogs/software-security/wp-content/uploads/2015/08/threat-modeling-glossary-diagram.jpg

[dp40] https://docplayer.net/docs-images/40/21587129/images/15-0.jpg

[cfilter] https://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter/aci/apic/white_papers/Cisco_IT_ACI_Design.docx/_jcr_content/renditions/Cisco_IT_ACI_Design_13.jpg

Threat Modelling and Beyond for Cisco ACI · Threat Modelling and Beyond for Cisco ACI Frank Block...

Documents