Benachrichtigungen
Alles löschen

OWA Download Domain - CVE-2021-1730

Seite 2 / 2

NorbertFe
(@norbertfe)
Reputable Member
Beigetreten: Vor 12 Monaten
Beiträge: 471
 

Vermieden werden soll, dass deine User sich mit attachment-owa… anmelden. Wenn sie den link selber nicht kennen, dürfte das wohl eher selten passieren. Und ja wenn der Host fehlt sollte das Bild dann nicht mehr angezeigt werden. Wäre also zu klären, warum das bei dir trotzdem passiert. Da du aber nur sehr selektiv antwortest…


AntwortZitat
(@carstengeh)
Eminent Member
Beigetreten: Vor 1 Jahr
Beiträge: 32
 

Wollte nur zwischendurch ein Update geben.

Die Konfiguration hat mit dem von NorbertFe geposteten Link super geklappt. Nach einem IIS Reset werden die Bilder jetzt in der subdomain geöffnet.

Leider hatte ich nach dem IIS Reset den Internetzugriff vom Exchange zu schnell gekappt. Darum wird jetzt "Sperrungsprüfung fehlgeschlagen" im ECP angezeigt. Das Zertifikat ist jedoch trotzdem gültig und funktioniert. Werde wohl später ein Neustart machen müssen mit Internet und schauen, ob die Prüfung dann durchgeht.

Gruß

Diese r Beitrag wurde geändert Vor 3 Monaten von carstengeh

AntwortZitat
 mom
(@mom)
New Member
Beigetreten: Vor 2 Monaten
Beiträge: 1
 

Ich habe ein Problem bei der Umsetzung dieser Anforderung und hoffe ihr habt einen Tipp/Lösung für mich!

Der Aufbau für OWA ist folgendermaßen:

- Domain owa.domain.de liegt bei Strato und zeigt per A-Eintrag auf die IP-Adresse unseres Anschlusses bei Vodafone

- Die IP-Adresse zeigt in unsere DMZ und wird im IIS per Hostname (owa.domain.de) angenommen

- Per Reverse Proxy wird der interne Exchange aufgelöst

Alles läuft und die Bilder werden problemlos angezeigt.

Ich habe nun intern einen CNAME Eintrag für attachments.domain.de auf owa.domain.de erstellt und die Funktion mittels Powershell aktiviert auf dem Exchangeserver (mit dem setzen des internen Download Pfads). Alles ist super und funktioniert. Die Url des Bildes in der E-Mail wird korrekt aufgelöst und unterscheidet sich von OWA.

Jetzt habe ich das ganze für extern probiert und die Bilder werden nicht angezeigt. Die E-Mail wird kurz geladen und der Platzhalter für das Bild wird angezeigt. Danach verschwindet der Platzhalter und es wird nichts angezeigt.

Folgendes Vorgehen für Extern:

- Subdomain attachments.domain.de erzeugt und CNAME für owa.domain.de gesetzt

- Im Exchange die externe Downloadurl hinzugefügt

- Funktion EnableDownloadDomains einmal deaktiviert und wieder aktiviert

- IIS Reset sowie Neustart durchgeführt

Die Domain attachments.domain.de ist ohne Probleme erreichbar und auch (sollte man nicht) wenn ich diese verwende um mich bei OWA anzumelden, funktioniert es. Die Kommunikation steht also und die Konfigurationen haben soweit gewirkt. Die Bilder werden nicht angezeigt von extern.

In den Entwicklertools von Firefox habe ich die Kommunikation auflisten lassen. Hierbei wird protokolliert, dass alle Verbindungen auf die URL attachments.domain.de mit dem Status 200 zurückkommen. Alle bis auf die mit GetFileAttachment-Inhalt.Diese kommen mit der Fehlermeldung 404 zurück.

Zum Beispiel:

attachments.domain.de/owa/VORNAME.NACHNAME@domain.de/service.svc/s/GetFileAttachment...

Ich habe zum Tests die CNAME-Einträge mittels A-Eintrag getauscht und auf dem IIS in der DMZ eine Webseite für attachments.domain.de angelegt. Der ebenfalls per Reverse Proxy das OWA auflöst. Gleiches Problem nur bekomme ich dann beim Bilderladen den Fehlerstatus 302. Rufe ich die URL direkt auf, wird mir die Anmeldeseite von OWA angezeigt.

Jemand eine Idee für Extern?


AntwortZitat
(@carstengeh)
Eminent Member
Beigetreten: Vor 1 Jahr
Beiträge: 32
 

