Login
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.
The victim shaming website operated by the cybercriminals behind 8Base — currently one of the more active ransomware groups — was until earlier today leaking quite a bit of information that the crime group probably did not intend to be made public. The leaked data suggests that at least some of website’s code was written by a 36-year-old programmer residing in the capital city of Moldova.
The 8Base ransomware group’s victim shaming website on the darknet.
8Base maintains a darknet website that is only reachable via Tor, a freely available global anonymity network. The site lists hundreds of victim organizations and companies — all allegedly hacking victims that refused to pay a ransom to keep their stolen data from being published.
The 8Base darknet site also has a built-in chat feature, presumably so that 8Base victims can communicate and negotiate with their extortionists. This chat feature, which runs on the Laravel web application framework, works fine as long as you are *sending* information to the site (i.e., by making a “POST” request).
However, if one were to try to fetch data from the same chat service (i.e., by making a “GET” request), the website until quite recently generated an extremely verbose error message:
The verbose error message when one tries to pull data from 8Base’s darknet site. Notice the link at the bottom of this image, which is generated when one hovers over the “View commit” message under the “Git” heading.
That error page revealed the true Internet address of the Tor hidden service that houses the 8Base website: 95.216.51[.]74, which according to DomainTools.com is a server in Finland that is tied to the Germany-based hosting giant Hetzner.
But that’s not the interesting part: Scrolling down the lengthy error message, we can see a link to a private Gitlab server called Jcube-group: gitlab[.]com/jcube-group/clients/apex/8base-v2. Digging further into this Gitlab account, we can find some curious data points available in the JCube Group’s public code repository.
For example, this “status.php” page, which was committed to JCube Group’s Gitlab repository roughly one month ago, includes code that makes several mentions of the term “KYC” (e.g. KYC_UNVERIFIED, KYC_VERIFIED, and KYC_PENDING).
This is curious because a FAQ on the 8Base darknet site includes a section on “special offers for journalists and reporters,” which says the crime group is open to interviews but that journalists will need to prove their identity before any interview can take place. The 8base FAQ refers to this vetting process as “KYC,” which typically stands for “Know Your Customer.”
“We highly respect the work of journalists and consider information to be our priority,” the 8Base FAQ reads. “We have a special program for journalists which includes sharing information a few hours or even days before it is officially published on our news website and Telegram channel: you would need to go through a KYC procedure to apply. Journalists and reporters can contact us via our PR Telegram channel with any questions.”
The 8Base FAQ (left) and the KYC code in Kolev’s Gitlab account (right)
The 8Base darknet site also has a publicly accessible “admin” login page, which features an image of a commercial passenger plane parked at what appears to be an airport. Next to the airplane photo is a message that reads, “Welcome to 8Base. Admin Login to 8Base dashboard.”
The login page on the 8Base ransomware group’s darknet website.
Right-clicking on the 8Base admin page and selecting “View Source” produces the page’s HTML code. That code is virtually identical to a “login.blade.php” page that was authored and committed to JCube Group’s Gitlab repository roughly three weeks ago.
It appears the person responsible for the JCube Group’s code is a 36-year-old developer from Chisinau, Moldova named Andrei Kolev. Mr. Kolev’s LinkedIn page says he’s a full-stack developer at JCube Group, and that he’s currently looking for work. The homepage for Jcubegroup[.]com lists an address and phone number that Moldovan business records confirm is tied to Mr. Kolev.
The posts on the Twitter account for Mr. Kolev (@andrewkolev) are all written in Russian, and reference several now-defunct online businesses, including pluginspro[.]ru.
Reached for comment via LinkedIn, Mr. Kolev said he had no idea why the 8Base darknet site was pulling code from the “clients” directory of his private JCube Group Gitlab repository, or how the 8Base name was even included.
“I [don’t have] a clue, I don’t have that project in my repo,” Kolev explained. “They [aren’t] my clients. Actually we currently have just our own projects.”
Mr. Kolev shared a screenshot of his current projects, but very quickly after that deleted it. However, KrebsOnSecurity captured a copy of the image before it was removed:
A screenshot of Mr. Kolev’s current projects that he quickly deleted.
Within minutes of explaining why I was reaching out to Mr. Kolev and walking him through the process of finding this connection, the 8Base website was changed, and the error message that linked to the JCube Group private Gitlab repository no longer appeared. Instead, trying the same “GET” method described above caused the 8Base website to return a “405 Method Not Allowed” error page:
Mr. Kolev claimed he didn’t know anything about the now-removed error page on 8Base’s site that referenced his private Gitlab repo, and said he deleted the screenshot from our LinkedIn chat because it contained private information.
Ransomware groups are known to remotely hire developers for specific projects without disclosing exactly who they are or how the new hire’s code is intended to be used, and it is possible that one of Mr. Kolev’s clients is merely a front for 8Base. But despite 8Base’s statement that they are happy to correspond with journalists, KrebsOnSecurity is still waiting for a reply from the group via their Telegram channel.
The tip about the leaky 8Base website was provided by a reader who asked to remain anonymous. That reader, a legitimate security professional and researcher who goes by the handle @htmalgae on Twitter, said it is likely that whoever developed the 8Base website inadvertently left it in “development mode,” which is what caused the site to be so verbose with its error messages.
“If 8Base was running the app in production mode instead of development mode, this Tor de-anonymization would have never been possible,” @htmalgae said.
A recent blog post from VMware/Carbon Black called the 8Base ransomware group “a heavy hitter” that has remained relatively unknown despite the massive spike in activity in Summer of 2023.
“8Base is a Ransomware group that has been active since March 2022 with a significant spike in activity in June of 2023,” Carbon Black researchers wrote. “Describing themselves as ‘simple pen testers,’ their leak site provided victim details through Frequently Asked Questions and Rules sections as well as multiple ways to contact them. ”
According to VMware, what’s particularly interesting about 8Base’s communication style is the use of verbiage that is strikingly familiar to another known cybercriminal group: RansomHouse.
“The group utilizes encryption paired with ‘name-and-shame’ techniques to compel their victims to pay their ransoms,” VMware researchers wrote. “8Base has an opportunistic pattern of compromise with recent victims spanning across varied industries. Despite the high amount of compromises, the information regarding identities, methodology, and underlying motivation behind these incidents still remains a mystery.”
Update, Sept. 21, 10:43 a.m. ET: The author of Databreaches.net was lurking in the 8Base Telegram channel when I popped in to ask the crime group a question, and reports that 8Base did eventually reply: ““hi at the moment we r not doing interviews. we have nothing to say. we r a little busy.”
About 79 percent of public-facing Juniper SRX firewalls remain vulnerable to a single security flaw can allow an unauthenticated attacker to remotely execute code on the devices, according to threat intelligence platform provider VulnCheck.…
Last October, Pennsylvania State University (Penn State) was sued by a former chief information officer for allegedly falsifying government security compliance reports.…
A Microsoft employee accidentally exposed 38 terabytes of private data while publishing a bucket of open-source AI training data on GitHub, according to Wiz security researchers who spotted the leaky account and reported it to the Windows giant.…
FreshRSS 