Leserbriefe Juli 2019

Nicht nur der Nutzer, auch der Client

(Phishing: Awareness-Projekt der Landeshauptstadt Kiel;  5/2019, S. 78)

Auch wenn der Mensch hier wie so oft die Schwachstelle ist, wird es den Menschen, die E-Mails einsetzen, durch die gängigen E-Mail-Programme nicht unbedingt leichter gemacht, eine Phishing-E-Mail zu erkennen. Viele E-Mail-Programme zeigen per Default die E-Mail-Adresse nicht an, nur den Namen vor der eigentlichen Adresse, wenn Adresse oder Name schon mal in irgendeiner Form vom E-Mail-Programm zwischengespeichert wurde. Ein anderes Problem ist auch die mittlerweile wohl übliche HTML-Ansicht vom E-Mail-­Inhalt. Es ist ja schon schön, wenn in der E-Mail alles schön bunt formatiert ist, aber Links nicht dahin führen, was sie eigentlich anzeigen, und auch andere „Nettigkeiten“ im HTML-Code versteckt werden können. Vielleicht sollte man hier auch mal an die Entwickler von E-Mail-­Programmen appellieren, dass die Standardeinstellungen eher der Sicherheit des Benutzers dienen und nicht dem Komfort. Wer es bunt mag, kann dies ja dann abweichend von den Standardeinstellungen sich immer noch antun.

Ralf Nägele, via E-Mail

Kein Hinweis auf Adressfälschung

(Internetkriminalität: CEO-Fraud: Wenn der „Chef“ zur Geldüberweisung auffordert;  6/2019, S. 78)

Interessanter Text, aber mir fehlte der Hinweis, dass – auch wenn es in diesem Fall nicht genutzt wurde – Absenderadressen genauso leicht gefälscht werden können wie der angebliche Name des Chefs. Es ist schön, dass der Finanzchef in diesem Fall die falsche Adresse bemerkt hat, aber leider ist es ja nicht ausreichend, darauf zu trainieren.

Hamsterimrad, aus dem iX-Forum

PGP hilft hier wirklich

(Internetkriminalität: CEO-Fraud: Wenn der „Chef“ zur Geldüberweisung auffordert;  6/2019, S. 78)

Wenn ich von meinem Chef eine dienstliche Mail bekomme und die ist nicht verschlüsselt und valide signiert, dann weiß ich, dass diese Mail nicht echt ist. Aber, ja, ich weiß, nicht jeder hat dieses Glück bei der Arbeitgeberwahl.

Lars Rohwedder, aus dem iX-Forum

Zu hoher Sicherheitsanspruch

(Follow-up: Datenschutz-GAU Office 365;  6/2019, S. 30)

Leider bin ich mit dem Artikel erneut nicht besonders glücklich – leider auch aus fast denselben Gründen wie beim ersten Ar­tikel über Sicherheitsprobleme bei ­Office 365: 

• Ich finde es nach wie vor sehr befremdlich, dass der Sicherheitsanspruch einer Bürosoftware höher sein soll als der ­einer Webanwendung. Wie verhält es sich dann mit Salesforce, das sowohl eine Bürosoftware als auch eine Web­anwendung ist?

