Die Platte in Tokyo einhängen

Die Idee ist schon fast zehn Jahre alt, aber es hat wohl eine Weile gedauert bis es funktioniert hat. Der Traum in Tokyo ein USB-Gerät in einen PC zu hängen und in Kenia zu benutzen, funktioniert tatsächlich. Die Lösung lautet: USBIP

Wie funktioniert das ?

Es gibt einen USBIP-Server und einen Clienten. Der Server bindet Geräte ein und stellt Sie im Netz zur Verfügung. Der Server sorgt auch dafür, daß das Gerät lokal nicht mehr zur Verfügung steht. Damit kann es bei der Benutzung keine Kollisionen geben. Der Client verbindet sich zum Server und bindet das USB-Gerät dann lokal ein und stellt es, wie jedes andere Gerät zur Verfügung.

Damit das funktioniert müssen einige Kernel-Module geladen werden. Praktischerweise ist alles was man so braucht im Paket dabei. Alles in allem ein ziemlich übersichtlicher Vorgang.

Die Installation

Die Installation ist ganze einfach:

sudo dnf -y install usbip

Das wars schon.

WARNUNG

Wie man im Beispiel sehen wird, greifen die Befehle direkt auf IP Adressen zu. D.h. wenn Ihr ein Gerät freigebt, kann jeder, der es über das Netzwerk erreichen kann, es auch benutzen. Das kann im Einzelfall ein Problem werden. Daher ist eine Begrenzung des Zugriffs per IP-Firewall zwingend notwendig.

Der USBIPd stellt die Option zur Verfügung, sich auf einen bestimmten Port zubinden :

–tcp-port PORT Listen on TCP/IP port PORT.

Damit kann man, zumindest theoretisch, mehrere Dienste parallel benutzen und somit die Freigabe per Firewall regeln.

Beispiel – Eine Kamera benutzen

Der Server hat IP 192.168.0.103. Auf dem wurden zur Vorbereitung folgende Befehle ausgeführt:

[root@warrior marius]# modprobe usbip-host
[root@warrior marius]# usbipd &

nun müssen wir natürlich noch wissen, welches Device wir überhaupt freigeben müssen:

[root@warrior marius]# usbip list -l
– busid 2-3 (0ac8:0302)
Z-Star Microelectronics Corp. : ZC0302 Webcam (0ac8:0302)

[root@warrior marius]# usbip bind -b 2-3
usbip: info: bind device on busid 2-3: complete

„usbip list -l“ listet die zur Verfügung stehenden lokalen Geräte auf.
„usbip bind -b 2-3“ bindet das USB Gerät mit der ID 2-3 an den usbipd, so daß es exportiert werden kann.

Auf der Clientseite ist das ähnlich einfach:

[root@eve marius]# modprobe vhci-hcd

Das Kernelmodul i.d.R. immer nötig, es können aber auch andere Module zusätzlich benötigt werden.

[root@eve marius]# usbip list -r 192.168.0.103
Exportable USB devices
======================
– 192.168.0.103
2-3: Z-Star Microelectronics Corp. : ZC0302 Webcam (0ac8:0302)
: /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3
: (Defined at Interface level) (00/00/00)

Wie man sehen kann, ist das Gerät jetzt verfügbar. Nun müssen wir es noch lokal einfügen:

[root@eve marius]# usbip attach -r 192.168.0.103 -b 2-3

und nun können wir es benutzen, da es wie jede andere WebCam als Videogerät zur Verfügung gestellt wurde:

[root@eve marius]# camorama -d /dev/video0
… jede Menge unnötige Fehlermeldungen später …
name = medium
name = large

Wenn man es wieder abmelden will, muß man den lokalen USBIP Port kennen:

[root@eve marius]# usbip port
Imported USB devices
====================
Port 00: <Port in Use> at Full Speed(12Mbps)
Z-Star Microelectronics Corp. : ZC0302 Webcam (0ac8:0302)
12-1 -> usbip://192.168.0.103:3240/2-3
-> remote bus/dev 002/004
[root@eve marius]# usbip detach -p 00
usbip: info: Port 0 is now detached!

Das wars. Jetzt noch auf dem Server mit unbind entfernen:

[root@warrior marius]# usbip unbind -b 2-3
usbip: info: unbind device on busid 2-3: complete

und das Gerät ist wieder lokal benutzbar.

Anwendungen

Per SSH-VPN könnte man damit z.b. WebCams in Rechenzentren benutzen, oder Festplatten einbinden, die vollverschlüsselt sind, auch wenn der „Server“ kompromittiert wurde, denn die Verschlüsselung läuft auf dem lokalen Rechner, ein MITM-Angriff kann damit nicht stattfinden. USB-Tastaturen und Mäuse würden auch lustige Sachen erlauben 😉

Bitlocker unter Linux öffnen

Ihr erinnert Euch noch diesen c’t Uplink Beitrag, wo die Heise Redakteure über Bitlocker und Luks schwadroniert haben?  Damals wurde Bitlocker als „properitär“ eingestuft und sinngemäß gesagt:  „Um Festplatteverschlüsselung zu machen, brauchst Du eh die PRO Version, die Home kann das nicht“. Da hat sich was getan 😉

Bitlocker für Linux

Vor drei Tagen kam eine Updatemeldung von Fedora zu einem Produkt namens „Dislocker“ rein. Der Name versprach etwas spannendes, also habe ich mir die Meldung angesehen:

Name        : dislocker
Product     : Fedora 28
Version     : 0.7.1
Release     : 10.fc28
URL         : https://github.com/Aorimn/dislocker
Summary     : Utility to access BitLocker encrypted volumes
Description :
Dislocker has been designed to read BitLocker encrypted partitions ("drives")
under a Linux system. The driver has the capability to read/write partitions
encrypted using Microsoft Windows Vista, 7, 8, 8.1 and 10 (AES-CBC, AES-XTS,
128 or 256 bits, with or without the Elephant diffuser, encrypted partitions);
BitLocker-To-Go encrypted partitions (USB/FAT32 partitions).

Das Tool gibts als FUSE Modul, so daß die Bitlocker-Partition zur Laufzeit eingebunden und Gelesen sowie Geschrieben werden kann, und als Einmal-Komplett-Entschlüssler. So oder so, man kommt an die Daten ran.  Damit ist Linux jetzt Windows offiziell voraus 😀

Ob das eine gute Idee war/ist wird sich zeigen, aber eins kann man Bitlocker damit nicht mehr nennen: properitär. Zumindest nicht mehr im ganz engen Sinn. Es wird natürlich nur von M$ produktiv eingesetzt, aber immerhin, wie auch bei NTFS, kann man es jetzt auf anderen Plattformen ( Ja, Macs machen auch mit ) benutzen.

@Heise-Redaktion: Wird Zeit für einen neuen c’t Uplinkbeitrag zu dem Thema. Da könnt Ihr gleich die ganzen Gerüchte vom letzten mal berichtigen, von wegen Luks wäre unpraktisch, keine Passworteingabe usw. usw. 😀 PS: wenn Ihr schon dabei seid: Mit LUKS einen USB Stick verschlüsseln und Double Layer Encryption mit Veracrypt falls Euch die Beispiele ausgehen 😉

Fehler in der Security

Der Grund für das Update war dann übrigens das Beheben von drei CVE-Schwachstellen in der genutzten Cryptobibliothek, wie man auf der Projektseite nachlesen konnte u.a. :

ID: CVE-2018-0497
Impact: Allows a remote attacker to partially recover the plaintext
Severity: High

Im Bereich Crypto ist das quasi eine 11 von 10 möglichen Punkten auf der Richterskala (+1 weils Remote geht  😉 ).

Den Schlüssel für die Bitlocker Partition könnt Ihr bei Microsoft erfragen, falls Ihr den vergessen haben solltet 😉

Wie dämlich muß man sein…

Diese Logzeile habe ich grade aus dem Mailserver gezogen:

2018-10-09 10:44:35 SMTP protocol synchronization error (next input sent too soon: pipelining was not advertised): rejected „GET / HTTP/1.1″ H=[107.170.202.125] next input=“Host: mailserver:26\r\nUser-Agent: Mozilla/5.0 zgrab/0.x\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n“

Ich übersetz mal :

