Beitrag vom

Momentan liest man fast überall in den Nachrichten vom Panama Paper Leak: Ein Aktivist hat unter dem Pseudonym „John Doe“ über 2,4 TB Daten von der Kanzlei Mossack Fonseca erbeutet und der Süddeutschen zugespielt. Falls du davon nicht gehört hast: Mossack Fonseca hat in Panama über 300.000 Briefkastenfirmen bei der Gründung geholfen. Über Offshore Firmen wird eine ganze Menge Schund getrieben; zum Beispiel Steuerhinterziehung und Terrorfinanzierung, so die Süddeutsche

Die Jungs und Mädels von wordfence haben den Hack mal genauer analyisert und festgestellt, wie leicht es gewesen sein muss, an die Daten heran zu kommen. Offensichtlich waren die Einfallstore nicht gepatchte Versionen von WordPress und Drupal. 

Das Datenleck in WordPress

Das Groß an erbeuteten Daten sind mit über 4 Millionen Dateien E-Mails. Über eine alte Version des Plugins Revolution Slider gelang es den Angreifern, die WP-Config Datei auszulesen. Wer Zugriff auf die Config Datei hat, hat dann auch Zugriff auf die Datenbank. Unglücklicherweise wurden auch das WP SMTP Plugin und das ALO EasyMail Newsletter Plugin verwendet.

WP SMTP Speichert Zugangsdaten zu einem Email-Server in der Datenbank, um via SMTP Mails zu versenden. Das ist ziemlich ungünstig, wenn man WordPress nicht seinen eigenen Mail Account sponsert und die komplette Kommunikation über das Postfach laufen lässt, zu dem Zugangsdaten in der Datenbank liegen. Das ALO EasyMail Newsletter Plugin hatte auch Zugangsdaten, um gebouncete Emails (also Emails die nicht an ihren Empfänger zustellbar sind) aus den Newsletter Listen zu entfernen. Darüber hinaus werden in Newslettern natürlich Listen von Empfängern gepflegt. Vermutlich sind auch diese Daten vorhanden gewesen.

Hat man jetzt wie in diesem Fall Zugriff auf die Datenbank, so hat man auch Zugriff auf den Mail Server und kann sich bedienen.

Das Datenleck in Drupal

Mossack Fonseca haben unter portal.mossfon.com ein Portal mit Drupal betrieben, unter dem Firmendaten und Aufträge gepflegt wurden und abrufbar waren. Hier wurden Kundendokumente wie PDFs und Textdokumente von John Doe abgegrast. Möglich war der Anriff auch in diesem Fall durch eine Sicherheitslücke, die eigentlich schon längst gepatcht worden ist: Drupalgeddon

Drupalgeddon ist eine Sicherheitslücke, die Oktober 2014 entdeckt wurde und über die es möglich war, SQL-Injection zu betreiben. Die Lücke wurde mit 25/25 Punkten als super mega hammer kritisch eingestuft. Die Aufdeckung ging ähnlich groß wie Heartbleed durch die Medien. Wer sein Drupal bis zum 15. Oktober nicht gepatcht hatte, dem wurde geraten, die Webseite neu aufzusetzen, weil man sich trotz Update nicht sicher sein kann, ob nicht schon eine Backdoor eingebaut wurde. 

Auch hier ging dann der Weg über die Datenbank des CMS: Hast du Zugriff auf die Daten, weißt du auch, wo sich welche Files befinden, die über die Website erreichbar sind. John Doe musste sich also nur noch bedienen.

Sicherheitslücken sind leicht auffindbar

Selbst wenn du kein explizites Ziel eines Angreifers und potentiell auch für Hacker uninteressant bist: Tagtäglich crawlen tausende von Bots das Internet und versuchen, sich in dein System einzunisten. Entweder bist du dann selbst eine Spam- und Malware-Schleuder oder teil eines Botnetzes, das weitere Angriffe ausführt.

Kluge Bots und Hacker nehmen Listen zur Hand, um Schwachstellen von deinem System abzugleichen. Diese Informationen sind öffentlich verfügbar und werden von Security Scannern genutzt. Das geht voll automatisiert und muss nicht mal mit Trial and Error großartig probiert werden. Und je beliebter die eingesetzte Software, um so wahrscheinlicher ist es, dass Angriffe darauf stattfinden. 

Was wir aus dem Hack lernen

Auch wenn man keine Terrorfinanzierung betreiben will oder anderen Leuten dabei hilft, ihre Steuergelder unsichtbar zu machen: das Thema Datensicherheit im Internet ist viel zu wichtig, um sich nicht damit zu beschäftigen. Sowohl für Webentwickler als auch Kunden und Seitenbesitzer gilt: So ein Hack ist hässlich, kann richtig weh tun und dich in null Komma nix in den Ruin treiben. Die wichtigsten Lektionen, die man aus einem Vorkommnis wie diesem lernen kann sind:

 

  • Halte deine Systeme aktuell: Egal ob WordPress und Drupal, PHP, dein Linux Server oder dein Firmenlaptop. Jede Softwarelücke die entdeckt wird, wird potentiell auch von Angreifern genutzt. Du investierst also nicht nur in deinen Sysadmin, sondern auch in deine eigene Sicherheit. Ein Plugin oder Modul wird nicht mehr unterstützt? Ersetze es!
  • Zugangsdaten in einer öfentlich erreichbaren Datenbank sind ein dickes no-go: Vor allen Dingen, wenn es um Kundeninformationen, persönliche Daten, Geschäftsdaten usw. geht. Sowas gehört hinter schloss und Riegel. 
  • Trenne deine Applikationen voneinander: Also bitte: Ein CMS, Das großzügigen Zugriff auf deine Mails hat? Das grenzt schon wieder ganz hart an Dummheit. Darüber hinaus solltest vielleicht auch darauf achten, dass deine Vhosts eigene Benutzer haben und nicht alle unter einem User – im schlimmsten Fall Root – laufen. Genauso gilt das für deine Datenbanken. Denn wird eine Instanz gekapert, lassen sonst alle die Hosen runter!
  • Übertreib’s nicht mit Plugins oder Modulen: Jede Systemerweiterung birgt neue potentielle Einfallstore, die gestopft werden müssen. Denk mal drüber nach, ob du wirklich für jeden Scheiß erst einmal ein Plugin installieren musst. Oftmals kann man viele Kleinigkeiten auch wunderbar mit den Standard Bordmitteln lösen. 
  • Mach die Schotten dicht: Was, auf deinem Webserver läuft Samba? Du kannst dich als Root via SSH anmelden? Du antwortest auch auf den 500sten fehlgeschlagenen Request? Fail2ban oder knock noch nie gehört? Dann nimm dir einen Experten zur Hand, der weiß, wie man ein System absichert. Und installiere nur Dienste, die du wirklich brauchst! Der Gebrauch einer Firewall ist vielleicht auch eine Überlegung wert.
  • Lass deinen Webserver nicht so viel reden: Ob WordPress Plugin oder Apache Header – oftmals sind Informationen zu eingesetzten Programmversionen so leicht zugänglich wie Tante Erna’s Telefonnummer im Örtlichen. Kennt man die Programmversion kennt man auch die Schwachstellen. Lösche also alle Readme’s, info.txt’s, mache deine Header sauber. Und lass keine info.php Datei offen rum liegen.
  • Sensible Daten wegsperren: Die haben einfach nichts im Neuland verloren. Schütze, was schützenswert ist!

 

Bildnachweis: Headerbild von Pablo GarciaSaldaña

Tags: , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.