Chrome: requêtes DNS avec des noms DNS aléatoires: un logiciel malveillant?

Au fil des ans (depuis 2005), j'ai vu des journaux de requêtes DNS aléatoires étranges effectuées sur les multiples serveurs DNS / BIND que je maintenais.

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)

Je l'ai généralement attribué à un malware Windows. Cependant, j'ai commencé à remarquer que cela venait aussi de clients Linux et Mac, récemment. Encore une fois, je pensais que cela pouvait être dû à des plug-ins de navigateur malveillants.

Cependant, lors du débogage d'un problème de navigateur Google Chrome, dans mon Macbook Pro / Chrome nouvellement installé, à l'aide de l'URL chrome: // net-internals / # dns, j'ai trouvé des demandes similaires dans ma page de statistiques DNS Chrome.

Les plug-ins installés dans mon navigateur Chrome sont plutôt anodins et ne présentent aucun signe apparent de malware .

J'ai des doutes honnêtes quant à savoir si ce devrait être ou non une activité malveillante. Qu'est-ce qui se passe?

(Comme le montre l’image pnxcygqqemww , ryzypwbheguutkd et les requêtes de noms DNS snplueo effectuées par Chrome).

Détection de l'activité DNS lors de l'ouverture du navigateur Chrome, avec:

sudo tcpdump -n port 53

Je suis capable de voir les demandes DNS suivantes, et encore les demandes aléatoires à 10:20:34:

Chrome d'ouverture:

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)

Au bout de quelques secondes, les requêtes DNS aléatoires mentionnées apparaissent:

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)

Ouvrir un nouvel onglet dans 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)

En outre, selon lien @Gilles, lorsque vous utilisez un proxy (Squid) dans Chrome, vous pouvez voir les noms DNS aléatoires dans le Squid correspondant access.logfichier journal, lorsque Chrome est le démarrage:

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

J'ai trouvé une série de messages / rapports de bugs sur des requêtes DNS aléatoires effectuées par Chrome. La conclusion est que les requêtes DNS aléatoires ne sont générées ni par des logiciels malveillants, ni par des plugins ou des add-ons.

Les requêtes sont effectuées par Chrome pour savoir s’il peut gérer les recherches effectuées dans sa barre d’adresses.

La meilleure explication que j'ai trouvée est citée ci-dessous à partir de ce lien .

Si vous tapez une requête de recherche comportant un seul mot, chrome doit envoyer une requête DNS pour vérifier s'il peut s'agir d'un nom d'hôte composé d'un seul mot. Par exemple, "test" peut être une recherche de "test" ou une navigation vers " http: // test ". Si la requête finit par être un hôte, chrome affiche une barre d’information qui demande "voulez-vous dire que vous voulez aller à" tester "à la place". Pour des raisons de performances, la requête DNS doit être asynchrone.

À présent, certains FAI ont commencé à diffuser des annonces pour des noms de domaine inexistants ( http://en.wikipedia.org/wiki/DNS_hijacking ), ce qui signifie que Chrome l'afficherait toujours pour chaque requête comportant un seul mot. Comme cela est agaçant, chrome envoie maintenant trois requêtes DNS aléatoires au démarrage, et si elles résolvent toutes (vers la même adresse IP, je pense), il sait désormais qu'il ne faut pas afficher l'infobar "voulez-vous dire" pour les requêtes à mot unique qui résolvent à cette adresse IP.

Au-delà du niveau de fournisseur de services ou du programme malveillant DNS piratant l'entrée liée Wikipedia ci-dessus, certains points d'accès sans fil payants ou portails captifs piratent également le DNS. Les requêtes aléatoires sont effectuées à des intervalles apparemment aléatoires, et pas seulement au démarrage de Chrome. Au moins, elles se produisent chaque fois que l’interface réseau actuelle obtient une nouvelle adresse IP.

Voici un autre lien en rapport avec le thème de @Gilles: demandes HEAD inhabituelles aux URL non-sens de Chrome . Par conséquent, ajouter à la question le sujet de la configuration du test de proxy. Vous finissez par voir les journaux du proxy car, lorsqu'un proxy est configuré, les demandes sont effectuées via le proxy; et, il appartient au proxy de résoudre les demandes DNS.

Manquant de plus de détails en ligne, j'ai téléchargé et lu le code source de Chromium avec la commande ci-dessous.

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

La citation ci-dessous a été copiée à partir des commentaires du code source Chromium:

Etant donné que cette fonction peut être appelée au démarrage, lorsque le démarrage d'une extraction d'URL peut prendre 20 ms, nous différons de sept secondes, ce qui est suffisamment long pour être après le démarrage, mais les résultats sont toujours rapidement récupérés.

Ce composant envoie des requêtes à trois noms d’hôte générés aléatoirement, et donc probablement inexistants. Si au moins deux redirigent vers le même nom d'hôte, cela suggère que le fournisseur de services Internet pirate NXDOMAIN et que l'omnibox devrait traiter les navigations redirigées similaires comme "en échec" lorsqu 'il décide d'inviter l'utilisateur à indiquer si vous voulez naviguer dans l'infobar pour certaines recherches. contributions.

trigger: "Au démarrage et lorsque l'adresse IP de l'ordinateur change."

Nous générons un nom d'hôte aléatoire comprenant entre 7 et 15 caractères.

Ma conclusion est que ces noms de requêtes DNS aléatoires ne sont pas une manifestation du comportement des logiciels malveillants ; ce sont des sondes pour Chrome (et Google Chrome) pour savoir ce qu’il peut faire au moins pour les recherches .

Manquant de plus de détails en ligne, j'ai téléchargé les sources de Chrome dans mon enquête. La logique traitant de cette fonctionnalité peut être trouvée dans le fichier, src/chrome/browser/intranet_redirect_detector.ccet src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc.

Ci-dessous un extrait de 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();
  } 

....

Ci-dessous un extrait du fichier 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|!
}

Lien connexe: Demandes DNS de cas mixtes - Malware sur mon réseau? .

Légèrement lié: Pourquoi Chromium ne met-il pas le DNS en cache plus d'une minute?