Chrome: żądania DNS z losowymi nazwami DNS: złośliwe oprogramowanie?

Przez lata (od 2005 r.) Widziałem dzienniki dziwnych losowych żądań DNS wykonanych na wielu serwerach DNS / BIND, które prowadziłem.

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)

Zazwyczaj przypisywałem to złośliwemu oprogramowaniu dla systemu Windows. Zacząłem jednak zauważać, że ostatnio pochodzi on także od klientów Linux i Mac. Znów pomyślałem, że może to być spowodowane złośliwymi wtyczkami do przeglądarki.

Jednak podczas debugowania problemu z przeglądarką Google Chrome w moim nowo zainstalowanym Macbooku Pro / Chrome, używając adresu URL chrome: // net-internals / # dns, znalazłem podobne żądania na mojej stronie statystyk DNS Chrome.

W mojej przeglądarce Chrome są zainstalowane raczej nieszkodliwe wtyczki i brak widocznych oznak złośliwego oprogramowania .

Mam szczere wątpliwości, czy powinna to być złośliwa aktywność, czy nie. Co się dzieje?

(Jak widać na obrazku, pnxcygqqemww , ryzypwbheguutkd i snplueo żądania nazw DNS złożone przez Chrome).

Wykrywanie aktywności DNS podczas otwierania przeglądarki Chrome:

sudo tcpdump -n port 53

Jestem w stanie zobaczyć następujące żądania DNS i ponownie losowe żądania o 10:20:34:

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

Po kilku sekundach rzeczywiście pojawiają się wspomniane losowe żądania 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)

Otwieranie nowej karty w 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)

Ponadto, zgodnie z linkiem @Gilles, gdy używasz proxy (Squid) w Chrome, możesz zobaczyć losowe nazwy DNS w odpowiednim access.logpliku dziennika Squid podczas uruchamiania Chrome:

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

Znalazłem serię postów / raportów o błędach dotyczących losowych żądań DNS wysyłanych przez Chrome. Wniosek jest taki, że losowe żądania DNS nie są generowane przez złośliwe oprogramowanie ani wtyczki lub dodatki.

Żądania są wykonywane przez Chrome, aby dowiedzieć się, czy może on obsługiwać wyszukiwania wykonane z paska adresu.

Najlepsze wyjaśnienie, które znalazłem, jest cytowane poniżej z tego linku .

Jeśli wpiszesz zapytanie do wyszukiwania pojedynczego słowa, Chrome musi wysłać żądanie DNS, aby sprawdzić, czy może to być nazwa hosta zawierającego jedno słowo: Na przykład „test” może być wyszukiwaniem „testu” lub nawigacją do „ http: // test ”. Jeśli kwerenda jest hostem, chrome pokazuje pasek informacyjny, który pyta „czy zamiast tego chciałeś przejść do„ testu ”. Ze względu na wydajność zapytanie DNS musi być asynchroniczne.

Teraz niektórzy dostawcy usług internetowych zaczęli wyświetlać reklamy dla nieistniejących nazw domen ( http://en.wikipedia.org/wiki/DNS_hijacking ), co oznacza, że ​​Chrome zawsze wyświetla ten pasek informacyjny dla każdego pojedynczego zapytania. Ponieważ jest to denerwujące, Chrome wysyła teraz trzy losowe żądania DNS podczas uruchamiania, a jeśli wszystkie zostaną rozwiązane (myślę, że do tego samego adresu IP), teraz nie wyświetla paska informacji „Czy miałeś na myśli” w przypadku zapytań zawierających pojedyncze słowa do tego adresu IP.

Poza poziomem ISP lub złośliwym DNS przechwytującym powyższy link w Wikipedii, niektóre płatne bezprzewodowe punkty dostępowe lub niewoli portale również przejmują DNS. Losowe żądania są wysyłane w pozornie losowych odstępach czasu, a nie tylko podczas uruchamiania Chrome. Przynajmniej zdarzają się za każdym razem, gdy bieżący interfejs sieciowy otrzymuje nowy adres IP.

Oto kolejny link związany z motywem z @Gilles: Nietypowe żądania HEAD do nonsensownych adresów URL z Chrome . Stąd dodanie do pytania tematu konfiguracji testu proxy. W efekcie widzisz dzienniki proxy, ponieważ kiedy proxy jest skonfigurowane, żądania są wysyłane przez proxy; i od proxy zależy rozstrzyganie żądań DNS.

Nie mając bardziej szczegółowych informacji w Internecie, pobrałem i przejrzałem kod źródłowy Chromium za pomocą poniższego polecenia.

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

Poniższy cytat został skopiowany z komentarzy do kodu źródłowego Chromium:

Ponieważ tę funkcję można wywołać podczas uruchamiania, po uruchomieniu pobierania adresu URL można zużyć 20 ms czasu, opóźniamy siedem sekund, co, miejmy nadzieję, wystarczy na uruchomienie, ale nadal szybko wracamy do wyników.

Ten komponent wysyła żądania do trzech losowo generowanych, a zatem prawdopodobnie nieistniejących nazw hostów. Jeśli co najmniej dwa przekierowują na tę samą nazwę hosta, sugeruje to, że ISP przejmuje kontrolę nad NXDOMAIN, a omnibox powinien traktować podobne przekierowane nawigacje jako „nieudane” przy podejmowaniu decyzji, czy poprosić użytkownika o wyświetlenie paska informacyjnego „czy chciałeś nawigować” w celu określonego wyszukiwania wejścia.

wyzwalacz: „Po uruchomieniu i zmianie adresu IP komputera”.

Generujemy losową nazwę hosta zawierającą od 7 do 15 znaków.

Mój wniosek jest taki, że te losowe nazwy żądań DNS nie są przejawem zachowania złośliwego oprogramowania ; są sondami dla Chromium (i Google Chrome), aby dowiedzieć się, co może zrobić, jeśli chodzi o przynajmniej wyszukiwania .

Nie mając bardziej szczegółowych informacji w Internecie, pobrałem źródła Chromium w moim dochodzeniu. Logikę dotyczącą tej funkcji można znaleźć w pliku src/chrome/browser/intranet_redirect_detector.cci src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc.

Poniżej fragment 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();
  } 

…

Poniżej znajduje się fragment pliku 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|!
}

Powiązany link: Żądania DNS dotyczące różnych przypadków - złośliwe oprogramowanie w mojej sieci? .

Nieznacznie powiązane: Dlaczego Chromium nie buforuje DNS przez dłużej niż minutę?