Meet|Alice,|she is a developer at a fast-growing company that creates a face filter app. What is Alice's worst fear? Seeing her competitor launch the newest filter into market first.  Their security team lead, Bob, would have probably hoped that her worst fear would be writing vulnerable code. More often than not, however, this is not top of mind for developers like Alice. So, as you'd expect, Alice and Bob sometimes have difficulties communicating with each other, due to different goals and drivers. Think speed vs. risk aversion.

In this blog we will walk through some awesome new features within AppDynamics with Cisco Secure Application. What we will do is simulate a Remote Code Execution (RCE) attack and what response Bob can take to help Alice launch her application quicklyandwith security top of mind.

What is a Remote Code Execution attack? What is the impact?

A RCE attack is an attacker's ability to remotely execute arbitrary commands or code on a target machine or in a target process. Such a RCE vulnerability is an obvious security flaw in applications, and somewhat bad news to Alice, but much worse news to Bob (who is responsible for the security around this app). A program that is designed to exploit such a vulnerability is called an arbitrary RCE exploit. There are many libraries that developers use when developing their apps. Many of those have vulnerabilities in them.

Now, what can be the impact of such an attack? Imagine that a malicious actor, Eve, can execute arbitrary code commands inside of your application, without being physically present. Imagine Eve being able to read and write into your database, or take your application offline. Now you might have thought that you are safe, since you migrated your apps to the public cloud: how could anyone get in there? Well, with application-level attacks (like RCE) this is unfortunately still possible. So how can we have the comfort of the public cloud, but also visibility and control like never before?

AppDynamics with Cisco Secure Application

Cisco Secure Application protects applications at runtime, detects and block attacks in real-time, and simplifies the lifecycle of security incidents by providing application and business context. This creates a shared "language" across app and security teams, and makes it easier for them to communicate. It is natively built into AppDynamics Java agent (more languages to follow) and embeds security into the application runtime without adding performance overhead. Let's have a look at our remote execution attack via the eyes of Bob, our AppSec expert, who is testing out Cisco Secure Application!

Below you can see theVulnerabilitiestab in the dashboard. Important here is that you can see the CVE with associated severity, but what's more is that you can also see the status: has it been fixed or not. This is especially valuable information when triaging and prioritizing work. We can now focus on what still needs to be fixed first, and then check the others for potential compromises.

Secure App goes even further than this: we can also notice these 2 exclamation mark symbols, the first indicating that an exploit is possible for this CVE, and then second that a someone tried to compromise this vulnerability! Has Eve been able to do bad stuff in our application? We will need to act even faster on this vulnerability!

When we click on this line, we are shown more detailed information about this vulnerability: as we can see this CVE-2017-5639 is a flaw in Apache Struts with incorrect exception handling, which allows remote attackers to execute arbitrary command via HTTP headers. Recognize this type of attack? Yes, it is indeed the worst nightmare of our AppSec manager Bob, and this has actually been done as well!

We have to find out more about this compromise, so we can click on the attack and this will drill down further. What we can see now is truly amazing if we compare this to other classical security tools. Not only can Bob see the affected app, the affected service and the vulnerable library, Bob can also see the actual misused Java method and the stack trace!

When Bob checks out the stack trace you can actually scroll through the node's entire stack trace and associated errors. This can be essential when investigating what has happened, and if certain database calls have been made.

Now when Bob checks out the details of this page, you can see the command that has been tried to execute, the method name and working directory. As you can see, Eve had tried to show the contents of the /etc/passwd file! Was Eve able to see into this precious file?

In Cisco Secure Application, you can set policy in either Detect or Block mode. Luckily, we can see that this action was blocked by the policy used (lowest policy in list). This was good thinking of Bob! Using all of the gathered information, Bob can now show exactly what needs to be changed in Alice's code. Secure App is now providing a common tool which both parties understand. Alice and Bob worked happily ever after.

If you thought this was interesting, and want to learn more. Then check out this video with Keith O'Brian on DevNet Snack Minutes!

Additional resources:

Visit the DevNet Security Dev Centerto learn more about how to remediate security events and get started with Cisco security APIs.

We'd love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

Twitter @CiscoDevNet | Facebook | LinkedIn

Visit the new Developer Video Channel