IPRO - PC Magazine Romania, Aprilie 2004
SOLUŢII PENTRU PROGRAMATORII ŞI DESIGNERII WEB

Welcome to ARPANET…

Atacurile prin telnet

Alexandru Ioan Lazăr

În anii ´80, pe vremea când Internetul era abia la început, când nimeni nu auzise de WWW, BBS era cuvântul de ordine. În loc de situri web scrise în HTML, cei care erau în căutare de distracţii printre biţi accesau sisteme bulletin board (BBS - Bulletin Board System) scrise în C. Chiar şi acum, BBS reprezintă o activitate prolifică, iar scrierea unei interfeţe BBS este o provocare interesantă pentru foarte mulţi programatori. Un sistem BBS funcţionează prin comunicarea directă dintre client şi server. Comunicarea se face tot prin intermediul protocoalelor. Numai că în loc de cripticul şi complicatul httpd, aceste sisteme folosesc telnet…

Boom-Boom System

Telnet poate fi folosit nu numai pentru BBS. Telnet este un protocol care, în sine, nu permite cine ştie ce atacuri. Spargerile se produc din cauza vulnerabilităţilor interne ale sistemelor. Hackerii din anii ´80 numeau sistemele nesigure la atacurile telnet Boom-Boom System (aluzie, evident, la BBS).

Am vorbit data trecută despre atacurile de la distanţă. Atacurile prin telnet intră în această categorie, deoarece ele vizează obţinerea accesului de la distanţă; telnet fiind un protocol folosit pentru comunicarea între calculatoare (RFC 856). Telnet funcţionează prin schimbul de pachete pe 8 biţi între staţii. Demonul telnet rulează pe portul 23 (atenţie însă! Sesiuni telnet pot fi lansate pe orice port, iar comunicaţia prin telnet se poate face cu aproape orice demon).

Cazul WebForce

Există mai multe motive din care un atac prin telnet reuşeşte. Primul este software-ul prost configurat, iar în legătură cu acesta există un caz celebru: cazul maşinilor SGI WebForce.

Calculatoarele WebForce au fost fabricate de Sillicon Graphics şi erau livrate cu un sistem UNIX. WebForce au fost apreciate pentru calitatea lor - dar au avut o singură problemă: sistemul de operare avea, implicit, contul lp activ. Contul lp este destinat imprimantei de reţea, şi există pe majoritatea sistemelor UNIX - dar este dezactivat. Dacă ai acces la o staţie Linux, aruncă o privire în /etc/passwd. Vei vedea o linie cu contul lp - şi vei vedea că este neprotejate (nu are parolă) dar este implicit dezactivat.

S-a dezvoltat o întreagă "industrie" de spart maşini WebForce. Totul se făcea lansând o conexiune telnet spre acea maşină:

telnet 192.141.128.51
Connecting to 192.141.128.51…
Connected.
Escape character is ´^[´
login: lp
$  

Staţia atacată prezenta imediat un prompt. Contul lp putea fi folosit ca o "rampă de lansare" pentru a ataca alte staţii din reţea. De fapt, era situaţia perfectă: un cont care nu cerea parolă, pe o maşină UNIX...

Conturile protejate prin parole slabe sunt şi ele vulnerabile. Practic, în momentul în care fişierele cu parole - fie ele Linux, Windows, NetWare sau orice alt sistem - au fost afişate sau obţinute, ele pot fi şi sparte. Dacă un cracker a putut afişa la stdout fişierul /etc/passwd de pe o maşină UNIX, el poate, cel puţin teoretic, obţine acces ca root. De aceea, parolele utilizatorului root trebuie să fie alese cu mare grijă. Regulile sunt binecunoscute: minim opt caracter, litere mari şi mici, cifre şi nu cuvinte din dicţionar. Toate dicţionarele includ numele de Bob (câinele unui prieten, de ce nu?). O asemenea parolă se sparge uşor. Dar nimeni nu-şi botează câinele shg98Abf5.

E drept că, pe un sistem configurat cum trebuie, cazuri ca cele de mai sus sunt foarte rare. Doar o greşeală serioasă poate activa un cont neprotejat prin parolă, iar dacă fişierul de parole a putut fi vizualizat sau descărcat, ar fi cazul să revizuieşti schema de securitate a reţelei tale. Mare atenţie la numărul de tentative de conexiune pe care le permiţi. Dacă un utilizator nu e în stare să nimerească parola din cinci încercări, mai mult ca sigur nici nu o ştie!

Pasărea R… login

rlogin şi rsh permit utilizatorilor de la distanţă să acceseze resursele unei staţii, într-un mod asemănător cu telnet. Numai că, spre deosebire de telnet, lipseşte terminalul virtual. Cu alte cuvinte, programe ca EMACS sau pico nu vor funcţiona. În schimb, ceea ce face foarte periculos aceste servicii este faptul că ele nu cer parola utilizatorilor de pe maşiniile "trusted". Multe sisteme sunt vândute cu wildcard-ul ´+´ activat în fişierul /etc/hosts.equiv, ceea ce implică faptul că, implicit, toate maşinile sunt tratate drept "trusted". În acest fel, se poate obţine accesul folosind orice nume de utilizator existent în fişierul /etc/passwd al ţintei, mai puţin root (iată de ce este serviciul finger atât de periculos…).

Să vedem un exemplu…

$whoami
ftp
$rsh test.ro csh -i
  Warning: no access to tty;
$ rlogin test.ro -l toor
	Welcome to our domain!

Poţi observa că totul a pornit cu mine logat ca ftp (şi nu root, cum aş lucra în mod normal). M-am logat apoi, tot ca ftp. Warning: no access to tty; ar fi trebuit, poate, să mă alarmeze. Dimpotrivă, cu atât mai bine, asta înseamnă că nu există job control… aşa că pot să mă desfăşor "în voie". Probabil că ftp nu are o importanţă atât de mare. DAR contul bin, cont de sistem, are, pentru că este proprietarul unor fişiere importante. De exemplu, dacă m-aş loga ca bin, aş putea avea acces la fişierele pe care acest cont le deţine. Părerea mea? Rsh şi rlogin trebuie dezactivate fără drept de apel - sau, dacă ai neapărată nevoie de ele, permite conexiunea numai de la anumite adrese.

Protecţia

Cum se atinge o configurare corectă? Păi… În primul rând, parolele. Nu aştepta să-ţi fie spartă reţeaua ca să schimbi parolele. Evită folosirea conturilor fără parole (impune folosirea parolelor chiar pe maşini cu Windows9x) şi verifică-le pe cele existente. Schimbarea parolelor ar trebui făcută la cel mult o lună pentru fiecare utilizator. Pentru un administrator, educarea utilizatorilor trebuie să fie o prioritate. Degeaba ai parole gen X0jkgfsIGl dacă sunt pe un post-it lipit de monitor.

În Windows, trebuie să blochezi orice fel de conexiune telnet venită din exterior, cu excepţia cazului în care e nepărată nevoie de ele (iar atunci în nici un caz să nu permiţi logarea ca guest). Telnet nu e încă destul de configurabil pe platforma Microsoft. Părerea mea. În cazul Linux, nu trebuie să iei măsuri atât de radicale. Dimpotrivă, îţi poţi permite chiar să descurajezi atacatorii folosind mascarea parolelor prin shadow şi trecerea unor shell-uri false pentru conturile sistem.

Să le luăm pe-ndelete. Folosirea de shell-uri false pentru conturile sistem înseamnă că vei da conturilor ca bin sau daemon (care nu au nevoie de un shell ´real´ ca sh sau bash) un shell care nu există, de exemplu /bin/false, atât în /etc/passwd cât şi în celelalte fişiere care le cer. În felul acesta, oricine va încerca să se logheze ca bin sau daemon va avea o mică surpriză (un shell care nu există nu poate răspunde la comenzi).

Chiar dacă ei vor obţine acces non-root, rămâne o soluţie. Shadow este, pentru cine nu ştie, un utilitar care permite înlocuirea fişierului /etc/passwd cu un link simbolic pentru adevăratul fişier cu parole care este ascuns bine prin structura de directoare. Dacă un atacator obţine acces ca utilizator non-root, el nu va vedea nici un fişier cu parole (shadow este destul de deştept ca să nu permită deschiderea fişierului real printr-o comandă care invocă link-ul simbolic. De exemplu, cat /etc/passwd | less nu va produce nici un rezultat în afara unui mesaj de eroare).

Telnet mai are o mare problemă: comunicaţia prin el este necriptată. Plasarea unui sniffer (interceptor de trafic) în reţeaua ta va putea dezvălui parolele pe care tu le introduci când te conectezi prin telnet. De aceea, eu prefer să-l înlocuiesc cu ssh (Secure SHell), care foloseşte o comunicaţie criptată, asigurând parolele tale pentru următoarele câteva era glaciare câte vor fi necesare pentru a le sparge.