Benötigt werden ein „Fachübersetzer“ und IT-Verantwortliche einen guten Durchblick

Von unserem Gastautor Marcel Mock, CTO und Mitgründer von totemo

[datensicherheit.de, 20.07.2021] E-Mails sind im Arbeitsalltag von zentraler Bedeutung: Unternehmen erreichen fast alle Kunden, sowohl Endverbraucher als auch Firmen, sowie ihre Geschäftspartner auf diesem Weg. Eine starke E-Mail-Verschlüsselung zählt deshalb zu den wichtigsten Grundlagen, um geschäftskritische oder personenbezogene Daten bei der Übertragung und Speicherung vor dem Zugriff durch Unbefugte zu schützen. Deshalb sollten sich IT-Sicherheitsverantwortliche mit den Standards TLS, PGP/OpenPGP, MIP und S/MIME auseinandersetzen. Dabei wird schnell klar: E-Mail-Verschlüsselung benötigt einen „Fachübersetzer“ und IT-Verantwortliche einen guten Durchblick.

TLS: Der Transportschutz

Bei TLS (Transport Layer Security) handelt es sich um ein kryptografisches Protokoll, das den Transportkanal zwischen Absender und Empfänger verschlüsselt. Der Vorteil einer solchen „Transportverschlüsselung“ liegt darin, dass während der Übertragung selbst Metadaten wie Absender und Empfänger, Betreff und Zeit des Versands nicht von außen einsehbar sind.

Dafür müssen die Mail-Systeme des Versenders und Empfängers direkt miteinander kommunizieren. Das ist jedoch meistens nicht gegeben, sodass die Verschlüsselung nur bis zum nächsten Knotenpunkt greift. Deswegen raten Experten dazu, das TLS-Protokoll mit einer Inhaltsverschlüsselung wie S/MIME oder PGP zu kombinieren. Das gleicht die Schwächen von TLS aus.

Marcel Mock, CTO und Mitgründer von totemo, Bild: totemo

PGP: Ziemlich gut, aber komplex

PGP steht für „Pretty Good Privacy“ und verschlüsselt im Gegensatz zu TLS den Inhalt einer E-Mail, der unabhängig vom Übertragungskanal dann nur vom berechtigten Empfänger lesbar gemacht werden kann. Dieser Standard setzt bei der Validierung eines Schlüssels auf ein „Web of Trust”. Öffentliche Schlüssel werden dabei dezentral von vielen Personen zertifiziert. Das gewährt die Sicherheit unter der Annahme, dass ein potenzieller Angreifer nur schwerlich gleichermaßen alle täuschen kann, die zuvor den Schlüssel signiert haben. Auf der anderen Seite bleibt im Dunkeln, wer überhaupt zur Zertifizierung beigetragen hat.

Obwohl PGP zu einem der wichtigsten Standards zählt, greifen aufgrund mangelnder Benutzerfreundlichkeit hauptsächlich technikaffine Firmen und Privatnutzer aus der IT-Community auf PGP zurück. Ein Grund ist, dass der Standard nicht in alle gängigen E-Mail-Clients integriert ist – eine konsistente Nutzererfahrung fehlt also.

Microsoft 365 bietet eine Alternative mit MIP

Mit Microsoft Information Protection (MIP) in Microsoft 365 (M365) gibt es prinzipiell eine sehr nutzerfreundliche Option, um E-Mails mit einer weitverbreiteten Lösung zu verschlüsseln. Allerdings gilt das hauptsächlich für Geschäftskunden – selten für Privatnutzer.

Anwender sollten außerdem hellhörig werden: Der Cloud-Anbieter besitzt die Schlüssel für die Verschlüsselung. US-Behörden können sich auf den CLOUD Act von 2018 berufen, um US-Unternehmen dazu zu zwingen, personenbezogene Daten selbst dann herauszugeben, wenn sie auf Servern im Ausland liegen. Wer sich darauf einlässt, übergibt Microsoft sozusagen eine Geldkassette, auf deren Unterseite der Schlüssel klebt.

S/MIME

