Am Samstag fiel mir auf, dass das eingebundene Script von Trigami leider eine Malwarewarnung verursachte. Dies passiert wenn Google der Meinung ist, dass eine Seite Schadcode enthalten könnte. Geprüft wird also jede aufgerufene Seite, welche man den lieben langen Tag so ansurft. Ist eine Domain dann auf der schwarzen Liste bei Google wird nicht nur im Google Chrome eine Warnmeldung angezeigt, sondern auch im Firefox und anderen Browsern, die diese Engine von Google benutzen. Der InternetExplorer ist nicht betroffen, denn Microsoft wird es weitestgehend vermeiden offiziell irgendwelche Services von Google zu benutzen

Auf jeden Fall äusserte sich heute das Trigami Team zu dem Vorfall und ich hoffe, dass Google schnell einen erneuten Test der Server durchführt, um die schwarze Liste positiv zu aktualisieren. Hier die Stellungnahme:

Montag, 2. August 2010 / 20.00 Uhr

Liebe Blogger

Am letzten Samstag wurde unseren AdServer zum Opfer eines Hackerangriffs. Dabei wurde schadhafter Code integriert, welcher mit unseren Werbebannern im Internet verteilt wurde. Als Folge davon, haben bei Google die „Alarmglocken“ geläutet undhttp://www.trigami.com wurde auf die Schwarze Liste gesetzt, was wiederum zur Folge hatte, dass alle Surfer, die mit FireFox und anderen Browsern auf unsere Seite kamen, mit einer Sicherheitswarnung konfrontiert wurden (ausgenommen Benutzer des Internet Explorers).

Leider haben wir erst heute Montag früh davon Kenntnis erlangt, obwohl die Blogosphäre schon das ganze Wochenende darüber berichtet hat. Durch diverse Ferienabwesenheiten und dem Schweizer Nationalfeiertag, welcher just auch an diesem Wochenende stattfand, konnten wir nicht früher reagieren. Wir bitte Euch darum an dieser Stelle ausdrücklich um Entschuldigung.

Da die Sicherheitslücke in unserem AdServer nicht zu 100% geschlossen werden konnte, haben wir uns entschieden, den Server vom Netz zu nehmen. D.H. es werden im Moment keine Banner mehr ausgeliefert. Vereinzelt kann dies bedeuten, dass auf den entsprechenden Seiten – anstatt der Banner – eine Fehlermeldung „Objekt nicht gefunden“ angezeigt wird. Aktuell sind wir daran, die betroffenen Seitenbetreiber persönlich zu kontaktieren.

Bei Google haben wir die nötigen Schritte bereits heute Vormittag um 10 Uhr eingeleitet, damit wir wieder freigeschalten werden. Leider ist dies bis zum jetzigen Zeitpunkt noch nicht erfolgt, wir rechnen aber jeden Moment damit.

Was bedeutet dies nun für Dich als Blogger:
Auch einige Blogs wurden übers Wochenende auf die Schwarze Liste gesetzt, da diese Banner oder Beiträge von uns Publiziert haben und durch die Verlinkung auf unsere Seiten, quasi den schlechten „Ruf“ der Schwarzen Liste mit geerbt haben. Nach unserem Kenntnisstand, sind aber mittlerweile alle Blogs wieder „Normal“ erreichbar. Zur Sicherheit überprüft bitte unbedingt Euren Blog mit dem FireFox. Solltet Ihr trotzdem Bedenken haben und lieber abwarten wollen, bis alles wieder „normal“ läuft, ist es Euch freigestellt, die Trigami Blogbeiträge zwischenzeitlich auf Entwurf oder Privat zu setzten. Selbstverständlich ohne Folgen für Euch.

Zwischenzeitlich haben uns viele Beiträge und E-Mails erreicht, bitte habt Verständnis dafür, dass wir nicht sofort alle beantworten können.

Euer Trigami-Team

