Laborator 7

Tematica laboratorului

• Atacuri bazate pe injectare de pachete cu efect de "deturnare" a sesiunii - session hijacking
• Scurta descriere SSH

Atacuri bazate pe injectare de pachete cu efect de "deturnare" a sesiunii - session hijacking

La fel ca si atacurile RST si SYN flood si aceasta categorie de atacuri este bazata pe transmisia de pachete TCP ce contin valori false pentru campurile de adresa, port si numere de secventa sau confirmare. In acest caz nu mai este vizata insa conexiunea in sine ca scop al atacului - terminare sau denial-of-service. Scopul atacatorului este de a utiliza o conexiune deja creata in interes propriu - de unde si termenul de "deturnare" (hijacking). Atacurile se refera la sesiunea de nivel superior a protocolului aplicatie (Telnet, FTP, SIP, etc) ce ruleaza peste TCP, pe care atacatorul incearca sa o foloseasca in interes propriu.
Generic atacul s-ar prezenta in urmatorul mod:

	[SEQ: 0 ]		A ----- SYN ----> B
				A <---SYN/ACK---- B	[SEQ: 0 ACK: 1]
	[SEQ: 1 ACK: 1]		A ----- ACK ----> B
	[SEQ: 1 ACK: 1]		A ----DATA 20B--> B
				A <---- ACK ----- B	[SEQ: 1 ACK:21]

	[SEQ:21	ACK: 1]		E(A)--DATA 10B--> B

Ca exemplu putem considera un atac asupra unei sesiuni Telnet. Telnet reprezinta un protocol prin care se permite controlul la distanta asupra unei statii la nivel de consola. Serviciul de Telnet e deschis la port 23, si ofera unui client conectat posibilitatea de a rula comenzi la nivel de server.
Un atacator actioneaza trimitand pachete spre server ce corespund in campurile sursa cu adresa IP si portul clientului real, au numerele de secventa si de confirmare valide relativ la traficul vehiculat pe conexiunea curenta si contin in partea de date comenzi introduse de atacator. Considerand exemplul generic de mai sus drept o sesiune Telnet, ultimul pas ar putea reprezenta o comanda introdusa de atacator - de exemplu " rm * ", ce ar avea ca efect stergerea tuturor fisierelor din directorul curent la nivelul serverului.
O alta variatie frecventa, posibila prin intermediul Telnet, consta in tentativa de a deschide o noua sesiune de shell interactiva care sa se conecteze la un server rulat de atacator. Ulterior, atacatorul poate folosi aceasta sesiune pentru rularea oricarei comenzi.
Evident, succesul executiei comenzii depinde si de contextul/starea in care se afla sesiunea respectiva. Spre exemplu, daca respectiva comanda ar fi injectata inaintea autentificarii prin parola a clientului real, atunci nu ar avea nici un efect.
Acest tip de atac poate fi realizat asupra a diverse protocoale de nivel aplicatie, gravitatea consecintelor atacului depinzand de starea sesiunii protocolului la executia atacului si de comanda rulata. Pentru a determina deci sansele de succes ale injectarii unei comenzi ar trebui ca atacatorul sa cunoasca, pe langa numerele de secventa (si eventual confirmare) si starea curenta a sesiunii. "Ghicirea" in mod orb a momentului de injectie a mesajelor este deci impractica. Din aceasta cauza un atac de acest gen are loc in mod normal pe baza interceptiei traficului intre cele doua parti. Metodele de protectie se concentreaza pe criptarea acestui trafic, cel putin la nivel de date ale protocolului aplicatie, ceea ce conduce la imposibilitatea determinarii starii curente a sesiunii.

Scurta descriere SSH

Pe langa solutii generale de criptare a traficului, cum ar fi spre exemplu IPSec, pentru diverse protocoale aplicatie exista variante securizate alternative ce aduc aceasta adaugire. In cazul Telnet, un protocol securizat cu aceeasi functionalitate este SSH - Secure Shell (din a carui dezvoltare a fost creata si versiunea sigura pentru FTP: SFTP). Prima versiune SSH dateaza din 1995, iar a doua versiune (incompatibila) din 1996, fiind standardizata insa abia in 2006. Exista patru standarde principale ce definesc modul de functionare a SSH 2.0 dupa cum urmeaza:

