Threat Stack Introduces Additional Runtime Attack Detection

F5

Threat Stack is now F5 Distributed Cloud App Infrastructure Protection (AIP). Start using Distributed Cloud AIP with your team today.

Protection From More Types of Application Attacks

Threat Stack Application Security Monitoring detects vulnerabilities in code and blocks live attacks in real time. Most application security solutions talk about the most common runtime attacks — SQL injection or XSS — for example, but modern web application languages and frameworks also include some legitimate functions that can be abused, resulting in attacks that can be as high impact as those (or higher). Threat Stack Application Security Monitoring protects against SQLi and XSS, and we are now introducing additional runtime attack detection to further protect your web application, microservice, and API workloads against path or directory traversal attacks, and remote code execution.

Remote Code Execution (RCE)

Remote code execution (RCE — also known as arbitrary code execution, or ACE) allows an attacker to run arbitrary code on the server where an application is running. This is an injection attack — an attacker could pass a string into a function that would execute his own operating system commands. A good explanation of how this works in Javascript is on the Wanago.io blog at https://wanago.io/2018/11/19/how-does-eval-work-and-how-is-it-evil-javascript-eval/. In this example, the function eval takes a string and executes it as code with the same privileges as the rest of the application. Imagine an attacker submitting the following on your site’s sign-up form as a username:

'John"); exec("rm -rf ./*"); console.log("'

If that username value is used in an eval function, it’s not going to be a very good day!

Threat Stack protects you from RCE in two ways: at build-time and at runtime. At build-time, the AppSec microagent identifies function calls that are vulnerable to RCE attacks — things like eval() in Node.js or os.fork in Python. There could be legitimate, safe uses of these functions, so we flag them as “risk” to developers. We provide eLearning content that explains why they could be risky and offer safer alternatives. At runtime, though, we identify attempts to actually exploit the vulnerabilities. For example, if we see that one of those risky functions is being invoked with content that came in from the web containing a shell command exploit, we flag that as an attack and immediately notify your team. Common command exploits could consist of commands such as kill, disable, stop, fdisk, etc.

Path or Directory Traversal

A path or directory traversal attack allows an attacker to read (or in some cases write) arbitrary files on the server where an application is running — files outside of the folders where the web application resides. This could include application source code, credentials, or valuable operating system files. It works by exploiting a common technique of using relative file paths in variables — generally referred to as “dot-dot-slash (../)” sequences. For example, the sequence ../ refers to one level up in the directory structure. String a number of these sequences together, and you can refer to the filesystem root from which other files and directories could be accessed.

There are plenty of legitimate uses for dot-dot-slash sequences, so it would be annoying if any use of them was flagged as a risk (as you might see from a SAST tool). Instead, Threat Stack AppSec Monitoring analyzes both the function that uses it and the payload being passed to the function at runtime. For example, in a Node.js application using commands such as fs.open/read/write/etc., the payload being passed to the function can be checked for directory path encoding or references to sensitive OS files. A risky function with a malicious payload will be flagged as an attack, and your team will be notified immediately.

Part of a Full Stack Security Observability Solution

Attackers don’t think about tiers; they don’t focus solely on applications while ignoring the containers where they run or the cloud service where they’re hosted. An RCE attack, for example, could result in unauthorized processes running on a host. Or a path traversal attack could compromise sensitive cloud host credentials files. It’s important to be able to detect these and other runtime application attacks, but it’s critical to enable security observability across all your attack surfaces, regardless of their complexity or how your infrastructure changes. That’s the power of AppSec Monitoring as part of the full Threat Stack Cloud Security Platform®.

If you’d like to learn more about the Threat Stack Cloud Security Platform, including its Application Security capabilities, feel free to sign up for a demo. Our security and compliance experts will be happy to discuss your organization’s requirements.

Threat Stack is now F5 Distributed Cloud App Infrastructure Protection (AIP). Start using Distributed Cloud AIP with your team today.

About the Author

F5

More blogs by F5