PS: Den aktuellen Stand könnt Ihr jeweils über unseren Tweet oder Blog erfahren (Zugang mit IEX geht).

Ich finde es auf jeden Fall gut, dass Trigami dies nicht nur auf der eigenen Seite publiziert, sondern entsprechende Blogs, die davon berichtet haben, persönlich kontaktiert. Hier funktioniert der Service auf jeden Fall ganz ungefragt.

Als Reaktion auf eine Sicherheitslücke in mehreren Versionen des Internet Explorer (IE) hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) am Freitag empfohlen, den Microsoft-Browser vorerst nicht zu nutzen, sondern bis zum Vorliegen eines Patches auf einen alternativen Browser umzusteigen. Das Ausführen des Internet Explorer im “geschützten Modus” sowie das Abschalten von Active Scripting erschwere zwar mögliche Angriffe, könne sie jedoch nicht vollständig verhindern, erläutert das BSI.

Zuvor war bekannt geworden, dass durch die Lücke in den IE-Versionen 6, 7 und 8 ein konzertierter Angriff gegen Google, Adobe und zahlreiche andere US-Firmen, hinter denen chinesische Cyber-Spione vermutet werden, ermöglicht wurde. Die Lücke, die Microsoft inzwischen offiziell bestätigt hat, ermöglicht es, über eine manipulierte Webseite Code auf einen Windows-Rechner zu schleusen und zu starten. Die Angreifer nutzten dies, um einen Trojaner-Downloader auf die angegriffenen Rechner zu schleusen.

Der Downloader lud wiederum über eine SSL-gesicherte Verbindung weitere Module von einem Server nach, unter anderem eine Backdoor, mit der die Angreifer aus der Ferne Zugriff auf die Rechner hatten. Die Links zu den präparierten Webseiten wurden wohl per Mail an ausgesuchte Mitarbeiter in den jeweiligen Firmen gesendet. Microsoft arbeitet eigenen Angaben zufolge an einem Patch und will diesen eventuell als “Emergency Patch” außerhalb der monatlichen Patchday-Reihe veröffentlichen.

Quelle: heise.de

HP hat mit SWFScan ein kostenloses Tool für das Erkennen von Sicherheitsverletzungen in Flash-Anwendungen veröffentlicht. Das Tool dekompiliert den ActionScript-2- oder ActionScript-3-Bytecode der Applikationen und durchsucht den Code dann nach Verletzungen. Die Tests wurden auf Basis von Adobes unterschiedlichen Security Best Practices zusammengestellt.

Laut Billy Hoffman, verantwortlich für HPs Web Security Research Group, haben die Entwickler des Tools nahezu 4000 Webanwendungen auf Flash-Basis untersucht und dabei herausgefunden, dass 35 Prozent von ihnen gegen die Adobe-Sicherheitsrichtlinien verstoßen. Als Beispiel nennt er in der Ankündigung Verschlüsselungen und andere heikle Daten, die in clientseitigem Flash-Code zu finden seien.

Das Werkzeug unterstützt alle Flash-Versionen und enthält unter anderem Funktionen wie das Hervorheben der im Code gefundenen Sicherheitsfehler, Lösungsvorschläge für die gefundenen Lücken auf Basis von Adobes Empfehlungen sowie das Erstellen von Reports zu den Verletzungen.

heise online – 23.03.09 – HP veröffentlicht kostenloses Sicherheitswerkzeug für Flash-Entwickler.

Nach Beobachtungen von Sicherheitsfirmen breitet sich der Zero-Day-Exploit für den Internet Explorer rapide im Netz aus. Er richtet sich gegen eine besonders gefährliche Lücke in allen Versionen des des Microsoft-Browsers, für die es bislang keinen Patch gibt: Allein durch Öffnen einer Internetseite kann der Windows-PC mit Schadsoftware infiziert werden. Anders als bei den meisten anderen Angriffen ist also kein weiterer unvorsichtiger Klick des Surfers erforderlich.

