Chrome:带有随机 DNS 名称的 DNS 请求:恶意软件?

Chrome:带有随机 DNS 名称的 DNS 请求:恶意软件?

多年来(自 2005 年以来),我在我维护的多个 DNS/BIND 服务器上看到了奇怪的随机 DNS 请求的日志。

May  7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#24123 (verxkgiicjmcnxg): view internal: query: verxkgiicjmcnxg IN A + (1.1.1.1)
May  7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#29159 (epqoaqsayo): view internal: query: epqoaqsayo IN A + (1.1.1.1)
May  7 12:13:50 1.1.1.1 named[63742]: client 1.1.1.2#27411 (qlllglwcjglu): view internal: query: qlllglwcjglu IN A + (1.1.1.1)

我通常将其归因于某些 Windows 恶意软件。然而,最近我开始注意到它也来自 Linux 和 Mac 客户端。我再次认为这可能是由于某些恶意浏览器插件造成的。

然而,在调试 Google Chrome 浏览器问题时,在我新安装的 Macbook Pro/Chrome 中,使用 URL chrome://net-internals/#dns,我在 Chrome DNS 统计页面中发现了类似的请求。

我的 Chrome 浏览器安装了相当无害的插件并且没有明显的恶意软件迹象

我真诚地怀疑这是否应该是恶意活动。怎么了?

(如图所示,pnxcygqemww,雷兹普布赫古特克德, 和斯普鲁奥Chrome 发出的 DNS 名称请求)。

域名系统

当 Chrome 浏览器打开时嗅探 DNS 活动,使用:

sudo tcpdump -n port 53

我能够看到以下 DNS 请求,以及 10:20:34 的随机请求:

打开Chrome:

tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes
10:20:27.119736 IP 1.1.1.2.12568 > 1.1.1.1.53: 10990+ A? apis.google.com. (33)
10:20:27.119962 IP 1.1.1.2.34930 > 1.1.1.1.53: 13828+ A? disconnect.me. (31)
10:20:27.120078 IP 1.1.1.2.17860 > 1.1.1.1.53: 37420+ A? mxr.mozilla.org. (33)
10:20:27.120314 IP 1.1.1.1.53 > 1.1.1.2.12568: 10990 2/4/4 CNAME plus.l.google.com., A 216.58.214.174 (206)
10:20:27.120479 IP 1.1.1.1.53 > 1.1.1.2.34930: 13828 3/4/8 A 54.197.255.152, A 54.225.94.202, A 204.236.239.134 (339)
10:20:27.120666 IP 1.1.1.1.53 > 1.1.1.2.17860: 37420 1/4/5 A 63.245.215.42 (234)
10:20:27.123394 IP 1.1.1.2.51642 > 1.1.1.1.53: 58375+ A? ssl.gstatic.com. (33)
10:20:27.123658 IP 1.1.1.2.17933 > 1.1.1.1.53: 48570+ A? www.google.pt. (31)
10:20:27.123726 IP 1.1.1.1.53 > 1.1.1.2.51642: 58375 1/4/4 A 216.58.214.163 (192)
10:20:27.123897 IP 1.1.1.2.57779 > 1.1.1.1.53: 7559+ A? www.gstatic.com. (33)
10:20:27.123946 IP 1.1.1.1.53 > 1.1.1.2.17933: 48570 1/4/4 A 216.58.207.163 (193)
10:20:27.124192 IP 1.1.1.1.53 > 1.1.1.2.57779: 7559 16/4/4 A 194.210.238.166, A 194.210.238.170, A 194.210.238.174, A 194.210.238.176, A 194.210.238.177, A 194.210.238.181, A 194.210.238.185, A 194.210.238.187, A 194.210.238.144, A 194.210.238.148, A 194.210.238.152, A 194.210.238.154, A 194.210.238.155, A 194.210.238.159, A 194.210.238.163, A 194.210.238.165 (432)
10:20:27.432926 IP 1.1.1.2.29865 > 1.1.1.1.53: 62300+ A? clients4.google.com. (37)
10:20:27.433219 IP 1.1.1.2.28193 > 1.1.1.1.53: 23734+ A? translate.googleapis.com. (42)
10:20:27.433703 IP 1.1.1.1.53 > 1.1.1.2.29865: 62300 2/4/4 CNAME clients.l.google.com., A 216.58.211.238 (213)
10:20:27.464772 IP 1.1.1.1.53 > 1.1.1.2.28193: 23734 1/4/4 A 216.58.198.202 (201)
10:20:28.430622 IP 1.1.1.2.46792 > 1.1.1.1.53: 1963+ A? accounts.google.com. (37)
10:20:28.431046 IP 1.1.1.1.53 > 1.1.1.2.46792: 1963 1/4/4 A 216.58.201.141 (189)
10:20:32.348765 IP 1.1.1.2.16654 > 1.1.1.1.53: 39847+ A? www.google.com. (32)
10:20:32.349362 IP 1.1.1.1.53 > 1.1.1.2.16654: 39847 1/4/4 A 216.58.213.164 (184)

