image

Microsoft Exchange lekt via Autodiscover-bug inloggegevens Windows-domeinen

donderdag 23 september 2021, 09:55 door Redactie, 30 reacties

Een bug in de Autodiscover-feature van Microsoft Exchange maakt het mogelijk om inloggegevens voor Windows-domeinen te onderscheppen. Onderzoekers van securitybedrijf Guardicore stellen dat ze op deze manier 372.000 inloggegevens voor Windows-domeinen hebben bemachtigd en bijna 97.000 inloggegevens afkomstig van Microsoft Outlook, mobiele e-mailclients en andere applicaties die met Exchange-servers communiceren.

Autodiscover is een protocol dat Microsoft Exchange gebruikt voor het automatisch configureren van e-mailclients zoals Microsoft Outlook. Het moet het eenvoudig voor gebruikers maken om hun Outlook-client in te stellen. Alleen het opgeven van een gebruikersnaam en wachtwoord is voldoende, waarna het protocol de rest van de configuratie afhandelt. De client probeert hiervoor verbinding te maken met een Autodiscover-url, die gebaseerd is op het e-mailadres van de gebruiker.

Is het e-mailadres voorbeeld@example.com, dan zal de client verschillende Autodiscover-url's proberen, zoals autodiscover.example.com en example.com/Autodiscover. Wanneer deze url's niet worden gevonden, omdat de organisatie van de gebruiker die niet heeft ingesteld, maakt de client verbinding met Autodiscover.com, ook al staat dit los van het domein van de gebruiker, namelijk example.com. De eigenaar van dit Autodiscover.com ontvangt zo alle requests voor het oorspronkelijke domein.

Guardicore registreerde verschillende Autodiscover-domeinen, zoals Autodiscover.es, Autodiscover.fr en Autodiscover.uk. Hierdoor ontvingen de onderzoekers honderdduizenden inloggegevens van gebruikers die hun e-mailclients wilden instellen, maar geen verbinding konden maken met het Autodiscover-endpoint van hun organisatie. De gegevens waren onder andere afkomstig van banken, energiecentrales, logistieke bedrijven, voedselproducenten en vastgoedondernemingen.

Als oplossing adviseren de onderzoekers om onder andere Autodiscover-domeinen in de firewall te blokkeren en http-authenticatie uit te schakelen. Microsoft laat in een reactie weten dat het niet van tevoren over het probleem was ingelicht en stappen zal nemen om gebruikers te beschermen.

Image

Reacties (30)
23-09-2021, 10:01 door Anoniem
Als oplossing adviseren de onderzoekers om onder andere Autodiscover-domeinen in de firewall te blokkeren
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??
23-09-2021, 10:01 door [Account Verwijderd]
Microsoft laat in een reactie weten dat het niet van tevoren over het probleem was ingelicht en stappen zal nemen om gebruikers te beschermen.

Irresponsible disclosure zou als computervredebreuk behandeld moeten worden?
23-09-2021, 10:17 door Anoniem
Door Toje Fos:
Microsoft laat in een reactie weten dat het niet van tevoren over het probleem was ingelicht en stappen zal nemen om gebruikers te beschermen.

Irresponsible disclosure zou als computervredebreuk behandeld moeten worden?

Of een te late reactie van Microsoft dat nu probeert de vermoorde onschuld te spelen.
23-09-2021, 10:24 door Anoniem
Vrijwel een identiek probleem met wpad.
https://nakedsecurity.sophos.com/2016/05/25/when-domain-names-attack-the-wpad-name-collision-vulnerability/
23-09-2021, 10:27 door MathFox
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.

Door Toje Fos:
Irresponsible disclosure zou als computervredebreuk behandeld moeten worden?

Zodat er nog maandenlang gelekt kan worden; mogelijk ook naar ransomware groepen?
23-09-2021, 10:46 door CorChando
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?
23-09-2021, 11:15 door Anoniem
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?
23-09-2021, 11:36 door Bitje-scheef
Door Coritchando: 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?

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.
23-09-2021, 11:37 door Anoniem
Ik zeg herverkiezingen en dan laten we alleen security specialisten stemmen waarbij ze garant staan voor veiligheid en beheersbaarheid.
23-09-2021, 11:42 door Anoniem
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.
23-09-2021, 11:48 door Anoniem
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.
23-09-2021, 11:54 door Briolet
Door Coritchando: Wat ik er zo snel uit haal is dat je Outlook in ieder geval een certificate warning geeft.…

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.
23-09-2021, 12:38 door MathFox
Door Coritchando: 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?
Uit het artikel:
However, this could be easily avoided by deploying an actual SSL certificate. In our case, we deployed a LetsEncrypt certificate within seconds, which remediated the issue of the SSL warning being displayed.
23-09-2021, 12:43 door Hatsikidee
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.
23-09-2021, 12:51 door -Peter-
Door Anoniem: 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?

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.

