Mitigate Baron SameEdit (CVE-2021-3156) vulnerability

Anatomy of a brute force attack

By Don McCrady

When software developers sit down to build an application, more often than not they use pre-compiled binaries, pre-built packages, or Docker images to get a running start, perhaps not knowing — or feeling the need to know — much about the underlying software stack vulnerabilities leave them open to attack.

When popular software like NGINX gets deployed to millions of machines, developers start to take its security posture for granted. While “buffer overflows” are a popular keyword in cybersecurity circles, most developers don’t intuitively know exactly what those vulnerabilities look like in real life. This is despite the fact that every major software vendor considers memory vulnerabilities the most dangerous and most common vulnerabilities out there.

This lack of intuition is forgivable because for most, the software stack either works or it doesn’t. Few concretretely come face to face with an exploit through a buffer that isn’t bounds-checked correctly.

You may have heard of the famous Secure Development Lifecycle (SDLC) that Microsoft created in the early 2000s in response to security threats against Windows. If we look at the very first step they took, which was to replacebanned APIs with safe versions, nearly all APIs have to do with memory bounds safety.

Having a better understanding of why buffer overflows are the most talked about vulnerability in cybersecurity, can help users avoid serious exploits that allow hackers to send packets to servers and take over machines remotely without injecting any code at all, thereby completely bypassing antivirus and antimalware scanners which look for “bad code”. This technique allowed hackers to compromise innumerable Linux, Windows and Macintosh systems.

This sort of exploit, known as a Return-Oriented Programming (ROP) attack, allows hackers to use instructions already present in the victim’s software stack for their own purposes. Firewalls, scanners and some moving-target defenses cannot detect or prevent these attacks because nothing malicious is being injected on the victim machine, and all code that is executing is already vetted, scanned, approved, validated, certified and even perhaps signed.

Hackers can use this ROP methodology to read and write data, and grant themselves root shell access to a vulnerable system. From there, the sky’s the limit. If they’ve happened on a cluster of identical servers, they can move across each one and turn an exploit on one into an exploit on hundreds or thousands of others.

Exploiting the seemingly unexploitable

How can hackers manage to use a single buffer overflow to completely take over the victim? Aren’t there counter-measures such as ASLR and Stack Canaries meant to prevent and detect such exploits?

The answer lies in a more advanced style of ROP called a Blind ROP attack (may also be called a Brute-Force ROP attack.)

You see, while ASLR and Stack canaries do indeed prevent a static ROP (one that is constructed with predetermined fixed locations), they cannot prevent an attack wherein the attacker’s first step is to read and discover precisely what your Stack Canaries are, find where your gadgets (snippets of useful code) are, and where useful functions (such as fwrite, read, strcpy, etc.) are.

Uncover how all this possible, and how to prevent it

You might think such brute force mapping and exploiting would take days or weeks, giving you plenty of time to discover telltale crashes or other odd system behaviour. But a blind ROP attack — one in which the hacker uses trial and error on a live target server — can be accomplished in as little as two hours (and in our example, accomplished within minutes.)

The process is not as complicated as it might first appear, and even hackers with modest know-how can pull it off. Preventing these attacks takes a sophisticated approach that can reliably obfuscate the software stack faster than the attacker can discover it.

We’ve outlined the steps hackers use to exploit ROP vulnerabilities in a new Polyverse white paper, “Blind ROP Attack on NGINX”. It’s a comprehensive look at how machine-level exploits, a few simple tools and a little time can be used to compromise any system.

If you’re impatient and want to see the attack happen live, you can run your own attack right within your browser in our online playground:

Want to discover if your systems have been compromised by ROP or BROP? Check out Zerotect, an open source detection agent that catches attacks with a 0% false-positive rate, even if it’s the first time in history the attack occurred. Blind ROP is only one example of an attack that can be detected. If you can discover your own attacks you could be rewarded. With our Zero Day Rewards Program you could receive up to $1,000 per attack submitted to us. To learn more and read the terms of the program click here

Interested in learning more?

Be the first to hear about the latest product releases and cybersecurity news.

The registered trademark Linux® is used pursuant to a sublicense from the Linux Foundation, the exclusive licensee of Linus Torvalds, owner of the mark on a world­wide basis.