Akto as an API Security Automation Case Study

Introduction:

In this blog, Oleg - Security Partner at Block talks about the following:

1. Five Pillars of Security Automation:

   • Capturing Traffic to discover APIs

   • Automated API Inventory

   • Adding test templates to find vulnerabilities

   • Automating testing

   • Collaboration amongst teams

2. How to use Akto to do the above five?

Looking Ten Years Back

When I look 10 years back, an annoying and persistent question pops up: did we just lose those ten years in API security automation? The answer is not that obvious and details are important. Probably it’s just my PoV that becomes more pessimistic as the years are passing by.

10 years ago I worked for a mid-size fintech company doing application security and watching all those “need for speed” trends like DevOps, DevSecOps, and ultimately DevSecOpsAndEverybodyElse.

The problem with security automation was always a bit different compared to traditional testing where the results are more deterministic than in security where tools, security engineers, and product engineers keep arguing about vuln’s severity the same way as they did 10 years ago.

The situation below happened just recently, but it could easily happen in the distant past.

"There are some things in this world ... that will never change"

First Stab

There was definitely a disconnect between fully automated CI/CD process and mostly manual security assessments, be they manual application design review or penetration testing.

Burp Suite was as popular then as it is now, but I don’t believe that much progress was made in the last 10 years to make it more suitable for automation. It’s still very much a UI-based workbench for security engineers working as individual contributors.

I’ve tried to fix it then by creating a command line tool written in Ruby and integrated with Burp through extensions. An idea was to use a Ci/CD regression test that was run before each release as a payload generator hooked up to a Burp’s proxy. We implemented the same approach with OWASP ZAP to improve the fidelity of our findings.

The advantage of that approach was that it could be easily integrated with the pre-release regression test and with a Treatfix security dashboard that was used for triaging findings and pushing them to PD’s Jira if they were valid.

10 years back

An obvious disadvantage was that it was a passive scan since we’re afraid to break the regression test logic that would be definitely the case with active scan and injections. This framework was successfully used in an IoT startup whose mission was to connect all devices and people on Earth. I don’t know where we would end up with all that by now, but the startup went down taking our project with it.

That’s why I like OWASP and their chapters more than startups. They are definitely more persistent and you can still find our 2016 AppSec Cali presentation if you want to see the details of our approach

These Days

These days I work for a bit bigger and more innovative fintech company and am thinking: how can we implement a dynamic security API scanner that would be more efficient in regard of findings and supporting processes? 

Many cool new things have been implemented in Burp: more languages to write extensions, more OSS examples for those extensions, ActiveScan with tons of out of the box injections in Pro version, more parameters and config files that you can pass on a command line.

I decided to use it again, but write my extensions in Python this time, and integrate with our own security dashboard allowing me to review the findings before anything is submitted to product teams’ Jira.

Now

That works, and even finds some useful bugs that PD has already agreed to ti fix, but still I’d like Burp to be more friendly when it comes to automation:

• Python 3 is not supported for extensions since it uses Jython that supports Python 2.7 only

• It’s not possible to pass scan details and scan tasks config on a command line

• It’s not possible to retrieve Burp’s collab server interactions originated from ActiveScan programmatically

Looking to the Next Ten Years 

Just like any other manual work in Security (threat modeling, design review, manual code review) penetration testing is still not scalable.

Security engineers need to test dozens of services in each BU to achieve a good level of confidence in the integrity of all their systems, but in reality we could not assess even 5% of them. Frequent changes  introduce new threats and vulnerabilities to the systems that have been already tested.

Since hiring new testers is not scalable either, we need to find ways to automate the initial testing as well as testing of all incremental changes to the existing systems.

An additional benefit of the approach described in this document will also include: 

• Better visibility to what has been already tested and what not

• A statement of work for each item that we have in the assets inventory

What (aka Pillars)

There are a few major tasks that will allow us achieving a better level of security testing automation:

1. Implementing automatic (e.g. through AWS/GCP traffic mirroring) and semiautomatic assets/API discovery (e.g. coming from manual testing by Burp)

2. Creating inventory of all API’s and apps that we need to test

3. Creating templates for different categories of vulnerabilities 

4. Creating or adopting tools allowing to retest API’s quickly using the existing template

5. Creating a collaborative framework allowing to share the inventory items and templates between team members

How 

Let us take a closer look at each item described in the previous section

Discovery

Asset discovery is the first step for any automated security framework allowing to find documented or even undocumented service either in automated or semi automated manner, e.g. 

• Mirroring AWS traffic and finding API calls automatically

• Mirroring GCP traffic and finding API calls automatically

• Using Burp (or other manual testing tools) traffic to find and store API calls with their payloads

Inventory

We need to create a data repository where all testing entities will be stored. For each entity at least the following information should be stored:

• Name

• Endpoint

• Date of discovery

• Authentication type

• Request and response format preferable in formal notation such as a swagger document

• Sensitive data elements with DSL levels

• State, e.g.

• Documented/undocumented

• Deprecated

• Last tested date

• Planned EOL date

• All prior reports covering testing for this API

Templates

Templates are reusable code snippets written in common languages (e.g. Java, Python, Ruby, etc.) or in popular security specific notations such as Nuclei. They usually include payload that needs to be sent in a request and could include parameters enumerated through common attack techniques such as:

• BatteringRam

• Pitchfork

• Clusterbomb

While templates are usually specific and will work with certain API calls only, categories of vulnerabilities are common and well defined, which means that we can have many templates in each category (or sub-category)

Testing Tools

While Discovery, Inventory and Templates are important even without tools (e.g. it will definitely increase visibility to our security posture and help new hires to create attack payloads using existing templates), tools and collaborative frameworks are the ones that could really make a difference when it comes to automation.

Good tool should allow:

• Selecting an existing API from inventory

• Finding a template related to this API

• Modifying the template quickly

• Running an attack against the selected endpoint using the modified (or original) template

Collaborative Framework

All pillars described in the prior sections allow a single security engineer to find assets, create attack payloads, run an attack, and store a result. However the whole organization can benefit tremendously if artifacts created by a single engineer can be shared with the team.

Even though security engineers usually work independently on their project, the attack patterns are common, and a template created for application A could often be reused for testing a  application B  

Having all testing results in one place is also good from analytics point of view since it simplifies finding common threats and vulnerabilities that could be addressed by Infosec in a centralized manner.