Ehhhh hoe moet dat gaan werken als gebruikers met de Outlook app op hun telefoon zitten te klooien?
Dan zitten ze toch helemaal niet achter een zelf beheerde firewall??

Irresponsible disclosure zou als computervredebreuk behandeld moeten worden?

Of een te late reactie van Microsoft dat nu probeert de vermoorde onschuld te spelen.

Vrijwel een identiek probleem met wpad.
https://nakedsecurity.sophos.com/2016/05/25/when-domain-names-attack-the-wpad-name-collision-vulnerability/

Ik heb even de moeite genomen om te lezen hoe het autodiscover protocol werkt... onverantwoord om authenticatiegegevens zo naar een niet vertrouwde server te sturen.


Zodat er nog maandenlang gelekt kan worden; mogelijk ook naar ransomware groepen?

Wat ik er zo snel uit haal is dat je Outlook in ieder geval een certificate warning geeft. Dat zou voor de meeste beheerders toch al direct een signaal moeten afgeven?

IK heb nu al zo veel over exchange problemen gelezen hier te laatste tijd. Waarom gebruiken we dit eigenlijk nog. Is er een goed alternatief?

Wat als je installatie geautomatiseerd is en de gebruiker gewoon op ok klikt ? Het zoveelste gat.... gaat lekker met MickeySoft.
Exchange wordt gewoon steeds minder een goede optie.

Ik zeg herverkiezingen en dan laten we alleen security specialisten stemmen waarbij ze garant staan voor veiligheid en beheersbaarheid.

Dit is eigenlijk hetzelfde wat er met het WPAD mechanisme gebeurt, en ook daar is eigenlijk nooit iets mee gedaan. Jammer om te zien dat het default gedrag betreft hier. Mogelijk is het een idee om autodiscover op een bepaalde manier verder dicht te timmeren in de toekomst.

Ik ben wel bekend met Outlook en AutoDiscover, maar het verhaal wat de partij schetst heb ik zelf niet gezien. Als in: clients die uiteindelijk met autodiscover.com communiceren. Maar dat komt wellicht doordat er ofwel een Service Connection Point in AD aanwezig is en/of goede AutoDiscover records. Zover ik weet valt Outlook (en overige Microsoft producten) zelf nooit terug naar httpx://autodiscover.com/ .

Ik vermoed dat er bij deze organisatie ernstige configuratie fouten zijn gemaakt en/of third-party plugins of maatwerk applicaties die een slordige implementatie hebben gemaakt van het AutoDiscover protocol. Afhankelijk van gebruikte SDKs, agent-strings etc. kan het lijken alsof het Outlook is. Dus, vermoedelijk geen issue met het AutoDiscover protocol zelf, maar eerder bij client implementaties en dan mogelijk ook nog eens niet-Microsoft clients.

Maar de originele post geeft helaas niet genoeg informatie om dit te kunnen vaststellen. Dat met het gebrek aan responsible disclosure (ik nergens eens vermelding dat ze Microsoft benaderd hebben) maakt mij heel erg skeptisch of ze wel zorgvuldig en secuur te werk zijn gegaan. Ze maken nogal een statement, maar IMHO te zwak onderbouwd.

Heb je half gelezen. Die waarschuwing is er alleen als er geen of een selfsigned certificaat is. Als je op het domein "autodiscover.xxx" een gesigneerd certificaat installeert, blijft de waarschuwing weg.

----

Zoals de eerste reactie al schrijft, helpt een firewall maar beperkt. Dat werkt alleen als je het e-mail account binnen het bedrijf installeert. Doe je dat buiten het bedrijf, dan werkt de aanval nog steeds.

De meest logische mitigatie mist volgens mij.: Creëer een autodiscovery setup op je domein als je een exchangeserver gebruikt. De meeste mailcliënts hebben de configuratie optie "exchange server" en verwachten dat dit gaat werken.

Uit het artikel:

Dit is geen Exchange bug, maar een Outlook bug. Aangezien de client probeert te connecten richting een onzinnig domain. Dit moet zeker worden opgelost, maar dit heeft niets te maken met Exchange.

Als ik ons management mag geloven, is er een goed en veilig alternatief: Exchange Online (of hoe dat vandaag heet)

Het voordeel van regelmatig van naam veranderen is dat je kunt zeggen dat de vorige versie buggie was, maar dat in de nieuwe geen enkele bug is ontdekt.


De vraag is of het computervredebreuk is als je zelf een server opzet en daar een domein ophangt en al die Outlook systemen hun username en wachtwoord aan jou vertellen. Je zou kunnen verdedigen dat die Outlook gebruikers computervredebreuk plegen. Zij zijn degenen die constant proberen op jouw computer in te breken.

Het voordeel van het niet melden is wel dat Microsoft nu niet, zoals zo vaak bij het publiek maken, kan zeggen dat Exchange Online (of hoe het morgen heet) dit probleem niet kent en iedereen daar op moet overstappen.

