Chrome: Yêu cầu DNS với tên DNS ngẫu nhiên: phần mềm độc hại?

Trong nhiều năm (từ năm 2005), tôi đã thấy nhật ký của các yêu cầu DNS ngẫu nhiên kỳ lạ được thực hiện, trên nhiều máy chủ DNS / BIND mà tôi đã duy trì.

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)

Tôi thường viết nó lên một số phần mềm độc hại Windows. Tuy nhiên, gần đây tôi đã bắt đầu nhận thấy nó cũng đến từ các máy khách Linux và Mac. Một lần nữa tôi nghĩ rằng nó có thể là do một số trình cắm trình duyệt độc hại.

Tuy nhiên, trong khi gỡ lỗi sự cố trình duyệt Google Chrome, trong Macbook Pro / Chrome mới cài đặt của tôi, sử dụng URL chrome: // net-internals / # dns, tôi đã tìm thấy các yêu cầu tương tự trong trang thống kê DNS Chrome của mình.

Trình duyệt Chrome của tôi đã cài đặt các plugin khá vô hại và không có dấu hiệu phần mềm độc hại rõ ràng .

Tôi có nghi ngờ trung thực của tôi rằng nó nên hay không hoạt động độc hại. Chuyện gì đang xảy ra vậy?

(Như đã thấy trong hình ảnh, pnxcygqqemww , ryzypwbheguutkd và snplueo yêu cầu tên DNS được thực hiện bởi Chrome).

Đánh hơi hoạt động DNS khi trình duyệt Chrome đang mở, với:

sudo tcpdump -n port 53

Tôi có thể thấy các yêu cầu DNS sau đây và một lần nữa các yêu cầu ngẫu nhiên lúc 10:20:34:

Mở 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)

Sau một vài giây, các yêu cầu DNS ngẫu nhiên được đề cập, thực sự xuất hiện:

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)

Mở một tab mới trong 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)

Ngoài ra, theo liên kết @Gilles, khi sử dụng proxy (Squid) trong Chrome, bạn có thể thấy tên DNS ngẫu nhiên trong access.logtệp nhật ký Squid tương ứng , khi Chrome khởi động:

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

Tôi đã tìm thấy một loạt các bài đăng / báo cáo lỗi về các yêu cầu DNS ngẫu nhiên được tạo bởi Chrome. Kết luận là các yêu cầu DNS ngẫu nhiên không được tạo bởi phần mềm độc hại cũng như bởi các plugin hoặc tiện ích bổ sung.

Các yêu cầu được Chrome thực hiện để tìm hiểu xem nó có thể xử lý các tìm kiếm được thực hiện từ thanh địa chỉ của nó không.

Giải thích tốt nhất tôi đã tìm thấy được trích dẫn dưới đây từ liên kết này .

Nếu bạn nhập truy vấn tìm kiếm một từ, chrome cần gửi yêu cầu DNS để kiểm tra xem đây có phải là tên máy chủ một từ không: Ví dụ: "test" có thể là tìm kiếm "test" hoặc điều hướng đến " http: // kiểm tra ". Nếu truy vấn kết thúc là một máy chủ lưu trữ, chrome sẽ hiển thị một infobar hỏi "bạn có nghĩa là đi đến 'thử nghiệm" thay vào đó. Vì lý do hiệu suất, truy vấn DNS cần phải không đồng bộ.

Giờ đây, một số ISP bắt đầu hiển thị quảng cáo cho các tên miền không tồn tại ( http://en.wikipedia.org/wiki/DNS_hijacking ), có nghĩa là Chrome sẽ luôn hiển thị thông tin đó cho mọi truy vấn một từ. Vì điều này gây khó chịu, giờ đây chrome gửi ba yêu cầu DNS ngẫu nhiên khi khởi động và nếu tất cả chúng đều giải quyết (với cùng một IP, tôi nghĩ giờ đây sẽ không hiển thị thông tin "có nghĩa là" đối với các truy vấn một từ giải quyết đến IP đó.

Ngoài cấp độ ISP hoặc phần mềm độc hại DNS chiếm quyền điều khiển Wikipedia được liên kết ở trên, một số điểm truy cập không dây phải trả tiền hoặc cổng bị khóa cũng chiếm quyền điều khiển DNS. Các yêu cầu ngẫu nhiên được thực hiện theo các khoảng thời gian dường như ngẫu nhiên và không chỉ khi bắt đầu Chrome. Ít nhất, chúng xảy ra mỗi khi giao diện mạng hiện tại có địa chỉ IP mới.

Đây là một liên kết khác liên quan đến chủ đề từ @Gilles: Các yêu cầu CHÍNH bất thường đến các URL vô nghĩa từ Chrome . Do đó, thêm vào câu hỏi về chủ đề thiết lập thử nghiệm proxy. Cuối cùng, bạn sẽ thấy nhật ký proxy vì khi proxy được định cấu hình, các yêu cầu được thực hiện thông qua proxy; và, tùy thuộc vào proxy để giải quyết các yêu cầu DNS.

Thiếu thông tin chi tiết trực tuyến hơn, tôi đã tải xuống và kiểm tra mã nguồn Chromium bằng lệnh bên dưới.

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

Trích dẫn bên dưới được sao chép từ các nhận xét về mã nguồn Chromium:

Bởi vì chức năng này có thể được gọi trong khi khởi động, khi khởi động một URL tìm nạp có thể ngốn hết 20 ms thời gian, chúng tôi trì hoãn bảy giây, hy vọng đủ lâu để có được sau khi khởi động, nhưng vẫn nhanh chóng lấy lại kết quả.

Thành phần này gửi yêu cầu đến ba tên được tạo ngẫu nhiên và do đó có thể không tồn tại, tên máy chủ lưu trữ. Nếu ít nhất hai lần chuyển hướng đến cùng một tên máy chủ, điều này cho thấy ISP đang chiếm quyền điều khiển NXDOMAIN và thanh địa chỉ nên coi các điều hướng được chuyển hướng tương tự là 'thất bại' khi quyết định có nhắc người dùng bằng 'bạn có ý định điều hướng' cho một tìm kiếm nhất định không đầu vào.

kích hoạt: "Khi khởi động và khi địa chỉ IP của máy tính thay đổi."

Chúng tôi tạo một tên máy chủ ngẫu nhiên có từ 7 đến 15 ký tự.

Kết luận của tôi là những tên yêu cầu DNS ngẫu nhiên đó không phải là biểu hiện của hành vi phần mềm độc hại ; họ là những người thăm dò Chromium (và Google Chrome) để tìm hiểu những gì nó có thể làm liên quan đến ít nhất các tìm kiếm .

Thiếu thông tin chi tiết trực tuyến hơn, tôi đã tải xuống các nguồn Chromium trong cuộc điều tra của mình. Logic xử lý chức năng này có thể được tìm thấy trong tệp src/chrome/browser/intranet_redirect_detector.ccvà src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc.

Dưới đây là một đoạn trích của 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();
  } 

....

Dưới đây là một đoạn trích của tập tin , 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|!
}

Liên kết liên quan: Yêu cầu DNS trường hợp hỗn hợp - Phần mềm độc hại trong mạng của tôi? .

Liên quan một chút: Tại sao Chromium không lưu trữ DNS trong hơn một phút?