Die Inhaltsverschlüsselung S/MIME erfreut sich einer ähnlichen Bekanntheit wie PGP und hat den Vorteil, bereits in gängige Mail-Clients integriert zu sein. Da keine zusätzlichen Plug-ins oder Downloads erforderlich sind, bietet S/MIME eine hohe Nutzerfreundlichkeit – auch für M365. Daher greifen viele Unternehmen auf diesen Standard statt auf PGP zurück.

Im Unterschied zu PGP sieht der Standard für die Validierung von öffentlichen Schlüsseln eine kleine Anzahl von zuverlässigen Zertifizierungsstellen vor. Auch wenn das Verfahren nicht unfehlbar bleibt, bietet es den Nutzern mehr Sicherheit als das Web of Trust von PGP, bei dem faktisch jeder die Funktionen der Zertifizierungsstelle übernehmen kann, quasi ohne Aufsicht

Eine echte Allround-Lösung ist leider auch dieser Standard nicht, weil er – wie fast alle Verfahren – erfordert, dass ihn sowohl Absender als auch Empfänger nutzen. Dazu kommt, dass Anwender ihre Schlüssel und die von Kommunikationspartnern verwaltenmüssen– keine triviale Aufgabe.

Gesucht: Flexibler Fachübersetzer

Es gibt also viele gute Verschlüsselungsstandards – diese sind jedoch wie Sprachen: Sender wie auch Empfänger müssen dieselbe Sprache sprechen, um verschlüsselte Nachrichten „zu verstehen“. Eine Alternative sind Push- und Pull-Verfahren, bei dem der Empfänger keine eigene Verschlüsselung nutzen muss. Diese sind sehr sicher und erlauben es dem Nutzer ohne eigene Verschlüsselung, die verschlüsselte E-Mail entweder als Anhang einer E-Mail im eigenen Postfach zu öffnen oder auf einem externen Web-Portal – je nach gewählter Methode.

Auf technischer Ebene kann ein E-Mail-Gateway helfen, das die gängigsten Standards „spricht“. Dieses übernimmt die Verschlüsselung im Hintergrund, indem es vor dem Versand einer E-Mail prüft, welchen Standard der Empfänger beherrscht und die Nachricht des Absenders automatisch entsprechend verschlüsselt. Dadurch wird die E-Mail-Verschlüsselung nutzerfreundlicher und kann möglichst breit gewährleistet werden.

Weitere Informationen zum Thema:

datensicherheit.de, 12.03.2021
Rückverfolgbarkeit und Authentizität in der E-Mail-Kommunikation

PSW GROUP rät zur Multi-Faktor-Authentifizierung und Verschlüsselung via TLS

[datensicherheit.de, 17.09.2018] Das Sicherheitsunternehmen Lacework stieß im Internet auf über 22.000 öffentlich zugängliche Managementoberflächen zur Verwaltung von Containern, die vorrangig zum Open-Source-System Kubernetes gehören. Darauf machen die IT-Sicherheitsexperten der PSW GROUP aufmerksam: „Das hätte Unbefugten die Möglichkeit eines kompletten Zugriffs auf die Containerverwaltung spendiert. Via API und User Interface wäre Angreifern schlimmstenfalls sogar eine Remote Code Execution möglich“, verdeutlicht Geschäftsführer Christian Heutger die Tragweite der Entdeckung.

Unternehmen müssen heutzutage immer schneller neue Anwendungen, Erweiterungen und Updates auf den Markt bringen. Dazu bedienen sie sich so genannter Microservices. Deren „Verpackung“ wird als Container bezeichnet. Ein Container enthält neben der eigentlichen Anwendung alle Abhängigkeiten wie Bibliotheken und Konfigurationsdateien. „Wer viele Container betreibt, braucht aber auch eine komfortable Verwaltung. Eines dieser Verwaltungssysteme ist Kubernetes, das die Bereitstellung, Verwaltung und Skalierung von Container-basierten Anwendungen automatisiert. Es erfreut sich insbesondere bei Entwicklern, CTOs und IT-Architekten großer Beliebtheit. Typisch für die Kubernetes-Plattform ist eine Web-Oberfläche, die mittels Public Cloud über öffentliche IP-Adressen zu erreichen ist. Laut Lacework sind nun also rund 22.000 dieser Managementoberflächen öffentlich zugänglich“, erklärt Heutger die Hintergründe.

