Attack Trees for Containers as a Service (CaaS)

On the heels of platform virtualization comes the proliferation of containers – compartmentalized applications aimed at achieving greater efficiency in packaging, delivering and managing applications. With platform-level virtualization adoption still maturing, the rise of app level virtualization and isolation over shared platform resources is already intriguing many dev shops who are looking in greater efficiencies around environment management and deployment. Security concerns are abound, particularly as the theme of true isolation and priv escalation haunt many early instances of containers. During this talk we’ll look at threat modeling vignettes based upon current implementations and industry use cases around Containers as a Service. We’ll explore viable threat patterns around deploying and using containers as well as current and evolving countermeasures for threat mitigation.

This talk will employ risk centric approaches to threat modeling around containers and tie in many of the more current threat and countermeasures covered from Docker15. The risk centric threat modeling approach will tie in well to security by design intents being fostered into evolving container related controls. This talk will not address in general the general precepts around threat modeling but rather dive into a few deployment scenarios around containers that have been analyzed for viable threat motives, supporting attack patterns, and effective countermeasure options for risk reduction.

Transcript

1. Attack Tree Vignettes for CaaS Attacking Containers as a service via risk centric threat models
2. 2 Primary Focus Secondary Focus Process for Attack Simulation & Threat Analysis
3. Outline • Why this talk matters (Significance) • Background & Use Cases (Inheritance & Topicality) • Threat Motives & Attack Vignette (Harms) • Countermeasures (Solvency)
4. Speaker • Author of ‘Risk Centric Threat Modeling’, Wiley 2015 • CEO, Founder of VerSprite, global security consulting firm (www.versprite.com) • 20 year background in dev, sys admin, network eng, architecture, security • OWASP ATL Chapter Leader • @t0nyuv • tonyuv@versprite.com
5. Significance Proliferation of Containerization
6. Container Proliferation Containers are not new. Rapid adoption is. Google, Amazon lead the way. 2B Containers launched weekly at Google. Technology change ushers in changes to attack patterns
7. Growing Adoption, Shifting Attack Surface Docker, Kubernetes leading container Securing the Stack via Containerization PASTA, Stage II – Technology Discovery & Enumeration Chef, Puppet bake security configuration into templates Jenkins – tests code & builds Docker images
8. Container Commands that Run Your Services & Apps Source: Anthony Bettini
9. Evolving Attacks, Weaknesses Shifting Targets DevOps Team Members NetSec Groups Open Source Marketplaces/ Repos Abuse Cases against Weak Containers Container breakout via kernel exploit Mis-configuration opportunities Privilege escalation via root Illicit network ACL requests Speed of Deployments Dependency check freedom
10. Proliferation’s Significance to Threat Agent(s) • Shift to DevOps redefines OSint • Scope of Attack (Hosting model) • Technology footprint • Workflows • Architecture • End of Generic Attack Patterns • Targeted Attacks on Process & Tech • Orchestration selection may alter attack patterns vs
11. Factors Supporting Cloud Threat Models Cloud management fails (process flaw) Mis-configuration (process/ tech flaw) Cloud insider (threat agent) Tenant hopping (attack pattern) Broken trust models (weakness)
12. Threat Motives & Attack Vignettes Foreshadowing Abuse Cases in DevOps
13. Container Use to Abuse Case Mapping Containers Use Cases • Decoupling • Process Isolation • Resource Dependency • Web-enabled APIs • Container marketplaces Container Abuse Cases • Opportunities for implicit trust abuse • More actors w/ poorly assigned privs • Host resource (kernel) hacking • Larger attack surface • Tainted containers
14. Dissecting Docker Components  Docker run  Namespace  Achieve network isolation  CGroups  availability control  Docker Daemon  runs as root  /host = / on host system  Vulnerable to other inputs (load & pull)  Shared services (?)  REST API  Can be exposed  Arbitrary commands via fuzzing  Dockerfile (affects builds)  Can be tainted  Infiltrate DockerHub or Registry  Multiple options given numerous functions within a tainted image Docker Daemon Docker Client Docker Registry (Public/ Private) Docker Images (read only templates) Docker containers
15. DevOps “Dishing”  Serving deliberately tainted images to a marketplace  Goal is mass deployment and consumption of images with vulnerabilities or backdoors  Convenience of pre-built images is too tempting  Relying on speed of DevOps workflows and increase business/ IT pressures  Like most (in)security initiatives, weak or immatures processes around open source security testing
16. Examining Prior Container Weaknesses • Absence of user spaces • History: LXC adopted as model container • Docker: Early versions susceptible to tenant breakout • Adding users to Docker groups (inherits root privs) • chmod +s <target volume> • Other misconfiguration gafs • Knowing what actor can run Docker in your contains • Higher privs, more container breakout issues (ex: /var/run/docker.sock) • Review your Dockerfile
17. Ripe for “Dishing”
18. Precedence of Attack Patterns Vulnerable Images across Marketplace Multiple attack vectors available via tainted image Kernel based exploits Docker Container Breakout Proof of Concept Exploit Legacy LXC code found to be vulnerable Exploit was around running untrusted apps w/ root priv MITM for DockerHub Access HTTP access by default for DockerHub Access
19. Containers Attack Surface Regular applications (e.g. – Nginx, MySQL, Hadoop, Redis.) System Services (High) (SSH, cron, syslog) Prefers root! System Services (Low Level – manage nic, networking, filesystems) Kernel Level (manage kernel Ddrivers
20. Orchestration Attack Surface Tainted cmds for container build Social eng of DevOps Submitting Tainted images Exploiting insecure /etcd dir Injecting arbitrary commands Social engineering Zookeeper for tainted configs
21. Personal Services Attack Vignette Uber Case Study in CaaS & Exercising Possible Attack Patterns
22. Adoption, Advertising, & Attack Vectors … “Docker provides consistency for both build and run time environments. It has helped Uber reduce their footprint of Debian packages as well. Makes it easy to updates certain images without having to reboot then entire fleet. They are now onboarding all of there new services into Docker, and will be onboarding all of their existing applications into Docker clusters. Docker containers also reduce time from weeks and months to minutes or hours, providing an isolation of resources so that applications no longer interference with one another.” …
23. [Attacking] Uber’s Business Objectives PASTA S1:A1 Biz Objectives of Target Segment growth (e.g. – BlackCar service, Uber Pool, Trucking?) Availability/ reliability of driver services Credibility amongst riders and drivers Cross-selling opportunities PASTA S1:A2 Compliance Pain Points  PCI-DSS 3.1  Privacy laws (e.g. – State, Federal, EU, etc.) Missing PASTA Activities (S1:A3 – Business Impact)
24. Defining an Attack Surface Uber Provided  Uber Rides SDK  APIs  SOA backend services  Node.js (‘many services’)  Python/ Tornado  GoLang  Java  Backend Datastores  Riak & Postgres (Data stores)  Redis (caching layer)  Ringpop – ‘highly available consistent hash ring for app layer sharding of services’ OSInt  BuiltWith Technology Profile  Nginx  Apache  AWS  Job Boards Intel  Python (Django?)  Hadoop  PostresSQL  pgBouncer  Node.js  Redis
25. App Decomposition (Blackbox)
26. App Decomposition (Stage III – PASTA) Blackbox  Exposed, discoverable containers  Social engineering  OSInt Whitebox  Identify actors on Docker clients  Identify shared container nodes  Lynis can help audit (container image)  Nmap for exposed services/ ports
27. Threat Analysis for Personal Service Attacks (Stage IV) 1. IP Theft 2. Corporate Sabotage (ex: game nights, concerts, etc. 3. PII Compromise 4. Transaction fraud 5. Hacktivism
28. Threat Assertions Threat Claims  (T1) want to steal drivers  (T1.1) Attacker need drivers contact information  (T2) I want to know driver contract terms with Uber (OSint)  (T3) I want (T1-T2) but want to frame target competitor Threat Agents  Competition (IT threat actors)  Bounty hunters  Foreign nation state actors
29. Sniffing Out Weaknesses… Container Orchestration Weaknesses  Containers run as root  Low namespace adoption (Docker)  Use of public Docker registry/tainted containers via marketplace  Sharing containers w/ root  Insecure transport layers  Challenges w/ Client daemons (Docker  Misconfiguration Container Insecurity  --net=host  Chroot for archive extraction  Priv escalation or RCE w/ elevated privs most attractive  Docker group runs w/ elevated privs  Exposed RESTful APIs susceptible to fuzzing
30. Leveraging Vuln for RCE or DoS (if all else fails) Source: Anthony Bettini
31. RCE in ElasticSearch Source: Anthony Bettini
32. Mapping Threats to Attacks
33. Container Orchestration Attack Tree
34. Dockerfile Attack Vector  Dishing out Dockerfiles embedded in repos  Images built from Dockerfile  Provide instructions or commands for assembly of an image  Docker daemon runs commands from Dockerfile using ‘Docker build’  Attack Vector is..  File itself  Repository where file is managed
35. Targeting DevOps Teams
36. Looking for insider candidates …  Want to pull more details on who supports DevOps at Uber  Social engineering option  Turning them may be easier
37. Social media pulls on target DevOps  Google Goggles on image
38. Alternate Attack Paths…
39. Revisiting Container Attack Service
40. Attack Library Genres Dishing Create tainted docker images Create tainted dockerfiles Embedded binary commands and rogue image pulls MITM for default HTTP API access Fake CA for MITM secure connections Client side arbitrary command injection Social engineering DevOps REST API command injection Kernel side exploits Embedded malware in tainted container images DDoS Attacks
41. Countermeasure Library docker run –u (run w/ another UID other than root) Docker can now prevent processes in container to gain new privileges via the -- security-opt=no-new-privileges flag AppArmor, SELinux Seccomp Run kernel w/ GRSEC Run kernel w/ PAX Control groups (cgroups) Kernel namespaces debian:jessie as base image FROM tagging Use your own base images Network ACLs Signed Images 1/13/2016 – Docker 1.10 release (Feb ‘16) UID 0 mapping Security Training for DevOps Email anti-phishing [Dockerfile] Don’t boot init Use of trusted builds Don’t apt-get upgrade in containers TOMOYO Great resource: http://cecs.wright.edu/~pmateti/Courses/4420/HardenOS/
42. Thank you! @t0nyuv tonyuv@versprite.com Blog: www.versprite.com/og