Immer mehr harmlose Server werden derzeit durch SQL-Injection so manipuliert, dass sie den Zero-Day-Exploit an anfragende Rechner ausliefern. Daher kann man sich unter Umständen auch auf Webseiten vertrauenswürdiger Anbieter infizieren.

Antiviren-Software schützt nur begrenzt vor Web-Seiten, die einen solchen Exploit nutzen, um Rechner mit Schadsoftware zu infizieren. Zum Einen überwachen längst nicht alle Virenwächter den Internet-Verkehr; viele beschränken sich darauf, Dateien zu durchsuchen. Aber wenn eine Web-Seite im Browser-Cache landet, ist es meist schon zu spät und der böse Code läuft bereits. Zum Anderen haben noch längst nicht alle Hersteller passende Signaturen erstellt. Einen echten Exploit, der heise Security am Dienstag erreichte, erkannten am heutigen Samstag unter anderem CA, Kaspersky, Trend Micro, NOD32, Panda und F-Secure noch nicht.

Microsoft gibt eine ausführliche Liste von Workarounds, wie der Internet Explorer zu konfigurieren ist, um den Exploit ins Leere laufen zu lassen. Dazu gehört unter anderem der wenig praxistaugliche Tipp, Scripting zu deaktivieren, ohne das es auf eine Reihe von Webseiten zu Problemen bei der Darstellung und Bedienung kommen kann.

Solange Microsoft noch keinen Patch bereitstellt, sollte man zu einem alternativen Browser greifen, der die verwundbaren Microsoft-Bibliotheken nicht benutzt. Populäre Beispiele sind Firefox, Opera oder Safari.

Quelle: heise.de

Microsoft beobachtet derzeit die zunehmende Verbreitung eines neuen Windows-Wurms, der die seit mehreren Wochen bekannte Lücke in den RPC-Funktionen des Server-Dienstes ausnutzt, um in Systeme einzudringen. Insbesondere in Firmennetzen soll die derzeit beobachtete Variante Conficker.A an Fahrt zunehmen. Die meisten Meldungen liegen nach Angaben des Microsoft Malware Protection Centers aus den USA vor. Aber auch Kunden aus Europa, Asien und Südamerika seien betroffen. Zudem lägen Microsoft Berichte von mehreren hundert Heimanwendern vor.

Conficker öffnet auf infizierten Systemen einen Port, auf dem ein Webserver-ähnlicher Dienst laufen soll. Von dort kann ein System eine Kopie des Wurms nachladen, nachdem es initial infiziert wurde. Interessanterweise spielt der Wurm auf infizierten System den Patch zum Schließen der Sicherheitslücke ein, was aber weniger aus Freundlichkeit geschieht, sondern eher zum Ziel hat, andere RPC-Würmer draußen zu halten. Zusätzlich fragt Conficker diverse Webseiten ab, um die nach außen erscheinende IP-Adresse sowie die aktuelle Zeit zu ermitteln. Anhand der Zeit generiert der Wurm laut Symantec eine Liste von Domains, mit denen er Kontakt aufnimmt, um weiteren Code nachzuladen.

Schutz vor Conficker bietet weiterhin die Installation des Sicherheits-Updates von Microsoft sowie eine aktive Firewall, wobei die seit Windows XP integrierte und seit SP2 standardmäßig aktive Firewall in der Regel vollkommen ausreicht. Anwender sollten sicherheitshalber aber die Einstellungen überprüfen und sicherstellen, dass nicht ungewollt Ausnahmen definiert sind, die doch den Zugriff auf Dienste erlauben, die für die RPC-Lücke anfällig sind – etwa die Datei- und Druckfreigabe.

Quelle: heise.de

Nach Aussage von Google sind die kürzlich gemeldeten Manipulationen von Google-Mail-Konten nicht auf eine Cross-Site-Request-Forgery-Schwachstelle (CSRF) zurückführen. Vielmehr habe es sich nach einer Analyse zusammen mit den Betroffenen herausgestellt, dass simple Phishing-Angriffe auf die Inhaber der Mail-Konten die Ursache waren. Mit den abgephishten Daten hätten die Betrüger dann Zugriff auf das Mail-Konto gehabt und bestimmte Filter definieren können, um Mails automatisch an sich umzuleiten.

