Butoneală distructivă – „Suntem atacați!”
S-au pus „Butoniștii” pe noi …
Zi de zi citești la radio și auzi la TV tot felul de întâmplări despre noua generație de butoniști rău intenționați, care au atacat te miri ce site al unei instituții sau mari corporații dar cu noi?! cu noi ăștia mai mici cum rămâne??! noi cu ce am greșit?
Să trec la subiect
Ieri îmi butonam email-ul și nu am putut să nu observ un mesaj foarte interesant.
Mesajul venea de la cert[at]woorifis.com, CERT-WFG.
CERT?
În caz că vă întrebați ce este acest CERT, este un departament specializat pe atacuri cibernetice, sub o denumire mai pompoasă și din care nu reiese cu punct și virgulă domeniul lor de „cercetare”; CERT-WFG = „Computer Emergency Response Team for Woori Financial Group”
CERT…dar Woori Financial Group???
În primul rând trebuie să recunosc că nici eu nu știu, chiar dacă în mesaj există totuși o descriere. 
„The infrastructure of Woori Financial Group is classified as „National Security Objective Facility – class A” and unauthorized access to this facility is strictly prohibited by related laws and regulations. ”
Ce vrea CERT-WFG de la mine?
Să mă înștiințeze într-o manieră oficială că unul din IP-urile serverelor pe care le administrez, le-a atacat instituția, după cum reiese din mesajul de mai jos:
„I’m a security manager of CERT-WFG (Computer Emergency Response Team for Woori Financial Group) and this is an official warning message against unauthorized access trial from IP addresses you managenot.
We perform 24/7 security monitoring, threat assessment, investigation and response for threats or attacks to protect information asset of Woori Financial Group.
We have received an unauthorized access trial report from our information security systems as shown below: […]”
Ironia?
În primul rând, țin să le mulțumesc pentru că mi-au pus la dispoziție extraordinar de multe informații care să mă ajute în remedierea problemei pe care o au/o am. (Sunt ironic).
Mailul conținea un tabel:
| Time of attack | Attacker | Victim | Name of Attack |
| 2015-01-22 05:26 | ip-ul serverului meu | 1.209.X.X | UD_PUT_METHOD |
În coloana „Victim” este … victima ( ip-ul lor ) … sau mai bine spus jumătate de victimă, pentru că așa cum bine observați, „.X.X” nu sunt mascările făcute de mine, ci chiar așa am primit mailul; bine măcar că mi-a dat clasa, putea să-mi spună doar portul;
De asemenea numele tipului de „Attack” mie nu-mi spune nimic. După câteva butoneli pe google nu am aflat mare lucru dar am trecut la treabă.
Pasul 1: M-am logat pe server ssh … mă uitam la un ecran negru ( fereastra de Putty ) și nu știam de unde să o apuc, din cauza … uimirii referitoare la lipsa de informații (ne)obținute din mesajul lor.
Pasul 2: Pornesc un tcpdump, exclud sesiunea mea, constat prea mult trafic de analizat, mă opresc!
Pasul 3: Pornesc din nou un tcpdump, fac grep după „jumătatea de victimă”, nici un rezultat, mă opresc!
Pasul 4: Gândesc … ( cel puțin așa cred eu ), dacă eu „atack”, atunci pleacă de la mine;
Unde? Încerc clasic prin ghicit SMTP, FTP, … HTTP?? Da, tcpdump-ul pe 80 mă pune pe gânduri pentru că nu e normal să am atât de mult trafic care pleacă din serverul meu către destinație port 80 ( nu face nimeni „brows-ing” de pe serverul meu ); Mă gândesc că ar putea fi anumite „iframe-uri” pe care clienții mei le au pe site-uri…dar atât de mult trafic???
Pasul 5: Am descoperit destinația atacului, vag în internet :), concret în ip-uri aleatoare, cu un singur lucru în comun și anume portul destinație TCP/80; prin urmare am rulat lsof să vad ce fișier din serverul meu a inițiat o conexiune pe acest port.
Începe spectacolul!
Fișierul are o denumire aleatoare, dar userul, userul este cel în care am văzut „lumina”! Am rulat din nou lsof pentru a afișa toate instanțele utilizatorului cu pricina, și am constatat că … nu mă ajută cu nimic, momentan… 
Atât de repede se închideau procesele deschise încât nu apucam să văd ce și cum, de unde pleacă, până încercam eu să închid PID-ul, el deja nu mai exista, altul nou fiind creeat și noi conexiuni deschise și închise și … fișier inexistent…
Șoarecele și pisica
Cum aflu ce executabil/fișier a inițiat procesul dacă procesul nu mai există ?
… 1 ora…butoneală…inutila….nimic în google…nimic în minte…
Pasul 6: Ma gândesc că poate printr-o „portiță” ( backdoor ), execută aceste comenzi, și mă duc în folderul în care găsesc activitatea utilizatorului, întrerup accesul din exteriorul serverului la el prin .htaccess.
Mă uit un folder „mai sus” și constat că mai sunt altele cu structură asemănătoare ( 1111, 1122, 1133, 1144, 1155, 1166, 1177, 1188 ), generez un htaccess pentru fiecare, să nu mai poată fi accesat din internet.
Rezultatul?
Atacurile continuau să plece de la mine de pe server…
Pasul 7: Schimbăm mentalitatea!
Rerouting! ( Ca la navigație )
Ma gândesc cum e posibil acest lucru?!; cum aș face eu acest lucru?! îmi vine în minte următoarea modalitate: Creez un script care să execute un atac scurt…generez un nou fișier care să facă același lucru și care să șteargă fișierul care l-a generat, îl execut….( „Catch me if you can!” ).
Soluția pe care am văzut-o era clară ca lumina zilei: să găsesc o modalitate mai rapidă să închid procesul înainte să dispară și înainte să execute noul fișier!
Pasul 8: Butonăm iar pe google și găsim rezultatul!
Omorâm toate procesele unui utilizator dintr-o singură comandă!
GATA! L-am dovedit!
Pasul 9: Mai facem o verificare generală! Totul pare în regulă, mergem la culcare…nu înainte să anunțăm responsabilul de cont (Utilizatorul) că trebuie să verifice care este breșa de securitate în WP-ul lui ( WordPress ).
O noua zi
Dimineața o iau de la capăt…verificare de rutină…nimic nou…totul pare în regulă..
Mult prea frumos sa fie adevărat?
Hai să mai rulăm un tcpdump…
Norocul prostului?
Nu introduc prea multe argumente în tcpdump și traficul rezultat conținea și altceva decât îmi doream…dar STOP!!! îmi sare în ochi o secvență care conține un IP!
IP-ul îmi aparține, dar nu îl folosesc, nu l-am oferit niciunui client, este liber! De ce am trafic către el??? Și pe portul 25 SMTP!
Clar ceva este în neregulă și încep să filtrez mai bine cu tcpdump inspectând doar traficul pe care îl face acest ip.
O nouă zi / Un nou atac !
Atacul se oprește…modific filtrarea lăsând tot traficul dinspre și către ip-ul nefolosit de pe server și constat că ???!!! AM O NOUĂ ZI DE RAHAT!
Adică nu s-a oprit nimic, e un DDoS (care vine de la mai multe ip-uri), aparent în clase diferite.
Reiau strategia cu „Pașii” și încep cu „Pasul 1: Al cui e IP-ul?”
Vă spune ceva „Sharktech”? Dar SHARKTECH INC – Las Vegas – abuse@sharktech.net ?
Nici mie …
Pasul 2: Verific al 2 -lea IP…ghiciți? Vă spune ceva sharktech ? DA! Îmi chinuie serverul de la un alt IP; Verific mai aproape toate IP-urile … da, toate aparțin sharktech.net
Pasul 3: Scriu și eu un mail asemănător celor de la CERT-WFG, pentru că am văzut că se practică în ultima vreme și dacă ține și se ocupă cineva, bine, dacă nu, nu,…muncim mai mult!
Pasul 4: Ne bazăm pe propriile forțe și continuăm butoneala; Blocăm o clasă, o blocăm și pe a 2-a și pe a 3-a…și mă plictisesc că tot apar clase noi, ip-uri noi!
Intuiție
Extind tcpdump-ul la mai multe IP-uri de pe server, nealocate, și constat că atacul îmi încerca conexiuni pe TCP/25, pe toate ip-urile mele, aleator, de la ip-uri aleatoare, toate aparținând sharktech.net.
Pasul 5
Butonează-l pe google
Și află cum găsești ip-urile care aparțin ASN-ului lui sharktech!
… mă enervez … realizez că pierd vremea butonând când cineva deja știe răspunsul;
Sună un prieten
Q: Livache cum aflu care sunt [blah, blah, blah…]
A: 1. Deschide o sesiune telnet către route-views.oregon-ix.net
2. Folosește utilizatorul „rviews”
3. Rulează comanda: show ip bgp regexp _[ASN-numarul AS]$
„Output” de mii de linii????! Mă omoară, prin urmare salvez sesiunea într-un log, selectez „output-ul”, îl arunc într-un fișier pe linux, extrag cu awk doar coloana care-mi trebuie ( mă mai ajut un pic și de grep ), generez un nou fișier numai cu clasele de ip-uri care aparțin de ASN-ul celor de la SHARKTECH.
Pasul 6: Constat că am muncit degeaba, deoarece aveam un tab deschis în Firefox, din butoneală, care îmi generase ce doream: [urmează să reeditez];
Pasul 7: Foarte multe clase consecutive mă duc cu gândul că dacă generez în firewall-ul meu 12090 de linii, omor procesorul degeaba, așa că încerc să sumarizez clasele folosind bineînțeles un calculator online de subneturi ( http://jodies.de/ipcalc – cred că mă bucur de el de mai bine de 7 ani! );
Pasul 8: Generez liniile de firewall ( IPTABLES ) cu DROP-urile aferente claselor subnetului cu pricina.
Pasul 9: Butonez iar mailul și mă minunez citind NOU-ul mail de la…cine credeți? kapil[at]sharktech.net, în care mă anunță că nu poate face nimic referitor la atac, eu fiind o victimă colaterală, destinația atacului fiind chiar ip-urile pe care eu le blochez!
Cum se face ca toți sunt victime și eu nu contez pentru nimeni???
Mail:
„Hi
We are getting multiple complains for the IPs in question so we have been keeping watch on it and it looks like that some attacker is actually spoofing our client’s IP address and sending requests to different hosts around the world which in return respond back to our client’s server/IP and basically attacking it.
Thanks
Kapil Jain
Sharktech Inc.”
Explicatie
Acest tip de DDoS este din ce in ce mai rar intalnit ( spune prietenul meu Livache ).
Cineva spofeaza ip-urile sharktech-ului si imi trimite mie si probabil inca la cateva sunte/mii de destinatii cereri pe portul 25 ca si cand ar veni de la sharktech, serverele noastre raspunzand in consecinta chiar ip-urilor clientilor lor si in acest mod, sute de mii/ milioane de „raspunsuri” ( pachete, in cazul de fata nesolicitate ), ajung la ip-urile sharktech.
Concluzia?
sharktech victima finală!
EU? Timp pierdut și victimă colaterală!
Mâine oare ce mai apare?????
