Für Mittwoch, den 28.3.2018 zwischen 18:00 und 19:30 UTC war ein extrem kritisches Drupal Update angekündigt worden. Das Sicherheitsteam des Projekts ging davon aus, dass in kürzester Zeit nach der Veröffentlichung des Patches die Sicherheitslücke von automatisierten Scripts ausgenutzt werden könnte.
Extrem kritisch bedeutet in diesem Zusammenhang:
- Jeder Besucher der Website kann die Lücke ausnutzen, er muss kein Benutzerkonto auf der Site haben
- Alle Daten, auch die nicht öffentlichen, sind zugänglich
- Alle Daten, auch die nicht öffentlichen, können manipuliert werden
So ein Update gab es bisher einmal am 15.10.2014: SA-CORE-2014-005 – Drupal core – SQL injection. Es ist in die Geschichte eingegangen als #drupalgeddon (https://www.drupal.org/project/drupalgeddon). Ich war damals glücklicherweise nur für meine eigenen Sites zuständig und während dieser Zeit unterwegs in Italien ohne Internet Verbindung :) Das Update habe ich erst ein paar Tage später eingespielt … leider zu spät … eine Drupal Installation wurde “gehackt” und ich beschloss den Server neu aufzusetzen. Ausser mir traf es auch viele andere, unter anderem eine Firma in Panama. Dieser “Hack” brachte die Panama Papers hervor :) (The security flaws at the heart of the Panama Papers)
Das war übrigens damals der Entscheidungsweg:
Ich habe in den letzten 20 Jahren viele Websites gesehen, die in einem bedauernswertem Zustand waren. Nicht gepflegt, nicht gepatched, nicht aktualisiert. Das betrifft ALLE Websites in ALLEN Systemen. Millionen von Websites (und die darunter liegenden Server, Programmiersprachen, Datenbankserver, Router, etc.) sind anfällig für Fehler, die mit einem Update aus der Welt zu schaffen wären. Trotzdem tun sich viele schwer mit Updates. Es kostet Geld und Zeit und man verdient nichts dabei. Gerade bei Drupal sind Updates (und Upgrades) immer so eine Sache, da das Projekt sehr konsequent neue Ideen verfolgt und Aktualisierungen oft schwer bis unmöglich sind. Man muss dann auch schon mal seine Arbeitsweise anpassen. Also versuchen viele Firmen Updates, so weit es geht, zu vermeiden.
Dieses Mal war es so, dass ich für ein paar Firmensites zuständig war und genug sensibilisiert vom letzten Mal. Glücklicherweise vertrauten die Kunden meinen Empfehlungen. Auch in meinem Fall war es natürlich so, dass die Drupal 8 Seiten noch auf 8.4.x liefen, weil ich ein Update auf 8.5. geschoben hatte. War ja kein Sicherheitsrisiko :) In der Version 8.5. hatten sich tatsächlich einige Dinge verändert und es gab bei mir ein paar Probleme mit dem Page Manager Modul. Ich machte mir die Mühe und installierte alles lokal auf meinem PC, probierte hin und her und hatte dann gestern alle Sites auf Drupal 8.5. Vermutlich kann ich langfristig den Page Manager entfallen lassen und alles mit dem neuen Layout Builder im Core lösen. Ob ich das bezahlt bekomme? Hm … mal sehen.
Dann sah ich diesen Tweet
we took down #drupal and created custom screens for displaying downtime…. #justtobesure #DrupalSecurity
— bert boerland (@bertboerland) March 28, 2018
Der Maintenance Mode ist vielleicht nicht genug … Also löschte ich auf den Drupal 8 Sites die core, vendor und Dateien im root Verzeichnis. Für Drupal 7 fiel mir nix ein, also machte ich ein Apache Passwort auf die Seite … Es war 19:30 Uhr und ich dachte, dass es in einer halben Stunde den Patch gibt, dann spiele ich den schnell ein und gut :)
Eine halbe Stunde später begann dann eine Art weltweite Drupal Update Party.
Today the web will blackout.
All #drupal sites will go in to maintenance mode for a security update, hitting 10% of the top 1M sites
In 9 month later we will see the results…
— bert boerland (@bertboerland) March 28, 2018
Immerhin sassen alle verantwortlichen Drupal Admins vor Ihren Rechnern und warteten auf das Update.
Every #Drupal sysadmin right now pic.twitter.com/0HSfg4oWhH
— Christopher Weatherhead (@CJFWeatherhead) March 28, 2018
Da sie alle F5 drückten um die Drupal Security Seite zu aktualisieren, war drupal.org erstmal eine Stunde offline :)
Wir sind bereit für den abendlichen Feuerwehreinsatz für die Sicherheit unserer Kunden #DrupalSecurity 💚 pic.twitter.com/FYG9phlNtO
— undpaul (@undpaul) March 28, 2018
Das Security Team meldete sich auch zwischendurch, da Drupal.org nicht mehr erreichbar war und dieser Zustand doch für Unbehagen sorgte.
We are aware of the 500 errors affecting https://t.co/57fE1VZHTn – we are working to restore stability so that we can complete the process of publishing the security release. Thank you for your patience and go easy on that F5 key.
— Drupal infra (@drupal_infra) March 28, 2018
In Europa sammelte man sich zum virtuellen Lagerfeuer in https://drupalchat.eu/channel/psa-2018-001. und vertrieb sich die Zeit …
#drupal #drupalsecurityhttps://t.co/td7iRdoXSu
— hagengraf (@hagengraf) March 28, 2018
So gegen 21 Uhr geisterten dann erste FTP Links zu den 7er und 8er Versionen durch die Gegend, Drupal.org stabilisierte sich und das Update war da!
Update now — Drupal core – Highly critical – Remote Code Execution – SA-CORE-2018-002 — https://t.co/uwzodrmegc
— Drupal Security (@drupalsecurity) March 28, 2018
Das Einspielen war dann Routine und ging fix. Letztlich war es ein Problem in der bootstrap.inc Datei, also der Datei, die wirklich bei jedem Aufruf von Drupal benötigt wird.
In Partystimmung habe ich dann noch zwei Stunden Tweets und FB posts verfolgt und bin froh, diesmal aufgepasst zu haben.
Das ist übrigens die Kurzstory hinter der aktuellen Lücke:
The issue was identified by Jasper Mattsson (Jasu_M) as part of general research into the security of Drupal. Jasper works for Druid who provide a variety of services including security audits of Drupal sites. Over the years, security issues in Drupal have been found a variety of ways including researchers with personal motivation and through paid penetration tests or security audits. Drupal site owners concerned about security are encouraged to hire security firms to review their site. (https://groups.drupal.org/security/faq-2018-002)
Dries hat sich auch bedankt …dann mach ich mal weiter mit meiner Arbeit :)
Leave a Reply