Sniffing mit Ettercap

Bei Ettercap handelt es um ein recht mächtiges Werkzeug, mit welchem ein Angreifer in der Lage ist eine Man-in-the-Middle-Attack (MITM) durchzuführen. Hierfür muss natürlich der Datenstrom erst mal zum Angreifer umgeleitet werden. Dazu sind andere Tools vorhanden, die diese Aufgabe durchführen können. Auf diese Weise können auch Verbindungen in einem geswitchten LAN angegriffen werden.

Meist interessiert sich der Angreifer für Passwörter. Schließlich möchte er Zugang zu persönlichen geschützten Bereichen erlangen, die ihm so erst mal verwehrt sind. Einfaches Mitschneiden der Datenverbindung ist auch eine durchaus lohnenswerte Angelegenheit, jedoch werden Kennwörter sehr häufig mithilfe SSL verschlüsselt übertragen. Und genau an dieser Stelle kommt der Angreifer mit beispielsweise Wireshark vorerst nicht so weit. Es muss also eine Möglichkeit geschaffen werden, sich genau dazwischen zu setzen, so dass die SSL Verbindung beispielsweise durch den Computer des Angreifers durch geschleift wird. An dieser Stelle wiederum, lässt sich das Kennwort einfach auslesen und der Zugriff auf die Daten wird im späteren Fall möglich. Dazu kann einfach der verschlüsselte Datenstrom mitgelesen werden, sollte sich der Angreifer nur die übertragenen Daten interessieren. Mit Ettercap kommt der Angreifer seinem gewünschten Ziel soweit recht nahe.

Wir gehen davon aus, dass der Angreifer sich Zugriff auf das Netzwerk des Opfers verschafft hat. Gerade in der heutigen Zeit, wo viele Benutzer WLAN nutzen, lässt sich oft ein Einfallstor finden, bzw. mit etwas Aufwand aufhebeln. Einige Nutzer schützen ihr WLAN gar überhaupt nicht mit einer Verschlüsselung (WEP, WPA oder WPA2) oder verwenden nur einen MAC-Filter, der sich auch recht leicht austricksen lässt. Der Angreifer muss also das Opfer dazu bewegen seine Verbindungen nicht zum Zielsystem aufzubauen, sondern zum Angreifer. Wurde die Verbindung zum Angreifer aufgebaut, wird sie entsprechend weitergeleitet zum eigentlichen Zielsystem. Und schon hängt der Angreifer dazwischen und kann Daten entsprechend ausspähen.

Eine Methode, um Verbindungen zu einem anderen Ziel-Host zu leiten kann das DNS-Spoofing sein. Wer zuerst antwortet, wird erhört, so ungefähr. Der Angreifer fälscht DNS Antworten (Spoofing) und sendet entsprechend eine Antwort, die auf seine dortige IP-Adresse verweist. Das Opfer baut nun eine Verbindung zum Angreifer auf. Antworten lokale DNS Server im LAN zu schnell, können diese mit einer DOS Attack entsprechend ausgebremst werden.

Eine weitere Möglichkeit ist das ARP Spoofing. Hier genauer ARP Cache Poisoning. Im LAN und auch genauso natürlich im WLAN werden Computer nicht direkt über IP adressiert, sondern über die MAC Adressen. Jeder Host, also angeschlossener Netzwerkcomputer jeder Art, besitzt einen kleinen Puffer, in dem er die Verknüpfung zwischen IP Adresse und MAC Adresse abspeichert. Ist die MAC Adresse bereits im Puffer so braucht das System keinen ARP Request zu senden und kann gleich loslegen. Existiert die MAC Adresse noch nicht, so fragt das System mit einem Broadcast nach. Dieser Broadcast wird von allen Maschinen empfangen und die Maschine, die gemeint ist, antwortet entsprechend. Das erste einlaufende Antwortpacket wird wieder genommen und entsprechend wird die Tabelle im Hostsystem erweitert. Dieser ARP Cache wird oft auch dann aktualisiert, wenn kein Request vorher abgesendet worden ist. Die Implementierungen variieren an dieser Stelle.

So sendet der Angreifer einfach gefälschte ARP Antworten des Zielsystems und schon wird entsprechend nach einiger Zeit der Cache des Opfersystems mit der Angreifer MAC Adresse vergiftet. Baut das System nun eine Verbindung zum Zielsystem auf, so werden die Pakete zur MAC Adresse des Angreifers gesendet. Wie bereits erwähnt wird in LANs mit MAC adressiert und nicht über IP. Somit empfängt der Angreifer die Daten. Der Angreifer wird somit zu einer Art Proxy Server. Diese kann er wiederum einfach nur mit Wireshark aufzeichnen und entsprechend einfach an den ursprünglichen Host weiterleiten oder er kann mit Ettercap entsprechend eine MITM Attack fahren.

Natürlich möchte der Angreifer möglichst etwas verschlüsseltes lesen, sonst könnte auch Wireshark einfach eingesetzt werden. Dazu erzeugt der Angreifer sich ein neues SSL Zertifikat. Das sollte natürlich möglichst so aussehen, wie das Zertifikat des zu fälschenden Zielsystems. Ettercap wird dieses nun verwenden, um die SSL Verbindung entsprechend entgegen zu nehmen. Damit wird sozusagen der SSL Datenstrom aufgebrochen und die entschlüsselten Daten werden ausgelesen. Also tippt der Angreifer in seiner Linux Konsole (Backtrack oder GRML sind als Live CD sehr empfehlenswert) folgendes ein: ettercap –newcert.

