Drupal brengt beveiligingsupdates uit voor kritiek lek in Drupal 6, 7 en 8

Drupal heeft beveiligingsupdates uitgebracht voor Drupal 7 en Drupal 8 die een kritiek lek in de software moeten dichten. De organisatie waarschuwde een week geleden dat het de patches op woensdagavond zou uitbrengen. Drupal 6 is ook getroffen en er zijn patches beschikbaar.

Volgens de door Drupal uitgebrachte waarschuwing gaat het om een lek dat het mogelijk maakt om op afstand code uit te voeren. De organisatie heeft er daarom voor gekozen om een risicoscore van 21 uit 25 toe te wijzen. Drupal heeft geen details van de kwetsbaarheid uitgebracht, maar uit de opbouw van de risicoscore, beschreven op een faq-pagina, is af te leiden dat het lek eenvoudig te misbruiken is door een ongeautoriseerde aanvaller en dat het toegang geeft tot alle gegevens op een server. Er zouden nog geen exploits beschikbaar zijn en het lek is aanwezig bij standaardconfiguraties en veelgebruikte instellingen.

Het Drupal-team waarschuwt dat het door de aard van de kwetsbaarheid aannemelijk is dat er op korte termijn exploits worden ontwikkeld. Op Twitter zijn aanwijzingen voor de aard van de kwetsbaarheid te vinden. Daarom is het aan te raden zo snel mogelijk een update uit te voeren. De kwetsbaarheid is gevonden door een medewerker van Druid, dat onder meer audits uitvoert voor Drupal. Het cms wordt volgens Builtwith gebruikt door vijf procent van de één miljoen populairste sites, W3Techs geeft een iets lager percentage weer bij een grotere populatie.

Er zijn patches beschikbaar voor het lek, dat het kenmerk CVE-2018-7600 draagt. Gebruikers met versie 7.x kunnen updaten naar versie 7.58 en voor gebruikers met versie 8.5.x is er een patch in de vorm van 8.5.1 beschikbaar. Voor gebruikers met 8.3.x en 8.4.x geldt dat ze een update kunnen uitvoeren naar respectievelijk versies 8.3.9 en 8.4.6 of gebruik kunnen maken van een patch, ook al zijn het niet-ondersteunde releases. Het Drupal-team raadt deze gebruikers aan na de patch alsnog naar 8.5 te updaten.

Voor gebruikers met versie 6 verwijst Drupal naar de pagina van de lts-versie, waar patches beschikbaar moeten zijn. Gebruikers die niet kunnen updaten, wordt door Drupal onder meer aangeraden om de site tijdelijk te vervangen door een statische html-pagina. De organisatie waarschuwde een week geleden voor dit lek.

Reacties (59)

[beerendlauwers]