Damit war es in der Folge möglich, an die von Domain-Verwaltern per Mail verschickten Instruktionen zum Zurücksetzen des Passwortes zu gelangen und anschließend die Domain zu transferieren oder freizugeben. Opfer dieses Angriffs war nach eigenen Angaben Anfang November der Betreiber des bei GoDaddy.com registrierten Newsdienstes MakeUseOf.com.

Google widerspricht zudem Vermutungen, dass eine 2007 bekannt gewordene CSRF-Schwachstelle immer noch funktioniert. Allerdings tritt Google nicht explizit der im Blog GeekCondition veröffentlichten Anleitung entgegen, wie Unbefugte einen Filter im Mail-Konto anderer Anwender definieren können.

Schutz vor Pishing-Angriffen auf Google-Mail-Nutzer bietet nach Meinung von Google, wenn der Anwender den Maildienst grundsätzlich nur über SSL-gesicherte HTTP-Verbindungen aufruft und die Gültigkeit des Zertifikats prüft beziehungsweise Fehlermeldungen nicht einfach ignoriert. Auch die ICANN hat bereits Mitte des Jahres mit einem Leitfaden auf mögliche Phishing-Attacken hingewiesen, bei denen Administratoren auf nachgemachten Registrar-Seiten landen und dort Name und Passwort verraten. Leider hatte die ICANN die eigenen Empfehlungen wohl nicht beherzigt, sodass bereits einen Monat später die Domain der ICANN (und der IANA) von türkischen Hackern entführt wurde.

Quelle: heise.de

Ein neuer Schädling macht per Mail Runde und versucht wieder einmal, seine Empfänger in Angst und Schrecken zu versetzen, damit diese unbedacht auf den Anhang klicken. Die Mails geben vor, von einem Inkasso-Büro zu stammen, das mehrere Tausend Euro vom Konto abgebucht hat.

Sehr geehrte Damen und Herren!

Die Anzahlung Nr.885434211759 ist erfolgt Es wurden 5327.00 EURO Ihrem Konto zu Last geschrieben. Die Auflistung der Kosten finden Sie im Anhang in der Datei: Abrechnung.

xxxxxx GmbH & Co. KG
xxxxx Str. 21

Glücklicherweise ist es mit dem Klick auf den Anhang allein nicht getan, um den eigenen Rechner zu infizieren. Zuvor muss das Opfer das mit einem Zipper gepackte Archiv auspacken und auf die Datei abrechnung.lnk klicken. Die hat es dann aber in sich: Sie ruft die Command-Shell (cmd.exe) mit der ebenfalls entpackten Datei scann.a als Argument auf, in welcher der eigentliche Schädling steckt.

Damit nutzen die Malware-Autoren einen Trick, vor dem heise Security bereits vor vier Jahren in einer Analyse der Sicherheitsfunktionen von Windows XP SP2 gewarnt hatte. Über die Shell lassen sich Dateien mit beliebigen Dateierweiterungen ausführen. Dieser Umweg über cmd.exe führt auch dazu, dass die ZoneID komplett ignoriert wird. Anhand der ZoneID erkennt Windows eine aus dem Internet heruntergeladene Datei auch später noch und kann vor dem Ausführen eine Warnung anzeigen.

Da die eigentliche Schaddatei die unverdächtige Endung .a trägt, dürfte so mancher Scanner die Datei ignorieren und somit den Schädling übersehen. Wenn er denn hinschaut, könnte ihn allerdings der ungewöhnliche Packer argwöhnisch machen. Aktuell (Stand 15:30) erkennt keiner der bekannten Antiviren-Hersteller den Schädling namentlich. Nach ersten Analysen von heise Security nimmt der Schädling Kontakt mit einem Server in China auf, um weitere Dateien nachzuladen.

