(This image was created with the assistance of DALL·E 2)

Flipping AES Bits like Pancakes: How a Hacker flipped his way to admin access

Welcome back to our blog series: Vulnerability of the Month! With this series we would like to give you insights into our and our hackers’ daily work and talk about vulnerabilities. By doing so, we hope to help spread important security knowledge about specific vulnerabilities, how to find them, techniques used and by doing that raise awareness to all the vulnerabilities that may still be out there.

If you want to learn more about the series and why we do it this way, please have a look at the first blog post available here: https://www.bugbounty.ch/votm-jan-23/

Author: this month’s blog post was authored by Kaou Tamine

Credits: this month’s vulnerability was reported by Raphaël Arrouas (“Xel”)

Context of the Bug Bounty program

• A time limited, budget limited private program
• Almost the entire Internet exposed footprint of the customer in scope
• Time between launch of the program and submission of the report: 10 days

The system affected

A system with multiple websites supplying various services from job offers, internal file exchange platforms and sensitive database queries interfaces.

The vulnerability as described by the hacker

The path to the hack

The first step is to identify an admin login section that is protected by a WAF (Web Application Firewall). This WAF is easily bypassed by inverting the brackets in the URL link from “/” to “\”.

There are multiple services allowing to authenticate to the backend. One of these shows a [STATE] variable in the URL upon redirection. From a previous vulnerability report containing a source code disclosure, it is known that this variable is encrypted by a symmetric encryption scheme called AES-CBC. If we somehow manage to inject this STATE parameter with the right information, admin access to the backend can be obtained, so the hack is centered around this idea.

By examination of the source code of the backend authenticator, it can be noted that while AES-CBC encryption (a symmetric block cypher) is used for the SSO, there is no tampering verification. This is what enables injecting data into the State parameter without raising flags.

If we look at the AES-CBC op mode:

(Source of image: https://i.stack.imgur.com/bOu8Q.png)

We can see that it is possible to inject whatever content we want into a block by modifying the previous one because the previous block is fed into the next. The hacker states:

The attack impact is limited to full control of one block N in exchange for making block N-1 garbage. Because there are no tampering verification mechanisms, block N-1 does not raise any flags in the backend. As only the username field needs to be injected, modifying one block is enough to break authentication.

To simplify things, the hacker provided a 15-line python script to generate a URL that when clicked on gives full admin access to the backend – that’s all it takes:

Impact analysis

Full admin access to the backend. Since the authentication service comes from a multi-tenant enterprise context, all other clients using the same system or software are vulnerable as well.

Ongoing steps

(Either by us, the customer or in combination):

• Coordinating with vendor to fix the vulnerability
• Issue a CVE advisory

Our perspective

What went wrong?

The main mistake was that AES-CBC wasn’t paired with a HMAC (Hash-based Message Authentication Code) to verify authenticity and correctness. Or the choice of the algorithm was probably not the best – another one not vulnerable to bit flipping attacks could easily have been chosen (Xel proposed AES-GCM).

Having access to the backend source code of the authenticator is not problematic in our view, because cryptographic security models should always assume that the code running the cryptographic protocols is available for the attacker.

The main lesson

For developers: cryptographic protocols should always be taken from an official source, never be implemented by yourself and every building block of a cryptographic protocol has normally its reason to be there. If one of these blocks is not applied, security can break quite easily. There should NEVER be a reason to remove a piece of a protocol to accommodate backend needs.

For the white hat hackers: checking for correct application of cryptographic protocols is always a good idea, cryptography is mostly broken in the implementation…

How can you participate?

Be part of the first Bugs & Beers event taking place in Switzerland! From and for Cyber Enthusiasts! 👾 Register now: bugbounty.ch/events

Interested in finding vulnerabilities? We’re always looking for new hacking talents – please register yourself here: bugbounty.ch/hacker!