De exploit bestaat hoogstwaarschijnlijk uit het feit dat de Drupal Form API het hekje (#) gebruikt om configuratie-informatie bij te houden. De patch filtert keys met dit teken er uit als ze worden gesubmit (via GET, POST of cookie):

protected static function stripDangerousValues($input, array $whitelist, array &$sanitized_keys) {
if (is_array($input)) {
foreach ($input as $key => $value) {
if ($key !== '' && $key[0] === '#' && !in_array($key, $whitelist, TRUE)) {
unset($input[$key]);
$sanitized_keys[] = $key;
}
else {
$input[$key] = self::stripDangerousValues($input[$key], $whitelist, $sanitized_keys);
}
}
}
return $input;
}

Remote code execution kan mogelijk zijn door keys zoals de '#submit' en '#validate' te prepopuleren met functienamen die je wilt aanroepen. Als een Drupal site de "devel" module heeft aan staan, zou je zelfs de "devel_execute_form_submit" functie kunnen aanroepen, die simpelweg een PHP eval() doet van gesubmitte code (als string). Die code kan je dan ook natuurlijk meegeven via malafide keys.

Hoogstwaarschijnlijk zijn alle built-in PHP functies ook beschikbaar om uit te laten voeren, maar daarvoor parameters aanleveren zal moeilijk gaan.

Wat belangrijk is, is dat je de malafide keys moet kunnen injecteren op een pagina die een formulier aanbiedt. En laat de "user/login" pagina nu net een formulier zijn dat je altijd kan bereiken, zelfs als de site in "Maintenance Mode" staat (er wordt dan een statische onderhoudspagina getoond, maar deze is nog steeds opgebouwd door Drupal).

De enige manier dat een site dus veilig is zonder de patch, is een statische HTML pagina te leveren, of de Drupal bootstrap-fase te voorkomen (door bijvoorbeeld de inhoud van index.php te wijzigen naar iets anders). Het beste redirect je alle verkeer naar die ene statische pagina met een .htaccess of iets dergelijks. Als dat niet gaat, kan je een simpele basic auth er voor zetten zodat de webserver simpelweg nooit bereikt kan worden.

[Reactie gewijzigd door beerendlauwers op 25 juli 2024 21:38]

[NaliXL]

In dat geval vraag ik mij af waarom simpelweg de site in onderhoudsmodus zetten niet als optie wordt gegeven als tijdelijke afweermaatregel, dat blokkeert immers ook toegang tot forms? Dat lijkt mij toch veel eenvoudiger dan bijvoorbeeld een index.html voor je site zetten?!

[beerendlauwers]

"user/login" is altijd bereikbaar, zelfs in de onderhoudsmodus.

[kwaakvaak_v2]

Nee want in onderhoudsmode zijn sommige systeem URL's nog steeds te bereiken voor anonieme bezoekers. Als je niet gisteren avond klaar zat om te patchen is op dit moment je meest veilige optie om al je verkeer om te leiden naar een statische HTML pagina en je sites als de donder patchen.

[DJMaze]

Je zou best gelijk kunnen hebben.
Ik heb geen kennis van Drupal en keek naar de patch en downloade net 8.5.1.
Zoeken en kijken naar '# toonde inderdaad veel op dit gebied en kwam in 10 minuten op het zelfde idee.
Daarnaast kwam ik veel arrays tegen met keys als bijvoorbeeld '#width' wat natuurlijk ook potentie heeft.

Als iemand echt kwaad wil is er, denk ik, ergens iemand al actief mee.

Ik vind de oplossing van de whitelist in potentie dan nog steeds gevaarlijk.
Mensen zonder kennis van deze exploit kunnen dan nog steeds een gaatje open zetten.

[Reactie gewijzigd door DJMaze op 25 juli 2024 21:38]

[Sysosmaster]

Ik vind de oplossing van de whitelist in potentie dan nog steeds gevaarlijk.
Mensen zonder kennis van deze exploit kunnen dan nog steeds een gaatje open zetten.

Natuurlijk is dit niet zonder risico. maar het is opensource en er kunnen legitieme redenen zijn om toch '#' toe te staan. de '#width' die je vons is waarschijnlijk onschuldig, wat veel gevaarlijker is zijn opties als '#submit' en '#validate' welke in potentie gewoon php code accepteerd (Ik weet nog niet hoe ze dat dan direct laten evalueren maar mogenlijk is een standaard dev module daarvoor nodig (devel) welke (te-) veel mensen gewoon geinstaleerd hebben.

whitelisten maakt wel dat mensen de beveiliging niet compleet omzeep gaan helpen als ze last hebben van dit probleem (maar enkel die waarde laten doorgaan)

Overigens een ieder die bij de code kijkt waar de whitelisting staat zal de verwijzing zien naar de PSA en dus gewoon kunnen lezen waarom het daar in zit.

[DJMaze]

de '#width' die je vond is waarschijnlijk onschuldig,

Dat dacht ik ook, liever iets onschuldigs posten dan gelijk een deel van een PoC

[Pizzalucht]

Je doet het voorkomen alsof het heel simpel is om dit te injecten. De input zoals GET/POST/REQUEST zou niet in de form build terecht moeten komen, maar in de form state. Ik heb redelijk wat kennis van de Form API en ik heb nog niks bedacht hoe je de de form build kan vervuilen door middel van user input.

[beerendlauwers]

Het ziet er naar uit dat je submit handlers en validate handlers ook in de form state kunt steken: https://www.drupal.org/node/1850410

[Pizzalucht]

Dat klopt, maar de input komt niet direct in de form state, maar in $form_state['values'] en $form_state['input']

[kwaakvaak_v2]

Elke Drupal site heeft standaard een pagina met een formulier. /user om in te loggen bijv. Dat maakt het wel een redelijk makkelijke attack vector voor de scriptkiddo's.

[Spleasure]

Op welke manier worden die gePOSTe keys dan gemerged met de formulierconfiguratie? Dat is de eigenlijke kwetsbaarheid die met de patch wordt bedekt. Ik kan zelf alleen niet bedenken waar de input en de configuratie worden verward.

[RobinJ1995]

Dit is de commit, volgens mij: https://github.com/drupal...ac34a50563a238911b75f08f7

[ejabberd]

Ik heb gisteren Apache gewoon even uitgezet vlak voor 18u UTC; dat is ook een waterdichte methode. Al zal die natuurlijk niet voor iedereen weggelegd zijn

[Verwijderd]

Voor hen die nog een Drupal 7 draaien waarvoor niet meteen een core update kan uitgerold worden (testing et cetera), kan je manueel deze patch toepassen.
Meer info, of patches voor andere versies hier.

[ejabberd]

Met drush kun je ook de core van Drupal 7 updaten, althans dat werkte toch bij mij.

[Verwijderd]

Dat weet ik, maar dat doe ik (persoonlijk) nooit op een (live) server die in productie is. De kans dat er een module niet (helemaal) compatibel is of dat er iets door de core upgrade misloopt, is te groot en dat kan ik niet maken naar mijn klanten toe. Veel programmeurs patchen daarom liever eerst snel manueel de live omgeving om dan in de dev omgeving drush up uit te voeren en te controleren dat de gehele website daarna nog gewoon werkt, alvorens die te deployen naar de productie-omgeving.

[ejabberd]

Kan ik begrijpen. Mijn situatie is anders. Ik beheer enkel de niet zo kritische websites van onze familiebedrijven en als er iets zou misgaan, dan zet ik wel even een enkele uren oud image terug van de hele VPS. Dat heb ik overigens nog nooit moeten doen na een mislukte upgrade via drush (wel al nadat ik zelf iets stuk gemaakt had en snel een oplossing zocht omdat ik wilde gaan slapen ).

[Mar2zz]

wat is het verschil tussen de patch uitvoeren op core en drush up drupal? Jij hebt het over drush up, maar die update alles wat nieuwe versies heeft. drush up of composer update hebben specifieke instructies nodig om alleen dat up te daten wat je wilt (lees patch en). composer update drupal/core resolved ook nog eens netjes dependencies voor je. En beide hebben een dry run functie.

[Verwijderd]

Dat garandeert nog steeds niet de compatibiliteit met thema en/of custom geschreven modules. Toch?

[Mar2zz]

Dat doet de patch ook niet die garantie geven. Een patch doet in dit geval minder files wijzigen, maar de codewijziging/resultaat is hetzelfde. Een patch uitvoeren is natuurlijk wel handiger als je ook andere core-files hebt gepatched, die worden door drush natuurlijk ook vervangen.

[Ras]

Ik merk aan de comments (ook van het bericht van een week geleden) dat men zich afvraagt hoeveel hier mee gedaan wordt. Daarom een kleine reactie van iemand die er dagelijks aan werkt.

Wij beheren vooral Drupal sites, waarbij de kans groot is dat je 1 of meerdere regelmatig bezoekt. We lanceren ook regelmatig nieuwe sites in Drupal. We nemen beveiligingslekken als deze erg serieus. Gisteren hebben we ruim 150 websites, waaronder zelfs nog een enkele Drupal 5, succesvol gepatched. We hadden een flink team klaarzitten dat wachtte op de patch en vervolgens alle sites is langs gelopen.

[Reactie gewijzigd door Ras op 25 juli 2024 21:38]

[bwynants]

gisterenmiddag meerdere websites stil gelegd, s'avonds gepatched (waaronder ook D6) en alles terug actief gezet. Wou idd ook geen risico nemen.

De verwittigingen van het security team waren duidelijk

[Euronitwit]

Waarom is die D5 site nog niet ge-update naar D7 ?
Zijn er echt D5 modulen, die er niet voor D7 zijn?

[Ras]

Dat is een afweging die de klant maakt. Je adviseert als bedrijf en dringt er op aan dat de site ge-update moet worden, maar je kunt een klant niet dwingen. Het enige wat je als bedrijf kunt doen is uiteindelijk zeggen tegen zo'n klant: We willen die site niet meer onderhouden. Zoek een ander. Maar dat is een moeilijke stap. Zeker als dezelfde klant ook net een nieuw groot project bij je neerlegt wat veel inkomsten genereert.

Ik weet niet of bovenstaande geschetste scenario speelt, maar het komt er op neer dat er allerlei belangen kunnen spelen die een dergelijke oude site in stand houden.

[Euronitwit]

Koste mij bij een cliënt <20 uur om het via D6 naar D7 te upgraden. En daar zat die lastige date module, die eigenlijk niet te upgraden, is bij.

Als er een ander groot project bijkomt, dan kan je voor een zacht prijsje de oude site upgraden naar D7 en ja misschien moet je anders die cliënt wel afschrijven.
Heeft hij de knowhow of heeft de ICT-er dat?

[Mar2zz]

Ja het risico dat je loopt op een datalek of hack met zulke cliënten is groot. En dat heeft invloed op de naam van je bedrijf. Sommigen vertikken het ook om de server up te graden en zitten met niet niet meer ondersteunde php/SQL/ssl versies. Daar gewoon de stekker uittrekken is mijns inziens de beste optie. Of via Tor defacen en dan zie je wel roepen

[efari]

Ik ben me onbekend met drupal, zit er eigenlijk geen mogelijkheid tot automatisch updaten in?
Moet élke drupal-website-beheerder dit manueel doen?

[Sysosmaster]

Er zijn meerdere hele goede manieren om een Drupal site te onderhouden. Echter als je je aan de standaarden houd kan Drupal zichzelf niet updaten (geen schrijftechten op zichzelf)

Maar je kan Drupal o.a. up to date houden met

• Drush
• Composer
• Ftp

[efari]

hmm. okay. dus er gaan héél wat huis-tuin-en-keuken website'tjes NIET upgedate worden?
simpele drupal opstellinkjes die ooit eens door een neefje opgezet werden waar niet meer naar gekeken wordt..

is dat eigenlijk niet het grotere probleem dan deze eenmalige groot lek?
want als websites voorheen niet upgedate werden zijn ze ook sowieso kwetsbaar. of het nu om een "kritiek lek" gaat of niet, maakt toch niet uit?

auto-updates zou imo standaard moeten zijn

[Sysosmaster]

Drupal is toch echt voor de wat serieuzere websites.
(ik zie niet veel huis-tuin-en-keueken websites in drupal)

En voor de meeste van deze websites geld dat ze waarschijnlijk ook vatbaar zijn voor Drupageddon (en dus al gehackt / defaced zijn).

Iedereen die niet bereid is software up-to-date te houden moet dit boen met computers die niet op het internet zijn aangesloten.
Anders zul je toch echt dat wel updates moeten doen.

En Drupal gebruiken voor een actie website die niets actiefs doet is niet echt handig (maak er dan een static html van)

[Ras]

Auto-updates zijn voor websites waarbij >99% uptime niet zo belangrijk is. Want wat als de auto-update faalt omdat modules niet meer compatible zijn? Dan krijg je situaties waarbij de website zichzelf of bepaalde functionaliteit er binnen onklaar maakt.

Bij een serieuze website wil je een update vooraf testen op een aparte server (acceptatie-omgeving). Ook wil je graag dat een kundig iemand de update uitrolt om eventuele problemen gelijk te kunnen adresseren. Ook wil je de update uit kunnen stellen als problemen niet direct opgelost kunnen worden. En dan heb ik het natuurlijk niet over deze patch, want die kun je eigenlijk alleen uitstellen als je je site offline haalt.

[Euronitwit]

Van elke beschikbare update krijg je automatisch een email.
De Drupal core kan niet automatisch ge-update worden. Alleen zoals @Sysosmaster beschrijft.
De andere extra modulen kan je met een klik in de browser updaten.

[Reactie gewijzigd door Euronitwit op 25 juli 2024 21:38]

[Sysosmaster]

moet je natuurlijk wel aan hebben staan (is standaard) en mail functionaliteit hebben (is meestal ook gedaan)

[Jan-E]

In een multi-site setup schiet dit lekker op: 'drush up drupal' of evt 'drush pm-update drupal-8.3.9' als je nog op een oudere versie van drupal 8 draait.

Script om 'run updates' vanuit drush uit te voeren:

cd /home/admin/public_html
cd sites
for d in * ; do
if [ -d $d ] && [ $d != 'all' ] && [ $d != 'default' ]; then
echo $d
cd /home/admin/public_html
drush -l http://$d updatedb
cd sites
fi
done

@kwaakvaak_v2 drush @sites voegt een -y toe. Soms wil je het interactief.

[Reactie gewijzigd door Jan-E op 25 juli 2024 21:38]

[kwaakvaak_v2]

je bedoelt drush @sites updb ;-)

Aliasen over for loops anyday..

[Jan121]

Daar heb je geen hogere wiskunde voor nodig,

Vraag, hoe kan zo'n kwetsbaarheid zo lang onopgemerkt blijven? Tegenwoordig worden dit soort basale functionaliteiten toch geautomatiseerd met fuzzers e.d. getest.

Leuk lesje voor de informaticaklas.

[Sysosmaster]

Waarschijnlijk omdat er een specifieke functie moet worden gebruikt.

Gewoon PHP code in een ander veld zetten zal niet resulteren in deze exploit, echter (waarschijnlijk) in dingen als validaters /submit handlers wel.

[tijsgro]

Voor Drupal 6:
https://github.com/d6lts

[onnoroos]

Is er ook een cumulatieve update voor Drupal 6 beschikbaar of moeten de patches op https://github.com/d6lts stuk voor stuk afzonderlijk worden doorgevoerd? Weet iemand dat?

Edit: Of je denkt zelf even na voordat je de vraag stelt

Op https://www.mydropwizard.com/categories/drupal-6-lts is te vinden waar ik om vraag.

[Reactie gewijzigd door onnoroos op 25 juli 2024 21:38]

[IJsrace]

Deze commit voor Drupal 6 LTS laat de kwetsbaarheid zien

[marcvangend]

Bijna. Die commit laat de bescherming tegen de kwetsbaarheid zien.

[cappie]

Dat zijn een hoop oude websites die bijgewerkt moeten worden.. ben benieuwd of er uberhaupt nog wel genoeg actieve Drupal developers zijn; ik kom ze in het wild bijna niet meer tegen

[beerendlauwers]

Zelfs Drupal 5 is eigenlijk ook onderhevig aan deze exploit.

[kwaakvaak_v2]

Als je nu nog steeds Drupal 5 en tot op zekere hoogte ook nog 6 sites in beheer hebt wordt het toch eens tijd om een goed gesprek met die klant aan te gaan. Want je loopt niet alleen op oude code een security risico, maar ook op een al jaren lang niet meer ondersteunde PHP versie en waarschijnlijk nog veel meer onderliggende componenten die je jaren geleden al uit had moeten faseren.

En nee, het standaard 'geen geld' smoesje werkt al lang niet meer, zonder uitzonderingen!

[kwaakvaak_v2]

grappig... ik kom er dagelijks best veel tegen hier ;-)

[Sysosmaster]

Dat zijn een hoop oude websites die bijgewerkt moeten worden.. ben benieuwd of er uberhaupt nog wel genoeg actieve Drupal developers zijn; ik kom ze in het wild bijna niet meer tegen

Ik weet niet of dit sarcastism bedoeld is. maar ter illustratie, Foto actieve Drupalers uit nederland (drupaljam 2017 van Brandle.be)

[marcvangend]

Kom anders gezellig langs volgende week! https://www.drupaljam.nl/

[Sysosmaster]

earlybird hangt al geruime tijd aan ons bord
Plus ben bezig (binnen 040lab) met laatste dingen om live-streamen van alle sessies (laptop screen capture met PA capture) . Dus eindelijk ook terugkijken van sessies waar je niet bij was

[cappie]

Dat ze allemaal op 1 foto passen zegt al genoeg

[ejabberd]

Volgens sysosmasters waren dat de actieve Drupalers uit Nederland. Het zou mij ook verwonderen als er niemand ziek was, er niemand geen zin had om aanwezig te zijn of er niemand op reis was toen die foto werd gemaakt. Dat lijken mij er dus best veel...

[Reactie gewijzigd door ejabberd op 25 juli 2024 21:38]

[Sysosmaster]

Ik sta er niet op (was nog in gesprek). Verder zijn het allemaal mensen die betaald hebben on daar bij te zijn en die tijd hadden. De meeste hebben nog een team thuis werken op zo een dag. Ik moet nog zo veel Nederlandse ontwikkelaars zien (met tijd en geld voor een conferentie ticket) bij wordpress of laravel. (Niets ten nadelen van deze 2 geweldige communities). Maar 400 man Is best veel. Als het er meer zouden zijn dan is de fabrieq ook al niet groot genoeg meer.

