Chrome: запити DNS із випадковими іменами DNS: зловмисне програмне забезпечення?

Протягом багатьох років (починаючи з 2005 року) я бачив журнали про випадкові випадкові запити DNS, виконані на декількох серверах DNS / BIND, які я підтримував.

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, я знайшов подібні запити на своїй сторінці статистики DNS Chrome.

У моєму браузері Chrome встановлені досить нешкідливі плагіни та відсутні видимі ознаки зловмисного програмного забезпечення .

У мене є сумнівні сумніви, чи має це бути шкідлива діяльність чи ні. Що відбувається?

(Як видно із зображення, запити імен pnsxcygqqemww , ryzypwbheguutkd та snplueo DNS, зроблені Chrome).

Прослуховування DNS-активності, коли браузер Chrome відкривається, за допомогою:

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, під час використання проксі (Squid) у Chrome, ви можете бачити випадкові імена DNS у відповідному access.logфайлі журналу кальмарів під час завантаження 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

Я знайшов серію повідомлень / помилок про випадкові запити DNS, зроблені Chrome. Висновок полягає в тому, що випадкові запити DNS не генеруються ні зловмисним програмним забезпеченням, ні плагінами чи доповненнями.

Запити виконуються Chrome, щоб дізнатися, чи може він обробляти пошук, здійснений із його адресного рядка.

Найкраще пояснення, яке я знайшов, цитується нижче за цим посиланням .

Якщо ви вводите однословний пошуковий запит, chrome повинен надіслати запит DNS, щоб перевірити, чи це може бути однословне ім'я хоста: Наприклад, "test" може бути пошуком "test" або навігацією до " http: // тест ". Якщо запит стає хостом, у хромі відображається інфабар, який запитує "ти мав намір перейти на" тест "замість цього". З міркувань продуктивності запит DNS повинен бути асинхронним.

Тепер деякі провайдери почали показувати рекламу для неіснуючих доменних імен ( http://en.wikipedia.org/wiki/DNS_hijacking ), тобто Chrome завжди показував би інфобар для кожного однослівного запиту. Оскільки це дратує, зараз хром надсилає три випадкові запити DNS при запуску, і якщо всі вони вирішуються (на той самий IP, я думаю), він тепер знає, що не показувати "ви мали на увазі" інфобар для однослівних запитів, які вирішують до цього IP.

Крім рівня провайдера або зловмисного програмного забезпечення DNS, що викрадає пов'язаний запис Вікіпедії вище, деякі платні точки бездротового доступу або невідомі портали також захоплюють DNS. Випадкові запити робляться з, здавалося б, випадковими інтервалами, а не лише при запуску Chrome. Принаймні, вони трапляються щоразу, коли поточний мережевий інтерфейс отримує нову IP-адресу.

Ось ще одне посилання, пов’язане з темою від @Gilles: Незвичайні запити HEAD до нерозумних URL-адрес із Chrome . Отже, додавши до питання тему налаштування проксі-тесту. У кінцевому підсумку ви бачите журнали проксі, оскільки, коли проксі налаштовано, запити робляться через проксі; і, щоб вирішити запити DNS, залежить від проксі.

Не маючи більш ґрунтовних деталей в Інтернеті, я завантажив і вивчив вихідний код Chromium за допомогою команди нижче.

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

Цитата нижче була скопійована з коментарів до джерела Chromium:

Оскільки ця функція може бути викликана під час запуску, коли запуск URL-адреси може з'їсти 20 мс часу, ми затримуємо сім секунд, що, сподіваємось, достатньо довго, щоб бути після запуску, але все одно швидко отримуємо результати.

Цей компонент надсилає запити до трьох випадково згенерованих і, таким чином, ймовірно відсутніх імен хостів. Якщо принаймні два переспрямування на те саме ім’я хоста, це говорить про те, що ISP захоплює NXDOMAIN, і всебічне вікно повинне трактувати подібні перенаправлені навігації як "невдалі", коли вирішує, чи спонукати користувача з "чи ти мав на увазі орієнтуватися" на інфобар для певного пошуку входи.

тригер: "При запуску та коли IP-адреса комп'ютера змінюється."

Ми генеруємо випадкове ім’я хоста, що містить від 7 до 15 символів.

Мій висновок полягає в тому, що ці випадкові імена запитів DNS не є проявом поведінки шкідливих програм ; вони є зондами для Chromium (і Google Chrome), щоб дізнатися, що він може зробити принаймні щодо пошукових запитів .

Не маючи більш ґрунтовних деталей в Інтернеті, я завантажив джерела хрому в моє розслідування. Логіку роботи з цією функціональністю можна знайти у файлі 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 більше хвилини?