Apple fixt 88(!) Sicherheitslücken

Immer dann, wenn irgendwo die Sprache auf Virenscanner oder Bugfixes für Windows kommt, findet man recht flott die immer gleichen Aussagen von Apple-Usern, die da lauten: „Auf meinem Apple brauch ich sowas nicht.“, „Windows ist doch ein Schweizer Käse…“ und so weiter. Was mich immer wieder zu einem breiten Grinsen verleitete.

Virenscanner würden nämlich nicht mal ansatzweise irgend eine Hilfe sein, wenn der Hersteller Eures Betriebssystems die Hintertüren und Rootkits frei Haus liefert. Wofür braucht man da noch Viren?

Apple hat mal eben auf einen Schlag 88 Sicherheitslücken in OS X geschlossen. Fefe hat die Highlights mal heraus gepickt:

  • Code Execution in Rechtschreibprüfung
  • Nach dem Reboot ist manchmal die Firewall aus
  • Wenn man bei AFP den Gastzugang abschaltet, ist er noch an, und man kann auf Dateien außerhalb der Share zugreifen
  • Code Execution durch Audio oder Video abspielen
  • Code Execution durch Plattenimage Mounten
  • Rootzugriff über Directory Service oder eine der Lücken in OS Services
  • Auch per FTP kann man Dateien außerhalb des FTP-Verzeichnisbaumes abrufen
  • beim Chatten kann man den Server ownen
  • Bilder aufmachen haben sie anscheinend einmal bei jedem verfügbaren Bildformat verkackt, sogar bei RAW-Bildern.
  • Das Konvertieren von Fließkommazahlen führt zu Code Execution
  • Man kann sich remote über ein altes Passwort einloggen, und Login-Restriktionen wirken auch nicht
  • Postscript-Dateien öffnen führt zu Code Execution
  • Quicktime ist eh eine einzige Trojaner-Deployment-Plattform

Hey, das nenn ich echt mal sicher. So sicher wie das Amen in der Kirche ist hier, dass nicht mal ein Bruchteil der User weiß, was auf ihrem System so alles passiert. Von genau solchen Fehlern in der Software rede ich seit Jahren, aber keiner der Apple-Maniacs nahm das je wahr. Hier habt ihr es Schwarz auf Weiß. Liebe Leute, mit so etwas habt ihr die ganze Zeit über „gearbeitet“!

Ich bin gespannt auf den nächsten Schwung. Glaubt mir, das war noch lange nicht alles …

Tags: , , , ,

Man-in-the-middle attack auf Blizzard Authenticator

Letztes Wochenende wurde die erste erfolgreiche Man-in-the-middle attack auf Blizzards Authenticator bekannt. Ein WoW-Spieler meldete im Forum einen Account-Hack, der trotz Verwendung des Authenticators erfolgte.

Den Authenticator führte Blizzard vor geraumer Zeit ein, um das weit verbreitete Ausspähen von Accountdaten der World of Warcraft-Spieler zu erschweren und so für mehr Sicherheit zu sorgen. Beim Authenticator handelt es sich um ein bedrucktes DIGIPASS GO 6 von Vasco, einem belgischen Hersteller. Er generiert abhängig von der aktuellen Zeit One-time Passwörter, also Passwörter, die exakt 1 Mal innerhalb eines bestimmten Zeitfensters gültig sind. Das eigentliche Zeitfenster, innerhalb dessen das OTP gültig ist,  ist ungefähr 30 Sekunden groß. Um dieses Zeitfenster herum existiert ein weiteres, etwas größeres Zeitfenster, in dem das OTP nicht mehr gültig ist, aber dennoch akzeptiert wird. Letzteres Zeitfenster hat den Zweck, auch Token, deren interne Uhr nicht ganz genau läuft, verwenden zu können. Auftretende Abweichungen der internen Uhr werden so vom Server erkannt und kompensiert.

Die Gültigkeit eines OTP verfällt automatisch, sobald der generierte Code einmal verwendet wurde. Dies erschwert das Ausspähen von Daten enorm, kann es aber nie ganz verhindern. Üblicherweise werden Accountdaten durch Keylogger ausgespäht, die sich auf dem Rechner des Opfers befinden. Bei der Verwendung statischer Kennwörter gestaltet sich das recht einfach: Die Daten werden ausgespäht, an den Angreifer gesendet und dieser hat nun alle Zeit der Welt, die Accountdaten zu benutzen.

Durch die Verwendung von OTPs wird dieser Vorgang für einen Angreifer erheblich aufwändiger. Zum Einen muss hierbei eine Reaktion durch den Angreifer nahezu in Echtzeit erfolgen, da, wie oben beschrieben, die Gültigkeitsdauer eines OTPs nur wenige Minuten beträgt. Zudem muss der Angreifer verhindern, dass das OTP zum Server gesendet werden kann, da anderenfalls das OTP ungültig würde.

