[ad_1]
Thanks to James Cope and Rajeev kapur from Sophos IT for their help with this article.
Researchers from a cybersecurity startup called Guardicore just published a report on an experiment they conducted over the past four months …
… in which they claim to have collected hundreds of thousands of Exchange and Windows passwords that have been inadvertently uploaded to their servers by unsuspecting Outlook users from a wide variety of corporate networks.
The problem, researchers say, is caused by a Microsoft feature known as Auto discovery, which is used by various parts of Windows, including Outlook, to simplify setting up new accounts.
For example, if I want to connect Outlook on my laptop to the “Exchange server” managed by IT, I don’t need to know and correctly enter a whole stack of technical specifications before going all the way to setup. a password and sending my first e-mail.
Law. Next step in setting up Autodiscover.
If you’ve gone through the process before, you’ve probably seen the two simple setup screens above, where you enter your email address, tell it you’re looking for an Exchange server, and Outlook comes out and automatically finds out the details of. configuration for you.
The Autodiscover Process
Microsoft’s Autodiscover process can include many different steps, as explained in its own Autodiscover documentation, and different apps might use slightly different variations on Microsoft’s core theme.
For email accounts, Autodiscover typically involves creating a short list of URLs where configuration file data can be expected, then trying to access those URLs and retrieve the configuration data there. stored, until one of them passes (or all of them fail).
For an email address such as duck@naksec.test, as noted above, the documentation suggests that you look for the following configuration files:
https://autodiscover.naksec.test/autodiscover/autodiscover.xml https://naksec.test/autodiscover/autodiscover.xml
This is because when we tried to set up Outlook 2016 on a network with no Autodiscover files or servers present, and so we expected Outlook to browse its entire directory of possible Autodiscover file locations, we found out. ‘observed looking for the following sequence of network names in our own domain:
autodiscover.naksec.test naksec.test _autodiscover._tcp.naksec.test
(The last query above was a DNS lookup known as an SRV record, a common way to look up server names for specific services, including Autodiscover, in Microsoft domains. The data returned by this SRV registration are, like the previous two, under the control of the owner of the naksec.test domain, since the DNS name is a subdomain of naksec.test.)
According to Guardicore, however, in their testing – possibly conducted with an older version of Windows and Outlook, but we’re not sure – there was an extra step in the process, which is if these two sites fail …
autodiscover.naksec.test <--if this failed naksec.test <--and this failed
… then the Autodiscover code would move up a notch in the domain hierarchy and also try:
autodiscover.test <--then Guardicore reported that this site was tried as well
External domains considered harmful
It seems dangerous, because the owner of the domain naksec.test controls the use of the server name autodiscover.naksec.test, but the domain autodiscover.test could be owned by someone else entirely.
And that third-party owner could have maliciously registered it, with the specific intention of monitoring accidental “autodiscover request spills” inside other people’s networks.
We assume that if the email address had been duck@naksec.co.test rather than simply duck@naksec.test, as might be the case in a country with a strictly two-tiered trade domain system like New Zealand (.co.nz) or South Africa (.co.za), then the Guardicore sequence could have been …
autodiscover.naksec.co.test naksec.co.test _autodiscover._tcp.naksec.co.test
… as in the example above, followed by:
autodiscover.co.test <--go back up one domain level autodiscover.test <--and then go back up one more as well
This could, in theory, first expose you to a sneaky registered third-party domain called autodiscover.co.test, follow-up (in case of failure) of the same, uncertain autodiscover.test domain mentioned above. (Some two-level domain countries sell both second-level domains, for example .co.uk, and top-level domains, for example .uk.)
So Guardicore went out and registered a whole bunch of ‘Autodiscover’ domains in various two and one tier domain hierarchies, and set up listening web servers on each of them, including:
Autodiscover.com.br Autodiscover.com.cn Autodiscover.com.co Autodiscover.es Autodiscover.fr Autodiscover.in Autodiscover.it Autodiscover.sg Autodiscover.uk Autodiscover.xyz Autodiscover.online
Researchers say that over the next four months, they Collected over 1,000,000 unsolicited and unexpected Autodiscover requests, including a significant minority authentication tokens or clear passwords included which could, in theory, provide access to the disclosed accounts.
Worse yet, they say, their fake Autodiscover servers, faced with login information such as NTLM credentials from which the original password could not be recovered, were frequently able to reply to the sender with a “please downgrade” response which caused the client software. on the other end (probably Outlook) to try again using HTTP Basic Authentication.
In Basic Authentication, the password is not salted or hashed to prevent it from being reversed and recovered.
Instead, the password is simply encoded using the base64 algorithm, so that the original data can be extracted as needed.
How bad is that?
Obviously, for most businesses with Outlook clients trying to automatically discover Exchange servers on the corporate network, this type of data leak can be considered unlikely.
Any internal locations where Autodiscover data would typically be found would have to fail first, leaving only the domains under someone else’s control to receive trace requests.
Additionally, the appropriate Autodiscover domain should be registered and active, and in the hands of an owner who intended to abuse it to recover the password and authentication data it was not. not supposed to receive at all.
Nonetheless, Guardicore’s own researchers claim to have seen and collected a significant amount of traffic over a four month period, along with tens or hundreds of thousands of unique passwords.
The risk is therefore worth considering, especially if your network is generally immune (as it has its own Autodiscover servers which usually respond first), but may unexpectedly ‘fail to open’ (s ‘there is an internal network failure that would suddenly cause clients to go looking for Autodiscover servers externally).
What to do?
- Remember to block external domains starting with the word
autodiscover, using your web filtering firewall. This will prevent any application on your network from inadvertently connecting to external Autodiscover servers. Note that you may need to add legitimate cloud sites to your allow list, for exampleautodiscover.outlook.com, but we ourselves don’t remember ever visiting a regular website whose name began with the word “Autodiscover”. - Remember to activate Outlook
Disable Autodiscoverprotection using Group Policy. In the GPEDIT Policy Editor or from the Group Policy Management Console, navigate to User configuration > Administrative Templates > Microsoft Outlook 2016 [amend number by version] > Account settings > To exchange. Click onDisable Autodiscover, Choose[Enable]and light upExclude the query for the AutoDiscover domain. According to Microsoft, this means that “Outlook [will] do not use the following URL: https: // autodiscover.[DOMAIN]]/autodiscover/autodiscover.xml ”.
Note that you will need to install the Microsoft Administrative Template files for Microsoft 365 and Office, otherwise the Microsoft Outlook Group Policy items described above will not appear.
If you haven’t installed the template files or don’t want to use GPEDIT or Group Policy for this process, you can enable the setting yourself in the registry:
Registry Key: HKCUsoftwarepoliciesmicrosoftoffice[VERSIONNUMBER]outlookautodiscover Create Value: excludehttpsautodiscoverdomain Value type: DWORD Set value to: 1
What we observed
As simple as the Group Policy workaround may sound, and as much as Microsoft’s help file for Office Group Policy settings seems to reassure you that the setting we have listed will remove the use of names from “automatic discovery” domain …
… We have to say that this is not how it turned out in our own (necessarily brief) tests.
The bad news even after setting the excludehttpsautodiscoverdomain option, we nevertheless observed Outlook 2016 trying to locate autodiscover.naksec.test in our experiences. (We also tried with realistic TLD and 2LD external domains, for example .fr and .co.za.)
The good news is that we were unable to entice Outlook to visit domains that would have been outside of our own network.
In other words, using an email domain from naksec.test, we were unable to try Outlook autodiscover.test, even after autodiscover.naksec.test had failed. (Again, we also tested this behavior with realistic external TLD and 2LD domains.)
So while we couldn’t get our own workaround (based on Microsoft’s documentation) to work …
… We just couldn’t get the “Autodiscover Great Leak” hack (based on Guardicore article) to work either.
Whether that means you’re safe as long as you use Office 2016, and Guardicore is wrong, we can’t be sure.
We can only tell you that this is what we observed on a standalone Windows 10 Enterprise machine when we tried to connect to a nonexistent Exchange server and watched Outlook go through its Autodiscover list – our result was different from the behavior described. by Guardicore.
If you have older versions of Outlook or other email clients that you can try on your own network while monitoring the affected app’s network requests, we would love you to share your results below!
[ad_2]
Source link