Microsoft hat mit Vista im 64-Bit Modus strenge Richtlinien eingeführt, welche Treiber von Vista in den Kernel geladen werden und welche nicht. Die wichtigste Anforderung von Kernel-Mode Treibern ist, dass alle Treiber von Microsoft digital signiert werden müssen (KMCS – Kernel Mode Code Signing). Die vollständigen Anforderungen beschreibt Microsoft in den Driver Signing Requirements for Windows.
Microsoft begründet diese Anforderung damit, ihre Kunden vor bösartigem Programmcode schützen zu wollen. Kernel-Mode Rootkits, die nicht über eine digitale Signatur verfügen, werden nicht mehr in den Vista Kernel geladen und können daher auch ihre Schadwirkung nicht mehr entfalten. Im Grunde eine sinnvolle Funktion. Aber mit einem Haken. Microsoft lässt den Kunden keine Wahl mehr, ob sie andere Treiber vielleicht doch laden wollen. Gut, es gibt eine spezielle Boot-Option mit der man diese Anforderung deaktivieren kann, aber diese Option muss bei jedem Neustart mit angegeben werden. Außerdem funktioniert eine Reihe anderer Software (hauptsächlich Mediensoftware) nicht, wenn Vista ohne KMCS gestartet wurde. Praktisch ist daher nicht wirklich nutzbar. Bei Windows XP möchte das Betriebssystem ebenfalls einen signierten Treiber und wenn die Signatur fehlt, bekommt der Anwender einen Hinweis, kann sich aber entscheiden den Treiber doch noch zu installieren. Bei Vista geht nichts mehr.
Die Firma Linchpin Labs hat nun am 20.07.2007 einen signierten Treiber namens Atsiv veröffentlicht, der mit einem eigenen PE-Loader ausgestattet ist und damit beliebige, auch unsignierte Treiber und Bibliotheken in den Vista-Kernel nachladen kann. Aus der Beschreibung von Linchpin Labs:
Atsiv is a command line tool that allows the user to load and unload signed or unsigned drivers on 32 bit (x86) and 64 bit (x64) versions of Windows XP, Windows 2K3 and Windows Vista. Atsiv is designed to provide compatibility for legacy drivers and to allow the hobbyist community to run unsigned drivers without rebooting with special boot options or denial of service under Vista.
Als Anwender oder Entwickler ist das eine praktische Sache. Man kann so Treiber für eigene Hardware entwickeln oder andere Erweiterungen programmieren, ohne auf die Signatur von Microsoft angewiesen zu sein. Das hilft, weil es eine Reihe von Treibern auch für aktuelle Hardware gibt, die nicht digital signiert ist. Diese Hardware kann vom Anwender mit Hilfe des Atsiv-Moduls genutzt werden. Das hilft auch, weil es die geschlossene Vista-Plattform für Funktionen öffnet, die Microsoft vielleicht nicht vorgesehen hat, die ich als Anwender vielleicht aber machen möchte.
Bereits am 03.08.2007 hat Microsoft reagiert. Scott Field, der Windows Security Architect schreibt in seinem Blog, welche Maßnahmen Microsoft dagegen ergriffen hat: Das an Linchpin Labs ausgestellte Zertifikat wurde am 02.08.2007 zurückgezogen. Auf Drängen von Microsoft hat Verisign das Zertifikat auf die Revocation List gepackt, das Zertifikat wird folglich nicht mehr anerkannt. Das Microsoft Sicherheitsteam hat das gesperrte Zertifikat zusätzlich in die Kernel-interne Sperrliste aufgenommen, die mit dem nächsten Update aktualisiert wird. Das Update der internen Sperrliste erfordert allerdings einen Systemreboot. Und damit nicht genug, der Atsiv-Treiber wird von Microsoft Defender als Schadprogramm eingestuft und vom System des Benutzers entfernt.
Spätestens jetzt bekomme ich Bauchschmerzen. Es ist eine Sache, wenn z.B. mein Virenscanner ein Programm wie Cain & Abel, das sich auf meinem Rechner befindet, als Schadprogramm charakterisiert und mir anbietet es zu entfernen. Die Wahl darüber bleibt schließlich weiterhin bei mir und ich kann meinem Virenscanner beibringen dieses (und andere Hackingtools) auf meinem Rechner zu ignorieren. Vista gibt mir diese Möglichkeit nicht mehr. Das Zertifikat wurde gesperrt und der Treiber ist damit nicht mehr funktionsfähig. Nur um das klarzustellen, eigene Treiber im Betriebssystem sind eine vollkommen legale und legitime Angelegenheit. Dabei handelt es sich weder um einen Urheberrechtsverstoß (solange die verwendete Vista-Version legal erworben wurde), noch um einen Lizenzverstoß (da 3rd-Party Treiber ja generell erlaubt sind). Trotzdem verbietet Microsoft es mit über technische Maßnahmen, das Betriebssystem so zu nutzen wie ich möchte. Ohne, dass ich gefragt wurde, werde ich als Anwender bevormundet.
In der Taugshow (österreichisch für Talkshow) von monochrom war ich nur so ca. 45 Minuten. Irgendwie fand ich das nicht so ganz lustig. Die Show war auch nicht wirklich gut besucht, da sind einige Plätze leer geblieben. Ich habe mir ja etwas mehr Show erhofft, so im Sinne des RFID-Songs auf dem CCC aber dann wurde es nach Überwindung der technischen Schwierigkeiten erstmal doch eine recht zähe Talkshow, die ich nicht komplett angekuckt habe.
Egal. Das RFID-Video von YouTube kommt hier jedenfalls rein:
Der notorische Dan Kaminsky mit seinen jährlichen Black Ops. Ich frage mich ja, was er dann auf dem Congress im Dezember bringt, weil da kann er seine Black Hat Slides nicht schon wieder recyceln. Das gab übrigens ganz schön Buh-Rufe von den Zuhörern, dass auf den Slides nicht mal „Black Hat Conference“ durch „Chaos Communication Camp“ ausgetauscht war. Ich frag mich ja, was eigentlich originäre Arbeit von Dan in den Präsentationen ist und was er so zugetragen bekommt. Beim Thema Flash-Vulnerabilites fand ich den Vortrag von Fukami inhaltlich um Klassen besser. Nur die Show und das gehampel auf der Bühne hat Dan besser drauf.
Angriffe mit Flash und DNS Rebinding
Jedenfalls hat Dan das Thema Flash und DNS Rebinding wieder aufgegriffen und ein wenig genauer erklärt. Das Problem wurde wohl erstmals 1996 als Princeton Attack veröffentlicht und für Flash von Dan Boneh von der Stanford University genauer untersucht. Zurückzuführen lässt sich das alles auf die „Same Origin Policy“, die davon ausgeht, dass eine Datenquelle mit einem Rechnernamen identisch ist. Nur stammen die Daten von einer IP-Adresse und der Rechnername aus DNS. Und die DNS-Einträge lassen sich schnell mal ändern. Zu einem Zeitpunkt zeigt www.example.com auf einen Webserver und lädt die Flash-Applikation, zu einem späteren Zeitpunkt (nur Sekunden später) auf eine private interne IP-Adresse und führt einen Angriff aus. Damit lässt sich natürlich sehr schön jede Firewall umgehen.
Dan unterscheidet zwischen Angriffen Level 1 (nur der Browser ist betroffen), Level 2 (Web-Plugins werden zum Angriff verwendet) und Level 3 (Plugins mit Socket-Funktion werden verwendet, Angriffe in das LAN sind möglich). Sockets finden sich beispielsweise in Flash und Java. Java war übrigens das Originalziel der Princeton Attacke von ’96.
Für das DNS-Rebinding sieht Dan als alter DNS-Hacker drei Möglichkeiten:
Temporal: Die TTL wird auf 0 gesetzt, dann darf der DNS-Server eigentlich nicht cachen. Einige DNS-Server implementieren jedoch eine Minimum-TTL (meist so etwa 5 Minuten) und ignorieren eine TTL=0.
Spatial: Man kann für einen DNS-Namen mehrere IP-Adressen angeben. Allerdings hat man dann keine Kontrolle, welche IP-Adresse der Browser wann verwendet. Aber man kann ja mehrfach versuchen.
Ridiculous: Mit Hilfe von CNiping, d.h. der Verwendung von CNAME anstatt direkten IP-Adressen lässt sich ein Eintrag im DNS-Cache auch überschreiben, wenn die TTL noch nicht abgelaufen ist. Da kann man was mit anfangen.
Und nun setzt Dan ein paar Bausteine zusammen. Dazu verwendet er den Browser mit einer speziellen Flash-Anwendung, den Angreifer, der über den Browser in das lokale Netz eindringen will und einen speziellen Proxy (Slirpie). Dabei handelt es sich um einen Multiprotokoll-Server, der TCP-Stream von/zum Flash, HTTP für den Browser, DNS für das Rebinding und XML-Socket zur Kontrolle der Policy unterstützt. Anscheinend hat Dan sowas programmiert, leider jedoch nicht veröffentlicht.
Mit einem Rückgriff auf Slirp (1995) und PPTP ist es damit möglich, VPN über den Browser einzurichten, wobei der Browser nicht als VPN-Client sondern als VPN-Gateway dient. Scary!
Provider Hostality
Der zweite Teil des Vortrags beschäftigt sich mit der Thematik eines neutralen Netzes. Welche Möglichkeiten gibt es, um eine Provider zu entdecken, der einzelne Webseiten in seinem Netz bevorzugt transportiert und andere Seiten ausbremst oder noch schlimmer Content manipuliert in dem z.B. Werbeeinblendungen verändert werden.
Hier gab es ein paar interessante Ideen, z.B. über einen transparenten Proxy, der alle Seiten cached zu ermitteln, ob der Provider irgendwas manipuliert. Als geeignetes Werkzeug bietet sich ein Sniffer im Browser an, hier hat Dan etwas mit dem Namen „Inspector Pakket“ gebastelt aber leider auch noch nicht veröffentlicht.
Mal sehen, was davon demnächst als reale Software auftaucht. So ein Metasploit als Flash im Browser um die Angriffe von innen auszuführen wäre schon cool 🙂
Fefesersten Vortrag habe ich ja leider verpasst, aber zum zweiten Vortrag bin ich dann doch rein, obwohl ich anfangs ein wenig skeptisch war. Ein paar Sachen muss man Fefe jedoch neidlos zugestehen … was C angeht hat er richtig Ahnung. Die Kernaussage war dafür recht schlicht: „Lesbarer Code ist wichtiger als Optimierung“.
Don’t use Inline
das macht der Compiler von alleine wo es sinnvoll ist
in modernen Compilern ist da eine sehr gute Optimierung
Range checks
kann man immer machen
optimiert der Compiler gegebenenfalls automatisch weg wo sie unnötig sind
Strength Reduction
der Compiler macht automatisch shifts draus
Sizeof
optimiert der Compiler automatisch, auch bei mehrfachem Einsatz
keine „magic numbers“ verwenden
Tail recursion
kann man in eine nichtrekursive Funktion auflösen
macht der gcc automatisch
nicht icc und sun-cc
Aliasing
der Compiler muss hier sehr vorsichtig optimieren
(außer der gcc, der optimiert alles weg, aber dafür hat Fefe ja einen Bugreport geschrieben)
hier ist manuelle Optimierung möglich (aber lohnt sich kaum)
Dead Code
Compiler/Linker kann Code bzw. Objectfiles weglassen
Beim kompilieren von Bibliotheken jede Funktion in ein eigenes Objectfile packen
Inline Assembler
braucht man praktisch nie
ist blöd zu debuggen
besser nicht (lohnt sich auch kaum bei modernen Compilern)
Shifting
schwer in C zu programmieren
optimiert der Compiler automatisch
Pre- vs. Post-Operation
auch hier kaum noch Optimierungsmöglichkeiten
Memory Hierarchien
hier lässt sich am meisten tunen
ein Cache Miss schlägt mit 250 CPU-Cycles Penalty zu buche
das ist meist der teuerste Schaden und am wichtigsten zu optimieren
Aha … also gute Neuigkeiten für Spaghettiprogrammierer wie mich … einfach weitermachen, der Compiler optimiert das schon. 🙂
Gil Dabah, u.a. Autor des diStorm Disassembler hat in diesem Vortrag die Möglichkeiten des Binary Patchings am Beispiel von zwei Microsoft Lücken (VML, ANI) vorgestellt und dabei ein wenig Werbung für seinen Arbeitgeber ZERT (Zeroday Emergency Response Team) gemacht. Insgesamt war der Vortrag aber sehr ausgewogen, er hat nicht nur auf Vorteile des Binary Patchings hingewiesen sondern auch auf die möglichen Probleme und Gefahren und es den Teilnehmern überlassen, daraus ihren Schluss zu ziehen. Der Vortrag hat mir auch aus diesem Grund recht gut gefallen.
Patching wird von Gil definiert als Änderung von Daten oder Code, die das Verhalten eines Programms verändern. Das vielleicht bekannteste Beispiel von Binary Patching sind Game Cracks, nach deren Anwendung sich ein Spiel ohne zugehörige CD bzw. Registrierungscode spielen lässt.
Typische Probleme beim Patchen von Binaries sind:
verschiedene Binary Versionen
Code Änderungen / Verschiebungen des Programmcodes im Binary
Kein Platz im Binary für Zusatzcode
Konkurrierendes Hot Patching von Microsoft
Windows File Protection, das Änderungen an Systembibliotheken verhindert
Virenscanner Probleme (modifizierte Binaries)
Insgesamt ist daher das Ändern von Systemdateien gar nicht so einfach. Der Binärpatch kann auf verschiedene Art erzeugt werden:
PE-Patching
Ein Portable Executable Binary ist ein komplettes ausführbares Programm unter Windows.
Beim PE-Patching wird das komplette Programm angepasst, was auch Änderungen der PE-Struktur erfordert
In kurzer Zeit nicht verläßlich durchzuführen, da meist größere Änderungen erforderlich sind
Insgesamt sehr aufwendig
Per-Version Patching
Jede einzelne Version eines Binaries wird passend gepatcht
Benötigt alle vorhandenen Programmversionen
Wenn einzelne Versionen unbekannt sind, kann der Patch nicht angewandt werden
Hot Patching Bytes
Möglich, wenn der Patch nur an wenigen Stellen angewandt werden muss
7 Bytes sind oft nicht genug
Spot Patching
Einfach, da lediglich Search & Replace verwendet wird
Geht nicht, wenn z.B. die Patch-Signatur nicht statisch ist
Eine Lücke, für die ZERT einen Patch entwickelt hat ist die VML (Vector Markup Language) Lücke, ein Zeroday, der am 19.09.2006 von Adam Thomas von Sunbelt Software gefunden wurde. Die Lücke wurde zu diesem Zeitpunkt aktiv im Internet genutzt, um in Systeme einzubrechen. der VML-Bug ist ein einacher Stack-based Buffer Overflow in der Datei VGX.DLL, die von allen Internet Explorer 6 Versionen in Windows XP SP2 verwendet wird. DEP (Data Execution Prevention) würde vor dem Exploit schützen, wird jedoch standardmäßig beim IE nicht verwendet. Der Angriff benötigt lediglich fehlerhafte Attribute in der VML-Fill-Methode und ist daher einfach auszuführen. Ein typischer „surf and geht owned“-Exploit.
Das Patchen des VML-Binaries ging relativ einfach vonstatten, da VGX.DLL eine In-proc DLL ist die registriert und deregistriert werden kann. Der Ablauf erfolgt dann wie folgt:
Einlesen der VGS.DLL
Finden der Signatur
Patchen des Binaries
Speichern der gepatchten PATCHEDVGX.DLL
Deregistrieren der VGX.DLL
Registrieren der PATCHEDVGX.DLL
Beim ANI-Fehler musste zum Patchen eine andere Methode angewandt werden, da die USER32.DLL sich so nicht ändern lässt. Die verwendete Technik nennt sich in-memory patching:
Mittels knownDLLs die Patch-DLL jedem Prozeß hinzuladen
Im RAM die USER32.DLL finden und patchen
Allerdings wird diese Technik in 64 Bit Vista nicht mehr funktionieren, da nur signierte Bibliotheken geladen werden können.
Fazit und Risikomanagement:
Don’t use 3rd-party patches!
Do you trust patches from people that don’t own the source code?
What about liability and vendor support?
If not patched, you are already vulnerable!
Do you want to stay unprotected?
ZERT supplies source code of the patches
Am Ende bleibt es halt doch immer dem Sicherheitsbeauftragten und dem Administrator überlassen zu entscheiden, was sie tun wollen.
Lisa Thalheim hat im Vortrag Twisting Time ein paar Probleme konkurrierender Programme vorgestellt. Dabei ging es um typische Programmierfehler, die zu Concurrency Bugs führen. Ursache sind entweder Programme oder Threads von Programmen, die parallel (simultaneously) ablaufen können und entweder gemeinsam auf eine Ressource zugreifen oder miteinander kommunizieren müssen. Hier treten leicht schwer zu findende und unregelmäßig auftretende Fehler auf.
Der Vortrag selbst war eigentlich ein reiner Grundlagenvortrag, von meiner Einschätzung her das Niveau eines Proseminars an der Uni. Für Leute, die damit noch nie zu tun hatten sicher interessant, da alle Grundlagen erklärt wurden, für Programmierer die sich damit schon beschäftigt hatten eher langweilig, da außer ein paar anschaulichen Source Code Abschnitten nichts wirklich neues vorgestellt wurde. Im Zusammenhang mit dem Stichwort „Twisting Time“ hätte ich mir vielleicht auch noch einen Hinweis auf zeitkritische Sidechannel-Angriffe vorstellen können.
Typische Fehler sind:
Deadlocks (das Programm hängt komplett)
Livelocks (das Programm hängt in einer Endlosschleife)
Fehlerhafte Kommunikation
Fehler in der gemeinsamen Datennutzung
Race Conditions
Race Conditions sind für den Angreifer in der Regel am interessantesten.
Die Ursachen für Race Conditions sind praktisch immer drei Hauptursachen:
Vergessene Locks in konkurrierenden Zugriffen
File System Races (TOCTOU-Fehler)
Signal Races
Race Condition am Beispiel eines Ringpuffers
#define CELLS 32
int rbf[CELLS];
int rbf_idx = 0;
uint32_t num_elems;
void rbf_store( int data ) {
if (rbf_idx == CELLS)
rbf_idx = 0;
rbf[rbf_idx] = data;
rbf_idx++;
num_elems++;
}
Wenn dieser Code konkurrierend abläuft, kann es passieren, dass die if-Abfrage des ersten Threads einen rbf_idx-Wert kleiner CELLS ergibt, danach wird dieser Thread angehalten, ein zweiter Thread für die if-Abfrage durch, ebenfalls mit einem Wert in rbf_idx kleiner CELLS, der erste Thread schreibt folglich in den Puffer und erhöht den Index, anschließend schreibt der zweite Thread in den Buffer (wobei damit der reservierte Speicherbereich bereits überschritten wird) und erhöht den Index. Da rbf_idx jetzt bereits größer ist als CELLS, wird in Zukunft immer über den eigentlich reservierten Speicher des Buffers hinaus geschrieben. Ursache für diesen Fehler ist ein vergessener Lock, der den Bereich rbf_store sichert, da dieser Bereich nur einmal konkurrierend betreten werden darf.
Locking Fehler liegen entweder an komplett fehlenden Locks bzw. fehlender Synchronisation, da sich der Entwickler der Konkurrenz nicht bewusst war oder inkonsequentem Einsatz, bei dem einzelne Funktionen nicht richtig gesichert werden.
Bei File System Race Conditions handelt es sich praktisch immer um TOCTOU-Fehler (Time Of Check vs. Time Of Use). Ein Zustand wird zu einem Zeitpunkt A geprüft und das Wissen über diesen Zustand zu einem Zeitpunkt B verwendet, ohne zu beachten, dass sich dieser Zustand auf einem Multithreaded-System in der Zwischenzeit geändert haben kann. TOCTOU-Fehler treten besonders gerne bei temporären Dateien auf und sind sehr schwer zu vermeiden, da es in Unix keine atomare (d.h. nicht unterbrechbare Aktion) zum Prüfen und Anlegen einer Datei gibt. Exploits sind oft über Symlinks möglich, die Präsentation gibt hier ein cleveres Beispiel einer temporären Syslog-Datei verlinkt auf /root/.bash.
Signal Races
Signal Races sind die dritte Klasse häufiger Race Conditions und am schwierigsten zu verstehen. Dabei werden Signal-Handler konkurrierend eingesetzt, beispielsweise beim Beenden von Programmen oder Schreiben von Logfiles. Der klassische Fehler ist der Aufruf einer non_reentrant Funktion (d.h. einer Funktion die z.B. aufgrund interner Variablen nicht konkurrierend mehrfach aufgerufen werden darf) oder die Verwendung von non_reentrant Signal Handlers.
Signal Races findet man beispielsweise im Zusammenhang mit sigaction() und nicht offensichtlich erkennbar mehrfach genutzten Ressourcen (z.B. libc-Funktionen mit internen statischen Variablen die bei konkurrierenden Aufrufen überschrieben werden). In C++ kann man nach Singletons wie instanceOf suchen.
Auf dem Camp wurde der Vortrag zu RFID von Milosch Meriac, dem Hauptentwickler der RFID-Hardware und von Henryk Plötz gehalten, der an der Software schraubt. Der Vortrag war recht ähnlich zum RFID-Vortrag von Harald Welte und Milosch Meriac auf dem letzten Congress.
RFID-Standards
Als Einleitung wurde wieder der RFID-Standard ISO 14443 vorgestellt, der Proximity Integrated Circuit Cards (PICC) definiert. Der Standard beschreibt im Detail
1. Physical Characteristics
2. RF Power & Signal Interface
3. Initialization & Anti-collision
4. Transmission Protocol
Hauptsächlich gibt es zwei verschiedene Kartentypen, Typ A, die Mifare-Karten von Phillips und Typ B, die z.B. bei ePassports zum Einsatz kommen. ISO 14443 setzt Amplitude Shift Keying (ASK) Modulation ein, die so kodierten Signale des Receivers (PDC) sind aus 5-10 m empfangbar, die Antwortsignale der Karte (PICC) liegen 60-80 dB unter der Signalstärke des Senders und sind typischerweise aus maximal 2 m empfangbar. Ein Anti-Collision-Protokoll soll unterschiedliche Karten in Reichweite des Empfängers trennen. Dazu werden UIDs (Unique Identifier mit 4, 7 oder 10 Byte) verwendet. Auf dem Congress im Dezember gab es dazu einen interessanten Vortrag einer holländischen Gruppe, die durch gezielte Erzeugung von Kollisionen einzelne Karten ausblenden konnte.
Kartentypen
ISO 14443A
16×4 = 64 Byte Speicher
10 Byte Read-Only Factory-Programmed, davon 7 Byte UID
6 Byte PROM, davon 2 Byte Lock-Bits
48 Byte nutzbarer Speicher
Keine Verschlüsselung
Keine Security-Funktionen außer der UID
Mifare Classic
Weitverbreiteter Standardtyp
1-4 KB Speicher
Proprietärer Stream-Cipher („Crypto1“) mit 48 Byte Schlüssellänge, bisher nicht gebrochen
4 Byte UID
ACLs für einen Speicherbereich für Geldwerte auf den nur mit INCREASE/DECREASE-Kommandos zugegriffen werden kann
Multiple User-Areas mit unterschiedlichen Schlüsseln
Multi-Application-fähig
Mifare DESfire
Mifare Classic-kompatibel
DES/3DES Verschlüsselung
7 Byte UID
T=CH
In ISO 14443-4 definiert
APDUs vergleichbar zu kontaktbasierten Karten nach ISO 7816
Wird in vielen ePassports verwendet
Hardware
Milosch hat sehr schön die benötigte Hardware beschrieben, im einfachsten Fall reicht eine triviale Kupferspule mit LED und Kondensator. Für die komplexeren Angriffe gibt es einen von ihm entwickelten RFID Sniffer/Sender, mit dem auch trivial Replay-Angriffe möglich sind. Die benötigte Hardware kann man entweder bei www.OpenPCD.org fertig kaufen oder anhand der Anleitungen und Vorlagen selbst bauen.
Work in Progress
Ein paar Sachen funktionieren noch nicht ganz:
Anticollision tut noch nicht so 100%, aber daran arbeitet das Team
Bereitstellen von Mifare-Samples um die Verschlüsselung zu brechen
OpenPDC/OpenPICC OS nach FreeRTOS portieren
Und für folgendes benötigen die Jungs dringend Hilfe:
Brechen der Mifare-Verschlüsselung
OpenPCD und OpenPICC in ein Standalone-Sniffer/Replay-Gerät kombinieren
Marco Gehrcke gab in seinem Vortrag Online Search zu Beginn einen Überblick über die Diskussion zum Bundestrojaner, inzwischen Remote Forensic Software genannt, in den USA und in Deutschland. Interessant der Vergleich einer Hausdurchsuchung, die öffentlich erfolgen muss und einer Rechnerdurchsuchung, die geheim bleiben soll. Hier bestehen erhebliche verfassungsrechtliche Bedenken. Ich möchte die angesprochenen wichtigen Punkte nur mal in Stichwörtern zusammenfassen, es gibt genug Sekundärliteratur, die genauere Informationen liefert.
Begründung für den Trojaner:
Verschlüsselung verhindert Strafverfolgung
Funktionen des Trojaner:
Standort- bzw. IP-Adressbestimmung um Anonymisierungsdienste auszuschalten
Aufzeichnung aller eingetippten Daten und gelesenen Dokumente
Keylogger-Funktionen zum Auslesen von Passwörtern und Encryption Keys
Problem: Wie kommt der Trojaner auf den Rechner
Installation vor Ort durch herkömmlichen Einbruch
Definierte Schwachstellen durch die Betriebssystemhersteller
Gefahren:
Zu wenig Ressourcen für die Polizei, um geeignete Software für alle Betriebssystem-Versionen zu entwickeln (OpenBSD-User sind immun?)
Antivirus-Software erkennt die Remote Forensic Software nicht, Virenschreiber bauen auf diesen Funktionen auf
Hintertüren im Betriebssystem können z.B. durch Kriminelle missbraucht werden
Strafverfolgungsmöglichkeiten werden auf Bagatellstraftaten ausgedehnt (z.B. einfache Urheberrechtsverletzungen)
Verletzung der staatlichen Souveränität bei grenzüberschreitenden Ermittlungen
Durchsuchungen erfolgen heimlich (wie bei der Gestapo oder Stasi) und nicht mehr öffentlich wie das unser Grundgesetz fordert
Online Durchsuchungen verletzen elementare Grundrechte. Die notwendige Abwägung von Sicherheit gegenüber Freiheit scheint hier nicht erfolgt zu sein. Dazu gab es von Marco Gercke ein schönes Zitat: „Es ist nicht Aufgabe des Staates dafür zu sorgen, dass jedes noch so kleine Verbrechen effizient verfolgt werden kann.“
Was wäre die Alternative?
Verbot anonymer Kommunikation
Verbot von verschlüsselter Kommunikation
Gercke argumentierte nun, bevor diese Verbote kommen, sei eine gelegentlich stattfindende Online-Durchsuchung mit Richtervorbehalt das kleinere Übel. Ich denke hier genau umgekehrt. Die Online-Durchsuchung scheint von vielen, gerade technisch kaum versierten Mitbürgern akzeptiert zu werden, weil sie nicht verstehen worum es sich dabei handelt und vor allem, dass es sich um einen massiven Angriff auf die grundgesetzlich geschützten Bürger- und Freiheitsrechte handelt. Es steht zu befürchten, dass gerade auch durch die um Zuge des letzten G8-Gipfels in Heiligendamm erfolgte Ausweitung der Definition der „Terroristischen Vereinigung“ (§ 129a StGB) praktisch jeder Demonstrant unter Verdacht steht und damit heimlich durchsucht werden kann. In der ehemaligen DDR genügten dazu „Westkontakte“ in der Bundesrepublik zukünftig wohl „Demonstrationskontakte“. Ein Verbot von verschlüsselter Kommunikation würde jedoch auch der letzten Oma mit Internetbanking klar machen, dass hier etwas grundlegend verkehrt läuft. Der öffentliche Aufschrei würde folglich auch den sitzhaftesten Bundesinnenminister aus dem Amt rollen. Und das wäre dann das kleinstmögliche Übel.
Abgestufter Schutz, wenn Daten sowieso z.B. zu Abrechnungszwecken gespeichert werden dann ist das über den Staatsanwalt zulässig, für den Abruf der Daten aus § 113a TKG-E ist die richterliche Anordnung aus § 110g notwendig.
Die Vorratsdatenspeicherung widerspricht jedoch der Rechtsprechung des Bundesverfassungsgerichts zu Art. 10 GG (Volkszählungsurteil: Speicherung von persönlichen Daten ohne konkreten Zweck ist unzulässig). Die Bundesregierung versucht daher offensichtlich den Verfassungsverstoß über den Umweg einer EU-Richtlinie zu legitimieren. Bisher gibt es dazu die Solange-Urteile, die im Kern sagen, solange EU-Recht gleichen Rechtsstandards wie das Grundgesetz genügt, mischt sich das Bundesverfassungsgericht nicht ein. Die Vorratsdatenspeicherung könnte laut Gietl daher entweder ein Solange-3- oder ein JetztReichts-1-Urteil provozieren.