Beim Start von ettercap wird zunächst automatisch das Netzwerk nach vorhandenen Host abgesucht. Wenn dieser Vorgang abgeschlossen ist, zeigt Ettercap eine zweispaltige Tabelle jeweils mit allen gefunden Hostcomputern an. Der Angreifer wählt nun in der linken Spalte den anzugreifenden Client aus und in der rechten Spalte den entsprechenden anzugreifenden Server. Nun wählt der Angreifer die Schaltfläche ARP Sniff. Damit wird das ARP Poisoning eingeleitet und alle verschlüsselten Verbindungen lassen sich nun mitschneiden.

Das Opfer testet nun mithilfe der Shell mit arp -a (Windows Shell), ob das ARP Poisoning geklappt hat. Taucht die Angreifer MAC Adresse in Verbindung mit der Ziel IP des Fremdsystems auf, so hat das ARP Cache Poisoning geklappt. Nun entsprechend den Server mit einer SSL Verbindung ansprechend und sich dort einloggen. Da oft der Angreifer keine erweiterten Möglichkeiten hat, wird der Webbrowser sich beklagen, dass das Zertifikat nicht verifiziert werden kann, bzw. dem Zertifikat nicht vertraut wird. So kann das Opfer diesen Angriff alleine an dem nicht ganz korrekten Zertifikat erkennen. (Es sei denn der Angreifer lässt das Zertifikat von einem Trustcenter entsprechend korrekt signieren oder manipuliert die Root Zertifikate im Opferwebbrowser und signiert selbst)

Was kann das Opfer tun, um diese Manipulation zu erkennen? Erstens kann das Opfer prüfen, ob die URL mit der URL im Zertifikat übereinstimmt. Zweitens kann das Opfer überprüfen, ob die Chain of Trust verletzt wurde oder nicht. Also, ob das Zertifikat von einer autorisierten Stelle zertifiziert wurde. Der erste Punkt wird vom Angreifer korrekt erfüllt, da der Client davon ausgeht, dass er direkt mit dem Server kommuniziert. Die IP Adressen werden bei diesem Angriff nicht verändert. Der zweite Punkt allerdings ist schon weitaus schwerer. Aus diesem Grund sollte jeder Nutzer Warnungen dieser Art von seinem Browser sehr ernst nehmen.

Netzwerktools unter Linux – Schnüffler und MITM Programme

In der Linux-Welt existieren einige sehr nützliche Tools, die Netzwerkadministratoren, Sicherheitsbeauftragten und Hackern die Möglichkeit geben Daten mitzuschneiden. Die Tools sind weniger die Allrounder, allerdings besitzen alle ihre speziellen Fähigkeiten, die kombiniert erst ihre volle Wirkung entfalten. Es ist also etwas Puzzeln angesagt, steht das Bild, so fluppen die Daten nur so heraus. So lassen sich Daten abgreifen, Protokollfehler ermitteln oder Schwächen in einem Netzwerk aufdecken.

– Dsniff
Das Paket Dsniff beinhaltet ein Sammlung vielseitiger Netzwerktools, die hauptsächlich für Penetrationstests entwickelt worden sind. Es dienst dazu Schwächen im eigenen Netzwerk zu erkennen. Anschließend kann der Tester entscheiden, wie weit verschiedene erkannte Aspekte eine Bearbeitung bedürfen. Natürlich lässt sich dieses Paket auch für andere Analysen verwenden.

– arpspoof
Dieses Paket, bzw. Programm dient dem Fälschen von ARP-Paketen. Getestet werden kann damit die Sicherheit in LANs im Punkto einer Umleitung von Datenströmen. Beispielsweise kann mit dieser Software das Gateway entsprechend gespooft werden. Entsprechende Daten lassen sich anschließend ausleiten. Das Paket sendet gefälschte ARP-Pakete an bestimmte IP Adressen. In einem geswitchten Netzwerk lassen sich so auch einzelne Rechner entsprechend ausleiten.

– dnsspoof
Das Paket dnsspoof arbeitet ähnlich wie der ARP-Spoofer, jedoch schickt der gefälschte DNS-Pakete an Rechner. Damit kann man eine DNS-Auflösung insofern Ändern, das ein Computer die IP Adresse zu einem Angriffsrechner auflöst und entsprechend dorthin eine Verbindung aufbaut, anstatt zur „echten“ Adresse. Dies Tool kann damit den Grundstein für eine MITM-Attack legen.

– dsniff
Hat der Angreifer erst einmal den Datenstrom auf seiner Maschine, so kann das Auslesen von Kennwörtern von Wichtigkeit sein. Das Programm dsniff ließt als Passwort-Sniffer Kennwörter aus verschiedenen Protokollen, wie FTP, Telnet, SMB, IMAP, POP und HTTP. Es werden nur die Pakete abgelegt, die entsprechend Kennwörter beinhalten, nicht der ganze Netzwerkstrom.

– filesnarf
filesnarf ist ein File-Sniffer. Das Programm leitet übertragene Dateien aus dem Datenstrom aus. Beispielsweise wird eine Datei über das NFS Protokoll übertragen. Diese Datei wird erkannt und ausgeleitet. Ein Angreifer, der keinen Zugang zum NFS Server hat, kann auf diese Weise mit einer Umleitung des Traffic entsprechend übertragene Dateien in einem Netzwerk abfangen.

– macof
Möchte ein Angreifer den kompletten Traffic eines geswitchten Netzwerken sehen, so kann das Switch dazu überredet werden, entsprechend nach dem Standard sich als Hub zu verhalten. Dies geschieht, wenn der Mac-Adressen Speicher überfüllt ist. Somit erzeugt dieses Programm Pakete mit zufälligen Mac-Adressen und flutet damit den Speicher des Switch. Nach einiger Zeit sieht der Angreifer den Traffic des LANs. Nachteilhaft ist, das aufgrund des starken Performanceeinbruch die Benutzer schnell misstrauisch werden.

– mailsnarf
Mailsnarf ist ein Mail-Sniffer. Er leitet alle Mails aus den Datenströmen aus, die nicht SSL verschlüsselt sind. Das Protokoll POP und SMTP wird unterstützt.

– msgsnarf
Msgsnarf ist ein Nachrichten-Sniffer, der Inhalte von Chats ausließt. Unterstützt werden der AOL Messenger und ICQ, sowie MSN und Yahoo.

– sshmitm
Der Angreifer möchte die übertragenen Kennwörter beschaffen, die entsprechend über eine sichere SSH Verbindung gesendet werden. Hierzu sollte der Traffic auf die Angreifer-Maschine umgeleitet werden. Das Programm sshmitm versucht nun als eine Art Proxy die Daten einmal entgegenzunehmen und sie entsprechend weiter zur eigentlichen Zielmaschine zu senden. Hierzu ist auch das Tool dnsspoof nützlich, welches der Quellmaschine die Ziel-IP des SSH Servern vorgaukelt. Hat der Benutzer entsprechend das Zertifikat gespeichert, so wird entsprechend sofort ein Alarm angezeigt. Der Vorgang funktioniert nur, wenn der Benutzer achtlos einfach entsprechend das neue Zertifikat akzeptiert, ohne den Fingerprint zu prüfen.

– tcpkill
Das Programm tcpkill unterbricht laufende TCP-Verbindungen, indem Reset-Pakete entsprechend gefälscht und an die Maschine übertragen wird. Hiermit soll der Benutzer werden, erneut eine Verbindung zum Ziel-Rechner aufzubauen, die entsprechend möglichweise anschließend angegriffen werden soll. Ein Session-Hijacking könnte im Vorfeld auch versucht werden.

– tcpnice
Mit tcpnice wird eine Verbindung, durch die Anpassung der Flusssteuerung in den Paketen, die erlaubte maximale Datendurchsatzmenge entsprechend gebremst.

– urlsnarf
Möchte ein Angreifer alle angesurften URLs abgreifen, so kann er auf dieses Tool zurückgreifen. urlsnarf speichert alle URLs, die es aus dem HTTP Datenstrom abgreift in eine Protokolldatei. Damit entsteht ein Logfile, auf welchen Seiten sich die Benutzer bewegen.

– webmitm
Der Angreifer hat den Datenstrom mit einer DNS-Spoofing-Attack in seine Maschine geleitet. Nun möchte er SSL Verbindungen mit einer MITM Attack für ihn sichtbar machen. Dazu ist das Programm webmitm sehr nützlich und ermöglicht damit das Mitlesen von Kennwörtern. Das SSL Zertifikat muss entsprechend erzeugt werden, entsprechend getrustet sein. Das Opfer kann den Angriff durch Vergleich der Fingerprints erkennen. Auch wird der Browser warnen, falls das SSL Zertifikat des Angreifers nicht überprüft werden kann bzw. dem nicht vertraut wird.

– webspy
Das Programm webspy spioniert dem Quell-Host hinterher, indem es alle URLs aufruft, die durch den anderen aufgerufen worden ist. Der Angreifer kann so beobachten, wo der andere Benutzer surft.

Starcraft 2 Absturz unter Windows Vista beheben

Unter Windows Vista kann es beim Starten von Starcraft 2 Probleme geben. Die Software scheint einzufrieren und stürtzt ab. Vermutlich wird Blizzard recht schnell ein Fix liefern. Um das Problem zu umgehen kann folgendes gemacht werden, dann steht dem Spielgenuß nichts mehr im Weg. 🙂

– Änderungen der Firewalleinstellungen. StarCraft 2 zu den sicheren Anwendungen hinzufügen. Dazu die auszuführende EXE Datei in das etsprechende Menü hinzufügen.
– StarCraft 2 mit Administrationsrechten starten.
– Wenn dies noch nicht klappen sollte, in den Einstellungen auf den Fenstermodus umstellen.

Ein wichtiger Hinweis für Computersysteme mit persönlichen, sensiblen Informationen. Programme, die mit administrativen Rechten arbeiten haben Vollzugriff auf jede Datei im System. Das bedeutet, das ein entsprechender Exploit, falls einer existieren sollte, Zugriff auf eurer System erlaubt. Des weiteren hat natürlich die Applikation ebenso Vollzugriff auf alle Dateien. Hierbei spielt es keine Rolle, ob der Benutzer mit einem eingeschränkten Account sich bei dem System anmeldet oder nicht, da schließlich die Applikation entsprechend mit Admin-Rechten arbeitet. Falls also der Computer mit sensiblen Firmendaten gefüttert wurde oder anderweitig als sensibel eingestuft werden muss, sollte umbedingt ein neuer, anderer Rechner verwendet werden.

Eine kleine Koppel für den Streichelzoo