Wie immer gilt: Nicht in Panik versetzen lassen und nicht unbedacht Archive öffnen und darin enthaltene Dateien anklicken, denn genau auf diese Reaktion setzen die Virenautoren. Weitere Hinweise zum Schutz vor Schädlingsbefall liefern die Antivirenseiten von heise Security.

Quelle: heise.de

Eine Sicherheitslücke in Google Mail soll es Angreifern ermöglichen, eigene Filter im Postfach eines Opfer zu definieren und so etwa bestimmte empfangene Mails auf die Adresse des Angreifers umzulenken. Aktuell gibt es mehrere Berichte über erfolgreiche Attacken, bei denen die Lücke missbraucht wurde, um die Kontrolle über die Verwaltung der Domains von Opfern zu erhalten.

Im Wesentlichen soll die Lücke auf einer Cross-Site-Request-Forgery-Schwachstelle (CSRF) beruhen, bei der eine präparierte Webseite den Filter in Google Mail setzt. Dazu muss das Opfer allerdings ein Browserfenster mit Google Mail geöffnet und sich dort authentifiziert haben sowie in einem zweiten Browserfenster die manipulierte Webseite aufrufen.

Ist der Filter gesetzt, muss der Angreifer auf den Seiten des Domain-Verwalters die Funktion zum Rücksetzen des Passwortes für das Management der Domain aufrufen und bekommt anschließend per Mail die eigentlich für das Opfer vorgesehenen Instruktionen zum Erhalt eines neuen Passworts. Damit ist er in der Lage, das Konto und somit die Kontrolle über die Domain zu übernehmen und diese zu transferieren oder freizugeben.

Eine sehr ähnliche Lücke gab es Mitte 2007 bei Google Mail, die Berichten zufolge ebenfalls zum Umleiten von Mail per Filter benutzt wurde. Allerdings ging man bislang davon aus, dass Google die Lücke seinerzeit beseitigt hatte. Offenbar ist dem nicht so, denn Google verwendet Analysen zufolge immer noch eine sitzungsbezogene statt einer request-bezogenen Authentifizierung. Letztere böte nämlich Schutz vor CRSR-Angriffen, da ein Angreifer dabei eine bestimmte ID für einen gültigen HTTP-Request erraten muss.

Immerhin können Anwender sich mit dem Plug-in NoScript selbst vor CSRF-Angriffen schützen. Dies versucht verdächtige Anfragen zu erkennen und zu blockieren. Daneben kann NoScript auch vor Cross-Site-Scripting-Attacken schützen. In den Genuss dieses Schutzes kommen derzeit jedoch nur Anwender eines Mozilla-basierten Browsers wie Firefox.

• Gmail Security Flaw Proof of Concept, Beschreibung von Brandon.
• Gmail Exploit May Aid Domain Hijacking Gmail Security Flaw Proof of Concept, Beschreibung von Lidija Davis

Quelle: heise.de

Einen Monat ist es nun her, als am 22. Oktober, also am Geburtstag meines Vaters, diese Seite online ging. Hätte selber nicht damit gerechnet, dass im ersten Monat so viele Hits auf Artikel dieser Seite zustande kommen. Danke für Eure Unterstützung! Die Zugriffe machen Mut auf mehr, auch wenn einige der Meinung sind, dass dies alles sinnlos ist. 549 unterschiedliche Benutzer bedeuten für mich, dass quasi 17 unterschiedliche und reale Personen pro Tag diese Seite besucht haben.

Statistik nach einem Monat

Ich persönlich bin mit einer festen IP unterwegs, was mich ebenfalls erstaunt, denn meine eigenen Besuche bzw. Änderungen werden nur einmal in der Statistik aufgeführt. Vielen Dank nochmal! Alleine diese Statistik macht Mut zum Weitermachen.

Was bedeutet “nicht gesehener Traffic”?

Grundsätzlich wird zwischen Zugriffen von normalen Benutzern und Zugriffen von Suchmaschinen unterschieden. Der Googlebot steht hier an Platz eins mit 2977 Hits, gefolgt vom UniversalFeedParser mit 334 Zugriffen. Plätze drei und vier belegen hier MSNBot-media und MSNBot mit 226 und 225 Durchsuchungen. Der Bot von Yahoo schafft es mit 217 auf Platz 5. Da ich mein Online-Marketing momentan eher auf Google beschränke lässt sich der Faktor von etwa 10 gegenüber anderen Suchmaschinen schnell erklären. Mal schauen wie es im nächsten Monat aussieht, wenn ich die Services von MSN und Yahoo auch noch in Anspruch nehme. Weniger werden diese Unternehmen auf keinen Fall meine Seite durchsuchen.

Was wünsche ich mir für die Zukunft?

Da das meiste Feedback durch User zustande kommt, welche nicht die Kommentar-Funktion dieser Seite benutzen, wünsch ich mir, dass diese mehr beachtet wird. Diese verlangt zwar, dass Name und Email-Adresse angegeben werden, aber Ihr könnt Euch 100% sicher sein, dass Eure Daten nicht an Dritte weiter geleitet oder sogar verkauft werden! Ich bin selber Gegner dieser Methoden wünsche mir allgemein, dass Benutzer immer sehr sorgsam mit der Herausgabe ihrer persönlichen Daten sind. Nicht umsonst versuche ich seit nunmehr fünf Jahren die Leute dazu zu bewegen, mehr auf Ihre Daten acht zu geben und ein gesundes Datenschutzverständnis in unserer Gesellschaft publik zu machen.

Martin Beck und Erik Tews haben in ihrem Paper “Practical Attacks against WEP und WPA” Details zu ihrem Angriff auf WPA-gesicherte Funknetze veröffentlicht. Im Wesentlichen handelt es sich um eine Variante der seit Anfang 2005 bekannten chopchop-Attacke auf WEP-gesicherte Netze. Der Name geht auf das von KoreK entwickelte Tool chopchop zurück, mit dem man ein beliebiges verschlüsseltes Datenpaket ohne Kenntnis des WEP-Schlüssels entschlüsseln kann.

Das Programm schneidet das letzte Byte eines WEP-Paketes ab. Unter der Annahme, dass das Byte 0 war, versucht es, durch eine XOR-Verknüpfung der letzten vier Bytes mit einem bestimmten Wert wieder eine gültige Checksumme zu rekonstruieren. Dann sendet es das Paket an einen Access Point und beobachtet, ob dieser es akzeptiert. Wenn nicht, nimmt es an, dass das abgeschnittene Byte eine 1 war – im ungünstigsten Fall probiert es das bis 256 durch. Dieses Spiel wiederholt sich dann für jedes weitere Byte des Paketes. Am Ende hat der Angreifer das Paket im Klartext.

Das in der Regel unter WPA eingesetzte Temporal Key Integrity Protocol (TKIP) verwendet zwar wie WEP den RC4-Algorithmus, hat allerdings einige Sicherheitsmaßnahmen implementiert, wozu unter anderem Anti-chopchop-Funktionen gehören. So werden die Verbindungen im WLAN beendet, wenn mehr als zwei Pakete mit falschen Message Integrity Check (MIC) innerhalb von 60 Sekunden von einem Client empfangen wurden. Zudem erschwert der TKIP Sequence Counter (TSC) das Wiedereinspielen abgefangener Pakete, wodurch die chopchop-Attacke und andere Replay-Attacken erheblich schwerer funktionieren. Liegt der TSC des empfangenen Paketes unter der des aktuellen Zählers, wird es einfach verworfen.

