[English]Ich stelle mal eine merkwürdige Leserbeobachtung hier im Blog ein. Es geht um die Autoermittlung von E-Mail-Empfängern in Outlook, über den AutoErmittlungsdienst in Microsoft Exchange. Einem Leser ist in diesem Kontext ein krudes Problem aufgefallen. Jemand scheint eine Subdomain, die mit .de.de endet und für Autodiscover-Anfragen konfiguriert wurde, registriert zu haben. Es stellt sich die Frage, warum dieser Ansatz gewählt wurde – und ob ein Leser eine logische Erklärung hat. Für mich riecht es jedenfalls nach Cyberbetrug.
Anzeige
Autoermittlung von Outlook zu Exchange
Unter Microsoft Exchange gibt es einen AutoErmittlungsdienst für Clients wie Outlook, der den Zugriff auf Exchange-Funktionen bereitstellt und die zur Benutzerkonfiguration und Bereitstellung erforderlichen Schritte auf ein Minimum reduziert. Microsoft beschreibt die Funktionen im Dokument AutoErmittlungsdienst in Exchange Server (bezogen auf Exchange Server 2019). Über die AutoErmittlung lassen sich unkompliziert alle Informationen abrufen, die erforderlich sind, um eine Verbindung zu Postfächern auf Exchange-Servern herzustellen, schreibt Microsoft dazu. Auch für Outlook ist der AutoErmittlungsdienst verfügbar. Daher benötigt Outlook nur Benutzeranmeldeinformationen, um sich bei Active Directory zu authentifizieren und die AutoErmittlungs-SCP-Objekte zu suchen. Die Details sind im verlinkten Microsoft-Beitrag beschrieben.
Eine krude Leserbeobachtung
Blog-Leser Horst S. hat mich Anfang des Monats kontaktiert, weil er bei einem Kunden auf ein sehr merkwürdiges Problem gestoßen ist. Bei diesem Kunden wurde ein Exchange Server (lokal in eigener AD- Domäne) mit Verbindung zu einer bei einem Provider bestehenden Domain eingerichtet. Die bestehende Domain beherbergt den Internetauftritt des Kunden und dient auch zur Bereitstellung der E-Mail-Adressen (@domain.de). Horst schrieb mir, dass man in dieser Konstellation in der Regel dort eine Subdomain einrichtet, die für die Autodiscover Anfragen (mit Verweis zum eigenen lokalen Exchange Server) konfiguriert ist.
Es gibt plötzlich eine zweite (Fremd-)Domain
In der vorliegenden Konstellation beim Kunden ist er plötzlich auf den Sachverhalt gestoßen, dass ein Dritter eine Domain in Betrieb hat, die genau die Autodiscover-Subdomain eines Dritten (hier der betreffende Kunde bzw. dessen Domain) abbildet. Der einzige, aber feine Unterschied ist, dass am Ende dieser Fremd-Domain ein zweites .de steht (also das Muster autodiscover.domainname.de.de verwendet wird).
Aufgefallen durch Zertifikatswarnungen
Dem Leser ist diese Diskrepanz dadurch aufgefallen, dass in der betreffenden Umgebung auf einmal Zertifikatswarnungen beim Start von Outlook auftraten (siehe folgendes Bild). Die Autoermittlung (Autodiscover) ist wohl über diese URL "gefallen" und probierte eine Verbindung zur Fremddomain herzustellen.
Anzeige
Das Zertifikat selbst ist seit Jahren (2012) abgelaufen, wurde nicht für die Domain ausgestellt und es kommt von einer Firma, die als nicht vertrauenswürdig eingestuft wird. An dieser Stelle klingeln wohl bei jedem Administrator die Alarmglocken, und es stellt sich die Frage, was hinter diesem Ansatz steckt. Für mich zeichnet sich folgendes Bild: Falls jemand dort auf die Ja-Schaltfläche klickt, würden die AutoDiscover-Einträge der Fake-Domain von Outlook oder andere Mail-Clients abgerufen.
Welche Gegenmaßnahme wurden unternommen?
Das Problem mit der Fake-Domain wurde momentan durch eine Blockade in der vorgelagerten Firewall für diese Adresse und Black-Listing des Zertifikates gelöst. Zum Black-Listing des Zertifikats wurde dieses in Windows importiert und im Zertifikatsspeicher in die Liste der gesperrten Zertifikate aufgenommen, sagte mir der Leser.
IP-Adresse der Fake-Domain in Luxemburg
Er hat dann noch etwas geforscht und schrieb, dass die IP- Adresse, die man zur betreffenden Domain ermittelt, aus einem "Datacenter" in Luxemburg kommt. Wie oder wo die Domain (.de.de) registriert wurde, entzieht sich der Kenntnis des Lesers und er kannte diese Möglichkeit auch nicht. Der Leser hat bei der DENIC angerufen und erfuhr, dass diese .de.de-Domain dort nicht registriert ist.
Was steckt dahinter?
An dieser Stelle stellt sich die Frage, warum jemand so etwas macht? Und was passiert, wenn dort beispielsweise ein akzeptiertes Zertifikat liegen würde oder Clients ohne Zertifikatsprüfung (Android etc.) auf diese Domain per AutoDiscover zugreifen? Kann sich jemand aus der Leserschaft da einen Reim drauf machen?
Ergänzung: Ich hatte das Ganze noch weiter verfolgt – das magere Ergebnis findet sich im Beitrag Nachlese: Exchange-Autoermittlung und die Doppeldomain .de.de.
Anzeige
Alles mit dem Muster aaa.de.de bzw. aaa.bbb.de.de wird offenbar nach 80.92.67.155 aufgelöst, was zu lepton.dclux.com Datacenter Luxembourg S.A. bei datacenter.eu führt.
Wie kann die DENIC dazu nichts wissen?
alles unterhalb von .de.de geht den DENIC doch gar nichts mehr an.
Über de.de müsste die DENIC doch was wissen, oder?
und wer de.de registriert hat sollte der DENIC wissen, dürfen die dir aber nicht sagen.
>> Wie kann die DENIC dazu nichts wissen?
Die DENIC ist eine Genossenschaft. Es gibt zwei Möglichkeiten, eine .de-Domain zu registrieren, entweder bei der DENIC selbst (https://direct.secure.denic.de/) oder bei einem der Genossenschaftsmitglieder (https://www.denic.de/ueber-denic/mitglieder/liste) die die meisten großen ISPs umfaßt. In diesem Fall nehmen diese die Identitätsprüfung vor und verwalten die Mitgliedsdaten.
Diese Daten unterliegen übrigens dem Datenschutz, viel mehr als daß die Domain bereits registriert ist dürfen sie Dir nicht sagen und werden sie auch nicht. Für die Abfrage des Inhabers gibt es ein spezielles Prozedere, i.d.R. können das nur der Inhaber und Strafverfolgungsbehörden.
Ich sehe hier eher eine Überreaktion des Einsenders (auch das Sperren eines 10 Jahre alten und mit SHA1 signierten Zertifikates).
Bei einem Kunden fragt ein PC mit Outlook 365 Client seit letzter Woche regelmässig nach, ob die Zugangsdaten zu einem E-Mail Account mit der Kundendomain bei IONOS gespeichert werden sollen, obwohl sie bereits gespeichert sind, nach einfachem Klick auf Ok geht es weiter, Zusammenhang?
Es wäre denkbar, daß mit der IONOS-Adresse/-Domain ein Microsoft-Konto für Office oder Teams registriert wurde, MS-Outlook versucht dann immer zuerst, sich mit dem vermeintlichen O365-Postfach zu verbinden, was fehlschlägt.
Man könnte versuchen, die Abfrage externer Autodiscover-Dateien mit ExcludeExplicitO365Endpoint=1 zu unterbinden. (Details dazu im Internet)
Das macht vor allem Sinn, wenn man einen eigenen Exchange-Server hostet.
Ich habe das gerade mal ausprobiert und jede beliebige Subdomain von [.]de[.]de liefert mir die selbe IP zurück.
Und laut Denic Abfrage soeben ist auch die Domain de[.]de schon bereits registriert.
Ein ähnliches Verhalten habe ich auch mit anderen TLDs, nicht nur mit de[.]de
Warum ist dem so? Muss es ja eine Erklärung geben.
>> Warum ist dem so? Muss es ja eine Erklärung geben.
https://en.wikipedia.org/wiki/Wildcard_DNS_record
Danke Fritz!
Wieder was dazugelernt…
Jetzt wo ich den Artikel gelesen habe, fällt mir wieder ein, dass ein Kollege mir davon sogar schon mal erzählt hat…
Siehe https://www.heise.de/news/Gericht-Denic-muss-Domain-mit-zwei-Buchstaben-zuteilen-214934.html
2008 mußten nicht nur die vier bis dahin bestehenden Bestandsdomains (neben ix.de z.B. auch db.de), sondern alle zweibuchstabigen Domains zur Registrierung freigegeben werden.
Trotz damals noch hoher Registrierungspreise (1€ pro Monat) waren binnen Minuten alle von Domaingrabbern belegt – so sicherlich auch de.de.
Heute werden diese zweibuchstabigen Domains – wenn überhaupt – für astronomische Summen gehandelt.
Das abgelaufene Zertifikat (siehe https://www.sslshopper.com/ssl-checker.html#hostname=https://www.borncity.de.de/) scheint etwa aus dieser Goldgräberzeit zu stammen und ist offensichtlich mangels Bedarf bisher nicht ersetzt worden – der Webserver kann auch nur veraltete Protokolle bis TLS1.0.
Mit wenig Mühe (neuer Apache, Wildcard-Zertifikat "*.de.de" von Let's Encrypt per DNS-01-Challange) ließe sich beides einfach lösen – von daher sehe ich jetzt hier keine kriminelle Energie oder einen besonderen Betrugsversuch.
Ich denke beim Einsender hat sich einfach jemand vertippt (oder copy/paste) wodurch diese Domain in den Cache von Outlook bzw. der betreffenden Rechner gelandet ist.
Autodiscover (von einem Deiner Kollegen hier https://www.msxfaq.de/exchange/autodiscover/autodiscover_grundlagen.htm mal schön erklärt) kennt ja den Weg, auf einer Website eine autodiscover.xml anzufordern (entweder über die Subdomain "autodiscover" oder den Pfad "autodiscover" auf der betreffenden Domain), wenn ich die obigen Screenshots richtig interpretiere hat Outlook ja auch keine deratige Datei geladen (vermutlich liegt dort auch keine) sondern sich schon beim Versuch am Zertifikat gestoßen. Soweit völlig normal.
Theoretisch könnte der Einsender die Abfrage zweistufiger Domains beim automatischen "Raten" der Domain durch Outlook unterbinden (ndots bzw. AppendToMultiLabelName), das ist aber keine gute Idee, da es Länder gibt, in den auch legitime Domains auf dieser Ebene residieren (in England hättest Du vermutlich nicht "borncity.uk", sonder "borncity.co.uk").
ich denke das zielt im Endeffekt auf CVE-2024-21410 ab, durch autodiscover umleiten und die hashes abgreifen, autodiscover ist leider dafür bekannt alle möglichen Stückelungen der Domainnamen beim ermitteln zu verwenden. sofern man dabei in Outlook im ersten Schritt auch gleich Emailadresse und Kennwort mit eingegeben hat werden diese Daten im request gleich an den falschen Server geliefert und müssen dort nur mehr abgeholt werden
An dem Verhalten ist eigentlich nichts verwunderlich. Das sind die Unzulänglichkeiten von Autodiscover. Seitdem man auch Domänen mit 1,2 oder 3 Buchstaben oder Zahlen registrieren kann sind die Probleme vorprogrammiert. Jede Kombination ist denkbar also z.B. auch com.com, nl.nl oder info.info mit allen subdomains. Nicht jede Erweiterung der erlaubten Domains in den letzten Jahren ist wirklich sinnvoll.
1. Exchange liefert die Kontoinformationen erst nach Authentisierung: damit ist das "warum" für eine gefakte Autodiscover-Domain schon klar…
2. Auch für IMAP gibt es Autodiscover: funktioniert etwas anders, hat aber den gleichen Zweck, nämlich dem Endanwender Konfigurationsaufwand abzunehmen (RFC 6186)
Zu Punkt 1. So ist es. Dann sag mal beim Zertifikat "JA" bitte verbinden.
Und je nach dem was dann dort auf dich wartet…. Das kam im übrigen bei
jedem Client in der Installation und bei jedem Start von Outlook (weil halt eben
die Namen der Domänen bis auf das zweite .de identisch sind). Also hilft erst einmal nur blocken und dafür sorgen das im Zweifelsfall niemand auf "JA" drücken kann.
…und wenn du wüsstest wessen Original URL das ist wärest du auch in Unruhe.
Sieht für mich nach einem defekten CNAME Eintrag aus bei dem der Punkt am Ende fehlt.
genau, …und der Client hängt alle Domains (.tld.sld.de, .sld.de und .de) generisch zum Probieren an, weil er nicht weiß, dass die Domain eigentlich zu Ende sein soll.
nein das wird ein Client niemals tun, ggf. ein schlecht selbst programmierter oder ein illegal gezogenes Outlook
Oder ein schlecht administriertes Windows.
https://www.edv-lehrgang.de/dns-suffix-aendern/
Die Option heißt "Übergeordnete Suffixe des primären DNS-Suffixes anhängen"
Ja aber nicht bei Autodiscover, das macht Outlook und nicht die Adapterkonfig, ganz Stumpf rechter Teil neben dem @ der Mailadresse oder wie an anderer Stelle thematisiert ein falscher SCP oder ein fehlerhaftes lokales autodiscover xml File
p.s. der abgebildete Client ist wohl schlecht administriert da er mit TLS 1.0 Servern Verbindungen aufbaut
Man kann natürlich auf diesen typischen Flüchtigkeitsfehler hoffen und dann mittels Proxy Anmeldedaten beliebiger Webseiten abfangen, ohne diese Seite vorher zu kennen.
Moin,
ist ein bereits bekanntes Thema seit Jahren:
Autodiscover Guardicore Frank Carius
Autodiscover: Exchange-Protokoll leakt Windows-Anmeldedaten ins öffentliche Netz heise
Autodiscovering the Great Leak
Danke für die Links
Naja um dies ausnutzen zu können müsste man ja seine EMail Adresse falsch eintippen bei der Konfiguration nach dem Schema domain.de.de wie oft passiert dies denn? Mir noch nie, die Autoermittlung ist da relativ stumpf, und nimmt den Anteil rechts neben dem @ und sucht dazu autodiscover.domain.tld danach domain.tld/autodiscover. Die Autoermittlung wird nie auf die Idee kommen an domain.tld ein .tld also in diesem Fall .de anzuhängen den Fehler muss der User schon selbst machen, sofern er überhaupt noch manuell eingreifen muss da in einem gepflegte AD diese Informationen schon vom DC an Outlook übergeben werden, Tippfeher sind da eher mutwillig. Bliebe also nur noch die User ohne AD übrig mit o365 Konten, da ohne AD kein lokaler Exchange.
Diese User müssten dann ihr EMail auchnoch falsch eintippen … also ich sehe das ganze unkritisch – die Wahrscheinlichkeit das dies eintritt tendiert eher gegen 0
btw. dies Prozedere funktioniert für alle tld, z.B org.org com.com, net.net …..
p.s. das alle Subdomains in eine IP aufgelöst werden liegt wohl an dem Wildcard DNS Eintrag eine Unsitte wenn Domains zu verkaufen sind, naja manche bekommen diesen Unfug auch auf produktiv Domains hin
Warum macht hier eigentlich keiner mal eine einfache Whois-Abfrage?
https://www.whois.com/whois/de.de
Raw Whois Data
% Restricted rights.
%
% Terms and Conditions of Use
%
% The above data may only be used within the scope of technical or
% administrative necessities of Internet operation or to remedy legal
% problems.
% The use for other purposes, in particular for advertising, is not permitted.
%
% The DENIC whois service on port 43 doesn't disclose any information concerning
% the domain holder, general request and abuse contact.
% This information can be obtained through use of our web-based whois service
% available at the DENIC website:
% http://www.denic.de/en/domains/whois-service/web-whois.html
%
%
Domain: de.de
Nserver: ns1.eurodns.com
Nserver: ns2.eurodns.com
Nserver: ns3.eurodns.com
Nserver: ns4.eurodns.com
Status: connect
Changed: 2024-06-21T13:28:46+02:00
Und anschließend
https://www.whois.com/whois/eurodns.com
Raw Whois Data
Domain Name: eurodns.com
Registry Domain ID: D15672942-COM
Registrar WHOIS Server: whois.eurodns.com
Registrar URL: http://www.eurodns.com
Updated Date: 2024-04-01T05:56:44Z
Creation Date: 1998-04-08T00:00:00Z
Registrar Registration Expiration Date: 2025-04-06T00:00:00Z
Registrar: Eurodns S.A.
Registrar IANA ID: 1052
Registrar Abuse Contact Email: email@eurodns.com
Registrar Abuse Contact Phone: +352.27220150
Domain Status: clientTransferProhibited http://www.icann.org/epp#clientTransferProhibited
Domain Status: clientDeleteProhibited http://www.icann.org/epp#clientDeleteProhibited
Registry Registrant ID:
Registrant Name: BUCK Xavier
Registrant Organization: EuroDNS S.A.
Registrant Street: 2, rue Leon Laval
Registrant City: Leudelange
Registrant State/Province:
Registrant Postal Code: L-3372
Registrant Country: LU
Registrant Phone: +352.2637251
Registrant Fax: +352.26372537
Registrant Email: email@eurodns.com
Registry Admin ID:
Admin Name: BUCK Xavier
Admin Organization: EuroDNS S.A.
Admin Street: 2, rue Leon Laval
Admin City: Leudelange
Admin State/Province:
Admin Postal Code: L-3372
Admin Country: LU
Admin Phone: +352.2637251
Admin Fax: +352.26372537
Admin Email: email@eurodns.com
Registry Tech ID:
Tech Name: BUCK Xavier
Tech Organization: EuroDNS S.A.
Tech Street: 2, rue Leon Laval
Tech City: Leudelange
Tech State/Province:
Tech Postal Code: L-3372
Tech Country: LU
Tech Phone: +352.2637251
Tech Fax: +352.26372537
Tech Email: email@eurodns.com
Name Server: ns-a.eurodns.com
Name Server: ns-b.eurodns.org
Name Server: ns-c.eurodns.eu
Name Server: ns-d.eurodns.biz
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form:
>>> Last update of WHOIS database: 2024-07-01T10:51:56Z <<<
For more information on Whois status codes, please visit https://icann.org/epp
Please email the listed admin email address if you wish to raise a legal issue.
The Data in EuroDNS WHOIS database is provided for information purposes only.
The fact that EuroDNS display such information does not provide any guarantee
expressed or implied on the purpose for which the database may be used, its
accuracy or usefulness. By submitting a WHOIS query, you agree that you will
use this Data only for lawful purposes and that, under no circumstances will
you use this Data to:
(1) allow, enable, or otherwise support the transmission of mass unsolicited,
commercial advertising or solicitations via e-mail (spam); or
(2) enable high volume, automated, electronic processes that apply to EuroDNS
(or its systems). EuroDNS reserves the right to modify these terms at any time.
By submitting this query, you agree to abide by the above policy.
Ich hoffe, ich liefere damit einen Ansatz für Takedown/Abuse der de.de Domain! Xavier Buck bei EuroDNS in Leudelange in Luxemburg ist euer Mann! Email-Adresse, Telefonnummer, Postadresse, alles da!
Und mit welcher Begründung? Ein abgelaufenes Zertifikat? Eine Domain 4 Sale die Seite macht nichts verbotenes.
Der kann die Domain deregistrieren, wenn man ausreichend gut begründet. hab ich schon ein paar Mal machen lassen.
Ich habe gerade auf FB einen anderen Leser, der mir auch die Denic-Infos zukommen ließ, gebeten, eine Abuse-Meldung mit Bitte um Deregistrierung abzusetzen. Wollte er machen. Wenn noch jemand aus der Leserschaft das Gleiche tut, kann das nicht schaden – ich will mir das nicht auch noch an die Backen binen.
Ja eben, was wäre die Begründung? Diese Seite tut nichts, sie ist registriert mit einem Wildcard DNS sonst nichts oder übersehe ich da etwas ?
>> Xavier Buck bei EuroDNS in Leudelange in Luxemburg ist euer Mann!
Wie üblich frei von jeder Sachkenntnis.
Der Inhaber von EuroDNS ist der Provider, nicht aber der Eigentümer bzw wirtschaftlich Berechtigte der Domain "de.de".
Mit der selben Begründung müßte Günnis Adresse wahlweise in Tempe, Arizona (Provider des Nameservers) oder Middlesex, GB (Domainregistrar) sein. Die meisten Domainhobbyisten wohnen dann wohl bei Strato in Karlsruhe oder United Internet?
Halbwissen 1ST.
Derjeneige, der den DNS betreibt, kann auch Domains deregistrieren. Das ist überhautp kein Problem, hab ich bestimmt schon ein dutzend fach machen lassen, z.B. über ownregistrar, wenn da mal eine Seite war, die uns nachgemacht hat.
Auf Facebook habe ich die erste Rückmeldung, dass die Denic sich als nicht zuständig ansieht. Der Betreffende bleibt dran.
Ist der Denic im ersten Schritt auch nicht, aber obiger DNS-Registrar ist es. Aber wenn dann unter dieser de.de-Donain dann basf.de.de, volkswagen.de.de, daimler-benz.de.de, bundestag.de.de, t-online.de.de, usw. registriert wird, dann brennt eben die Hütte. Spätestens dann liegt auch die Fackel beim Denic.
Der Facebook-Nutzer hat sparkasse.de.de als Beispiel genommen – da brennt noch mehr die Hütte. Er will das weiter verfolgen.
Hallo Herr Born, können Sie mir bitte einen Kontakt zu dem herstellen? Meine Mailadresse kennen Sie ja. Ich sehe gerade, dass einige Domains meines Arbeitgebers auch auf *.de.de abgebildet werden, immer die gleiche IP. Ein "Catch all" scheint es aber nicht zu sein, denn manche Domains sind auch nicht dabei. Ich werde morgen schonmal intern eine TK aufsetzen um unsere Vorgehensweise zu klären. Vielleicht muss man da zusammen an einem Strang ziehen.
Der Betreffende hat die E-Mail-Adresse mit der Bitte um Kontaktaufnahme bekommen. Die .de.de-Domain steht wohl zum Verkauf, wie er mir schrieb.
Was mich eigentlich an dem Artikel erschüttert ist die Clientumgebung des Lesers Horst. Wieso um alles in der Welt unterstützt dieser TLS 1.0 mit uralt Chiphersuiten die sei einem Jahrzehnt als extrem unsicher gelten.
Dem Bild nach zu urteilen scheint es ja ein Windows 10>= zu sein und das macht dies per se nicht ohne das jemand Hand angelegt hat, ich denke solange es solche Umgebungen gibt brauch man sich über eventuelle Lücken im Autodiscover keine Gedanken machen.
und Teamviewer solle man nach dem 2ten Hack ggf. auch mal loswerden.
https://www.borncity.com/blog/?s=teamviewer
Ist aktuelles Windows 11 und es wurde nichts "umgestrickt".
Ich denke schon denn der Server unter dieser IP spricht nur TLS 1.0, das unterstützt Windows seit lengem nicht mehr, checkt mal Eure GPO's da scheint wohl sehr viel im Argen zu liegen
Hier kurz und schön zusammengefasst …
https://www.deskmodder.de/blog/2022/09/21/tls-1-0-und-tls-1-1-werden-im-september-2022-komplett-deaktiviert/
mal zurück zum thema, da muss doch eine fehlkonfiguration im exchange vorliegen und zwar bei der autodiscoverurl oder wie soll es dazu kommen das die falsche domain angesprochen wird?
Get-ClientAccessServer | Select Name, AutoDiscoverServiceInternalUri | Format-List
…oder beim Anwender, der statt "firma.de" einfach "firma.de.de" getippt hat.
Ja ein falscher SCP kann schnell passieren auf der Powershell oder wenn man sich die Konfig Scripte schnell von Franky kopiert und die URL Variablen füllt und vergisst das der Editor im Einfügemodus ist statt überschreiben, klassischer Fehler dann kommt schnell ein de.de zustande, naja abr dann würde dies eine komplette Firma betreffen, da sollte man dann vllt. einen IT'ler ran lassen der einen Plan hat.
p.s. ein faslch erstelltes lokales xml File käme auch in Frage
https[:]//crt.sh/?q=de.de
Die Domain existiert bereits seit 2014, wurde aber am 24.06.2024 "wiederbelebt
NSLOOKUP de.de: 199.59.243.226
NSLOOK abcd.de.de: 80.92.67.155 (ua. z.B. abc.de.de
Ist alles schon längst überprüft. Es passiert auch von Außerhalb mit einem völlig neutralen System. Aber das diese Domain in LX am 24.06.24 reaktiviert wurde passt zeitlich haargenau.
Naja wenn autodiscover auf de.de sucht dann ist längts nicht alles überprüft.
Wie ermittelt denn Outlook seine Konfig? Via SCP, via HTTP, via SRV Record, via lokalem xml File oder die letzte funktionierende Verbindung aus dem Cache, ach ja Redirect ginge ja auch noch
Es kann nur eine Fehlkonfiguration sein, wenn alles richtig konfiguriert ist fragt ein Domain Rechner niemals einen externen Server ab (ausser in Hybrid Umgebungen vllt), da ist irgendwo ein typo
Siehe oben Beitrag, die dortigen Weblinks
Stefan sagt:
3. Juli 2024 um 08:08 Uhr
Das Problem ist vielleicht schlimmer als gedacht, auf *.de.de scheint sowas wie eine Catch-them-All-Namensauflösung für alles was da kreucht und fleucht zu existieren und alles löst auf die IP in Luxemburg auf, auch wenn man sich selbst eine Domain ausdenkt.
C:\>nslookup huuurz.de.de 8.8.8.8
Server: dns.google
Address: 8.8.8.8
Nicht autorisierende Antwort:
Name: huuurz.de.de
Address: 80.92.67.155
Da dürfte jemand Credentials im ganz großen Stil abgreifen zu wollen.
Aber es kommt noch besser:
C:\>nslookup microsoft.com.com 8.8.8.8
Server: dns.google
Address: 8.8.8.8
Nicht autorisierende Antwort:
Name: microsoft.com.com
Addresses: 2606:4700:20::681a:594
2606:4700:20::ac43:48da
2606:4700:20::681a:494
104.26.5.148
104.26.4.148
172.67.72.218
Mit com.com funktioniert das auch, es kommen aber andere IP-Adressen dabei raus, egal ob man microsoft, ibm, google, oder was auch immer angibt, das Ergebnis ist gleich. com.com liegt bei godaddy, als DNS-Registrar steckt da Cloudflare dahinter, bei denen habe ich schon ganz gute Reaktionen auf Abuse-Meldungen gehabt.
Stichprobenweise hab ich das jetzt auch mal für ru.ru, cn.cn, ca.ca, fr.fr und it.it probiert, da gibts sowas nicht.
traritrara.ua.ua "funktioniert" auch, zeigt dreisterweise immer auf die selbe IP bei einem Hoster in Kiew. . Ich glaube, es ist Zeit das BSI einzuschalten. Könnte sein, dass da die russischen Bären dahinter stecken.
Wir hatten erst kürzlich eine Migration von 2010 auf 2016 (als Zwischenschritt zu 2019).
Durch eine Fehlkonfiguration in unserem Reverse Proxy für den Zugriff auf autodiscover, OWA, ECP usw. stand in der Zertifikatskette auch autodiscover.tld.de.de
Ich hatte seit letzter Woche auch exakt das gleiche Problem auf einem älteren Terminalserver (konnte das Problem aber relativ zeitnah umschiffen). Alle Outlookclients auf diesem Server brachten die oben erwähnte Meldung, und wollten unsere Domain erreichen mit der Endung de.de
Ich konnte mir überhaupt keinen Reim drauf machen. Umso interessanter finde ich, jetzt hier davon zu lesen.