Wenngleich laut Lacework die Mehrheit aller Zugänge mithilfe von Login-Daten geschützt war, standen doch 305 der aufgespürten Cluster offen. „Sie waren also entweder nicht durch ein Passwort geschützt oder aber sie befanden sich gerade im Setup-Prozess. Unter anderem gehörten dazu auch 38 Server für Containerumgebungen des Health-Check-Dienstes Healthz, zu denen Zugriff ohne Zugangsdaten möglich war“, so Heutger.

© PSW Group

Christian Heutger, Geschäftsführer der PSW GROUP,

Das Ausmaß wird deutlich bei einem Blick auf die von Lacework veröffentlichten Zahlen: 95 Prozent der aufgespürten Management-Oberflächen werden bei Amazons Web Services (AWS) gehostet. Knappe 80 Prozent der Oberflächen gehören zu Kubernetes, die restlichen 20 Prozent zu Swarmpit und Docker Swarm. Weitere Oberflächen waren von Swagger API, Red Hats Openshift und Mesos Marathon erreichbar. Mehr als die Hälfte der offenen User Interfaces (UI) werden in den USA gehostet, es folgen Irland, Australien, Deutschland, Singapur sowie Großbritannien.

Dabei sind es nicht ausschließlich die ungeschützten Interfaces, die problematisch sind. Auch bei den mit Zugangsdaten geschützten Managementoberflächen ist die Angriffsfläche hoch: „Cyberkriminelle könnten Sicherheitslücken ausnutzen, auf Zertifikate zugreifen oder Dictionary- sowie Brute-Force-Angriffe starten. Aus diesem Grund empfiehlt sogar Kubernetes-Initiator Google, das Kubernetes-UI zu deaktivieren“, ergänzt Heutger. Für einen sicheren Umgang mit Containerverwaltungen sind deshalb nach Meinung des IT-Sicherheitsexperten sowohl eine Multi-Faktor-Authentifizierung, als auch das Regulieren des Zugangs von UI- und API-Ports empfehlenswert. „Aber auch ein so genannter Bastion Host und eine sichere Verschlüsselung via TLS und valide Zertifikate helfen“, so Heutger.

Weitere Informationen zum Thema:

PSW GROUP
Schock: Lacework entdeckt tausende ungeschützte Containerverwaltungen

datensicherheit.de, 16.09.2018
Europas Unternehmen mit Nachholbedarf im Bereich Cloudsicherheit

datensicherheit.de, 06.09.2018
Mehr Vertraulichkeit im Internet durch DNS über HTTPS

„Breach“-Weiterentwicklung ohne vorherigen Lauschangriff erfolgreich

[datensicherheit.de, 18.08.2016] Laut einer Mitteilung der PSW GROUP haben Forscher der Universität Leuven Timing-Angriffe in „JavaScript“ mit der „Breach“-Attacke kombiniert und damit ein Angriffsszenario erschaffen, das sie „HTTP Encrypted Information can be Stolen through TCP-windows“ (HEIST) nennen. Angriffe gegen „SSL/TLS“ ließen sich mit dieser Methode direkt im Browser durchführen, warnt Christian Heutger, Geschäftsführer der PSW GROUP. Bislang habe ein Angreifer dazu „Man-in-the-Middle“-Attacken durchführen müssen. Mit dieser neuen Methode müsse er den verschlüsselten Traffic nun nicht mehr überwachen können.

Mittels „JavaScript“ die Länge komprimierter und verschlüsselter Informationen extrahieren

Das Forscherteam Tom Van Goethem und Mathy Vanhoef habe herausgefunden, dass sich mithilfe von „JavaScript“ die Länge komprimierter und verschlüsselter Informationen extrahieren lasse. Die Funktionsweise des „Transmission Control Protocols“ (TCP) habe den Forschern geholfen: Bei TCP übertrage der Server zunächst zehn Pakete und warte dann auf Antwort seitens des Clients, um anschließend mehr Pakete zu übertragen. Zwei „JavaScript“-Funktionen ermöglichten Angreifern herauszufinden, wie viel Zeit solche Requests brauchten. Die Server-Antwort im ersten Zehnerpack der TCP-Pakete verlaufe zügiger als Antworten mit mehreren Paketen; dafür werde ein neuer Roundtrip notwendig. Probiere der Angreifer mit reflektierten Parametern herum, finde er heraus, auf welche Größe er die Parameter setzen müsse, um diese in das erste Zehnerpack einzufügen bzw. um es exakt ein Byte groß zu gestalten, erläutert Heutger.
Und genau das ermögliche nun den bereits 2013 vorgestellten „Breach“-Angriff. Lediglich die Antwortlänge müsse ein Angreifer anpassen, um dann durch die Antwortzeit darauf schließen zu können, ob das Folgezeichen korrekt erraten sei.