• RFC 4251 - Arhitectura SSH
• RFC 4253 - Nivelul protocol transport SSH-TRANS - include in principal functionalitati de autentificare a serverului, si asigura stabilirea unei sesiuni de comunicatie ce asigura confidentialitatea si verificarea integritatii traficului
• RFC 4252 - Nivelul protocol autentificare SSH-USERAUTH - functioneaza peste sesiunea stabilita la nivelul transport asigurand in principal functionalitati de autentificare la nivel de client
• RFC 4254 - Nivelul protocol conexiune SSH-CONNECT - functioneaza peste sesiunea stabilita la nivelul transport si face uz de functionalitatile din nivelul autentificare asigurand multiplexarea de diferite canale logice pe aceeasi sesiune criptata (de exemplu forwarding in mod tunel la trafic de pe diverse porturi)

Pentru claritate, desi in practica nu mai este foarte utilizata, vom prezenta mai intai in continuare functionalitatea de baza a primei versiuni a SSH, ce se constituie intr-un singur protocol. Acest protocol a fost practic impartit in cadrul elaborarii versiunii 2 in cele trei nivele de mai sus.
Prezentam in cele ce urmeaza doua extrase din "SSH: The Secure Shell - The Definitive Guide" - D. J. Barett, R. E. Silverman, 2001 O'Reilly, ce ofera o imagine de ansamblu asupra arhitecturii SSH 1 si a unei sesiuni de comunicatie:

La nivelul clientului este mentinuta o mapare intre cheile publice ale statiilor serverelor (host keys) si identitatea acestora. Initial aceste chei nu exista la nivelul clientului. La o prima conexiune cu un anumit server clientului SSH ii e prezentata o optiune/avertizare explicita de acceptare pentru valoarea inexistenta. Ceea ce este notat in figura de mai sus ca server key este o pereche temporara de cheie publica/privata ce este utilizata in securizarea unei chei de sesiune. Aceasta cheie de sesiune va securiza efectiv traficul pe respectiva conexiune SSH dupa stabilirea acesteia.

Pasii exemplificati mai sus pentru o sesiune tipica SSH s-ar descrie pe scurt in modul urmator:

• Clientul se conecteaza la server, in mod uzual pe portul 22 corespunzator serviciului SSH.
• Serverul trimite catre client versiunea de protocol implementata.
• Clientul trimite catre server versiunea de protocol implementata. In acest punct daca exista incompatibilitati de protocol ce nu pot fi solutionate se va renunta la conexiune
• Serverul se identifica prin trimiterea cheii publice persistente (host key) la care adauga parametrii necesari stabilirii unei sesiuni: cheia publica temporara pentru securizarea cheii de sesiune (server key), un nonce (cookie) anti-spoofing si o lista de algoritmi de criptare si autentificare suportati din care clientul poate alege variante pentru sesiunea curenta. Asupra cheilor si a cookie-ului trimis fiecare din cei doi participanti la conexiune va calcula un hash pentru identificarea sesiunii curente - SessionID, ce va fi utilizat in operatii de protocol care nu sunt explicit redate in figura de mai sus.
• Cheia de sesiune este generata de client, criptata cu ambele chei publice primite de la server, si trimisa impreuna cu valoarea de cookie primita si cu o selectie de algoritmi. Utilizarea cheii persistente - host key - in criptare confirma identitatea unui server. Utilizarea cheii temporare a serverului - server key - se face pentru a nu compromite sesiunile anterioare in cazul in care acestea ar fi inregistrate si partea privata a cheii persistente ar fi descoperita (se asigura PFS - Perfect Forward Secrecy).
• Serverul va trimite o confirmare ce va fi criptata cu noua cheie de sesiune, dupa care traficul in continuare va decurge criptat.

Pasii pana in acest punct corespund in mare si protocolului de nivel transport din cadrul versiunii 2 a SSH. Din acest punct incepe faza de autentificare a clientului, ce poate decurge in mod diferit in functie de algoritmul de autentificare incercat de client. In sesiunea descrisa mai sus e exemplificata o autentificare bazata pe cheie publica RSA, ce decurge in modul urmator:

