When users put your app at risk. The attack surface iceberg

Introduction

Web applications handle a lot of user accounts and data today. This is especially true for B2C products, but self-service SaaS applications also deal with thousands of user accounts. The vast majority of users use apps in a legitimate way. Attackers don’t.

It can be a challenge for developers to identify these attackers in their whole user base.

This post covers two main questions:

• What are the threats that an application faces from logged in users
• How engineering teams can identify attackers early, before attackers take advantage of the app

Cyber attacks targeting web applications always follow the same scheme:

1. An attacker performs an initial vulnerability discovery or fingerprinting, usually through a standard security scan. A security scan is unlikely to expose security vulnerabilities. However, they bring an initial overview about topology and exposed services.
2. Unauthenticated users have very limited access to applications. For web applications, when the account creation is open, the attacker will create a user account to investigate further. For the others, the attacker will target existing user accounts. He will basically target qualified accounts first: users from the app domain, administrators, power users, etc.
3. Gaining authenticated access allows the attacker to benefit from a much wider surface attack, with the ability to query most of the endpoints (application backend services).

Linking security threats and attacks to individual users is key to protecting SaaS applications or marketplaces. Let’s understand why and how.

Attack surfaces of a web application: threats and recommendations

Attack Surface

The concept of attack surface describes the exposure of an application to cyber attacks. Web applications offering a wide range of endpoints (backend services) have a much wider attack surface than web applications delivering static content.

The attack surface is like a standard funnel: the majority of attacks are gathered at the top of the funnel. Usually unqualified and harmless: script kiddies, security crawlers…

The bottom of this funnel is where the skilled and motivated attackers are. They are the ones who will likely find security breaches.

The attack surface is directly related to authentication. Most of the web applications expose limited endpoints to unauthenticated users.

Targeted attacks, performed manually by attackers, have much more chance to succeed.

Execution flow of a standard web app

Skilled attackers maximize the attack surface to assess the security of a web application. A web application has thousands of internal routines (internal functions or methods as well as third party libraries). The illustration above illustrates a real-life example:

• The very first node, on the left, is the web app entry point, handling the HTTP requests. This node filters out unauthenticated users. If users are not authenticated, the application will stop processing the request. Attack surface is likely null at this stage.
• Right after this, a dispatch node routes the application execution according to HTTP parameters.
• At this stage, any vulnerability in a subroutine puts the entire web application at risk.

We can split applications into 3 zones.

Yellow Zone

Features exposed to unauthenticated users are part of the yellow zone. Most of the endpoints require authentication, which drastically reduces the exposure to attacks.

Security bots and security scanners are targeting this layer. The attack surface, at this stage, is hopefully often too small for most applications ( excluding WordPress hosted blogs 😉 ).

Harmless security activity doesn’t bring any value to developers. Sqreen monitors the yellow zone to detect abnormal security activity, such as unusual massive security scans.

Orange Zone

At this stage, a mix of automated and manual assessments are performed. In this zone, attackers are real people. This makes a big difference! They will mutate original requests, serialize crafted variables, and start stressing the application with other vulnerability scanners.

Experience is key: skilled attackers know where to dig and which endpoints they should investigate. Complex forms, filesystem manipulation, serialized cookies, upload services, or search engines are usually good candidates for first findings.

Errors raised by the application (exceptions), unvalidated returns, are great hints for attackers.

Detecting attackers early is key. Sqreen monitors the Orange Zone detecting security anomalies in web applications (exceptions, HTTP errors, etc.) and alerting about users performing attacks.

Red Zone

Some user accounts have additional rights. They are administrators, moderators, paying users, users allowed to use beta features, etc. They have access to restricted subset of features, and they are part of the Red Zone.

Attackers getting access to the red zone are the most dangerous ones, and reaction time is key. The attack surface is greatly improved and can lead to data exfiltration (SQL injections, data leaks), control of the web server (code or command injection), XSS, or access to other users data.

Sqreen also protects this last red zone by blocking attacks in real-time and linking those attacks to users inside the application. Software teams can immediately react and take action on those user accounts and events.

Multiply the attack surface by the number of apps

This description of the attack surface for a given application has to be multiplied by the number of applications exposed (especially with the explosion of microservices). Large infrastructures, such as BBC’s in the illustration below, expose thousands of endpoints to attackers.

Source: https://dnsdumpster.com/static/map/bbc.co.uk.png

This is not just a theory!

Here is a real-life story of a company that started using Sqreen after a security breach. The attacker managed to gain access to the complete user database. They only discovered the breach after the fact and had to figure out the complete modus operandi. Analyzing logs, user connections, correlating data, they were able to track the incident:

1. The attacker attacked the web application for months with basic security scans to fingerprint the application. This happened in the yellow zone (unauthenticated).
2. He quickly shifted to the orange zone, creating a user account to perform the attacks. Note that he didn’t even take the time to hide his identity (IP) in the first days of the attack. But further connections were done through TOR and open proxies.
3. After a few weeks, the attacker managed to steal an internal account ([name]@company.com) through a cross-site scripting attack (XSS)
4. Getting access to this account allowed him to get access to additional features on the web app, restricted to employee user accounts.
5. The attacker then identified a SQL injection in one of the backend endpoints and was able to retrieve the user database that way.

This case highlights perfectly the attack surface of a web application and how it can be used to trigger vulnerabilities. Having a security monitoring tool in place to identify insider threats coming from users could have avoided this breach.

Conclusion

Web applications, and SaaS apps, in particular, automate most of the processes: account creation, infrastructure auto-scaling, exception handling or monitoring. SaaS is all about scaling. Identifying hackers inside an application across thousands or even millions of legitimate users can be hard.

You can check the SaaS CTO Security Checklist to see other security measures that you can take to protect your app against cyber security threats.

Don’t hesitate to give Sqreen a trial to see how it can protect your application against insider threat.

Any comment or feedback? Feel free to leave a comment!

About the author

Pierre is the co-founder & CEO of Sqreen. He spent 9 years at Apple, where he led the team in charge of security asses­sments for the Int­er­net Ser­vices de­part­ment, hacking products and designing prot­ection. Pierre holds 23 US patents.