Wireless Risk Potential Scenario: WEP - Revision history

Grauel at 10:59, 31 October 2006

2006-10-31T10:59:01Z

← Older revision		Revision as of 10:59, 31 October 2006
Line 4:		Line 4:

	Autoren: Moritz Grauel und Matthias Naber		Autoren: Moritz Grauel und Matthias Naber

			Bei Fragen stehen wir gerne per eMail zur Verfügung. Die Adressen sind jeweils unsere Nachnamen gefolgt von @informatik.hu-berlin.de

	= Ziele =		= Ziele =

Grauel: /* Code */

2006-10-31T10:57:34Z

Code

@@ Line 161: / Line 161: @@
 = Code =
 Unsere Implementation des Fragmentierungsangriffs: [[attack.c]]
 Dazu notwendig:
 * Als Verifikation unseres "erratenen" Schlüssels: [[rc4.h]] [[rc4.c]] (Quelle: Google-Groups)
 * Implementation des crc32-Prüfsummenalgorithmus: [[crc32.c]] (Quelle: SAR)

Grauel: /* Code */

2006-10-31T10:33:11Z

Code

← Older revision		Revision as of 10:33, 31 October 2006
Line 165:		Line 165:
	Dazu notwendig:		Dazu notwendig:
	* Als Verifikation unseres "erratenen" Schlüssels: [[rc4.h]] [[rc4.c]] (Quelle: Google-Groups)		* Als Verifikation unseres "erratenen" Schlüssels: [[rc4.h]] [[rc4.c]] (Quelle: Google-Groups)
			* Implementation des crc32-Prüfsummenalgorithmus: [[crc32.c]] (Quelle: SAR)

Grauel: /* Code */

2006-10-31T10:31:22Z

Code

← Older revision		Revision as of 10:31, 31 October 2006
Line 162:		Line 162:

	Unsere Implementation des Fragmentierungsangriffs: [[attack.c]]		Unsere Implementation des Fragmentierungsangriffs: [[attack.c]]

			Dazu notwendig:
			* Als Verifikation unseres "erratenen" Schlüssels: [[rc4.h]] [[rc4.c]] (Quelle: Google-Groups)

Grauel: /* Code */

2006-10-31T10:18:30Z

Code

← Older revision		Revision as of 10:18, 31 October 2006
Line 160:		Line 160:

	= Code =		= Code =

			Unsere Implementation des Fragmentierungsangriffs: [[attack.c]]

Grauel at 10:00, 24 October 2006

2006-10-24T10:00:10Z

← Older revision		Revision as of 10:00, 24 October 2006
Line 1:		Line 1:
	Im Rahmen des [[W2006-ITS\|IT Security Workshop 2006]] haben wir uns mit der Sicherheit der WEP-Verschlüsselung befasst. Wir haben bestehende Schwachstellen analysiert und einen eigenen Angriff nach Vorlage von [http://tapir.cs.ucl.ac.uk/bittau-wep.pdf A.Bittau] entwickelt.		Im Rahmen des [[W2006-ITS\|IT Security Workshop 2006]] haben wir uns mit der Sicherheit der WEP-Verschlüsselung befasst. Wir haben bestehende Schwachstellen analysiert und einen eigenen Angriff nach Vorlage von [http://tapir.cs.ucl.ac.uk/bittau-wep.pdf A.Bittau] entwickelt.

			[[Media:Wep-security.pdf\|Folien zur Presentation]]

	Autoren: Moritz Grauel und Matthias Naber		Autoren: Moritz Grauel und Matthias Naber

Grauel: /* Unbekannter SNAP */

2006-10-20T10:41:47Z

Unbekannter SNAP

← Older revision		Revision as of 10:41, 20 October 2006
Line 152:		Line 152:

	=== Unbekannter SNAP ===		=== Unbekannter SNAP ===
	Aus uns völlig unbekannten Gründen hat der AP ständig WEP-verschlüsselte Pakete mit einem SNAP-Header von AA AA AA 03 00 00 00 '''00 27''' verschickt (auch ohne angemeldete Teilnehmer). Dies hat unsere Annahme mit dem bekannten SNAP-Header zunächst durcheinander gebracht, später dann aber deutlich vereinfacht. Wir konnten praktisch immer davon ausgehen, dass es sich um ein solches Paket handelt. Vermutlich handelt es sich um Managementframes. Es handelt sich jedenfalls nicht um eines, der bekannten Protokolle -> kein Problem		Aus uns völlig unbekannten Gründen hat der AP ständig WEP-verschlüsselte Pakete mit einem SNAP-Header von AA AA 03 00 00 00 '''00 27''' verschickt (auch ohne angemeldete Teilnehmer). Dies hat unsere Annahme mit dem bekannten SNAP-Header zunächst durcheinander gebracht, später dann aber deutlich vereinfacht. Wir konnten praktisch immer davon ausgehen, dass es sich um ein solches Paket handelt. Vermutlich handelt es sich um Managementframes. Es handelt sich jedenfalls nicht um eines, der bekannten Protokolle -> kein Problem

	=== viel ''noise'' ===		=== viel ''noise'' ===

Grauel: /* Schwache IVs */

2006-10-20T10:40:22Z

Schwache IVs

← Older revision		Revision as of 10:40, 20 October 2006
Line 81:		Line 81:
	=== Schwache IVs ===		=== Schwache IVs ===

	Aufgrund einer Schwachstelle im RC4-~~Algorythmus~~ lassen sich aus bestimmten IVs Rückschlüsse auf Bits im Schlüssel ziehen. Es ist daher möglich, mit relativ wenigen abgefangenen Paketen den presharedkey zu errechnen. Ein Programm, dass dieses Verfahren einsetzt, ist das bekannte [http://www.aircrack-ng.org aircrack]. Mit nur ca 150.000 bis 300.000 Paketen kann man innerhalb von Sekunden (oft sogar schneller) den presharedkey errechnen.		Aufgrund einer Schwachstelle im RC4-Algorithmus lassen sich aus bestimmten IVs Rückschlüsse auf Bits im Schlüssel ziehen. Es ist daher möglich, mit relativ wenigen abgefangenen Paketen den presharedkey zu errechnen. Ein Programm, dass dieses Verfahren einsetzt, ist das bekannte [http://www.aircrack-ng.org aircrack]. Mit nur ca 150.000 bis 300.000 Paketen kann man innerhalb von Sekunden (oft sogar schneller) den presharedkey errechnen.
	Durch die Verlängerung des Schlüssels wächst die Anzahl der schwachen IVs derart, dass die benötigte Menge abgefangener Pakete nur linear steigt. (Doppelte Schlüssellänge -> Doppelter Aufwand)		Durch die Verlängerung des Schlüssels wächst die Anzahl der schwachen IVs derart, dass die benötigte Menge abgefangener Pakete nur linear steigt. (Doppelte Schlüssellänge -> Doppelter Aufwand)

Grauel: /* Verschlüsselung bei WEP */

2006-10-20T10:40:10Z

Verschlüsselung bei WEP

← Older revision		Revision as of 10:40, 20 October 2006
Line 33:		Line 33:

	=== Verschlüsselung bei WEP ===		=== Verschlüsselung bei WEP ===
	Mit dem Zufallszahlengenerator RC4 wird eine Zufallszahlenfolge gebildet, die so lang ist, wie der zu verschlüsselnde Text (plus 4 Byte). Der RC4-~~Algorythmus~~ wird dabei mit dem Schlüssel (40 oder 104 Bit) und einem sogenannten Initialisierungsvektor (IV) initiiert. Der IV hat eine Länge von 24 Bit. Zusammen mit dem Schlüssel ergeben sich so die 64 bzw 128 Bit, für die WEP bekannt ist. Der Schlüssel muss a priori allen Teilnehmern bekannt sein, der IV wird jedesmal im Klartext mitverschickt.		Mit dem Zufallszahlengenerator RC4 wird eine Zufallszahlenfolge gebildet, die so lang ist, wie der zu verschlüsselnde Text (plus 4 Byte). Der RC4-Algorithmus wird dabei mit dem Schlüssel (40 oder 104 Bit) und einem sogenannten Initialisierungsvektor (IV) initiiert. Der IV hat eine Länge von 24 Bit. Zusammen mit dem Schlüssel ergeben sich so die 64 bzw 128 Bit, für die WEP bekannt ist. Der Schlüssel muss a priori allen Teilnehmern bekannt sein, der IV wird jedesmal im Klartext mitverschickt.
	Über den Klartext wird vor der Verschlüsselung eine CRC32-Prüfsumme (Integrity Check Value - ICV) berechnet und hinten an den Klartext angehängt. Anschließend wird der Klartext (und die Prüfsumme) mit der RC4-Zufallszahl verschlüsselt. Vor den somit entstandenen Ciphertext wird der IV und ein Schlüsselindex (WEP unterstützt 4 verschiedene Schlüssel) geschrieben.		Über den Klartext wird vor der Verschlüsselung eine CRC32-Prüfsumme (Integrity Check Value - ICV) berechnet und hinten an den Klartext angehängt. Anschließend wird der Klartext (und die Prüfsumme) mit der RC4-Zufallszahl verschlüsselt. Vor den somit entstandenen Ciphertext wird der IV und ein Schlüsselindex (WEP unterstützt 4 verschiedene Schlüssel) geschrieben.

Line 39:		Line 39:

	Bildquelle [http://de.wikipedia.org Wikipedia]		Bildquelle [http://de.wikipedia.org Wikipedia]


	=== Entschlüsselung bei WEP ===		=== Entschlüsselung bei WEP ===

Grauel: /* Probleme */

2006-10-20T10:39:40Z

Probleme

← Older revision		Revision as of 10:39, 20 October 2006
Line 130:		Line 130:

	= Probleme =		= Probleme =

			=== Speicherplatz ===
			Da der AP nur über 16 MB Speicher verfügt, haben wir uns entschieden, zusätzlichen Platz per NFS ''einzumounten''. Das hat sich als etwas schwieriger erwiesen, als wir dachten. Die NFS-Module, die wir im Internet fanden, sind regelmäßig eingefroren und ließen sich dann auch nicht mehr (ohne Neustart) entfernen.

			Das BRN-Projekt hat uns daraufhin die Module zur Verfügung gestellt, die sie benutzen -> Problem gelöst

			=== Fake-Authentifizierung ===
			Ohne Authentifizierung am AP waren wir keine berechtigten Teilnehmer und der Router hat unsere Pakete lediglich mit Deauthentifizierungsframes beantwortet. Die Aircrack-Suite bietet aber ein Tool, das sich beim AP anmeldet -> Problem gelöst

			=== madwifi-Treiber ===
			Um Pakete beliebigen Inhalts (sowie ungültige Pakete) verschicken zu können, benötigt man gepatchte Treiber, die das ath0raw-Device zur Verfügung stellen. Die Treiber, die wir vom BRN-Projekt erhalten haben waren bereits gepatcht -> Problem gelöst

			=== Sequenznummer ===
			Fragmentierte Pakete müssen alle die selbe Sequenznummer im 802.11-Header haben, damit sie wieder zusammengesetzt werden können. Der madwifi-Treiber hat aber auch beim Raw-Device die Sequenzummer selbst verwaltet und in der Regel inkrementiert.
			Dieser Mechanismus lässt sich nur umgehen, wenn man bei dem Paket das ''retransmit-Bit'' setzt -> Problem gelöst

			=== Checksummen ===
			Um gültige IP-Pakete (z.B. Pings) generieren zu können benötigt man einen Checksummenalgorithmus - wir haben uns leider zu doof angestellt, diesen korrekt zu implementieren (vermutlich aufgrund von ''Endian''-Problemen). Daher können wir bisher keine beliebigen IP-Pakete erstellen, sondern nur bekannte Replizieren -> Problem bisher ungelöst, aber eigentlich leicht zu lösen

			=== Antwort/Forward ===
			Der AP hat auf unsere verschlüsselten Fragmentierten Pakete (Echo-Requests) nie geantwortet, sondern sie immer nur geforwarded. Für unsere Zwecke ist dies zwar ausreichend, aber es ist nicht befriedigend. Vermutlich liegt es daran, dass die Checksummen der IP-Pakete nicht stimmen (siehe oben) -> Problem ungelöst

			=== Unbekannter SNAP ===
			Aus uns völlig unbekannten Gründen hat der AP ständig WEP-verschlüsselte Pakete mit einem SNAP-Header von AA AA AA 03 00 00 00 '''00 27''' verschickt (auch ohne angemeldete Teilnehmer). Dies hat unsere Annahme mit dem bekannten SNAP-Header zunächst durcheinander gebracht, später dann aber deutlich vereinfacht. Wir konnten praktisch immer davon ausgehen, dass es sich um ein solches Paket handelt. Vermutlich handelt es sich um Managementframes. Es handelt sich jedenfalls nicht um eines, der bekannten Protokolle -> kein Problem

			=== viel ''noise'' ===
			An unserem Standpunkt gab es eine Vielzahl verschiedener drahtloser Netze (Uninetz, BRN, VPNs, etc..). Dadurch flogen ständig irgendwelche Pakete durch die Luft, die wir immer erst ausfiltern mussten. Ein Arbteisplatz ohne weitere Netze wäre wünschenswert gewesen -> geringes Problem

	= Code =		= Code =