Protecting against containerized web app attacks

WAF the heck do I do to protect against attacks on my container-based web applications?

The hackers who want your organization’s valuable data will invariably target your web applications. Despite the steady increase in distributed denial-of-service (DDoS) attacks and ransomware, web application attacks represent the most common cause of data breaches.1

The vast majority of these attacks are executed by botnets, operated by organized crime2. Their goals: stealing credentials, growing the size of the botnet, and, of course, exfiltrating information that can be used for financial gain.

More sophisticated attackers use these compromised systems as stepping stones to further intrusion. Strategic web compromise (also known as “watering hole” attacks) modify the links and forms of an existing system to intercept credentials to other more confidential applications.

These adversaries are relying on tried-and-true attack patterns. Both OWASP Top 103 and the Akamai State of Security4 continue to identify types of code injection (e.g., SQL, Javascript) as the predominant web application attack vectors.

Containers VS. monolithic environments: two distinct attack surfaces

Though the top attack vectors haven’t changed much over the past few years, there has been a dramatic shift in application architecture. Enterprises are rapidly moving toward microservices, where they build, deploy, and run applications in containers.

A container environment represents a very different attack surface than that of a monolithic application environment, and it is critical for security practitioners to be aware of the resulting differences in the way certain types of attacks can unfold.

While a traditional host system contains multiple services (some which are irrelevant to the application itself) such as an SSH server or package management system, a container only includes application services. With fewer exposed services, the resulting attack surface is significantly smaller.

For example: a code execution bug in a monolithic environment can lead to host compromise, whereas with a microservices model, an attack only impacts the container, and the service to which it belongs.

Another interesting example of this is Cisco’s Talos team’s discovery of an Apache Struts vulnerability (CVE-2017-5638)5 that was recently found to be exploited in the wild. Let’s compare how the exploitation techniques would differ between monolithic and microservice architectures.


Exploit TechniqueMonolithic environment behaviorMicroservices environment behavior
Probing Some attack patterns used simple commands like `whoami`, `ps aux`, for host reconnaissanceInformation about the host is gathered to build an exploit chain.Information is namespaced and is in the context of the given service and would not be helpful to the attacker.
Payload execution Talos discovered that some payloads tried to disable security features like ‘linux firewall’ and then execute the dropped binary.Malicious binaries can be used for denial-of-service (DoS), or be used as part of a botnet.Service resource limits and ease of scalability will prevent such attacks.
PersistenceSome advanced payloads try to maintain persistence by invoking copy to a known directory and disabling firewalls on reboot.Immutable infrastructure will periodically restart services from a known-safe configuration. Therefore, attack payloads do not persist.

Attackers are ultimately adapting their techniques to be more effective across a narrower surface of attack characterized by a high degree of isolation (processes running in a given container are effectively isolated from processes running in other containers). Their payloads will start to identify container resources in a fashion similar to how malware started to detect virtual machine encapsulation. Key targets of these new attacks will include:

  • persistent volume mounts

  • network traffic to other containers or hosts in order to pivot

  • device, kernel capability, and system call access

The traditional WAF is at a disadvantage in the container world

Traditionally, Web Application Firewalls (WAFs) provide a common preventive approach to protecting monolithic applications. By intercepting web traffic as it comes in, a WAF will attempt to identify common injection and other types of attacks and block them before they reach their intended target. This approach makes sense given the frequency and automation of attacks originating from botnets. However, a major downside to most WAFs is that they examine each network connection in isolation.

WAFs must also evaluate traffic quickly; user experience requirements cannot tolerate noticeable delays. Therefore, WAFs specialize in identifying hit-and-run type attacks where the exploit and payload arrive in the same request. Attempts to establish persistence that depend on a series of pivots or privilege escalation are less likely to show up on a WAF’s radar. Where containers are involved, traditional WAF solutions are at an even greater disadvantage as they have no visibility into the container-to-container network traffic that attackers use to persist in a microservices-based environment.

Attacks on container-based web apps require a container-based approach to security

High-efficacy threat detection depends on isolating signals from noise. With multiple containers on one system, noise overwhelms traditional event detection. A container-based security solution associates behavior with individual containers, instead of the whole system, improving the signal strength.

StackRox expertly fits the bill: not only does StackRox deploy as a set of security microservices (StackRox containers run right alongside application containers), it captures millions of container signals across the environment, including system calls, network traffic, and Docker commands. Finally, an extensive set of machine learning capabilities enables the detection of malicious behavior against a backdrop of observed application behavior.

StackRox identifies common injection attacks in network traffic, and recognizes programming languages, encodings, entropy, data types, and common credential formats in both network and file system data. It also checks which processes are accessing them. StackRox will alert on malicious activity correlated across indicators of attack and compromise (per user-defined policy). Last but not least, as part of a scalable containerized infrastructure, StackRox’s approach to preventing and responding to malicious activity aims to minimize disruption to other operations.

In a traditional monolithic architecture, this would require snapshotting and initializing an entire virtual machine. With containers, once the orchestrator identifies a single-container disruption, it will simply launch another container of the same type. The cluster restores itself to full capacity in a matter of seconds.

Conclusion

Traditional security approaches are ineffective as container adoption proliferates. Familiar attacks unfold differently in container environments, so it is critical to leverage a dedicated container security solution with deep monitoring capabilities and robust machine learning in order to protect against them.

Find out more about how StackRox protects your containers and cloud workloads against web application attacks and other types of threats aimed at your organization.

Sources


  1. Financial vertical, Figure 9, Data Breach Investigations Report 2017, Verizon [return]
  2. Web Application Attacks, Page 57, Data Breach Investigations Report 2017, Verizon [return]
  3. 2017 Top 10 List, OWASP; https://www.owasp.org/index.php/Top_10_2017-Top_10 [return]
  4. Web Application Attack Activity, Page 14, 2017 State of the Internet Security Report, Akamai [return]
  5. http://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html [return]

Categories:

Tags: