Două remedii de securitate
Săptămâna trecută, Joomla! Proiectul a lansat Joomla! 3.7.4, o versiune care a inclus două remedii de securitate, una dintre ele evaluată ca fiind o problemă de "severitate severă" legată de aplicația de instalare a CMS. În buletinul inițial publicat în Centrul de Securitate , nu s-au dezvăluit detalii suplimentare despre vectorul de atac real - dar, deoarece vectorul a fost dezvăluit de reporterul inițial, Hanno Böck, într-o convorbire la conferința Def Con, aș dori să împărtășesc Unele perspective din perspectiva echipei de securitate.
Vremurile bune
Până acum, instalarea unei aplicații bazate pe web, cum ar fi Joomla! A fost un proces mai mult sau mai puțin simplu: încărcați fișierele pe serverul dvs. web, aprindeți aplicația de instalare din browserul dvs. sunând la adresa URL corectă, introduceți datele dvs. de acreditare și alte detalii de configurare și sunteți gata să plecați. În timpul acestui proces, nu a fost necesară nici o dovadă a proprietății pentru serverul web, nici o autentificare nu a avut loc - și aceasta a fost perfectă până acum, deoarece orice atacator avea nevoie de două informații cheie:
Atacatorul trebuie să știe când aplicația este complet încărcată, dar nu este încă instalată - în mod normal, aplicația nu va mai fi în această stare mai mult de câteva minute, ceea ce o face și mai greu
Atacatorul trebuie să cunoască locația exactă (URL) a aplicației web pentru a rula programul de instalare
Dacă un atacator ar putea obține aceste două informații, un exploit este un lucru destul de ușor:
Rulați programul de instalare utilizând o bază de date externă aflată sub controlul dvs. pentru că nu veți putea să acreditați acreditările bazei de date de forță de muncă pe serverul web al victimei
Utilizați aplicația instalată pentru a încărca un backdoor (pentru Joomla! Acest lucru ar putea fi ușor de făcut cu un pachet de extensii malware încărcat în backend)
Utilizați backdoor-ul pentru a reseta aplicația (de ex., Prin eliminarea fișierului configuration.php și restaurarea folderului de instalare al lui Joomla) pentru a face victima să creadă că nu sa întâmplat nimic rău.
Acești pași se pot întâmpla în mai puțin de un minut dacă sunt automatizați printr-un script - totuși, aceasta a fost o problemă pur teoretică, deoarece pur și simplu nu exista nicio modalitate pentru atacator să obțină informațiile critice (când și unde). Din acest motiv, aproape nici o aplicație web majoră nu a implementat un proces de verificare și acest lucru a fost perfect în fine până acum.
Nori negri la orizont
Din păcate, un nou protocol utilizat pentru a îmbunătăți securitatea web modifică acest status quo, deoarece funcționează ca sursă nouă de informații. Protocolul, numit Transparența certificatelor (CT), este un jurnal în timp real al tuturor certificatelor SSL emise de o autoritate de certificare (CA). Ideea de bază din spatele protocolului este de a detecta emiterea de certificate SSL necinstite, ceea ce ar îmbunătăți securitatea generală pe această parte foarte importantă a web-ului.
Cu toate acestea, dacă ne gândim la protocol, acesta are un efect secundar: imaginați-vă că doriți să construiți un site nou folosind Joomla. Deschideți site-ul preferat al gazdei web, achiziționați un nou cont de găzduire și înregistrați un domeniu - și din moment ce este 2017 și avem servicii minunate precum LetsEncrypt, veți primi un certificat SSL gratuit pentru acest nou domeniu activat în mod implicit. Câteva minute mai târziu, domeniul dvs. este gata să meargă și îl încărcați pe Joomla! - și boom, ești hacked! De ce? Deoarece gazda dvs. Web a primit automat un certificat SSL pentru noul dvs. domeniu și din cauza protocolului CT, acest nou certificat (inclusiv numele domeniului dvs.) a fost împărțit instantaneu cu restul lumii. Un atacator care a monitorizat fluxul de date CT a găsit domeniul dvs. și a început să o probeze la fiecare câteva secunde până când ați încărcat în cele din urmă Joomla! Fișiere - și odată ce sa întâmplat, atacatorul a executat exploatarea menționată mai sus.
Menținerea soldului
Acest vector de atac este un exemplu foarte bun al conflictului dintre securitate și uzabilitate pe care noi, ca o echipă de securitate, îl confruntăm pe o bază obișnuită. Îmbunătățirea securității instalatorului ar necesita un pas suplimentar de "proof of ownership" care solicită utilizatorului să elimine un fișier generat de instalator. Acest pas suplimentar ar putea fi o provocare în special pentru utilizatorii neexperimentați și afectează gradul de utilizare negativ. Deci, la sfârșitul zilei ne întrebăm adesea: este acest vector de atac un scenariu plauzibil în lumea reală care justifică impactul negativ al utilizabilității sau este o problemă teoretică?
Cu transparența certificatului, o amenințare teoretică a devenit o problemă reală la nivel mondial și a necesitat o soluție implementată imediat de echipa de securitate. Am împărtășit soluția noastră cu reporterul inițial (și cu alte CMS-uri) și am ales o dată de lansare care a fost cât mai apropiată de discuția Def Con (care a dezvăluit public vectorul) cât mai mult posibil.
Joomla! Este singura aplicație web majoră care a ajustat programul de instalare la această nouă amenințare
Până acum, Joomla! Este singura aplicație web majoră care a ajustat programul de instalare la această nouă amenințare - și toate acestea vă sunt aduse de o mică echipă de voluntari care lucrează în spatele scenei Joomla, luptând în mod constant pentru un echilibru optim, menținând CMS în siguranță .
Joomla! Echipa sursa: https://developer.joomla.org/news/702-best-security-process-fast-reactions-to-new-threats.html