Plug & Plague Sicherheitsdefizite durch automatische Geräteerkennung

Ordnungsmerkmale

erschienen in: <kes> 2004^#1, Seite 6

Zusammenfassung: Was dem unerfahrenen (Heim-)Anwender helfen soll, entwickelt sich in einer administrierten Windows-Landschaft leicht zur Plage: Die automatische Geräteerkennung und -installation (Plug&Play) birgt etliche Sicherheitsrisiken – und zwar nicht nur in puncto USB.

Autor: Von Peter Scholz, München

Die Problemzonen eines unerlaubten Datentransports nach "draußen" sowie des unerlaubten Einschleusens von Daten durch "mitgebrachte" handliche Massenspeicher sind als Plug&Play-Problem besonders leicht zu erkennen. Der unkontrollierte Einsatz externer USB-Speichermedien (inkl. Digitalkameras), die unter Windows 2000 und XP keine Treiberinstallation benötigen, ist mittlerweile vielerorts als Bedrohung registriert worden – oftmals leider erst nach einem entstandenen Schaden. Es gibt aber im Umfeld der automatischen Geräteerkennung und -installation (dem sog. Plug&Play) noch zahlreiche weitere, weniger bekannte Bedrohungen, die aus Unternehmenssicht einen kurz- oder mittelfristigen Handlungsbedarf schaffen.

Mit spezieller zusätzlicher Verwaltungssoftware (im Bild: DeviceWatch) lassen sich Windows-Schnittstellen per Policy regulieren.

Es empfiehlt sich, vor der Installation oder einer Migration zu Windows 2000/XP die mit dem erweiterten Plug&Play verbundenen Schwachstellen genau zu analysieren und geeignete Schutzmaßnahmen zu ergreifen, vor allem da sich einmal zur Verfügung gestellte Nutzungsmöglichkeiten später nur noch mit größerem Aufwand wieder rückgängig machen lassen.

In Unix-Umgebungen oder unter Windows NT sind zur Installation neuer Hardware bei geeigneter Konfiguration Administratorrechte erforderlich. Windows 2000/XP "erkennt" Geräte hingegen automatisch. Das hat vor allem für den technisch nicht versierten Nutzer positive Effekte, da das Betriebssystem alle notwendigen Installationen automatisch für ihn startet und durchführt. Um die Arbeit für den Endanwender möglichst einfach zu gestalten, sind für sehr viele Geräte und Technologien bereits alle notwendigen Treiber in die Standardinstallation der Betriebssysteme integriert.

In einem Unternehmen hat damit jedoch der Sicherheitsverantwortliche einen wesentlichen Schutzmechanismus verloren, da ein Anwender keine Administratorrechte mehr benötigt, um ein neues Gerät oder eine neue Verbindungstechnik in Betrieb zu nehmen. Wieder einmal stehen die Handhabbarkeit der Systeme und eine einfache Integration von Innovationen den Anforderungen nach einem sicheren Betrieb gegenüber, der auch die notwendige Prüfbarkeit und Revisionssicherheit umfasst – kurz: Plug&Play und Sicherheit vertragen sich nicht.

Unbekannt erkannt

Der Sicherheitsverantwortliche steht zunächst vor einer scheinbar unlösbaren Aufgabe, weil er permanent mit neu auf dem Markt erscheinender Technik konfrontiert wird, die er nicht kennt und für die er keine eigenen Testmöglichkeiten besitzt, aber für (oder gegen) die er dennoch Schutzmechanismen bereitstellen soll. Schützen kann er seine Umgebung aber nur, wenn er prüft, wie sich die Clients mit neuen Geräten verhalten – auch dann, wenn diese nicht gemäß der Benutzeranweisung eingesetzt werden.

Viele Unternehmen gehen heute davon aus, dass sie beispielsweise von Plug&Play-Problemen per IEEE 1394 (Firewire, i.LINK) oder USB nicht betroffen sind, weil sie keine PCs, Workstations oder Notebooks mit einer solchen Schnittstelle einsetzen. Ein Blick in die aktuell am Markt verfügbare Hardware zeigt aber, dass es Konverter für beinahe jede Technik gibt: So kann beispielsweise aus einer Infrarotschnittstelle ohne großen Aufwand ein USB-Port werden, oder aus einem PCMCIA-Einschubplatz eine vollwertige SCSI-Schnittstelle.

