Automating REST Security Part 3: Practical Tests for Real-World APIs

If you have read our two previous blogposts, you should now have a good grasp on the structural components used in REST APIs and where there are automation potentials for security analysis. You've also learned about REST-Attacker, the analysis tool we implemented as a framework for automated analysis.

In our final blogpost, we will dive deeper into practical testing by looking at some of the automated analysis tests implemented in REST-Attacker. Particularly, we will focus on three test categories that are well-suited for automation. Additionally, we will look at test results we acquired, when we ran these tests on the real-world API implementation of the services GitHub, Gitlab, Microsoft, Spotify, YouTube, and Zoom.

Author

Christoph Heine

Overview

• Part 1: Challenges in Analyzing REST Security
• Part 2: Tool-based REST Analysis with REST-Attacker
• Part 3: Practical Tests for Real-World APIs

Automating REST Security Part 2: Tool-based Analysis with REST-Attacker

Our previous blog post described the challenges in analyzing REST API implementations. Despite the lack of REST standardization, we learned that similarities between implementations exist and that we can utilize them for tool-based REST security analysis.

This blog post will now look at our own implementation. REST-Attacker is a free software analysis tool specifically built to analyze REST API implementations and their access control measures. Using REST-Attacker as an example, this blog post will discuss how a REST security tool can work and where it can improve or streamline the testing process, especially in terms of automation.

Author

Christoph Heine

Overview

• Automating REST Security Part 1: Challenges
• Automating REST Security Part 2: Tool-based Analysis with REST-Attacker
• Automating REST Security Part 3: Practical Tests for Real-World APIs 

Automating REST Security Part 1: Challenges

Although REST has been a dominant choice for API design for the last decade, there is still little dedicated security research on the subject of REST APIs. The popularity of REST contrasts with a surprisingly small number of systematic approaches to REST security analysis. This contrast is also reflected in the low availability of analysis tools and best security practices that services may use to check if their API is secure.

In this blog series, we try to find reasons for this situation and what we can do about it. In particular, we will investigate why general REST security assessments seem more complicated than other API architectures. We will likewise discuss how we may still find systematic approaches for REST API analysis despite REST's challenges. Furthermore, we will present REST-Attacker, a novel analysis tool designed for automated REST API security testing. In this context, we will examine some of the practical tests provided by REST-Attacker and explore the test results for a small selection of real-world API implementations.

Author

Christoph Heine

Overview

• Automating REST Security Part 1: Challenges
• Automating REST Security Part 2: Tool-based Analysis with REST-Attacker
• Automating REST Security Part 3: Practical Tests for Real-World APIs 

Shadow Attacks … the smallest attack vector ever

In July 2020, we introduced a novel attack class called Shadow Attacks. In our recent research, we discovered a new variant of the attack which relies only on an Incremental Update containing a malicious trailer.
A proof-of-concept exploit working on Foxit (Version: 11.0.1.49938) can be downloaded here.

ALPACA: Application Layer Protocol Confusion-Analyzing and Mitigating Cracks in TLS Authentication

In cooperation with the university Paderborn and Münster University of Applied Sciences, we discovered a new flaw in the specification of TLS. The vulnerability is called ALPACA and exploits a weakness in the authentication of TLS for cross-protocol attacks. The attack allows an attacker to steal cookies or perform cross-site-scripting (XSS) if the specific conditions for the attack are met.

Security Analysis in an OpenID Connect Lab Environment

In this post, Christian Fries shows an approach to unveil security flaws in OpenID Connect Certified implementations with well-known attack methods. One goal of the master's thesis Security Analysis of Real-Life OpenID Connect Implementations was to provide a platform for developers and security researchers to test implementations in a reproducible and maintainable OIDC lab environment.

We included six OpenID Provider (OP) and eight Relying Party (RP) services in the lab environment. For the comprehensive security analysis, we tested the implementations against eleven Relying Party attacks and seven OpenID Provider attacks in different variations with our tool PrOfESSOS. In addition, we carried out manual tests as well. We have disclosed twelve implementation flaws and reported them to the developers in a responsible disclosure process.

Two developer teams fixed (✔) the vulnerabilities before the deadline of the master's thesis. One Redirect URI Manipulation vulnerability was rejected (✖). This particular case can be permissible for only one registered URI for reasons of interoperability and fault tolerance. We informed three further development teams (✦).

Name	Vulnerability	Fixed	CVE
MITREid Connect	PKCE Downgrade Attack	✦
mod auth openidc	ID Spoofing, JWKS Spoofing	✔
node oidc-provider	Redirect URI Manipulation	✖
OidcRP	Replay Attack	✦
phpOIDC	Message Flow Confusion, ID Spoofing, Key Confusion	✦
pyoidc	Replay Attack, Signature Manipulation, Token Recipient Confusion	✔	CVE-2020-26244

We explain the method of how we have archived this result in the following sections.

Attacks on PDF Certification

In recent years, we have presented How to Spoof PDF Signatures and Shadow Attacks: Hiding and Replacing Content in Signed PDFs, which describe attacks on PDF signatures under various attack scenarios. The attacks focused on so-called approval signatures. However, in addition to signing PDFs, the PDF specification also specifies the certification of documents, also known as certification signatures.

To close this research gap, we performed an extensive analysis of the security of PDF certification. In doing so, we developed the Evil Annotation Attack (EAA), as well as the Sneaky Signature Attack (SSA). The attack idea exploits the flexibility of PDF certification, which allows signing or adding annotations to certified documents under different permission levels. Our practical evaluation shows that an attacker could change the visible content in 15 of 26 viewer applications by using EAA and in 8 applications using SSA by using PDF specification compliant exploits. We improved both attacks’ stealthiness with applications’ implementation issues and found only two applications secure to all attacks.

We responsibly disclosed all affected vendors. Together with the CERT-Bund (BSI), we supported the vendors in developing suitable countermeasures. The attacks are documented in CVE-2020-35931, CVE-2021-28545 and CVE-2021-28546.

Full results are available in our paper, vulnerability report and on our website.