Case Studies

Blog Post

Detecting jQuery File Upload vulnerability using Falco (CVE-2018-9206)

In the past few days, a new vulnerability was disclosed in a widely used component –  jQuery File Upload plugin. A change in Apache’s Web Server security setting handling, exposed users of this plugin to an unrestricted file upload flaw. Let’s dig in on how to detect jQuery File Upload vulnerability (CVE-2018-9206) using Falco.

Complete Takeover

The plugin allows a user to place files in the root path of a Web Server. As a result, a malicious user can upload shell scripts, malwares or executables that can be used to remotely access the server, and completely take over the host.

The sheer amount of forks of the plugin’s git repository and popularity of this component, on top of how simple the exploitation is, makes this vulnerability even more critical than the simple risk assessment done based on the technical details alone.

Using Falco for detecting jQuery File Upload vulnerability

Patching systems takes time. Finding all vulnerable components in an environment, is even more complex when third party applications may use the plugin behind the scenes, without any clear indication for its existence. This is where Falco, a behavioral detection system, can help. Falco instruments the underlying host OS to get access to a rich stream of data to evaluate rules based on any system event that passes through the kernel.

Falco out-of-the-box policies will identify any suspicious activity by an HTTP server.

Any attempt to exploit the vulnerability above, by running a shell for example, will be detected by Falco, and generate the following security event:
 

Falco implements a rich language that allows the user to create a more focused rule aimed at specific applications’ vulnerabilities. Here’s example on how the engine can be used to detect a suspicious behavior:


This might capture a broader set of actions, so small tweaking might be needed to make this compatible with one’s environment.

Taking actions & figuring out what happened

Sometimes just detecting an event or an indicator of compromise isn’t enough. Organizations will want implement active enforcement to trigger actions like tainting a node, restarting a container, or killing a process. In our implementing runtime container security blog, we provide different playbooks for how to mitigate threats on top of Kubernetes.

Being able to figure out what happened following a breach is a must have for many security practitioners, especially if the incident happened in a container that is long gone. 
Sysdig Secure builds on top of the Falco engine to give the user the ability to not only detect an incident, but also analyze any subsequent malicious activity that happened in the system by providing deep system level data and tools.

We cover more details on DFIR with Falco and Sysdig Secure in our webinar: Best practices for Forensics and Incident Response in Containers.

Share This

Stay up to date

Sign up to recieve our newest.

Related Posts

Detecting Cryptojacking with Sysdig’s Falco

Fishing for Hackers: analysis of a Linux Server Attack

Runtime container security – How to implement open source container security (part 1).