lansarea sistemului de gestionare a conținutului web . Lansați notele de lansare în implementarea verificării actualizărilor și extensiilor prin semnătură digitală.
Până acum, la instalarea actualizărilor în WordPress, factorul principal de asigurare a securității era încrederea în infrastructura și serverele WordPress (după descărcare se realiza o verificare a hash-ului fără verificarea sursei). În cazul compromiterii serverelor proiectului, atacatorii aveau posibilitatea de a modifica actualizarea și de a răspândi cod malicios în rândul site-urilor bazate pe WordPress care utilizau sistemul de instalare automată a actualizărilor. Conform modelului de livrare bazat pe încredere aplicat anterior, o astfel de modificare ar fi rămas neobservată de utilizatori.
Având în vedere că proiectul w3techs, platforma WordPress este utilizată pe 33,8% din site-urile de pe internet, incidentul ar fi avut un impact catastrofal. De asemenea, riscul de compromitere a infrastructurii nu era ipotetic, ci foarte real. De exemplu, cu câțiva ani în urmă, unul dintre cercetătorii în securitate o vulnerabilitate care permitea atacatorului să execute propriul cod pe serverul api.wordpress.org.
În cazul utilizării semnăturilor digitale, obținerea controlului asupra serverului de distribuție a actualizărilor nu va duce la compromiterea sistemelor utilizatorilor, deoarece pentru a efectua un atac ar fi necesar să se obțină și cheia privată stocată separat, cu ajutorul căreia se realizează semnătura actualizărilor.
Implementarea verificării sursei actualizărilor prin semnătură digitală a fost împiedicată de faptul că suportul pentru algoritmii criptografici necesari a apărut în livrarea standard a PHP destul de recent. Algoritmii criptografici necesari au apărut grație integrării bibliotecii în compunerea principală . Dar versiunea minim suportată în WordPress lansarea 5.2.4 (începând cu WordPress 5.2 — 5.6.20). Activarea suportului pentru semnături digitale ar duce la creșterea semnificativă a cerințelor pentru versiunea minim suportată de PHP sau la adăugarea unei dependențe externe, ceea ce dezvoltatorii nu ar fi putut să-și permită având în vedere prevalența versiunilor PHP în sistemele de hosting.
Soluția a fost și includerea în WordPress 5.2 a unei versiuni compacte a Libsodium — , în care este implementat în PHP un set minim de algoritmi pentru verificarea semnăturilor digitale. Implementarea lasă de dorit din punct de vedere al performanței, dar rezolvă complet problema compatibilității, permițând de asemenea dezvoltatorilor de pluginuri să înceapă să integreze algoritmi criptografici moderni.
Pentru formarea semnăturilor digitale este utilizat algoritmul , dezvoltat cu participarea lui Daniel Bernstein. Semnătura digitală este generată pentru valoarea hash SHA384, calculată din conținutul arhivei cu actualizări. Ed25519 are un nivel de securitate mai ridicat decât ECDSA și DSA și demonstrează o viteză foarte mare de verificare și generare a semnăturilor. Rezistența la atacuri pentru Ed25519 este de aproximativ 2^128 (în medie, pentru a ataca Ed25519 ar fi necesare 2^140 operații pe biți), ceea ce corespunde rezistenței unor algoritmi precum NIST P-256 și RSA cu o dimensiune a cheii de 3000 de biți sau criptare bloc de 128 de biți. Ed25519 nu este, de asemenea, afectat de probleme de coliziune în hash-uri, nu este sensibil la atacuri prin analiza temporizării cache-ului și atacuri prin canale laterale.
În versiunea WordPress 5.2, verificarea semnăturii digitale acoperă momentan doar actualizările principale ale platformei și nu blochează actualizarea în mod implicit, informând doar utilizatorul în legătură cu problema apărută. Decizia de a nu include blocarea implicită a fost luată din cauza necesității de a verifica complet și de a contura . În viitor, se preconizează că verificarea semnăturii digitale va fi adăugată și pentru a verifica sursa de instalare a temelor și pluginurilor (producătorii vor putea semna lansările cu cheia lor).
Pe lângă suportul pentru semnăturile digitale în WordPress 5.2, se pot menționa următoarele schimbări:
- În secțiunea „Starea site-ului” au fost adăugate două pagini noi pentru depanarea problemelor tipice de configurare, precum și un formular prin care dezvoltatorii pot lăsa informații de depanare administratorilor site-ului;
- A fost adăugată implementarea „ecranului alb al morții”, care apare în cazul problemelor fatale și ajută administratorul să corecteze singur problemele legate de pluginuri sau teme, trecând într-un mod special de recuperare după defectare;
- A fost implementat un sistem de verificare a compatibilității cu pluginurile, care verifică automat posibilitatea utilizării pluginului în configurația curentă, având în vedere versiunea PHP utilizată. Dacă pentru funcționarea pluginului este necesară o versiune mai nouă de PHP, sistemul va bloca automat activarea acestui plugin;
- A fost adăugată suportul pentru activarea modulelor cu cod JavaScript folosind și ;
- A fost adăugat un nou șablon privacy-policy.php, care permite configurarea conținutului paginii cu termenii de respectare a confidențialității;
- Pentru temele de design a fost adăugat un handler pentru hook-ul wp_body_open, care permite inserarea codului imediat după tag-ul body;
- Cerințele pentru versiunea minimă de PHP au fost ridicate la 5.6.20, iar în pluginuri și temele de design a apărut posibilitatea utilizării spațiilor de nume și a funcțiilor anonime;
- Au fost adăugate 13 pictograme noi.
În plus, se poate menționa o vulnerabilitate critică în pluginul WordPress (CVE-2019-11185). Vulnerabilitatea permite executarea de cod PHP arbitrar pe server. Pluginul este utilizat pe mai mult de 27 de mii de site-uri pentru organizarea de chaturi interactive cu vizitatorii, inclusiv pe site-uri ale unor companii precum IKEA, Adobe, Huawei, PayPal, Tele2 și McDonald’s (Live Chat este adesea folosit pentru a implementa chaturi pop-up insistente pe site-urile companiilor cu oferta de a interacționa cu un angajat).
Problema se manifestă în codul de încărcare a fișierelor pe server și permite ocolirea verificării tipurilor de fișiere acceptate, încărcând un script PHP pe server, care poate fi apoi executat printr-o adresare directă prin web. Este interesant că anul trecut în Live Chat a fost identificată o vulnerabilitate similară (CVE-2018-12426), care permitea încărcarea codului PHP sub forma unei imagini, specificând un alt tip de conținut în câmpul Content-type. Ca parte a remedierii problemei, au fost adăugate verificări suplimentare pe baza listelor albe și a tipului de conținut MIME. Se pare că aceste verificări au fost implementate incorect și pot fi ușor ocolite.
În particular, încărcarea directă a fișierelor cu extensia «.php» este interzisă, dar extensia «.phtml» nu a fost adăugată în lista neagră, fiind asociată pe multe servere cu interpretatorul PHP. Lista albă permite doar încărcarea imaginilor, dar poate fi ocolită specificând o extensie dublă, cum ar fi «.gif.phtml». Pentru a ocoli verificarea tipului MIME la începutul fișierului, înainte de a deschide tagul cu codul PHP, era suficient să specifici șirul «GIF89a».
Sursa: opennet.ro
