Entwicklung eines Angriffssensors für Wireless LAN

Transkript

1 Diplomarbeit Entwicklung eines Angriffssensors für Wireless LAN bearbeitet von René Neumerkel geboren am 13. Oktober 1978 in Dresden Technische Universität Dresden Fakultät Informatik Institut für Systemarchitektur Professur Rechnernetze Betreuer: Hochschullehrer: Dipl.-Inform. Stephan Groß Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Eingereicht am 28. Oktober 2005

2 Platzhalter für Aufgabenstellung

3 Inhaltsverzeichnis 1 Einleitung 7 2 Grundlagen Bedrohungen im Zusammenhang mit Wireless LAN Anschluss nicht autorisierter Hardware Unsichere Konfiguration von WLAN-Komponenten Angrenzende Funk-Netze Angriffe auf drahtlose Netzwerke Network Discovery, Wardriving Eavesdropping, Sniffing Angriffe gegen WEP und Co Masquerading, Impersonation, Spoofing Denial-of-Service-Attacks Man-In-The-Middle-Attacks Herkömmliche Angriffe Intrusion Detection Systeme Klassifikation von Intrusion Detection Systemen Komponenten eines IDS Intrusion Detection Systeme für Wireless LAN Besonderheiten bei der Überwachung von Wireless LAN Anforderungen an Wireless IDS Existierende Systeme (Stand der Technik) Analyse Architektur von Bro Basiskonzepte von Bro Ereignis-Generierung Ereignis-Verarbeitung Policy-Interpretation Policy-Definition Notwendige Erweiterungen der Bro-Architektur Implementierung Erweiterung der Ereignis-Generierung Anpassung der Klasse PktSrc Hinzufügen der Klasse WLANSessions Erweiterungen der Ereignis-Verarbeitung

4 4.2.1 Definition neuer Ereignisse für Hinzufügen der neuen Ereignisse zu Bro Erweiterungen der Policy-Interpretation Anpassung der C++-Klassen Anpassung des Parsers Erweiterungen auf Policy-Ebene Evaluierung Definition einer Policy Beispiel 1: Erkennen von Rogue Access Points Beispiel 2: Erkennen von DoS-Angriffen Beispiel 3: Erkennen von Man-In-The-Middle Vorbereitungen Versuchsaufbau Installation der benötigten Treiber Installation von Bro Durchführung Versuch 1: Rogue Access Point Versuch 2: DoS-Angriff Versuch 3: Man-In-The-Middle Ergebnis der Versuche Zusammenfassung 72 A Bedrohungen in drahtlosen Netzwerken 73 B Angriffswerkzeuge 74 4

5 Abbildungsverzeichnis 3.1 Architektur von Bro [10] Funktionsweise von Bro Verwendung von libpcap Informationsfluss bei der Ereignis-Generierung Informationsfluss bei der Ereignisverarbeitung Interpretation der Policy-Skripte Geänderter Informationsfluss bei der Ereignis-Generierung Hinzufügen neuer Ereignisse zu Bro Windows-Rechner verbindet sich mit Rogue AP Ergebnis einer Umleitung von DNS-Anfragen Eine MITM-Attacke aus Sicht der betroffenen Station Erkennung des nicht autorisierten Access Points Erkennung des DoS-Angriffs Erkennung des Man-In-The-Middle-Angriffs A.1 Übersicht über die in drahtlosen Netzwerken bekannten Angriffe

6 Tabellenverzeichnis 2.1 Einordnung der Angriffe auf drahtlose Netzwerke Klassifikation von Intrusion Detection Systemen Versuchsanordnung B.1 Angriffswerkzeuge, Teil B.2 Angriffswerkzeuge, Teil

7 1 Einleitung Aufgrund ihrer zunehmenden Verbreitung sind drahtlose lokale Netze immer öfter Gegenstand gezielter Angriffe mit der Absicht, persönliche Daten auszuspähen oder Dienste zu erschleichen. Die in den letzten Jahren entwickelten Sicherheitstechniken für Wireless LAN tragen zwar zu einer deutlichen Verbesserung der Situation bei, jedoch ist darüber hinaus eine permanente Überwachung der getroffenen Sicherheitsvorkehrungen mittels so genannter Intrusion Detection Systeme sinnvoll. Ziel dieser Arbeit ist es daher, ein bestehendes IDS aus dem Festnetzbereich um die notwendige Funktionalität zu ergänzen, damit es als Wireless IDS eingesetzt werden kann. Voraussetzung hierfür ist jedoch, dass zunächst die konkreten Anforderungen an ein solches System bekannt sind. In Kapitel 2 werden daher zunächst die in einem drahtlosen Netzwerk existierenden Bedrohungen klassifiziert, bevor anschließend kurz auf Intrusion Detection Systeme im Allgemeinen sowie Wireless IDS im Besonderen eingegangen wird. Im Anschluss daran widmet sich Kapitel 3 der Analyse von Bro. Dabei werden die Architektur sowie die wichtigsten Basiskonzepte untersucht, um Ansatzpunkte für die notwendigen Änderungen zu identifizieren. Die Implementierung der erforderlichen Anpassungen wird in Kapitel 4 ausführlich beschrieben. Den Abschluss der Arbeit bildet mit Kapitel 5 ein praktischer Versuch. Dabei wird anhand konkreter Angriffe untersucht, ob die durchgeführten Änderungen tatsächlich dazu geeignet sind, Bedrohungen in drahtlosen Netzwerken zu erkennen. 7

8 2 Grundlagen Dieses Kapitel beleuchtet die Hintergründe, welche für das Verständnis der Arbeit notwendig sind. Dabei wird insbesondere auf die Bedrohungen im Zusammenhang mit Wireless LAN eingegangen. Außerdem werden Möglichkeiten zur automatischen Erkennung dieser Bedrohungen angesprochen. Nach einer kurzen Einführung in das Thema Intrusion Detection Systeme werden die besonderen Anforderungen an so genannte Wireless IDS untersucht. Am Ende des Kapitels wird kurz der aktuelle Stand der Technik wiedergegeben. Auf den Standard IEEE sowie die in der Vergangenheit bereits ausführlich diskutierten Sicherheitsprobleme von wird in diesem Kapitel nicht näher eingegangen. Stattdessen wird eine gewisse Vorbildung des Lesers vorausgesetzt und darüber hinaus auf die zahlreich vorhandene Literatur verwiesen [22, 13, 7, 17, 8]. 2.1 Bedrohungen im Zusammenhang mit Wireless LAN Neben den in der Literatur oft beschriebenen Angriffen auf drahtlose Netzwerke gibt es darüber hinaus weitere Bedrohungen, über die seltener gesprochen wird. Dazu gehören u.a. der Anschluss nicht autorisierter WLAN-Hardware an ein bestehendes Netzwerk, die fehlerhafte Konfiguration von WLAN-Komponenten sowie angrenzende drahtlose Netzwerke. Bedrohungen dieser Art sind nicht weniger ernst zu nehmen als die im darauffolgenden Abschnitt diskutierten Angriffe Anschluss nicht autorisierter Hardware Ein nicht zu unterschätzendes Risiko stellt der Anschluss eines nicht autorisierten Access Points an ein bestehendes Netzwerk dar. Dabei ist es zunächst unerheblich, ob die Installation durch einen Angreifer oder durch einen Mitarbeiter erfolgt. Zwar sind deren Absichten in der Regel sehr unterschiedlich, das Ergebnis bleibt jedoch in beiden Fällen gleich: Indem sich der Access Point der Kontrolle der zuständigen IT-Verantwortlichen entzieht, führt er somit schlimmstenfalls sämtliche getroffenen Sicherheitsvorkehrungen ad absurdum [2, 15, 27, 39]. 8

9 In der Literatur wird in diesem Zusammenhang oft der Begriff Rogue Access Point verwendet. Seit der Einführung von entwickeln Hersteller immer ausgefeiltere Lösungen, um Bedrohungen dieser Art automatisch erkennen zu können [3, 5, 27] Unsichere Konfiguration von WLAN-Komponenten Ebenso schwerwiegend wie der Einsatz nicht autorisierter Hardware, ist eine falsche Konfiguration der eingesetzten Geräte. So sind zum Beispiel viele Endgeräte standardmäßig so konfiguriert, dass sie sich automatisch mit drahtlosen Netzwerken in ihrer Reichweite verbinden, ohne dass der Benutzer notwendigerweise etwas davon bemerkt. Was für den Benutzer zunächst komfortabel erscheinen mag, kann sich schnell als ein Sicherheitsrisiko etablieren. So kann es vorkommen, dass sich ein Benutzer ohne es zu bemerken mit einem nicht autorisierten, fremden Access Point verbindet. Dabei kann es sich sowohl um den Access Point eines benachbarten Wireless LAN als auch um den eines Angreifers handeln. In beiden Fällen hätten der Angreifer bzw. die Benutzer des fremden WLAN möglicherweise Zugriff auf Freigaben und Dienste des betroffenen Endgerätes [2, 27]. Ein noch größeres Risiko besteht dann, wenn zum Beispiel ein Benutzer sein mit WLAN ausgestattetes Notebook an ein vorhandenes Kabelnetzwerk anschließt. Unter bestimmten Voraussetzungen verhält sich das Notebook wie eine Brücke zwischen beiden Netzwerken. Somit wäre es Angreifern und Benutzern des fremden WLANs gleichermaßen möglich, unter Umgehung sämtlicher möglicherweise mit enormen Aufwand installierten Sicherheitsvorkehrungen, Zugriff auf das Kabelnetzwerk zu erhalten [2, 27]. Dieses Szenario ist mit dem Anschluss eines nicht autorisierten Access Points durchaus vergleichbar und nicht weniger bedrohlich. Bisher wurde nur von der Möglichkeit gesprochen, dass sich ein Endgerät mit einem fremden Access Point verbindet. Darüber hinaus gilt das oben gesagte natürlich auch für den Fall, dass sich eine Station per ad-hoc-netzwerk mit einer anderen Station verbindet. In diesem Fall kommt jedoch hinzu, dass der Verbindungsaufbau auch durch die fremde Station initiiert werden kann. Neben falsch konfigurierten Endgeräten können auch manche Access Points ein Risiko darstellen. So kommt es vor, dass die in den APs eingebauten Sicherheitsmechanismen nicht oder nur teilweise aktiviert werden. Auch besitzen einige Access Points die Eigenart, dass sie Nachrichten aus dem Kabelnetzwerk ungefiltert ins WLAN weiterleiten. Auf diese Art und Weise könnten sensible Informationen den geschützten Bereich des Netzwerkes verlassen und von einem potentiellen Angreifer aufgefangen werden. 9

10 2.1.3 Angrenzende Funk-Netze Das Vorhandensein von drahtlosen Netzwerken in der Nachbarschaft kann unter Umständen ebenfalls ein Sicherheitsrisiko darstellen. Insbesondere in Kombination mit falsch konfigurierten Endgeräten besteht hier die Gefahr, dass eine Verbindung mit dem fremden Netzwerk zu Stande kommt, ohne dass der Benutzer dies bemerkt. Dabei sind insbesondere folgende Fälle zu unterscheiden: Ungewollte Verbindung mit dem WLAN eines benachbarten Unternehmens Ungewollte Verbindung mit dem WLAN eines Angreifers Ungewollte ad-hoc-verbindung mit einem unbekannten WLAN Nachdem die Risiken durch nicht autorisierte bzw. falsch konfigurierte Hardware bekannt sind, sollen als nächstes tatsächliche Angriffe auf drahtlose Netzwerke betrachtet werden. 2.2 Angriffe auf drahtlose Netzwerke Neben den im vorangegangenen Abschnitt beschriebenen allgemeinen Bedrohungen für drahtlose Netzwerke, sind es vor allem die möglichen Angriffe gegen Wireless LANs, über die in einschlägiger Literatur am häufigsten berichtet wird. Dieser Abschnitt stellt eine Übersicht über die zur Zeit bekannten Angriffe zusammen und nennt Möglichkeiten zu deren Erkennung. Doch bevor auf diese im Einzelnen eingegangen wird, sollen noch kurz die unterschiedlichen Gesichtspunkte, nach denen sie sich charakterisieren lassen, betrachtet werden. Ziel des Angriffs Ein Angreifer kann unterschiedliche Ziele verfolgen. Die Palette reicht von der einfachen Nutzung angebotener Dienste (z.b. Internetzugang) über den Zugriff auf vertrauliche Informationen bis hin zur Störung des reibungslosen Betriebes. Gegenstand des Angriffs Angriffe lassen sich zudem anhand der Schutzziele unterscheiden, gegen die sie gerichtet sind. Hierbei sind vor allem die Vertraulichkeit von Informationen, die Integrität von Daten und Kommunikationspartnern, sowie die Verfügbarkeit von Diensten und Infrastruktur zu nennen. Netzwerkschicht Angriffe können auf mehreren Schichten des OSI-Referenzmodells stattfinden. Während die Angriffe in herkömmlichen Kabelnetzen hauptsächlich auf den Schichten 3 (Vermittlungsschicht) und höher erfolgen, finden die hier 10

11 betrachteten Angriffe vorrangig auf den Schichten 1 (Bitübertragungsschicht) und 2 (Sicherungsschicht) statt. Aktive und passive Angriffe Je nachdem, ob während eines Angriffs Nachrichten durch den Angreifer in das Netzwerk gelangen oder nicht, wird zwischen aktiven und passiven Angriffen unterschieden. Passive Angriffe haben die Eigenschaft, dass sie sich nicht unmittelbar erkennen lassen, da sie sich durch keinerlei Netzwerkaktivitäten verraten. In den folgenden Abschnitten sollen nun die einzelnen Angriffe näher betrachtet werden. Zur besseren Übersicht sind sie in Tabelle 2.1 noch einmal zusammengefasst dargestellt. Angriffsvorbereitung Angriffe gegen die Vertraulichkeit Angriffe gegen die Integrität Angriffe gegen die Verfügbarkeit Kombination von Angriffen Network Discovery / Wardriving Eavesdropping / Sniffing Angriffe gegen WEP und Co. Masquerading / Impersonation / Spoofing Denial-of-Service-Attacks Man-In-The-Middle-Attacks Tabelle 2.1: Einordnung der Angriffe auf drahtlose Netzwerke Hinweis: Eine Übersicht der zusammen mit den einzelnen Angriffen vorgestellten Werkzeuge findet sich im Anhang. Darüber hinaus sei auch auf [43] und [4] verwiesen Network Discovery, Wardriving Als Network Discovery wird der Vorgang bezeichnet, bei dem eine Station nach drahtlosen Netzwerken innerhalb ihrer Reichweite sucht. Dabei handelt es sich genau genommen nicht um einen Angriff, sondern vielmehr um einen normalen Bestandteil des IEEE Standards. Potentielle Angreifer verwenden diese Methode allerdings auch, um Informationen über geeignete Angriffsziele an einem bestimmten Standort zu sammeln. Daher ist dieser Schritt stets auch in Verbindung mit den übrigen Angriffen zu sehen. 11

12 Bei der Suche nach drahtlosen Netzwerken wird grundsätzlich zwischen dem so genannten Active Probing und Passiv Probing unterschieden [11, 4, 18]. Active Probing Bei dieser Methode versendet eine WLAN-Station spezielle Management-Frames, so genannte Probe Requests, nacheinander auf allen Kanälen. Ein Access Point in Reichweite der Station antwortet, sofern er nicht explizit anders konfiguriert wurde, ebenfalls mit einer speziellen Management-Nachricht, einer so genannten Probe Response, in der neben des Netzwerknamens (SSID) und der MAC-Adresse des APs auch die von ihm unterstützten Protokoll-Merkmale übermittelt werden. Durch sequentielles Abfragen aller Kanäle erhält die Station Informationen über die in Reichweite befindlichen Access Points. Passive Probing Neben dem Versenden von Probe Requests durch die Stationen sieht der Standard zudem das Versenden so genannter Beacons durch die Access Points vor. Dabei handelt es sich um kurze Nachrichten, die regelmäßig und in kurzen Abständen an alle Stationen im Netzwerk gesendet werden, wobei der Inhalt im Wesentlichen dem einer Probe Response entspricht. Eine Station muss also nur nacheinander alle Kanäle nach diesen Nachrichten abhören, um Informationen über die Access Points in ihrer Nähe zu sammeln. Eine Station kann sich beider Methoden bedienen, um nach geeigneten Access Points in ihrer Reichweite zu suchen. Darüber hinaus existieren spezielle Tools, welche sich auf das Aufspüren drahtloser Netzwerke spezialisiert haben. Am bekanntesten ist sicher Netstumbler, ein aktives Netzwerkerkennungs-Tool für Windows. Darüber hinaus existiert aber auch eine Reihe von Werkzeugen, welche die passive Methode implementieren. Zu dieser Gruppe gehört zum Beispiel das Programm Kismet. Einen Spezialfall drahtloser Netzwerkerkennung stellt das so genannte Wardriving dar. Hierbei befindet sich ein Angreifer nicht stationär an einem Ort, sondern bewegt sich, ausgerüstet mit einem mobilen WLAN-Client und einer entsprechenden Netzwerkerkennungs-Software, innerhalb eines Gebietes, um nach drahtlosen Netzwerken zu suchen [12, 39]. Einige Tools lassen sich mittlerweile sogar mit einem GPS-Empfänger koppeln, so dass beim Aufspüren drahtloser Netzwerke deren genaue Position automatisch ermittelt und gespeichert werden kann. Die so gewonnenen Informationen stehen Interessierten anschließend über öffentliche Datenbanken im Internet zur Verfügung. In dem Versuch, das Aufspüren drahtloser Netzwerke durch Wardriving-Software zu verhindern, haben einige Hersteller ihre Access Points mit der Möglichkeit ausgestattet, bei Bedarf das Senden von Beacon-Frames zu deaktivieren. In diesem, auch als Closed Network bezeichneten Modus, reagiert ein Access Point ausschließlich auf Verbindungsanfragen mit korrekt gesetzter SSID. Damit soll erreicht werden, dass sich nur Benutzer mit Kenntnis des korrekten Netzwerknamens mit dem Access Point verbinden. 12