Die Limitierungen lassen sich laut Beck und Tews aber relativ leicht umgehen, indem man einfach beim Senden die 60-Sekunden-Zeitspanne einhält und sich die Quality-of-Service-Funktionen von WPA-Access-Points zunutze macht. Die unterstützen nämlich 8 Kanäle, sodass man das “gechopte” Paket statt an den Senderkanal einfach an einen anderen Kanal zurückspielt, um den TKIP Sequence Counter auszutricksen. Üblicherweise findet der Verkehr hauptsächlich auf Kanal 0 statt, während der TSC auf den anderen Kanälen so gut wie nie erhöht wird und ein zurückgespieltes Paket mit seinem TSC immer über der des empfangenen liegt.

Wird die vorgestellte WPA-Attacke auf ein verschlüsseltes ARP-Paket angewendet, dessen Aufbau im Klartext ja in wesentlichen Teilen immer der selbe ist, so muss man zum Entschlüsseln nur die IP-Adressen sowie die MIC und den noch aus WEP-Zeiten stammenden Integrity Check Value (ICV) erraten. Für die insgesamt 12 Bytes von MIC und ICV tut das chopchop, die IP-Adressen muss der Angreifer selbst raten. Mit dem gesamten Paket im Klartext und dem Wissen über den MIC ist es nun laut Beck und Tews möglich, den Schlüsselstrom für die Kommunikation vom Access Point zum Client ermitteln – ohne den ursprünglichen Schlüssel zu kennen. Im Anschluss lassen sich zudem weitere Pakete vom AP an den Client mit weniger Aufwand entschlüsseln. Mit dem Schlüsselstromn lassen sich eigene Pakete verschlüsseln und an einen Client versenden, etwa um den weiteren Verkehr mittels gefälschter ARP- oder ICMP-Pakete umzuleiten.

Der WPA-Angriff ist in der beschriebenen Weise allerdings erheblich limitiert: Für einen erfolgreichen Angriff muss die Zeit bis zum Erzeugen eines neuen TKIP-Schlüssels (Rekeying) relativ groß sein, Beck und Tews gehen von 3600 Sekunden aus. Zudem muss die Wireless Multimedia Extension (WMM) aktiviert sein, damit mehrere QoS-Kanäle verfügbar sind. Nach dem Entschlüsseln eines Paketes (sofern der Verkehr nur über Kanal 0 geht) kann der Angreifer jeweils nur ein Paket an die Kanäle 1 bis 7 senden. Anschließend liegt der TSC seiner Pakete unter dem der Kanäle.

Darüber hinaus arbeitet der Angriff nur in eine Richtung: Vom Access Point zu einem Client. Angriffe auf den AP sind so nicht möglich. Zudem funktioniert er derzeit nur mit ARP-Paketen, um innerhalb von 12 bis 15 Minuten an einen Schlüsselstrom zu gelangen. Zwar lassen diese Einschränkungen den Angriff auf WPA weitaus weniger spektakulär erscheinen als seinerzeit die Angriffe auf WEP. Allerdings ist ein Anfang gemacht und die innovativen Ansätze zeigen, dass WPA nicht nur durch Brute-Force-Angriffe zu knacken ist. Ob der Angriff bereits die Sicherheit des eigenen WPA-gesicherten Netzes bedroht, hängt von der Verwendung ab. Möglicherweise lässt sich auf diese Weise bereits in Unternehmensnetzen genug Schindluder treiben. Die WLANs von Heimanwendern dürften jedoch erst einmal nicht bedroht sein, da der Angriff kaum Gelegenheit zum Schwarzsurfen bietet.

Tews und Beck schlagen in ihrer Untersuchung unter anderem vor, die Rekeying-Dauer von TKIP auf 120 Sekunden oder weniger herunterzusetzen, um den beschriebenen Angriff abzuwehren. Innerhalb dieses Zeitraums ließen sich nur Teile des Paketes berechnen. Besser wäre nach Meinung der Autoren, gleich AES-CCMP als Verschlüsselungsmethode einzusetzen, sofern der Access Point dies unterstütze. Dieser Algorithmus gilt derzeit als sicher.

Quelle: heise.de