Will man eine sichere Client-Konfiguration gewährleisten, so gilt es zuerst, alle nicht benötigten Technologien zu sperren. Bereits dabei treten die ersten Probleme auf: Die Entnahme von Treibern, die standardmäßig im Betriebssystem enthalten sind, erweist sich als kritisch, da zumeist die Systemstabilität leidet. Geräte oder Schnittstellen zu sperren, die im Netzwerk noch nicht verfügbar sind, stellt sich sogar als unmöglich heraus, denn eine Sicherheitspolicy "alle Geräte, welche nicht explizit erlaubt wurden, sind verboten" existiert nicht. Zur Lösung dieser Problematik gibt es aber mittlerweile einige Produkte im Markt (siehe Kasten).

Client-Verfügbarkeit

Der prinzipielle Mechanismus des Plug&Play lässt sich aus Windows nicht mehr entfernen. Sobald das Betriebssystem ein neues Gerät findet, wird automatisch versucht es zu installieren. Ist kein Treiber verfügbar oder hat der Benutzer keine Rechte zur Installation, so sind zwar die primären Sicherheitsrisiken gebannt, die mit dem Einsatz des Geräts verbunden wären, dennoch existieren weitere, nachgelagerte Risiken: Denn fehlerhafte oder abgebrochene Treiberinstallationen, beispielsweise aufgrund mangelnder Benutzerrechte, gefährden die Verfügbarkeit der Clients. Nicht korrekt zu Ende geführte Plug&Play-Aktivitäten destabilisieren PCs, angefangen mit Modifikationen an der Konfiguration anderer Geräte, welche zu aufwändigen Fehlersuchen führen, bis hin zum regelmäßigen Totalabsturz (Blue-Screens), also der vollständigen Unbrauchbarkeit der Client-Installation. Dadurch können Zusatzkosten in signifikanter Höhe in den Bereichen Support und Help-Desk entstehen.

Die Investition in eine zentral kontrollierbare Plug&Play-Lösung amortisiert sich deshalb häufig schon durch reduzierte Support-Kosten und eine höhere Verfügbarkeit. Weder erfolgreiche noch abgebrochene Plug&Play-Installationen lassen sich überdies im Security-Event-Log des Betriebssystems verfolgen – zwei der im Kasten genannten Lösungen korrigieren auch das.

Dienstanweisungen

Viele Unternehmen versuchen die Plug&Play-Problematik auf organisatorische Weise zu lösen, beispielsweise durch eine Dienstanweisung. Natürlich ist die alte Weisheit "technische Lösungen sind organisatorischen vorzuziehen" generell gültig, doch in diesem Fall ist überdies ein besonderer Aspekt zu berücksichtigen: Ein Mitarbeiter kann nur dann zur Durchsetzung der organisatorischen Lösung verpflichtet werden, wenn es auch vollständig in seinem Einflussbereich liegt, ihre Einhaltung zu kontrollieren.

Organisatorische Maßnahmen greifen nur schlecht gegen Plug&Play

Folgendes Szenario beschreibt ein Beispiel, das die Durchsetzbarkeit organisatorischer Anweisungen in Frage stellt: Nehmen wir an, in einem gut ausgelasteten Zug arbeitet jemand an seinem Notebook. In der Schlange, die sich bei der Suche nach Sitzplätzen gebildet hat, befindet sich ein Handybesitzer, der in seiner Sakkotasche ein Mobiltelefon mit aktivierter Infrarotschnittstelle trägt. Bereits bei einem kurzen Verweilen in – aus technischer Sicht – günstiger Position wird das Notebook mit der Installation des Handys beginnen. Sicher ein Versehen, welches dem Notebookbesitzer nicht anzulasten ist...

Durch WLAN, Bluetooth oder ähnliche Technik werden die überbrückbaren Distanzen zudem immer größer, sodass auch die Wahrscheinlichkeit eines unerwünschten Kontakts gerade in "technologischen Ballungszentren" – wie Flughafenaufenthaltsräumen, Bahnhöfen, Zügen und Hotels – deutlich steigt. Dabei ist es zu kurz gegriffen, sich nur auf die (meist noch überschaubare) Hotel-Lobby mit Hotspot und anderen Funknetz-Nutzern zu konzentrieren. Spätestens die Frage, wie gut die Hotelwand seines Zimmers die Bluetooth-Kommunikation abschirmt, kann innerhalb der "organisatorischen Vereinbarung" sicher nicht mehr zu den Mitwirkungspflichten eines Mitarbeiters gerechnet werden.

Basisinstallation

Anwender-Kennungen sollten natürlich nicht über Administrationsprivilegien verfügen. In einem umfassenden Rollout von beispielsweise mehreren tausend Notebooks unter XP steht der Projektleiter dieses Vorhabens damit aber auch vor der Aufgabe, die Erstinstallation automatisiert und mit den Optionen "unattended" beziehungsweise "hands free" durchzuführen. Diese Herausforderung wird häufig zum Drahtseilakt zwischen Sicherheit und Funktionalität. Der Grund dafür liegt in der Hartnäckigkeit, mit der sich Windows 2000/XP gegen die Vorkonfektionierung nicht verfügbarer Hardware wehrt.

Das Problem wird beispielsweise deutlich, wenn man ein Notebook mit zwei PCMCIA-Slots für den Einsatz von drei PCMCIA-Karten – automatisiert – vorbereiten möchte: Es können ja nur zwei Karten in den Slots stecken. Die dritte Karte muss entweder während der Erstinstallation von Hand gewechselt oder später durch den Benutzer eingesteckt werden. Im ersten Fall ist die Installation nicht mehr "unattended" und deshalb deutlich teurer und anfällig für Fehler. Im zweiten Fall benötigt der Benutzer die Rechte zur Installation.

Eine pragmatische Lösung liegt darin, den Installationsprozess in einen eigenen Rechteraum unter Administrationsprivilegien zu legen – leider geht das auf Kosten der Sicherheit, da dann alle Installationen von diesem Privileg profitieren. Eine Lösung hierzu deutet sich im Markt durch die Integration zweier Produkte verschiedener Hersteller an, ist aber bislang nicht verfügbar.

Mobiler Einsatz

Eine weitere Problemstellung folgt aus den flexiblen Einsatzmöglichkeiten eines Notebooks: Viel innovative Technik wie Bluetooth, WLAN, GSM über PCMCIA oder berührungslose Chipkarten beseitigt zwar auf der einen Seite den "Kabelsalat", bringt aber andererseits Sicherheitslücken in das System, da der Benutzer die Kommunikationsverbindungen nicht mehr physisch prüfen kann. Auf der technischen Seite kann man zudem das Abbrechen einer Funkverbindung nicht einmal mit dem Ereignis des "Stecker-Herausziehens" gleichsetzen, da in Funkumgebungen die Roaming-Anforderung zu einer permanenten Suche nach neuen Verbindungsmöglichkeiten führt.

Ein Notebook soll heute so anwenderfreundlich konfiguriert sein, dass man es am angestammten Arbeitsplatz ohne das Lösen von Steckverbindungen aus dem Netzwerkbetrieb entfernen und ohne neu zu booten zur Weiterarbeit im Zug oder Flugzeug in die Aktentasche packen kann. Am Zielort sollte es – wiederum ohne Neustart und Steckverbindungen – im dort vorhandenen Netzwerk über VPN und Internet oder an einem anderen Standort des Unternehmens sofort und uneingeschränkt funktionieren...

Meistens will oder kann der Benutzer auch keine technischen Entscheidungen über den Betriebsmodus (im Netzwerk oder stand-alone) treffen. Deshalb muss man für den Einsatz jedes aktivierten und potenziell kabellosen Protokolls vorab die Frage stellen, ob es für einen Angriff geeignet sein könnte. Ohne das an dieser Stelle umfassend erläutern zu können, sei doch auf ein Beispiel hingewiesen: Innerhalb des GSM-Protokolls wird eine wesentliche Sicherheitseigenschaft, nämlich die Verschlüsselung, allein durch den Server vorgegeben – der Client kann die Sicherheitseigenschaften der Kommunikation nicht aktiv steuern. Somit stehen einem potenziellen Angreifer zahlreiche Möglichkeiten zur Verfügung.

