Protecting the Cloud from Inside

Transcription

1 Protecting the Cloud from Inside Intra-cloud security intelligence Protection of Linux containers Mitigation of NoSQL injections Alexandra Shulman-Peleg, PhD Cloud Security Researcher, IBM Cyber Security Center of Excellence 1

2 Securely Moving Corporate Applications to a Cloud Customer s view: My infrastructure moved to a 3rd party cloud service Help me to protect my assets. Detection and remediation of cloud vulnerabilities. Public cloud Hybrid cloud Private cloud 2

3 Cloud Security Orchestration Layer NoSQL security Container security Cloud Application Layer (PaaS) Cloud Infrastructure Layer (IaaS) Use cloud insights to raise the security No perimeter security in clouds 3

4 Cloud Trends The cloud s code: Controls distributed and complex environments Executes automatically with admin privileges Has modules in scripting languages Is open source with well known weaknesses May share the same kernel and host OS between applications of different users (e.g. Linux containers) Cloud software is more vulnerable than traditional systems and applications! 4

5 Cloud Trends Automation brings order! Each module knows its role! Let s use automation to improve protection! 5

6 Automating Code Distribution and Deployment with Containers Container cloud (IaaS) Deployment packages (PaaS) 70% of organizations are evaluating Docker 49% are concerned with Docker security 6 Survey of Vmblog.com (745 participants)

7 Containers - Emerging Building Blocks of Clouds Lightweight OS-level virtualization via grouping resources like processes, files, and devices into isolated spaces. Benefits: Portability and easy deployment Application isolation Near native performance App A App B App C Bins/ Libs Bins/ Libs Bins/ Libs App A App B App C App D Guest OS Guest OS Guest OS Bins /Libs Bins /Libs Bins/Libs Hypervisor Host OS Host OS Server Server Containers VMs 7

8 Containers Threats Threats Kernel exploits Container Engine Shared resources Shared Bins/Libs Mis-configurations Private/Public cloud Attack flow: Escape to host via kernel exploits Propagating to additional servers 8

9 How to make my containers secure? Securing the Infrastructure and the Workloads of Linux Containers, Workshop on Security and Privacy in the Cloud, Sept Mattetti, M., Shulman-Peleg, A., Allouche, Y., Corradi, A., Dolev, S., Foschini, L. 9

10 Open Source Linux Tools to the Rescue! Linux Security Modules (LSMs, e.g. AppArmor, SElinux) are lightweight, loadable kernel modules enforcing access control. Advantages of LSM: Part of Linux distributions Provide mandatory access control(mac) Disadvantages of LSMs: Complicated configuration and tuning Profile to restrict the Docker daemon (none exists) Profiles to restrict the containers (limited dockerdefault profile) 10

11 Tracing Execution and Profile Generation 1. Invoke Docker API (build/run etc.). 2. Use SystemTapto monitor the kernel operations. 3. Generate LSM profiles splitting between the host and the containers. LiCShield.git 11

12 Profile Distribution and Enforcement Construct the security policy once for each image -apply to all the instances. My image Deploy Docker Daemon Host OS Server 12

13 Overview of Host s Runtime Protection 1. Linux host + container engine high protection! Protecting server s runtime with HIDS 2. Containers protection as a service Per image training and creation of AppArmor, Selinux policies As a service workload protection Per Image profiles App A App B App C App D Bins/ Libs Bins/ Libs Bins/Libs Container Engine Host Based Intrusion Detection (HIDS) Host OS Server Secure, yet, Usable Protecting Servers and Containers S. Barlev, Z. Basil, S. Kohanim, R. Peleg, S. Regev, A. Shulman-Peleg, to appear. 13

14 No SQL, No Injection? Workshop on Web 2.0 Security and Privacy (W2SP) 2015 A. Ron, A. Shulman-Peleg, E. Bronshtein, A. Puzanov 14

15 The Popularity of NoSQLContinues to Rise db-engines.com 15

16 NoSQL Attack Vectors The new data models of NoSQL make old attacks, like SQL injections irrelevant. Attackers get new opportunities for injecting their malicious code into the statements passed to the database. Attackers web browser Injection added Data Attacked web server Client/Protocol wrapper Injection processed Data NoSQL data store 16

17 NoSQL Injection Techniques Tautologies -bypassing access control by injecting code in conditional statements that are always true. username=tolkien&password=hobbit username[$ne]=1&password[$ne]=1 db.logins.find({ username: { $ne: 1 }, password: { $ne: 1 } }) Union queries changing the data set returned for a given query. username=tolkien, $or: [ {}, { a : a&password= } ], $comment: successful MongoDB injection { username: tolkien, $or: [ {}, { a : a, password: } ], $comment: successful MongoDB injection } 17

18 NoSQL Injection techniques Cont JavaScript injections -Passing un-sanitized user input to queries may allow injecting arbitrary JavaScript code. Origin violation - a legitimate user and its web browser are exploited to perform some unwanted action on behalf of the attacker. 18

19 NoSQLInjection Techniques Caches Piggy-backed queries -where an attacker exploits some assumptions in the interpretation of escape sequences special characters (e.g. termination characters like CRLF) to insert additional queries to be executed by the database. Attackers web browser Injection added Data Attacked web front end Protocol wrapper Injection Data Cloud or BigData Framework In-memory data store Data Data Data 19

20 Mitigation of Attacks and Injections Development and testing Continuous Mitigation Secure Deployment Insider s view Monitoring and Protection 20

21 Protecting the Cloud from the Inside Cloud Application Layer (PaaS) cloud Foundry IDaaS, NoSQL data stores, Spark Cloud Infrastructure Layer (IaaS) Heat, Mistral,... Network, VMs, Containers, Storage, Users Cloud Operation Layer Details of the workload to be executed Security tools and policies Security and Policy Dashboard Admin disruptive: Chef, TripleO, DevOps Admin monitoring: logs, accounting etc. 21 Security Intelligence for Cloud Management Infrastructures S. Berger, S. Garion, Y. Moatti, D. Naor, D. Pendarakis, A. Shulman-Peleg JR Rao, E. Valdez, Y. Weinsberg, to appear.

22 IBM Cyber Security Center of Excellence 22