Peter

Omdat dit eigenlijk een client probleem is en eigenlijk niets met Exchange te maken heeft.

Nou, ik ben er niet eens van overtuigd dat het een Outlook probleem is. Wat wel mogelijk is, zijn maatwerk aplicaties met een foutieve AutoDiscover implementatie. Maar dat lijkt mij dan niet meteen een probleem met het AutoDiscover protocol of de implementatie binnen Microsoft producten. Wat ze wel sterk impliceren.

Ikzelf heb nooit Outlook een request zien uitvoeren naar httpx://autodiscover.com/ direct, hun "back-off" process waar eigenlijk dit hele verhaal op leunt. De post is er ook niet echt duidelijk over en de logging die we zien is niet altijd voldoende om een definitieve conclusie te vormen.

Nog een nuance, zover ik het kan inschatten treedt dit alleen op bij Basic Authentication, en niet met modern auth. En basic wordt steeds meer uitgefaseerd. Zojuist getest in onze federated omgeving, en wanneer ik een nieuwe mbx toevoeg aan Outlook, wordt ik redirected naar onze adfs server voor credentials. Dus die credentials gaan niet langs de Autodiscover service. En verder treedt dit ook alleen op wanneer Autodiscover verkeerd is geconfigureerd aan de kant van Exchange. Dus ik zie hier niet zo'n groot probleem in eerlijk gezegd.

Is volgens mij een en hetzelfde:
Windows proxy auto discovery;
Ik denk zelfs gerelateerd aan Proxyshell heel kort door de bocht

Nu je het zegt, ik lees ook nergens terug in de MS documentatie dat dit gebeurt. Zoals het document https://support.microsoft.com/en-au/topic/outlook-2016-implementation-of-autodiscover-0d7b2709-958a-7249-1c87-434d257b9087

Geen vermelding voor het gebruik van het autodiscover.xxx domain. Ofwel, het is een undocumented feature. Of de onderzoekers maken een fout.

Dit is echt gewoon een designfout van het autodiscover protocol > CLIENT SIDE. Dit heeft op zich niets te maken met Exchange Server of Office 365 die Autodiscover host.

Daarnaast, het gaat gewoon fout in het begin als je Autodiscover records niet goed in DNS hebt staan.

Inhoudelijk: Punt van design fout in dit hele verhaal is dat, mocht Autodiscover NIET goed geconfigureerd zijn, why the* gaat Autodiscover dan naar een ander domein toe dan het mail domein.

Dus wat logisch zou zijn voor henk@test.nl?
1 = https://autodiscover.test.nl/AutodiscoverURL (of eventueel je CNAME)
2 = http://autodiscover.test.nl/AutodiscoverURL (of eventueel je CNAME)
3 = https://test.nl/AutodiscoverURL (of eventueel je CNAME)
4 = http://test.nl/AutodiscoverURL (of eventueel je CNAME)

Wat NIET zou moeten is(!):
5e poging: http://autodiscover.nl
>>> Dit is gewoon een verkeerde up loop.

Dit is gewoon een fout. punt.

Als het een "undocumented feature" was, had microsoft dat domein geregistreerd. Het is gewoon een bug waarbij de software variaties op de domeinnaam probeert. Waarschijnlijk willen ze er een subdomein af halen om te kijken of het restant dan bestaat. En als er geen subdomein was blijven ze zitten met een poging op "autodiscovery" met het TLD van de domeinnaam.

autodiscover met outlook gaat nooit naar een ander domeinnaam dan wat in je emailadres staat, dus verhaal lijkt me broodje aap

Dit soort problemen is het gevolg van het instellen van een "default domain search list".
NOOIT doen!

OK dus ik hoef mij met thunderbird en exchange geen zorgen te maken? Die doet namelijk ook een autodiscovery

Lees even het item van 13:51.

Die stap is ook niet beschreven in de AutoDiscover protocol definitie. Als een client dat wel doet, dan is dat een implementatie fout in de client, die zover ik heb kunnen controleren niet heeft plaatsgevonden bij Microsoft producten.

AutoDiscover Protocol: https://docs.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxdisco/d912502b-c0e2-41a1-8b0e-f714ba523e08

Die tweede stap is al hartstikke fout.

In 2017 was ik bij een bedrijf dat gebruik maakte van hosted Exchange in Office365, dus outlook.com.

De beheerder had, conform instructies van Microsoft, een CNAME DNS record gemaakt voor autodiscover.<bedrijf>.nl, namelijk autodiscover.outlook.com

Elke keer als een medewerker diens (lokaal geïnstalleerde) Outlook client startte, probeerde deze het volgende bestand te downloaden:
https://autodiscover.<bedrijf>.nl/autodiscover/autodiscover.xml, maar kennelijk lukte dat niet want dit werd opgevolgd door een http-verzoek om te downloaden:
http://autodiscover.<bedrijf>.nl/autodiscover/autodiscover.xml.

Ik heb dit toen nagebootst met Firefox:
https://autodiscover.<bedrijf>.nl/autodiscover/autodiscover.xml: Firefox meldde "unable to connect";
http://autodiscover.<bedrijf>.nl/autodiscover/autodiscover.xml: er verscheen een dialoogbox met:

Verder onderzoek wees uit dat een DNS lookup voor autodiscover.<bedrijf>.nl, na nog een aantal CNAME "redirects", uitkwam op autodiscover-emeacenter.outlook.com (met daaraan gekoppeld een reeks roulerende IP-adressen).

De autodiscover-emeacenter.outlook.com server waar verbinding mee gemaakt werd, stuurde een TCP RST netwerkpakket als antwoord op het SYN pakket voor TCP poort 443. M.a.w. geen ondersteuning voor https. Dus probeerde Outlook het, na de mislukte https-poging, via http. Daar kwam wel antwoord op: HTTP 302 "moved temporarily" naar
https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml. Probleem: het is voor een aanvaller veel eenvoudiger om een http- dan een https-verbinding te kapen (ik leg dat verderop uit).

Dat is niet waar. Het lijkt mij zeer sterk dat ik de enige ben die Microsoft op Autodiscover-risico's gewezen heeft. Ik heb het bovenstaande in 2017 uitgebreid beschreven aan secure bij Microsoft.com met in de mail o.a.:

Het antwoord dat ik kreeg:
Ik ben het er volstrekt niet mee eens dat "man in the middle style attack vectors" betekenen dat "the user already being in a compromised state": dan hadden we gewoon met z'n allen http en basic authentication kunnen blijven gebruiken.

Na Microsoft's antwoord heb ik gecheckt of toevallig slechts één van de autodiscover-emeacenter.outlook.com servers geen https ondersteunde, maar dat gold voor elk van hen. Dat heb ik (opnieuw met logs) gemailed. Als antwoord kreeg ik een herhaling van die eerdere mail van Microsoft. Daarna heb ik er niets meer over gehoord.

Terugvallen naar http is not done: zelfs als https://autodiscover-emeacenter.outlook.com/autodiscover/autodiscover.xml wel een XML file zou opleveren, zou een MitM dat netwerkverkeer (op de heen- en/of terugweg) kunnen blokkeren, of je via een DNS- of BGP-aanval naar een andere (niet op https antwoordende) server kunnen sturen - waarna de mail client http zal proberen. Omdat er dan geen servercertificaat gecheckt wordt kan de aanvaller je met elke gewenste server laten verbinden - ook als de mail client en het OS absoluut niet in een "compromised state" verkeren. Precies om dit soort aanvallen te voorkomen maakt https gebruik van certificaten, zodat je behoorlijk zeker weet dat je daadwerkelijk met het IP-adres van een server met een specifieke domeinnaam communiceert (die server moet namelijk beschikken over een private key passend bij de public key in het door de server verzonden certificaat, en dat certificaat moet digitaal zijn ondertekend door een vertrouwde certificaatuitgever die heeft vastgesteld dat die server en domeinnaam bij elkaar horen).

Daarbij is de fall-back naar basic authentication ook onverstandig, vooral in combinatie met http verbindingen (of https na een http-tussenstap, want dan weet je niet zeker op welke server je uitkomt). Zelfs in 2017 was dat allang het geval. Nb. als ik https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml in m'n browser open, vraagt deze nu nog steeds om gebruikersnaam en wachtwoord (via basic authentication).

Dat er mail clients zijn die domeinnamen "afpellen" (op eigen initiatief of op basis van instellingen in het betreffende OS), zoals dit onderzoek uitwijst, verergert de zaak - doch vooral als alle communicatie uitsluitend via https zou plaatsvinden (wat nog niet het geval is). Immers, dan zorgt de fallback naar basic authentication ervoor dat gebruikersnaam en wachtwoord via https naar een untrusted server worden gestuurd, dus zonder dat er MitM of DNS/BGP aanvallen voor nodig zijn. En ook als die basic authentication fallback niet mogelijk zou zijn (er met challenge-response zou worden ingelogd, dus zonder het feitelijke wachtwoord prijs te geven), kan die server je een XML file -met daarin servers naar keuze- sturen, waar de mail client mogelijk alsnog naam en plain text wachtwoord aan prijsgeeft (zoals IMAPS en POP3S).

Als Microsoft serieus werk wil maken van hun "zero trust" belofte aan president Biden, moeten ze per direct stoppen met al die autodiscover flauwekul (inclusief WPAD zoals Anoniem van 13:39 schrijft).

Nou ja zeg! De gewaarschuwde fabrikant van de software zou in zo'n geval toch onmiddellijk maatregelen treffen om juist dat te voorkomen?

Kleine nuancering: De http verbinding wordt dan ook niet gebruikt voor een authenticatie, maar alleen voor een redirect naar een https verbinding, waarbij in ieder geval de Outlook client een redirect waarschuwing geeft aan de gebruiker.