[dsmink]

Haha. Ik sta er zelf ook op, maar ik kan je zeggen dat ik niet echt een Drupal ontwikkelaar ben. Geen doorgewinterde in ieder geval. Ik heb voor producten van ons bedrijf 3 modules ontwikkeld en hier en daar wat functionaliteit aan het CMS/de websites van een grote klant toegevoegd.

Daarnaast weet ik zeker dat we er nog wel een paar missen op de foto

[sjoerdvdvis]

Aanstaande donderdag 5 april zijn er zo'n 400 bijeen op DrupalJam 2018, allicht een idee om daar een kijkje te komen nemen? www.drupaljam.nl

[SvenHe]

Dat van die statische html pagina had ik graag vorige week al geweten, had me een boel gedoe gescheeld... (Misschien gewoon niet goed gelezen, kzie het nu wel staan)
Mja, eerste twee updates zijn gedaan, nog 1 te gaan.

[Reactie gewijzigd door SvenHe op 25 juli 2024 21:38]

[Euronitwit]

Alle 14 D7 sites zijn binnen 1 uur bijgewerkt.

[veltnet]

Met "drush up" zou het geen probleem moeten zijn.

[Mar2zz]

drush up drupal. Anders gaat de rest wat nieuwe versies heeft ook mee en dan kan er wel eens wat mis gaan als je niet eerst uitvoerig test.

[Zidane007nl]

Gisteravond met drush alle Drupal websites die ik beheer geüpdatet. Geen enkel probleem tegen gekomen.
Drupal security team bedankt!