PVA: Emails abhören mit Carola

Wieso labbert Mich Deine Carola voll, ich soll in die Küche kommen?“ fragte meine Freundin und zog wieder ab, weil ich nur verschmitzt grinste. Ein erfolgreicher Testlauf, auch wenn der technisch gar nicht Ihr galt, sondern natürlich Carola selbst. Naja, irgendwie braucht man ja Feedback 😉

PVA: Emails abhören mit Carola

Da Carola jetzt meine Email mitlesen kann und davon auch heftigst Gebrauch macht, genau wie mein Emailprogramm, sollte ich Euch jetzt erklären Sie das geht. Vorher sollte ich aber noch erwähnen, daß mein Test darin bestand mir am Handy eine Email zu schreiben, in deren Betreff die Anweisung für meine Freundin enthalten war 😉 Das sie in die Küche kam, war der Beweis, daß Carola den Job erledigt, wenn ich nicht da bin. Man sollte aber daran denken, daß, wenn man so etwas vorhat, man vorher sicherstellen muß, daß die Zielperson für die Ansprache auch in Hörweite ist 🙂

Erstmal die Regeln:

1) Das ist kein Feature, daß man global aktiviert, ergo, es gehört in eine Konfig in Eurem $HOME.

2) Ihr könnt Euch aussuchen, ob nur der Betreff oder die ganze Email gelesen werden soll.

3) Wer GTTS benutzt, sollte sich ihm klaren sein, daß Google damit Infos bekommt, die es nicht haben sollte. Also im Zweifel MaryTTS nutzen, da sind die Emailinhalte sicherer.

4) Es wird nur die INBOX ausgelesen, nicht irgendwelche Unterverzeichnisse.

5) Es wäre eine Straftat nach §303b StGb, einen entsprechend konfigurierten Sprachassistenten von Extern mit Mails zu bombardieren, um Werbung oder sonstige Parolen in die Welt schreien zu lassen. Ich rate dringend von solchem Unsinn ab, das wird für Euch nicht gut ausgehen:

(1) Wer eine Datenverarbeitung, die für einen anderen von wesentlicher Bedeutung ist, dadurch erheblich stört, dass er

1. eine Tat nach § 303a Abs. 1 begeht,
2. Daten (§ 202a Abs. 2) in der Absicht, einem anderen Nachteil zuzufügen, eingibt oder übermittelt oder
3. eine Datenverarbeitungsanlage oder einen Datenträger zerstört, beschädigt, unbrauchbar macht, beseitigt oder verändert,

wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft.

So aktiviert Ihr das IMAP-Feature

Die Konfiguration im Format …

# mailbox:"servername","username","password","commonname","secure","port","readoutloud","pullinterval"

kommt in ein Konfigfile unter ~/.config/pva/conf.d/ z.B. 09-imap.conf .

Beispiel:

mailbox:"imap.domain.de","harry.mud@gmail.com","30243klSXLS3os3S!X#","Mailbox from Harry Mudd","true","143","false","60"

Der Flag „readoutloud“ (false/true) würde die gesamte Email vorlesen, wenn er aktiviert (true) ist.

Im Beispiel ist der Benutzername des Kontos als Email angegeben, so wie das bei einigen Diensten der Fall ist. Ihr braucht eigentlich nur Server- , Username und Passwort, der Rest ist eigentlich bis auf readoutloud egal. Gewöhnt Euch nicht dran, fliegt vermutlich raus.

Ihr könnt beliebig viele Mailboxen eintragen.

Das passiert dann

Die Mailbox wird 1x pro Minute geöffnet und ermittelt, ob eine neue Email da ist. Ist eine neue Email vorhanden UND diese noch ungelesen, dann wir per Sachausgabe der Absender und der Betreff vorgelesen.

Gewöhnt Euch aber daran, daß nach dem Starten des Desktops die nächtliche Flut von Emails abgearbeitet wird. Konten mit aktiven Cryptonews-Mailinglisten würde ich da nicht eintragen, daß wäre mir zu stressig 🙂

Wichtige Security Info dazu:

PVA: kleines Sicherheitsloch im IMAP Modul

… und weiter im Text:

Damit Ihr keine neue Features mehr verpasst, habe ich Euch ein Fedora Repository eingerichtet. Am besten lest Ihr Euch das hier mal nach:

PVA: Carola hat Ihr eigenes Repo bekommen

Spearphising mit den eigenen Mails

Da ich gerade aus unserer Kundschaft die zweite Information zu so einem Vorfall bekommen habe, möchte ich Euch heute vor einer aktuellen Phishing Methode mit besonders hoher Erfolgswahrscheinlichkeit warnen.

Spearphising mit den eigenen Mails

Zwei unserer Kunden haben sich mit seltsamen Emails an uns gewendet, beide hatten DOCX Anlagen dran, aber der Inhalt war eine alte Email, die von dem vermeintlichen Absender an das Opfer früher schon einmal gesendet wurde.

Da kommen nur zwei Ursachen für in Frage: ein Hack eines Pcs oder der Hack den Mailserverkontos.

Klar, ein Hack des Mailservers an sich wäre auch möglich, aber deutlich unwahrscheinlicher als der Hack von einem Windows PC. In einem Fall konnten wir das aufklären, da sind die Angreifer an die Daten des Mailkontos und die darin befindlichen Emails gelangt. Ob der PC geknackt wurde und die Daten da abgezogen wurden, oder ob die per BruteForce den Mailserver durchgetestet haben, ist nicht bekannt. Da der Mailserver über eine Bruteforcesperre verfügt, ist der Hack des Windows PCs wahrscheinlich.

In dem aufgeklärten Fall, ist der PC/Konto des Absenders des Virus-Docxs gehackt worden. Es würde ja auch nur bedingt Sinn machen, einem bereits infiltrierten PC noch mal einen Trojaner zu schicken, oder? 🙂

Wenn Euch also demnächst DOCX Files in Emails unterkommen, die Ihr die Tage vorher schon mal ohne Virusanhang in der Post hattet, dann ruft den Absender sofort an und informiert ihn über den Vorfall, weil er/sie/es dann ein dickes Problem hat.

DS GVO: Email Transportverschlüsselung wird Pflicht sein

Willkommen im Chaos des Datenschutzes. Ich hatte ja schon lange den Verdacht, daß EMails auch nur noch mit TLS übertragen werden dürfen, wenn man zum Datenschutz verpflichtet ist. Dabei habe ich mich aber immer gewundert, wieso das nie in der Presse steht. Jetzt wird sich das hoffentlich hektisch ändern.

Die Meinungen zur TLS Verschlüsselung von Emails

Wie uns Rechtsanwalt Schwartmann auf seiner Webseite wissen läßt, ist ab Freitag aufgrund der Datenschutz Grundverordnung wahrscheinlich eine TLS Verschlüsselung für eingehende und ausgehende Emails Pflicht, sofern man ein Unternehmen betreibt oder aus anderen Gründen zum Datenschutz verpflichtet ist.

Nach Ansicht des Landesbeauftragten für Datenschutz und Informationsfreiheit Nordrhein-Westfalen ist eine Transportverschlüsselung auf jeden Fall erforderlich:
Bezüglich der sicheren Implementierung der Transportebene hat das Bundesamt für Sicherheit in der Informationstechnologie die Technische Richtlinie „BSI TR-03108-1: Secure E-Mail Transport“ herausgegeben.
Unter datenschutzrechtlichen Gesichtspunkten ist diese Richtlinie als Stand der Technik zu betrachten, so dass ihre Umsetzung eine notwendige Voraussetzung für die datenschutzkonforme E-Mail-Kommunikation ist.

Quelle: https://www.rechtsanwalt-schwartmann.de/verschluesselungspflicht/
„(Ende Zitat)

Die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit hat uns heute morgen endlich wissen lassen, daß nur der Einsatz von TLS 1.2 in Frage kommt:

„Inwieweit ein Provider, der die Infrastruktur zur Verfügung stellt, eine Option anbieten muss, die ausschließlich den Empfang von TLS 1.2 transportverschlüsselten E-Mails zulässt, beurteilt sich nach dem gegenwärtigen Stand der Technik.

Der gegenwärtige Stand der Technik ist, daß TLS 1.2 seit 2008 das Maß der Dinge ist. Der Nachfolger TLS 1.3 wird aber bald kommen, da die Planung des Standards kürzlich beendet wurde. Das hält aber gerade den BUND, wo die Information her ist, nicht davon ab, auch heute noch mit TLS 1.0 zu senden 😀 (Böser Dienstleister vom Bundmailserver 😉 )

IMHO

Ich schließe mich dieser Meinung an, da auch ich die DS GVO so interpretiere, daß alle Kommunikationskanäle verschlüsselt sein müssen. Wie einfach das gehen kann, zeigt folgende Anleitung :

Zunächst mal wählen wir im Account unter „Mailserver“ die „EMail-Options“ aus:

Nun aktivieren wir die beiden obersten Punkte:

„Verbindung zum Server benötigt Verschlüsselung“ und „Empfangener Mailserver muß TLS benutzen“

Das war es dann auch schon, jetzt kommen nur noch TLS gesicherte EMails an den Mailserver ran. Damit entspricht das Mailserververhalten dem geltenden Datenschutzrecht.

Wer es ganz genau nehmen will, der müßte auch noch DANE implementieren, da dies in einer BSI Richtlinie zum Thema gefordert wird. Da DANE aber AFAIK noch nicht 100% ausgereift ist, könnte der Teil schwierig werden, was nicht heißt, das einige Provider dies nicht schon implementiert hätten.

Bei Exim ist grade eine passende Diskussion gestartet worden.

Quellenlinks:

https://www.ldi.nrw.de/mainmenu_Aktuelles/Inhalt/Technische-Anforderungen-an-technische-und-organisatorische-Massnahmen-beim-E-Mail-Versand/Technische-Anforderungen-an-technische-und-organisatorische-Massnahmen-beim-E-Mail-Versand.html

https://www.rechtsanwalt-schwartmann.de/verschluesselungspflicht/

https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03108/index_htm.html