[English]Unschöne Geschichte: In Microsofts E-Mail-Diensten gibt es eine Schwachstelle, die es Dritten ermöglicht, E-Mails im Namen von Microsoft zu versenden. Microsoft hat meines Wissens diesen Bug bestätigt, bisher aber noch nicht gepatcht. Bedeutet, dass man mit Phishing-Mails von Microsoft-Konten rechnen sollte.
Anzeige
Sicherheitsforscher stößt auf Spoofing-Bug
Sicherheitsforscher @slonser_ (aka Vsevolod Kokorin) von SolidLab ist vor einiger Zeit auf eine unschöne Geschichte im Zusammenhang mit Microsofts E-Mail-Diensten gestoßen. In nachfolgendem Tweet schreibt er "Ich habe eine Schwachstelle gefunden, die es erlaubt, eine Nachricht von einer beliebigen user@domain zu senden."
Gemeint ist, dass der Sicherheitsforscher einen Bug in den E-Mail-Diensten von Microsoft gefunden hat, der es erlaubt, Dritten eine Mail unter einer beliebigen Domain (z.B. @microsoft.com) zu versenden. Wer eine solche Mail erhält, muss davon ausgehen, dass diese von Microsoft stammt.
Aus dem Tweet gehen nicht so viele Details hervor, aber der Sicherheitsforscher hat Techcrunch kontaktiert, die einige Details in diesem Beitrag offen legen (ein Leser hat in diesem Kommentar auf den Techcrunch-Artikel hingewiesen). Dort wird ausgeführt, dass der vom Sicherheitsforscher gefundene Bug es jedem ermöglicht, Mails unter einem Microsoft-Firmen-E-Mail-Konto (@microsoft.com) zu versenden. Dadurch erhielten Phisher ein wirksames Instrument, um Phishing-Versuche glaubwürdiger erscheinen zu lassen.
Anzeige
Der Sicherheitsforscher hat keine Details veröffentlicht, um einen Missbrauch zu verhindern, versuchte das Ganze aber mit Microsoft zu klären. Er meldete den Bug an das Sicherheitsteam von Microsoft. Als Antwort kam, dass man den Bug nicht reproduzieren könnte. Daraufhin hat der Sicherheitsforscher noch ein Video mit Proof-of-concept (PoC) an Microsoft geschickt, ohne einen Fortschritt in der Sache vermelden zu können.
An dieser Stelle beschloss Vsevolod Kokorin die Kommunikation einzustellen und hat obigen Tweet veröffentlicht. Der Tweet ist ziemlich eingeschlagen (mehr als 120.000 Abrufe), und der Sicherheitsforscher hat mit Techcrunch gesprochen, die dann einige Details des Falls öffentlich machten. Laut Kokorin funktioniert der Fehler nur, wenn die E-Mail an Outlook-Konten gesendet wird. Das beträfe aber immer noch 400 Millionen Konten.
Das Problem ist dabei, dass als Absenderadresse beliebige Domain-Namen vergeben werden können. Kokorin hat nach eigenen Angaben zuletzt am 15. Juni 2024 Kontakt mit Microsoft gehabt. Microsoft reagierte nicht auf die Anfrage von TechCrunch nach einem Kommentar. Bisher ist der Bug wohl noch nicht behoben, aus diesem Grund werden keine technischen Details des Fehlers bekannt gegeben, um einen Missbrauch zu verhindern.
Anzeige
***** Sterne fuer Microsoft. Sie schiessen den Vogel inzwischen im Tagestakt ab.
Ich sage nur drei Wörter:
DMARC, DMARC, DMARC
DMARC nützt in diesem Fall wohl nix, weils nur Outlook Konten betrifft, es sei denn man hat ein geschäftliches Mailkonto mit Office 365 und eigener Domain, wo man das konfigurieren kann.
Genau! Und DMARC, SPF und DKIM bestätigen nur den Sender-Host, nicht den tatsächlichen Absender.
Das stimmt für SPF.
Aber DKIM kann vom Absender berechnet werden (die Schlüssel stehen im DNS der Domain! Und nur ein angemeldeter User kommt an die privaten keys. Es wird zwar meist auf dem Server implementier, ist aber nicht zwingend.).
Welcher Server die mit DKIM signierte Email ausliefert ist völlig wurscht. Die Auslieferung könnte auch über ein Dial-up erfolgen, denn die Spammer kommen nicht an die privaten DKIM Keys deren öffentliche Schlüssel im DNS bereit liegen.
Ich vermute stark auf einen Implementierungsfehler auf Seiten MS. DMARC schlägt ja auf Serverseite, wenn Mails zwischen diesen gereicht werden. Wenn nun aber der Absender (Microsoft) und der Empfänger im gleichen Mailserver(-cluster) hängen, die sich irgendwie krude gegenseitig vertrauen (weil ja alles irgendwie intern ist aus Sicht MS), dann passiert so ein Schmus. Ähnliches war ja bis vor kurzem auch bei IONOS möglich. Jeder mit einem eigenen IONOS Email-Account konnte im beliebigen Namen eines anderen IONOS Kunden Emails versenden.
Sie wissen davon aber patchen es nicht. Da würde ich mir doch als Kunde von Microsoft etwas verarscht vorkommen. Man sollte schon darauf vertrauen können das Microsoft drin ist wo Microsoft drauf steht.
Ok mir solls egal sein alles was von dort kommt würde ich eh sofort löschen da ich keinen Emailkontakt mit Microsoft haben möchte.
Microsoft und E-Mail…
…die unendliche Geschichte
Nach meinen eigenen Erfahrungen mit dem Microsoft Support habe ich schon länger die Vermutung, dass Microsoft nicht mit seinen eigenen Produkten arbeitet.
In Zusammenspiel mit "Laut Kokorin funktioniert der Fehler nur, wenn die E-Mail an Outlook-Konten gesendet wird", ist dann auch klar, warum Microsoft den Bug nicht nachstellen kann… :D
mehr oder minder ist das doch auch nichts anderes als ein riesen exchange cluster. und beim business cluster oder onpremise gibts die probleme dann nicht? muss man nicht verstehen oder?
Kommt drauf an, wo der Bug "implementiert" ist, dann könnte das auch alle Hosted Microsoft Exchange / 365 Produkte betreffen, wenn ich mich nicht irre 🤕
Verstehe ich nicht. Die From Zeile ist wie viele andere Header-Lines beliebig füllbar, da diese für den Transport nicht benötigt wird, war schon immer so.
Die einzige Möglichkeit eine E-Mail fälschungssicher einem Absender (nicht Host) zuzuordnen besteht in der Verwendung einer digitalen Signatur (PGP, S/Mime), alles andere gibt das Protokoll gar nicht her.
aha dann haben wir bei unseren externen postfix servern wohl was falsch gemacht oder erweitert, denn die können das dass von extern keiner an uns mit unserer maildomain schicken darf.
554 5.7.1 : Sender address rejected: You are not me!
Naja, wenn ein Sachbearbeiter draußen sitzt, kann er trotzdem mit der Domain schreiben, legal.
Aber das funktioniert heute WG. spf nicht mehr.
Mit DKIM ginge es, lässt aber niemand zu.
unser postfix akzeptiert aber von extern keine mails von absendern, die unsere maildomain in der absender adresse verwenden wollen.
554 5.7.1 xxxxx : Sender address rejected: You are not me!
Ja,
da klappt das.
Dein Mailserver kann unterscheiden, wer 'im Haus' ist und wer nicht. Dem MS-Cloudserver fällt diese Unterscheidung schwer, weil seine Nutzer sitzen nunmal überall im Internet, das ist das Grundprinzip der Cloud…
Also wenn ich mir die SPF listen ansehe, sitzen die meisten Cloud hosts in einem Netz von MSN, Microsoft Network.
Es war vor ein paar Jahrzehnten üblich, dass der Mail server allen anderen traute, die in seinem Netz saßen.
Ich hoffe doch sehr, das das MS inzwischen geändert hat.
leider wissen wir nicht wie der Trick abläuft und es kann hier nur wild spekuliert werden.
DMARC baut auf DKIM auf und das ermöglicht E-Mail-Inhalte kryptographisch zu signieren. Der Empfänger kann die Signatur dann überprüfen, um sicherzustellen, das die E-Mail von einem autorisierten Server der Maildomain gesendet und während der Übertragung nicht verändert wurde. Das dies nicht den menschlichen Absender verifiziert ist irrelevant, die Domain ist authentisch. Nur die Outlookkonten wollen das nicht machen…
absolutes NoGo, da nicht sofort seitens MS aktiv zu werden. Naja, die Fanboys und Jünger werden es wieder klein reden.
ich vermute mal dass es kein Problem ist, in den Body der Email eine From-Adresse support@micosoft.com einzubauen, wenn der return path korrekt auf den gehackten Account von franzi@yahoo.com zeigt.
Da nützt kein Dkim. Die Email kommt von Franzi!
Aber im Outlook wird dem sorglosen User ja nur die From-Adresse angezeigt…und nicht die verifizierte…
und der glaubt was er sieht solange bis er versucht zu antworten. Dann sieht er die echten Absender-Adresse des gehackten Accounts.
Ich verstehe nicht warum Microsoft den unfälschbaren Return Path (SMTP mail from:) dem User verheimlichen will.(Wahrscheinlich weshalb sie auch die Dateiendungen verbergen? Weil sie es können und Antivirus-Software fördern wollen in dem sie der Virus Verbreitung helfen?).
Vielleicht simpel kosmetische Gründe wie zum Beispiel IDN? Weiß keiner außer Microsoft. Und selbst die wissen das nur vielleicht.
Wenn man sich die Mühe gemacht hat, und sich den Return path schon im Eingangsordner anzeigen lässt, fallen die schlechtlesbaren Absender-Adresse der MS-Mail-mails sehr negativ auf.
"Kosmetik" könnte wirklich ein Grund sein diese dem User zu verbergen. Es erklärt aber nicht, warum Microsoft in Outlook die Aktivierung der Anzeige so kompliziert gestaltet hat (Es gibt im Netz mehrstufige Anleitungen, wie man das bewerkstelligen muss.
Ich habe allerdings noch nicht gesehen wie es dargestellt wird, wenn die Domain im punycode käme.
Naja,warten wir mal ab, was denn das eigentliche Problem war.
Wenn MS nicht patschen will, wird es wohl schon nicht so einfach zu nutzen sein, da können wir Microsoft aus Erfahrung vertrauen.
Erst kommt die Sicherheit ber Kunden und deren Gerschafte.
vgl. den Fall von Purple-tec, die 14 Tage vom Email Verkehr ausgeschlossen waren, und wedervein bitte Entschuldigung noch Erklärung erhielten…