Annahmen an die Umgebung

Dabei ist noch nicht einmal gesagt, dass ein Angriff stets eine fehlerhafte Konfiguration ausnutzt. Wie hier die Grenzen verschwimmen können, zeigt die folgende beispielhafte Konfiguration für ein besonders benutzerfreundliches Backup-Verfahren: Nehmen wir an, eine Vertriebsorganisation sei stark verteilt in kleinen Büros mit jeweils nur wenigen Mitarbeitern, aber großer räumlicher Distanz zum Rechenzentrum. Deshalb wird eine Backup-Lösung implementiert, bei der das Notebook immer nachts zu einer vorgegebenen Zeit aktiv versucht, per Bluetooth Kontakt zu einem DVD-Brenner herzustellen und ihm sein Backup anzuvertrauen. Hier wird eine sehr komfortable Lösung zur Schwachstelle, da ein Angreifer nur sehr wenige Fakten kennen muss, um sich in den vollständigen Besitz der Daten zu bringen – und das sogar ohne dass der Besitzer es bemerkt. So können das Hotelzimmer "nebenan" oder das im Kofferraum abgelegte Notebook zu einem unkalkulierbaren Risiko werden. Auch technisch korrekte Lösungen können gefährlich sein, wenn sicherheitsrelevante Annahmen an die räumliche Umgebung nicht gewährleistet werden oder sich im Laufe der Zeit verändern.

Für die konkrete Problemstellung des Backup gibt es auf dem Markt bereits Produkte, welche die geschriebenen Daten verschlüsseln, sodass ein Angreifer zwar gegebenenfalls in den Besitz der Backup-Daten gelangen könnte, diese aber nicht im Klartext vorliegen. Im Allgemeinen ist es jedoch notwendig, alle eingesetzten Technologien einer gründlichen Schwachstellenanalyse zu unterziehen.

Weitere offensichtliche Bedrohungen gegenüber der Vertraulichkeit und Integrität (inkl. der Infektion durch Viren o. Ä.) gibt es bei der Synchronisation mit PDAs, bei der Anbindung digitaler Fotoapparate und Kameras, bei der Integration von Massenspeichern für den Transport von und zu fremden Netzen und wann immer sonst ein Datenaustausch zwischen dem zu betrachtenden System und anderen Geräten zustande kommt.

Die verfügbare Bandbreite und die Verwendungsart erfordern bei vielen Systemen eine sehr fein abgestimmte gerätetypische Konfiguration: So wäre es beispielsweise eine gute Unternehmenspolitik, den Datenfluss aus dem Netz auf digitale Fotoapparate ganz zu unterbinden, aber den Import von Dateien mit der Endung .jpg (für berechtigte Benutzer) zu erlauben. Produkte, die solche Problemstellungen "von der Stange" lösen, fehlen aktuell zwar noch, sind aber für 2004 angekündigt.

Fazit

Im Rahmen seiner Beratertätigkeit hat der Autor oft festgestellt, dass die legitimen Anforderungen nach sicheren Systemen leicht dazu führen können, dass die IT-Sicherheit als "Verhinderer" betrachtet wird, wenn man bei der Planung einer Migration oder eines Rollouts nicht von Anfang an die inhärenten Schwachstellen aufdeckt und beheben kann. Erst gemeinsam mit zusätzlichen Produkten oder Lösungen, die eine adäquate Sicherheit herstellen und diese auch auf Dauer beherrschbar machen, lässt sich die Innovation guten Gewissens nutzen. Dann wird die IT-Sicherheit auch zum "Enabler" dafür.

Dieser Bericht konnte naturgemäß Lösungen nur skizzieren, da häufig system- oder einsatzspezifische Anforderungen bestehen. Die detaillierte Beschreibung einer möglichen Lösung für einige der angesprochenen Probleme finden Sie online in einem Projektbeispiel der SioS ( www.SioS-GmbH.de/projektbeispiele_PandP1.htm).

Dr. Peter Scholz ist Senior Consultant der SioS GmbH Unternehmensberatung für IT-Sicherheit (info@sios-gmbh.de).

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004^#1, Seite 6