Full path disclosure in pnl.ro

Azinoapte in timp ce ma documentam pentru un articol am ajuns pe Wikipedia si de acolo am urmat un link ce ducea spre pnl.ro, link care a scuipat ditamai eroarea din Laravel:

Mi s-a parut destul de suspect faptul ca pe un site atat de important astfel de erori sunt la liber si imediat m-am gandit ca cineva nu si-a facut meseria cum trebuia si astfel n-a securizat sistemul asa cum trebuia s-o faca. Pentru 99% dintre utilizatorii de internet eroarea asta nu reprezinta nimic din noment ce unicul ei scop e sa informeze programatorul de eventuale probleme de implementare sau compatibilitate, asa ca ea nu trebuia sa fie publica daca gandim strict logic si nu prin prisma aspectelor de securitate.

Vazand-o mi-am dat seama imediat ca in spatele ei se poate afla un „Full Path Disclosure” (FPD) si astfel m-am uitat in sursa, fapt ce mi-a confirmat suspiciunile:

Aplicatia web pe care se bazeaza siteul pnl.ro ce e construita in jurul Laravel se afla in directorul /home/adminpnl, iar adminpnl e de fapt numele de utilizator. Probabil ca veti spune ca e o informatie complet irelevanta pentru ca nu-i chiar asa mare branza faptul ca s-a putut afla asa de usor calea si userul, insa am sa repet din nou ca o astdel de informatie e irelevanta pentru 99% dintre utilizatori, insa pentru expertul de securitate informatica orice informatie oricat de irelevanta ar parea conteaza enorm.

Si am s-o iau pe rand ca sa ma intelegeti mai bine. Structura directoarelor mi-a sugerat faptul ca panoul de control utilizat pe pnl.ro e cPanel, fapt confirmat usor dupa ce am accesat siteul pe portul securizat de cPanel si am fost redirectionat catre https://ns2.pnl.ro:2083/ unde se afla pagina de login a cPanel.

Ori confirmand faptul ca vorbim de cPanel atunci avem o serie de certitudini majore:

• Numele de utilizator adminpnl se asociaza cu contul de cPanel si astfel permite accesul via cPanel si posibil WHM cu parola corecta.
• Acelasi nume de utilizator functioneaza si pentru contul de FTP principal si stiind numele de utilizator orice atac de bruteforce e pe jumatate reusit.
• Acelasi nume de utilizator e valid si pentru contul de email principal si cum in cPanel Horde permite sa navighezi si sa citesti toate directoarele de sub contrul principal nici nu e nevoie sa afli sau sa resetezi parola conturilor de email pentru ca le poti accesa doar avand acces la contul principal. Unde mai pui faptul ca se pot crea foarte usor pentru conturile de email filtre de forward care sa permita monitorizarea lor fara a lasa prea multe urme.
• Pe cPanel numele de utilizator e asociat cu acces privilegiat la MySQL, ceea ce presupune faptul ca stiind care-i numele de utilizator, la fel ca si in cazul unui atac de tip bruteforce, sa faci un blind SQL injection e pe jumatate reusit. De fapt probabil ca cel mai usor mod de a afla parola e printr-un blind SQL injection.
• Exista posibilitatea ca acelasi nume de utilizator sa aiba si acces de SSH si astfel o eventuala expunere de parola prin bruteforce sau blind SQL injection poate sa permita acces SSH cu care s-ar putea instala o serie de scripturi si programe rau intentionate care sa expuna si mai multe informatii.

Da stiu, suna fantezist pentru multi, insa si „Panama Papers” sau scurgerea de date in cazul „Hacking Team” au pornit tot de la astfel de informatii.

Insa treaba nu se opreste aici, pentru ca de curiozitate m-am apucat sa verific si alte aspecte de securitate in ceea ce priveste serverul pe care e gazduit siteul pnl.ro si am aflat urmatoarele:

• Porturile de FTP si SSH sunt cele implicite ceea ce face serverul sa pice victima atacurilor de bruteforce aleatorii in mod constant
• cPanel e configurat pe hostname ns2.pnl.ro ceea ce inseamna ca si nameserverele sunt gazduite pe acelasi server, ba mai mult folosesc acelasi IP ceea ce nu e doar ineficient din punct de vedere tehnic, dar e si absurd.
• Orice eroare 404 cauzeaza un FPD ceea ce sugereaza faptul ca orice eroare generata pe Apache poate sa expuna informatii critice.
• Cel putin contul de cPanel/WHM e gestionat de Razvan Sfat (razvan.sfat@gmail.com) lucru pe care l-am aflat dupa ce am fortat Apache sa scuipe o eroare 400 si confirmat de SOA din zona DNS:

Din nou s-ar putea considera faptul ca informatia asta n-are nicio relevanta, insa are foarte mare relevanta pentru ca stiind emailul personal al webmasterului sau administratorului de sistem e relativ usor de facut un spoof (chiar si cu SPF pe zona de DNS) si trimis niste emailuri de spear phishing sau mai stiu eu ce alte alea de inginerie sociala prin adrese @pnl.ro sau cine stie ce altfel de metode mai mult sau mai putin ortodoxe.

• Folosindu-ma de adresa de email in formatul de pe zona de DNS am aflat faptul ca pe server mai e o zona de DNS care duce asociaza domeniul mypnl.ro cu IP-ul 93.115.93.187 de la Voxility, unde pe serverul web pare sa fie doar un formular banal de login scris in PHP ce poate sa aiba adevarate vulnerabilitati de SQL injection.

Am generat si aici un bad request pe serverul de Apache fapt ce a expus versiunea de Apache folosita de server si sistemul de operare, din nou informatii critice care trebuiau sa fie ascunse:

Nu stiu zau de ce ar mai vrea cineva sa foloseasca Apache 2.2 in zilele noastre, insa stiu sigur ca versiunea instalata pe server nu a mai fost actualizata de o gramada de ani si are o serie de vulnerabilitati.

• M-am uitat prin codul sursa al paginii de login si am luat la revizat fisierele Javascript accesibile public si am remarcat ca sunt expuse o serie de URL-uri ce teoretic ar trebui sa verifice prin AJAX validitatea unor date introduse de la tastatura, date ce odata validate sunt trimise catre serverul de MySQL:

Ori treaba asta e de o importanta majora pentru ca stiind caile si caracterele permise precum si limita lor orice tentativa de SQL injection e cu un pas inainte.

• Versiunea daemonului de SSH ce ruleaza pe serverul pe care se afla mypnl.ro e OpenSSH 5.3, o versiune neactualizata la fel ca si cea de Apache si care s-ar putea sa aiba la randul lui o serie de vulnerabilitati.

Desigur o astfel de investigatie poate sa continue folosind si metode mai putin ortodoxe si apeland la solutii si optiuni care sunt la limita legii, insa am sa ma opresc aici pentru ca nu doar ca n-am niciun motiv sa continui in vreun fel, dar si scopul siteului e sa ofere informatii la nivel educativ, iar ceea ce prezinta o sa ramana mereu la stadiul de PoC (Proof of Concept).

E interesant faptul c-am putut sa aflam atat de multe pornind de la o banala eroare nu?