Login
The proliferation of new top-level domains (TLDs) has exacerbated a well-known security weakness: Many organizations set up their internal Microsoft authentication systems years ago using domain names in TLDs that didn’t exist at the time. Meaning, they are continuously sending their Windows usernames and passwords to domain names they do not control and which are freely available for anyone to register. Here’s a look at one security researcher’s efforts to map and shrink the size of this insidious problem.
At issue is a well-known security and privacy threat called “namespace collision,” a situation where domain names intended to be used exclusively on an internal company network end up overlapping with domains that can resolve normally on the open Internet.
Windows computers on a private corporate network validate other things on that network using a Microsoft innovation called Active Directory, which is the umbrella term for a broad range of identity-related services in Windows environments. A core part of the way these things find each other involves a Windows feature called “DNS name devolution,” a kind of network shorthand that makes it easier to find other computers or servers without having to specify a full, legitimate domain name for those resources.
Consider the hypothetical private network internalnetwork.example.com: When an employee on this network wishes to access a shared drive called “drive1,” there’s no need to type “drive1.internalnetwork.example.com” into Windows Explorer; entering “\\drive1\” alone will suffice, and Windows takes care of the rest.
But problems can arise when an organization has built their Active Directory network on top of a domain they don’t own or control. While that may sound like a bonkers way to design a corporate authentication system, keep in mind that many organizations built their networks long before the introduction of hundreds of new top-level domains (TLDs), like .network, .inc, and .llc.
For example, a company in 2005 builds their Microsoft Active Directory service around the domain company.llc, perhaps reasoning that since .llc wasn’t even a routable TLD, the domain would simply fail to resolve if the organization’s Windows computers were ever used outside of its local network.
Alas, in 2018, the .llc TLD was born and began selling domains. From then on, anyone who registered company.llc would be able to passively intercept that organization’s Microsoft Windows credentials, or actively modify those connections in some way — such as redirecting them somewhere malicious.
Philippe Caturegli, founder of the security consultancy Seralys, is one of several researchers seeking to chart the size of the namespace collision problem. As a professional penetration tester, Caturegli has long exploited these collisions to attack specific targets that were paying to have their cyber defenses probed. But over the past year, Caturegli has been gradually mapping this vulnerability across the Internet by looking for clues that appear in self-signed security certificates (e.g. SSL/TLS certs).
Caturegli has been scanning the open Internet for self-signed certificates referencing domains in a variety of TLDs likely to appeal to businesses, including .ad, .associates, .center, .cloud, .consulting, .dev, .digital, .domains, .email, .global, .gmbh, .group, .holdings, .host, .inc, .institute, .international, .it, .llc, .ltd, .management, .ms, .name, .network, .security, .services, .site, .srl, .support, .systems, .tech, .university, .win and .zone, among others.
Seralys found certificates referencing more than 9,000 distinct domains across those TLDs. Their analysis determined many TLDs had far more exposed domains than others, and that about 20 percent of the domains they found ending .ad, .cloud and .group remain unregistered.
“The scale of the issue seems bigger than I initially anticipated,” Caturegli said in an interview with KrebsOnSecurity. “And while doing my research, I have also identified government entities (foreign and domestic), critical infrastructures, etc. that have such misconfigured assets.”
Some of the above-listed TLDs are not new and correspond to country-code TLDs, like .it for Italy, and .ad, the country-code TLD for the tiny nation of Andorra. Caturegli said many organizations no doubt viewed a domain ending in .ad as a convenient shorthand for an internal Active Directory setup, while being unaware or unworried that someone could actually register such a domain and intercept all of their Windows credentials and any unencrypted traffic.
When Caturegli discovered an encryption certificate being actively used for the domain memrtcc.ad, the domain was still available for registration. He then learned the .ad registry requires prospective customers to show a valid trademark for a domain before it can be registered.
Undeterred, Caturegli found a domain registrar that would sell him the domain for $160, and handle the trademark registration for another $500 (on subsequent .ad registrations, he located a company in Andorra that could process the trademark application for half that amount).
Caturegli said that immediately after setting up a DNS server for memrtcc.ad, he began receiving a flood of communications from hundreds of Microsoft Windows computers trying to authenticate to the domain. Each request contained a username and a hashed Windows password, and upon searching the usernames online Caturegli concluded they all belonged to police officers in Memphis, Tenn.
“It looks like all of the police cars there have a laptop in the cars, and they’re all attached to this memrtcc.ad domain that I now own,” Caturegli said, noting wryly that “memrtcc” stands for “Memphis Real-Time Crime Center.”
Caturegli said setting up an email server record for memrtcc.ad caused him to begin receiving automated messages from the police department’s IT help desk, including trouble tickets regarding the city’s Okta authentication system.
Mike Barlow, information security manager for the City of Memphis, confirmed the Memphis Police’s systems were sharing their Microsoft Windows credentials with the domain, and that the city was working with Caturegli to have the domain transferred to them.
“We are working with the Memphis Police Department to at least somewhat mitigate the issue in the meantime,” Barlow said.
Domain administrators have long been encouraged to use .local for internal domain names, because this TLD is reserved for use by local networks and cannot be routed over the open Internet. However, Caturegli said many organizations seem to have missed that memo and gotten things backwards — setting up their internal Active Directory structure around the perfectly routable domain local.ad.
Caturegli said he knows this because he “defensively” registered local.ad, which he said is currently used by multiple large organizations for Active Directory setups — including a European mobile phone provider, and the City of Newcastle in the United Kingdom.
Caturegli said he has now defensively registered a number of domains ending in .ad, such as internal.ad and schema.ad. But perhaps the most dangerous domain in his stable is wpad.ad. WPAD stands for Web Proxy Auto-Discovery Protocol, which is an ancient, on-by-default feature built into every version of Microsoft Windows that was designed to make it simpler for Windows computers to automatically find and download any proxy settings required by the local network.
Trouble is, any organization that chose a .ad domain they don’t own for their Active Directory setup will have a whole bunch of Microsoft systems constantly trying to reach out to wpad.ad if those machines have proxy automated detection enabled.
Security researchers have been beating up on WPAD for more than two decades now, warning time and again how it can be abused for nefarious ends. At this year’s DEF CON security conference in Las Vegas, for example, a researcher showed what happened after they registered the domain wpad.dk: Immediately after switching on the domain, they received a flood of WPAD requests from Microsoft Windows systems in Denmark that had namespace collisions in their Active Directory environments.
Image: Defcon.org.
For his part, Caturegli set up a server on wpad.ad to resolve and record the Internet address of any Windows systems trying to reach Microsoft Sharepoint servers, and saw that over one week it received more than 140,000 hits from hosts around the world attempting to connect.
The fundamental problem with WPAD is the same with Active Directory: Both are technologies originally designed to be used in closed, static, trusted office environments, and neither was built with today’s mobile devices or workforce in mind.
Probably one big reason organizations with potential namespace collision problems don’t fix them is that rebuilding one’s Active Directory infrastructure around a new domain name can be incredibly disruptive, costly, and risky, while the potential threat is considered comparatively low.
But Caturegli said ransomware gangs and other cybercrime groups could siphon huge volumes of Microsoft Windows credentials from quite a few companies with just a small up-front investment.
“It’s an easy way to gain that initial access without even having to launch an actual attack,” he said. “You just wait for the misconfigured workstation to connect to you and send you their credentials.”
If we ever learn that cybercrime groups are using namespace collisions to launch ransomware attacks, nobody can say they weren’t warned. Mike O’Connor, an early domain name investor who registered a number of choice domains such as bar.com, place.com and television.com, warned loudly and often back in 2013 that then-pending plans to add more than 1,000 new TLDs would massively expand the number of namespace collisions.
Mr. O’Connor’s most famous domain is corp.com, because for several decades he watched in horror as hundreds of thousands of Microsoft PCs continuously blasted his domain with credentials from organizations that had set up their Active Directory environment around the domain corp.com.
It turned out that Microsoft had actually used corp.com as an example of how one might set up Active Directory in some editions of Windows NT. Worse, some of the traffic going to corp.com was coming from Microsoft’s internal networks, indicating some part of Microsoft’s own internal infrastructure was misconfigured. When O’Connor said he was ready to sell corp.com to the highest bidder in 2020, Microsoft agreed to buy the domain for an undisclosed amount.
“I kind of imagine this problem to be something like a town [that] knowingly built a water supply out of lead pipes, or vendors of those projects who knew but didn’t tell their customers,” O’Connor told KrebsOnSecurity. “This is not an inadvertent thing like Y2K where everybody was surprised by what happened. People knew and didn’t care.”
Google says it recently fixed an authentication weakness that allowed crooks to circumvent the email verification required to create a Google Workspace account, and leverage that to impersonate a domain holder at third-party services that allow logins through Google’s “Sign in with Google” feature.
Last week, KrebsOnSecurity heard from a reader who said they received a notice that their email address had been used to create a potentially malicious Workspace account that Google had blocked.
“In the last few weeks, we identified a small-scale abuse campaign whereby bad actors circumvented the email verification step in our account creation flow for Email Verified (EV) Google Workspace accounts using a specially constructed request,” the notice from Google read. “These EV users could then be used to gain access to third-party applications using ‘Sign In with Google’.”
In response to questions, Google said it fixed the problem within 72 hours of discovering it, and that the company has added additional detection to protect against these types of authentication bypasses going forward.
Anu Yamunan, director of abuse and safety protections at Google Workspace, told KrebsOnSecurity the malicious activity began in late June, and involved “a few thousand” Workspace accounts that were created without being domain-verified.
Google Workspace offers a free trial that people can use to access services like Google Docs, but other services such as Gmail are only available to Workspace users who can validate control over the domain name associated with their email address. The weakness Google fixed allowed attackers to bypass this validation process. Google emphasized that none of the affected domains had previously been associated with Workspace accounts or services.
“The tactic here was to create a specifically-constructed request by a bad actor to circumvent email verification during the signup process,” Yamunan said. “The vector here is they would use one email address to try to sign in, and a completely different email address to verify a token. Once they were email verified, in some cases we have seen them access third party services using Google single sign-on.”
Yamunan said none of the potentially malicious workspace accounts were used to abuse Google services, but rather the attackers sought to impersonate the domain holder to other services online.
In the case of the reader who shared the breach notice from Google, the imposters used the authentication bypass to associate his domain with a Workspace account. And that domain was tied to his login at several third-party services online. Indeed, the alert this reader received from Google said the unauthorized Workspace account appears to have been used to sign in to his account at Dropbox.
Google said the now-fixed authentication bypass is unrelated to a recent issue involving cryptocurrency-based domain names that were apparently compromised in their transition to Squarespace, which last year acquired more than 10 million domains that were registered via Google Domains.
On July 12, a number of domains tied to cryptocurrency businesses were hijacked from Squarespace users who hadn’t yet set up their Squarespace accounts. Squarespace has since published a statement blaming the domain hijacks on “a weakness related to OAuth logins”, which Squarespace said it fixed within hours.
At least a dozen organizations with domain names at domain registrar Squarespace saw their websites hijacked last week. Squarespace bought all assets of Google Domains a year ago, but many customers still haven’t set up their new accounts. Experts say malicious hackers learned they could commandeer any migrated Squarespace accounts that hadn’t yet been registered, merely by supplying an email address tied to an existing domain.
Until this past weekend, Squarespace’s website had an option to log in via email.
The Squarespace domain hijacks, which took place between July 9 and July 12, appear to have mostly targeted cryptocurrency businesses, including Celer Network, Compound Finance, Pendle Finance, and Unstoppable Domains. In some cases, the attackers were able to redirect the hijacked domains to phishing sites set up to steal visitors’ cryptocurrency funds.
New York City-based Squarespace purchased roughly 10 million domain names from Google Domains in June 2023, and it has been gradually migrating those domains to its service ever since. Squarespace has not responded to a request for comment, nor has it issued a statement about the attacks.
But an analysis released by security experts at Metamask and Paradigm finds the most likely explanation for what happened is that Squarespace assumed all users migrating from Google Domains would select the social login options — such “Continue with Google” or “Continue with Apple” — as opposed to the “Continue with email” choice.
Taylor Monahan, lead product manager at Metamask, said Squarespace never accounted for the possibility that a threat actor might sign up for an account using an email associated with a recently-migrated domain before the legitimate email holder created the account themselves.
“Thus nothing actually stops them from trying to login with an email,” Monahan told KrebsOnSecurity. “And since there’s no password on the account, it just shoots them to the ‘create password for your new account’ flow. And since the account is half-initialized on the backend, they now have access to the domain in question.”
What’s more, Monahan said, Squarespace did not require email verification for new accounts created with a password.
“The domains being migrated from Google to Squarespace are known,” Monahan said. “It’s either public or easily discernible info which email addresses have admin of a domain. And if that email never sets up their account on Squarespace — say because the billing admin left the company five years ago or folks just ignored the email — anyone who enters that email@domain in the squarespace form now has full access to control to the domain.”
The researchers say some Squarespace domains that were migrated over also could be hijacked if attackers discovered the email addresses for less privileged user accounts tied to the domain, such as “domain manager,” which likewise has the ability to transfer a domain or point it to a different Internet address.
Squarespace says domain owners and domain managers have many of the same privileges, including the ability to move a domain or manage the site’s domain name server (DNS) settings.
Monahan said the migration has left domain owners with fewer options to secure and monitor their accounts.
“Squarespace can’t support users who need any control or insight into the activity being performed in their account or domain,” Monahan said. “You basically have no control over the access different folks have. You don’t have any audit logs. You don’t get email notifications for some actions. The owner doesn’t get email notification for actions taken by a ‘domain manager.’ This is absolutely insane if you’re used to and expecting the controls Google provides.”
The researchers have published a comprehensive guide for locking down Squarespace user accounts, which urges Squarespace users to enable multi-factor authentication (disabled during the migration).
“Determining what emails have access to your new Squarespace account is step 1,” the help guide advises. “Most teams DO NOT REALIZE these accounts even exist, let alone theoretically have access.”
The guide also recommends removing unnecessary Squarespace user accounts, and disabling reseller access in Google Workspace.
“If you bought Google Workspace via Google Domains, Squarespace is now your authorized reseller,” the help document explains. “This means that anyone with access to your Squarespace account also has a backdoor into your Google Workspace unless you explicitly disable it by following the instructions here, which you should do. It’s easier to secure one account than two.”
Update, July 23, 1:50 p.m. ET: Squarespace has published a post-mortem about the incident. Their statement blames the domain hijacks on “a weakness related to OAuth logins”, which Squarespace said it fixed within hours, and contradicts the findings presented by the researchers above. Here are the relevant bits from their statement:
“During this incident, all compromised accounts were using third-party OAuth. Neither Squarespace nor any third-party authentication provider made any changes to authentication as part of our migration of Google Domains to Squarespace. To be clear, the migration of domains involved no changes to multi-factor authentication before, during or after.”
“To date there is no evidence that Google Workspace accounts were or are at risk, and we have received no customer reports to this effect. As a reseller, Squarespace manages billing but customers access Workspace directly using their Google account.”
“Our analysis shows no evidence that Squarespace accounts using an email-based login with an unverified email address were involved with this attack.”
FreshRSS 