Menu Butler – Dashboard-Widget zum Anpassen der Menüleiste

Sonntag, 24 Februar 2008 21:34 - Geschrieben von René Lindhorst

Widget-IconIm rechten Teil der Menüleiste von Mac OS X befinden sich bekanntlich verschiedene Symbole. Über diese kann man entweder verschiedene Statusinformationen (z.B. der WLAN-Verbindung, der Batterie o.ä.) erhalten oder schnell auf bestimmte Funktionen zugreifen.

Die zu Mac OS gehörenden Symbole lassen sich meist über die verschiedenen Bereiche der Systemeinstellungen einblenden. Einfacher und schneller geht es jedoch mit dem Dashboard-Widget Menu Butler. Es zeigt alle verfügbaren Symbole an (insgesamt 21 Menu-Items) und mit einem Klick werden sie aktiviert.

Menu-Butler

Die Symbole der Menüleiste lassen sich nach den eigenen Wünschen anordnen. Dazu muss man lediglich die Befehlstaste (Apfel-Taste) gedrückt halten, während man die Symbole mit der Maus umordnet. Um die Symbole wieder aus der Leiste zu entfernen, kann man sie bei gedrückter Befehlstaste aus der Leiste ziehen und sie verschwinden in der typischen “Staubwolke”. Leider funktioniert beides nicht mit Symbolen die von Drittanbietern zur Verfügung gestellt werden.

Links:
http://www.macmage.com/menubutler.php

Ähnliche Beiträge:


WEP – Schwachstellen

Samstag, 23 Februar 2008 21:09 - Geschrieben von René Lindhorst

WLAN-Icon Nachdem ich bereits die Shared-Key-Authentication und die WEP-Verschlüsselung erklärt habe, ist es nun an der Zeit die Schwachstellen von WEP genauer zu betrachten.

WEP sollte für Wireless-LANs eine den drahtgebundenen Netzwerken vergleichbare Sicherheit bieten. Es sollte sowohl die Zugangskontrolle als auch die Abhörsicherheit und Datenintegrität gewährleisten. Spätestens seit 2001 ist jedoch bekannt, dass der Sicherheitsmechanismus diese Aufgaben aufgrund diverser Schwachstellen nicht erfüllen kann.

Die Schwachstellen von WEP, wie sie in der einschlägigen Literatur dargestellt werden, sind:

  • Zu kurze WEP-Schlüssel Die Schlüssellänge von 40 Bit bietet keinen ausreichenden Schutz vor Brute-Force-Angriffen. Ein Angreifer kann durch das Aufzeichnen eines einzigen verschlüsselten Datenpaketes und das systematische Durchprobieren möglicher Schlüssel den richtigen WEP-Schlüssel in kurzer Zeit finden. Ein 104 Bit langer Schlüssel, der erst mit IEEE-802.11i (2004) offiziell in den Standard aufgenommen wurde, ist durch einen solchen Brute-Force-Angriff jedoch nicht in praktikabler Zeit zu bestimmen.
  • Kein Schlüsselmanagement Die statischen WEP-Schlüssel müssen manuell bei allen Clients und Access-Points im Netzwerk getauscht werden. Da die Verteilung auf diese Weise einen hohen Verwaltungsaufwand bedeutet, werden die Schlüssel in der Regel selten oder gar nicht gewechselt. Dies hat jedoch eine starke Gefährdung der Sicherheit zur Folge. Denn somit ist der Schlüsselstrom bei einem statischen sich nie ändernden WEP-Schlüssel nur vom IV abhängig. Da zusätzlich alle Teilnehmer den selben WEP-Schlüssel verwenden, besteht eine erhebliche Gefahr, dass ein Angreifer diesen Schlüssel ermitteln kann.
  • Zu kurze Initialisierungsvektoren Mit einer Länge von 24 Bit gibt es nur eine Gesamtmenge von 2^24 möglichen IVs und das führt zu einer häufigen Wiederverwendung. Somit entstehen aus den wiederholten IVs und dem WEP-Schlüssel auch Schlüsselströme, die bereits verwendet wurden. Ein Angreifer kann durch den unverschlüsselt übertragenen IV solche IV-Kollisionen erkennen und eine sog. Known-Plaintext-Attack durchführen.
  • Schwache Initialisierungsvektoren Einige IVs ermöglichen Rückschlüsse auf den WEP-Schlüssel. Die mit ihnen erzeugten Schlüsselströme korrelieren stärker mit dem WEP-Schlüssel als vorgesehen. Kann ein Angreifer genug Chiffretext aufzeichnen, der mit solchen schwachen IVs erzeugt wurde, so kann er daraus den eigentlichen WEP-Schlüssel ermitteln. Ein solcher Angriff wird als Weak-Attack bzw. FMS-Angriff bezeichnet und ist linear zur Schlüssellänge.
  • Mangelhafte Integritätsprüfung Der ICV ist keine kryptographische Prüfsumme sondern lediglich ein 32 Bit langer CRC (Cyclic Redundancy Check) Wert. Er bietet Schutz gegen zufällige Übertragungsfehler jedoch nicht gegen gezielte Manipulationen eines Angreifers. Ein solcher könnte durch gleichzeitige Manipulation der Nutzdaten und des CRC ein weiterhin gültiges Paket erzeugen. Somit ist das Verfahren wirkungslos, denn weder Sender noch Empfänger könnten denen manipulierten Nachrichteninhalt erkennen. Eine solche Nachrichtenmodifikation wird als Injection-Attack bezeichnet.
  • Fälschbare Authentisierung Ein Angreifer kann die Authentisierung eines anderen Clients beobachten und dabei den IV sowie den Challenge-Text sowohl im Klartext als auch verschlüsselt aufzeichnen. Daraus kann er anschließend den Schlüsselstrom berechnen. Diesen kann er für seine eigene Authentisierung nutzen. Ein solcher Angriff wird als Authentication-Spoofing bezeichnet und gehört zur Klasse der Message-Injection-Angriffe. Auf diese Weise ermittelte Schlüsselströme kann der Angreifer außerdem dazu verwenden, andere verschlüsselte Daten, mit entsprechendem IV, zu entschlüsseln. Die Shared-Key-Authentication ist somit in zweierlei Hinsicht ein Sicherheitsrisiko.
  • Fehlende Access-Point-Authentifizierung Die Access-Points authentisieren sich nicht gegenüber den Clients. Somit ist ein Man-in-the-Middle-Angriff möglich, bei dem sich der Angreifer als Access-Point ausgibt. Dies ermöglicht ihm, die Daten des Clients zu analysieren und ggf. zu manipulieren und anschließend an den richtigen Access-Point weiterzuleiten.
  • Keine Benutzer-Authentifizierung Die Authentifizierung überprüft nicht die Authentizität des Benutzers. Es werden lediglich die WLAN-Adapter authentifiziert. Dazu ist der WEP-Schlüssel auf dem jeweiligen Gerät z.T. sogar im Klartext abgelegt. So kann bspw. ein verloren gegangenes Notebook zum Eindringen in das WLAN verwendet werden.
  • Unverschlüsselte Steuerungsdaten Es werden nur die Nutzdaten, jedoch nicht die Steuerungsdaten verschlüsselt. Somit kann ein Angreifer bspw. die MAC-Adressen aller über das WLAN kommunizierenden Geräte abhören.

(Quelle: Lindhorst, René: Sicherheit von drahtlosen Netzwerken, Diplomarbeit, November 2007)

Diese große Anzahl an Schwachstellen und die diversen Angriffsmöglichkeiten zeigen deutlich, warum WEP heute nicht mehr eingesetzt werden sollte. WPA bzw. WPA2 sind heute die Sicherheitsmechanismen der Wahl um das eigene private WLAN abzusichern. In weiteren Artikeln werde ich diese Sicherheitsstandards noch genauer vorstellen.

Links:
http://standards.ieee.org/getieee802/download/802.11-1999.pdf
http://standards.ieee.org/getieee802/download/802.11i-2004.pdf

Ähnliche Beiträge:


Der größte Feind des Quellcodes

Freitag, 22 Februar 2008 13:42 - Geschrieben von René Lindhorst

Ein interessanter aber auch etwas länglicher Artikel (wie üblich) zum Thema “Code-Size” von Steve Yegge:

I happen to hold a hard-won minority opinion about code bases. In particular I believe, quite staunchly I might add, that the worst thing that can happen to a code base is size.

I say “size” as a placeholder for a reasonably well-formed thought for which I seem to have no better word in my vocabulary. I’ll have to talk around it until you can see what I mean, and perhaps provide me with a better word for it. The word “bloat” might be more accurate, since everyone knows that “bloat” is bad, but unfortunately most so-called experienced programmers do not know how to detect bloat, and they’ll point at severely bloated code bases and claim they’re skinny as a rail.

[...]

My minority opinion is that a mountain of code is the worst thing that can befall a person, a team, a company. I believe that code weight wrecks projects and companies, that it forces rewrites after a certain size, and that smart teams will do everything in their power to keep their code base from becoming a mountain. Tools or no tools. That’s what I believe.

[Stevey's Blog Rants: Code's Worst Enemy]

Ähnliche Beiträge:


Voreingestellte WPA-Schlüssel in WLAN-Routern leicht erratbar – heise Security

Donnerstag, 21 Februar 2008 23:57 - Geschrieben von René Lindhorst

WLAN-IconPassend zu einem meiner aktuelle Schwerpunktthemen, der WLAN Sicherheit, gab es heute einen kurzen Artikel auf heise Security. Darin ging es um einen in Großbritannien für Aufmerksamkeit sorgenden Fall, indem Sky Broadband einen bestimmten WLAN-Router zwar vorbildlich mit WPA-Verschlüsselung ausliefert aber der PSK dabei von der MAC-Adresse des Gerätes abhängt.

Der Anfang des Artikels hat dabei jedoch besonders meine Aufmerksamkeit erregt:

Dass unverschlüsselte heimische WLANs vielerlei Angriffsmöglichkeiten bieten, hat sich glücklicherweise unter Anwendern rumgesprochen. Viele Hersteller liefern ihre Geräte deshalb mittlerweile mit einem ab Werk eingestellten WPA-Schlüssel aus, der sich von Gerät zu Gerät unterscheidet.

[Voreingestellte WPA-Schlüssel in WLAN-Routern leicht erratbar - heise Security]

Nach meinen Recherchen kann ich mich dieser Aussage jedoch nicht anschließen. Im November 2007 habe ich die Produktpaletten einiger großer Hersteller bezüglich der unterstützten Sicherheitsstandards und der Werkseinstellungen untersucht. Anhand der Daten aus den einzelnen Handbüchern ergab sich folgendes Bild der Standard-Sicherheitseinstellungen:

  • Asus – unverschlüsselt
  • AVM – WPA-Personal
  • D-Link – unverschlüsselt
  • LANCOM – WEP (104Bit)
  • Linksys – 40% unverschlüsselt, 60% ohne Angaben
  • Netgear – 5 unverschlüsselt, 3 ohne Angaben
  • T-Com – Speedport W100XR, W501V unverschlüsselt, W700V mit WPA2, W900V mit WPA

Sollte sich also innerhalb der letzten 3 Monate die Situation nicht drastisch geändert haben, dann ist die Anzahl der WLAN-Router mit WPA-Verschlüsselung ab Werk eher sehr gering!

Ähnliche Beiträge:


WEP – Verschlüsselung

Donnerstag, 21 Februar 2008 15:22 - Geschrieben von René Lindhorst

WLAN-IconNachdem ich im letzten Beitrag kurz die Shared-Key-Authentication beschrieben habe ist nun die WEP-Verschlüsselung an der Reihe. Wie in der Einführung zu WEP erläutert, wird bei der Verschlüsselung mittels WEP der Datenteil der Pakete inklusive einer Prüfsumme verschlüsselt und so zwischen Client und Access-Point ausgetauscht. Durch die symmetrische Verschlüsselung mittels RC4-Algorithmus sollte (!) sichergestellt werden, dass nur Teilnehmer denen der WEP-Schlüssel bekannt ist, über das WLAN kommunizieren können.

WEP-Verschlüsselung nach IEEE-802.11

Der im Standard beschriebene Ablauf der Ver- und Entschlüsselung ist in der Abbildung dargestellt und läuft in den folgenden Schritten ab:

  • Zu Beginn liegt die zu sendende Nachricht im Klartext vor.
  • Über das in ein MAC-Frame eingefügte Nachrichten-Fragment wird eine 32-Bit-Prüfsumme, der so genannte Integritätsprüfwert (Integrity Check Value, ICV), gebildet.
  • Die Daten und der ICV werden anschließend konkateniert.
  • Zum Verschlüsseln dieser wird der zuvor zwischen den Kommunikationspartner ausgetauschte geheime WEP-Schlüssel benötigt. Dieser hat nach dem 802.11-Grundstandard (1999) eine Schlüssellänge von 40 Bit (WEP-64) bzw. 104 Bit (WEP-128) nach IEEE-802.11i (2004).
  • Der WEP-Schlüssel wird mit einem 24 Bit langen Initialisierungsvektor (Initialization Vector, IV) kombiniert, der möglichst für jedes Frame neu gesetzt werden sollte. Aus diesem Gesamtschlüssel (WEP-Seed) entsteht mittels des RC4-Zufallszahlengenerators (Pseudo Random Number Generator, PRNG) ein für die Übertragung einzigartiger Schlüsselstrom (Keystream).
  • Der Schlüsselstrom wird XOR mit den Daten und dem ICV verknüpft. So entsteht der verschlüsselte Datenstrom, der Chiffretext (Ciphertext).
  • Der IV wird unverschlüsselt zusammen mit dem Chiffretext übertragen. So kann der Empfänger den IV mit dem ihm bekannten WEP-Schlüssel kombinieren, um den selben Schlüsselstrom zu erhalten.
  • Eine erneute XOR-Verknüpfung mit dem Chiffretext liefert dann den ursprünglichen Klartext.
  • Um eine korrekte Entschlüsselung sicherzustellen, bildet der Empfänger ebenfalls eine Prüfsumme der entschlüsselten Daten und vergleicht diese mit dem entschlüsselten ICV. Sind beide identisch geht der Empfänger davon aus, dass die Entschlüsselung erfolgreich war und verarbeitet das Paket weiter.

(Quelle: Lindhorst, René: Sicherheit von drahtlosen Netzwerken, Diplomarbeit, November 2007)

Links:
http://www.ieee.org
http://standards.ieee.org/getieee802/download/802.11-1999.pdf
http://standards.ieee.org/getieee802/download/802.11i-2004.pdf

Ähnliche Beiträge: