Daca open source era mai vulnerabil am fi auzit ca a fost hackuit bitwarden nu lastpass(primul e oss al doilea e closed). Ce conteaza cel mai mult pentru un atacator este potentialul castig nu daca solutia este oss/closed. De asemenea am atins punctul in care este mult mai usor sa faci social engineering decat sa gasesti vulnerabilitati.
Parola nu este securitate prin obscuritate, la fel cum cheia privată nu este securitate prin obscuritate. Mai exact, codul e public doar acele “secrete” rămân private.
Schimbarea portului la SSH nu îți oferă mai multă securitate, doar tine logurile mai curate de încercările loserilor.
Discuția asta seamănă cu discuția despre Bill Gates sau Steve Jobs care s-au lăsat de școală, deci mă las și eu. Da, dar au abandonat Harvard, respectiv Stanford, nu profesionala de mecanici agricoli. Cam așa e cu “codul meu e secure că nu e public”.
Cod custom frumos, curat, secure e o raritate (situație determinată și de bugete mici și amatorismul beneficiarilor care aleg, astfel, diletanți). Iar transparența determină, de obicei, creșterea calității codului.
1 Like
Am spus de la începutul începuturilor că declanșatorul problemei poate fi unul din plugin-uri sau tema folosită. Pentru că și acelea sunt open-source.
Tot mai sus am spus că devii o țintă încă de când ai ales să-ți creezi site-ul folosind wordpress pentru că, de regulă, site-urile web se vor a fi în mare parte unice, atât prin design cât și prin modul lor de funcționare. În condițiile astea, developer-ul este nevoit să instaleze, pe lângă wordpress-ul în sine, o temă sau plugin-uri suplimentare. Astfel, site-urile create cu ajutorul wordpress-ului devin adesea vulnerabile.
Acum. să spunem că un CMS este open-source. Temele și plugin-urile la fel.
Care este șansa unui hacker rău să găsească vulnerabilități într-un site creat cu ajutorul unui CMS și a unor plugin-uri open-source și care este șansa acelui hacker să găsească vulnerabilități într-un site care are într-o anumită măsură codul sursă privat, pe server ?
Credeți că nu este nicio diferență și că șansele atacatorului sunt aceleași ? Răspunsul este că, evident, șansele sunt diferite.
Și urmează întrebarea: care din site-urile respective are mai multe șanse de a fi spart. Răspunsul este: depinde.
Atunci când codul sursă este public, șansele hacker-ului rău intenționat cresc prin simplul fapt că are codul sursă în fața ochilor și poate deduce mult mai ușor (sau din start) care parte din site este suspectă și merită exploatată pentru a putea identifica o vulnerabilitate.
Iar atunci când codul sursă nu este public, șansele hacker-ului cresc prin faptul că developerii nu pun preț pe securitate și pică testul la cele mai comune vulnerabilități. Vulnerabilități care sunt identificate de acei hackeri răi cu ajutorul tool-urilor de data asta, și nu prin interpretarea codului sursă (cum se întâmplă în cazul de mai sus). Uneori vorbim de haxori (niște așa ziși hackeri care se limitează la folosirea de tool-uri create de alți hackeri/crackeri).
Există și excepții în care hackerii rău intenționați acționează pe un site care nu are codul sursă public, și chiar fără tool-uri, dar în condițiile astea site-ul trebuie să prezinte interes, să merite efortul (în ce-i privește).
Adrian spunea mai sus că legea îi pedepsește pe cei care intră în casă cu cheia în ușă. Este adevărat, dar în același timp de asta vorbim despre securitate cibernetică și despre vulnerabilități. Pentru că lucrurile nu se întâmplă întocmai cum am vrea. Și tot pe principiul ăsta ar trebui să înlocuim sistemele de autentificare cu mesajul “Să nu umbli!”.
Răspunsul la întrebarea “Codul Open Source înseamnă cod vulnerabil?” este nu. Pentru că, s-a spus în alte cuvinte mai sus, cantitatea codului realmente vulnerabil nu se stabilește în funcție de caracterul public/privat.
Oricum, întrebarea este pusă greșit. Întrebarea corectă era, poate: “Dacă folosești cod open source, ești mai vulnerabil?”. Și răspunsul este atât de discutabil încât e greu să spui concret “da” sau “nu”. Asta pentru că “open-source” nu e singurul factor care califică codul ca fiind sigur de folosit sau nu. Depinde și de interesul pe care îl acorzi acelui cod open-source.
Dar, inițiatorul subiectului de care am fost separați a spus că folosește plugin-uri. Ori, în condițiile astea nu aș fi ales crearea site-ului folosind wordpress, ci mi-aș fi creat site-ul singur, cu funcționalitățile de care am nevoie.
În general, nu neapărat folosirea wordpress-ului în sine e o problemă, ci temele și plugin-urile care par că trec prin prea puține filtre care să demonstreze siguranța folosirii lor. Și nu o spun eu. Aveți aici plugin-uri care au fost găsite cu vulnerabilități: WordPress Vulnerability Database. Ultima actualizare a listei de vulnerabilități a fost pe data de 5! Și probabil că următoarea actualizare o să fie … în următoarele zile.
Vorbim de plugin-uri care sunt open-source și la care are access orice hacker rău intenționat. Plugin-uri care pot fi descărcate, inspectate și exploatate pe site-urile care le folosesc.
Mai repet o dată ? Dacă codul sursă stătea pe server, șansele ca cineva să găsească vulnerabilități în ele erau mai mici pentru că n-aveau acces la tot codul sursă. Folosind plugin-uri open-source, uneori nesigure, pur și simplu te expui.
Este adevărat și că vulnerabilitățile nu stau întotdeauna pe server. Uneori sunt vizibile în client-side (deci nu are importanță dacă s-a folosit un cms sau nu). Dar vorbim despre minimizarea riscului ca o vulnerabilitate să fie identificată, nu despre excluderea totală ca cineva să găsească o vulnerabilitate.
Un developer nu ar trebui să se limiteze doar la crearea site-ului cât să fie funcțional, ci și la a lua în considerare aspectele care țin de securizarea aplicației.
Cineva o să spună că în mod normal un site este creat de cel puțin un designer, cel puțin un programator, cel puțin un QA, șamd.
Lucrurile stau destul de diferit. De multe ori, responsabilitatea unei aplicații cade pe umerii unui singur developer, sau poate pe a trei developeri. Dar toți aceia având de multe ori cunoștințe limitate în materie de securizarea aplicațiilor, ceea ce este cumva greșit.
Nu mai vorbesc de faptul că CMS-urile, din punctul meu de vedere, nu au fost create pentru programatori. Ci tocmai pentru aceia care au cunoștințe limitate și totuși vor să-și facă singuri site-ul. În condițiile astea, riscul este și mai mare pentru că aceia nu înțeleg ce înseamnă să nu respecți indicațiile celor de la wordpress (actualizarea CMS-ului, a plugin-urilor șamd).
Da, există de exemplu browsere care sunt open-source și totuși sunt destul de sigure, dar companiile care le-au produs creează programe destinate hackerilor de bună credință. Sunt acele programe numite bug bounty care au ca scop identificarea vulnerabilităților înainte ca hackerii răi să ajungă la ele.
Deci, o dată cu publicarea codului sursă, există și riscul ca cineva să găsească vulnerabilități în cod, dar și șansa ca alți programatori/amatori etc, recompensați fiind, să identifice vulnerabilitățile și să le raporteze. Ceea ce duce la un cod calitativ mai bun, mai sigur de folosit.
Pe lângă acele programe clasice bug-bounty, companiile mari și-au creat și programe în care dau acces la cod sursă și la aplicații care n-au ajuns încă în stadiul de producție. În acele programe sunt incluși doar hackerii de bună credință care au dovedit că sunt de încredere. Iar dacă îmi dați voie să strecor ceva laudă, am fost invitat de o companie mare să intru într-un astfel de program.
Mai departe. Nu putem spune același lucru despre plugin-urile sau temele wordpress. E lesne de înțeles de ce. Nu vin întotdeauna la pachet cu wordpress-ul și nu sunt create de cei de la wordpress, ci de terți.
Ca să fie lucrurile cât se poate de clare, și cei de la wordpress și-au creat un program bug-bounty. Îl găsiți aici: HackerOne
Citiți ce scrie la “We generally aren’t interested in the following problems:”:
Security vulnerabilities in WordPress plugins not specifically listed as an in-scope asset. Out of scope plugins can be reported to the Plugin Review team.
Click pe link-ul “Plugin Review team” (Plugin Developer FAQ | Plugin Developer Handbook | WordPress Developer Resources) și vă va trimite într-o pagină din site-ul wordpress, unde veți găsi:
Q: Do you provide bounties for finding bugs in a plugin?
A: No. We have no relationship with any bug bounty programs, so we don’t file your reports etc to them. The only one with which we work is HackerOne and that’s for bugs related to Automattic properties. Everything else is on your own, don’t ask us to submit things.
Așadar, cei de la wordpress au un program bug-bounty, dar nu sunt incluse și plugin-urile. Deci, recomandă utilizatorilor să raporteze vulnerabilitățile, dar nu plătesc pentru ele și nici măcar nu le e recunoscută contribuția public. Lucru care poate duce la refuzul hacker-ilor de bună credință să le inspecteze și să raporteze vulnerabilitățile. Nu putem spune același lucru despre hackerii răi, cei care se ocupă de black hat, și care nu sunt interesați de recunoștință și de raportarea vulnerabilităților, ci de folosirea lor în scopuri proprii.
Două lucruri:
- Nu recomand hacking-ul în scop ilegal!
- Folosiți wordpress-ul dacă vreți, dar cu atenție sporită pe plugin-uri și pe teme. Mai ales pe cele instalate din surse neoficiale.
3 Likes
pai definitia cuvantului include “in mod ilegal”, deci cum ai putea sa o faci altfel?
Nu din nou. Iar ne întoarcem la dex ?
Există și ethical hacking: What Is Ethical Hacking and How Does It Work? | Synopsys
exista si patetic vs pathetic (spoiler: nu inseamna acelasi lucru).
aici spune clar: “With prior approval from the organization or owner of the IT asset”, adica nu e ilegal, deci nu mai e nici hacker (de fapt e “security expert”, cum scrie si in articol).
pana si pe google daca il intrebi (iar el se informeaza mai departe din surse solide) sa “define” un haker…
o sa spune ceva care include “gain unauthorized access”, elemetul cheie fiind “unauthorized” care nu poate fi in acelasi timp si “prior approval”.
cu atat mai mult cand spui “hacking-ul”, deci referinta clar la dex ro, nu la oxford.
da, stiu, ne impedicam in termeni (iar eu chiar nu imi doresc asta),
dar am impresia ca tocmai de asta ne “certam” aici… folosim aceeasi termeni dar ne imaginam contexte si grade diferite pentru ei.
1 Like
Nu pentru ca sunt open-source ci (in cazul plugins Wordpress) pentru ca sunt nu rareori scrise cu picioarele de catre niste amatori.
Cum ziceam mai sus, codul trebuie sa fie de foarta proasta calitate pentru a gasi vulnerabilitati la o simpla citire a sa. Dar daca autorul n-a auzit de SQL Injection de exemplu si are codul vulnerabil la asa ceva, gasesti vulnerabilitatea in cateva secunde si fara se uiti peste cod (deci esti la fel de vulnerabil si daca e codul closed-source).
Cand servesti un blog Wordpress, ai o gramada de soft open-source care coopereaza:
- Sistemul de operare (adesea Linux)
- Serverul web (Apache/Nginx)
- Motorul PHP
- Baza de date
- CMSul insusi cu ale sale plugins
Cum se face ca atunci cand este exploatata o vulnerabilitate, mai mereu aceasta e prezenta in CMS (sau ale sale plugins) si nu in celelalte sisteme de mai sus, chiar daca toate sunt open-source?
2 Likes
Apache imi amintesc ca era dezastru, cu cpanel avea by default compilat un mod de a rula perl in cgi daca ii dadeai o optiune exotica din ceva documentatie uitata de lume in .htaccess.
Era destul ca cineva sa citeasca intr-un mod obscur config.php-ul si sa ia userul si parola la baza de date de pe un alt host, un link de la host la phpmyadmin si era foarte greu de detectat.
O vulnerabilitate dupa mine e o permutatie de factori, sunt atat de multe incat n-ai cum sa nu ai vulnerabilitati, doar ca nu le iei in considerare.
Eu cand am cautat un pw manager m-am uitat sa fie open source si cat de cat popular, ca sa fiu sigur ca au trecut multi ochi prin codul ala cat sa fie safe.
Acuma, daca mi-l scriam eu, cu siguranta era mai gaurit. Dar daca nimeni nu stie si nu e ceva obvious…
E un echilibru la balanta aia, probabil depinde de efort vs beneficiu, timp si bani.
Cu ce deranja asta?
Hackerul cumpara hosting sau accesa un cont vulnerabil, isi punea un shell, dar nu orice shell, cu php am pus tot felul de limite si nu puteai accesa fisierele altora, setarile altora.
Cu perl in schimb scriptul rula cu userul de apache si avea acces de read la toate fisierele celorlalti. Nici nu era activat node/python/cgi etc. in panou, doar php tocmai din acest motiv. Mi-a luat ceva timp pana am descoperit cum reusea sa imi faca probleme. De fapt posibil nici nu era perl din cate imi amintesc, era un script specific pentru apache.
Urat. N-as gazdui insa mai multi clienti sub acelasi user pe server.
1 Like
Nici macar nu e vorba de clienti, daca reusesti sa incarci un shell pe un vhost cu drepturi de write iti poti pune un script de genul ca sa obtii ceva de la celelalte site-uri pe acelasi cont/vm.
Tocmai, acel script nu trebuie sa aibe voie sa acceseze date neautorizate. Exista diverse metode de izolare a accesului, chiar in interiorul aceluiasi VM.
Acum exista, atunci aveai doar chroot care se baza pe procesul si userul care rula fisierul. Un chroot configurat corect iti facea tot felul de probleme cu utilizatorii, trebuia sa ii ajuti sa isi foloseasca ftp-ul corect altfel nu functiona nimic.
Cum apache citeste fisierul .htaccess si din el dai acces la perl nu aveai cum pune chroot pe user. Chroot-ul se aplica doar procesului de php-fpm pornit de apache.
Solutia era sa recompilezi apache sa nu mai contina perl/acel limbaj de scripting pentru apache sau sa dezactivezi .htaccess (nici o sansa).
Fiecare user cu apache-ul sau. Si un reverse proxy in fata.
Da, era o solutie cu mod_ruid2/mod_suid2, dar nu era trivial cu cpanel si restul panourilor. Plus php era incet, foarte incet daca nu rula ca worker din apache. Motivul principal fiind cache-ul, sistemele de caching in aplicatiile de php erau module de php (zend/xcache) si trebuia sa functioneze intr-un anumit fel daca imi amintesc bine.