WordPress ist bei den meisten Nutzern gerade aufgrund seiner Flexibilität und einfachen Erweiterbarkeit sehr beliebt. Gerade letzteres bietet jedoch eine Vielzahl von Möglichkeiten, Backdoors einzuschleusen, die unerwünschten “Besuchern” eine Menge Möglichkeiten für Unsinn verschaffen können.

Wie einfach es beispielsweise ist, eine Backdoor in ein Template zu integrieren, welche einen Benutzer in WordPress anlegt und diesem Administrator-Rechte zuweist, zeigt der Beitrag “How-To: Create Backdoor Admin Access in WordPress“. Der Code sitzt in der functions.php des Templates und wird durch einen speziellen Aufruf der Zielseite aktiviert. Mittels der Funktion wp_create_user aus wp-includes/registration.php wird nun ein neuer Benutzer in der Datenbank angelegt und zum Administrator gemacht. Fertig, die Tür ist offen. Egal, ob die Registrierung von neuen Benutzern erlaubt ist oder nicht.

Um solch eine Backdoor nachträglich in eine WordPress-Installation zu integrieren, benötigt ein Angreifer natürlich Zugriff auf die Daten, beispielsweise via FTP. Allerdings ist man darauf nicht zwingend angewiesen, was hindert einen potentiellen Angreifer daran, eine Seite aufzusetzen, von der man Unmengen an WordPress-Templates herunter laden kann, die durch die Bank mit einer solchen Funktion präpariert sind? Oder warum sollte ein Entwickler nicht ein solches Hintertürchen in sein wunderbares WordPress-Plugin integrieren? Hand aufs Herz: Wie groß wird der Anteil an WordPress-Nutzern wohl sein, die PHP beherrschen und ein solches Hintertürchen erkennen könnten? 10%? Und wie viele prüfen denn tatsächlich jedes Plugin oder Template auf potentiellen Schadcode? 1%? Weniger?

Aktuell überwiegt einfach das Vertrauen. Vertrauen in die Redlichkeit der Entwickler und Vertrauen in die Ehrlichkeit der Betreiber von Template-Portalen. Sicherlich löblich, offenbar ist noch nicht zu viel passiert in der Vergangenheit. Aber ein wenig Vorsicht sollte dennoch angebracht sein und somit sind vorbeugende Maßnahmen sicherlich nicht falsch.

Den oben beschriebenen “Exploit” (um einen “echten” Exploit handelt es sich meiner Meinung nach nicht wirklich) kann man auf verschiedene Weisen aushebeln.

Variante 1: Wir benennen die Datei wp-includes/registration.php einfach um. Damit hebeln wir allerdings automatisch sämtliche Funktionen zur Bearbeitung bereits existierender Benutzer aus. Also nicht so schick. Zudem ist das nach jedem WordPress-Update zu wiederholen.

Variante 2: Wir kommentieren die Funktion wp_create_user in der Datei wp-includes/registration.php aus. Das Gleiche müssten wir mit der Funktion wp_insert_user in der gleichen Datei tun. Auch hier sind verschiedene Funktionen in der Admin-Oberfläche anschließend defekt und auch dieses Procedere müsste nach jedem Update wiederholt werden. Also auch nicht wirklich schön…

Variante 3 (empfohlen): Wir legen einen zusätzlichen Verzeichnisschutz für das Verzeichnis /wp-admin/ an. Die meisten Provider bieten diese Funktion in der Admin-Oberfläche an, wer diese Funktion bei seinem Provider nicht findet, dem empfehle ich Punkt 8 dieses Artikels. Hier wird die Vorgehensweise recht gut erläutert, auch die anderen Tipps sind prinzipiell sehr zu empfehlen.
Dieser zusätzliche Verzeichnisschutz sorgt nun dafür, dass für den Zugriff auf /wp-admin/ eine zusätzliche Anmeldung erforderlich ist. Bevor also ein Angreifer, der bspw. die oben beschriebene Backdoor ausführen konnte, sich mit seinem neuen Benutzer an Eurem Blog anmelden könnte, müsste er eine weitere, von WordPress unabhängige Authentifizierung erfolgreich vollziehen. Wenn Ihr hier mit einem ausreichend starken Passwort arbeitet, wird das (relativ) schwierig.

Wie weiter oben bereits geschrieben, sehe ich die im verlinkten Beitrag aufgezeigte Möglichkeit zum Anlegen eines administrativen Benutzers nicht als “echten” Exploit an sondern sehe die Problematik allgemein in der Möglichkeit der Erweiterbarkeit. Und sicherlich beschränkt sich das Problem somit nicht allein auf WordPress. Allerdings ist es natürlich durch die von WordPress zur Verfügung gestellten Funktionen wesentlich einfacher, erfolgreich eine Hintertür einzurichten. Möglicherweise sollten gerade die Funktionen zur Erstellung und Änderung von Benutzern gekapselt werden und eben nicht von jedem xbeliebigen Addon genutzt werden können. Aktuell ist es aber möglich, daher sollten WordPress-Nutzer sich nicht allein auf die mitgelieferten Sicherheitsfunktionen verlassen, sondern selbst Hand anlegen. Und sicherlich auch hin und wieder mal nachschauen, ob plötzlich neue Benutzer in der Datenbank auftauchen, obwohl die Registrierung nicht erlaubt ist.

Popularity: 1% [?]

Beim diesjährigen Wettbewerb Pwn2Own durften sich Interessenten wieder einmal an diversen Browsern austoben. Wer als Erster erfolgreich einen Exploit ausnutzen konnte, erhielt das Preisgeld in Höhe von 5000$.

Getestet wurde gegen Systeme, die auf dem aktuellsten Patchstand waren. Am schnellsten war Safari unter Mac OS X offen, ganze 2 Minuten dauerte der Spaß. Schnell verdientes Geld Auch der Internet Explorer 8 und Firefox wurden geknackt, Googles Chrome hingegen blieb bis zum Ende standhaft, nicht ein Exploit konnte erfolgreich durchgeführt werden.

Safari wurde im übrigen gleich 2 mal erfolgreich exploited. Nils, der einen dieser Exploits durchführte, war derjenige, der auch beim IE8 und Firefox erfolgreich war. 15.000$ Preisgeld konnte er so einstreichen, nicht übel.

Popularity: 1% [?]

Der wichtigste Sicherheitshinweis, den man immer und überall im Zusammenhang mit Online-Zahlungsverkehr zu lesen bekommt ist: Gib niemals, aber auch wirklich NIEMALS Deine PIN und Deine TAN heraus, es sei denn, Du hast Dich tatsächlich gezielt online bei Deiner Bank angemeldet.

Und was macht Conrad? Präsentiert einen Service namens “Sofortüberweisung“, bei dem ausgerechnet PIN und TAN abgefragt werden. Das schönste in diesem Zusammenhang ist dieses Zitat aus der Beschreibung (Hervorhebung durch mich):

“Bei dem Dienst “Sofortüberweisung” ist es bisher zu keinen Missbräuchen gekommen (TÜV- zertifiziertes-Online-Zahlungssystem).”

Der Krug geht so lange zum Brunnen… kennen wir ja. Fefe, bei dem ich diesen Hinweis gefunden habe, meint dazu:

“Sagt mir mal: bin ich da zu altmodisch, wenn ich die Idee für eine Katastrophe halte? Vor allem: sie haben da ein Banner, “TÜV Geprüfte Transaktionssicherheit”. Huh? Der TÜV prüft die Transaktionen? Oder hat der TÜV die Idee geprüft und fand sie gut? Kann ich beides kaum glauben.”

Es ist tatsächlich zum heulen. Da versuchen alle, die auch nur ansatzweise Wert auf Sicherheit legen, die Weitergabe von TAN und PIN zu verhindern und Conrad, oder richtiger: die Payment Network AG, ignoriert das glücklicherweise inzwischen gestiegene Sicherheitsbewusstsein und weicht das Ganze auf. Und nicht allein Conrad wickelt die Online-Zahlungen über diesen Dienstleister ab, eine ganze Menge mehr Onlinedienste nutzen offenbar diesen Service, darunter auch das Deutsche Rote Kreuz.

Ganz ehrlich: Ich würde nie im Leben irgendeinem mir unbekannten oder auch bekannten Dienst PIN und TAN übermitteln. Würde mir im Traum nicht einfallen. Und einem Online-Anbieter, der diese Zahlungsmethode anbietet, vertraue ich persönlich nicht. Man mag mich gern paranoid nennen…

Update: Fefe hat ein paar weitere Details veröffentlicht. Auch Banken und Verbraucherschutz warnen im Zusammenhang mit dieser Zahlungsmethode davor, PIN und TAN heraus zu geben.

Popularity: 1% [?]

Wenn ich mir die hysterische Berichterstattung in den Blogs anschaue, die seit gestern rund um Chrome herrscht, dann wird mir ehrlich schlecht. Was wird dem Browser inzwischen schon alles angedichtet: Datenspionage, Keylogger-Funktionalität, speichern der Surf-Historie auf Google Servern, jeder ist eindeutig identifizierbar und anhand dieser Daten werden die besuchten Seiten zugeordnet… Hanebüchener Unsinn!

Versteht mich nicht falsch, ich will jetzt hier keine Lanze für Google brechen, aber ich finde es gelinde gesagt erschreckend, welche Paranoia gepaart mit absoluter Ahnungslosigkeit und Sensationsgier hier zu den unmöglichsten, sachlich einfach falschen Aussagen führt. Deshalb will ich, basierend auf meinen gestrigen Untersuchungen, mal einige falsche Aussagen richtig stellen. Ich werde hier allerdings keinen der Beiträge verlinken, die diese vollkommen haltlosen Aussagen verbreiten.

Aussage 1: Chrome sendet meine eMail-Adresse an Google-Server.

Falsch! In keinem meiner Mitschnitte war auch nur ansatzweise eine Mailadresse zu finden. Ich habe gezielt verschiedene Online-Formulare ausgefüllt (und die dort verwendeten Adressen dann natürlich auch im HTTP-Stream gesehen, sofern die Formulare nicht per SSL übermittelt wurden), darüber hinaus jedoch nichts dergleichen finden können.

Aussage 2: Chrome übermittelt alles, was ich in die Adresszeile tippe, an Google-Server.

Diese Aussage ist nur halb wahr. Richtig ist: Chrome sendet sämtliche Eingaben in der Adresszeile an die voreingestellte Suchmaschine. Und das auch nur dann, wenn die Autosuggest-Funktion aktiviert ist! Ja, es ist ungeschickt, diese Funktionalität als Opt-Out zu gestalten, also in der Grundeinstellung aktiv zu lassen. Allerdings, und da werden mir sicherlich viele zustimmen, das ist es nun mal, was Otto-Normaluser wünscht. Falsch ist definitiv, dass Chrome diese Eingaben immer an Google-Server übermittelt. Die Anfragen werden in jedem Fall nur an die Suchmaschine übertragen, die als Standard eingestellt wurde (bei der Installation wird da auch nachegefragt). Stelle ich hier Yahoo ein, ist keine Kommunikation mehr mit Google-Servern zu sehen, dafür plötzlich jede Menge Verkehr mit Yahoo-Servern. Logisch, wie sollte solch eine Funktion auch anders realisiert werden? Hier aber zu behaupten, alles was man eintippt, landet bei Google, ist sachlich einfach nicht richtig.

Im übrigen passiert exakt das gleiche, wenn man Firefox nutzt. Nicht bei der Eingabe im Adressfeld (hier greift der Firefox ja auf die Browser-Historie zu), aber bei der Eingabe im Suchfeld. Auch hier gehen exakt die gleichen Anfragen übers Netz – zur voreingestellten Suchmaschine.

Verwendet man die Auto-Vervollständigen-Funktion im Chrome, dann wird die letzte, endgültige Eingabe NICHT mehr an die eingestellte Suchmaschine gesendet.

Aussage 3: Google speichert meine Surf-Historie auf seinen Servern.

Ebenfalls vollkommen falsch! Um dies zu realisieren, müsste jeder angeklickte Link zu einem der Google-Server übertragen werden, anderenfalls entgingen Google Unmengen an besuchten Seiten. Dies geschieht jedoch faktisch nicht. Wie in 2. bereits beschrieben, werden lediglich Anfragen an die voreingestellte Suchmaschine gesendet, wenn man etwas in die Adresszeile eintippt und die Autosuggest-Funktion noch aktiv ist.

Aussage 4: Google sendet mit jeder meiner Anfragen eine Identifikationsnummer, anhand derer der Browser eindeutig zu identifizieren ist.

Falsch! Googles eindeutige Identifikationsnummer wird lediglich bei Update-Check durch den GoogleUpdater gesendet. In keiner weiteren Anfrage von Chrome konnte ich sie entdecken. Im übrigen, wie bereits geschrieben: Firefox macht exakt das gleiche (und nahezu jede andere Software auch). Siehe unter anderem auch hier und hier.

Also: sicherlich ist es schön zu sehen, dass das Bewusstsein für Privacy und Datensicherheit steigt. Keine Frage, vor nicht all zu langer Zeit sah das noch vollkommen anders aus. Es ist allerdings nicht mal im Ansatz hilfreich, aufgrund vollkommen falscher Behauptungen eine Hysterie zu erzeugen, so etwas gibt über kurz oder lang sämtliche Bemühungen in dieser Richtung der Lächerlichkeit preis. Denn es ist tatsächlich erschreckend zu sehen, wie uninformiert viele hier in die Diskussion einsteigen: Ein Löwe brüllt es falsch vor (ja, manche Löwen gestehen es selbst immer wieder ein, von der Technik nicht wirklich viel Ahnung zu haben) und die ganzen Kojoten heulen es nach. Sorry, das hilft auf keinen Fall dabei, eine sachliche Diskussion zum Thema zu führen.

Popularity: 1% [?]