Chrome: यादृच्छिक यादृच्छिक नामों के साथ DNS अनुरोध: मैलवेयर?

88

वर्षों से (2005 के बाद से), मैंने कई डीएनएस / BIND सर्वरों पर बनाए गए अजीब यादृच्छिक DNS अनुरोधों के लॉग देखे हैं।

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)

मैंने आमतौर पर इसे कुछ विंडोज मालवेयर तक चाक किया। हालाँकि, मैंने यह देखना शुरू कर दिया है कि यह लिनक्स और मैक क्लाइंट से भी आ रहा है, हाल ही में। फिर से मुझे लगा कि यह कुछ दुर्भावनापूर्ण ब्राउज़र प्लग-इन (s) के कारण हो सकता है।

हालाँकि, Google Chrome ब्राउज़र समस्या को डीबग करते समय, मेरे नए स्थापित मैकबुक प्रो / क्रोम में, URL क्रोम का उपयोग करते हुए: // net-internals / # dns, मुझे अपने क्रोम DNS आँकड़े पृष्ठ में समान अनुरोध मिले।

मेरे क्रोम ब्राउज़र में सहज रूप से प्लग-इन स्थापित है और मैलवेयर के कोई स्पष्ट संकेत नहीं हैं ।

मुझे अपने ईमानदार संदेह हैं कि यह दुर्भावनापूर्ण गतिविधि होनी चाहिए या नहीं। क्या हो रहा है?

(जैसा कि चित्र में देखा गया है, pnxcygqqemww , ryzypwbheguutkd , और snplueo DNS नाम Chrome द्वारा किए गए अनुरोध)।

DNS

Chrome ब्राउज़र खुलने पर DNS गतिविधि को सूँघना, साथ:

sudo tcpdump -n port 53

मैं निम्नलिखित DNS अनुरोधों को देखने में सक्षम हूं, और 10:20:34 पर फिर से यादृच्छिक अनुरोध करता हूं:

ओपनिंग क्रोम:

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 लिंक के अनुसार, जब क्रोम में एक प्रॉक्सी (स्क्विड) का उपयोग कर रहे हैं access.log, तो आप क्रोम के बूट होने पर संबंधित स्क्वीड लॉग फ़ाइल में यादृच्छिक DNS नाम देख सकते हैं :

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
security  dns  chrome 
— रुई एफ रिबेरो
स्रोत
8
— Gilles

जवाबों:

124

मुझे Chrome द्वारा किए गए यादृच्छिक DNS अनुरोधों के बारे में पोस्ट / बग रिपोर्ट की एक श्रृंखला मिली। निष्कर्ष यह है कि यादृच्छिक डीएनएस अनुरोध न तो मैलवेयर द्वारा उत्पन्न होते हैं और न ही प्लगइन्स या ऐड-ऑन द्वारा।

Chrome द्वारा यह जानने के लिए अनुरोध किया जाता है कि क्या वह अपने एड्रेस बार से की गई खोजों को संभाल सकता है।

मैंने जो सबसे अच्छा स्पष्टीकरण पाया है, वह इस लिंक से नीचे उद्धृत किया गया है ।

यदि आप एकल-शब्द खोज क्वेरी में टाइप करते हैं, तो क्रोम को यह जाँचने के लिए DNS अनुरोध भेजने की आवश्यकता है कि क्या यह एकल-शब्द होस्ट नाम हो सकता है: उदाहरण के लिए, "परीक्षण" "परीक्षण" या "नेविगेशन" के लिए एक खोज हो सकती है। http: // परीक्षण "। यदि क्वेरी होस्ट के रूप में समाप्त होती है, तो क्रोम एक इन्फोबार दिखाता है जो पूछता है कि "क्या आपका मतलब इसके बजाय 'परीक्षण' में जाने का था"। प्रदर्शन कारणों से, DNS क्वेरी को अतुल्यकालिक होने की आवश्यकता है।

अब कुछ ISPs ने गैर-मौजूद डोमेन नाम ( http://en.wikipedia.org/wiki/DNS_hijacking ) के लिए विज्ञापन दिखाना शुरू कर दिया , जिसका अर्थ है कि क्रोम हमेशा हर एक-शब्द क्वेरी के लिए उस infobar को दिखाएगा। चूंकि यह कष्टप्रद है, इसलिए क्रोम अब स्टार्टअप पर तीन यादृच्छिक DNS अनुरोध भेजता है, और यदि वे सभी हल करते हैं (उसी आईपी के लिए, मुझे लगता है), तो अब यह एकल-शब्द प्रश्नों के लिए "क्या आपका मतलब" infobar नहीं दिखाना जानता है जो हल करते हैं उस आईपी को।

ऊपर दिए गए विकिपीडिया प्रविष्टि के आईएसपी स्तर या मैलवेयर डीएनएस अपहरण से परे, कुछ सशुल्क वायरलेस एक्सेस पॉइंट या कैप्टिव पोर्टल भी डीएनएस को हाईजैक करते हैं। यादृच्छिक रूप से यादृच्छिक अंतराल पर यादृच्छिक अनुरोध किए जाते हैं, और क्रोम शुरू करते समय ही नहीं। कम से कम, वे हर बार होते हैं जब वर्तमान नेटवर्क इंटरफ़ेस को एक नया आईपी पता मिलता है।

यहाँ @Gilles के विषय से संबंधित एक और लिंक दिया गया है: असामान्य HEAD Chrome से निरर्थक URL का अनुरोध करता है । इसलिए, प्रॉक्सी टेस्ट सेटअप के विषय पर सवाल जोड़ना। आप प्रॉक्सी लॉग देख कर समाप्त होते हैं क्योंकि, जब कोई प्रॉक्सी कॉन्फ़िगर किया जाता है, तो प्रॉक्सी के माध्यम से अनुरोध किया जाता है; और, यह DNS अनुरोधों को हल करने के लिए प्रॉक्सी पर निर्भर है।

अधिक ठोस विवरणों को ऑनलाइन खोना, मैंने क्रोमियम स्रोत कोड को नीचे दिए गए आदेश के साथ डाउनलोड किया और उपयोग किया।

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

नीचे दिए गए उद्धरण को क्रोमियम स्रोत कोड टिप्पणियों से कॉपी किया गया था:

क्योंकि स्टार्टअप के दौरान इस फ़ंक्शन को कॉल किया जा सकता है, जब एक URL प्राप्त करना बंद हो जाता है, तो आप 20 एमएस समय खा सकते हैं, हम सात सेकंड देरी करते हैं, जो स्टार्टअप के बाद होने की उम्मीद है, लेकिन अभी भी परिणाम जल्दी वापस मिलते हैं।

यह घटक तीन बेतरतीब ढंग से उत्पन्न करने के लिए अनुरोध भेजता है, और इस तरह की संभावना नहीं है, hostnames। यदि एक ही होस्टनाम में कम से कम दो पुनर्निर्देशित हैं, तो यह सुझाव देता है कि आईएसपी NXDOMAIN को अपहरण कर रहा है, और सर्वग्राही को समान पुनर्निर्देशित नेविगेशंस का इलाज करना चाहिए, जब यह तय करने के लिए कि क्या उपयोगकर्ता को 'क्या आपने नेविगेट करने का मतलब है' निश्चित खोज के लिए infobar नेविगेट करने का निर्णय लिया था आदानों।

ट्रिगर: "स्टार्टअप पर और जब कंप्यूटर का आईपी पता बदलता है।"

हम 7 और 15 अक्षरों के बीच एक यादृच्छिक होस्टनाम बनाते हैं।

मेरा निष्कर्ष यह है कि उन यादृच्छिक डीएनएस अनुरोध नाम मालवेयर व्यवहार की अभिव्यक्ति नहीं हैं ; वे क्रोमियम (और 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 अनुरोध - मेरे नेटवर्क में मैलवेयर? ।

थोड़ा संबंधित: क्रोमियम DNS को एक मिनट से अधिक समय तक कैश क्यों नहीं करता है?

— रुई एफ रिबेरो
स्रोत
@cat धन्यवाद, अगर आप इसे पसंद करते हैं, तो शायद आप भी इसे पसंद करेंगे। unix.stackexchange.com/questions/363498/…
— Rui F Ribeiro
3
"संकेत भी हैं उन यादृच्छिक अनुरोधों को प्रतीत होता है यादृच्छिक अंतराल पर किया जाता है, और न केवल क्रोम शुरू करते समय" - निश्चित रूप से सच है। मैं उन्हें पैकेट लॉग में देखता हूं, हालांकि मैं मूल रूप से क्रोम को कभी भी पुनरारंभ नहीं करता हूं।
— केविन
2
@ केविन "जब भी कंप्यूटर का आईपी पता बदलता है" - आपके कंप्यूटर को राउटर के साथ अपने डीएचसीपी पट्टे को नवीकरणीय रूप से यादृच्छिक अंतराल पर नवीनीकृत करना होगा, जो इसे ट्रिगर करेगा।
— रैलिंग जूल
@ बाइक चलाना प्रेरणा। मैंने टिप्पणी की कि स्पष्ट रूप से बताएं। हालांकि मुझे यकीन नहीं है कि यह अन्य स्थितियों में होता है।
— रुई एफ रिबेरो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.