Ich weiß das hilft hier nicht weiter mit deinem Problem. Ich wollte nur ein kurzes Update geben, was vielleicht für andere interessant sein könnte.

Gestern habe ich plötzlich allerei Probleme im OWA festgestellt. Bei einem User gab es immer eine Fehlermeldung, wenn man Anhänge anschauen oder herunterladen wollte. Bei den anderen Usern trat das nur sporadisch auf. Die interne Kommunikation mit Outlook war nie gestört.

Das war die Fehlermeldung in OWA: "Fehler beim erstellen der Dokumentenvorschau. Versuchen sie es später."

Ich habe dann die Fehlermeldung gegoogelt und vermutet, dass es irgendwas mit den Zertifikaten zu tun haben muss. Auf jeden Fall fand ich auch in den Eventlogs reichlich Fehler im Zusammenhang mit IIS. Auch hier deutete alles auf Zertifikate hin.

Stellte sich raus, der Exchange mag es gar nicht auf längere Zeit vom Internet getrennt zu sein. Die von mir angesprochene Sperrungsprüfung wird dann irgendwann wohl zum Verhängnis. Vielleicht ist es noch einmal gravierender, da wir das Zertifikat mit LE über win-acme erstellen lassen.

Nachdem der Exchange wieder nach draußen rufen durfte und ein IIS Reset gemacht wurde, waren alle Probleme und Fehler wie verschwunden.

Diese r Beitrag wurde geändert Vor 2 Monaten von carstengeh

AntwortZitat
NorbertFe
(@norbertfe)
Reputable Member
Beigetreten: Vor 12 Monaten
Beiträge: 471
 

Afaik kann man den revocation check auch deaktivieren, wenn man will. Alternativ könnte man ja den exchange nur zu den notwendigen crl sites lassen. ;)


AntwortZitat
(@carstengeh)
Eminent Member
Beigetreten: Vor 1 Jahr
Beiträge: 32
 

Zu früh gefreut. Heute ist das Problem wieder aufgetreten. Zertifikate sind alle gültig. Irgendwie scheint das mit der attachment subdomain nicht so ganz rund zu laufen...


AntwortZitat
NorbertFe
(@norbertfe)
Reputable Member
Beigetreten: Vor 12 Monaten
Beiträge: 471
 
Veröffentlicht von: @carstengeh

Ich weiß das hilft hier nicht weiter mit deinem Problem. Ich wollte nur ein kurzes Update geben, was vielleicht für andere interessant sein könnte.

Gestern habe ich plötzlich allerei Probleme im OWA festgestellt. Bei einem User gab es immer eine Fehlermeldung, wenn man Anhänge anschauen oder herunterladen wollte. Bei den anderen Usern trat das nur sporadisch auf. Die interne Kommunikation mit Outlook war nie gestört.

Das war die Fehlermeldung in OWA: "Fehler beim erstellen der Dokumentenvorschau. Versuchen sie es später."

Ich habe dann die Fehlermeldung gegoogelt und vermutet, dass es irgendwas mit den Zertifikaten zu tun haben muss. Auf jeden Fall fand ich auch in den Eventlogs reichlich Fehler im Zusammenhang mit IIS. Auch hier deutete alles auf Zertifikate hin.

Stellte sich raus, der Exchange mag es gar nicht auf längere Zeit vom Internet getrennt zu sein. Die von mir angesprochene Sperrungsprüfung wird dann irgendwann wohl zum Verhängnis. Vielleicht ist es noch einmal gravierender, da wir das Zertifikat mit LE über win-acme erstellen lassen.

Nachdem der Exchange wieder nach draußen rufen durfte und ein IIS Reset gemacht wurde, waren alle Probleme und Fehler wie verschwunden.

Da du ja wenig über deine Konfiguration verrätst, außer dass dein Exchange nicht ins Internet darf aber vom Internet offenbar erreichbar ist, wirds natürlich schwer. Man kann afaik die CRL Prüfung auch abschalten, ob das sinnvoll ist, sei mal dahingestellt. Alternativ erlaubt man seinem Exchange entweder zur CRL URL zu kommen, oder lebt mit deinem Problem. ;)

Ich kann derzeit wenig Probleme erkennen und habe die Konfig bei einigen umgesetzt. Aber vielleicht nutzen die OWA auch nur sehr begrenzt, das weiß ich nicht.

Bye

Norbert


AntwortZitat
(@carstengeh)
Eminent Member
Beigetreten: Vor 1 Jahr
Beiträge: 32
 

@norbertfe

Was willst du über die Konfiguration denn wissen? Drehen wir den Spieß doch um :)

Der Server kann mittlerweile auch wieder nach draußen funken, daher die gültigen Zertifikate.

Nach einem recycle vom MSExchangeOWA Pool geht alles wieder direkt. Leider, keine Fehler in den Logs etc. :/


AntwortZitat
NorbertFe
(@norbertfe)
Reputable Member
Beigetreten: Vor 12 Monaten
Beiträge: 471
 

Naja wär halt ggf. Interessant ob davor ein Reverse Proxy hängt. Aber wenn’s jetzt erstmal geht hilft erstmal nur beobachten.


AntwortZitat
(@carstengeh)
Eminent Member
Beigetreten: Vor 1 Jahr
Beiträge: 32
 

Ich habe jetzt eine kleine Änderung am DNS Eintrag vorgenommen. Vielleicht war es nicht klug ein A-Record zu verwenden. Ja, ich weiß es heißt immer "Alias" anlegen. Es hat halt trotzdem funktioniert, daher dachte ich vielleicht macht es keinen großen Unterschied. Naja, A-Record gelöscht CNAME mit selber subdomain angelegt. App Pool recycled. Getestet, geht noch. Werde dann wieder berichten, ob das Problem wieder auftritt oder damit behoben wurde.

Grüße

@NorbertFe

Der Server ist von außen nur per VPN erreichbar. Er darf aber per http/s nach draußen, wegen den CRLs.

Diese r Beitrag wurde geändert Vor 2 Monaten von carstengeh

AntwortZitat
NorbertFe
(@norbertfe)
Reputable Member
Beigetreten: Vor 12 Monaten
Beiträge: 471
 
Veröffentlicht von: @carstengeh

Ja, ich weiß es heißt immer "Alias" anlegen.

Nö, ich hab das auch alles als a-Record. Alias verwende ich eher nicht.


AntwortZitat
NorbertFe
(@norbertfe)
Reputable Member
Beigetreten: Vor 12 Monaten
Beiträge: 471
 

Warum verwendet man dann ein öffentliches Zertifikat, wenn der Server nur per VPN erreichbar ist? Dann täte es ggf. Auch ein internes Zertifikat und dann muss der Exchange auch nicht nach extern ;)


AntwortZitat
(@carstengeh)
Eminent Member
Beigetreten: Vor 1 Jahr
Beiträge: 32
 

@norbertfe

Da der Exchange vor Hafnium von extern erreichbar war. Das mit dem internen Zertifikat ist mir schon klar, wollte ich aber erst mal so weiter laufen lassen, in der Annahme vielleicht doch wieder auf RP umzustellen, wenn unsere UTM endlich LE Zertifikate unterstützt. Da sich die Mitarbeiter aber an das VPN gewöhnt haben, könnte ich das evtl demnächst angehen. Never change a running system though usw.

Diese r Beitrag wurde geändert Vor 2 Monaten von carstengeh

AntwortZitat
NorbertFe
(@norbertfe)
Reputable Member
Beigetreten: Vor 12 Monaten
Beiträge: 471
 
Veröffentlicht von: @carstengeh

Never change a running system though usw.

Es rennt ja nicht, sonst wärst du kaum hier :p

Bye

Norbert

PS: Wie ich diesen Spruch h...


AntwortZitat
(@hdreise)
New Member
Beigetreten: Vor 1 Jahr
Beiträge: 3
 

Hallo zusammen,

wir haben bei uns das Problem, dass bei uns das Bild nach der Umstellung nicht angezeigt wird. Vorgegangen bin ich nach https://www.nobbysweb.de/blog/index.php?entry/59-sicherheitsanf%C3%A4lligkeit-in-microsoft-exchange-server-bez%C3%BCglich-spoofing-cve-2021/

Eine neue Domain und ein neues Zertifikat für die Download Domain wurde erstellt, und im ADFS auch die neue Domain eingetragen. Die Anmeldung an der OWA funktioniert auch über die neue Domain. Vor den 4 Exchange Server ist ein Kemp. Ich vermute mal, dass der Kemp die Ursache ist, nur weiß ich nicht wo dort noch was geändert werden muss.

Hat jemand von euch vielleicht ein Rat?

Gruß


AntwortZitat
NorbertFe
(@norbertfe)
Reputable Member
Beigetreten: Vor 12 Monaten
Beiträge: 471
 

Habe ich in der Form auch schon bei einem Kunden gesehen. Da wird Kemp mit Prä-Auth genutzt (Eine Lösung gibts aktuell bisher noch nicht). Falls alles nix hilft, mach einen Support Case bei Kemp auf. Die sind sehr hilfreich.

Bye

Norbert


AntwortZitat
Seite 2 / 2

Teilen: