CHROMIUM’S TESTING OCCUPIES MORE THAN 50% RESOURCES ON ROOT NAMESERVERS

Google, the giant of giants, one of the child of Alphabet Inc., everybody knows that it empowers the internet today. Google has almost tried to replace the manpower with automation and is a great contributor towards technologies like Artificial Intelligence and Machine Learning. Its one of the most world widely used product, Chrome browser, account for more than 70% of the web browsers market share. The simple reason behind this big share is that either the person is a tech enthusiast or just a layman user, Google takes care for everyone. Every tech aspirant who gets into the IT industry, atleast tries once to make it to the Google.

Google, as the big name comes, the great responsibility comes with it. The trust behind a name comes only when that company put all their effort to their clients feedback. If we see around us, we find that most of the successful startup have grown just because of the better client service and satisfaction. Google does it to. For every small need to big needs, we all have one word on our mouth, “Let’s Google it”. But have we wonder how Google take care of our needs?

Some researchers from , registrar responsible for the distribution of IP addresses in the Asia-Pacific region have found that Chromium makes 60 billion requests to root servers per day to diagnose so that it can deliver better results to its users. For those who don’t know, Chromium is an open sou rce project by Google which form the basis of some top rated browsers like Google Chrome including Microsoft Edge, Amazon Silk and Brave. To know why this pe rcentage is so high, we have to go in depth a li ttl e to find out how it works.

Whenever we enter something in the omnibox (where Google ask for Search or type any URL), we might have noticed one thing that google sometimes automatically detects your destination URL or target based on your previous visits. For example, if you had previously visited www.facebook.com, as soon as you enter the most significant characters like “face”, the google will show you the target destination.

But sometimes what happens if the user might enters some string of meaningless characters like “ijfjorfpjhp”? When anyone search this kinds of strings in the omnibox, the browser queries the DNS assuming that user must be trying to query a site which is not on World Wide Web (WWW) but exists in the user’s internal network(intranet). But here the Internet Service Provider plays a game.

Usually if you check your DNS setting in your system, the DNS resolver is configured to same as your gateway which means that every URL request made by you will first move to your gateway (means your ISP) then it will resolve the domain name into the destination IP address, unless it is not cache by your browser. But when you type meaningless strings as mentioned above, these queries are not send to the Google’s search engine rather ISP’s redirect your request to their own pages which they want to display you. Thus, in this way ISPs your DNS queries.

To overcome this problem, the developers of Chromium have added additional checks to the browse sou rce code which on your every application launch either you change your DNS settings or change your IP address like (use Proxy or VPN). The browser sends three DNS queries with random first-level domain names that most likely do not exist. The names include from 7 to 15 Latin letters (without periods) which previously limited to only 10 characters and are used to detect the redirection of non-existent domain names by the provider to its host. If, when processing three HTTP requests with random names for two, a redirect to the same page is received, then Chromium considers that the user has been redirected to a third-party page. For example, the APNIC shows 20 records 20 sequential queries received at an

$ /usr/sbin/tcpdump -n -c 20 ... 20:01:34.063474 IP x.x.x.x.7288 > 198.41.0.4.domain: 34260% [1au] A? ip-10-218-80-155. (45) 20:01:34.063474 IP x.x.x.x.31500 > 198.41.0.4.domain: 64756 [1au] AAAA? fwhjxbnoicuu. (41) 20:01:34.063474 IP x.x.x.x.46073 > 198.41.0.4.domain: 13606 A? cluster1-1.cluster1.etcd. (42) 20:01:34.064413 IP6 x:x:x::x.9905 > 2001:503:ba3e::2:30.domain: 52824 [1au] A? xxnwikspwxdw. (53) 20:01:34.064413 IP x.x.x.x.30251 > 198.41.0.4.domain: 9286% [1au] AAAA? cxhplqrpuuck.home. (46) 20:01:34.064413 IP x.x.x.x.56760 > 198.41.0.4.domain: 60980% [1au] A? ofydbfct.home. (42) 20:01:34.065295 IP x.x.x.x.15410 > 198.41.0.4.domain: 21829% [1au] A? wwtsjikkls. (39) 20:01:34.065295 IP6 x:x:x::x.58815 > 2001:503:ba3e::2:30.domain: Flags [.], ack 3919467200, win 30118, length 0 20:01:34.065295 IP6 x:x:x::x.58815 > 2001:503:ba3e::2:30.domain: Flags [F.], seq 0, ack 1, win 30118, length 0 20:01:34.065295 IP x.x.x.x.17442 > 198.41.0.4.domain: 32435% [1au] A? agawwhcwueppouu. (44) 20:01:34.065295 IP x.x.x.x.35247 > 198.41.0.4.domain: 1328% [1au] A? dev-app.stormwind.local. (52) 20:01:34.065295 IP x.x.x.x.18462 > 198.41.0.4.domain: 23433% [1au] AAAA? liffezmsdw.home. (44) 20:01:34.065295 IP x.x.x.x.40905 > 198.41.0.4.domain: 40371% [1au] A? sqtpvvmi.home. (42) 20:01:34.066283 IP x.x.x.x.18125 > 198.41.0.4.domain: 45688% [1au] A? kktaruyy. (37) 20:01:34.066283 IP x.x.x.x.7986 > 198.41.0.4.domain: 60608 [1au] A? bpbutdlihan. (40) 20:01:34.066283 IP x.x.x.x.53489 > 198.41.0.4.domain: 27734% [1au] A? ip-100-65-32-140. (45) 20:01:34.066283 IP x.x.x.x.54028 > 198.41.0.4.domain: 41670 A? qvo7-itirqg3g.www.rabbitair.co.uk.notary-production. (69) 20:01:34.066283 IP x.x.x.x.43866 > 198.41.0.4.domain: 21093% [1au] A? ip-10-0-71-17. (42) 20:01:34.066283 IP x.x.x.x.41141 > 198.41.0.4.domain: 49747% [1au] A? edu. (32) 20:01:34.066283 IP x.x.x.x.36283 > 198.41.0.4.domain: 65449% [1au] SRV? _ldap._tcp.dc._msdcs.mwaa.local. (60)

According to their study, they first filtered out Chromium requests on non-existent domains which account for out of which 51% of queried names were observed fewer than four times in the 24-hour period. Out of that 51% queried domain names, were the domains containing containing from 7 to 15 letters. Thus, the actual existent domains which were queried to the root server s are only.

The study also showed the drastic change in load traffic on the root server s after Chromium made its presence in the market.

Researchers in their end note acclaimed that the number of queries received in other condition are indistinguishable like if someone has launched DDOS attacks on root servers, the chromium’s traffic will look similar to that. Google should improve their way to diagnose DNS hijacking attacks and try to minimize the use of root server’s resou rces as much as they can by building better and efficient st rat egies.

Suggested deals and offers:

  • Protect your system with Heimdal™ Thor Premium: All-in-One Security Suite at just $59.99 for 5 years. To buy it, click here. Original Price: $499
  • Protect your wordpress site with WordPress Security Course at just $33 for 3 years. To buy it, click here. Original Price: $37
  • Protect your online identity and data with Vault- The Online Security Cloud at just $99 per year. With this pack, you are fully secured as it contains Panda antivirus, Nord VPN, Dashlane to protect your identity online, Degoo 2TB Plan for backing up your data and Adguard. To buy it, click here. Original Price: $455

Disclaimer: The above suggested deals are from third party vendors and prices mentioned for the above deals may or may not change at the time you buy. We are not responsible for the change in price after 24 hours.

Originally published at https://ethicaldebuggers.com on August 25, 2020.

Debuggers covering infosec news,cyber security tutorials, data breaches, malware, threat analysis, ethical hacking, bugs, vulnerabilities and much more.