Es hat ein wenig gedauert. Überschattet wurde die doch sonst so einfache VM-Konfiguration durch einen sehr seltsamen Fehler im BIOS der Notebooks, die ich verwenden wollte. Sie booteten keine Datenträger mehr und ließen sich nur selten dazu bewegen das BIOS aufzurufen. Da half auch ein Reset nicht. Eine ungewöhnliche Sache, die ein durch ein wenig händisches Spielen in der Konfiguration ein Ende fand. Ja, BIOS Fehler, aber mein verblüffenster bisher. Ich denke mit der Zeit wird es ein Update geben.

Zurück zum Streichelzoo. In einigen VMs wurde ein XP installiert und entsprechend auf den neusten Stand sprich Patchlevel gebracht. Die Datenausführungsverhinderung an und Wireshark drauf. Nun das Tierchen erzeugen und installieren. Mit DAV startet es nicht und wird aus dem Speicher geworfen. Das war schonmal ein gutes Zeichen. Zumindest zeigte mir das praktisch, dass manche Malware mit eingeschalteter Datenausführungsverhinderung nicht läuft. Ein Grund mehr, es bei Arbeitsmaschinen auch einzuschalten. Nun aus damit, schließlich sollte ja das RAT (Remote Administration Tool) getestet werden. Es lief nun mit administativen Rechten.

Unter einem eingeschränkten Benutzer gab es auch einige Probleme. Auch wieder ein Grund mehr, den Benutzer zu bitten mit eingeschränkten Konten unter Windows zu arbeiten. Das RAT redete mit seinem Herrchen und konnte alle Funktionen erfolgreich ausführen. Unter anderem die Übertragung der Gespräche im Raum durch das angeschlossene Mikro und das Aktivieren der Webcam. Tastatureingaben gehören ja auch zu den Standardaufgaben solcher Programme.

Die Idee das ausführlich zu testen kam aus der Richtung, dass ich vor einer Woche RATs fand, die von keinem AV Programm, auch nicht im geringsten, als verdächtig eingestuft worden sind. Gut, dass wird nicht mehr lange so bleiben. Dennoch können Crypter ausführbare Dateien völlig umstricken und letztendlich wird ein gefundenes RAT wieder unsichtbar. Mit Wireshark schaute ich mir die versendeten Pakete an und fand eine Art Signatur, bei meinem Testobjekt. Damit lassen sich leicht Pakete mit diesem Inhalt und der entsprechende Größe aus dem Datenstrom löschen. Es wird genug andere Malware geben, die sich nicht so leicht in den TCP Paketen auffinden lässt.

Vielleicht macht es Sinn, internes Netzwerk und externes Internet zu trennen. Also keine physikalische Trennung mit unterschiedlicher Hardware, jedoch mit zwei Netzwerkkarten, die sich in zwei verschiedenen Subnetzen befinden. Das eine, um die Computer mit SMB und so weiter zu verbinden. Das Netz hat keinen Zugang zum Internet. Das zweite Subnetz ist logisch an das Internet angeschlossen. Auf diese Weise fällt wohlmöglich das Filtern der Datenpakete etwas leichter? Ich denke, dass werde ich probieren müssen. Vielleicht lassen sich auf diese Weise einige Trojaner so einsperren, dass wenn sie schon unsichtbar aktiv sind, nicht zu ihrem Herrchen telefonieren können?

Arima HDAMA Mainboard Treiber und Handbücher

Das Arima HDAMA Mainboard in Rev.F und Rev.G ist eine Mehrsockel-Hauptplatine für den Sockettyp 939. Betrieben werden können mit diesem Mainboard zwei AMD Opteron Prozessoren. Hierbei handelt es sich um 64-Bit CPUs. Das Board unterstützt, bzw. verlangt Registered Buffered ECC DDR Speicher. Wichtig hierbei ist, dass jeweils auf den Bänken die gleiche Anzahl von Modulen installiert wird. Empfohlen wird, jeweils ein gleichen Speicher der gleichen Serie zu installieren. Wenn Module verschiedener Hersteller gemischt werden, kann es zu seltsamen Problemen kommen. Dies ist allerdings ein allgemeiner Hinweis, der auch für andere Computermodelle gilt.

Leider ist die Herstellerwebseite offline. Aus diesem Grund werden hier die Rev.F und Rev.G Treiber und Handbücher für das Arima HDAMA Mainboard zur Verfügung gestellt.

Arima HDAMA Driver and Manual
Arima HDAMA Rev.G Driver and Manual

Betrieben werden können folgende Betriebssysteme mit diesem Baord:

– Linux (alle Versionen),
– Sun Solaris 10 (Der SATA Controller wird nicht erkannt werden),
– Microsoft Windows 95, 98, ME, 2000,
– Microsoft Windows 2003 Server,
– Microsoft Windows XP (32-Bit und 64-Bit)

Windows Vista und 7 arbeiten aufgrund mangelnder ACPI kompatibilität NICHT. Hierzu wäre ein BIOS Patch erforderlich, welches nicht mehr verfügbar gemacht zu werden scheint. Für Windows 2003 und XP ist die Version 2.17 erforderlich. Die Zip-Dateien beinhalten das letzte verfügbare BIOS Patch für die Arima HDAMA Boards.

Unsichtbare Fernadministration mobiler Geräte

Es ist immer wieder interessant. Je komplexer und funktionaler Geräte werden, je mehr unsichtbare Funktionen schleichen sich von geisterhand in diese ein und ermöglichen dem Hersteller bzw. anderen Firmen ihre Finger tief in die persönlichen Daten ihrer Nutzer zu stecken. Ist ja auch lukrativ. Hierzu gibt es einen interessanten Artikel.

Google kann Android-Apps aus der Ferne löschen

Google kann Android-Apps aus der Ferne löschen, so lautet die Überschrift des Artikel zu dem der obige Link führt. Das Installieren beliebiger Software ist ebenso möglich. Also auch das Installieren beliebiger Trojaner und Spyware, die dann auch praktischerweise nach und nach wieder deinstalliert werden kann. Das mindert die Beweislage. Würde man jemanden auf offener Straße fragen, ob dieser dem Fragenden seine Wohnungsschlüssel überlässt, würde er diesen Herrn vermutlich für verrückt erklären. Logisch eigentlich, oder?

Ob sich die Nutzer von Smartphones im Klaren sind, was Ferninstallation und Fernlöschung eigentlich bedeutet? Vermutlich eher weniger. Aus den Augen, aus dem Sinn, kann in dieser Sache auch gesagt werden. Solange der Bildschirm nichts anzeigt, ist alles gut. So glaubt der Nutzer scheinbar. Unternehmen, Google ist da nicht das einzigste, nehmen sich heraus, auf dem Produkt, dass ihre Kunden erworben haben, nach Belieben herumzufuhrwerken. Natürlich dient das nur zur eigenen Sicherheit. Klar. Wenn dies auf dem PC Markt geschehen würde, wäre die Sorgen vermutlich noch vorhanden. Beliebige Daten auf den PC schieben und ein bisschen hier installieren und dort löschen. Kein Anwender würde das gerne einfach so zu Hause zu lassen. Da wird nämlich jedes dubiose Anti-Spy Programm installiert, was irgendwo und irgendwie verfügbar zu sein scheint. 😉

Und beim Handy ist es plötzlich kein Problem? Richtig. Aus den Augen und so weiter. Mhnm, dann müsste ja auch jeder Anwender auf der Straße beliebige Fragen zu seinen Telefonpartnern gerne beantworten. Richtig? Nein. Komisch, oder? Schöne Frage: „Wen haben Sie heute alles angerufen?“ Man gehe davon aus, dass der Fragende ebenso nicht nur verrückt erklärt werden würde, sondern auch als überaus neugierig betitelt werden wird. Fakt ist, verschwinden die Daten hinten rum und niemand sieht es direkt, ist alles okay. Das ist, wie als würde man im Schlaf bestohlen werden. Solange der Einbrecher den Anwender nicht weckt, ist alles okay. 🙂 Ja, manchmal sogar macht es den Eindruck, als ob der Schlaf wird bei manchen sehr beliebten Smartphonebesitzern mit Rohypnol herbeigeführt wird… zumindest wenn das Anwenderverhalten bei einigen Menschen etwas betrachtet wird. 😉

Hier ein Abschnitt aus dem Artikel von ZDNet: „Auch Onlinehändler Amazon kann elektronische Bücher von den Lesegeräten seiner Nutzer löschen. Diese Möglichkeit hat der Händler vergangenes Jahr einmal wahrgenommen, als sich herausstellte, dass ein Verlag gar nicht die Rechte an einem E-Book besaß. Ein Schüler verlor auf diese Weise nicht nur seinen Text, sondern auch seine Aufzeichnungen, und klagte. Der Fall sorgte für weltweites Aufsehen, Amazon musste sich entschuldigen.“ Ja, jemand komme zu Ihnen nach Hause und nimmt sich ein paar Bücher aus ihren Regalen mit. Er erklärt Ihnen, dass diese ihnen nicht gehören und zieht von dannen. Der Mr. X. würde vermutlich nicht nur mit einem Besen verjagt werden. Solche Funktionen gehören in keinen E-Book Reader. Der Anwender sollte erst gar nicht auf die Idee kommen Produkte mit Funktionen dieser Art zu kaufen. Allerdings wird auch kein normaler Anwender ein Produkt auf solche Funktionen überprüfen können. Da beißt sich die Katze in den Schwanz.

Rat-Race durch die Matrix

Manchmal ist es sehr schade, nicht Chinesisch und Russisch zu beherrschen. Die Teile des Internets, die ausschließlich in dieser Sprache gehalten sind, haben hier und da besonders interessante Inhalte. Google war der Freund und half beim Übersetzen. Teils kam ein wirklich sehr verkrüppeltes Deutsch zustande, so dass der ursprüngliche Sinn des Textes zu einem großen Teil unterging. Nun ja, es konnten hier und da ein paar kleine Tierchen gefunden werden, darunter eine interessante Art der Hausratte.

Diese durchaus pflegeleichte, wenn auch wegen der Schriftzeichen vorerst nicht zu verstehenden Ratte, besitzt außerordentlich interessante Fähigkeiten. Die Opa-Ratte wurde bisher ein wenig erforscht und hatte ein paar telepathische Fähigkeiten weniger. Die aktuelle Art der Ratte hat ein paar kleine Psi-Fähigkeiten. Die Matrix oder besser die VM wird zuverlässig von der einen erkannt und in kleine Stücke zerrissen. Die VM klappt beim Auslaufen der Ratte in sich zusammen und das Hostsystem kommentiert diesen Vorgang mit einem Schweigen. Hatte sich das Tierchen aus der VM herausgeschlichen und nagt nun an den Bits und Bytes des Hostsystems?

Entdeckt wurde nichts, es scheint, dass eine Speicherspielei mit einem kräftigen Segmentgehüpfe zum Zusammenbruch der VM führt. Möglicherweise ist dies ein Feature, leider sind meine Fähigkeiten der genauen Analyse noch zu begrenzt, um wirklich etwas genaues sagen zu können. Allerdings wurde eine weitere Version entdeckt, die die gleiche Versionsnummer trägt. Diese ist an wenigen Stellen leicht verändert worden und startet zumindest.

Die Datenausführungsverhinderung bombt, wenn sie aktiv geschaltet ist, generell alle Prozesse der Hausratte aus dem Speicher. DA abgeschaltet allerdings startet die Variante und die VM bleibt auf den Beinen. So rate ich, es war ein Feature. Die Hausratte besitzt die üblich zu erwarteten Fähigkeiten. Mit dem „Scotty-Modus“ verschwindet sich von ihrem Urspungsort ins tiefere System und verweilt dort recht unerkannt. Allerdings lassen sich die Dateien vom Betriebssystem auffinden und löschen, also scheint keine intensive Root-Kit-Technik eingebaut zu sein. Allerdings taucht das Tierlein nicht in der Prozessliste auf, was stark zu erwarten war. Generell heftet sie sich an Prozesse, um störungsfrei nach draußen funken zu können. Gewisse Firewalls, die einen hohen Bekanntheitsgrad haben, lassen die Ratte nach draußen sprechen, ohne Alarm auszulösen. Der Vorgang lässt sich aber gut im Wireshark sehen. Da die Pakete der Ratte entsprechend innen signiert sind, lässt sich die ganze Ratten-Generation mindestens mit einem Deep-Paket-Filter einsperren. Somit kommt der Angreifer nicht an die Daten des Computers. Forefront arbeitet in Firmenumgebung in diesem Fall hervorragend. Natürlich existieren auch andere Lösungen aus dem OpenSource Bereich. Auch snort lässt sich mit einem Filter so ausstatten, dass es Alarm auslösen kann.

Die Übertragung von Sound, Webcam und Bildschirmübertragungen sind ganz interessant, besonders als Demo. Der Keylogger ist ausgezeichnet. Dieser speichert die Daten in die alternative Datenströme unter NTFS in eine Datei und dokumentiert, welches Fenster aktiv gewesen ist mit entsprechenden Bezeichnungen. Somit bleibt das Log sehr übersichtlich. Die Ratte wird aktuell von jedem guten AV-Programm erkannt. Mit einem Crypter kann man Abhilfe schaffen. Natürlich ist es einfacher den auch erhältlichen Sourcecode entsprechend ein wenig umzubauen und dann neu kompilieren. Das Übersetzen der Schaltflächen wäre dann mal was… oder einfach ein Language-File in XML einfach dazu bauen. 🙂

Arbeitsspeicher aufrüsten beim Lenovo S10

Es handelt sich bei dem Lenovo S10 um ein sehr gutes Netbook. Der Atom Prozessor ist recht flott, der Akku hält recht lang und auch das Display ist hell und ausreichend. Schön ebenfalls, dass der Benutzer auch bei starkem Sonnenlicht noch etwas sieht. Soweit so gut. Das Netbook könnte noch weiter gelobt werden, dies ist allerdings nicht Thema des Eintrages.

Das Aufrüsten des S10 mit weiterem Arbeitsspeicher ist recht einfach. Unten die Klappe öffnen und einen DDR2 S0-DIMM 667 Mhz Riegel dazustecken. Wichtig zu beachten ist, dass das Lenovo S10 nicht mehr als 2GB Arbeitsspeicher verträgt. Steckt der Benutzer einen 2GB Riegel in den Slot kann es gut sein, dass das Gerät anschließend nicht startet. Das Limit wird nicht überall wirklich erwähnt. Allerdings sind auch 2GB Speicher aktuell für das Surfen ausreichend. Auch mit Windows 7. Das S10-2 läßt sich mit mehr Speicher ausstatten. Also Augen auf, vorm Speicherkauf.

Gedanken und Aspekte zu Skype

Skype hat so ziemlich jeder auf seinem Computer installiert und das Produkt ist auch eine gute Sache. Auch in öffentlichen Bereichen kann man getrost chatten, reden und Daten austauschen, ohne sich Sorgen zu machen, dass beispielsweise im WLAN jemand mit Wireshark die Daten mitschneidet und auswertet. Auch im kabelgebundenen LAN ist dies von Vorteil. Also verschlüsselt sind die Daten und damit ist es sicher? Gewiss nicht. Genauer gesagt, nein.

Skype mag zwar die Daten von dem Nutzersystem verschlüsseln, aber wer hat denn nun den Schlüssel zum entschlüsseln? Ja gut, den hat der Gesprächspartner, aber wer noch? Diese Frage lässt sich nicht wirklich klären, der Phantasie ist hier keine Grenze gesetzt, da niemand wirklich genau weiß, wie Skype arbeitet.

Skype sagt, dass die Daten mit AES mit einem 256 Bit Schlüssel verschlüsselt werden. Dazu soll der Schlüssel mittels RSA mit einem 1024 bis 2048 Bit Schlüssel ausgetauscht werden. Gut, am Ende gibt es, ich sage mal, einen Session-Key der 256 Bit groß ist. Wie der Schlüssel zustande kommt, ist nicht gesagt.

Überlege man sich eine Möglichkeit. Ein AES Schlüssel wird aus dem Hashwert des Benutzernamens gebildet. Natürlich wäre das keine gute Idee, das doch der Benutzername auf jeden Fall bekannt ist. Na gut, der Hashwert des Benutzernamens bilden, davon die Hälfte der Zeichen mit der anderen Hälfte XORen und dazu etwas anderes hinzufügen. Etwas besser, nicht das Gelbe vom Ei, besonders, weil Teile in jedem Fall bekannt sind und ein Bruteforce nicht mehr in die weiteste Ferne rückt. Was gesagt werden soll: Eine gute Verschlüsselung ist wertlos, wenn die Erzeugung des Schlüssels murks ist oder er in falsche Hände gerät.

Schlimm wird es auch, wenn bekannt ist, wie das Schlüsselkomponieren zustande kommt. Wenn dieses noch dazu führt, den Schlüsselraum von 256 Bit auf ich sage mal 32 Bit zu reduzieren, dann sozusagen Gute Nacht. Nun, keiner weiß, wie Skype arbeitet und da noch keiner das Programm seziert hat, wird auch keiner sagen können, wie das nun geht mit der Schlüsselerzeugung.

Jetzt ein weiterer Aspekt. Wo befindet sich der Session Key? Normalerweise ist der ein geteiltes Geheimnis zweier Gesprächspartner. Wenn ein Dritter diese Schlüssel besitzt, so kann er einfach mit entschlüsseln, also mithören. Keiner weiß, ob die Software nicht irgendwo den Schlüssel an einer Stelle dem Server übermittelt oder nicht. Fakt ist, dass die chinesische Version das TOM-Skype eine Abhörfunktion beinhaltet. Im Jahre 2008 deckten Menschenrechtsaktivisten der Forschergruppe „Citizen Lab“ der Universität Toronto auf, dass in China Skype Nachrichten auf gewisse Begriffe untersucht und diese speichert. Auch wurden laut Citizen Lab in diesem Zusammenhang Informationen mit persönlichen Daten, wie Benutzernamen, IP-Adresse oder die Telefonnummern mit protokolliert. Der Benutzer muss davon ausgehen, dass die Infrastruktur, auch hierzulande funktioniert. Ob das stimmt oder nicht, weiß niemand. Natürlich würde auch niemand so etwas zugeben. Nun stellt sich vermutlich jede Zweite die Frage, in wie weit dies relevant ist, da ja der Normalverbraucher nichts geheimes oder verwerfliches ausspricht. Nun ja, wir haben hier nicht umsonst ein Telekommunikationsgeheimnis. Spätestens, wenn hochprivate Daten der Normalverbraucher in Google auftauchen und öffentlich diskutiert wird, ändert sich die Sensibilität. Privatsphäre ist ein freiheitliches Gut.

Kurt Sauer, der Leiter der Sicherheitsabteilung von Skype, antwortete auf die durch ZDNet gestellte Frage, ob Skype die Gespräche abhören könnte, ausweichend: „Wir stellen eine sichere Kommunikationsmöglichkeit zur Verfügung. Ich werde Ihnen nicht sagen, ob wir dabei zuhören können oder nicht.“ Persönlich finde ich solch eine Antwort sehr interessant. Wo lang werden die Pakete eigentlich geroutet? Nicht immer direkt von A nach B.

Ein anderer technische Gedanke. Skype verfügt über sehr intensiven Systemzugriff. Daten lesen, Webcam aktivieren, Sound und so weiter. Im Prinzip lädt sich jeder Benutzer eine unbekannte Software auf sein System (weil keiner weiß, was sie genau eigentlich kann, bzw. alles so unsichtbar macht) und vertraut, dass sie nicht böse nicht. Vielleicht ist sie das auch nicht, vielleicht ist sie auch die interessanteste Art und Weise, die mit dem Wort Spionage beschrieben werden kann. Wieviele Firmen haben Skype im Betrieb? Skype ist sehr intensiv gegen Debugging und Analysen geschützt. Viele versteckte Integritätsprüfungen testen, ob etwas verändert worden ist oder nicht. Wenn ja, verhält sich das Programm anders. Letztendlich ist das Disassemblieren von Skype eine wirklich üble Angelegenheit. Das spricht nicht immer für ein gutes Gefühl, diesem Programm teils administrative Rechte zu geben. Auch die Fähigkeit durch NAT und Firewall sich durchzuwurschteln, erscheint einigen Benutzern als unheimlich. Allerdings ist das STUN Protokoll nichts neues und auch viele andere Produkte haben ähnliche Fähigkeiten.

Installation von CAPI4HylaFax unter Kubuntu 10.04

Nachdem beschrieben wurde, wie eine AVM Fritz!Card unter Linux zum Laufen zu bewegen ist und wie entsprechend die CAPI Schnittstelle eingerichtet werden muss, wird jetzt ein weiterer Schritt folgen. Das Verwenden der CAPI Schnittstelle mit HylaFax. Verwendet wurde hier Kubuntu 10.04 bzw. Ubuntu in der gleichen Version. Als Treiber der hier angesprochen fcpci Treiber, der entsprechend gepatched worden ist. Für einige Konfigurationsangelegenheiten wird das Paket dialog benötigt, falls es nicht bereits installiert worden ist. Der Anwender gibt ein:

# apt-get install dialog

Nun ist es an der Zeit das Paket für CAPI4HylaFax zu installieren. Wieder bemühen wir apt-get.

# apt-get install capi4hylafax

Nachdem das Paket installiert worden ist, müssen einige Konfigurationsänderungen durchgeführt werden. Falls nicht schon geschehen, werden die Rechte der CAPI Schnittstelle geändert. Der Benutzer uucp und die Gruppenmitglieder in der Gruppe dialout sollen auf diese zugreifen können. Hierzu gibt der Anwender folgendes ein:

# chown -R uucp:dialout /dev/capi*