Door Toje Fos:
Microsoft laat in een reactie weten dat het niet van tevoren over het probleem was ingelicht en stappen zal nemen om gebruikers te beschermen.

Irresponsible disclosure zou als computervredebreuk behandeld moeten worden?

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
23-09-2021, 13:14 door Anoniem
Door Anoniem: 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?
Omdat dit eigenlijk een client probleem is en eigenlijk niets met Exchange te maken heeft.
23-09-2021, 13:14 door Anoniem
Door Hatsikidee: 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.

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.
23-09-2021, 13:15 door Hatsikidee
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.
23-09-2021, 13:39 door Anoniem
Door Anoniem: Vrijwel een identiek probleem met wpad.
https://nakedsecurity.sophos.com/2016/05/25/when-domain-names-attack-the-wpad-name-collision-vulnerability/

Is volgens mij een en hetzelfde:
Windows proxy auto discovery;
Ik denk zelfs gerelateerd aan Proxyshell heel kort door de bocht
23-09-2021, 13:43 door Hatsikidee
Door Anoniem:
Door Hatsikidee: 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.

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.

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.
23-09-2021, 13:51 door Anoniem
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.
23-09-2021, 14:49 door Briolet
Door Hatsikidee:Nu je het zegt, ik lees ook nergens terug in de MS documentatie dat dit gebeurt. …

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

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.
23-09-2021, 14:50 door Anoniem
autodiscover met outlook gaat nooit naar een ander domeinnaam dan wat in je emailadres staat, dus verhaal lijkt me broodje aap
23-09-2021, 15:18 door Anoniem
Dit soort problemen is het gevolg van het instellen van een "default domain search list".
NOOIT doen!
23-09-2021, 16:24 door Anoniem
Door Anoniem:
Door Anoniem: 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?
Omdat dit eigenlijk een client probleem is en eigenlijk niets met Exchange te maken heeft.
OK dus ik hoef mij met thunderbird en exchange geen zorgen te maken? Die doet namelijk ook een autodiscovery
23-09-2021, 19:04 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: 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?
Omdat dit eigenlijk een client probleem is en eigenlijk niets met Exchange te maken heeft.
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.
23-09-2021, 19:32 door Anoniem
Door Anoniem:
Wat NIET zou moeten is(!):
5e poging: http://autodiscover.nl
>>> Dit is gewoon een verkeerde up loop.

Dit is gewoon een fout. punt.

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
24-09-2021, 01:36 door Erik van Straten - Bijgewerkt: 24-09-2021, 01:41
Door Anoniem: 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)
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:
Authentication required
https://autodiscover-s.outlook.com is requesting your username and password.
User Name: [<invoerveld>]
Password: [<invoerveld>]

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).

Door redactie: Microsoft laat in een reactie weten dat het niet van tevoren over het probleem was ingelicht
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.:
Subject: Office365 (EMEA only?) security risk via Outlook/Exchange Autodiscover.xml request via http
[...]
However, if I use my PC on an untrusted network, an attacker may return any XML file they like. Worse, if I open https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml, that server asks me to log on (http basic authentication). So anyone able to intercept the http request will probably be able to obtain my authentication credentials.

The behavior of Outlook to fall back to http is described in, among other Microsoft webpages, https://support.microsoft.com/en-us/help/2212902/unexpected-autodiscover-behavior-when-you-have-registry-settings-under-the-autodiscover-key (CAUSE [...] HTTP redirect method).

Apparent cause: multiple autodiscover.outlook.com servers reject https connections, forcing Outlook to redirect to an http request which I consider a serious security risk.
[...]

Het antwoord dat ik kreeg:
Hello,

Thank you for contacting the Microsoft Security Response Center (MSRC).

In general, man in the middle style attack vectors are not considered valid for security servicing due to the user already being in a compromised state.

However I have sent your submission to an analyst for this area and I will update you as soon as I have a response.

For an in-depth discussion of what constitutes a product vulnerability please see the following:
"Definition of a Security Vulnerability"
<https://technet.microsoft.com/library/cc751383.aspx>

Again, we appreciate your report.

Regards,

<voornaam>
MSRC
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).
24-09-2021, 02:12 door [Account Verwijderd]
Door MathFox:
Door Toje Fos:
Irresponsible disclosure zou als computervredebreuk behandeld moeten worden?

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

Nou ja zeg! De gewaarschuwde fabrikant van de software zou in zo'n geval toch onmiddellijk maatregelen treffen om juist dat te voorkomen?
26-09-2021, 16:34 door Anoniem
Door Erik van Straten:
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).

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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.