Login
Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the third quarter of 2023 closed with 359.3 million domain name registrations across all top-level domains (TLDs), an increase of 2.7 million domain name registrations, or 0.8%, compared to the second quarter of 2023. Domain name registrations also increased by 8.5 million, or 2.4%, year over year.
Check out the latest issue of The Domain Name Industry Brief Quarterly Report to see domain name stats from the third quarter of 2023, including:
DNIB.com and The Domain Name Industry Brief Quarterly Report are sponsored by Verisign. To see past issues of the quarterly report, interactive dashboards, and learn about DNIB.com’s statistical methodology, please visit DNIB.com.
The post Domain Name Industry Brief Quarterly Report: DNIB.com Announces 359.3 Million Domain Name Registrations in the Third Quarter of 2023 appeared first on Verisign Blog.
Last week, KrebsOnSecurity broke the news that one of the largest cybercrime services for laundering stolen merchandise was hacked recently, exposing its internal operations, finances and organizational structure. In today’s Part II, we’ll examine clues about the real-life identity of “Fearlless,” the nickname chosen by the proprietor of the SWAT USA Drops service.
Based in Russia, SWAT USA recruits people in the United States to reship packages containing pricey electronics that are purchased with stolen credit cards. As detailed in this Nov. 2 story, SWAT currently employs more than 1,200 U.S. residents, all of whom will be cut loose without a promised payday at the end of their first month reshipping stolen goods.
The current co-owner of SWAT, a cybercriminal who uses the nickname “Fearlless,” operates primarily on the cybercrime forum Verified. This Russian-language forum has tens of thousands of members, and it has suffered several hacks that exposed more than a decade’s worth of user data and direct messages.
January 2021 posts on Verified show that Fearlless and his partner Universalo purchased the SWAT reshipping business from a Verified member named SWAT, who’d been operating the service for years. SWAT agreed to transfer the business in exchange for 30 percent of the net profit over the ensuing six months.
Cyber intelligence firm Intel 471 says Fearlless first registered on Verified in February 2013. The email address Fearlless used on Verified leads nowhere, but a review of Fearlless’ direct messages on Verified indicates this user originally registered on Verified a year earlier as a reshipping vendor, under the alias “Apathyp.”
There are two clues supporting the conclusion that Apathyp and Fearlless are the same person. First, the Verified administrators warned Apathyp he had violated the forum’s rules barring the use of multiple accounts by the same person, and that Verified’s automated systems had detected that Apathyp and Fearlless were logging in from the same device. Second, in his earliest private messages on Verified, Fearlless told others to contact him on an instant messenger address that Apathyp had claimed as his.
Intel 471 says Apathyp registered on Verified using the email address triploo@mail.ru. A search on that email address at the breach intelligence service Constella Intelligence found that a password commonly associated with it was “niceone.” But the triploo@mail.ru account isn’t connected to much else that’s interesting except a now-deleted account at Vkontakte, the Russian answer to Facebook.
However, in Sept. 2020, Apathyp sent a private message on Verified to the owner of a stolen credit card shop, saying his credentials no longer worked. Apathyp told the proprietor that his chosen password on the service was “12Apathy.”
A search on that password at Constella reveals it was used by just four different email addresses, two of which are particularly interesting: gezze@yandex.ru and gezze@mail.ru. Constella discovered that both of these addresses were previously associated with the same password as triploo@mail.ru — “niceone,” or some variation thereof.
Constella found that years ago gezze@mail.ru was used to create a Vkontakte account under the name Ivan Sherban (former password: “12niceone“) from Magnitogorsk, an industrial city in the southern region of Russia. That same email address is now tied to a Vkontakte account for an Ivan Sherban who lists his home as Saint Petersburg, Russia. Sherban’s profile photo shows a heavily tattooed, muscular and recently married individual with his beautiful new bride getting ready to drive off in a convertible sports car.
A pivotal clue for validating the research into Apathyp/Fearlless came from the identity intelligence firm myNetWatchman, which found that gezze@mail.ru at one time used the passwords “геззи1991” (gezze1991) and “gezze18081991.”
Care to place a wager on when Vkontakte says is Mr. Sherban’s birthday? Ten points if you answered August 18 (18081991).
Mr. Sherban did not respond to multiple requests for comment.
Okta, a company that provides identity tools like multi-factor authentication and single sign-on to thousands of businesses, has suffered a security breach involving a compromise of its customer support unit, KrebsOnSecurity has learned. Okta says the incident affected a “very small number” of customers, however it appears the hackers responsible had access to Okta’s support platform for at least two weeks before the company fully contained the intrusion.
In an advisory sent to an undisclosed number of customers on Oct. 19, Okta said it “has identified adversarial activity that leveraged access to a stolen credential to access Okta’s support case management system. The threat actor was able to view files uploaded by certain Okta customers as part of recent support cases.”
Okta explained that when it is troubleshooting issues with customers it will often ask for a recording of a Web browser session (a.k.a. an HTTP Archive or HAR file). These are sensitive files because they can include the customer’s cookies and session tokens, which intruders can then use to impersonate valid users.
“Okta has worked with impacted customers to investigate, and has taken measures to protect our customers, including the revocation of embedded session tokens,” their notice continued. “In general, Okta recommends sanitizing all credentials and cookies/session tokens within a HAR file before sharing it.”
The security firm BeyondTrust is among the Okta customers who received Thursday’s alert from Okta. BeyondTrust Chief Technology Officer Marc Maiffret said that alert came more than two weeks after his company alerted Okta to a potential problem.
Maiffret emphasized that BeyondTrust caught the attack earlier this month as it was happening, and that none of its own customers were affected. He said that on Oct 2., BeyondTrust’s security team detected that someone was trying to use an Okta account assigned to one of their engineers to create an all-powerful administrator account within their Okta environment.
When BeyondTrust reviewed the activity of the employee account that tried to create the new administrative profile, they found that — just 30 minutes prior to the unauthorized activity — one of their support engineers shared with Okta one of these HAR files that contained a valid Okta session token, Maiffret said.
“Our admin sent that [HAR file] over at Okta’s request, and 30 minutes after that the attacker started doing session hijacking, tried to replay the browser session and leverage the cookie in that browser recording to act on behalf of that user,” he said.
Maiffret said BeyondTrust followed up with Okta on Oct. 3 and said they were fairly confident Okta had suffered an intrusion, and that he reiterated that conclusion in a phone call with Okta on October 11 and again on Oct. 13.
In an interview with KrebsOnSecurity, Okta’s Deputy Chief Information Security Officer Charlotte Wylie said Okta initially believed that BeyondTrust’s alert on Oct. 2 was not a result of a breach in its systems. But she said that by Oct. 17, the company had identified and contained the incident — disabling the compromised customer case management account, and invalidating Okta access tokens associated with that account.
Wylie declined to say exactly how many customers received alerts of a potential security issue, but characterized it as a “very, very small subset” of its more than 18,000 customers.
The disclosure from Okta comes just weeks after casino giants Caesar’s Entertainment and MGM Resorts were hacked. In both cases, the attackers managed to social engineer employees into resetting the multi-factor login requirements for Okta administrator accounts.
In March 2022, Okta disclosed a breach from the hacking group LAPSUS$, which specialized in social-engineering employees at targeted companies. An after-action report from Okta on that incident found that LAPSUS$ had social engineered its way onto the workstation of a support engineer at Sitel, a third-party outsourcing company that had access to Okta resources.
Okta’s Wylie declined to answer questions about how long the intruder may have had access to the company’s case management account, or who might have been responsible for the attack. However, she did say the company believes this is an adversary they have seen before.
“This is a known threat actor that we believe has targeted us and Okta-specific customers,” Wylie said.
Update, 2:57 p.m. ET: Okta has published a blog post about this incident that includes some “indicators of compromise” that customers can use to see if they were affected. But the company stressed that “all customers who were impacted by this have been notified. If you’re an Okta customer and you have not been contacted with another message or method, there is no impact to your Okta environment or your support tickets.”
Update, 3:36 p.m. ET: BeyondTrust has published a blog post about their findings.
Update, Oct. 24, 10:20 a.m. ET: 1Password and Cloudflare have disclosed compromises of their Okta authentication platforms as a result of the Okta breach. Both companies say an investigation has determined no customer information or systems were affected. Meanwhile, an Okta spokesperson told TechCrunch that the company notified about 1 percent of its customer base (~170 customers), so we are likely to see more such disclosures in the days and weeks ahead.
One of the oldest malware tricks in the book — hacked websites claiming visitors need to update their Web browser before they can view any content — has roared back to life in the past few months. New research shows the attackers behind one such scheme have developed an ingenious way of keeping their malware from being taken down by security experts or law enforcement: By hosting the malicious files on a decentralized, anonymous cryptocurrency blockchain.
In August 2023, security researcher Randy McEoin blogged about a scam he dubbed ClearFake, which uses hacked WordPress sites to serve visitors with a page that claims you need to update your browser before you can view the content.
The fake browser alerts are specific to the browser you’re using, so if you’re surfing the Web with Chrome, for example, you’ll get a Chrome update prompt. Those who are fooled into clicking the update button will have a malicious file dropped on their system that tries to install an information stealing trojan.
Earlier this month, researchers at the Tel Aviv-based security firm Guardio said they tracked an updated version of the ClearFake scam that included an important evolution. Previously, the group had stored its malicious update files on Cloudflare, Guardio said.
But when Cloudflare blocked those accounts the attackers began storing their malicious files as cryptocurrency transactions in the Binance Smart Chain (BSC), a technology designed to run decentralized apps and “smart contracts,” or coded agreements that execute actions automatically when certain conditions are met.
Nati Tal, head of security at Guardio Labs, the research unit at Guardio, said the malicious scripts stitched into hacked WordPress sites will create a new smart contract on the BSC Blockchain, starting with a unique, attacker-controlled blockchain address and a set of instructions that defines the contract’s functions and structure. When that contract is queried by a compromised website, it will return an obfuscated and malicious payload.
“These contracts offer innovative ways to build applications and processes,” Tal wrote along with his Guardio colleague Oleg Zaytsev. “Due to the publicly accessible and unchangeable nature of the blockchain, code can be hosted ‘on-chain’ without the ability for a takedown.”
Tal said hosting malicious files on the Binance Smart Chain is ideal for attackers because retrieving the malicious contract is a cost-free operation that was originally designed for the purpose of debugging contract execution issues without any real-world impact.
“So you get a free, untracked, and robust way to get your data (the malicious payload) without leaving traces,” Tal said.
Attacker-controlled BSC addresses — from funding, contract creation, and ongoing code updates. Image: Guardio
In response to questions from KrebsOnSecurity, the BNB Smart Chain (BSC) said its team is aware of the malware abusing its blockchain, and is actively addressing the issue. The company said all addresses associated with the spread of the malware have been blacklisted, and that its technicians had developed a model to detect future smart contracts that use similar methods to host malicious scripts.
“This model is designed to proactively identify and mitigate potential threats before they can cause harm,” BNB Smart Chain wrote. “The team is committed to ongoing monitoring of addresses that are involved in spreading malware scripts on the BSC. To enhance their efforts, the tech team is working on linking identified addresses that spread malicious scripts to centralized KYC [Know Your Customer] information, when possible.”
Guardio says the crooks behind the BSC malware scheme are using the same malicious code as the attackers that McEoin wrote about in August, and are likely the same group. But a report published today by email security firm Proofpoint says the company is currently tracking at least four distinct threat actor groups that use fake browser updates to distribute malware.
Proofpoint notes that the core group behind the fake browser update scheme has been using this technique to spread malware for the past five years, primarily because the approach still works well.
“Fake browser update lures are effective because threat actors are using an end-user’s security training against them,” Proofpoint’s Dusty Miller wrote. “In security awareness training, users are told to only accept updates or click on links from known and trusted sites, or individuals, and to verify sites are legitimate. The fake browser updates abuse this training because they compromise trusted sites and use JavaScript requests to quietly make checks in the background and overwrite the existing website with a browser update lure. To an end user, it still appears to be the same website they were intending to visit and is now asking them to update their browser.”
More than a decade ago, this site published Krebs’s Three Rules for Online Safety, of which Rule #1 was, “If you didn’t go looking for it, don’t install it.” It’s nice to know that this technology-agnostic approach to online safety remains just as relevant today.
The fake USPS phishing page.
Recent weeks have seen a sizable uptick in the number of phishing scams targeting U.S. Postal Service (USPS) customers. Here’s a look at an extensive SMS phishing operation that tries to steal personal and financial data by spoofing the USPS, as well as postal services in at least a dozen other countries.
KrebsOnSecurity recently heard from a reader who received an SMS purporting to have been sent by the USPS, saying there was a problem with a package destined for the reader’s address. Clicking the link in the text message brings one to the domain usps.informedtrck[.]com.
The landing page generated by the phishing link includes the USPS logo, and says “Your package is on hold for an invalid recipient address. Fill in the correct address info by the link.” Below that message is a “Click update” button that takes the visitor to a page that asks for more information.
The remaining buttons on the phishing page all link to the real USPS.com website. After collecting your address information, the fake USPS site goes on to request additional personal and financial data.
This phishing domain was recently registered and its WHOIS ownership records are basically nonexistent. However, we can find some compelling clues about the extent of this operation by loading the phishing page in Developer Tools, a set of debugging features built into Firefox, Chrome and Safari that allow one to closely inspect a webpage’s code and operations.
Check out the bottom portion of the screenshot below, and you’ll notice that this phishing site fails to load some external resources, including an image from a link called fly.linkcdn[.]to.
Click the image to enlarge.
A search on this domain at the always-useful URLscan.io shows that fly.linkcdn[.]to is tied to a slew of USPS-themed phishing domains. Here are just a few of those domains (links defanged to prevent accidental clicking):
usps.receivepost[.]com
usps.informedtrck[.]com
usps.trckspost[.]com
postreceive[.]com
usps.trckpackages[.]com
usps.infortrck[.]com
usps.quicktpos[.]com
usps.postreceive].]com
usps.revepost[.]com
trackingusps.infortrck[.]com
usps.receivepost[.]com
usps.trckmybusi[.]com
postreceive[.]com
tackingpos[.]com
usps.trckstamp[.]com
usa-usps[.]shop
usps.infortrck[.]com
unlistedstampreceive[.]com
usps.stampreceive[.]com
usps.stamppos[.]com
usps.stampspos[.]com
usps.trckmypost[.]com
usps.trckintern[.]com
usps.tackingpos[.]com
usps.posinformed[.]com
As we can see in the screenshot below, the developer tools console for informedtrck[.]com complains that the site is unable to load a Google Analytics code — UA-80133954-3 — which apparently was rejected for pointing to an invalid domain.
Notice the highlighted Google Analytics code exposed by a faulty Javascript element on the phishing website. Click to enlarge. That code actually belongs to the USPS.
The valid domain for that Google Analytics code is the official usps.com website. According to dnslytics.com, that same analytics code has shown up on at least six other nearly identical USPS phishing pages dating back nearly as many years, including onlineuspsexpress[.]com, which DomainTools.com says was registered way back in September 2018 to an individual in Nigeria.
A different domain with that same Google Analytics code that was registered in 2021 is peraltansepeda[.]com, which archive.org shows was running a similar set of phishing pages targeting USPS users. DomainTools.com indicates this website name was registered by phishers based in Indonesia.
DomainTools says the above-mentioned USPS phishing domain stamppos[.]com was registered in 2022 via Singapore-based Alibaba.com, but the registrant city and state listed for that domain says “Georgia, AL,” which is not a real location.
Alas, running a search for domains registered through Alibaba to anyone claiming to reside in Georgia, AL reveals nearly 300 recent postal phishing domains ending in “.top.” These domains are either administrative domains obscured by a password-protected login page, or are .top domains phishing customers of the USPS as well as postal services serving other countries.
Those other nations include the Australia Post, An Post (Ireland), Correos.es (Spain), the Costa Rican post, the Chilean Post, the Mexican Postal Service, Poste Italiane (Italy), PostNL (Netherlands), PostNord (Denmark, Norway and Sweden), and Posti (Finland). A complete list of these domains is available here (PDF).
A phishing page targeting An Post, the state-owned provider of postal services in Ireland.
The Georgia, AL domains at Alibaba also encompass several that spoof sites claiming to collect outstanding road toll fees and fines on behalf of the governments of Australia, New Zealand and Singapore.
An anonymous reader wrote in to say they submitted fake information to the above-mentioned phishing site usps.receivepost[.]com via the malware sandbox any.run. A video recording of that analysis shows that the site sends any submitted data via an automated bot on the Telegram instant messaging service.
The traffic analysis just below the any.run video shows that any data collected by the phishing site is being sent to the Telegram user @chenlun, who offers to sell customized source code for phishing pages. From a review of @chenlun’s other Telegram channels, it appears this account is being massively spammed at the moment — possibly thanks to public attention brought by this story.
Meanwhile, researchers at DomainTools recently published a report on an apparently unrelated but equally sprawling SMS-based phishing campaign targeting USPS customers that appears to be the work of cybercriminals based in Iran.
Phishers tend to cast a wide net and often spoof entities that are broadly used by the local population, and few brands are going to have more household reach than domestic mail services. In June, the United Parcel Service (UPS) disclosed that fraudsters were abusing an online shipment tracking tool in Canada to send highly targeted SMS phishing messages that spoofed the UPS and other brands.
With the holiday shopping season nearly upon us, now is a great time to remind family and friends about the best advice to sidestep phishing scams: Avoid clicking on links or attachments that arrive unbidden in emails, text messages and other mediums. Most phishing scams invoke a temporal element that warns of negative consequences should you fail to respond or act quickly.
If you’re unsure whether the message is legitimate, take a deep breath and visit the site or service in question manually — ideally, using a browser bookmark so as to avoid potential typosquatting sites.
Update: Added information about the Telegram bot and any.run analysis.
The victim shaming site operated by the Snatch ransomware group is leaking data about its true online location and internal operations, as well as the Internet addresses of its visitors, KrebsOnSecurity has found. The leaked data suggest that Snatch is one of several ransomware groups using paid ads on Google.com to trick people into installing malware disguised as popular free software, such as Microsoft Teams, Adobe Reader, Mozilla Thunderbird, and Discord.
First spotted in 2018, the Snatch ransomware group has published data stolen from hundreds of organizations that refused to pay a ransom demand. Snatch publishes its stolen data at a website on the open Internet, and that content is mirrored on the Snatch team’s darknet site, which is only reachable using the global anonymity network Tor.
The victim shaming website for the Snatch ransomware gang.
KrebsOnSecurity has learned that Snatch’s darknet site exposes its “server status” page, which includes information about the true Internet addresses of users accessing the website.
Refreshing this page every few seconds shows that the Snatch darknet site generates a decent amount of traffic, often attracting thousands of visitors each day. But by far the most frequent repeat visitors are coming from Internet addresses in Russia that either currently host Snatch’s clear web domain names or recently did.
The Snatch ransomware gang’s victim shaming site on the darknet is leaking data about its visitors. This “server status” page says that Snatch’s website is on Central European Summer Time (CEST) and is powered by OpenSSL/1.1.1f, which is no longer supported by security updates.
Probably the most active Internet address accessing Snatch’s darknet site is 193.108.114[.]41, which is a server in Yekaterinburg, Russia that hosts several Snatch domains, including snatchteam[.]top, sntech2ch[.]top, dwhyj2[.]top and sn76930193ch[.]top. It could well be that this Internet address is showing up frequently because Snatch’s clear-web site features a toggle button at the top that lets visitors switch over to accessing the site via Tor.
Another Internet address that showed up frequently in the Snatch server status page was 194.168.175[.]226, currently assigned to Matrix Telekom in Russia. According to DomainTools.com, this address also hosts or else recently hosted the usual coterie of Snatch domains, as well as quite a few domains phishing known brands such as Amazon and Cashapp.
The Moscow Internet address 80.66.64[.]15 accessed the Snatch darknet site all day long, and that address also housed the appropriate Snatch clear-web domains. More interestingly, that address is home to multiple recent domains that appear confusingly similar to known software companies, including libreoff1ce[.]com and www-discord[.]com.
This is interesting because the phishing domains associated with the Snatch ransomware gang were all registered to the same Russian name — Mihail Kolesnikov, a name that is somewhat synonymous with recent phishing domains tied to malicious Google ads.
Kolesnikov could be a nod to a Russian general made famous during Boris Yeltsin’s reign. Either way, it’s clearly a pseudonym, but there are some other commonalities among these domains that may provide insight into how Snatch and other ransomware groups are sourcing their victims.
DomainTools says there are more than 1,300 current and former domain names registered to Mihail Kolesnikov between 2013 and July 2023. About half of the domains appear to be older websites advertising female escort services in major cities around the United States (e.g. the now-defunct pittsburghcitygirls[.]com).
The other half of the Kolesnikov websites are far more recent phishing domains mostly ending in “.top” and “.app” that appear designed to mimic the domains of major software companies, including www-citrix[.]top, www-microsofteams[.]top, www-fortinet[.]top, ibreoffice[.]top, www-docker[.]top, www-basecamp[.]top, ccleaner-cdn[.]top, adobeusa[.]top, and www.real-vnc[.]top.
In August 2023, researchers with Trustwave Spiderlabs said they encountered domains registered to Mihail Kolesnikov being used to disseminate the Rilide information stealer trojan.
But it appears multiple crime groups may be using these domains to phish people and disseminate all kinds of information-stealing malware. In February 2023, Spamhaus warned of a huge surge in malicious ads that were hijacking search results in Google.com, and being used to distribute at least five different families of information stealing trojans, including AuroraStealer, IcedID/Bokbot, Meta Stealer, RedLine Stealer and Vidar.
For example, Spamhaus said victims of these malicious ads would search for Microsoft Teams in Google.com, and the search engine would often return a paid ad spoofing Microsoft or Microsoft Teams as the first result — above all other results. The malicious ad would include a logo for Microsoft and at first glance appear to be a safe and trusted place to download the Microsoft Teams client.
However, anyone who clicked on the result was whisked away instead to mlcrosofteams-us[.]top — yet another malicious domain registered to Mr. Kolesnikov. And while visitors to this website may believe they are only downloading the Microsoft Teams client, the installer file includes a copy of the IcedID malware, which is really good at stealing passwords and authentication tokens from the victim’s web browser.
Image: Spamhaus
The founder of the Swiss anti-abuse website abuse.ch told Spamhaus it is likely that some cybercriminals have started to sell “malvertising as a service” on the dark web, and that there is a great deal of demand for this service.
In other words, someone appears to have built a very profitable business churning out and promoting new software-themed phishing domains and selling that as a service to other cybercriminals. Or perhaps they are simply selling any stolen data (and any corporate access) to active and hungry ransomware group affiliates.
The tip about the exposed “server status” page on the Snatch darkweb site came from @htmalgae, the same security researcher who alerted KrebsOnSecurity earlier this month that the darknet victim shaming site run by the 8Base ransomware gang was inadvertently left in development mode.
That oversight revealed not only the true Internet address of the hidden 8Base site (in Russia, naturally), but also the identity of a programmer in Moldova who apparently helped to develop the 8Base code.
@htmalgae said the idea of a ransomware group’s victim shaming site leaking data that they did not intend to expose is deliciously ironic.
“This is a criminal group that shames others for not protecting user data,” @htmalgae said. “And here they are leaking their user data.”
All of the malware mentioned in this story is designed to run on Microsoft Windows devices. But Malwarebytes recently covered the emergence of a Mac-based information stealer trojan called AtomicStealer that was being advertised through malicious Google ads and domains that were confusingly similar to software brands.
Please be extra careful when you are searching online for popular software titles. Cracked, pirated copies of major software titles are a frequent source of infostealer infections, as are these rogue ads masquerading as search results. Make sure to double-check you are actually at the domain you believe you’re visiting *before* you download and install anything.
Stay tuned for Part II of this post, which includes a closer look at the Snatch ransomware group and their founder.
Further reading:
@HTMalgae’s list of the top Internet addresses seen accessing Snatch’s darknet site
Ars Technica: Until Further Notice Think Twice Before Using Google to Download Software
Bleeping Computer: Hackers Abuse Google Ads to Spread Malware in Legit Software
This article originally appeared Aug. 21, 2020 on the APNIC blog.
Chromium is an open-source software project that forms the foundation for Google’s Chrome web browser, as well as a number of other browser products, including Microsoft Edge, Opera, Amazon Silk, and Brave. Since Chrome’s introduction in 2008, Chromium-based browsers have steadily risen in popularity and today comprise approximately 70% of the market share.1
Chromium has, since its early days, included a feature known as the omnibox. This is where users may enter either a web site name, URL, or search terms. But the omnibox has an interface challenge. The user might enter a word like “marketing” that could refer to both an (intranet) web site and a search term. Which should the browser choose to display? Chromium treats it as a search term, but also displays an infobar that says something like “did you mean http://marketing/?” if a background DNS lookup for the name results in an IP address.
At this point, a new issue arises. Some networks (e.g., ISPs) utilize products or services designed to intercept and capture traffic from mistyped domain names. This is sometimes known as “NXDomain hijacking.” Users on such networks might be shown the “did you mean” infobar on every single-term search. To work around this, Chromium needs to know if it can trust the network to provide non-intercepted DNS responses.
Inside the Chromium source code there is a file named intranet_redirect_detector.c. The functions in this file attempt to load three URLs whose hostnames consist of a randomly generated single-label domain name, as shown in Figure 1 below.
This code results in three URL fetches, such as http://rociwefoie/, http://uawfkfrefre/, and http://awoimveroi/, and these in turn result in three DNS lookups for the random host names. As can be deduced from the source code, these random names are 7-15 characters in length (line 151) and consist of only the letters a-z (line 153). In versions of the code prior to February 2014, the random names were always 10 characters in length.
The intranet redirect detector functions are executed each time the browser starts up, each time the system/device’s IP address changes, and each time the system/device’s DNS configuration changes. If any two of these fetches resolve to the same address, that address is stored as the browser’s redirect origin.
Nearly any cursory glance at root name server traffic will exhibit queries for names that look like those used in Chromium’s probe queries. For example, here are 20 sequential queries received at an a.root-servers.net instance:
In this brief snippet of data, we can see six queries (yellow highlight) for random, single-label names, and another four (green highlight) with random first labels followed by an apparent domain search suffix. These match the pattern from the Chromium source code, being 7-15 characters in length and consisting of only the letters a-z.
To characterize the amount of Chromium probe traffic in larger amounts of data (i.e., covering a 24-hour period), we tabulate queries based on the following attributes:
Figure 2 shows a classification of data from a.root-servers.net on May 13, 2020. Here we can see that 51% of all queried names were observed fewer than four times in the 24-hour period. Of those, nearly all were for non-existent TLDs, although a very small amount come from the existing TLDs (labeled “YXD” on the left). This small sliver represents either false positives or Chromium probe queries that have been subject to domain suffix search appending by stub resolvers or end user applications.
Of the 51% observed fewer than four times, all but 2.86% of those have a first label between 7 and 15 characters in length (inclusive). Furthermore, most of those match the pattern consisting of only a-z characters (case insensitive), leaving us with 45.80% of total traffic on this day that appears to be from Chromium probes.
From there we break down the queries by number of labels and length of the first label. Note that label lengths, on the far right of the graph, have a very even distribution, except for 7 and 10 characters. Labels with 10 characters are more popular because older versions of Chromium generated only 10-character names. We believe that 7 is less popular due to the increased probability of collisions in only 7 characters, which can increase the query count to above our threshold of three.
Next, we turn our attention to an analysis of how the total root traffic percentage of Chromium-like queries has changed over time. We use two data sets in this analysis: data from DNS-OARC’s “Day In The Life” (DITL) collections, and Verisign’s data for a.root-servers.net and j.root-servers.net.
Figure 3 shows the results of the long-term analysis. We were able to analyze the annual DITL data from 2006-2014, and from 2017-2018, labeled “DITL Full” in the figure. The 2015-2016 data was unavailable on the DNS-OARC systems. The 2019 dataset could not be analyzed in full due to its size, so we settled for a sampled analysis instead, labeled “DITL Sampled” in Figure 3. The 2020 data was not ready for analysis by the time our research was done.
In every DITL dataset, we analyzed each root server identity (“letter”) separately. This produces a range of values for each year. The solid line shows the average of all the identities, while the shaded area shows the range of values.
To fill in some of the DITL gaps we used Verisign’s own data for a.root-servers.net and j.root-servers.net. Here we selected a 24-hour period for each month. Again, the solid line shows the average and the shaded area represents the range.
The figure also includes a line labeled “Chrome market share” (note: Chrome, not Chromium-based browsers) and a marker indicating when the feature was first added to the source code. Note, there are some false positive Chromium-like queries observed in the DITL data prior to introduction of the feature, comprising about 1% of the total traffic, but in the 10+ years since the feature was added, we now find that half of the DNS root server traffic is very likely due to Chromium’s probes. That equates to about 60 billion queries to the root server system on a typical day.
The root server system is, out of necessity, designed to handle very large amounts of traffic. As we have shown here, under normal operating conditions, half of the traffic originates with a single library function, on a single browser platform, whose sole purpose is to detect DNS interception. Such interception is certainly the exception rather than the norm. In almost any other scenario, this traffic would be indistinguishable from a distributed denial of service (DDoS) attack.
Could Chromium achieve its goal while only sending one or two queries instead of three? Are other approaches feasible? For example, Firefox’s captive portal test uses delegated namespace probe queries, directing them away from the root servers towards the browser’s own infrastructure. While technical solutions such as Aggressive NSEC Caching (RFC 8198), Qname Minimization (RFC 7816), and NXDomain Cut (RFC 8020) could also significantly reduce probe queries to the root server system, these solutions require action by recursive resolver operators, who have limited incentive to deploy and support these technologies.
This piece was co-authored by Matt Thomas, Distinguished Engineer in Verisign’s CSO Applied Research division.
1https://www.w3counter.com/trends
The post Chromium’s Impact on Root DNS Traffic appeared first on Verisign Blog.
FreshRSS