几秒钟后,确实出现了上述随机 DNS 请求:

10:20:34.159229 IP 1.1.1.2.5042 > 1.1.1.1.53: 47676+ A? kblxfid.xxx.xxx.xxx. (44)
10:20:34.159829 IP 1.1.1.2.63360 > 1.1.1.1.53: 55094+ A? weefjmw.xxx.xxx.xxx. (44)
10:20:34.159893 IP 1.1.1.1.53 > 1.1.1.2.5042: 47676 NXDomain* 0/1/0 (104)
10:20:34.160230 IP 1.1.1.1.53 > 1.1.1.2.63360: 55094 NXDomain* 0/1/0 (104)
10:20:34.160872 IP 1.1.1.2.29339 > 1.1.1.1.53: 22434+ A? luebcanqpumlaj.xxx.xxx.xxx. (51)
10:20:34.161290 IP 1.1.1.1.53 > 1.1.1.2.29339: 22434 NXDomain* 0/1/0 (111)
10:20:34.162489 IP 1.1.1.2.64592 > 1.1.1.1.53: 49055+ A? kblxfid.xxx.xxx.xxx. (44)
10:20:34.162859 IP 1.1.1.1.53 > 1.1.1.2.64592: 49055 NXDomain* 0/1/0 (104)
10:20:34.164105 IP 1.1.1.2.50225 > 1.1.1.1.53: 1276+ A? weefjmw.xxx.xxx.xxx. (44)
10:20:34.164386 IP 1.1.1.2.52389 > 1.1.1.1.53: 59022+ A? luebcanqpumlaj.xxx.xxx.xxx. (51)
10:20:34.164472 IP 1.1.1.1.53 > 1.1.1.2.50225: 1276 NXDomain* 0/1/0 (104)
10:20:34.164751 IP 1.1.1.1.53 > 1.1.1.2.52389: 59022 NXDomain* 0/1/0 (111)

在 Chrome 中打开新标签页:

10:20:44.106915 IP 1.1.1.2.26171 > 1.1.1.1.53: 14460+ A? clients2.google.com. (37)
10:20:44.139387 IP 1.1.1.1.53 > 1.1.1.2.26171: 14460 2/4/4 CNAME clients.l.google.com., A 216.58.211.238 (213)

另外,根据 @Gilles 链接,在 Chrome 中使用代理(Squid)时,您可以access.log在 Chrome 启动时在相应的 Squid 日志文件中看到随机 DNS 名称:

1494276554.709    216 127.0.0.1 TCP_MISS/504 277 HEAD http://vgifrooogs/ - DIRECT/vgifrooogs text/html
1494276554.731    238 127.0.0.1 TCP_MISS/504 277 HEAD http://cbwknhka/ - DIRECT/cbwknhka text/html  
1494276554.875    382 127.0.0.1 TCP_MISS/504 277 HEAD http://vtjhiag/ - DIRECT/vtjhiag text/html

答案1

我发现了一系列关于 Chrome 发出的随机 DNS 请求的帖子/错误报告。结论是这些随机 DNS 请求既不是由恶意软件生成,也不是由插件或附加组件生成。