GET / HTTP/1.1
Host: mailserver:26
User-Agent: Mozilla/5.0 zgrab/0.x
Accept: */*
Accept-Encoding: gzip

Wenn man sich das genau ansieht, wobei „MAILSERVER“ unsere Mailserver IP war, wird man bei HOST das irritierende „:26“ entdecken. Die Portnummer gehört im HTTP Protokoll gar nicht in den „Host:“- Header rein, trotzdem hat dieses miserable Script es angehängt. Unser Glück, so kann man das aufklären 🙂

Es handelt sich offenbar um einen Portscanner, der bei „nicht-so-standart“-Ports wie „26“ , einfach mal austestet, ob da nicht ein Webserver zu finden ist. Vielleicht in der Hoffnung da was zu finden, was auf Port 80 nicht zu finden wäre, wer weiß. Auf Port 26 hat unser Mailserver einen Ausweichport, falls der DSL-Router des Kunden mal wieder Port 25 für alles außer T-Offline-Mailservern sperrt. Das hat sich in der Vergangenheit extrem gut bewährt, weil man im Mailprogramm nur statt Port 25 26 angeben brauchte und schon war diese leidige Routersperre umgangen.

Eingeführt haben die Routerhersteller das, damit die ganzen gehackten Windows-Pcs nicht ständig das Netz mit Spams beglücken. Das war aber nur bedingt erfolgreich 😉

Wie kam ich jetzt auf dämlich, achso ja, weil sich der Mailserver natürlich, wie auf Port 25 auch, sofort als Mailserver outet 🙂 Man muß also nicht erst HTML hinschicken um zu sehen was es ist 😀

richtig gute Phisingmail für die Sofortüberweisung Co. KG

Ich hatte schon lange keine Spam/Trojaner/Phisingmails mehr über die ich berichten konnte, weil sich jahrelang nichts am Niveau der Emails geändert hat. Deswegen freut es mich auch, daß ich heute mal eine präsentieren kann, die in ordentlichem Deutsch verfaßt wurde, aber aus Bulgarien stammt:

Sehr geehrte(r) Axel Mustermann, 

leider konnte Ihre Überweisung an Sofortüberweisung Co. KG nicht verbucht werden. 

Wir erwarten die ausstehende vollständige Zahlung bis spätestens 05.10.2018 auf unser Bankkonto. Falls wir bis zum genannten Termin keine Überweisung bestätigen, sehen wir uns gezwungen unsere Forderung an ein Gericht abzugeben. Sämtliche damit verbundenen Kosten werden Sie tragen müssen.

Um zusätzliche Mahnkosten zu vermeiden, bitten wir Sie den ausstehenden Betrag auf unser Konto zu überweisen. Aufgrund des andauernden Zahlungsrückstands sind Sie verpflichtet zusätzlich, die entstandene Gebühren von 12,99 Euro zu tragen.

Berücksichtigt wurden alle Buchungseingänge bis zum 28.09.2018.
Ihre persönliche Kostenaufstellung liegt unter folgendem Link zum Download bereit.

Bei Rückfragen erwarten wir eine Kontaktaufnahme innerhalb von 48 Stunden.


Mit verbindlichen Grüßen

Sofortüberweisung Co. KG
10178 Berlin
USt-Id: DE 266468424
Sitz der Gesellschaft: Berlin

Die Mail kam am 1.10. rein, d.h. der Spammer hat da tatsächlich mal auf fast alles geachtet. Was er nicht richtig gemacht hat, sieht man im Emailheader:

Received: from fwd05.aul.t-online.de (fwd05.aul.t-online.de [172.20.27.149])
	by mailout05.t-online.de (Postfix) with SMTP id B4E2D42736D4
	for <a.mustermann@web.de>; Mon,  1 Oct 2018 04:23:27 +0200 (CEST)
Received: from www.stargate.by (VsozMrZVohaIxcK-h5wF--b+zynNoGv71sXPFO21KEWQhLH5BAxhdko3rMKrOKIgx9@[178.124.141.134]) by fwd05.t-online.de
	with (TLSv1:DHE-RSA-AES256-SHA encrypted)
	esmtp id 1g6nCA-3jKFrU0; Mon, 1 Oct 2018 03:23:21 +0200
Date: Mon, 1 Oct 2018 05:22:22 +0300
To: Axel Mustermann <a.mustermann@web.de>
From: =?utf-8?Q?Sofort=C3=BCberweisung_Co=2E_KG?= <a.dickenbrok@t-online.de>
Message-ID: <443a5cfb4db2c0d8da39a5035228f9d3@www.stargate.by>

Er konnte den Absender nicht vollständig kontrollieren, weil das sonst der Mailserver von T-Online nicht angenommen hätte. Ansonsten ganz nett gemacht. Zeitlich knappes Fenster. Drohkulisse. Alles was man so braucht um die Schafe zu scheren. Allerdings muß ich mich auch bei dem unbekannten Spammer beschweren 😉

Werter Herr,

Sie sind ein Spammer mit Sitz in Bulgarieren und unterliegen damit der Europäischen Datenschutzverordnung. Wie können Sie es wagen Artikel 32 nicht zu beachten ? Der fordert Verschlüsselung auf Stand der Technik und das ist NICHT TLS V1.0 . Sauerei!

Wo wir grade bei der EU DS GVO sind : Ich hoffe für Sie, das Sie die Emailadressen nach allen Vorschriften für Datenverarbeiter lagern. Wenn Sie erwischt werden, sollten Sie das nachweisen können, ansonsten 4% Jahresumsatz weg! Und wo sind eigentlich Ihre Technisch Organisatorischen Maßnahmen… WO KANN MAN IHRE DATENSCHUTZERKLÄRUNG EINSEHEN!?! Was sind Sie nur für ein Krimineller?!?  Einfach kein Format mehr, diese möchtegern Reddingtons.

Neues Spammerabzockmodel entdeckt

Laut Jim Clausing vom InternetStormCenter ( ISC ) könnte es eine neue kreative Form der Abzocke bei Spams geben:

Die Bezahl-Mich-Fürs-Nicht-Spammen Methode

Analog zur Ransomware mit Krypto-Trojanern, fordert der Spammer hier Geld per BitCoin, damit er aufhört Spams an diese Adresse zu senden. Da es natürlich nicht nur einen Spamclan auf der Welt gibt, und Verbrecher an sich ja so notorisch zuverlässig sind, ist Bezahlen natürlich keine Option 😉

Dem Spammer muß man aber zu gute halten, daß er wenigstens mal was originelles gespammt hat 😀