• Die Microsoft-Antwort wurde unnötig lächerlich gemacht, allerdings wäre es besser gewesen, zu überlegen, was gemeint ist. Um ein Root-Zertifikat zu installieren, werden Admin-Rechte benötigt. Der Angreifer musste also bereits Admin-Rechte erlangt haben, um den Rechner derart zu kompromittieren. Auf einem kompromittierten Rechner ist aber mit bestem Willen kein sicherer Office-­Betrieb möglich, da rettet Pinning beim Setup auch nichts.
• Es wird der Hashing-Vorschlag auf eine „flapsige Formulierung“ geschoben, die unhaltbare Wortwahl „Klartext“ wird sogar erneut verwendet. Interessanterweise steht da jetzt nur, dass hashen doch nicht gemeint ist. Mir ist jetzt nicht klar, was nun überhaupt mit Hashing gemacht werden soll (und warum es im ersten Artikel erwähnt wurde) oder welche Verfahren denn stattdessen gemacht werden sollten. Ich finde, hier wäre das Einräumen von Fehlern besser gewesen, zumal offensichtlich die Verständnisprobleme deutlich tiefer liegen. Es wird danach schon wieder von „Veri­fizierung des Servers“ geschrieben, allerdings findet der erste Login im Browser statt und auch die Office-365-Registrierung ist im Embedded-­Browser. Pinning wird dort – wie in der letzten iX angemerkt – nicht mehr unterstützt und anders lässt sich im Browser diese Verifikation nicht umsetzen.
• Unabhängig davon, ob man den Rechner bereits kompromittieren konnte, wurde das MitM-Szenario nicht gut zu Ende gedacht. Wenn ich den Datenverkehr mitlesen und manipulieren kann, ist es völlig unerheblich, ob der Google- oder Microsoft-Installer das Server­zertifikat fest in die Installationsroutine eingebrannt hat. Zum einen muss man sich mit einem Browser einloggen, um es herunterzuladen, sodass der Angreifer das Kennwort kennt, zum Anderen kann der Angreifer auch einfach an der Stelle ein manipuliertes Setup unterschieben. Warum sollte der Angreifer erst das Original-Setup durchlassen und dann die nachgeladenen Files tauschen?
• Der Seitenhieb auf das Verhalten von Edge ist leider völlig daneben. Bei dem Versuchsaufbau wurde der Zertifikatsstore des Internet Explorer/Edge vom Angreifer mit einem falschen Root-Zertifikat „vergiftet“. Firefox nutzt bekanntermaßen einen eigenen Zertifikats­store, nicht den von Windows/IE/Edge. Vergiftet man diesen auf dieselbe ­Weise – durch Installieren des MitM-Root ­Zertifikats –, wirft er selbstverständlich ebenfalls keine Warnung aus. Dieses muss logischerweise auch so sein, sonst könnte man die Funktion, eigene Root-Zertifikate zu installieren, auch ausbauen.
• Die Formulierung „Wir konnten den TLS-verschlüsselten Datenverkehr durch eine Man-in-the-Middle-Attacke aufbrechen“ ist ebenfalls mindestens flapsig, eigentlich aber falsch. Sie suggeriert einen erfolgreichen Angriff auf TLS, den Sie so nicht durchgeführt ­haben. Sie konnten die TLS-Verbindung nur aufbrechen, weil Sie vorab den Computer kompromittiert haben, was mit MitM überhaupt nichts zu tun hat.

Es fällt mir irgendwie schwer zu glauben, dass derart offensichtliche Überlegungen nicht auch von Ihnen oder Herrn Grunwald beim Schreiben des Artikels getätigt wurden. Auf der anderen Seite fällt mir aber auch schwer vorzustellen, dass Sie den Artikel so trotz dieser Überlegungen publiziert haben.

Sebastian Hertz-Eichenrode, Hamburg

Korrigierter Link

(Software-defined Storage: Freie NAS-Distributionen;  4/2019, S. 60)

Im Leserbrief „NAS-Performance mit ARM“ in der iX 5/2019 steht in der letzten Zeile „Eine Liste der ARM-Pro­dukte, die als NAS Top-Geschwindigkeit bringen, gibt es online (siehe ix.de/ix1905006).“ Der Link führt jedoch wieder auf die Leserbriefseite. Ist das so gewollt?

Carsten Pache, Hamburg

Das war im System falsch eingetragen. Gemeint war die URL https://forum.openmediavault.org/index.php/Thread/26095-One-big-powerful-server-Or-several-small-ones/?postID=200015#post200015 (d. Red.).

Ergänzungen und Berichtigungen

Konferenz: Microsoft Build: Einheitliches .NET; 6/2019, S. 8

In den Artikel hat sich ein Tippfehler bei einer Jahreszahl eingeschlichen. Das Jahr der geplanten Zusammenführung von .NET Framework, .NET Core und Mono ist nicht 2010, sondern 2020.

Die iX-Redaktion behält sich Kürzungen und auszugsweise Wiedergabe der Leserbriefe vor. Die abgedruckten Zuschriften geben ausschließlich die Meinung des Einsenders wieder, nicht die der Redaktion.