Chrome: Permintaan DNS dengan nama DNS acak: malware?

Selama bertahun-tahun (sejak 2005), saya telah melihat log dari permintaan DNS acak yang aneh dilakukan, pada beberapa server DNS / BIND yang saya kelola.

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)

Saya biasanya menghubungkannya dengan beberapa malware Windows. Namun, saya mulai memperhatikan bahwa ini juga berasal dari klien Linux dan Mac, belakangan ini. Sekali lagi saya pikir itu bisa disebabkan oleh beberapa plug-in browser jahat.

Namun, saat men-debug masalah browser Google Chrome, di Macbook Pro / Chrome yang baru saya instal, menggunakan URL chrome: // net-internal / # dns, saya menemukan permintaan serupa di halaman statistik Chrome DNS saya.

Browser Chrome saya memasang plug-in yang tidak berbahaya dan tidak ada tanda-tanda malware .

Saya memiliki keraguan jujur ​​saya apakah itu harus atau tidak kegiatan berbahaya. Apa yang terjadi?

(Seperti yang terlihat pada gambar, pnxcygqqemww , ryzypwbheguutkd , dan snplueo, permintaan nama DNS dibuat oleh Chrome).

Mengendus aktivitas DNS saat browser Chrome terbuka, dengan:

sudo tcpdump -n port 53

Saya dapat melihat permintaan DNS berikut, dan sekali lagi permintaan acak pada 10:20:34:

Membuka 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)

Setelah beberapa detik, permintaan DNS acak yang disebutkan di atas memang muncul:

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)

Membuka tab baru di 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)

Selain itu, menurut tautan @Gilles, saat menggunakan proxy (Squid) di Chrome, Anda dapat melihat nama DNS acak di access.logfile log Squid yang sesuai , ketika Chrome mem-boot:

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

Saya menemukan serangkaian posting / laporan bug tentang permintaan DNS acak yang dibuat oleh Chrome. Kesimpulannya adalah bahwa permintaan DNS acak tidak dihasilkan oleh malware atau oleh plugins atau add-on.

Permintaan dilakukan oleh Chrome untuk mengetahui apakah ia dapat menangani pencarian yang dilakukan dari bilah alamatnya.

Penjelasan terbaik yang saya temukan dikutip di bawah ini dari tautan ini .

Jika Anda mengetikkan permintaan pencarian satu kata, chrome perlu mengirim permintaan DNS untuk memeriksa apakah ini mungkin nama host satu kata: Misalnya, "test" mungkin pencarian untuk "test" atau navigasi ke " http: // test ". Jika kueri akhirnya menjadi host, chrome menunjukkan infobar yang menanyakan "apakah Anda bermaksud untuk 'menguji' sebagai gantinya". Untuk alasan kinerja, permintaan DNS harus tidak sinkron.

Sekarang beberapa ISP mulai menampilkan iklan untuk nama domain yang tidak ada ( http://en.wikipedia.org/wiki/DNS_hijacking ), yang berarti Chrome akan selalu menunjukkan infobar itu untuk setiap permintaan kata tunggal. Karena ini menjengkelkan, chrome sekarang mengirim tiga permintaan DNS acak saat startup, dan jika mereka semua menyelesaikan (ke IP yang sama, saya pikir), sekarang tahu tidak menunjukkan infobar "maksud Anda" untuk pertanyaan satu kata yang menyelesaikan untuk IP itu.

Di luar level ISP atau DNS malware yang membajak entri Wikipedia yang tertaut di atas, beberapa titik akses nirkabel berbayar atau portal tawanan juga membajak DNS. Permintaan acak dibuat dengan interval yang tampaknya acak, dan tidak hanya saat memulai Chrome. Setidaknya, itu terjadi setiap kali antarmuka jaringan saat ini mendapatkan alamat IP baru.

Berikut ini tautan lain yang terkait dengan tema dari @Gilles: Permintaan HEAD yang tidak biasa untuk URL yang tidak masuk akal dari Chrome . Oleh karena itu, menambah pertanyaan tentang topik pengaturan uji proxy. Anda akhirnya melihat log proxy karena, ketika proxy dikonfigurasi, permintaan dilakukan melalui proxy; dan, tergantung pada proxy untuk menyelesaikan permintaan DNS.

Karena tidak memiliki detail yang lebih solid secara online, saya mengunduh dan membaca kode sumber Chromium dengan perintah di bawah ini.

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

Kutipan di bawah ini disalin dari komentar kode sumber Chromium:

Karena fungsi ini dapat dipanggil saat startup, ketika memulai mengambil URL dapat memakan waktu hingga 20 ms, kami menunda tujuh detik, yang diharapkan cukup lama setelah startup, tetapi masih mendapatkan hasil dengan cepat.

Komponen ini mengirimkan permintaan ke tiga nama host yang dibuat secara acak, dan karenanya kemungkinan tidak ada, nama host. Jika setidaknya dua mengarahkan ke nama host yang sama, ini menunjukkan bahwa ISP sedang membajak NXDOMAIN, dan mahakotak harus memperlakukan navigasi yang dialihkan yang sama sebagai 'gagal' ketika memutuskan apakah akan meminta pengguna dengan infobar 'maksud Anda menavigasi' untuk pencarian tertentu input.

pemicu: "Saat startup dan ketika alamat IP komputer berubah."

Kami menghasilkan nama host acak dengan antara 7 dan 15 karakter.

Kesimpulan saya adalah bahwa nama-nama permintaan DNS acak itu bukan manifestasi dari perilaku malware ; mereka adalah probe untuk Chromium (dan Google Chrome) untuk mempelajari apa yang dapat dilakukannya terkait dengan setidaknya pencarian .

Karena tidak memiliki detail yang lebih solid di internet, saya mengunduh sumber Chromium dalam penyelidikan. Logika yang berhubungan dengan fungsi ini dapat ditemukan di dalam file, src/chrome/browser/intranet_redirect_detector.ccdan src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc.

Di bawah ini adalah kutipan dari 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();
  } 

....

Berikut adalah kutipan dari file, 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|!
}

Tautan terkait: Permintaan DNS case campuran - Malware di jaringan saya? .

Sedikit terkait: Mengapa Chromium tidak melakukan cache DNS selama lebih dari satu menit?