13 Allerdings handelt es sich hierbei nur um Sicherheit auf den ersten Blick, da bei jedem Verbindungsaufbau durch eine autorisierte Station die SSID in Klartext übermittelt wird. Ein Angreifer muss also nur warten, bis sich ein Benutzer mit dem Netzwerk verbindet, um an den korrekten Netzwerknamen zu gelangen. Darüber hinaus kann er den Vorgang beschleunigen, indem er mittels gefälschter Deauthenticate-Nachrichten andere Stationen dazu zwingt, sich erneut mit dem AP zu verbinden [12, 39]. Eine entsprechende Implementierung wird durch das Tool essid_jack realisiert. Möglichkeiten zur Erkennung von Wardriving Es existieren mehrere Ansätze, um den Einsatz aktiver Wardriving-Software zu erkennen. So lassen sich zum Beispiel die Tools Netstumbler und DStumbler anhand spezieller Zeichenketten identifizieren, die sie als Teil der Probe Requests versenden [18, 4, 5, 3]. Des Weiteren können Tools wie zum Beispiel Wellenreiter dadurch erkannt werden, dass sie bei dem Versuch, die SSID eines Netzwerkes zu erraten, wiederholt Probe Requests mit unbekannten Netzwerknamen versenden [19, 18, 4]. Auch verwenden einige Tools gern zufällig generierte Absender-Adressen in den Probe Requests, um ihre Präsenz zu verschleiern. Dabei kommt es oft vor, dass auch ungültige MAC-Adressen generiert werden [19, 4]. Dem gegenüber ist eine direkte Erkennung passiver Wardriving-Software per Definition nicht möglich, da bei diesem Vorgang keine Nachrichten versendet werden Eavesdropping, Sniffing Wurde das Ziel erst einmal gefunden, so wird der Angreifer mit hoher Wahrscheinlichkeit zunächst versuchen, an weitere Informationen zu gelangen. Bei dem als Sniffing oder Eavesdropping bezeichneten Angriff geht es darum, die über ein drahtloses Netzwerk gesendeten Nachrichten aufzuzeichnen. Damit lassen sich unter Umständen neue Erkenntnisse für das weitere Vorgehen sammeln. Schlimmstenfalls gelangt ein Angreifer so möglicherweise auch an vertrauliche Informationen, wie zum Beispiel Kennwörter von -Accounts. Darüber hinaus erlaubt die Aufzeichnung des Netzwerk-Verkehrs eine spätere Analyse bzw. einen Offline-Angriff auf die Verschlüsselung (Abschnitt 2.2.3). Voraussetzung für diesen Angriff ist, dass die verwendete WLAN-Hardware einen speziellen Modus (Monitor Mode) unterstützt, bei dem sie sämtliche auf einem Kanal gesendeten Nachrichten empfängt und sie unverändert an das Betriebssystem weiter- 13

14 leitet. Obwohl längst nicht alle WLAN-Karten diesen Modus unterstützen, so gibt es jedoch einige Chipsätze und Treiber, die das ermöglichen [51]. Beim Sniffing ist zwischen folgenden Fällen zu unterscheiden: Unverschlüsseltes Wireless LAN Handelt es sich bei dem Angriffsziel um ein unverschlüsseltes WLAN, so entspricht dies dem Sniffing, wie man es von herkömmlichen ungeswitchten Kabelnetzen kennt [15, 11, 17, 5]. Mit Hilfe so genannter Protocol Analyzer wie zum Beispiel tcpdump oder Ethereal lässt sich der Netzwerkverkehr komfortabel und in Echtzeit mitlesen sowie für spätere Analysen speichern. Verschlüsseltes Wireless LAN Bei Netzwerken, die durch das im Standard spezifizierte WEP-Protokoll 1 geschützt sind, wird die Informationsgewinnung zwar erschwert, jedoch nicht verhindert. Eine Möglichkeit ist beispielsweise die statistische Analyse des Netzwerkverkehrs, auch als Traffic Analysis bekannt [17, 24]. Dabei lassen sich aus Länge und zeitlichem Auftreten bestimmter Nachrichten Rückschlüsse auf deren Inhalt ziehen. Darüber hinaus existiert heute eine Reihe unterschiedlicher Verfahren und Tools, mit denen der in einem drahtlosen Netzwerk verwendete WEP-Schlüssel in relativ kurzer Zeit ermittelt werden kann. Diese werden im nächsten Abschnitt genauer besprochen. Auch bei drahtlosen Netzwerken, die durch die neuen Standards WPA sowie i geschützt sind, besteht unter gewissen Voraussetzungen die Möglichkeit, den Datenverkehr zu entschlüsseln. Auch hier sei auf den nächsten Abschnitt verwiesen, der sich ausschließlich mit Angriffen gegen die Verschlüsselung drahtloser Netzwerke beschäftigt. Möglichkeiten zur Erkennung von Sniffing Wie schon bei der passiven Netzwerkerkennung lässt sich dieser Angriff nicht direkt nachweisen, da hierbei in der Regel keine Nachrichten gesendet werden. Allerdings wird in [39] eine Möglichkeit beschrieben, wie auch solche Stationen entdeckt werden können, die keine Nachrichten versenden. Die Autoren verweisen darauf, dass eine Station auf ein empfangenes Request-To-Send laut Standard in der Regel mit einem Clear-To-Send reagiert, selbst dann, wenn sie sich im passiven Modus befindet. 1 WEP steht für Wired Equivalent Privacy und bezeichnet die im ursprünglichen Standard definierte Sicherheitslösung für drahtlose Netzwerke nach

15 2.2.3 Angriffe gegen WEP und Co. Bereits 2001 wurden erstmals Schwachstellen in WEP bekannt [35], ein Jahr darauf wurde der erste Angriff auf WEP erfolgreich durchgeführt [1]. Seit dem wurden die bestehenden Algorithmen immer weiter verbessert bzw. sind neue hinzugekommen. Heute verfügen Angreifer über ein ganzes Arsenal an so genannten Cracking Tools, von denen einige schon in relativ kurzer Zeit den WEP-Schlüssel ermitteln. Voraussetzung hierfür ist, dass ein Angreifer über genügend Pakete verfügt, die mit dem gleichen WEP-Schlüssel kodiert wurden. Dazu bedient er sich des im letzten Abschnitt beschriebenen Sniffings. Je nach Angriff reichen hier schon einige hunderttausend Pakete, um den Schlüssel mit hoher Wahrscheinlichkeit zu ermitteln. In einem gut ausgelasteten WLAN muss ein Angreifer nicht allzu lange warten, bis er die notwendige Anzahl Pakete gesammelt hat. Anschließend kann er eins der zahlreichen Tools verwenden, um den Schlüssel binnen kurzer Zeit zu knacken. Die Möglichkeiten reichen von einer einfachen Wörterbuch-Attacke bis hin zu statistischen Verfahren [23, 4, 39, 17]. Prominentestes Beispiel für letztgenannte Klasse ist der unter der Bezeichnung Korek-Attacke bekannt gewordene Angriff [21]. Obwohl WEP damals schon als vollständig kompromittiert angesehen werden konnte, glaubten sich dennoch viele Anwender dadurch auf der sicheren Seite, dass es in einem weniger ausgelasteten WLAN relativ lange dauern würde, um genügend Pakete zu sammeln. Seit spätestens diesen Jahres gilt diese Annahme allerdings nicht mehr. So existiert mittlerweile ein Angriff, der über eine so genannte Replay-Attacke binnen kürzester Zeit ausreichend verschlüsselte Pakete generiert, so dass auch in weniger ausgelasteten WLANs der verwendete WEP-Schlüssel innerhalb von Minuten ermittelt werden kann [24, 4]. Dieser Angriff wurde bereits von der Software aireplay implementiert. Aber auch ohne Kenntnis des verwendeten Schlüssels bieten sich einem Angreifer interessante Möglichkeiten. So ist es ihm unter bestimmten Voraussetzungen möglich, verschlüsselte Pakete zu versenden, ohne selbst den Schlüssel zu kennen [17, 24, 4]. Mit WEPWedgie existiert bereits ein entsprechendes Tool. Hiermit sollen angeblich sogar ganze Port-Scans möglich sein [24]. Der Vollständigkeit halber sei an dieser Stelle noch das Programm chopchop erwähnt, das mit Hilfe eines Access Points versucht, WLAN-Pakete einzeln zu entschlüsseln [24, 11]. Nicht zuletzt wurde 2003 durch Robert Moskowitz erstmals ein Angriff auf den bei WPA-PSK verwendeten Schlüssel vorgestellt [34]. Dabei handelt es sich im Prinzip um eine Wörterbuch-Attacke auf ein einzelnes verschlüsseltes Paket. Der Angriff wurde inzwischen durch Joshua Wright in Form des Tools cowpatty implementiert. 15

16 Möglichkeiten zur Erkennung von Angriffen gegen WEP und Co. Auch hier beschränkt sich eine mögliche Erkennung auf solche Angriffe, bei denen der Angreifer selbst Pakete verschickt. So lässt sich beispielsweise eine Replay-Attacke recht einfach dadurch erkennen, dass ein und diesselbe Nachricht wieder und wieder versandt wird. Darüber hinaus lässt sich der Einsatz von WEPWedgie dadurch nachweisen, dass alle gesendeten Pakete mit ein und demselben IV 2 verschlüsselt wurden Masquerading, Impersonation, Spoofing Unter Masquerading, manchmal auch als Impersonation oder Spoofing bezeichnet, versteht man das Vortäuschen einer fremden Identität. Diese Technik wird immer dann eingesetzt, wenn es darum geht die eigene Identität während eines Angriffs zu verschleiern oder aber die eines rechtmäßigen Benutzers anzunehmen, um auf diese Weise eventuell vorhandene Zugriffskontrollen zu umgehen. Grundsätzlich lassen sich vier Fälle von Masquerading beobachten: a) Ein Angreifer gibt sich als autorisierter Benutzer aus Ein Angreifer nimmt die Identität eines rechtmäßigen Benutzers an, um damit zum Beispiel vorhandene Zugriffskontrollen zu umgehen [19, 4, 3, 15, 11]. Dazu ändert er ganz einfach die MAC-Adresse seiner WLAN-Karte entsprechend der Station eines autorisierten Benutzers. Auf diese Weise lassen sich zum Beispiel die in vielen Access Points integrierten MAC-Filter sehr leicht umgehen. Aber auch in anderen Szenarien, wo die MAC-Adresse eines Clients als Zugangscode dient, ist dieser Angriff erfolgreich. Darüber hinaus lassen sich auf diese Weise auch bestehende Kommunikationssitzungen autorisierter Benutzer übernehmen. Dieser Angriff wird auch als Session Hijacking bezeichnet. Nicht zuletzt findet diese Methode auch bei dem in vorgestellten Man-In-The-Middle-Angriff Anwendung. b) Ein Angreifer gibt sich als autorisierter Access Point aus Interessant ist für einen Angreifer auch die Möglichkeit, sich als autorisierter Access Point auszugeben, um damit die Endgeräte rechtmäßiger Benutzer so zu täuschen, dass sie sich statt mit dem echten AP mit dem des Angreifers verbinden [27, 4, 11, 3, 5]. Alles was er dazu benötigt, ist ein Notebook mit einer handelsüblichen WLAN-Karte, Linux sowie geeignete Treiber. Damit ist er in der Lage, seine WLAN-Karte mit der 2 IV steht für Initialisierungsvektor, der zusätzlich zum WEP-Schlüssel benötigt wird und mit jeder Nachricht als Klartext gesendet wird 16

17 SSID und der MAC-Adresse des gewünschten Access Points zu konfigurieren, um sie anschließend auf einem anderen Kanal als ursprünglich zu platzieren. Clients, welche sich mit dem echten Access Point verbinden wollen, starten eine entsprechende Suche und erhalten als Ergebnis zwei Access Points mit der gleichen SSID auf unterschiedlichen Kanälen. In der Regel werden sie sich für den entscheiden, dessen Signal am stärksten ist. Hat sich ein Client erst einmal mit dem AP des Angreifers verbunden, so befindet sich dieser in einer idealen Ausgangssituation für einen klassischen Man-In- The-Middle-Angriff, wie er in Abschnitt beschrieben wird. Noch einen Schritt weiter geht das Tool airsnarf. Es simuliert neben dem echten Access Point zudem ein dahinter liegendes Intranet mit DHCP- und WWW-Server, um ahnungslose Benutzer dazu zu bringen, über ihren Browser vertrauliche Daten wie zum Beispiel Kennwörter preiszugeben [4]. Besonders interessant ist dieser Angriff in öffentlichen Hotspots. Diese authentifizieren ihre Benutzer gern über ein HTML- Formular. Ein Angreifer muss seinen Opfern somit nur eine Kopie dieser Seite anzeigen, um an ihre Benutzerkennungen zu gelangen. Dazu kann er sogar eine SSL- Verbindung zu den Clients aufbauen, um seine Opfer in falscher Sicherheit zu wiegen. Ein Angreifer ist keinesfalls gezwungen abzuwarten, dass sich fremde Clients mit seinem AP verbinden. Durch das Versenden gefälschter Deauthenticate-Nachrichten an die Stationen in seiner Reichweite kann er diese dazu bringen, ihre bestehende Verbindung mit einem AP zu beenden und sich stattdessen mit ihm zu verbinden [4][25]. Mit essid_jack steht dem Angreifer bereits ein passendes Tool zur Verfügung. c) Ein Angreifer simuliert mehrere Stationen Ein Angreifer kann aber auch mehrere Clients imitieren, indem er die MAC-Adresse seiner WLAN-Karte häufig ändert und dabei beliebige Werte zulässt. Diese Technik benutzt zum Beispiel die Software Wellenreiter, wenn sie versucht, mittels Brute Force den Netzwerknamen eines Access Points zu ermitteln [19]. Ein anderes Tool namens void11 verschickt massenhaft Association Requests an einen bestimmten Access Point und simuliert dabei hunderte WLAN-Stationen, die sich mit dem AP verbinden wollen [15, 31, 4, 3, 5]. Hierbei handelt es sich um ein Beispiel für eine so genannte DoS-Attacke (Denial-of-Service) welche Gegenstand des folgenden Abschnitts ist. d) Ein Angreifer simuliert mehrere Access Points Ebenfalls als DoS-Angriff geeignet ist das massenhafte Versenden gefälschter Beacon-Frames, bei denen der Netzwerkname sowie die MAC-Adresse zufällig generiert werden. Clients, die versuchen, sich mit den nicht existierenden Access Points zu verbinden, sind natürlich nicht erfolgreich und versuchen es mit dem nächsten vermeintlichen Access Point. Auf diese Weise wird es Clients erschwert, sich mit einem legitimen AP zu verbinden. 17

18 Möglichkeiten zur Erkennung von Masquerading Der Nachweis von Masquerading gehört sicherlich zu den schwierigsten Aufgaben bei der Erkennung von Angriffen. Joshua Wright beschreibt einen Ansatz, der anhand der in den Frames enthaltenen Sequenznummern versucht, Nachrichten mit gefälschtem Absender zu erkennen [19]. Dieser Ansatz basiert auf der Tatsache, dass eine Station, egal ob Endgerät oder Access Point, jede gesendete Nachricht mit einer für sie spezifischen Sequenznummer versieht, deren Wert in der Regel für jede neue Nachricht um eins erhöht wird. Ausgehend von der Annahme, dass die Sequenznummer nicht oder nur mit erheblichem Aufwand durch einen Angreifer manipuliert werden kann (siehe auch [16]), lassen sich im weiteren Verlauf geeignete Strategien entwickeln, die das Vorhandensein von Nachrichten mit gefälschter Absender-Adresse nachweisen können [19]. Nicht immer ist jedoch eine aufwändige Analyse der Sequenznummern notwendig. Um sich beispielsweise als legitimer Access Point auszugeben, kann ein Angreifer auch nur den Netzwerknamen des echten AP übernehmen. Diese als ESSID-Spoofing bekannte Form von Masquerading lässt sich meist schon dadurch erkennen, dass die verwendete MAC-Adresse oder der Kanal nicht mit den Einstellungen des echten AP übereinstimmen Denial-of-Service-Attacks Unter der Bezeichnung Denial-of-Service-Attacks oder kurz DoS-Attacks werden Angriffe gegen die Verfügbarkeit drahtloser Netzwerke zusammengefasst. Ziel dieser Klasse von Angriffen ist es, autorisierte Benutzer am Zugriff auf das drahtlose Netzwerk zu hindern. Hierfür existieren unterschiedliche Techniken. Dieser Abschnitt konzentriert sich vor allem auf Angriffe gegen die MAC-Schicht von Die wohl häufigste Form von DoS-Angriffen gegen sind so genannte flooding- Attacken, bei denen in sehr kurzen Abständen wiederholt gefälschte Management- Nachrichten versandt werden. Dabei wird intensiv von den bereits beschriebenen Möglichkeiten des Masquerading Gebrauch gemacht, um den Absender der Nachrichten je nach Situation entsprechend anzupassen. Prinzipiell können alle Typen von Management-Frames für flooding-angriffe benutzt werden. Allerdings bestimmt in der Praxis die Auswahl an verfügbaren Tools, welche Frames verwendet werden. Deauthentication Flooding Die Software wlan_jack versendet zum Beispiel gefälschte Deauthenticate-Frames, um Clients daran zu hindern, sich mit einem Access Point zu verbinden [15, 31, 4, 16, 3, 5, 25, 17]. Dazu ändert das Tool die Absender-Adresse der Nachrichten entsprechend der Adresse des verantwortli- 18

19 chen AP. Für einen Client sieht es so aus, als ob der AP die Verbindung getrennt hat. Der Client ist gezwungen, sich erneut mit dem Access Point zu verbinden. Dazu kommt es jedoch nicht, da ständig neue Deauthenticate-Frames eintreffen. Das Ergebnis ist, dass der betroffene Client am Zugang zum drahtlosen Netzwerk gehindert wird. Neben Deauthenticate-Frames eignen sich aber prinzipiell auch Disassociate-Nachrichten. Authentication Flooding Eine andere Strategie verfolgt das Tool void11. An Stelle von Deauthenticate-Frames, versendet es Authentication-Anfragen an einen bestimmten Access Point und verwendet dabei für jede Nachricht eine andere, zufällig gewählte Absender-Adresse [15, 31, 4, 3, 5]. Für den betroffenen Access Point sieht es so aus, als ob hunderte Stationen gleichzeitig versuchen würden, sich mit ihm zu verbinden. Laut Standard muss der Access Point auf jede Verbindungsanfrage antworten. Zudem muss er sich merken, welche Clients gerade eine Verbindung mit ihm aufbauen. Aufgrund der Masse der Anfragen sind alsbald sämtliche Puffer als auch verfügbare Verarbeitungskapazitäten erschöpft und der Access Point ist nicht mehr in der Lage, auf die Anfragen legitimer Clients zu antworten. Dieser Angriff funktioniert auch in Verbindung mit Association Requests. Beacon Flooding Eine weitere Möglichkeit ist das Versenden von Beacon-Frames mit wechselnden SSIDs und Absender-Adressen [3, 5, 19]. Zum einen wird es legitimen Clients hierdurch erschwert, einen geeigneten AP zu finden. Zum anderen reduziert sich dadurch die verfügbare Übertragungskapazität für die anderen Stationen in dem drahtlosen Netzwerk. Zum Schluss sei noch ein Angriff genannt, welcher sich speziell gegen WPA richtet. Dabei sendet ein Angreifer wiederholt Nachrichten mit ungültigem Message Integrity Check (MIC) an einen Access Point. Laut Spezifikation muss dieser die Kommunikation für die Dauer einer Minute unterbrechen, sobald er eine Nachricht mit ungültigem MIC empfängt. Das permanente Eintreffen ungültiger Nachrichten führt im Endeffekt dazu, dass der betroffene AP seine Arbeit praktisch einstellt [17, 4]. Möglichkeiten zur Erkennung von DoS-Angriffen Die Möglichkeiten zur Erkennung von DoS-Angriffen werden in Abschnitt beschrieben. Am einfachsten lassen sich so genannte Flooding-Attacken erkennen, deren wichtigstes Kennzeichen das massenhafte Auftreten ähnlicher Nachrichten ist. Solche Angriffe lassen sich zum Beispiel dadurch aufdecken, dass die Häufigkeit bestimmter Nachrichten innerhalb eines begrenzten Zeitfensters ermittelt und anschließend mit einem Schwellwert verglichen wird. 19

20 2.2.6 Man-In-The-Middle-Attacks Eine Man-In-The-Middle-Attacke kombiniert mehrere der bisher vorgestellten Techniken, um einen Angreifer unbemerkt in die Kommunikation zweier Stationen einzuschleusen. Im Festnetzbereich wurde dieser Angriff vor allem im Zusammenhang mit ARP-Poisoning bekannt [6, 9]. Die hier vorgestellten Angriffe finden jedoch vorwiegend auf Schicht 2 des OSI-Modells statt [25, 4, 19, 39, 11]. Einige wurden bereits im Abschnitt kurz angesprochen. Sie sollen an dieser Stelle noch einmal in einem etwas anderen Kontext beschrieben werden. In dieser Arbeit wird insgesamt zwischen drei Varianten von Man-In-The-Middle- Angriffen unterschieden. Session Hijacking Bei diesem Angriff soll eine bestehende Verbindung zwischen einer Station und einem Access Point so manipuliert werden, dass im weiteren Verlauf die ursprüngliche Station durch die des Angreifers ersetzt wird. Hiermit wird der Angreifer in die Lage versetzt, eventuell bereits authentifizierte Kommunikationssitzungen des Opfers zu übernehmen [17, 4, 15]. Dazu initiiert der Angreifer zunächst eine DoS-Attacke gegen den anderen Client mit dem Ziel, dass dieser eine Zeit lang nicht senden kann. Eine Möglichkeit besteht zum Beispiel darin, dem Opfer eine speziell präparierte Nachricht zu senden, welche eine Lücke in dessen Betriebssystem ausnutzt und das betroffene System zum Absturz bringt. Nachdem der Client ausgeschaltet wurde, übernimmt der Angreifer die weitere Kommunikation mit dem AP und verwendet dazu die in vorgestellten Techniken des Masquerading. Connection Hijacking Bei diesem Angriff soll nicht der Client, sondern der Access Point durch den des Angreifers ersetzt werden [27, 4]. Auch hier kommt wieder eine Kombination aus DoS-Angriff und Masquerading zum Einsatz. Dazu führt der Angreifer wie im Abschnitt beschrieben eine Flooding-Attacke gegen den AP durch. Sobald dieser aufhört, auf Verbindungsanfragen zu reagieren, ersetzt der Angreifer ihn durch einen eigenen AP auf dem gleichen Kanal. Nun kann er beispielsweise den in vorgestellten Angriff durchführen, bei dem er ein nicht vorhandenes Intranet simuliert, um Benutzer zu verleiten, vertrauliche Informationen preiszugeben [27, 4]. 20

21 Echtes Man-in-the-Middle Wie bereits zu Beginn dieses Abschnitts erwähnt, geht es bei Man-In-The-Middle hauptsächlich darum, einen Angreifer unbemerkt in die Kommunikation zweier Gegenstellen einzuschleusen, um beispielsweise eine vorhandene Verschlüsselung auf Anwendungsebene zu umgehen [25, 4, 19, 39, 11]. Alles was ein Angreifer hierzu benötigt, ist ein Rechner mit zwei handelsüblichen WLAN-Karten. Eine der beiden Karten wird mit der SSID und MAC-Adresse eines autorisierten Access Points konfiguriert. Sobald sich ein Client mit dem Angreifer verbindet, konfiguriert dieser die zweite WLAN-Karte mit der MAC-Adresse des Clients und baut an dessen Stelle eine Verbindung zum echten AP auf. Anschließend ist der Angreifer in der Lage, Nachrichten zwischen Client und AP weiterzuleiten sowie nach Belieben zu manipulieren. Dieser Vorgang erfolgt sowohl für den betroffenen Client als auch für den AP transparent. Mittels gefälschter Deauthenticate-Nachrichten kann ein Angreifer zudem eine bereits bestehende Verbindung zwischen einer Station und einem Access Point angreifen. Eine Software, welche diesen Angriff durchführt, ist zum Beispiel monkey_jack [25]. Die hier vorgestellten Angriffe sowie mögliche Strategien zu ihrer Erkennung sind Gegenstand weiterführender Untersuchungen in Kapitel Herkömmliche Angriffe Neben den hier vorgestellten Angriffen speziell für Wireless LAN existieren darüber hinaus weitere bereits bekannte Techniken aus dem Festnetzbereich. Hat ein Angreifer erst einmal Zugang zum drahtlosen Netzwerk, so könnte er in einem zweiten Schritt die darin befindlichen Stationen sowie Ziele in einem eventuell vorhandenen LAN direkt angreifen. An dieser Stelle soll jedoch nicht weiter darauf eingegangen werden, da hier ausschließlich bereits bekannte Techniken zum Einsatz kommen. Zudem existieren bereits seit einiger Zeit geeignete Lösungen zur Erkennung solcher Angriffe. Nachdem nun die wesentlichen Angriffe gegen drahtlose Netzwerke bekannt sind, soll im weiteren Verlauf auf mögliche Systeme zur automatischen Erkennung dieser Angriffe eingegangen werden. Im Festnetzbereich werden solche Systeme bereits erfolgreich eingesetzt und auch für Wireless LAN gibt es erste Lösungen. 2.3 Intrusion Detection Systeme Unter der Bezeichnung Intrusion Detection Systeme, oder kurz IDS, werden Werkzeuge zusammengefasst, welche Angriffe auf ein System erkennen sollen. Dazu un- 21

22 tersuchen sie unter anderem mit Hilfe heuristischer Verfahren den Netzwerkverkehr nach bekannten Angriffsmustern, auch Signaturen genannt. Andere Ansätze versuchen hingegen, Abweichungen vom normalen Systemverhalten festzustellen, um so einen möglichen Angriff zu erkennen Klassifikation von Intrusion Detection Systemen Kriterium Arbeitsweise Klassen Signatur-basierte IDS Anomalien-erkennende IDS Grad der Verteilung Monolithische IDS Verteilte IDS Gegenstand der Überwachung Host-basierte IDS Netzwerk-basierte IDS Tabelle 2.2: Klassifikation von Intrusion Detection Systemen In der Literatur werden Intrusion Detection Systeme nach den unterschiedlichsten Kriterien klassifiziert [36, 32]. Diese Arbeit beschränkt sich hierbei auf die in Tabelle 2.2 dargestellte Einteilung. Danach lassen sich IDS zunächst einmal nach ihrer prinzipiellen Arbeitsweise klassifizieren: Signatur-basierte IDS untersuchen den Netzwerkverkehr bzw. das Systemverhalten nach bekannten Angriffsmustern, so genannten Signaturen. Diese können ganz unterschiedlich spezifiziert sein. Die Spannweite reicht von einfachen Zeichenketten bis hin zu komplexen Zustandsmodellen. Signatur-basierte IDS verfügen in der Regel über eine hohe Treffergenauigkeit, können allerdings nur solche Angriffe erkennen, für die sie in ihrer Datenbasis eine entsprechende Signatur besitzen. Anomalien-erkennende IDS versuchen hingegen Abweichungen vom normalen Systemverhalten zu erkennen. Hierzu erstellen sie selbstständig ein Modell, welches das normale Verhalten abbilden soll. Diese Systeme benutzen vor allem statistische Methoden, um auch bisher völlig unbekannte Angriffe zu erkennen. Allerdings leiden diese Systeme an einer relativ hohen Fehlerrate, was vor allem darauf zurückzuführen ist, dass sich das Verhalten komplexer Systeme sehr schwer modellieren lässt. Darüber hinaus lassen sich IDS auch anhand ihrer Granularität bzw. dem Grad ihrer Verteilung einordnen: 22

23 Monolithische IDS bestehen aus einem einzigen, zusammenhängenden, abgeschlossenen System, das die gesamte Funktionalität eines IDS in einer einzigen Anwendung vereint. Monolithische Systeme laufen auf einzelnen Netzwerk- Knoten und verarbeiten ausschließlich Daten, die an dieser Stelle des Netzwerkes auftreten. Verteilte IDS bestehen hingegen aus mehreren Komponenten, welche auf mehrere Knoten im Netzwerk verteilt sind. Diese Systeme verarbeiten somit Informationen, wie sie an verschiedenen Stellen im Netzwerk entstehen. Verteilte IDS haben gegenüber monolithischen Systemen den Vorteil, dass sie meist eine umfassendere Sicht auf die Vorgänge in einem Netzwerk haben. Mögliche Architekturen reichen von der einfachen Integration einzelner monolithischer IDS über die Verteilung einzelner IDS-Komponenten im Netzwerk bis hin zu Agenten-basierten Systemen. Nicht zuletzt unterscheiden sich Intrusion Detection Systeme auch darin, ob sie die Aktivitäten im Netzwerk oder auf den einzelnen Hosts überwachen: Host-basierte IDS überwachen die Abläufe innerhalb eines Rechners, wie zum Beispiel den Aufruf bestimmter Systemfunktionen. Dabei agieren sie im Hintergrund, während der Rechner seiner eigentlichen Aufgabe nachgeht. Netzwerk-basierte IDS überwachen hingegen den Netzwerkverkehr an einem oder mehreren Knoten. Meist handelt es sich dabei um dezidierte Systeme, deren einzige Aufgabe die Überwachung des Netzwerkes ist. Bei dem in dieser Arbeit betrachteten System namens Bro handelt es sich um ein Regelbasiertes IDS, einer speziellen Unterklasse der Signatur-basierten IDS. Darüber hinaus gehört Bro zu der Klasse der Netzwerk-basierten Intrusion Detection Systeme. In Bezug auf den Grad der Verteilung lässt es sich nicht ohne weiteres klassifizieren. So ist ein einzelnes Bro-System zwar monolithisch, allerdings können mehrere Bro- Instanzen Nachrichten über ein Netzwerk austauschen und damit eine Art verteiltes IDS realisieren [10] Komponenten eines IDS Ein Intrusion Detection System besteht im wesentlichen aus vier Komponenten. Aufgabe der Sensoren ist es, je nach Anwendungsgebiet den Netzwerkverkehr zu überwachen, spezielle Audit-Daten auszuwerten oder das aktuelle Systemverhalten zu beobachten. Daraus generieren sie IDS-spezifische Ereignisse, die anschließend von einem Monitor zusammengefasst und mit dem zugrunde liegenden Verhaltensmodell verglichen werden. 23

24 Es ist Aufgabe des Monitors, eine Folge von Ereignissen nach Hinweisen auf potentielle Angriffe zu untersuchen und entsprechende Nachrichten zu erzeugen. Diese werden von einem oder mehreren so genannten Resolvern verarbeitet, welche über das weitere Vorgehen entscheiden. Dazu gehören neben der Protokollierung der Daten auch die Benachrichtigung der Sicherheitsverantwortlichen sowie gegebenenfalls eine automatischen Rekonfiguration der eingesetzten Sicherheitsmechanismen. Die Überwachung und Wartung des gesamten Systems erfolgt mit Hilfe eines so genannten Controllers von einem zentralen Punkt aus. 2.4 Intrusion Detection Systeme für Wireless LAN Im Festnetzbereich werden Intrusion Detection Systeme bereits seit längerem eingesetzt. Allerdings unterscheiden sich die Angriffe in drahtlosen Netzwerken erheblich von den bisher bekannten Angriffen in Kabelnetzen. Daher lassen sich bestehende Systeme nicht ohne weiteres wiederverwenden. Stattdessen müssen die Systeme angepasst bzw. komplett neue Lösungen entwickelt werden, um die Besonderheiten von drahtlosen Netzwerken in ausreichendem Maße zu berücksichtigen Besonderheiten bei der Überwachung von Wireless LAN Voraussetzung für die Erkennung von Bedrohungen in drahtlosen Netzwerken ist die permanente und gleichzeitige Überwachung aller in Frage kommenden Kanäle. Damit ist bereits einer der Hauptunterschiede zur Überwachung in Kabelnetzen und zugleich eines der größten Probleme von Wireless IDS identifiziert. Um den Netzwerkverkehr eines LAN-Segmentes vollständig zu überwachen, genügt es, einen an das Segment angeschlossenen Host so zu konfigurieren, dass er alle vorbeikommenden Pakete empfängt. Im Falle von WLAN, sind aber je nach Anzahl der gesetzlich zugelassenen Kanäle bis zu 13 Segmente simultan zu überwachen. Herkömmliche WLAN-Karten können jedoch zu jeder Zeit nur einen Kanal überwachen. Einige Hersteller bieten daher spezielle Hardwarelösungen an, welche eine simultane Überwachung aller Kanäle ermöglichen sollen [3, 5]. Ein weiterer Unterschied zur Überwachung in Kabelnetzen besteht darin, dass die hier vorgestellten Angriffe vorwiegend auf den Schichten 1 und 2 des OSI-Modells stattfinden, während herkömmliche IDS in der Regel auf Schicht 3 und höher ansetzen. Zudem gehen diese Systeme von der Annahme aus, dass die unteren Schichten aufgrund der physikalischen Begrenzung von Kabelnetzen ausreichend geschützt sind [39]. Dies ist jedoch bei Wireless LAN nicht der Fall. Nicht zuletzt ist es auch eine Besonderheit von drahtlosen Netzwerken, dass sich die zu überwachende Infrastruktur aufgrund der Mobilität der einzelnen Stationen relativ 24

25 häufig ändert. Zudem sind die in einem WLAN verwendeten Endgeräte in der Regel vorab nicht bekannt. Ein Intrusion Detection System für Wireless LAN muss also in jedem Fall die hier betrachteten besonderen Eigenschaften drahtloser Netzwerke berücksichtigen Anforderungen an Wireless IDS Ausgehend von den spezifischen Eigenschaften drahtloser Netzwerke sowie den in 2.1 und 2.2 vorgestellten möglichen Bedrohungen lassen sich folgende Anforderungen an ein Wireless IDS formulieren: Überwachung auf Schicht 2 des OSI-Modells Um die in drahtlosen Netzwerken vorkommenden Angriffe erkennen zu können, muss ein Wireless IDS die Kommunikation auf der Ebene von überwachen. Dabei sind insbesondere alle für WLAN relevanten Frequenzen abzudecken. Erkennung nicht autorisierter Hardware Ein Wireless IDS muss in der Lage sein, für alle in Reichweite befindlichen WLAN-Stationen, egal ob Access Point oder mobiles Endgerät, zwischen autorisierten und nicht autorisierten Stationen zu unterscheiden. Erkennung von fehlerhaft konfigurierter Hardware Ein Wireless IDS sollte die Verantwortlichen außerdem auf mögliche Fehlkonfigurationen von Access Points und Client-Geräten hinweisen. Siehe Abschnitt Erkennung von Angriffen Die Hauptaufgabe eines Wireless IDS besteht natürlich darin, die in Abschnitt 2.2 diskutierten Angriffe zu erkennen. Erkennung von unerwünschten Verbindungen Hierzu gehören sowohl Verbindungen zwischen Clients und nicht autorisierten Access Points als auch unerwünschte ad-hoc-kommunikation. Echtzeit-Benachrichtigung Ein Wireless IDS muss zudem in der Lage sein, die zuständigen Verantwortlichen möglichst ohne Verzögerung über stattfindende Angriffe zu informieren. Aufzeichnung für weiterführende Analysen Für eine spätere Offline-Analyse und zur Sicherung von Beweisen sollte ein IDS alle erkannten Angriffe in geeigneter Weise protokollieren. Dies beinhaltet gegebenenfalls auch die Speicherung der während eines Angriffs empfangenen Nachrichten. 25

26 2.4.3 Existierende Systeme (Stand der Technik) Inzwischen hat sich bereits ein Markt für Wireless Intrusion Detection Systeme gebildet und zahlreiche Hersteller bieten entsprechende Produkte an. Die Palette reicht von vergleichsweise einfachen Lösungen zur Erkennung nicht autorisierter Access Points bis hin zu technisch ausgefeilten Systemen, die angeblich alle bekannten Angriffe abdecken sollen. Eine Übersicht über aktuelle Systeme und ihre Möglichkeiten wird in [15] gegeben. Die zur Zeit verfügbaren Systeme lassen sich anhand ihrer prinzipiellen Herangehensweise in zwei Gruppen einteilen. Die eine Gruppe setzt auf Lösungen, die zusätzlich zu einem bereits bestehenden Wireless LAN installiert werden. Sie bestehen meist aus einer zentralen Monitor-Komponente und mehreren über das Netzwerk verteilten Sensoren. Der Vorteil dieser Lösung ist, dass sich damit auch eine bestehende Infrastruktur um die Funktionalität von Wireless IDS erweitern lässt. Der größte Nachteil sind die hierdurch entstehenden Kosten, da mindestens für jeden Access Point ein eigener Sensor erforderlich ist. Aus diesem Grund sind einige Hersteller dazu übergegangen, die notwendigen Techniken zusammen mit weiteren Managementfunktionen direkt in ihre Access Points zu integrieren [3, 5]. Sie bilden die zweite Gruppe von Wireless IDS. Neben den kommerziellen Produkten existieren auch einige wenige Open-Source- Lösungen. Diese können jedoch erwartungsgemäß nicht den Funktionsumfang professioneller Systeme bieten. Insbesondere bei der Erkennung von Angriffen beschränken sie sich meist auf das Erkennen nicht autorisierter Hardware sowie einiger DoS- Angriffe. Im Verlauf der Arbeit soll deshalb eine eigene Lösung entwickelt werden, die in der Lage sein soll, die meisten der hier vorgestellten Angriffe zu erkennen. Gleichzeitig sollte das System möglichst flexibel sein, d.h. es sollte sich möglichst einfach an die jeweiligen Gegebenheiten vor Ort anpassen lassen. Mit Bro IDS existiert im Festnetzbereich bereits eine Lösung, welche unter anderem die geforderte Flexibilität bietet. In dieser Arbeit soll deshalb untersucht werden, ob und wie das bestehende System um die notwendige Funktionalität erweitert werden kann, so dass es anschließend als Wireless IDS eingesetzt werden kann. 26

27 3 Analyse Bei dem in dieser Arbeit vorgestellten Bro handelt es sich um ein Unix-basiertes Intrusion Detection System, das speziell für den Einsatz in Breitbandnetzen entwickelt wurde [40]. Es ist in der Lage, Angriffe auf ein Netzwerk in Echtzeit zu erkennen und hierauf entsprechend zu reagieren. Dazu überwacht das System den Netzwerkverkehr auf den Schichten 3 bis 7 des OSI-Modells und generiert wohl definierte Ereignisse, welche das Vorhandensein bestimmter Aktivitäten anzeigen. Die Entwickler von Bro legten dabei größten Wert auf eine klare Trennung zwischen den Mechanismen zur Ereignis-Generierung und der Definition einer Standort-spezifischen Sicherheitspolitik. Daher sind alle auf Netzwerkebene generierten Ereignisse zunächst Policy-neutral. Erst durch die Existenz einer geeigneten Security Policy wird festgelegt, wie diese Ereignisse entsprechend den konkreten Sicherheitsanforderungen eines Standortes zu interpretieren sind. Zur Formulierung einer solchen Sicherheitspolitik verwendet Bro eine eigens hierfür entwickelte Skript-Sprache. Damit lassen sich so genannte Event Handler definieren, welche die Verarbeitung der generierten Ereignisse übernehmen. Die Möglichkeiten reichen von der Protokollierung bestimmter Aktivitäten bis hin zur Generierung benutzerdefinierter Ereignisse. Im folgenden Abschnitt wird zunächst die Architektur von Bro betrachtet. Danach werden die wesentlichen Basiskonzepte des Systems näher untersucht, um Ansatzpunkte für die im Zusammenhang mit Wireless LAN notwendigen Erweiterungen zu identifizieren. 3.1 Architektur von Bro Die Architektur von Bro ist in Abb. 3.1 dargestellt. Sie besteht zum einen aus den Basiskomponenten Network Analysis, Event Engine und Policy Script Interpreter, die zusammen den Kern der Anwendung bilden. Den zweiten großen Teil bildet die für einen Standort geltende Sicherheitspolitik, die mit Hilfe verschiedener Policy-Skripte definiert wird. Im Folgenden werden die einzelnen Bestandteile von Bro kurz erläutert. 27

28 Abbildung 3.1: Architektur von Bro [10] Network Analysis Wie bereits erwähnt, analysiert Bro den Netzwerkverkehr auf den Schichten 3 bis 7 des OSI-Modells. Dabei kommen folgende zwei Techniken zum Einsatz. Zum einen untersucht eine so genannte Signature Engine den ankommenden Datenstrom nach speziellen Signaturen, welche auf bekannte Angriffe hinweisen. Hierbei handelt es sich um eine weit verbreitete Technik von Intrusion Detection Systemen. Darüber hinaus unterstützt Bro die direkte Analyse der auf den einzelnen Schichten eingesetzten Protokolle. Die so genannten Protocol Analyzer existieren unter anderem für ICMP, UDP, TCP sowie diverse Anwendungsprotokolle. Sowohl Signature Engine als auch Protocol Analyzer generieren beim Auftreten bestimmter Aktivitäten entsprechende Ereignisse. Event Engine Die bei der Analyse des Netzwerkverkehrs generierten Ereignisse werden durch eine spezielle Event Engine verarbeitet. Dazu werden beim Start von Bro alle auf Policy- Ebene definierten Event-Handler registriert. Zudem werden neue Ereignisse zunächst in einer Warteschlange gesammelt, bevor anschließend die zugehörigen Event Handler aufgerufen werden. 28

29 Abbildung 3.2: Funktionsweise von Bro Policy Script Interpreter Der Policy Script Interpreter stellt das Bindeglied zwischen Policy-Ebene und dem Rest der Anwendung dar. Seine Aufgabe besteht hauptsächlich darin, die in den Policy- Skripten enthaltenen Anweisungen auf entsprechende C++-Klassen abzubilden und auszuführen. Gleichzeitig definiert er auch die verwendete Skript-Sprache. Policy Layer Während die bisher beschriebenen Komponenten im Wesentlichen die Mechanismen zur Generierung von Ereignissen bereitstellen, ist es Aufgabe der Policy-Ebene, die konkrete Sicherheitspolitik eines Standortes in Form so genannter Policy-Skripte zu definieren. Hauptbestandteil dieser Policy-Skripte sind die Event Handler. Sie legen fest, wie auf bestimmte Ereignisse reagiert werden soll und bilden die Grundlage der spezifischen Security Policy eines Standortes. Peer Communication Bei dieser Komponente handelt es sich um eine relativ neue Erweiterung von Bro. Sie erlaubt die Kommunikation mehrerer Bro-Instanzen sowie insbesondere auch die Ge- 29

30 nerierung so genannter Remote Events. Damit ist es möglich, mehrere Bro-Instanzen zu einer Art verteiltem IDS zu kombinieren. Darüber hinaus existiert mit broccoli ein spezielles API 1, über das es auch externen Programmen möglich ist, mit Bro zu kommunizieren. Auf diese Weise könnte Bro beispielsweise um einen speziellen Sensor erweitert werden, der zusätzlich zum Netzwerkverkehr die System Calls auf einem Rechner überwacht. Die hier beschriebenen Zusammenhänge sind noch einmal in Abb. 3.2 zusammengefasst dargestellt. 3.2 Basiskonzepte von Bro Ereignis-Generierung Wie in Abb. 3.3 dargestellt, verwendet Bro die C-Bibliothek libpcap, um auf den Netzwerkverkehr zuzugreifen. Darüber hinaus wird durch den Einsatz eines Paketfilters die zu verarbeitende Datenmenge bereits im Kernel reduziert, um die notwenige Verarbeitungskapazität so gering wie möglich zu halten. Die weitere Verarbeitung des Datenstroms erfolgt in Bro durch die Klassen PktSrc, NetSessions und Connection. Die Klasse PktSrc bildet die Schnittstelle zwischen Bro und libpcap. Dazu stellt sie eine Methode namens ExtractNextPacket zur Verfügung, mit der sich die Pakete der jeweiligen Netzwerkverbindung auslesen lassen. Die Klasse NetSessions übernimmt die initiale Verarbeitung der ankommenden Pakete. Diese werden unter anderem jeweils einer bestehenden Kommunikationsverbindung zugeordnet, welche in einer speziellen Listenstruktur verwaltet werden. Der größte Teil der Verarbeitung, sprich die Analyse des Netzwerkverkehrs, erfolgt in Abhängigkeit vom verwendeten Protokoll. Hierfür existieren unter anderem spezielle Klassen für ICMP, TCP und UDP sowie darüber hinaus für zahlreiche weitere Anwendungsprotokolle. Dabei handelt es sich jeweils um Unterklassen der Klasse Connection. Im Folgenden werden die verschiedenen Abläufe während der Analyse des Netzwerkverkehrs näher untersucht. Beim Start von Bro wird die globale Funktion net_init ausgeführt. Dabei wird unter anderem für jede zu überwachende Netzwerkschnittstelle ein neues Objekt der Klasse PktSrc erzeugt. Dieses erlaubt im weiteren Verlauf den Zugriff auf die Pakete der jeweiligen Schnittstelle. Gleichzeitig wird ein neuer Paketfilter installiert sowie der 1 API steht für Application Programming Interface 30

31 Abbildung 3.3: Verwendung von libpcap jeweilige Verbindungs-Typ (Datalink Type) des zugrunde liegenden Netzwerkes bestimmt. Zur Zeit erkennt Bro unter anderem Netzwerke auf Basis von Ethernet und FDDI 2. Alternativ erlaubt Bro auch die Offline-Analyse von mitgeschnittenem Netzwerkverkehr. In diesem Fall wird einfach die entsprechende Datei als Paketquelle verwendet. Anschließend findet die weitere Verarbeitung innerhalb der Funktion net_run statt. Die an dieser Stelle beschriebenen Abläufe sind in Abb. 3.4 dargestellt. 1. Als erstes wird die Methode ExtractNextPacket der Klasse PktSrc aufgerufen. Darin wird das nächste verfügbare Paket ausgelesen und zur weiteren Verarbeitung an die Klasse NetSessions übergeben. 2. Um auch bei der gleichzeitigen Überwachung mehrerer Paket-Quellen sicherzustellen, dass alle Nachrichten in der Reihenfolge ihres tatsächlichen Eintreffens verarbeitet werden, übernimmt die Methode DispatchPacket der Klasse NetSessions optional die Sortierung der ankommenden Pakete. 3. Die Methode NextPacket entfernt zunächst alle Protokoll-Header unterhalb von Schicht 3 des OSI-Modells und extrahiert anschließend den IP-Header. 2 FDDI steht für Fiber Distributed Data Interface, einer Technik für Glasfaser-Netzwerke 31

32 Abbildung 3.4: Informationsfluss bei der Ereignis-Generierung 4. Als Nächstes wird das Paket in der Methode DoNextPacket diversen Überprüfungen unterzogen. So wird unter anderem festgestellt, ob es sich bei dem im IP-Header angegebenen Transportprotokoll um TCP, UDP oder ICMP handelt. Ist dies nicht der Fall, so wird das Paket sofort verworfen und eine entsprechende Meldung generiert. Des Weiteren erfolgt an dieser Stelle gegebenenfalls die Zusammensetzung von fragmentierten IP-Paketen, bevor anschließend der IP-Header entfernt wird. Abschließend wird geprüft, ob das Paket Teil einer bestehenden Verbindung ist. In diesem Fall wird es zur weiteren Verarbeitung an das entsprechende Objekt der Klasse Connection bzw. ihrer Unterklassen übergeben. Handelt es sich bei dem Paket hingegen um das erste einer Verbindung, so wird ein entsprechendes Objekt der Klasse Connection erzeugt und zur Liste der bekannten Verbindungen hinzugefügt, bevor anschließend auch hier das Paket zur weiteren Verarbeitung übergeben wird. 5. Innerhalb der Methode NextPacket der jeweiligen Unterklasse von Connection findet nun die protokollspezifische Analyse des Paketes statt. Je nach Inhalt des Paketes werden an dieser Stelle nun die verschiedenen Ereignisse generiert. Damit ist die Verarbeitung für dieses Paket abgeschlossen. Der hier beschriebene Vorgang wiederholt sich für jedes einzelne Paket aller überwachten Netzwerk-Schnittstellen. 32

33 3.2.2 Ereignis-Verarbeitung Im letzten Abschnitt wurde gezeigt, wie die Analyse des Netzwerkverkehrs letztendlich die Generierung von bestimmten Ereignissen zur Folge hatte. Daher sollen als nächstes die konkreten Zusammenhänge bezüglich der Ereignisverarbeitung näher untersucht werden. Abbildung 3.5: Informationsfluss bei der Ereignisverarbeitung Voraussetzung für die Verarbeitung von Ereignissen ist die Definition so genannter Event Handler. Darin wird festgelegt, welche Anweisungen beim Eintreten bestimmter Ereignisse ausgeführt werden sollen. Neben den standardmäßig in Bro enthaltenen Events können auch benutzerdefinierte Ereignisse verwendet werden. Hierzu benötigt es allein der Definition eines entsprechenden Handlers. Nicht zuletzt können für ein Ereignis prinzipiell mehrere Handler definiert werden. Abb. 3.5 zeigt eine Übersicht der während der Verarbeitung von Ereignissen ablaufenden Vorgänge. Diese lassen sich wie folgt beschreiben: 1. Beim Start von Bro werden zunächst alle aktivierten Policy-Skripte eingelesen. 2. Damit die darin definierten Event Handler später auch aufgerufen werden können, werden sie in einem speziellen Verzeichnis, dem so genannten Event Registry, erfasst. 3. Soll nun zur Laufzeit ein bestimmtes Ereignis generiert werden, so kann der zugehörige Event Handler durch einfaches Nachschlagen im Event Registry ermittelt werden. 4. Anschließend wird das generierte Ereignis zusammen mit den erforderlichen Parametern in einer Warteschlange, der so genannten Event Queue, abgelegt. 33

34 5. Nachdem die Verarbeitung für ein Paket abgeschlossen ist, wird die Warteschlange durch den Event Manager verarbeitet. 6. Dabei werden nacheinander für alle in der Warteschlange befindlichen Ereignisse die zugehörigen Event Handler aufgerufen. Für den Fall, dass für ein Ereignis mehrere Handler existieren, werden diese sequentiell abgearbeitet. 7. Die Lokalisierung der Event Handler sowie die Ausführung der darin definierten Anweisungen erfolgt durch den Interpreter. Hierbei kann es vorkommen, dass zusätzliche Ereignisse generiert werden. In einem solchen Fall werden anschließend die Schritte 4 und 5 durch den Interpreter erneut ausgeführt. Zum Abschluss sollen noch kurz die im Zusammenhang mit der Ereignisverarbeitung wesentlichen Klassen genannt werden. Die Klasse EventRegistry entspricht dabei der gleichnamigen Komponente zur Registrierung von Event Handlern. Hierzu stellt sie die Methoden Register und Lookup zur Verfügung. Verantwortlich für die Verwaltung der Warteschlange ist die Klasse EventMgr. Über die Methode QueueEvent lassen sich neue Ereignisse zur Warteschlange hinzufügen, während ein Aufruf von Drain dafür sorgt, dass die in der Warteschlange befindlichen Ereignisse aufgerufen werden. Zu nennen ist an dieser Stelle noch die Tatsache, dass das Hinzufügen und anschließende Verarbeiten von Ereignissen asynchron erfolgt. Das bedeutet, dass während der Analyse eines Datenpaketes durchaus mehrere Ereignisse generiert werden können und diese erst nach Abschluss der Analyse durch einen Aufruf von EventMgr::Drain verarbeitet werden Policy-Interpretation Wie schon erwähnt, besteht bei Bro die konkrete Sicherheitspolitik eines Standortes aus einer Sammlung so genannter Policy-Skripte, die in einer speziell für diesen Anwendungsbereich entwickelten Skript-Sprache formuliert werden. Auf die einzelnen Konstrukte der Sprache soll an dieser Stelle nicht näher eingegangen werden. Sie werden in aller Ausführlichkeit in [48] beschrieben. Für den Moment soll es genügen zu wissen, dass die einzelnen Policy-Skripte im Wesentlichen aus den bereits genannten Event Handlern sowie darüber hinaus aus einer beliebigen Anzahl von Variablen-, Typ- und Funktionsdefinitionen bestehen. Das Einlesen und Ausführen der Skripte ist Aufgabe des Interpreters. An dieser Stelle sollen die verschiedenen Komponenten des Interpreters beleuchtet werden. Voraussetzung für die Interpretation der Policy-Skripte ist zunächst die Definition der verwendeten Sprache. Hierfür ist die Angabe einer entsprechenden Grammatik sowie 34

35 der zugehörigen Terminalsymbole (Tokens) erforderlich. Für die Bro-Skriptsprache erfolgt deren Spezifikation in den Dateien scan.l und parse.y. Mittels spezieller Werkzeuge lässt sich daraus nun ein geeigneter Parser in Form eines C-Programms erzeugen [44]. Die dazugehörigen Dateien lauten parse.cc und scan.cc. Neben der Definition des Parsers sind zudem spezielle Klassen notwendig, welche die verschiedenen Aspekte der Skriptsprache in C++ abbilden. Datentypen Zur Repräsentation der auf Policy-Ebene definierten Datentypen existiert die zentrale Klasse BroType, welche in den Dateien Type.h und Type.cc definiert wird. Für jeden Datentyp, egal ob benutzerdefiniert oder Bestandteil der Sprache, wird eine neue Instanz dieser Klasse erzeugt. Zur internen Unterscheidung wird jedes Objekt mit einer speziellen Kennzeichnung versehen. Die Klasse BroType stellt zudem zusätzliche Funktionalität bereit, um beispielsweise eine Typ-Überprüfung auf Policy-Ebene zu ermöglichen. Werte Die Speicherung von Variablenwerten erfolgt in Objekten der Klasse Val bzw. einer ihrer Unterklassen. Sie werden zusammen in den gleichnamigen Dateien Val.h und Val.cc spezifiziert. Neben dem Wert einer Variablen wird zudem der zugehörige Datentyp gespeichert. Außerdem verfügt auch diese Klasse über zusätzliche Funktionalität, wie sie zum Beispiel für den Umgang mit zusammengesetzten Werten notwendig ist. Bezeichner Um die auf Policy-Ebene definierten Variablen, Datentypen und Funktionen verwenden zu können, muss ihnen ein eindeutiger Name zugeordnet werden. Hierfür wird für jedes Bro-Objekt eine Instanz der Klasse ID erzeugt, welches die Verbindung zwischen Name, Typ und Wert eines Objektes herstellt. Die zugehörigen Dateien lauten ID.h und ID.cc. Attribute Variablen können neben einem Typ und einem Wert zudem verschiedene Attribute besitzen. Dabei handelt es sich um spezielle Meta-Informationen, mit denen sich beispielsweise die Dauer der Gültigkeit einer bestimmten Variablen angeben lässt. Zur Speicherung von Attributen existiert die Klasse Attr, die in den Dateien Attr.h und Attr.cc definiert wird. Gültigkeitsbereiche Die einzelnen Objekte innerhalb eines Policy-Skriptes besitzen jeweils einen definierten Gültigkeitsbereich. Prinzipiell lässt sich dabei zwischen globalen und lokalen Bereichen unterscheiden. Es ist Aufgabe der Klasse Scope, die in den Policy-Skripten definierten Bezeichner jeweils einem bestimmten Gültigkeitsbereich zuzuordnen. Gleichzeitig wird damit ein Verzeichnis aller auf Policy-Ebene existierenden Objekte realisiert. Die Klasse Scope ist in den gleichnamigen Dateien Scope.h und Scope.cc beschrieben. Ausdrücke Beim Einlesen der Policy-Skripte muss der Interpreter in der Lage sein, komplexe Ausdrücke wie beispielsweise Variablendefinitionen, Wertzuweisun- 35

36 gen oder Funktionsaufrufe entsprechend auszuwerten. Hierfür verwendet er Objekte der in den Dateien Expr.h und Expr.cc definierten Klassen. Anweisungen Mit Hilfe von Ausdrücken und den zur Sprache gehörenden Schlüsselwörtern lassen sich schließlich Anweisungen formulieren, welche die eigentliche Verarbeitung innerhalb eines Policy-Skriptes realisieren. Zur temporären Speicherung von Anweisungen verwendet Bro die Klasse Stmt, welche in den Dateien Stmt.h und Stmt.cc definiert wird. Funktionen Für die Verarbeitung von Funktionen verwendet der Interpreter zusätzlich die Klasse Func. Sie enthält unter anderem spezielle Methoden, welche zur Realisierung von Funktionsaufrufen auf Policy-Ebene benötigt werden. Sie steht zudem in engem Zusammenhang mit der Klasse Frame, welche den zur Laufzeit benötigten Aufruf-Stack realisiert. Event Handler Die Verarbeitung von Event Handlern erfolgt weitestgehend analog zu der Verarbeitung von Funktionen. Hierfür wird die Klasse EventHandler verwendet, welche einen Adpater für die Klasse Func darstellt. Nachdem die einzelnen Bestandteile des Interpreters untersucht wurden, sollen als Nächstes die konkreten Abläufe bei der Verarbeitung von Policy-Skripten betrachtet werden. Hierbei ist grundsätzlich zwischen zwei Phasen zu unterscheiden. Abbildung 3.6: Interpretation der Policy-Skripte Die erste Phase beginnt mit dem Starten von Bro. Dabei werden, beginnend mit der Datei bro.init, zunächst alle aktivierten Policy-Skripte eingelesen. Trifft der Interpreter dabei auf eine Variablen-, Typ- oder Funktionsdefinition, so erzeugt er die entsprechenden Objekte der Klassen BroType, Val und ID und speichert sie im aktuellen Scope. Die in einem Skript definierten Event Handler werden hingegen an ein Ob- 36

37 jekt der Klasse EventRegistry übergeben. Nach Einlesen aller Policy-Skripte kann auf sämtliche Objekte über ihren Namen zugegriffen werden. Die hier beschriebenen Abläufe werden zudem in Abb. 3.6 zusammengefasst. Die zweite Phase findet zur Laufzeit statt und beginnt mit dem Aufruf eines Event Handlers. Die darin definierten Anweisungen werden nacheinander ausgeführt. Im Falle eines Funktionsaufrufes wird die aktuelle Position im Stack gesichert. Als Ergebnis der ausgeführten Anweisungen ändert sich der Zustand der im Scope befindlichen Objekte. So ändert sich beispielsweise der Wert einer Variablen bei Ausführung einer Wertzuweisung. Darüber hinaus können jederzeit neue Variablen hinzukommen bzw. beim Verlassen eines bestimmten Gültigkeitsbereiches wegfallen Policy-Definition Abschließend soll noch kurz auf die Definition konkreter Policy-Skripte eingegangen werden. Die mit Bro mitgelieferten Skripte befinden sich nach der Installation in einem Verzeichnis namens policy. Wie bereits beschrieben, werden sie beim Start von Bro durch den Interpreter eingelesen. Dabei wird mit dem Skript bro.init begonnen. Über spezielle Include-Befehle werden dabei weitere Policies eingebunden. Dieser Vorgang wiederholt sich, bis alle verknüpften Policy-Skripte eingelesen wurden. Neben den Standard-Skripten befinden sich in dem Verzeichnis site zusätzlich die Dateien local.site.bro und host.bro. Über diese kann der Benutzer Standortspezifische Anpassungen von Bro vornehmen. So lassen sich beispielsweise weitere Policy-Skripte durch entsprechende Include-Befehle aktivieren. Darüber hinaus kann über spezielle Variablen die Arbeitsweise der geladenen Policies an die Bedingungen vor Ort angepasst werden. Dadurch entfällt in den meisten Fällen die Notwendigkeit, manuelle Änderungen an den Standard-Skripten vornehmen zu müssen. Am Ende ist es die Gesamtheit der aktiven Policy-Skripte, welche die konkrete Sicherheitspolitik eines Standortes abbildet. 3.3 Notwendige Erweiterungen der Bro-Architektur Nach der Analyse der wichtigsten Konzepte stellt sich nun die Frage, an welchen Stellen Bro erweitert werden muss, um die Funktionalität eines Wireless IDS zu realisieren. Dazu muss zunächst einmal die Ebene der Datenerfassung betrachtet werden. Die von Bro verwendete C-Bibliothek libpcap erfordert danach keinerlei Änderungen, da seit Version 0.7 der Empfang von Frames standardmäßig unterstützt wird. Jedoch wird für ein eigener Datalink Type verwendet. Daher sind hier entsprechende 37

38 Anpassungen an der Klasse PktSrc vorzunehmen. Zudem muss an geeigneter Stelle die notwendige Funktionalität für die Verarbeitung von Frames hinzugefügt werden. Es bietet sich an, hierfür eine eigene Klasse zu verwenden. Im Bereich der Ereignisverarbeitung sind neue Ereignisse zu definieren, wie sie speziell im Zusammenhang mit auftreten können. Darüber hinaus sind auf Policy- Ebene passende Event Handler hinzuzufügen. Nicht zuletzt ist zudem eine Anpassung der verwendeten Skript-Sprache erforderlich. So fehlen Bro derzeit geeignete Mittel zur Speicherung und Darstellung der in verwendeten Netzwerk-Adressen. 38

39 4 Implementierung Im vorangegangenen Kapitel wurden die wesentlichen Konzepte von Bro analysiert sowie die notwendigen Erweiterungen der Bro-Architektur genannt. Dieses Kapitel beschäftigt sich nun mit der konkreten Umsetzung der darin vorgeschlagenen Änderungen. Dabei soll die Gliederung aus Abschnitt 3.2 im Großen und Ganzen beibehalten werden. 4.1 Erweiterung der Ereignis-Generierung Ziel ist es, Bro so zu erweitern, dass es Frames verarbeiten kann. Hierzu ist zum einen die Klasse PktSrc an den neuen Netzwerktyp anzupassen. Zum anderen soll eine neue Klasse WLANSessions (in Anlehnung an die in Bro existierende Klasse NetSessions) hinzugefügt werden, welche die Verarbeitung der empfangenen Frames übernimmt Anpassung der Klasse PktSrc Bei der Initialisierung von Objekten der Klasse PktSrc wird unter anderem der zugrunde liegende Netzwerktyp ermittelt. Diese Information wird in der Regel dazu benötigt, die Größe der auf Schicht 2 verwendeten Protokoll-Header zu bestimmen, um diese im weiteren Verlauf von den einzelnen Paketen entfernen zu können. Im Falle von sollen die Header jedoch erhalten bleiben. Daher ist die Methode SetHdrSize so anzupassen, dass für den Netzwerktyp die Header-Größe auf null gesetzt wird. Darüber hinaus wird der Klasse PktSrc die Methode IsWireless hinzugefügt, um im weiteren Verlauf notwendige Fallunterscheidungen durchführen zu können. Im Zusammenhang mit muss außerdem berücksichtigt werden, auf welchen Kanal eine Netzwerkschnittstelle tatsächlich eingestellt ist. Diese Information wird unter anderem in Kapitel 5 benötigt, wenn es um die Erkennung von Angriffen auf drahtlose Netzwerke geht. Der Konstruktor der Klasse PktSrc wurde daher um einen speziellen Aufruf ergänzt, bei dem mit Hilfe der unter Linux verfügbaren Wireless Extensions der aktuelle Kanal einer drahtlosen Schnittstelle abgefragt wird. Zudem 39

40 wurde der Klasse die Methode GetChannel hinzugefügt, um auf diese Information im weiteren Verlauf zugreifen zu können Hinzufügen der Klasse WLANSessions Die Verarbeitung von Frames soll in der neuen Klasse WLANSessions erfolgen. Ein zentraler Punkt ist dabei die Zerlegung der Pakete in ihre atomaren Bestandteile. Im Folgenden werden die einzelnen Schritte der Verarbeitung beschrieben. Die einzelnen Schritte der Verarbeitung lauten wie folgt: 1. Zunächst muss festgestellt werden, um welche Art von Frame es sich handelt. Laut Standard sind hier die drei Typen Management-, Control- und Data-Frame möglich. 2. Anschließend muss der Frame-Header in seine Bestandteile zerlegt werden, um beispielsweise an die Absender- bzw. Empfängeradressen zu gelangen. 3. Bevor mit der Verarbeitung des Datenteils (Frame Body) begonnen wird, muss noch geprüft werden, ob es sich bei dem aktuellen Frame möglicherweise um ein Fragment handelt. In diesem Fall sind zunächst die alle Fragmente eines Paketes zusammenzusetzen, bevor mit der weiteren Verarbeitung fortgefahren werden kann. 4. Die für die Erkennung von Angriffen auf Wireless LAN interessanten Informationen befinden sich zum Teil im Frame Body der Management-Frames. Dabei muss zwischen obligatorischen Feldern mit fester Länge und optionalen Feldern mit variable Länge unterschieden werden. 5. Nachdem das Paket zerlegt und analysiert wurde, werden nun entsprechende Ereignisse generiert. Hierzu wird auf den nächsten Abschnitt verwiesen. Bei der beschriebenen Zerlegung der Pakete wird sich bewusst am ursprünglichen Standard orientiert. Eine Berücksichtigung der aktuellen Standards a, b und g ist zwar problemlos möglich, erscheint momentan jedoch nicht sinnvoll, da sie bezüglich des verwendeten Frame-Formats zu kompatibel sind. Auch aktuelle Entwicklungen wie WPA und i, sowie herstellerspezifische Erweiterungen des Standards sollen an dieser Stelle nicht betrachtet werden. Zum Schluss muss die neu erstellte Klasse an geeigneter Stelle in Bro eingebunden werden. Dabei sollen nach Möglichkeit die bestehenden Mechanismen erhalten bleiben. Insbesondere soll auch weiterhin die Verarbeitung von Paketen auf Schicht 3 des OSI-Modells möglich sein. 40

41 Abbildung 4.1: Geänderter Informationsfluss bei der Ereignis-Generierung Dazu wird in der Methode ExtractNextPacket der Klasse PktSrc eine Fallunterscheidung vorgenommen. Hierfür wird die zuvor hinzugefügte Methode IsWireless verwendet, um festzustellen, ob ein Paket über eine drahtlose Netzwerkverbindung empfangen wurde. In diesem Fall wird das Paket an die Methode DispatchPacket der Klasse WLANSessions übergeben. Andernfalls wird der bereits existierende Verarbeitungszweig verwendet. Dieser Vorgang wird in Abb. 4.1 dargestellt. Prinzipiell ist es somit möglich, drahtlose und kabelgebundene Netzwerke mit nur einer Bro-Instanz zu überwachen. 4.2 Erweiterungen der Ereignis-Verarbeitung Nachdem nun klar ist, wie die Frames verarbeitet werden, um Ereignisse zu generieren stellt sich die Frage, welche Ereignisse denn benötigt werden, um die in Kapitel 2 beschriebenen Angriffe erkennen zu können. Des weiteren wird in diesem Abschnitt die konkrete Vorgehensweise beim Hinzufügen neuer Ereignisse beschrieben Definition neuer Ereignisse für Bei der Definition neuer Ereignisse existiert zunächst nur eine einzige Vorgabe: die Ereignisse müssen Policy-neutral sein. Das bedeutet, dass erst durch die konkreten 41

42 Handler auf Policy-Ebene festgelegt wird, welche Ereignisse einen potentiellen Angriff darstellen. Die Definition neuer Ereignisse ist keine einfache Aufgabe. Es lässt sich nur schwer abschätzen, welche konkreten Ereignisse zur Erkennung bestimmter Angriffe notwendig sind. Einen ersten Ansatz liefert die genauere Betrachtung der in Abschnitt 2.2 beschriebenen Angriffe. Dabei wird deutlich, dass in den meisten Fällen gefälschte Management- Frames zum Einsatz kommen. Es ist daher sinnvoll, die verschiedenen Frame-Subtypen auf entsprechende Ereignisse abzubilden. Darüber hinaus werden zudem spezielle Ereignisse für das Anzeigen von Fehlern benötigt. Hieraus ergeben sich die folgenden neuen Ereignisse: event event event event event event event event event event event wlan_assoc_req wlan_assoc_resp wlan_reassoc_req wlan_reassoc_resp wlan_probe_req wlan_probe_resp wlan_beacon wlan_disassoc wlan_auth wlan_deauth wlan_unknown_type Ein anderer Ansatz basiert darauf, dass die einzelnen Pakete bestehenden Verbindungen zugeordnet werden und nur dann Ereignisse generiert werden, wenn sich der Zustand einer Verbindung ändert. Dieses Verfahren wird unter anderem von Bro bei der Analyse von IP-Paketen verwendet. In dieser Arbeit soll jedoch die erste Variante implementiert werden. Zum einen lässt sich mit ihr der o.g. Ansatz auf Policy-Ebene bei Bedarf simulieren. Zum anderen werden dadurch die Änderungen am Quelltext so gering wie möglich gehalten. Die Nachteile bezüglich der zu erwartenden Performance sind an dieser Stelle nicht Ausschlag gebend, da es sich hierbei nur um ein Proof-of-Concept handelt Hinzufügen der neuen Ereignisse zu Bro Als nächstes stellt sich die Frage, wie die neuen Ereignisse hinzugefügt werden können. Wie bereits in Abschnitt erläutert, müssen hierfür nur die entsprechenden Event Handler auf Policy-Ebene definiert werden. Beim Start von Bro werden sie dann in dem Event Registry erfasst und es kann anschließend wie in Abb. 3.5 dargestellt durch einen Aufruf von EventRegistry::Lookup darauf zugegriffen werden. Um einen Event Handler nicht immer wieder neu im Event Registry nachschlagen zu müssen, wird in der Datei NetVar.h für jeden standardmäßig in Bro enthaltenen Event Handler eine globale Variable definiert. Über diese kann aus jeder Klasse heraus unmittelbar auf den jeweiligen Event Handler zugegriffen werden. Die Initialisierung 42

43 dieser Variablen findet in der Datei NetVar.cc statt. Zudem müssen die Event Handler auch auf Policy-Ebene deklariert werden. Hierfür sind entsprechende Einträge in der Datei bro.init erforderlich. Abbildung 4.2: Hinzufügen neuer Ereignisse zu Bro Wesentlich einfacher jedoch lassen sich neue Ereignisse durch Angabe in der Datei event.bif hinzufügen. Aus dieser generiert ein spezieller Compiler automatisch die erforderlichen Code-Abschnitte, welche anschließend an den entsprechenden Stellen eingefügt werden. Dieser Vorgang ist auch in Abb. 4.2 dargestellt. Erläuterungen zu den in Abb. 4.2 genannten Dateien: event.bif Definiert Ereignisse in einer speziellen Syntax. event.bif.bro Enthält die notwendigen Deklarationen auf Policy Ebene. Wird beim Start zusammen mit der Datei bro.init geladen. event.bif.netvar_h Enthält die C++-Deklarationen der globalen Handler-Variablen. Wird mittels include zur Datei NetVar.h hinzugefügt. 43

44 event.bif.netvar_def event.bif.netvar_init Enthält die C++-Definitionen der globalen Handler-Variablen. Wird in der Datei NetVar.cc hinzugefügt. Initialisiert die globalen Handler- Variablen durch den Aufruf von EventRegistry::Lookup. Wird nach event.bif.netvar_def in NetVar.cc hinzugefügt. Die Definition der neu hinzugekommenen Event Handler findet direkt auf Policy- Ebene statt. Hierfür wird auf den Abschnitt 4.4 verwiesen. 4.3 Erweiterungen der Policy-Interpretation Wie bereits erwähnt verfügt die Bro-eigene Skript-Sprache über keine geeigneten Konstrukte zur Darstellung der in verwendeten MAC-Adressen. Bei der Definition neuer Policy-Skripte ist es jedoch nicht zuletzt aus Gründen der Lesbarkeit erwünscht, MAC-Adressen in der allgemein üblichen Notation angeben zu können. Aus diesem Grund soll die Sprache um die notwendigen Konstrukte zur einfachen Darstellung solcher Adressen erweitert werden. Es kann vorweg genommen werden, dass es sich hierbei um den wohl aufwändigsten Teil bei der Erweiterung von Bro handelt. Glücklicherweise unterstützt Bro in der aktuellen Fassung IPv6-Adressen, welche bezüglich ihrer Struktur MAC-Adressen sehr ähnlich sind. Hierdurch lassen sich die notwendigen Ansatzpunkte bei der Erweiterung von Bro etwas einfacher bestimmen. Die erforderlichen Schritte werden im Folgenden beschrieben Anpassung der C++-Klassen Jeder Bro-Typ wird durch eine Instanz der Klasse BroType repräsentiert. Dazu speichert Bro zu jedem Typ ein eigenes Tag. Sowohl die Klasse BroType als auch die bekannten Tags werden in den Dateien Type.h und Type.cc definiert. Listing 4.1 zeigt einen entsprechenden Auszug, wobei sämtliche Qualifier aus Gründen der Übersichtlichkeit weggelassen wurden. Wie daraus zu ersehen ist sind die Tags als der Datentyp TypeTag definiert und werden bei Anlegen eines neuen Objektes per Konstruktor übergeben. 44

45 1 typedef enum { TYPE_PORT, TYPE_ADDR, TYPE_NET, TYPE_SUBNET, } TypeTag; 6 7 class BroType : public BroObj { 8 9 BroType( TypeTag tag, bool base_type ); TypeTag Tag (); TypeTag tag; }; int is_assignable ( BroType* t); 18 int same_type ( BroType* t1, BroType* t2, int is_init); 19 BroType* merge_types ( BroType* t1, BroType* t2); Listing 4.1: Auszug aus Type.h Es ist also zunächst ein Tag für den neuen Datentyp hinzuzufügen. Der Name des neuen Tags soll TYPE_MAC sein. Damit kann der Parser später beim Einlesen der Policy- Skripte ein entsprechendes Typ-Objekt für MAC-Adressen anlegen. Wie in Listing 4.1 außerdem zu sehen ist, verwendet Bro verschiedene globale Funktionen, um damit diverse Überprüfungen durchführen zu können. So liefert die Funktion is_assignable den Wert true zurück, wenn einer Variablen mit Typ t ein Wert zugewiesen kann. Die Funktion same_types prüft hingegen, ob die Typen zweier Variablen übereinstimmen. Damit der neue Datentyp später in Policy-Skripten verwendet werden kann, müssen also auch diese Funktionen entsprechend angepasst werden, dass die auch für den neuen Typ stets das korrekte Ergebnis zurückgeben. Neben der Einführung des neuen Datentyps muss außerdem definiert werden, wie die zugehörigen Werte abgespeichert werden sollen. Jede Variable auf Policy-Ebene besitzt neben einem Namen (ID) immer einen Typ (BroType) sowie optional einen Wert. Für das Speichern und Bereitstellen des Wertes einer Variablen ist die Klasse Val zuständig (siehe Listing 4.2). Darüber hinaus existieren eine Reihe von Unterklassen, welche jeweils Werte eine bestimmten Typs aufnehmen können (Z ). Dabei wird für jede Variable auf Policy-Ebene ein eigenes Objekt der Klasse Val bzw. einer ihrer Unterklassen erzeugt. Diese bilden das Gerüst für den Zugriff auf Variablenwerte. Die eigentlich Speicherung erfolgt in einer speziellen Datenstruktur namens BroValUnion (Z. 1-6), welche Teil eines jeden Objektes ist. 45

46 1 typedef union { addr_type addr_val ; 4 subnet_type subnet_val ; } BroValUnion ; 7 8 class Val { 9 10 Val (); 11 void Describe( ODesc* d); addr_type * AsAddr (); 14 subnet_type * AsSubNet (); BroValUnion val; }; class AddrVal : Val; 21 class SubNetVal : Val; int same_atomic_val ( Val* v1, Val* v2); 24 bool is_atomic_val ( Val* v); 25 Val* recover_val ( void* ptr, BroType* t, int& n); Listing 4.2: Auszug aus Val.h Um also die möglichen Werte des neuen Datentyps speichern zu können, ist zum einen die Anpassung der Datenstruktur BroValUnion notwendig und zum anderen ist eine neue Unterklasse von Val zu definieren, welche den Namen MacVal tragen soll. Das Ergebnis ist in Listing 4.3 dargestellt. Wie zu sehen ist, soll der Wert einer MAC-Adresse als eine Folge von 8 Bit breiten Integerwerten gespeichert werden. Auf 64-bit Architekturen könnte man die Adresse auch direkt in einem 64-bit Integer ablegen. Die Klasse MacVal definiert zwei verschiedene Konstruktoren. Einmal wird die Adresse direkt als Byte-Array übergeben, alternativ kann die Adresse auch als Zeichenkette in dem für MAC-Adressen üblichen Format XX:XX:XX:XX:XX:XX übergeben werden. Des Weiteren wurde der Klasse Val eine zusätzliche Accessor-Funktion spendiert, um auf den gespeicherten Wert zugreifen zu können. Darüber hinaus ist auch die Funktion Describe() anzupassen. Diese Funktion teilt dem Interpreter zur Laufzeit mit, wie der Wert einer Variablen aufgebaut ist. Dies ist unter anderem notwendig, um zum Beispiel den Inhalt einer Variablen in eine Log- Datei schreiben zu können. Die Funktion ist also so anzupassen, dass sie für die Werte des neuen Datentyps die passende Beschreibung generiert. Als Letztes sind die globalen Funktionen is_atomic und same_atomic_val anzupassen. Wie der Name schon sagt, prüfen die Funktionen, ob es sich bei dem übergebenen 46

47 1 typedef union { uint8* mac_val; } BroValUnion ; 6 7 class Val { uint8* AsMac (); }; class MacVal : Val { MacVal(char* text); 17 MacVal( uint8* addr); }; Listing 4.3: Erweiterung von Val.h Argument um einen atomaren Wert handelt bzw. ob zwei beliebige Argumente den gleichen Wert besitzen. Auch hier sind wieder Anpassungen notwendig, damit diese Funktionen auch für die möglichen Werte des neuen Datentyps korrekt arbeiten. Schließlich gibt es da noch die Funktion recover_val. Ihre Aufgabe besteht darin, um einen Wert an einer bestimmten Speicherposition auszulesen und in Form eines Objektes der Klasse Val zurückzugeben. Dies wird benötigt, wenn auf Policy-Ebene über eine Variable vom Typ Set oder Table iteriert werden soll, wie dies zum Beispiel bei der for-anweisung der Fall ist. Als nächstes muss definiert werden, wie die in der Skript-Sprache existierende Operatoren auf den neuen Datentyp angewendet werden können. Speziell sind hier die Vergleichsoperatoren interessant. Es soll möglich sein, zwei MAC-Adressen zu vergleichen. Die Funktionalität der Operatoren wird durch die Klasse Expr und ihre Unterklassen definiert. Von besonderem Interesse sind die in Listing 4.4 dargestellten Klassen BinaryExpr, EqExpr und RelExpr. In den Konstruktoren der Klassen wird festgelegt, auf welche Datentypen die jeweilige Operation angewandt werden kann. Hier müssen entsprechende Einträge für den neuen Datentyp hinzugfügt werden. Von speziellem Interesse sind die binären Operationen. Mittels der Funktion Fold wird aus zwei Argumenten durch Anwenden der jeweiligen Operation ein neuer Wert zurückgegeben. Diese Funktion muss so angepasst werden, dass sie für die gewünschten Operationen (in diesem Fall Vergleichsoperationen) für zwei beliebige Argumente vom Typ MAC-Adresse stets das korrekte Ergebnis zurück liefert. Hierfür wurde eigens eine neue Funktion names MacFold eingeführt, an welche die Berechnung delegiert wird. 47

48 1 class BinaryExpr : Expr { 2 3 BinaryExpr ( BroExprTag arg_tag, Expr* arg_op1, Expr* arg_op2) : Expr (arg_tag) 4 Val* Fold(Val* v1, Val* v2); }; 7 8 class EqExpr : BinaryExpr { 9 10 EqExpr( BroExprTag tag, Expr* op1, Expr* op2); }; class RelExpr : BinaryExpr { RelExpr( BroExprTag tag, Expr* op1, Expr* op2); }; Listing 4.4: Auszug aus Expr.h class BinaryExpr : Expr { public: Val* MacFold(Val* v1, Val* v2); }; Bisher wurden der neue Datentyp, sein Wertebereich sowie grundlegende Operationen definiert. Des Weitern soll es möglich sein, den neuen Datentyp als Bestandteil zusammengesetzter Datentypen wie records und tables zu verwenden. So soll zum Beispiel in Bro Folgendes möglich sein: type test1: record { field1: <neuer Datentyp >; field2: < existierender Datentyp >; }; type test2: table [< neuer Datentyp >] of < existierender Datentyp >; Der erste Fall funktioniert mit den bisherigen Änderungen auf Anhieb. Für den zweiten Fall, also die Verwendung des neuen Datentyps als Index in einem table, sind jedoch zusätzliche Änderungen notwendig. Der Grund ist, dass tables intern als Hash-Tables realisiert werden. Daher muss es möglich sein, aus einem Index-Wert einen Hash-Wert zu berechnen. Auch hierfür existiert in Bro bereits eine eigene Klasse (siehe Listing 4.5). Die Funktionen ComputeHash und ComputeSingletonHash sind für die Berechnung eines Hash-Wertes aus einem Index-Wert zuständig. Die Funktionen ComputeKeySize und SingleTypeKeySize berechnen hingegen die Breite eines Hash-Wertes, welcher natürlich vom Index-Typ abhängt. 48

49 1 class CompositeHash { 2 3 CompositeHash ( TypeList* composite_type ); 4 5 HashKey* ComputeHash (Val* v,...); 6 HashKey* ComputeSingletonHash ( Val* v,...); 7 8 ListVal* RecoverVals ( HashKey* k); 9 char* RecoverOneVal ( HashKey* k, BroType* t,...); int ComputeKeySize (Val* v,...); 12 int SingleTypeKeySize ( BroType* t, Val* v,...); }; Listing 4.5: Auszug aus CompHash.h Die Methoden RecoverVals und RecoverOneVal werden benötigt, um umgekehrt zu einem bestimmten Hash-Schlüssel den eigentlichen Index-Wert zurückzugeben. Dies ist u.a. dann notwendig, wenn über die Werte einer table-struktur iteriert werden soll (siehe auch weiter oben). Alle hier genannten Funktionen sind ebenfalls entsprechend der Werte des neuen Datentyps anzupassen. Auf die Einzelheiten der Änderungen soll an dieser Stelle nicht weiter eingegangen werden, stattdessen wird auf den Quelltext verwiesen. Damit ist die Anpassung der C++-Klassen abgeschlossen Anpassung des Parsers Um den neuen Datentyp in Policy-Skripten verwenden zu können, muss natürlich auch der Parser enstprechend erweitert werden. So müssen zum einen die Zeichenketten für den Typ als auch für die gültigen Werte definiert werden. Zum anderen muss die Grammatik um eine Regel für den neuen Datentyp erweitert werden. Wie zuvor bereits geschildert, wird die Grammatik in der Datei parse.y beschrieben, während die Zeichenketten (Tokens) in scan.l definiert werden. Die notwendigen Erweiterungen sind in den Listing 4.6 und 4.7 abgebildet. 1 mac return TOK_MAC; 2 3 ({ HEX }:) {5}{ HEX} { 4 yylval. val = new MacVal( yytext); 5 return TOK_CONSTANT ; 6 } Listing 4.6: Erweiterung von scan.l 49

50 1 % token TOK_MAC 2 % token TOK_CONSTANT 3 4 type: 5 6 TOK_MAC { 7 set_location (@1); 8 $$ = base_type ( TYPE_MAC); 9 } 10 expr: TOK_CONSTANT { 13 set_location (@1); 14 $$ = new ConstExpr ( $1); 15 } Listing 4.7: Erweiterung von parse.y Der Ablauf ist im Wesentlichen wie folgt: Trifft der Parser auf die Zeichenkette mac, so merkt er sich deren Position und erzeugt eine neue Instanz der weiter oben beschriebenen Klasse BroType. Trifft er hingegen auf eine Zeichenkette, welche das Format XX:XX:XX:XX:XX:XX hat, so interpretiert er sie als eine Konstante vom Typ MAC- Adresse und erzeugt eine neue Instanz der Klasse MacVal (Z ). Für Details bezüglich der Syntax von parse.y und scan.l wird auf [44] verwiesen. Damit ist die Erweiterung der Skript-Sprache um den neuen Datentyp abgeschlossen. 50

51 4.4 Erweiterungen auf Policy-Ebene Nachdem im Abschnitt 4.2 neue Ereignisse für eingeführt wurden, fehlen nun noch die entsprechenden Event Handler, um die generierten Ereignisse zu verarbeiten. Hier ein Beispiel: //Auszug aus policy/wireless.bro event wlan_probe_req (c: ieee80211_probe_req ) { print fmt(" START POLICY "); print fmt(" Probe Request received!"); print fmt(" Management Frame Header:"); print fmt(" Duration: %d", hdr$duration ); print fmt(" Destination Address: %m", hdr$da); print fmt(" Source Address: %m", hdr$sa); print fmt(" BSSID: %m", hdr$bssid ); print fmt(" Fragment Number: %d", hdr$fragn ); print fmt(" Sequence Number: %d", hdr$seqn); print fmt(" Management Frame Body:"); print fmt(" SSID: %s", c$ssid); print fmt(" END POLICY "); } Darüber hinaus können auch auf Policy-Ebene neue, benutzerdefinierte Ereignisse definiert werden. Hierfür genügt die Angabe eines entsprechenden Event Handlers: //Auszug aus policy/wireless.bro type access_point_desc : record { bssid: mac; ssid: string; } global access_points : table [ mac] of access_point_desc ; event wlan_new_ap ( ap: access_point_desc ) { print fmt(" New Access Point with BSSID (% m) and name (% s) found!",ap$bssid,ap$ssid); } event wlan_beacon (c: ieee80211_beacon ) { print fmt(" Beacon Frame received!"); if ( c$hdr$bssid in access_points ) { print " Beacon belongs to existing AP" } else { local d: access_point_desc ; d$bssid = c$hdr$bssid ; d$ssid = c$ssid; access_points [ c$hdr$bssid ] = d; event wlan_new_ap (d); } } Die Datenstruktur ieee80211_beacon ist wie folgt definiert: 51

52 //Auszug aus policy/bro.init: type ieee80211_mgmt_frame_hdr : record { fc: ieee80211_frame_control ; duration: count; da: mac; sa: mac; bssid: mac; fragn: count; seqn: count; }; type ieee80211_beacon : record { hdr: ieee80211_mgmt_frame_hdr ; beacon_interval : count; ssid: string; rates: ieee80211_rates_list ; }; In der Datei policy/wireless.bro werden nun die Event Handler für alle neuen Ereignisse definiert. Die zugehörigen Datenstrukturen werden hingegen in der Datei policy/bro.init definiert. Damit ist die Erweiterung von Bro abgeschlossen. 52

53 5 Evaluierung Nachdem im vorangegangen Kapitel die notwendigen Erweiterungen von Bro beschrieben wurden, soll nun geprüft werden, ob die genannten Änderungen dazu geeignet sind, Angriffe auf drahtlose Netzwerke zu erkennen. In der ersten Hälfte dieses Kapitels werden dazu drei konkrete Angriffe näher untersucht. Das Ziel ist, zunächst einmal geeignete Strategien zur Erkennung der Angriffe zu identifizieren, um dann in einem weiteren Schritt konkrete Policy-Skripte zu formulieren. In der zweiten Hälfte dieses Kapitels soll dann anhand eines praktischen Versuches getestet werden, ob die neu entwickelten Policy-Skripte die hier beschriebenen Angriffe tatsächlich erkennen können. 5.1 Definition einer Policy Beispiel 1: Erkennen von Rogue Access Points In Abschnitt 2.1 wurde bereits auf die Gefahren im Zusammenhang mit unbekannten drahtlosen Netzwerken, insbesondere nicht autorisierten Access Points, hingewiesen. Darüber hinaus wurde in ein Angriff vorgestellt, bei dem die Existenz eines autorisierten Access Points vorgetäuscht wurde, um damit unbedachte Benutzer zur Preisgabe von vertraulichen Informationen zu verleiten. Strategie Ein erster Schritt zur Erkennung dieser Art von Bedrohungen ist die Identifizierung und Klassifizierung aller in Reichweite befindlichen Access Points. Hierbei ist mindestens zwischen autorisierten (trusted) und nicht autorisierten (rogue) Access Points zu unterscheiden. Dieser Vorgang wird in der Literatur auch als Rogue Detection bezeichnet. Eine Möglichkeit zur Erkennung von nicht autorisierten Access Points ist der Einsatz so genannter White Lists, in denen der Administrator sämtliche von ihm verwalteten Geräte mit Netzwerknamen (SSID), MAC-Adresse und dem Kanal, auf dem sie normalerweise arbeiten, angibt [11, 39]. Das System kann somit neu erkannte Access 53

54 Points mit den Einträgen in dieser Liste vergleichen und jeden nicht bekannten AP automatisch als rogue klassifizieren. Der Vorteil dieser Lösung liegt in ihrer Einfachheit. Allerdings kann der notwendige Verwaltungsaufwand in größeren WLANs mit bis zu hundert Access Points diesen Vorteil schnell aufwiegen. Nichtsdestotrotz wird diese Technik auch in aktuellen Lösungen verwendet, meist verbunden mit der Möglichkeit einer automatischen Erstellung eines Inventars an Access Points. Leider unterscheidet diese Lösung nicht zwischen unbekannten, jedoch harmlosen Access Points angrenzender Wireless LANs und tatsächlichen Angreifern. Eine zusätzliche Liste für benachbarte Access Points schafft jedoch Abhilfe. Damit können die Access Points angrenzender WLANs - sobald sie einmal identifiziert wurden - dem überwachenden System bekannt gemacht werden. Dies hat zur Folge, dass in Zukunft das bloße Vorhandensein dieser AP nicht als Bedrohung bewertet wird, jedoch trotzdem eine Warnung generiert wird, wenn es zu unerwünschten Verbindungen mit diesen AP kommt. Policy-Skript Das Kernstück der zu entwickelnden Policy ist die bereits erwähnte White-List. Dabei handelt es sich um die Zusammenstellung aller von dem System als vertrauenswürdig einzustufenden Access Points. Dazu muss jedoch zunächst eine geeignete Datenstruktur zur Speicherung der pro Access Point relevanten Informationen definiert werden. Hier bietet sich die Verwendung eines record an. Damit lässt sich ein AP wie folgt beschreiben: type access_point : record { ssid: mac; sa: mac; channel: count; }; Das Feld ssid speichert den Netzwerknamen, sa steht für die MAC-Adresse des Access Points. Bei mac handelt es sich um den in Kapitel 4 hinzugefügten Datentyp zur Speicherung von MAC-Adressen. Für die Definition der Liste mit den autorisierten Access Points empfiehlt sich die Verwendung des Datentyps set. Der Vorteil von set besteht darin, dass jedes Element implizit einen Hash-Schlüssel darstellt. Damit lässt sich dann später sehr einfach entscheiden, ob eine bestimmte Kombination aus SSID, MAC-Adresse und Kanal zu einem autorisierten AP gehört oder nicht. Die Menge der autorisierten Access Points lässt sich somit wie folgt definieren: global trusted_ap : set[ access_point ] = { [ $ssid = "wilma", 54

55 $sa = 00:11:22:33:44:55, $channel = 11 ], [ $ssid = "fred", $sa = 55:55:55:55:55:55, $channel = 6 ], }; Auf diese Weise lässt sich eine Datenbasis anlegen, mit der später alle im Netzwerk identifizierten Access Points verglichen werden sollen. Doch zunächst stellt sich die Frage, wie die im Netzwerk befindlichen APs überhaupt erkannt werden können. Einen ersten Ansatzpunkt bieten die im Zusammenhang mit der Netzwerkerkennung auftretenden Beacon-Frames sowie Probe Responses. Diese Nachrichten enthalten alle notwendigen Daten zur Identifizierung eines Access Points. In Kapitel 4 wurden für diese Frame-Typen bereits entsprechende Datentypen und Ereignisse definiert: type ieee80211_beacon : record { hdr: ieee80211_mgmt_frame_hdr ; beacon_interval : count; capabilities : count; ssid: string; channel: count; }; global wlan_beacon : event(c: ieee80211_beacon, channel: count); Durch Hinzufügen der entsprechenden Event-Handler für die Ereignisse wlan_beacon und wlan_probe_resp kann nun beim Eintreffen von Nachrichten dieses Typs eine entsprechende Verarbeitung stattfinden. Hier ein erster Ansatz: event wlan_beacon (c: ieee80211_beacon, channel: count) { local ap: access_point ; ap$ssid = c$ssid; ap$sa = c$hdr$sa ; ap$channel = c$channel ; } if (ap!in trusted_ap ) { print "!! Rogue Access Point erkannt!!"; } Diese Lösung funktioniert schon recht gut. Es werden zuverlässig alle Access Points gemeldet, bei denen die Kombination aus SSID, MAC-Adresse und Kanal nicht explizit als vertrauenswürdig definiert wurde. Anhand des verwendeten Kanals lassen sich auch Access Points erkennen, die SSID- oder MAC-Spoofing einsetzen. Allerdings wird bei der bisherigen Lösung bei jedem Eintreffen eines Beacons eine entsprechende Nachricht generiert. Das ist nicht wirklich sinnvoll, da sich der Inhalt der Beacons in der Regel für einen Access Point nicht ändert. 55

56 Dieses Problem lässt sich mit einer zweiten Liste beheben, in der die bisher identifizierten Access Points gespeichert werden. Das Ganze sieht dann so aus: global known_ap: set[ access_point ]; event wlan_beacon (c: ieee80211_beacon, channel: count) { local ap: access_point ; ap$ssid = c$ssid; ap$sa = c$hdr$sa ; ap$channel = c$channel ; } if (ap!in known_ap) { if (ap!in trusted_ap ) { print "!! Rogue Access Point erkannt!!"; } add known_ap [ ap]; } Jetzt wird nur noch bei tatsächlich neu erkannten Access Points eine entsprechende Meldung ausgegeben. Damit existiert nun ein einfaches Policy-Skript zur Erkennung nicht autorisierter Access Points, wobei noch Raum für Erweiterungen bleibt Beispiel 2: Erkennen von DoS-Angriffen Als nächstes soll ein Policy-Skript zur Erkennung von DoS-Angriffen entwickelt werden. Stellvertretend für eine ganze Klasse ähnlicher Angriffe soll hier speziell das Authentication-Flooding untersucht werden. Hierbei handelt es sich um einen Angriff gegen einen Access Point. Bei dieser Methode versendet ein Angreifer in schneller Folge Authentication Requests mit wechselndem Absender. Der zuständige Access Point ist ab einem gewissen Punkt ausschließlich damit beschäftigt, die vermeintlichen Verbindungsanfragen zu bearbeiten. Während dieser Zeit ist er für andere Stationen nicht erreichbar. Strategie Wichtigstes Merkmal von Authentication-Flooding ist die außergewöhnlich hohe Anzahl binnen kürzester Zeit versendeter Management-Frames. Während es in einem gut ausgelasteten WLAN nichts Ungewöhnliches ist, wenn innerhalb weniger Sekunden zehn, fünfzehn oder auch zwanzig Verbindungsanfragen auftreten, so werden bei einem Flooding-Angriff leicht mehr als hundert Frames in der gleichen Zeitspanne verschickt. 56

57 Ein weiteres Indiz für ein gerade stattfindendes Authentication-Flooding sind die verwendeten Absender-Adressen. Da diese oft zufällig generiert werden, kommt es häufig vor, dass sich unter ihnen auch ungültige, d.h. keinem Hersteller zugeordnete, MAC- Adressen befinden. Nicht zuletzt kann auch die ungewöhnlich hohe Anzahl vermeintlicher Stationen ein Hinweis sein. Eine geeignete Strategie zur Erkennung solcher Angriffe besteht darin, die Frequenz, d.h. Entstehungsrate, bestimmter Management-Frames zu überwachen und bei Überschreiten eines definierten Schwellwertes eine entsprechende Warnung auszugeben. Darüber hinaus sollte geprüft werden, ob es sich bei den verwendeten Absender-Adressen um gültige MAC-Adressen handelt. Policy-Skript Die Häufigkeit des Auftretens bestimmter Nachrichten innerhalb eines bestimmten Zeitfensters lässt sich in Bro dadurch bestimmen, dass in regelmäßigen Abständen ein Kontroll-Ereignis stattfindet bei dem geprüft wird, wie viele neue Nachrichten des jeweiligen Typs seit der letzten Kontrolle hinzugekommen sind. Aus diesem Wert lässt sich die durchschnittliche Entstehungsrate solcher Nachrichten näherungsweise bestimmen. Um also Authentication-Flooding zu bestimmen, könnte ein entsprechendes Policy-Skript wie folgt formuliert werden: global flooding_interval : interval = 10 sec; global flood_counter : count = 0; global flood_threshold : count = 100; event wlan_check_flooding () { if ( flood_couter > flood_threshold ) { print "!! Möglicher Flooding - Angriff erkannt!!"; } flood_counter = 0; } schedule flooding_interval { wlan_check_flooding () }; event wlan_auth (c: ieee80211_auth, channel: count) { flood_counter = flood_counter + 1; } event bro_init () { schedule flooding_interval { wlan_check_flooding () }; } Wie hieraus zu erkennen ist, wird für jedes empfangene Authenticate-Frame ein Zähler (flood_counter) um den Wert eins erhöht. Mittels schedule wird erreicht, dass das Kontroll-Ereignis in Abständen von flooding_interval automatisch aufgerufen wird. Dabei wird der aktuelle Zählerstand mit einem Schwellwert (flooding_threshold) verglichen und eine entsprechende Warnung ausgegeben, wenn dieser überschritten 57

58 wurde. Anschließend wird der Zähler auf seinen Anfangswert zurückgesetzt und der Vorgang wiederholt sich. Die Schwierigkeit besteht allerdings darin, einen optimalen Schwellwert zu finden. Ist er zu niedrig, so generiert das System möglicherweise zu viele Fehlalarme. Ist er hingegen zu hoch, kann es sein, dass das System einen Angriff übersieht. Ebenso schwierig ist die Wahl eines geeigneten Intervalls. Dieses darf auf der einen Seite nicht zu lang sein, da sonst bei nur kurz andauernden Flooding-Angriffen der Schwellwert nicht erreicht würde. Auf der anderen Seite sollte das Intervall aber auch nicht zu kurz sein, da jeder Aufruf des Events kostbare Rechenzeit in Anspruch nimmt Beispiel 3: Erkennen von Man-In-The-Middle Als drittes und letztes Beispiel soll ein typischer Man-In-The-Middle-Angriff betrachtet werden. Das besondere an diesem Angriff ist, dass er verschiedene der bisher vorgestellten Techniken kombiniert, um sich unbemerkt zwischen zwei Kommunikationspartner zu positionieren. Um zu verstehen, welche konkreten Schritte bei Man-In-The-Middle notwendig sind, soll der Angriff zunächst aus Sicht des Angreifers betrachtet werden. Anschließend soll untersucht werden, wie derselbe Vorgang aus Sicht des Monitors abläuft. Darauf basierend soll schließlich eine mögliche Strategie zur Erkennung von Man-In-The- Middle entwickelt und in ein entsprechendes Policy-Skript gegossen werden. Man-In-The-Middle aus Sicht des Angreifers Um einen Man-In-The-Middle-Angriff durchführen zu können, benötigt ein Angreifer ein Notebook mit zwei WLAN-Karten, von denen mindestens eine den so genannten Master Mode unterstützt. Unter der Annahme, dass der legitime Access Point auf Kanal 3 sendet, lässt sich ein konkreter Angriff wie folgt durchführen: 1. Der Angreifer konfiguriert eine der beiden WLAN-Karten mit der SSID und MAC-Adresse des echten Access Points. Anschließend versetzt er die Karte in den Master Mode oder auch AP Mode und beginnt auf Kanal 11 zu senden. 2. Mit der zweiten Karte versendet der Angreifer eine gefälschte Deauthenticate- Nachricht an eine beliebige Station auf Kanal 3. Dabei verwendet er als Absender die MAC-Adresse des echten Access Points. 3. Die betroffene Station geht davon aus, dass der Access Point auf Kanal 3 keine weiteren Verbindungen entgegennehmen kann und startet eine Suche nach alternativen Access Points. Dabei findet sie auch den AP des Angreifers auf Kanal 11, welcher über einen gültigen Netzwerknamen zu verfügen scheint. 58

59 4. Sobald sich die Station mit dem AP des Angreifers auf Kanal 11 verbunden hat, konfiguriert dieser die zweite WLAN-Karte mit der MAC-Adresse der Station und verbindet an deren Stelle mit dem echten AP auf Kanal Anschließend ist der Angreifer in der Lage, ankommende Nachrichten der Station an den AP weiterzuleiten und umgekehrt. Dieser Vorgang läuft vollkommen transparent ab, d.h. für beide Gegenstellen sieht es so aus, als würden sie direkt miteinander kommunizieren. Durch diesen Angriff befindet sich der Angreifer nun in einer Position, in der er die Kommunikation der beiden Gegenstellen nach Belieben manipulieren kann. Insbesondere ist er nun auch in der Lage, eine mögliche Verschlüsselung auf Anwendungsebene (z.b. SSL) zu umgehen. Hierfür sind zahlreiche Fälle aus der Literatur bekannt. Man-In-The-Middle aus Sicht des Monitor Die Betrachtung des Angriffs aus Sicht des Monitors ist ein Schritt in Richtung einer möglichen Strategie zur Erkennung solcher Angriffe. Dazu wurde der Angriff mit Hilfe des Tools Ethereal aufgezeichnet. Aus Sicht des Monitors lässt sich damit folgender Ablauf beobachten: 1. Der rechtmäßige Access Point sendet regelmäßig Beacon-Frames auf Kanal 3. Zu dieser Zeit ist auf Kanal 11 noch keine Aktivität festzustellen. 2. Dann tauchen auf Kanal 11 plötzlich Beacon-Frames eines bisher unbekannten Access Points auf. Eine Überprüfung ergibt, dass es sich hierbei um einen nicht autorisierten AP handelt. 3. Kurz darauf erhält eine Station auf Kanal 3 eine Deauthenticate-Nachricht, die vom rechtmäßigen AP zu kommen scheint. 4. Als nächstes kann beobachtet werden, wie die Station sowohl auf Kanal 3 als auch auf Kanal 11 Probe Requests versendet, die durch die Access Points mit entsprechenden Probe Responses beantwortet werden. 5. Wenig später verbindet sich die Station mit dem unbekannten AP auf Kanal 11. Dies lässt sich anhand der entsprechenden Association Response nachweisen. 6. Fast gleichzeitig scheint sich die Station allerdings auch mit dem AP auf Kanal 3 zu verbinden. Schließlich sieht es aus Sicht des Monitors so aus, als ob die Station zur selben Zeit mit Access Points verbunden ist, was normalerweise nicht vorkommen sollte. 59

60 Strategie Bei der Betrachtung der zuletzt beschriebenen Abläufe lassen sich verschiedene Ereignisse identifizieren, deren gleichzeitiges Auftreten ein mögliches Indiz für eine gerade stattfindende Man-In-The-Middle-Attacke ist. Dabei handelt es sich konkret um die folgenden Ereignisse: das Vorhandensein eines nicht autorisierten Access Points der Verbindungsaufbau einer Station mit dem nicht autorisierten AP die Tatsache, dass eine Station gleichzeitig mit zwei verschiedenen Access Points verbunden ist, von denen einer zuvor als nicht autorisierter AP identifiziert wurde Eine weitere Möglichkeit ist die Erkennung des eingesetzten MAC-Spoofings, wie es zum Beispiel beim Versand der gefälschten Deauthenticate-Nachricht eingesetzt wird. Die hierfür notwendige Analyse der Sequenznummern, wie sie zum Beispiel in [19] ausführlich beschrieben wird, ist jedoch zu aufwendig und würde den Rahmen der Arbeit sprengen. Daher soll sich auf die o.g. Ereignisse beschränkt werden. Die Möglichkeiten zur Erkennung nicht autorisierter Access Points wurden bereits in Abschnitt beschrieben. Des Weiteren lässt sich ein Verbindungsaufbau einer Station anhand der zugehörigen Association-Nachrichten erkennen. Um jedoch feststellen zu können, ob eine Station bereits mit einem AP verbunden ist, müssen die Verbindungen aller Stationen in geeigneter Form festgehalten werden. Hierzu bietet sich die Verwendung einer dynamischen Liste an, in der für jede Station der aktuelle Verbindungsstatus gespeichert wird. Dazu sind die im Zusammenhang mit Verbindungsaufund abbau auftretenden Nachrichten zu überwachen. Policy-Skript Für die Identifizierung nicht autorisierter Access Points wurde bereits ein entsprechendes Policy-Skript entwickelt. Darin wurden neu erkannte APs anhand der in den Beacon-Frames übermittelten Angaben über SSID, MAC-Adresse und verwendete Kanalnummer klassifiziert. Bei einem Verbindungsaufbau sind jedoch nur die MAC-Adresse eines APs sowie implizit der verwendete Kanal bekannt. Damit ist jedoch ein Vergleich mit der so genannten White-List nicht möglich, da hierzu die Angabe der SSID ebenfalls notwendig ist. Aus diesem Grund ist die ursprüngliche Policy wie folgt zu erweitern: global rogue_ap: set[mac,count ]; event wlan_beacon (c: ieee80211_beacon, channel: count) { 60

61 local ap: access_point ; ap$ssid = c$ssid; ap$sa = c$hdr$sa ; ap$channel = c$channel ; } if (ap!in known_ap) { if (ap!in trusted_ap ) { add rogue_ap [ ap$sa, ap$channel ]; } add known_ap [ ap]; } Damit wird für jeden nicht autorisierten Access Point ein Tupel bestehend aus MAC- Adresse und Kanalnummer zur Liste der nicht autorisierten Access Points (rogue_ap) hinzugefügt. Mit Hilfe dieser Information lässt sich nun der Verbindungsaufbau zu einem nicht autorisierten AP wie folgt erkennen: type ieee80211_mgmt_frame_hdr : record { da: mac; sa: mac; bssid: mac; }; type ieee80211_assoc_resp : record { hdr: ieee80211_mgmt_frame_hdr ; status_code : count; }; event wlan_assoc_resp (c: ieee80211_assoc_resp, channel: count) { if ( [ c$hdr$sa, channel] in rogue_ap ) { print "!! Verbindung mit nicht autorisiertem AP erkannt!!" } } Bleibt noch die Frage, wie erkannt werden kann, wenn sich eine Station mit zwei Access Points verbindet. Hierzu soll analog zu den bisherigen Lösungen eine weitere Liste implementiert werden, welche die aktuell bestehenden Verbindungen der einzelnen Clients festhält. Anders als bisher wird dazu jedoch der Datentyp table verwendet, da hier ein direkter Zugriff auf die einzelnen Elemente erforderlich ist. Eine geeignete Datenstruktur lässt sich wie folgt definieren: type connection : record { ap: mac; sta: mac; channel: count; }; global connections : table[ mac] of connection ; 61

62 Dabei wird die MAC-Adresse einer Station als Index für connections verwendet. Damit kann später direkt auf das jeweilige Element zugegriffen werden. Als Nächstes sollen die Ereignisse betrachtet werden, welche den Inhalt der Tabelle verändern. Während die Ereignisse Association Request und Association Response den Beginn einer Verbindung markieren, zeigen die Ereignisse Disassociate und Deauthenticate das Ende einer Verbindung an. Darauf aufbauend lässt sich folgender Algorithmus implementieren: global connections : table[ mac] of connection ; event wlan_assoc_resp (c: ieee80211_assoc_resp, channel: count) { local conn: connection ; conn$ap = c$hdr$sa; conn$sta = c$hdr$da; conn$channel = channel; } if ( conn$sta! in connections ) { connections [ conn$sta] = conn; } event wlan_disassoc (c: ieee80211_disassoc, channel: count) { } if ( c$hdr$sa == c$hdr$bssid ) { print "!! AP hat Verbindung beendet!!"; delete connections [ c$hdr$da ]; } else { print "!! Station hat Verbindung beendet!!"; delete connections [ c$hdr$sa ]; } Unter der Voraussetzung, dass der Monitor alle Association Responses bzw. Disassociates empfängt, kann der jeweilige Verbindungsstatus einer Station direkt mittels connections[station] abgelesen werden. Nachdem somit die notwendigen Werkzeuge zur Verfügung stehen, soll zum Abschluss eine mögliche Policy zur Erkennung von Man-In-The-Middle-Angriffen vorgestellt werden. global connections : table[ mac] of connection ; event wlan_assoc_resp (c: ieee80211_assoc_resp, channel: count) { local new: connection ; new$ap = c$hdr$sa; new$sta = c$hdr$da; new$channel = channel; if ( new$sta in connections ) { 62

63 } } local old = connections [ new$sta ]; if ( ( new$ap == old$ap) && ( new$channel == old$channel ) ) { print "!! Station hat sich erneut mit AP verbunden!!"; } else { print "!! Station ist mit zwei AP verbunden!!"; print "!! Möglicher Man -In - The - Middle - Angriff!!"; } Zusätzlich kann an dieser Stelle noch geprüft werden, ob es sich bei einem der beiden Access Points um einen nicht autorisierten AP handelt. Damit ließe sich die Treffergenauigkeit noch verbessern. 5.2 Vorbereitungen Nachdem die Betrachtung der Beispiel-Angriffe abgeschlossen ist, sollen nun die im vorangegangenen Abschnitt entwickelten Policy-Skripte in einem praktischen Versuch auf ihre Tauglichkeit hin überprüft werden Versuchsaufbau Bei diesem Versuch befinden sich Angreifer, Opfer und Monitor zusammen in einem Raum. Der Access Point befindet sich in einem angrenzenden Raum. Dadurch wird erreicht, dass die angreifende Station das stärkere Signal aussendet. Als Access Point kommt ein D-Link DI-624+ zum Einsatz, der sowohl b als auch g unterstützt. Das Gerät wird wie folgt konfiguriert: Netzwerkname: marvin Kanal: 11 Verschlüsselung: Authentifizierung: keine open system Die Konfiguration der restlichen Systeme ist in Tabelle 5.1 abgebildet. 63

64 System Angreifer Monitor Opfer Herkömmlicher PC mit PCMCIA-PCI-Adapter Notebook mit zwei PC-Card-Steckplätzen Notebook mit PC-Card-Steckplatz WLAN-Hardware Netgear WG311 mit Atheros-Chipsatz (802.11g) Netgear WAG511 mit Atheros-Chipsatz (802.11a+g) Netgear MA521 mit Realtek-Chipsatz (802.11b) Linksys WPC11 mit PRISM-Chipsatz (802.11b) Netgear MA521 mit Realtek-Chipsatz (802.11b) Betriebssystem Debian-GNU/Linux 3.1 (Sarge) mit Kernel Debian-GNU/Linux 3.1 (Sarge) mit Kernel Windows XP Professional mit Service Pack 2 Treiber Madwifi-Treiber vom [52] Madwifi-Treiber vom [52] Mitgelieferte Windows-Treiber der Karten-Hersteller Hostap-Treiber [50] Airjack-Treiber 0.6.6alpha [42] Treiber für RTL8180-Cjipsatz [54] Tabelle 5.1: Versuchsanordnung 64

65 5.2.2 Installation der benötigten Treiber Zum Thema Wireless LAN unter Linux existieren im Internet zahlreiche Tutorials [51]. Daher beschränkt sich diese Arbeit auf die Nennung der für diesen Versuch notwendigen Treiber und geht nicht näher auf die Einzelheiten während der Installation ein. Um die Netgear-Karten WAG511 und WG311 unter Linux zu nutzen, werden die MadWifi-Treiber in der Version vom verwendet [52]. Einzelheiten zur Installation werden in [53] behandelt. Zur Durchführung der Angriffe wird die Linksys-Karte abwechselnd mit zwei verschiedenen Treibern verwendet. Dabei handelt es sich zum einen um den HostAP-Treiber in der Version vom [50]. Alternativ wird der Airjack-Treiber verwendet, der zusammen mit der gleichnamigen Software aus dem Internet herunter geladen werden kann [42]. Für die Netgear MA521 existiert seit kurzem ebenfalls ein Treiber [54]. Dieser befindet sich zwar noch im frühen Beta-Stadium, allerdings funktionierte der für dieser Versuch benötigte Monitor Mode bereits zuverlässig. Hinweise zur Installation des Treibers sind in dem zugehörigen Readme-File enthalten Installation von Bro Als Nächstes muss Bro auf dem als Monitor vorgesehenen Rechner installiert werden. Dabei ist natürlich die auf der beliegenden CD-ROM befindliche Version zu verwenden. Nachdem das Quelltext-Archiv entpackt wurde, müssen noch einige Dateien generiert werden. Anschließend kann das Paket übersetzt werden: $./ configure -- enable - selectloop $./ make $./ make install - brolite Der Schalter --enable-selectloop bewirkt, dass Bro beim Empfang von Paketen durch mehrere Netzwerkschnittstellen nicht blockiert, sobald eines der überwachten Netzwerke eine zu geringe Auslastung hat. Der letzte Aufruf bewirkt schließlich, dass Bro nach /usr/local/bro/ installiert wird. Nach erfolgter Installation sind noch einige Anpassungen notwendig. Unter anderem sind die Netzwerkschnittstellen anzugeben, über die Bro Pakete empfangen soll. # /usr/local/bro/etc/bro.cfg:... BRO_CAPTURE_INTERFACE =" ath0 wlan0"... 65

66 Um im weiteren Verlauf einen Man-In-The-Middle-Angriff erkennen zu können, soll Bro zwei drahtlose Netzwerkschnittstellen überwachen, von denen jede auf einen anderen Kanal eingestellt ist. Des Weiteren muss der Debug-Modus von Bro aktiviert werden, da die Ausgabe der für Wireless LAN interessanten Informationen derzeit nur über die Konsole möglich ist. # /usr/local/bro/etc/bro.rc:... DEBUG =1... Schließlich sind noch die von Bro standardmäßig geladenen Policy-Skripte zu deaktivieren, um einen reibungslosen Ablauf des Versuches zu ermöglichen. # /usr/local/bro/site/<rechnername >. bro:... brolite... Damit ist die Konfiguration von Bro abgeschlossen. 5.3 Durchführung Bevor die Angriffe durchgeführt werden, muss zunächst der Monitor gestartet werden. Zudem sind die verwendeten Netzwerkschnittstellen zu konfigurieren. $ iwconfig ath0 mode monitor channel 11 $ iwconfig wlan0 mode monitor channel 3 $ ifconfig ath0 up $ ifconfig wlan0 up $ /usr/local/bro/etc/bro.rc start Damit wurde der Monitor erfolgreich eingerichtet und ist nun bereit, die im Folgenden durchgeführten Angriffe zu erkennen Versuch 1: Rogue Access Point Für diesen Versuch soll das Tool airsnarf verwendet werden. Dabei handelt es sich um ein Perl-Skript, das einen normalen Linux-PC in einen funktionstüchtigen Access Point verwandelt. Voraussetzung hierfür ist, dass die verwendete WLAN-Karte den so genannten Master Mode unterstützt. Des Weiteren müssen auf dem System ein DHCP-Server und ein WWW-Server installiert sein. Damit soll den Benutzern das Vorhandensein eines Intranets vorgetäuscht werden. Doch dazu später mehr. 66

67 Nachdem das Archiv in ein beliebiges Verzeichnis entpackt wurde, sind einige Anpassungen vorzunehmen. In der Regel müssen in dem Skript einige Systempfade sowie die Kommandos zum Starten von DHCP- und WWW-Server an die jeweiligen Gegebenheiten angepasst werden. Darüber hinaus sind noch einige Angaben zur Netzwerk-Konfiguration erforderlich. Dazu gehören unter anderem das zu benutzende Interface, die Netzwerkadresse sowie der zu verwendende Netzwerkname (SSID). Anschließend kann mit der Durchführung des Angriffes begonnen werden. Dazu wird zunächst die Linksys-Karte mit dem HostAP-Treiber initialisiert. Hierbei werden auch der Netzwerkname und der gewünschte Kanal eingestellt. Optional kann auch die MAC-Adresse der Karte geändert werden. Danach wird der Angriff per Kommandozeile wie folgt gestartet: $./ iwconfig wlan0 channel 3 $./ airsnarf Airsnarf - A rogue AP setup utility. 0.2 The Shmoo Group Creating dhcpd. conf... Done. Building the captive portal... Done. Setting the wireless parameters... Done. Setting the ip address and default route... Done. Stopping DHCP server: dhcpd3. Starting DHCP server: dhcpd3. Forcing reload of web server: Apache2. Setting up firewall to redirect DNS... Done. Starting local DNS resolver... creating TCP socket... done. creating UDP socket... done. waiting for connections... Das Ergebnis lässt sich auf dem Windows-Rechner anhand der mitgelieferten Konfigurationssoftware des Karten-Herstellers beobachten (siehe Abb. 5.1). Dabei handelt es sich bei dem Access Point auf Kanal 3 um den soeben hinzugefügten. Wie außerdem zu erkennen ist, hat sich der Windows-Rechner automatisch mit dem neuen Access Point verbunden. Der Grund hierfür ist, dass beide Access Points den gleichen Netzwerknamen verwenden. In einem solchen Fall verbindet sich eine Station in der Regel automatisch mit dem Access Point, der die höhere Signalstärke aufweist. Doch das ist noch nicht alles. Das Skript sorgt außerdem dafür, dass sämtliche DNS- Anfragen des Windows-Rechners mit der IP-Adresse des Angreifers beantwortet werden. Welche Konsequenzen dies hat, zeigt sich, sobald an dem Windows-Rechner ein Browser gestartet und eine beliebige Internet-Adresse eingegeben wird. Das Resultat einer solchen Anfrage ist in Abb.5.2 zu sehen. 67

68 Abbildung 5.1: Windows-Rechner verbindet sich mit Rogue AP Abbildung 5.2: Ergebnis einer Umleitung von DNS-Anfragen Statt der erwarteten Internet-Seite, bekommt der Benutzer ein Formular angezeigt, das ihn auffordert, Benutzername und Passwort einzugeben. Prinzipiell könnte an dieser Stelle jede beliebige HTML-Seite angezeigt werden. Im Extremfall ließe sich sogar eine komplette Web-Präsenz vortäuschen oder aber die Einstiegsseite eines Online- Banking-Portals Versuch 2: DoS-Angriff Für diesen Versuch soll die Software void11 eingesetzt werden, um eine DoS-Attacke gegen einen Access Point durchzuführen. Das Paket besteht aus einer C-Bibliothek zum Versenden gefälschter Management-Frames sowie aus einer Beispiel-Anwendung, 68

69 mit der sich verschiedene DoS-Angriffe durchführen lassen. Nach Übersetzung der Software muss nur noch die Bibliothek nach /usr/lib/ kopiert werden. Damit ist die Konfiguration abgeschlossen und es kann mit dem Angriff begonnen werden. Auch hierfür werden wieder die HostAP-Treiber benötigt. Zudem ist die optionale Access-Point-Unterstützung zu aktivieren. Anschließend lässt sich beispielsweise ein Authentication-Flooding-Angriff wie folgt starten: $./ iwconfig wlan0 mode master channel 11 $./ iwpriv wlan0 hostapd 1 $./ void11_penetration - t 2 - S marvin - D - B 00:11:95: XX: XX: XX - m 50 - d 1000 wlan0 Opening raw packet socket for ifindex 13 interface : wlan0ap ssid : marvin delay : 1000 usec auto_flood : disabled type : auth_flooding bssid : 00:11:95: XX: XX: XX Als Parameter erwartet das Tool unter anderem SSID und die MAC-Adresse des Access Points, gegen den der Angriff gerichtet ist. Bemerkung In der Regel sollte es nicht länger als eine Minute dauern, bis der Access Point seinen Dienst einstellt. Allerdings sind nicht alle Access Points gleichermaßen anfällig. So gelang es während der Durchführung des konkreten Versuches nur ein einziges Mal, den betroffenen Access Point soweit zu beeinflussen, dass er keine weiteren Verbindungen aufbauen konnte Versuch 3: Man-In-The-Middle Als letztes soll ein Man-In-The-Middle-Angriff durchgeführt werden. Auch hierfür existiert mit monkey_jack bereits ein geeignetes Tool. Dabei handelt es sich um eine Beispiel-Anwendung des ebenfalls benötigten Airjack-Treibers. Beide können frei aus dem Internet herunter geladen werden. Des Weiteren werden bei diesem Angriff zwei WLAN-Karten benötigt, von denen die eine durch den Airjack-Treiber angesteuert wird. Je nachdem, welche Treiber mit der zweiten Karte verwendet werden, sind möglicherweise Änderungen an der Beispiel- Anwendung erforderlich. So musste das Tool zunächst angepasst werden, bevor es mit den eingesetzten MadWifi-Treibern funktionierte. Die in diesem Versuch verwendete Version von monkey_jack befindet sich auf der beiliegenden CD-ROM. 69

70 Nachdem beide Karten installiert und die entsprechenden Treiber geladen wurden, lässt sich ein Man-In-The-Middle-Angriff wie folgt ausführen: $./ monkey_jack - b 00:11:95: XX: XX: XX - v 00:09:5 B: XX: XX: XX - c 11 - C 3 - I ath0 - e marvin Starting Monkey in the Middle Attack: victim: 00:09:5b:xx:xx:xx bssid: 00:11:95: xx: xx: xx configuring airjack device... done. forcing ourselves in the middle... done. configuring lucent card... done. layer 1 insertion complete. Als Parameter erwartet das Tool die MAC-Adressen von Access Point und betroffener Station, sowie den aktuellen und den zu verwendenden Kanal. Anschließend sendet die Software ein oder mehrere Deauthenticate-Nachrichten an die betroffene Station, womit diese gezwungen ist, sich erneut zu verbinden. Gleichzeitig gibt sich das Tool auf einem zweiten Kanal als legitimer Access Point aus, indem es sowohl den Netzwerknamen als auch die MAC-Adresse des echten AP übernimmt. Sobald sich die Station mit dem Angreifer verbunden hat, ändert die Software die MAC-Adresse der zweiten WLAN-Karte entsprechend der Einstellungen der echten Station und verbindet sich auf dem ursprünglichen Kanal mit dem echten Access Point. Wie schon zuvor lässt sich das Ganze an dem betroffenen Windows-Rechner mitverfolgen Abb. 5.3 zeigt den Angriff aus Sicht der betroffenen Station. Abbildung 5.3: Eine MITM-Attacke aus Sicht der betroffenen Station 70

71 5.4 Ergebnis der Versuche Wie aus den Abbildungen 5.4 bis 5.6 hervor geht, hat das System alle drei Angriffe identifiziert. Abbildung 5.4: Erkennung des nicht autorisierten Access Points Abbildung 5.5: Erkennung des DoS-Angriffs Abbildung 5.6: Erkennung des Man-In-The-Middle-Angriffs 71

72 6 Zusammenfassung Mittlerweile hat sich ein Markt für so genannte Wireless IDS etabliert und zahlreiche Hersteller bieten kommerzielle Produkte an. Demgegenüber ist die derzeitige Auswahl an frei verfügbaren Wireless IDS außerordentlich gering. Daher wird in dieser Arbeit eine eigene Lösung auf Basis des ursprünglich für den Festnetzbereich entwickelten Bro IDS vorgeschlagen. Um die konkreten Anforderungen an ein Wireless IDS zu identifizieren, wurde eine Übersicht über die bisher bekannten Angriffe zusammengestellt. Außerdem wurden verschiedene Möglichkeiten zu deren Erkennung untersucht. Der Hauptteil der Arbeit befasste sich jedoch mit der Analyse sowie anschließenden Implementierung der notwendigen Erweiterungen von Bro. Dazu wurden zunächst die verschiedenen Konzepte von Bro eingehend untersucht und aufgezeigt, an welchen Stellen Änderungen der Architektur erforderlich sind. Anschließend wurden die verschiedenen Schritte zur Anpassung von Bro für den Einsatz in drahtlosen Netzwerken beschrieben. Den Abschluss der Arbeit bildete ein praktischer Versuch bei dem nachgewiesen werden konnte, dass das entwickelte System prinzipiell in der Lage ist, Angriffe auf drahtlose Netzwerke zu erkennen. Es konnte nicht abschließend geklärt werden, wie die simultane Überwachung aller verfügbaren Kanäle zu realisieren ist. 72

73 A Bedrohungen in drahtlosen Netzwerken Abbildung A.1: Übersicht über die in drahtlosen Netzwerken bekannten Angriffe 73