Diese Methoden sind nicht neu, die Gefahr eines solchen Angriffs ist seit langem bekannt und keinesfalls auf Token des Herstellers Vasco beschränkt, alle Token basieren letztlich auf dem gleichen Grundprinzip. Hier irgendeine Verantwortlichkeit beim Hersteller zu suchen wäre also keinesfalls gerechtfertigt. Letztlich bleibt bei jeder Sicherheitsvorkehrung immer ein gewisses Restrisiko erhalten.

Neu ist hingegen, dass ein solcher Angriff erstmalig von einem WoW-Spieler beobachtet werden konnte (musste). Der Spieler versuchte, sich mit seinen Accountdaten und dem OTP im Spiel anzumelden. Unmittelbar nachdem er das OTP eingegeben hatte, crashte der WoW-Client. Und genau in diesem Moment reagierte der Angreifer und loggte sich mit den gerade eben ausgespähten Daten ein. Das deutet darauf hin, dass der eingesetzte Keylogger in Echtzeit kommuniziert. Zudem scheint er die weitere Anmeldung des Spielers zu verhindern, denn Zarakiteque schreibt in seinem Beitrag, dass er sich nach diesem Crash nicht mehr einloggen konnte. Dies gelang ihm erst dann wieder, nachdem er den vermutlichen Schädling auf seinem System identifiziert und unschädlich gemacht hatte. In seinem Fall handelte es sich um eine Datei namens emcor.dll, die sich in seinem Appdata/Temp-Verzeichnis befand.

Blizzard hat inzwischen bestätigt, dass es sich hierbei um eine Man-in-the-middle attack handeln muss und untersucht den Fall, weitere Informationen wird es sicherlich in naher Zukunft geben. Interessant finde ich, dass es sich hierbei offenbar um einen recht neuen Schädling handelt, Virenscanner entdeckten ihn noch nicht und via Google konnte der Spieler nur wenige Tage alte Informationen im Web finden (aktuell führen nahezu alle Suchergebnisse bei einer Suche nach emcor.dll zu Beschreibungen dieses Vorfalls).

Der Fall führt wieder deutlich vor Augen, dass jegliche Sicherheitsvorkehrungen auch umgangen werden können. Es wird sicherlich nie eine Lösung geben, die das Ausspähen von Logindaten (und die anschließende Nutzung) vollkommen verhindern kann. Jede Lösung wird letztlich nur den Aufwand erhöhen, der von einem Angreifer betrieben werden muss. Wenn der Aufwand irgendwann den Nutzen übersteigt, wird ein Angriff möglicherweise uninteressant.

Auch wenn ich es weiter oben bereits schrieb, möchte ich abschließend trotzdem noch einmal darauf hinweisen, dass für derartige Angriffe nicht allein die Produkte des Herstellers Vasco anfällig sind. Die Angriffe sind auch bei Token von RSA oder anderen Herstellern möglich. Vasco steht allein deshalb nun im Rampenlicht, weil dessen Produkte von Blizzard eingesetzt werden. Die Funktionsweise derartiger Token ist immer identisch, demzufolge funktioniert exakt diese hier eingesetzte Methode auch in der Praxis mit jedem beliebigen OTP-Generator sämtlicher Hersteller. Vasco ist hier also kein Vorwurf zu machen.

Dumm wäre es jetzt, OTPs generell abzulehnen, wie es in manchen Foren bereits geschieht. Auch wenn ein Angriff möglich bleibt: Er ist wesentlich schwieriger und mit höherem Aufwand durchführbar, als wenn allein Benutzername und Kennwort genutzt würden. Die Verwendung von OTPs erhöht in jedem Fall die Sicherheit, auch wenn sie Angriffe nicht vollends ausschließen kann. Hier ist (wieder einmal) der Anwender gefragt, der genügend Aufmerksamkeit und zusätzliche Absicherungen aufbringen muss, um das Einnisten eines Schädlings zu vermeiden. Sich allein auf die Verwendung einer bestimmten Maßnahme zu verlassen, reicht eben nicht.

Im übrigen setzen auch Paypal und eBay die Token von Vasco ein, diverse Banken nutzen sie ebenfalls und an vielen Stellen werden Lösungen von RSA eingesetzt. Ich bin gespannt, wann hier die ersten vergleichbaren Vorfälle bekannt werden.

Tags: , , , , , , ,

Backdoor in WordPress ganz easy

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.

Tags: , , ,

Pwn2Own2009: Chrome sicherster Browser

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.

Tags: , , , ,