Populäre Irrtümer zum Thema Computersicherheit
Marc Ruef | 17.09.2007

Es gibt verschiedene Themengebiete, die sich aufgrund ihrer Mystifizierung und Legendenbildung geradezu für populäre Irrtümer anbieten. Neben Geheimdiensten, politischen Verschwörungen und der traditionellen Kriegsführung gehört der Bereich der Computersicherheit ohne Zweifel zum beliebtesten Spekulationsthema am Stammtisch. Nachfolgend sollen einige typische Aussagen angegangen werden.

Frage: Linux ist sicherer als Windows? Antwort: Tendenziell ja, unter Umständen aber nein. Die Sicherheit eines Betriebssystems ist von vier Faktoren abhängig: Die Architektur, die Implementierung, die Administration und die Nutzung. Die Betriebssysteme aus dem Unix-Umfeld haben eine langjährige Tradition in Bezug auf ihre Sicherheit. Diese wird seit jeher Grossgeschrieben und nicht nur wie bei Windows eher beiläufig eingeführt (seit Windows NT immer mehr ins Zentrum gerückt). Die erhöhte Transparenz und Modularität macht es zudem einfacher, ein Linux-System zu verstehen und die Schwächen zu adressieren. Da hierbei viel Verständnis für die technischen Hintergründe erforderlich sind, ist der durchschnittliche Linux-User besser mit der Sicherheit seines Systems vertraut. Dennoch: Auch ein guter Windows-Administrator wird sein System hervorragend härten können.

Frage: Wer kein Programm öffnet, kann keinen Virus haben? Antwort: Nein, dies ist seit Jahren nicht mehr der Fall. Ursprünglich setzten Computerviren voraus, dass sich diese in ausführbaren Dateien (z.B. EXE und COM) einnisten konnten. Wird die Wirtsdatei ausgeführt, wird der Virus aktiv und geht seiner Arbeit nach. Deshalb hiess es, dass wer auf das Ausführen zwielichtiger Dateien verzichtet, sich keinen Virus einfangen kann. Mittlerweile sind Computersysteme und Dokumentdateien so komplex geworden, dass sich selbst in diesen langwierige Dateioperationen einbringen lassen. Durch das Ausnutzen eines Fehlers im Parsing wird es auch möglich, Viren über Bilder und Musikdateien zu verbreiten (z.B. als Payload eines Pufferüberlauf). Jedes Bit, das von einem Computer interpretiert wird, kann also als Träger für einen korrupten Programmcode herhalten. Ein ausserordentlich gewiefter und effizienter Vertreter dieser Richtung war W32.Blaster.Worm.

Frage: Eine aktuelle Antiviren-Software schützt vor Viren? Antwort: Nein, das war noch nie der Fall. Die Stärke der Antiviren-Produkte liegt in ihrem Pattern-Matching. Der korrupte Programmcode wird an seiner typischen Struktur (z.B. Zeichenketten von Meldungen des Virus) identifiziert. Dies setzt aber voraus, dass die Hersteller von Antiviren-Lösungen den zu findenden Virus kennen, analysiert und in ihre Pattern-Datenbank eingetragen haben. Ist der Viren-Entwickler nun aber darum bemüht, dieses Pattern zu verändern und damit eine Mutation seines Virus in Umlauf zu bringen, wird er bis auf weiteres nicht erkannt (siehe auch Polymorphie). Durch heuristische Methoden, bei denen das Verhalten einer Applikation geprüft werden kann, sollen ebenfalls Mutationen erkannt werden. Doch auch hier gibt es Techniken, die einen solchen Schutz unterbinden.

Frage: Eine Hintertür (Remote-Controlling) erfordert administrative Rechte? Antwort: Klassische Remote-Control-Utilities öffnen einen Socket auf dem infizierten Zielsystem und warten auf Anfragen des Clients. Dieser Prozess erfordert jenachdem administrative Rechte. Es sind aber ebenso Reverse-Backdoors möglich, bei denen das infizierte System keinen Dienst auf einem Port bereitstellt, sondern die Anfragen jeweils vom Client bezieht. Dies kann über reguläre Web-Zugriffe stattfinden, welche sich nur schwer erkennen und unterbinden lassen. Da es sich dabei um legitime Kommunikationen handelt, ist für diese in der Regel auch keine administrativen Rechte erforderlich. Ein Webbrowser braucht ja normalerweise auch keine erweiterten Privilegien. Die Hintertür kann sich jedoch in der Regel nur im Kontext bewegen, in dem die Infektion stattgefunden hat.

Frage: SSL/HTTPS schützt eine Webanwendung vollumfänglich? Antwort: Nein. SSL ist lediglich eine Methode, wie die Authentizität und Integrität der zur Übertragung zwischen Client und Server vorgesehenen Daten gewährleistet werden kann. Es wird also verhindert, dass jemand mithören und die Informationen zwischenzeitlich verändern kann. Sicherheitslücken auf dem Webserver oder Webapplikation werden damit jedoch nicht verhindert. Der Client kann nämlich nach wie vor mit diesen Komponenten interagieren und etwaige Fehler (z.B. Directory Traversal oder Cross Site Scripting) zu seinem Vorteil ausnutzen.

Frage: Cross Site Scripting-Schwachstellen sind unkritisch? Antwort: Jenachdem. Viele Administratoren und Entwickler argumentieren, dass sich über Script-Injection ja nur harmloser Javascript-Code in der Sitzung des Browser des Benutzers ausführen lässt. Mit diesem Wortlaut gibt man seine Besucher jedoch potentiellen Angreifern preis. Jenachdem wird es möglich, durch manipulative Eingriffe ins Aussehen der Webseite eine technisch gestützte Social Engineering-Attacke durchzuführen. Zudem sollte man die Mächtigkeit von Javascript nicht unterschätzen. Das Auslesen von Cookies, in denen sich Authentisierungs-Informationen finden lassen, ist ebenso denkbar wie das Umsetzen von Portscans (siehe Jikto). Hier ist in Bälde eine neue Generation von XSS-Payload zu erwarten.

Frage: C und PHP sind grundsätzlich unsicher? Antwort: Jein, dies ist eine Frage des Standpunkts. C erlaubt und erfordert teilweise direkte Zugriffe auf Speicherbereiche (z.B. malloc). Wird dies durch den Entwickler nicht umfassend abgesichert, tun sich Sicherheitslücken auf. Diese werden nicht oder nur bedingt durch den Compiler bei der Kompilierung oder durch das Betriebssystem bzw. den Prozessor während der Laufzeit abgefangen. Ein schlechter C-Programmierer wird also zwangsweise irgendwann unsichere C-Software schreiben. PHP weist mitunter ein ähnliches Problem auf, wobei hier unsichere Zugriffe auf Dateisysteme (z.B. Directory Traversal) und Datenbanken (z.B. SQL-Injection) für Schlagzeilen gesorgt haben. Aber auch hier ist der Entwickler für die Probleme verantwortlich und nicht die Sprache selbst. Die gleichen Probleme haben auch Java, Visual Basic, Python und Ruby. Anders könnte man jedoch argumentieren, betrachtet man die Interpretation des PHP-Codes durch die Zend-Engine. Weist diese Sicherheitslücken auf, kann ebenfalls sicher entwickelter PHP-Code zu unsicheren Zuständen führen. Das gleiche Problem haben alle interpretierten Sprachen bzw. Sprachen, die auf externe Funktionen/Bibliotheken zurückgreifen. Vor allem Java bzw. die Java Virtual Machine (JVM) ist in dieser Hinsicht immerwieder umstritten.

Frage: Ein nicht offengelegter Kryptoalgorithmus ist sicherer, als seine offene Variante? Antwort: Dies ist seit dem Kerckhoff Prinzip, dieses wurde gar im Jahr 1883 formuliert (http://www.petitcolas.net/fabien/kerckhoffs/), widerlegt: "Die Sicherheit eines Kryptosystems darf nicht von der Geheimhaltung des Algorithmus abhängen. Die Sicherheit gründet sich nur auf die Geheimhaltung des Schlüssels." Ein Verschlüsselungsalgorithmus gilt dann als schwach, wenn sich aus Schlüssel und Geheimtext Rückschlüsse auf Verfahren und Klartext erarbeiten lassen. Ein guter Algorithmus lässt dies nicht zu. Aus eben diesem Grund erfährt man mehr Nachteile, behält man ihn geheim (bestes Beispiel für das Versagen von Security by Obscurity ist die Verschlüsselung A5 in GSM). Denn ist er öffentlich, könnten sich mehr Experten mit ihm beschäftigen und damit die Unsicherheit dessen frühstmöglich erkennen. Damit wird quasi eine darwinistische Evolution der Mechanismen gewährleistet. Altbekannte Methoden wie DES und AES konnten sich also zuecht etablieren.

Frage: Voice-over-IP Telefonie (VoIP) ist sicherer als die klassische Telefonie? Antwort: Grundsätzlich Nein. Ein Telefonat in der analogen Telefonie abzuhören ist nicht besonders schwierig. Durch das Abzweigen der beiden Kupferkabel wird es mittels Beigeboxing möglich, quasi einen weiteren Anschluss einzubringen und auf diesem mitzuhören/mitzusprechen. In der digitalen Telefonie (ISDN) wird es ein bisschen schwieriger, muss man sich dabei um Abzweigungen in Glasfaser-Verbindungen und digitale Codierungen kümmern. Bei Voice-over-IP werden ebenfalls digitale Daten im Rahmen der klassischen TCP/IP-Familie verschickt. Findet diese Übertragung im Klartext statt, und dies ist bei den gegenwärtigen Mechanismen/Geräten der Fall, so ist das Mitlesen genauso einfach, wie das Sniffen von Telnet- und FTP-Logins. Man kann also nicht von einer Verbesserung der Kommunikationssicherheit sprechen.

Frage: Online-Banking ist generall unsicher? Antwort: Nein, es ist nicht weniger unsicher, weder eine manuelle Einzahlung an einem Bankschalter. Finanzinstitute unterliegen strengen Regulierungen der Kommissionen (z.B. EBK in der Schweiz). Sie sind entsprechend darum bemüht, beim Online-Banking ein Höchstmass an Sicherheit zu gewährleisten: Sichere Applikationen, Verschlüsselungen, strenge Authentisierungen und regelmässige Audits gehören dazu. Selbstverständlich passieren auch dort immerwieder Fehler. Doch diese können ebenso bei einer Zahlung über traditionelle Wege ausgenutzt werden. Die wenigsten Kapitalverbrechen im Bankenbereich geschehen im Zusammenhang mit Online-Banking. Kommt es dennoch zu einem Diebstahl, zeigen sich die meisten Banken sehr kulant und gewähren dem geschädigten Kunden einen rigorosen Ausgleich.

Frage: Chipkarten-Hacker können ohne Probleme Kreditkarten kopieren und diese weiterverwenden? Antwort: Nein, dies ist aufgrund der technischen Gegebenheiten nicht ohne weiteres möglich. Moderne Smartcards kommen mit einem speziellen Mikrochip daher, der sich nicht nur durch eine Software-Kopie klonen lässt. Das Umsetzen eines Hardware-Clonings erfordert ein sehr hohes Mass an technischem Verständnis sowie sehr teure Hardware. Aus eben diesem Grund ist ein solches Vorgehen weder für Hobby-Hacker noch für das organisierte Verbrechen von Interesse.