- Der Staat als Einbrecher - Link zur Techn. Realisierung des Bundestrojaners - Panzerknacker, 05.03.2007, 14:26
- Re: Der Staat als Einbrecher - Link zur Techn. Realisierung des Bundestrojaners - ManfredF, 05.03.2007, 15:03
- Re: Sygate....hab ich drauf. Ist enorm komfortabel zu konfigur. owT. - ottoasta, 05.03.2007, 17:42
- Re: Der Staat als Einbrecher - Link zur Techn. Realisierung des Bundestrojaners - Kasi, 05.03.2007, 16:37
- Re: Der Staat als Einbrecher - Link zur Techn. Realisierung des Bundestrojaners - Panzerknacker, 05.03.2007, 19:05
- Und wie koennen wir uns nun wehren? (Ausgeschnippelt aus TP-Forum) - FOX-NEWS, 05.03.2007, 19:02
- Re: Ausgeschnippelt aus TP-Forum - Demokrattiebegriff - völlig falsch - Baldur der Ketzer, 05.03.2007, 21:28
- Lieber Baldur - FOX-NEWS, 05.03.2007, 22:13
- Re: Birk, der Hannich der EDV - Tassie Devil, 06.03.2007, 17:29
- Re: Ausgeschnippelt aus TP-Forum - Demokrattiebegriff - völlig falsch - Baldur der Ketzer, 05.03.2007, 21:28
- Re: Der Staat als Einbrecher - Link zur Techn. Realisierung des Bundestrojaners - ManfredF, 05.03.2007, 15:03
Und wie koennen wir uns nun wehren? (Ausgeschnippelt aus TP-Forum)
-->ZITAT
4. März 2007 21:26
Und wie koennen wir uns nun wehren?
genunix (1 Beiträge seit 03.03.07)
Herr Birk beschreibt in seinem Artikel das Szenario, dass
Ueberwachungsorgane der Staates"auf unseren Leitungen sitzen", und
in der Lage sind, saemtlichen Datenverkehr zu manipulieren.
Ob dies in Form von bei den Providern installierter Hardware (SINA
Boxen) oder beim Endkunden aufgestellter Hardware (manipulierte
Router) realisiert wird, ist dabei nicht von belang - auch wenn ein
solches Angriffszenario vielleicht nicht ohne weiteres umzusetzen
ist, ist es zumindest denkbar.
Es geht nun um diese Dinge:
- der Angreifer (im folgenden"Staat" genannt, um die Betrachtung
nicht zu abstrakt geraten zu lassen) muss Code auf meine Maschine
bringen, und zur Ausfuehrung bringen; hierzu kann, wie von Herrn Birk
beschrieben, einfach downgeloadeter Programmcode mit virulentem Code
infiziert werden. Genausogut koennten aber ausgefeiltere Methoden zum
Tragen kommen: Manipulierte Nutzdaten die Programmierfehler in den
verarbeitenden Programmen ausnutzen, um Code in das System zu
schleusen. Die aufgetretenen Bugs in.pdf,.jpg und natuerlich alle
Formate mit eingebetteten Macrosprachen waeren derartige
Angriffspunkte.
- Der eingeschleuste Code muss das System nach irgendwelchen
Kriterien durchsuchen. Dabei wird er sich sicherlich nicht von
verstellten Dateiendungen abhalten lassen, wohl aber von
Kryptographie. Um die Kryptographie zu brechen, muss der
eingeschleuste Code die I/O Kanaele der infizierten Maschine
angreifen und ueberwachen, um die Passworte fuer die Schluessel
abzufangen.
- Der eingeschleuste Code muss versuchen, sich permanent im
infizierten System einzunisten, um seine Aufgaben auch nach einem
Neustart des infizierten Systems durchfuehren zu koennen. Dies sollte
auch dann funktionieren, wenn das System nicht mit dem Internet
verbunden ist, sodass eine einfache Neuinfektion micht ausreicht.
Dazu braucht der Staatsvirus hohe administrative Rechte: Er muss in
der Lage sein, Systemdateien dauerhaft zu veraendern.
So koennte sich der Staat zum beispiel im Bootcode, oder
systemspezifischen Startmechanismen, oder besser gleich weithin
benutzten Systembibliotheken (libc) einnisten.
- Der eingeschleuste Code muss seine Erkenntnisse an den Staat
zurueckliefern. Dazu koennte er entweder eigene Netzwerkverbindungen
aufbauen, oder - viel einfacher - auf jeder Protokollebene
groessergleich IP"huckepack" fahren, und die angehaengten Nutzdaten
werden auf der Uebertragungsstrecke (das SINA Teil in dem Artikel)
wieder aus dem Datenstrom herausgeschnitten, sodass dieser Vorgang
fuer die eigentliche Datenuebertragung (des Benutzers) transparent
bleibt.
Um nun ersteres, eine Infektion des Systems, zu erreichen, ist nicht
besonders viel Aufwand notwendig. Herr Birk beleuchtet dies recht
ausfuehrlich in seinem Artikel.
Die zweite Aufgabe ist fuer den eingeschleusten Code schon
schwieriger zu loesen: denn der Code laeuft erstmal mit den
Berechtigungen und in der Umgebung des Benutzers, der den
Programmcode ausgefuehrt hat. Dadurch hat der virulente Programmcode
auch nur Zugriff auf die Ressourcen (Festplatten, Speicher,
Netzwerkverbindungen, I/O Kanaele), auf die der aufrufende Benutzer
Zugriff hat. Von der Erweiterung der Berechtigungshorizontes
(Permission-Raising) durch Ausnutzen weiterer Systemfehler sei hier
einmal abgesehen.
Der letzte Satz nochmal fuer den Laien: Der eingeschmuggelte
Staatsvirus kann und darf erstmal nur das, was der Benutzer, der den
Staatsvirus eingeschleppt hat. kann und darf.
Um eine Datei zu durchsuchen, braucht der Staatsvirus vermutlich die
Rechte der dazugehoerigen Benutzeridentitaet; zum Ueberwachen der I/O
Kanaele (Passwort abfangen) braucht der Staat auch garnicht mal so
viel Aufwand: schon das Ueberladen der Routine, die das Passwort
liest, auf Ebene des Loaders, waere mit den Berechtigungen des
Benutzers machbar.
Die dritte Aufgabe ist auch noch nicht so schwer: alle
gebraeuchlichen Systeme beinhalten Mechanismen, mit denen sich ein
Programm zumindest fuer den User"permanent" einrichten kann; gelingt
es dem Virus, diese Information dauerhaft zu speichern (z.B. der
Staatsvirus fuegt einen Programmaufruf in mein.profile ein), dann
wuerde der virulente Code bei jeder Session wieder mit meinen
Berechtigungen wirksam. Genausogut koennte sich der virulente Code in
Modulen eines Programmes verbergen, z.B. sich als Mozille-Extension
tarnen oder eine installierte Extension"erweitern". Dan wird der
Staatsvirus in dem Augenblick aktiv, in dem ich das betreffende
Programm starte.
Die letzte Aufgabe, der Ruecktransport der Daten zum Ueberwacher, ist
komplex-aber-moeglich auf den hoeheren Netzwerkebenen: kennt man das
Protokoll, so kann man die herauszuschmuggelnden Schnueffelergebnisse
auf eine Weise in die Uebertragung einbetten, das sie auch von einem
eventuell verwendeten Proxy oder Forwarding-Server nach aussen
transportiert werden. Dies funktioniert im Client, also mit den
Berechtigungen des Benutzers. Ein Beispiel waere"einfach Anhaengen
an die Mail" - theoretisch denkbar, und voellig unabhaengig davon ob
der Benutzer pgp oder s/mime benutzt; es geht ja nur darum, Daten bis
zur SINA-Box (oder ihrem Nachfolger) zu transportieren, und sie dort
transparent aus dem Datenstrom zu schnibbeln.
Auf Packetebene ist das natuerlich genauso denkbar; richtig gut auf
Paketebene ("ich haenge jetzt 10 MB Schnueffeldaten in 100 Byte
Broeckchen an die naechsten ausgehenden Nutzerpakete") beinhaltet
aber, das der Staatscode die Kontrolle ueber den TCP-Stack der
infizierten Maschine hat.
Dazu spaetestens braucht das Virus erhoehte Privilegien und muss sich
in den Systemcode einnisten; unter Unix waere das zum Beispiel ein
Kernelmodul, dass in den TCP-Stack eingreift.
Bisher noch nicht betrachtet habe ich die Moeglichkeit des
"Phone-Home", also des Aufbaus eigener Netzwerkverbindungen zu einem
(oder mehreren) Servern, um die Schnueffelergebnisse zu uebertragen:
Hier sind wahre Meisterleistungen moeglich (wenn man mal das Programm
"Skype" als Beispiel nimmt), die auch Firewalls penetrieren und mit
beidseitigem NAT klarkommen. Fuer viele der dabei verwendeten
Techniken sind erhoehte Systemprivilegien noetig.
Fassen wir nochmal zusammen: Derartige Angriffe - durch Staatsdiener
oder finstere Gesellen - sind nicht nur denkbar und realistisch,
sondern durchaus auch Realitaet. Jeder Benutzer der Microsoft Systeme
wird mir hier seufzend zustimmen.
Der Angreifer braucht:
- einen Infektionsweg
- Berechtigungen fuer die ueberwachten/durchsuchten Ressourcen
- Kontrolle ueber die Eingabegeraete
- Permanenz im System
- Kontrolle ueber den Netzwerkverkehr
Alle diese Dinge kann er, dem Artikel von Herrn Birk und meinen
obigen Ausfuehrungen folgend, durchaus erlangen.
Insofern kann ich Herrn Birk verstehen, wenn er schlussfolgert, dass
man keinerlei Programmcode von aussen annehmen darf. Darauf laeuft es
hinaus. Weitergedacht bis zur Moeglichkeit, Nutzdaten zu manipulieren
um Viewer-Bugs auszunutzen, dass jeglicher Datentransfer ueber das
Internet fuer ein sicheres System tabu sein muss.
Daraus folgt, dass das System, mit dem wir auf das Internet
zugreifen, nicht sicher, also nicht vertrauenswuerdig ist.
Ganz so schwarz wie Herr Birk sehe ich die
Verteidigungsmoeglichkeiten auf technischer Ebene allerdings nicht:
die Zauberworte heissen in meinen Augen
- Virtualisierung
- Least Privileges
- Keine Schreibbarkeit ausfuehrbarer Daten (und umgekehrt)
- Protokollumbrueche
- Formatumbrueche
All das ist zwar technisch nicht unkomplex und teilweise recht
unbequem; aber wenn wir unsere"schoengeschminkte" Steuererklaerung
(oder auch unsere Plaene zum Bau thermonuklearer Sylvesterraketen)
vor der Analyse durch die Schnueffler schuetzen wollen, mussen wir
wohl ein paar Unbequemlichkeiten in Kauf nehmen, die ueber die
Installation von Nortons bunter Firewall hinausgehen.
In der Praxis bedeutet das:
Wir benutzen zum Zugriff auf das Internet virtuelle Maschinen. Diese
lassen wir in einer kontrollierten Umgebung laufen, und stellen ihnen
nur die Ressourcen zur Verfuegung die sie unbedingt brauchen. Dadurch
schuetzen wir unsere IP-Stacks, und koennen leichter eine Permanenz
des virulenten Staatscodes verhindern.
Ein Beispiel waere ein FreeBSD-Jail, oder eine Solaris-Zone,
innerhalb derer eine Windows oder Linux Installation unter VMWare
laeuft. Die Zone bzw. der Jail schuetzt meine Ressourcen, auch dann
wenn die Virtualisierungssoftware (vmware in dem Fall) selbst
kompromittiert ist.
Die ausfuehrbaren Programme der Zone/Jail werden readonly gemounted,
oder kommen von einem nicht schreibbaren Datentraeger (DVD), die
schreibbaren Bereiche (Datenbereiche) des virtuellen Surfsystems
kommen ueber ein Netzwerkprotokoll, z.B. nfs, cifs oder
loopback-mount. Hier ist auch die Einfuehrung von Kryptographie
sinnvoll: Ist das Filesystem an dieser Stelle verschluesselt, so ist
dies ein fuer die gehostete virtuelle Surfstation voellig
transparenter Layer zwischen (deren) Filesystem und der
Storage-Hardware (des Hosts). Der zum ver/entschluesseln der Daten
notwendige Schluessel ist innerhalb der virtuellen Maschine weder
noetig noch vorhanden. Das Programm/Projekt"cfs" kann derartiges
leisten.
Innerhalb dieser - geschuetzten und eingeschraenkten - Umgebung kann
ich dann eine virtuelle Maschine wie vmware mit meinem Lieblings-OS
starten lassen, um Daten ueber das Internet zu uebertragen.
Wir benutzen unsere Systeme immer mit den wenigst-moeglichen
Benutzerrechten. Unter Unix seit immer schon gaengige Praxis, sind
die Moeglichkeiten dafuer auch auf moderneren Systemen aus dem Hause
Microsoft vorhanden (den Ur- Unix Mechanismen sogar ueberlegen!).
Warum eine konsequente Benutzung derartiger Mechanismen in der
Microsoft-Welt seit Jahren nicht vorangetrieben, sondern fast
verhindert wird, ist mir ein Raetsel.
Damit schraenken wir den Berechtigungshorizont des Virus weiter ein.
Allerdings beruht die Sicherheit eines derartigen Systems nicht auf
der strikten Einhaltung von Least-Privileges auf der virtuellen
Maschine; verdaechtige Dokumente wie die Steuererklaerung oder die
thermonuklearen Knallkoerper schaffe ich sowieso so schnell wie
moeglich aus dem Bereich den die virtuellen Surfstation"sieht" in
einen anderen Bereich des Host-Dateisystems - und zwar von ausserhalb
der virtuellen Maschine, um dann - entweder auf dem Hostsystem
selbst, oder einer weiteren virtuellen Maschine (ohne
Netzwerkressourcen) die Information zu extrahieren / zu betrachten.
Klar sollte natuerlich auch sein, dass sowohl die Dateisysteme der
virtuellen Maschine, aber auch schon die Dateisysteme des
uebergeordneten Jail/Zone Read-Only ins System eingebunden sind,
sofern es sich um ausfuehrbare Dateien handelt. Unter unix kann man
die entsprechenden noexec bzw. ro Flags von mount benutzen, fuer die
VM hat man zumindest ueber die Schreibbarkeit der Systembereiche des
gehosteten Systems volle Kontrolle.
Nun haben wir noch Protokoll- und Formatumbrueche im Aermel:
Das bedeutet zum Beispiel, dass ich ein ueber die virtuelle
Surfstation erhaltene Anleitung zum Bau von Wasserstoff-Handgranaten
(warning, strong! Throw for a minimum distance of 72 miles after
pulling the ring!) im.doc Format noch auf der virtuellen Maschine
als HTML, XML, OpenOffice oder sonstwas speichere.
Die neuformatierte Kopie transferiere ich in einen anderen Bereich
meines Systems, ausserhalb des Horizontes der virtuellen Maschine,
bevor ich sie dort (z.B. mit Staroffice) bearbeite.
Auch eine Umkodierung von Bildformaten waere hier denkbar.
Ausserdem kann man natuerlich die Vorstellung von"Internet", die die
virtuelle Maschine hat, bequem vom hostenden System aus steuern.
So ist es leicht zu erreichen, dass eine derartige virtuelle
Surfstation ausschliesslich ueber Proxies Internetservices benutzen
kann.
Ebenfalls auf Ebene des Hostsystems kann man ein VPN zu einem
(vertrauenswuerdigen / auslaendischen) Host, oder verschluesselte
Verbindungen zu einem System wie TOR aufbauen. Hier ist noch einige
Entwicklungsarbeit zu leisten, aber wenn ein Hostsystem
verschluesselte Verbindungen zu einem derartigen verteilten System
aufbaut, und diese der virtuellen Surfmaschine transparent zur
Verfuegung stellt, hat kein StaSi/BND/Staatsvirus eine Chance
dagegen, und das gesamte Angriffszenario von Herrn Birk verpufft in
einer Wolke aus verschwendeten Steuergeldern.
Wie man sieht, ist der Paranoia hier keine Grenze gesetzt, dem
Staatsvirus hingegen schon. Und ich gebe zu, dass die Sicherheit von
Computersystemen umgekehrt proportional zu ihrer
Benutzerfreundlichkeit ist. Wie gross der Rechenfehler in der
Steuererklaerung ist, und welche technischen Massnahmen deshalb
notwendig sind, muss jeder fuer sich selber ausmachen.
Was meine Einlassungen noch ueberhaupt nicht betrachten, ist der
Schutz der beteiligten Host- und Serversysteme. Was nuetzt eine
kryptografisch verpackte VM in einem Jail, wenn der Staat schon im
Kernel des Hostsystems sitzt? Nix mehr.
Und hier bin ich wieder mit Herrn Birk d'accord: Keine downgeloadeten
Binaries auf das System lassen. Im Falle von BSD sehr einfach - ich
kompiliere meine BSD Systeme seit Jahren komplett aus dem Source - im
Falle anderer Systeme komplizierter und nicht so vollautomatisch,
aber nicht unmoeglich.
Ein Problem ist hier die Vertrauenswuerdigkeit der
Quellcodedistribution: Wenn"Vater" (!) Staat schon auf den Routern /
Leitungen hockt, kann ich weder meinen DNS Anfragen, noch sonstgem IP
Verkehr mehr trauen. Allein kryptographisch abgesicherte Verbindungen
sind dann noch vertrauenswuerdig. Die Schnueffler koennten durchaus
ftp.freebsd.org oder www.debian.org komplett faelschen (inclusive
aller denkbaren Checksums) - und den IP-Verkehr dorthin auf mehreren
Ebenen verbiegen: sei es durch das Faelschen von DNS Information, sei
es auf Ebene der Routingprotokolle.
Auch in diesem Falle ist ein kryptografisch abgesicherter Tunnel in
einen vertrauenswuerdigen und bekannten Netzwerkbereich die Antwort;
Wenn mein System nicht mehr den DNS meines Providers fraegt, sondern
einen SSL Tunnel zu meinem in Brasilien gemieteten Rootserver
benutzt, wo ich selber einen Nameserver betreibe, dann ist es -
zumindest auf der Ebene - fuer die Schnueffler vorbei.
Gleiches gilt sinngemaess fuer alle anderen Protokolle, die ich
benoetige um mein Hostendes System zu bootstrappen.
Selbstverstaendlich kann ich mir die Quellen oder Binaerpakete meiner
Distributionen auch per Post schicken lassen - wieder eine frage der
Paranoia.
Wie man sieht: technisch haben wir ein paar Moeglichkeiten.
Eigentlich haben wir das auch politisch, das ist aber ein Gebiet auf
dem ich mich wesentlich weniger kompetent fuehle.
Dennoch: Wir muessen diesen Ueberwachungswahnsinn stoppen! Demokratie
kommt von"daemos" (das Volk) und"kratein" (herrschen), und
bezeichnet eine Staatsform, in der die Gewalt vom Volke ausgeht.
Das"der Staat" und"die Regierung" nicht unbedingt die selben sind,
sehen wir deutlich an dem derzeit herrschenden Unrechtsregime in den
USA, und dass verbrecherische Regierungsformen auch in Deutschland
nicht undenkbar sind, hat die Vergangenheit bereits mehrfach gezeigt.
Die allgemeine Bildungslage der Bevoelkerung stuetzt auch nicht
gerade meinen Optimismus, und ich meine dass jetzt schon an viel zu
vielen Stellen nicht im Sinne des Volkes regiert wird, mit schlimmer
werdender Tendenz.
Deshalb fordere ich jeden auf, mitzuhelfen, dass derartige
Schnueffelmassnahmen gegen die Gesamtbevoelkerung politisch,
juristisch, ethisch und gesellschaftlich Tabu bleiben.
Jeder ist gefragt: Juristen, Techies, Politiker, Lehrer, Professoren,
und jeder Waehler an der Urne.
Noch haben wir die Wahl.
ZITATENDE
Gruss

gesamter Thread: