You’re Only as Strong as the Weakest Link in Your Web App Fence

As a leading provider of SaaS-based WAF solutions, we often encounter organizations who prioritize their applications and only secure the “top” web applications. There’s a critical flaw in this approach and it’s leaving organizations exposed. 

Overview

According to the Verizon 2018 Data Breach Investigations Report, the top attack vector continues to be external facing web applications. We have seen many examples of this over the past several months, including the infamous Equifax breach that exploited a known vulnerability in the Apache Struts framework.

By exploiting a web application, an attacker can bypass all the other traditional security measures protecting an organizations network and data including, firewalls, Intrusion Prevention Systems (IPS), etc. There are also other ways to bypass traditional security controls, like spear Phishing attacks but, in this post, I will concentrate on web applications as the attack vector and the main detection and neutralization solution for these kind of attacks – the Web Application Firewall (WAF).

WAF’s can be deployed in front of any web application and protect against web specific attacks that regular firewalls (yes, even Palo Alto Networks) and your IPS systems are ill equipped to deal with as these systems focus on a wider range of network attacks and not specifically web attacks.  

You are as secure as your weakest app. 

As a leading provider of SaaS-based WAF solutions, we work with organizations all the time, who of course want to protect their most important applications such as their eCommerce sites and obviously critical customer portals, but almost always de-prioritize other “less important” applications unprotected. Protecting the “crown jewel” web applications seems completely logical as the perception is you are protecting the highest value apps and therefore mitigating the most risk.

This is a highly risky approach however. Why? In a targeted attack scenario, any “smart” hacker will forego your sensitive apps for much easier targets. Once compromised, these easier targets can then be quickly leveraged to pivot to other attacks, eventually leading to a full and complete breach of business-critical applications and other digital resources.

As an ethical hacker for the last 18 years, I have been performing penetration tests for some of the largest enterprises in the world and have seen several scenarios that make seemingly less important applications ripe targets for exploitation:

1. Shared backend resources 

Often, backend resources such as database software will be shared by multiple web applications. In this scenario the goal of an attacker would be to find the weakest application in this resource pool and, by utilizing an attack vector such as SQL injection, attempt to gain cross-database access to resources used by the other business-critical applications. 

Additionally, an attacker will often attempt to place a malicious script within the execution path of an application. This script can then be used to establish a reverse telnet connection, effectively gaining shell access to the now compromised application.

Armed with shell-level access, an attacker can then attempt system privilege escalation attacks to gain administrative access. Even if this escalation is unsuccessful, they can browse the file system and access resources belonging to other web applications.

2. Shared credentials 

While the above exploit path might be viewed as a worst-case scenario, even if an application is well protected against more serious attacks like SQL injection, less sophisticated attack vectors like brute force of client login credentials can be used against under-protected applications. This is a very common approach as a surprisingly large number of organizations have still not deployed sophisticated authentication and authorization models such as SSO with two factor authentication. Making matters worse, users and administrators often use the same credentials across multiple applications.

Once credentials are obtained from a less important application, they can be used to log into sensitive applications or even gain VPN access to internal network resources.

3. It’s just APIs

Another scenario we often see is failure to protect API endpoints. With RESTful APIs becoming more and more powerful, they are becoming a very attractive target for an attacker.

Instead of session cookies, an API is often protected by JSON Web Tokens (JWT). We often see API backends that do not invalidate these tokens for days, making them much easier to exploit than standard session cookies which get invalidated upon logout or after idle time-outs.

And finally, APIs can provide a much more direct access path based on HTTP request methods such as PUT, PATCH and DELETE.

4. R&D and Marketing

Most large organizations have many departments with their own Internet facing resources, making it harder for IT security teams to enforce protection policies across the entire organization.

For example, it is not unusual for software product teams to stand up hundreds of test instances in the Cloud. Because such applications are often considered “non-production” they are classified as low sensitivity and low risk.

However, it’s these very non-production applications that often contain database and administrative passwords shared with a production environment and can be used as a first pivot point in an attack.

Marketing is another great example of a department that will often have their own unique web presence (think partner portals, sign-up forms etc) that are not controlled by IT.

RECOMMENDATIONS