• Articles
    • Editorial Articles
    • Research Articles
    • WatchGuard Articles
  • The 443 Podcast
  • Threat Landscape
  • About
    • About Us
    • Contact Us
    • Contribute to Secplicity

Secplicity - Security Simplified

Powered by WatchGuard Technologies

Microsoft Resolves Documentation Vulnerability with Domain Purchase

April 8, 2020 By Trevor Collins

Recently krebsonsecurity published an article on the sale of the domain name corp.com to Microsoft. This sale resolves an important security concern caused by many IT professionals following default configuration guidelines a bit too closely. In the past, Microsoft documentation used the example domain of “corp”, short for corporation, in much of their documentation and didn’t clearly recommend to users to use their own name instead. This led many admins to set up their private company domain with the domain “corp.” Because corp.com was a legitimately registered domain, it could cause a configuration vulnerability on those networks if users were to take their laptops off of the private network or if the local DNS server suddenly became unreachable. Specifically, if the previous owner of corp.com wanted to be malicious, they could set up a server and listen for these errant connections then attempt to steal information ranging from authentication details to file uploads.

Today, Microsoft doesn’t allow signal level domain names, you must use a TLD (Top Level Domain) with your domain name, like “example.com” instead of just your domain name by itself like “example” Microsoft changed their documentation, but older domains may still use signal level domains. While “corp” may be the most popular domain, many other domains don’t go to trusted websites. Test[.]com for example, leads to a website of unknown security. Administrators should make sure they carefully choose their domain names when setting up a new Active Directory or LDAP environment. Any domain name conflict may cause users to access the wrong resources or give private information to the wrong group.

When creating a domain, ensure you don’t conflict with any other public domains. For domains used for testing, and domains that will never become public you can stay secure with “.local” or “.test” But setting up a domain with common words like “local.local” may conflict if you merge the domain with another domain using the same configuration. Best practices for security and usability recommend you register the domain even if used locally. For more on selecting a domain name see the Microsoft documentation.

It is common for improper documentation to cause misconfigurations. The Internet Assigned Numbers Authority (IANA) governs domain name usage and specifically reserves “example.com”, “example.org” and “.example” for use in documentation. Technical writers who create documentation that involves domain names should never use any other domain as an example,  not everyone follows this rule and sometimes just the “example” domain names may not be sufficient. Sysadmins should not, of course, use these example names in their production setups, but at least in the event someone uses the reserved example domains they won’t resolve to an unknown party. Either way, when configurating a new domain, ensure you use a unique name and not one used in any documentation.

Share This:

Related

Filed Under: Editorial Articles

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

The 443 Podcast

A weekly podcast featuring the leading white-hat hackers and security researchers. Listen Now
the 443 podcast

Threat Landscape

Filter and view Firebox Feed data by type of attack, region, country, and date range. View Now
threat landscape

Top Posts

  • Cybersecurity News: Free Cybersecurity Training, TrickBot Group Exposed, Major GoDaddy Breach, and Russia to Legalize cybercrime?!
  • US National Cybersecurity Strategy
  • 3CX Supply Chain Attack
  • Here Come The Regulations

Email Newsletter

Sign up to get the latest security news and threat analysis delivered straight to your inbox

By signing up you agree to our Privacy Policy.


The views and opinions expressed on this website are those of the authors and do not necessarily reflect the policy or position of WatchGuard Technologies.

Stay in Touch

Recent Posts

  • 3CX Supply Chain Attack
  • The NSA’s Guidance on Securing Authentication
  • Cybersecurity News: LastPass Incident Revealed, White House Issues Cybersecurity Strategy, FBI Purchases Leaked USHOR PII Data, and a Slew of Other Breaches
  • An Update on Section 230
  • Here Come The Regulations
View All

Search

Archives

Copyright © 2023 WatchGuard Technologies · Cookie Policy · Privacy Policy · Terms of Use