Nun wird zur Gruppe dialout die Gruppe uucp hinzugefügt. Die dazu nötigen Informationen stehen in der Datei /etc/group. Diese wird mit einem Editor geöffnet. Jede Zeile beinhaltet eine Einstellung, so sucht der Benutzer die korrekte Zeile die ungefähr so lauten könnte: dialout:x:20:username. Hinter den Benutzernamen wird entsprechend die Gruppe eingetragen. Also lautet die Zeile dann folgendermaßen:

dialout:x:20:username,uucp

HylaFax verwendet standardmäßig das Gerät /dev/faxCAPI, um auf die CAPI-Schnittstelle zuzugreifen. Unsere CAPI-Schnittstelle liegt aber auf /dev/capi*, als Wildcard für meistens /dev/capi20. Unnötiges Geschrubbel soll vermieden werden, also lassen wir /dev/faxCAPI auf /dev/capi20 verweisen. Dies geschieht mit einem symbolischen Link, der auf das Dateisystem geschrieben wird. Um das zu bewerkstelligen, geben wir folgendes ein:

# ln -s /dev/capi20 /dev/faxCAPI

Nun wird alles von /dev/faxCAPI zu /dev/capi20 umgeleitet. Beim Systemneustart allerdings sind die Einstellungen nicht mehr vorhanden. Zumindest nicht alle. Die Rechte werden durch die Defaultwerte überschrieben. Also wird ein Startscript angepasst, das jene Dinge für uns macht, die sonst per Hand erledigt werden müßten. Dieses Script exestiert unter /etc/rc.local. Nun wird diese Datei mit einem Editor geöffnet und entsprechend angepaßt.

# pico /etc/rc.local

Diese Datei sollte folgendermaßen aussehen.

#!/bin/sh -e
#
# rc.local
#
/bin/chown -R uucp:dialout /dev/capi*
/bin/ln -s /dev/capi20 /dev/faxCAPI
/etc/init.d/capi4hylafax restart
/etc/init.d/hylafax restart

exit 0

Nun ist es fast soweit. Kleine weitere Änderungen müssen noch verrichtet werden, damit alles korrekt läuft. Die Datei /etc/default/capi4hylafax muss leicht angepaßt werden. Die Einstellung run_capi4hylafax muss auf true, also auf 1 gesetzt werden. Dies sieht in der Datei so aus:

run_capi4hylafax=1

Die obige Datei ist natürlich recht lang und besteht nicht nur aus einer Zeile. Nun wird die Datei /etc/default/hylafax etwas angepaßt.

# pico /etc/default/hylafax

In dieser Datei werden zwei Zeilen verändert. RUN_HYLAFAX wird entsprechend auf true, also 1 gesetzt und USE_FAXGETTY wird auf no, also nein, gesetzt. Es soll ja kein analoges Modem verwendet werden, sondern die CAPI Schnittstelle.

USE_FAXGETTY=no
RUN_HYLAFAX=1

Jetzt muss eine Datei in dem Verzeichnis /etc/init angelegt werden. Diese Datei lautet hylafax.conf.

# touch /etc/init/hylafax.conf

Diese Datei wird wieder mit einem Editor geöffnet und folgende Zeile wird eingefügt:

T5:23:respawn:/usr/bin/c2faxrecv

Nun die Datei /etc/hylafax/config bearbeiten, um folgende Zeilen zu ändern. Die Datei ist länger, hier sind nur die Änderungen aufgeführt.

# pico /etc/hylafax/config

SendFaxCmd: "/usr/bin/c2faxsend"
DialStringRules: "etc/dialrules"
InternationalPrefix: 011
SendFaxCmd: "/usr/bin/c2faxsend"
Use2D: "no"
MaxTries: 1
MaxDials: 3

Nun sollte geprüft werden, ob das Paket psrip installiert ist. Wenn nicht muss dieses nachinstalliert werden.

# apt-get install psrip

Nun muss die Datei /etc/hylafax/setup.cache verändert werden. Hier wird eine neue Zeile eingefügt.

IMPRIP='/usr/bin/psrip'

Nun die Datei /etc/hylafax/config.faxCAPI wieder mit einem Editor öffnen und entsprechend bearbeiten.

# pico /etc/hylafax/config.faxCAPI

SpoolDir: /var/spool/hylafax
FaxRcvdCmd: /usr/bin/c2faxrecv
PollRcvdCmd: /var/spool/hylafax/bin/pollrcvd
FaxReceiveUser: uucp
FaxReceiveGroup: dialout
LogFile: /var/spool/hylafax/log/capi4hylafax
LogTraceLevel: 4
LogFileMode: 0600
{
HylafaxDeviceName: faxCAPI
RecvFileMode: 0666
FAXNumber: +49.800.123456
LocalIdentifier: "DEIN NAME"
MaxConcurrentRecvs: 2
OutgoingController: 1
OutgoingMSN: 89012345
SuppressMSN: 0
NumberPrefix:
UseISDNFaxService: 0
RingingDuration: 0
{
Controller: 1
AcceptSpeech: 1
UseDDI: 0
DDIOffset: "12345"
DDILength: 3
IncomingDDIs:
IncomingMSNs: "8901234"
AcceptGlobalCall: 0
}
}

Nun die Dienste neu starten. Das geht so:

# /etc/init.d/hylafax restart
# /etc/init.d/capi4hylafax restart

Wenn keine Fehlermeldungen erscheinen, kann entsprechend nun gefaxt werden. Kabel anstecken nicht vergessen. Faxen geht in der Konsole so:

sendfax -n -d Faxnummer Datei.ps

Viel Spaß.