„Man-in-the-Middle“ gänzlich unnötig

Der Standard HTTP/2 erlaube eine zweite Variante des Angriffs: Hierbei würden sämtliche HTTP-Requests über nur eine TCP-Verbindung geschickt. So klappe der Angriff selbst dann, wenn sich das interessante Geheimnis und der reflektierte String auf verschiedenen Seiten befänden. Das Untermogeln des kontrollierten „JavaScripts“ stelle leider keine Hürde dar, denn gerade Ad-Netzwerke gestalteten ihre Produkte nicht sonderlich sicher und es brauche nur eine „JavaScript“ verwendende Werbeanzeige, so Heutger. Somit müsse der Angreifer nicht einmal den Netzwerkverkehr seines Opfers mitlesen – belauschen via „Man-in-the-Middle“ sei damit gänzlich unnötig.

© PSW Group

Christian Heutger: HEIST-Angriffe gegen „SSL/TLS“ direkt im Browser durchführbar

„Same-Site-Cookies“ als gangbare Lösung

HEIST durch Abschalten der Kompression zu begegnen, sei keine effiziente Lösung. HTML-Daten ließen sich bestens komprimieren und ein Verzicht würde immense Performance-Einbußen nach sich ziehen.
„Geheime Daten nicht zu komprimieren, wäre mit der HTTP/2-Headerkompression HPACK möglich, allerdings ist dies für Daten innerhalb des HTML-Parts schwer machbar. Eine einfache Lösung ist, Third-Party-Cookies im verwendeten Browser zu deaktivieren. Allerdings könnte es passieren, dass dann womöglich nicht mehr alle Websites uneingeschränkt aufrufbar sind“, sagt Heutger.
Stattdessen verweist der IT-Sicherheitsexperte auf „Same-Site-Cookies“ als gangbare Lösung: Webapplikationen könnten durch „Same-Site-Cookies“ verhindern, dass sich Site-Zugriffe von anderen Websites in Accounts einloggten. Bislang liege bei der IETF (Internet Engineering Task Force) lediglich ein Entwurf für „Same-Site-Cookies“ vor, jedoch würden sie von Googles Browser „Chrome“ bereits unterstützt.

Weitere Informationen zum Thema:

PSW GROUP, 09.08.2016
Verschlüsselung / HEIST: Angriff auf TLS ohne MITM

Viele Unternehmen vernachlässigen immer noch ihre E-Mail-Sicherheit / GROUP Business Software mahnt zusätzliche Verschlüsselung der E-Mail-Inhalte an

[datensicherheit.de, 19.09.2014] Trotz Sensibilisierung für das Thema Datenschutz und Datensicherheit beim Austausch geschäftsrelevanter Informationen per E-Mail vernachlässigen offenbar zahlreiche Unternehmen und Behörden immer noch ihre E-Mail-Sicherheit: In einem automatisierten TLS-Check des Bayerischen Landesamtes für die Datenschutzaufsicht fehlte bei rund einem Drittel von 2000 Probanden die Transportverschlüsselung TLS sowie die Unterstützung von Perfect Forward Secrecy für den E-Mail-Versand.

„Unternehmen sind nach Paragraph 9 des Bundesdatenschutzgesetzes dazu verpflichtet, Verschlüsselungsverfahren bei den von ihnen eingesetzten Mailservern nach aktuellem Stand der Technik zu verwenden“, macht Andreas Richter, Vice President Marketing bei GBS, aufmerksam. In diesem Zusammenhang erachten die Datenschützer den Einsatz von StartTLS zur Verschlüsselung der Kommunikation zwischen Mailservern als erforderlich.