这些请求由 Chrome 完成,以了解它是否可以处理从地址栏进行的搜索。

我找到的最好的解释引用如下关联

如果您输入单字搜索查询,chrome 需要发送 DNS 请求来检查这是否可能是单字主机名:例如,“test”可能是搜索“test”或导航到“ http://测试”。如果查询最终成为主机,chrome 会显示一个信息栏,询问“您是否打算改为转至“测试””。出于性能原因,DNS 查询需要异步。

现在,一些 ISP 开始针对不存在的域名展示广告( http://en.wikipedia.org/wiki/DNS_hijacking),这意味着 Chrome 将始终为每个单词查询显示该信息栏。由于这很烦人,chrome 现在会在启动时发送三个随机 DNS 请求,如果它们全部解析(我认为是同一个 IP),它现在知道不会为解析的单字查询显示“您是说吗”信息栏到那个IP。

除了上面维基百科条目中提到的 ISP 级别或恶意软件 DNS 劫持之外,一些付费无线接入点或强制门户也会劫持 DNS。随机请求是以看似随机的时间间隔发出的,而不仅仅是在启动 Chrome 时发出。至少,每次当前网络接口获得新的 IP 地址时都会发生这种情况。

这是来自 @Gilles 的与主题相关的另一个链接:Chrome 向无意义 URL 发出异常 HEAD 请求。因此,在问题中添加代理测试设置的主题。您最终会看到代理日志,因为配置代理后,请求是通过代理发出的;并且由代理来解析 DNS 请求。

由于网上缺乏更可靠的详细信息,我使用以下命令下载并仔细阅读了 Chromium 源代码。

git clone https://chromium.googlesource.com/chromium/src 

下面的引用是从 Chromium 源代码注释中复制的:

因为这个函数可以在启动期间调用,所以当启动 URL 获取可能会占用 20 毫秒的时间时,我们延迟了 7 秒,希望这足够长,足以在启动后进行,但仍然可以快速返回结果。

该组件将请求发送到三个随机生成的主机名,因此可能不存在。如果至少两个重定向到相同的主机名,则表明 ISP 正在劫持 NXDOMAIN,并且在决定是否针对某些搜索提示用户使用“您是否打算导航”信息栏时,多功能框应将类似的重定向导航视为“失败”输入。

触发器:“启动时以及计算机的 IP 地址更改时。”

我们生成一个包含 7 到 15 个字符的随机主机名。

我的结论是这些随机 DNS 请求名称并不是恶意软件行为的表现;他们是探针让 Chromium(和 Google Chrome)了解它可以做什么,涉及至少搜索

由于网上缺乏更可靠的详细信息,我在调查中下载了 Chromium 源代码。处理此功能的逻辑可以在文件src/chrome/browser/intranet_redirect_detector.cc和中找到src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc

以下是摘录src/chrome/browser/intranet_redirect_detector.cc

void IntranetRedirectDetector::FinishSleep() {
  in_sleep_ = false;

  // If another fetch operation is still running, cancel it.
  fetchers_.clear();
  resulting_origins_.clear();

  const base::CommandLine* cmd_line = base::CommandLine::ForCurrentProcess();
  if (cmd_line->HasSwitch(switches::kDisableBackgroundNetworking))
    return;

  DCHECK(fetchers_.empty() && resulting_origins_.empty());

  // Create traffic annotation tag.
  net::NetworkTrafficAnnotationTag traffic_annotation =
      net::DefineNetworkTrafficAnnotation("intranet_redirect_detector", R"(
        semantics {
          sender: "Intranet Redirect Detector"
          description:
            "This component sends requests to three randomly generated, and "
            "thus likely nonexistent, hostnames.  If at least two redirect to "
            "the same hostname, this suggests the ISP is hijacking NXDOMAIN, "
            "and the omnibox should treat similar redirected navigations as "
            "'failed' when deciding whether to prompt the user with a 'did you "
            "mean to navigate' infobar for certain search inputs."
          trigger: "On startup and when IP address of the computer changes."
          data: "None, this is just an empty request."
          destination: OTHER
        }
        policy {
          cookies_allowed: false
          setting: "This feature cannot be disabled by settings."
          policy_exception_justification:
              "Not implemented, considered not useful."
        })");

  // Start three fetchers on random hostnames.
  for (size_t i = 0; i < 3; ++i) {
    std::string url_string("http://");
    // We generate a random hostname with between 7 and 15 characters.
    const int num_chars = base::RandInt(7, 15);
    for (int j = 0; j < num_chars; ++j)
      url_string += ('a' + base::RandInt(0, 'z' - 'a'));
    GURL random_url(url_string + '/');
    std::unique_ptr<net::URLFetcher> fetcher = net::URLFetcher::Create(
        random_url, net::URLFetcher::HEAD, this, traffic_annotation);
    // We don't want these fetches to affect existing state in the profile.
    fetcher->SetLoadFlags(net::LOAD_DISABLE_CACHE |
                          net::LOAD_DO_NOT_SAVE_COOKIES |
                          net::LOAD_DO_NOT_SEND_COOKIES |
                          net::LOAD_DO_NOT_SEND_AUTH_DATA);
    fetcher->SetRequestContext(g_browser_process->system_request_context());
    fetcher->Start();
    net::URLFetcher* fetcher_ptr = fetcher.get();
    fetchers_[fetcher_ptr] = std::move(fetcher);
  }
}

void IntranetRedirectDetector::OnURLFetchComplete(
    const net::URLFetcher* source) {
  // Delete the fetcher on this function's exit.
  auto it = fetchers_.find(const_cast<net::URLFetcher*>(source));
  DCHECK(it != fetchers_.end());
  std::unique_ptr<net::URLFetcher> fetcher = std::move(it->second);
  fetchers_.erase(it);

  // If any two fetches result in the same domain/host, we set the redirect
  // origin to that; otherwise we set it to nothing.
  if (!source->GetStatus().is_success() || (source->GetResponseCode() != 200)) {
    if ((resulting_origins_.empty()) ||
        ((resulting_origins_.size() == 1) &&
         resulting_origins_.front().is_valid())) {
      resulting_origins_.push_back(GURL());
      return;
    }
    redirect_origin_ = GURL();
  } 

....

以下是该文件的摘录src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc

// Returns true if |final_url| doesn't represent an ISP hijack of
// |original_url|, based on the IntranetRedirectDetector's RedirectOrigin().
bool IsValidNavigation(const GURL& original_url, const GURL& final_url) {

....

void ChromeOmniboxNavigationObserver::NavigationEntryCommitted(
    const content::LoadCommittedDetails& load_details) {
  load_state_ = LOAD_COMMITTED;
  if (ResponseCodeIndicatesSuccess(load_details.http_status_code) &&
      IsValidNavigation(match_.destination_url,
                        load_details.entry->GetVirtualURL()))
    OnSuccessfulNavigation();
  if (!fetcher_ || (fetch_state_ != FETCH_NOT_COMPLETE))
    OnAllLoadingFinished();  // deletes |this|!
}

...

void ChromeOmniboxNavigationObserver::OnURLFetchComplete(
    const net::URLFetcher* source) {
  DCHECK_EQ(fetcher_.get(), source);
  const net::URLRequestStatus& status = source->GetStatus();
  int response_code = source->GetResponseCode();
  fetch_state_ =
      (status.is_success() && ResponseCodeIndicatesSuccess(response_code)) ||
              ((status.status() == net::URLRequestStatus::CANCELED) &&
               ((response_code / 100) == 3) &&
               IsValidNavigation(alternate_nav_match_.destination_url,
                                 source->GetURL()))
          ? FETCH_SUCCEEDED
          : FETCH_FAILED;
  if (load_state_ == LOAD_COMMITTED)
    OnAllLoadingFinished();  // deletes |this|!
}

相关链接:混合大小写 DNS 请求 - 我的网络中有恶意软件?

稍微相关:为什么 Chromium 缓存 DNS 的时间不会超过一分钟?

相关内容