• Clientul trimite un nume de cont pe care doreste autentificarea/logarea.
• Serverul trimite un raspuns prin care solicita autentificarea pentru respectivul cont.
• Clientul trimite cheia publica asociata numelui respectiv (de fapt un rezumat al acesteia) pentru validare.
• In cazul in care validarea e incorecta - cheia nu e asociata contului la nivel de server se va trimite un raspuns negativ (aceasta asociere e stabilita de un administrator la configurarea serviciului si crearea conturilor)
• Clientul poate reincerca trimiterea unei alte chei.
• In cazul in care serverul valideaza cheia in cauza - exista asocierea cu respectivul cont, si nu exista alte restrictii de autorizare impuse de configurari cum ar fi interzicerea conectarii de la o anume adresa, va trimite un raspuns afirmativ clientului. La acest raspuns este adaugat si un challenge pentru a dovedi ca respectivul client are in posesie si cheia privata. Challenge-ul consta intr-un string random criptat cu cheia publica a clientului.
• Clientul va decripta stringul primit, il va combina cu identificatorul de sesiune SessionID, va realiza un hash si il va trimite catre server pentru validare. Combinarea cu identificatorul de sesiune se realizeaza pentru evitarea atacurilor de tip replay. Aplicarea hashului se realizeaza pentru a evita o intentie de posibil atac din partea unui server corupt ce ar putea trimite un mesaj important in locul stringului (de genul altei parole, etc) captat deja ca fiind criptat din partea respectivului client. Altfel, clientul, in lipsa hashului, ar decripta acest mesaj si trimitandu-l inapoi ar putea fi interceptat de atacator.
• Serverul va calcula hashul pe baza datelor proprii - stringul si identificatorul de sesiune si in caz de potrivire va confirma autentificarea cu succes a clientului.

Acesti pasi s-ar incadra cu aproximatie si in varianta SSH 2 in cadrul nivelului de autentificare. Alte metode de autentificare acceptate de versiunea 2 a SSH ar fi cele bazate pe parola (simpla autentificare pe baza transmiterii pe canalul criptat a unei parole pentru care e mentinuta o asociere cu un cont la nivel de server) sau pe baza de hostname. Pentru mai multe detalii legate de aceste metode si in ceea ce priveste functionarea ulterioara a nivelului protocol conexiune, unde are efectiv loc traficul criptat la nivel de aplicatie in urma autentificarii cu succes recomandam consultarea RFC-urilor mentionate mai sus.

Cateva diferente principale intre secventa descrisa si elementele din versiunea SSH2 a protocolului, ar fi urmatoarele:

• In versiunea 2 nu se mai foloseste o pereche de cheie publica/privata temporara la nivel de server pentru criptarea si schimbul cheii de sesiune intre participanti ci se aplica un mecanism Diffie-Helmann in acest sens.
• Cheia de sesiune e regenerata la anumite intervale de timp - sau de trafic intre participanti
• Algoritmii pentru verificarea integritatii datelor transmise (ce nu au mai fost mentionati) sunt imbunatatiti in versiunea 2. In versiunea 1 e folosita o simpla suma de control; in versiunea 2 se folosesc variante criptografice in acest sens (HMAC-SHA1 e standardul cerut cerut in mod obligatoriu).
• Negocierea algoritmilor utilizati se face in ambele sensuri, existand posibilitatea de utilizare de algoritmi diferiti pentru criptare si verificare integritate de la client la server fata de directia inversa a traficului.
• Este suportat un mecanism de certificare a cheilor publice.

Recent, a fost descoperit unul dintre putinele atacuri cu un potential impact semnificativ asupra SSH 2, atacul Terrapin. Acest atac este fezabil in contextul in care un atacator are posibilitati de monitorizare a traficului in retea si de actiune ca man-in-the-middle asupra acestuia, prin injectare si oprire de pachete. Ca detaliu privind transportul mesajelor din fluxul de initiere a unei conexiuni SSH, acesta este organizat printr-un protocol intern specificatiei, SSH Binary Packet Protocol (BPP), in care fiecarui mesaj i se aplica un numar de secventa intern specificatiei pornind de la 0, pentru o contorizare a mesajelor trimise, si respectiv primite. Acest contor are tocmai rolul de a verifica daca mesajele sunt desincronizate, sterse sau reutilizate odata ce incepe a doua faza criptata a conexiunii, conform descrierii de mai sus, fiind parte a verificarii de integritate. Problema consta in faptul ca respectiva contorizare incepe din faza nesecurizata si continua fara a fi resetata in faza securizata. Astfel un atacator cu posibilitatile mentionate poate injecta un mesaj in faza nesecurizata si ulterior opri un mesaj in faza securizata, aceasta actiune nefiind observata la nivelul contoarelor respective ce vor ramane sincronizate. In anumite variante de securizare, dependent de cifrul (algoritmul de criptare) folosit, primul mesaj din faza securizata reprezinta parametri extinsi ce au rol in securizare. Daca acest mesaj e oprit, atunci se poate interveni cu un atac ulterior pe cifrul respectiv. O descriere mai detaliata a atacului e disponibila in pagina oficiala de prezentare a acestuia.

In prezent se afla in dezvoltare o versiune noua a protocolului, SSH 3 bazata pe QUIC si TLS 1.3 ca varianta de protocol de transport. Aceasta este inca in faza experimentala, mai multe informatii fiind disponibile in pagina dedicata.