Der Einsatz des Verschlüsselungsprotokolls StartTLS entspricht damit zwar dem Stand der Technik, ist jedoch kein Ersatz für eine Ende-zu-Ende-Verschlüsselung mit PGP oder S/MIME: „TLS ist die serverseitige Verschlüsselung des Datenaustausches auf Transportebene. Konkret bedeutet dies, dass die E-Mail-Übertragung vom sendenden zum empfangenden Mailserver verschlüsselt erfolgt. Diese kann jedoch von technisch gut ausgerüsteten Hackern angegriffen werden. Eine Ende-zu-Ende-Verschlüsselung dagegen verschlüsselt zusätzlich die Inhalte einer E-Mail gegen unbefugte Zugriffe“, erklärt Richter. Der Einsatz einer solchen E-Mail-Verschlüsselungslösung gestalte sich aufgrund ihrer Komplexität für viele Unternehmen jedoch schwierig und verhindere oftmals einen unternehmensweiten Einsatz.

© GROUP Business Software AG

GROUP Business Software mahnt zusätzliche Verschlüsselung der E-Mail-Inhalte an

Die Verschlüsselungslösung iQ.Suite Crypt Pro von GBS wird dagegen auf dem vorhandenen Mailserver integriert und macht somit eine Installation auf den Arbeitsplätzen überflüssig. Der gesamte Prozess der Ver- und Entschlüsselung wird damit auf dem Server realisiert. Das zentrale, serverbasierte Verfahren reduziert die Anzahl notwendiger Schlüssel sowie Zertifikate, integriert PKI-Strukturen und ermöglicht so ein effizientes Schlüssel- und Zertifikatsmanagement. Das Produkt unterstützt zudem die gängigen Verfahren wie PGP und S/MIME.

Die Integration der Lösung ist sowohl unter IBM Notes/Domino als auch Microsoft Exchange/SMTP möglich und erlaubt zudem einen geräteunabhängigen Einsatz auf Smartphones und Tablets.

Weitere Informationen zum Thema:

GBS
E-Mail Sicherheit

[datensicherheit.de, 11.04.2014] Der „Heartbleed Bug“, über den derzeit in den Medien berichtet wird, ist eine Sicherheitslücke in einer Programmerweiterung von OpenSSL namens „Heartbeat“. OpenSSL ist eine freie Software-Bibliothek für Transport Layer Security (TLS) und umfasst Implementierungen verschiedener Verschlüsselungen. Insbesondere Web- und Mail-Server aber auch andere Dienste wie Virtual Private Networks oder Appliances wie Router nutzen häufig diese Bibliothek für TLS/SSL-Verbindungen. Die Bibliothek enthält in den Versionen 1.0.1 bis 1.0.1f eine Schwachstelle, den „Heartbleed-Bug“.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stuft diese Schwachstelle als kritisch ein. Ein Angreifer ist unter Ausnutzung der Schwachstelle in der Lage, Speicherinhalte des OpenSSL Servers auszulesen, sofern diese die „Heartbeat“-Erweiterung aktiviert haben. Mithilfe des „Heartbleed Bugs“ können zudem unter Umständen die geheimen Schlüssel von OpenSSL-Servern ausgelesen werden.

Seit dem 7. April 2014 steht mit OpenSSL Version 1.0.1g ein Update zur Verfügung, das die Sicherheitslücke schließt. Betreiber, die auf ihren Servern OpenSSL einsetzen, sollten das Update umgehend einspielen. Falls seit März 2012 eine verwundbare OpenSSL-Version mit aktivierter Heartbeat-Erweiterung eingesetzt wurde, kann eine vergangene Kompromittierung von Schlüsseln nicht ausgeschlossen werden. Daher empfiehlt das BSI in einem solchen Fall den Austausch der verwendeten OpenSSL Server-, beziehungsweise Client-Zertifikate und Schlüssel sowie eine Änderung der verwendeten Passwörter. Der Austausch sollte erst nach der Einspielung des Updates erfolgen, da ansonsten die neuen Zertifikate wieder kompromittiert werden könnten. Die alten Zertifikate müssen nach erfolgreichem Austausch gesperrt werden. Betreiber sind aufgerufen, ihre Nutzer über die Umsetzung der Aktualisierung zu informieren, damit diese ihre Passwörter kurzfristig ändern.