Chrome: DNS-Anfragen mit zufälligen DNS-Namen: Malware?

Im Laufe der Jahre (seit 2005) habe ich auf mehreren von mir verwalteten DNS / BIND-Servern Protokolle mit seltsamen zufälligen DNS-Anfragen gesehen.

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)

Normalerweise habe ich Windows-Malware gefunden. Allerdings merke ich, dass es in letzter Zeit auch von Linux- und Mac-Clients kommt. Wieder dachte ich, es könnte an einigen böswilligen Browser-Plug-Ins liegen.

Beim Debuggen eines Google Chrome-Browserproblems in meinem neu installierten Macbook Pro / Chrome unter Verwendung der URL chrome: // net-internals / # dns habe ich jedoch ähnliche Anfragen auf meiner Chrome-DNS-Statistikseite gefunden.

In meinem Chrome-Browser sind ziemlich harmlose Plug-Ins installiert, und es gibt keine offensichtlichen Anzeichen von Malware .

Ich habe meine ehrlichen Zweifel, ob es sich um böswillige Handlungen handeln soll oder nicht. Was ist los?

(Wie im Bild zu sehen, benennen pnxcygqqemww , ryzypwbheguutkd und snplueo DNS Anfragen von Chrome).

Schnüffeln der DNS-Aktivität beim Öffnen des Chrome-Browsers mit:

sudo tcpdump -n port 53

Ich kann die folgenden DNS-Anfragen und erneut die zufälligen Anfragen um 10:20:34 sehen:

Chrome öffnen:

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)

Nach ein paar Sekunden erscheinen tatsächlich die erwähnten zufälligen DNS-Anfragen:

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)

Öffnen eines neuen Tabs in 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)

Laut @Gilles Link können Sie bei Verwendung eines Proxys (Squid) in Chrome die zufälligen DNS-Namen auch in der entsprechenden Squid- access.logProtokolldatei sehen, wenn Chrome bootet:

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

Ich habe eine Reihe von Beiträgen / Fehlerberichten zu zufälligen DNS-Anfragen von Chrome gefunden. Die Schlussfolgerung ist, dass zufällige DNS-Anfragen weder von Malware noch von Plugins oder Add-Ons generiert werden.

Die Anforderungen werden von Chrome ausgeführt, um zu ermitteln, ob Suchvorgänge in der Adressleiste verarbeitet werden können.

Die beste Erklärung, die ich gefunden habe, finden Sie weiter unten unter diesem Link .

Wenn Sie eine Einzelwort-Suchabfrage eingeben, muss Chrome eine DNS-Anfrage senden, um zu prüfen, ob es sich um einen Einzelwort-Hostnamen handelt: "test" ist beispielsweise eine Suche nach "test" oder eine Navigation zu " http: // test ". Wenn die Abfrage ein Host ist, wird in Chrome eine Infoleiste angezeigt, in der Sie gefragt werden, ob Sie stattdessen zum Testen gehen möchten. Aus Leistungsgründen muss die DNS-Abfrage asynchron sein.

Einige ISPs haben nun damit begonnen, Anzeigen für nicht vorhandene Domain-Namen zu schalten ( http://en.wikipedia.org/wiki/DNS_hijacking ), was bedeutet, dass Chrome immer diese Infoleiste für jede einzelne Wortabfrage anzeigt. Da dies ärgerlich ist, sendet Chrome jetzt drei zufällige DNS-Anfragen beim Start. Wenn alle aufgelöst werden (glaube ich an dieselbe IP-Adresse), wird jetzt die Infoleiste "Meinten Sie" für Einzelwortabfragen, die aufgelöst werden, nicht mehr angezeigt zu dieser IP.

Abgesehen von der ISP-Stufe oder dem Malware-DNS-Hijacking des oben verlinkten Wikipedia-Eintrags übernehmen einige kostenpflichtige WLAN-Zugangspunkte oder Captive-Portale auch DNS-Hijacking. Zufällige Anfragen werden in scheinbar zufälligen Abständen und nicht nur beim Starten von Chrome gestellt. Zumindest treten sie jedes Mal auf, wenn die aktuelle Netzwerkschnittstelle eine neue IP-Adresse erhält.

Hier ist ein weiterer Link zum Thema von @Gilles: Ungewöhnliche HEAD-Anfragen an unsinnige URLs von Chrome . Fügen Sie daher der Frage das Thema Proxy-Test-Setup hinzu. Am Ende werden Proxy-Protokolle angezeigt, da die Anforderungen bei der Konfiguration eines Proxys über den Proxy erfolgen. und es liegt an dem Proxy, die DNS-Anforderungen aufzulösen.

Da im Internet keine detaillierten Informationen verfügbar waren, habe ich den Chromium-Quellcode mit dem folgenden Befehl heruntergeladen und durchgesehen.

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

Das folgende Zitat wurde aus den Chromium-Quellcodekommentaren kopiert:

Da diese Funktion während des Startvorgangs aufgerufen werden kann und das Starten eines URL-Abrufs 20 ms Zeit in Anspruch nehmen kann, verzögern wir sieben Sekunden, was hoffentlich lang genug ist, um nach dem Startvorgang zu erfolgen, aber dennoch schnell Ergebnisse zurückgibt.

Diese Komponente sendet Anforderungen an drei zufällig generierte und daher wahrscheinlich nicht vorhandene Hostnamen. Wenn mindestens zwei auf denselben Hostnamen umleiten, deutet dies darauf hin, dass der ISP NXDOMAIN hijackt, und die Omnibox sollte ähnliche umgeleitete Navigationen als "fehlgeschlagen" behandeln, wenn Sie den Benutzer mit einem "Hatten Sie vor, in der Infoleiste zu navigieren" für eine bestimmte Suche aufzufordern Eingänge.

Trigger: "Beim Start und wenn sich die IP-Adresse des Computers ändert."

Wir generieren einen zufälligen Hostnamen mit 7 bis 15 Zeichen.

Mein Fazit ist, dass diese zufälligen DNS-Anforderungsnamen keine Manifestation des Malware-Verhaltens sind . Es handelt sich um Tests für Chromium (und Google Chrome), um zu erfahren, was es zumindest in Bezug auf Suchvorgänge leisten kann .

In Ermangelung genauerer Informationen im Internet habe ich die Chromquellen in meinen Nachforschungen heruntergeladen. Die Logik für diese Funktionalität finden Sie in der Datei src/chrome/browser/intranet_redirect_detector.ccund src/chrome/browser/ui/omnibox/chrome_omnibox_navigation_observer.cc.

Unten ist ein Auszug aus 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();
  } 

....

Unten ist ein Auszug aus der Datei 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|!
}

Weiterführender Link: DNS-Anfragen in Groß- und Kleinschreibung - Malware in meinem Netzwerk? .

Ein wenig verwandt: Warum speichert Chromium DNS nicht länger als eine Minute im Cache?