Chrome : 임의의 DNS 이름을 가진 DNS 요청 : 맬웨어?

수년 동안 (2005 년 이후), 내가 유지 관리 한 여러 DNS / 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)

나는 보통 그것을 일부 Windows 악성 코드에 분필로 넣었습니다. 그러나 요즘 Linux 및 Mac 클라이언트에서도 나옵니다. 다시 한 번 악의적 인 브라우저 플러그인 때문일 수 있다고 생각했습니다.

그러나 Chrome 브라우저 문제를 디버깅하는 동안 새로 설치된 Macbook Pro / Chrome에서 URL chrome : // net-internals / # dns를 사용하여 Chrome DNS 통계 페이지에서 비슷한 요청을 발견했습니다.

Chrome 브라우저에는 무해한 플러그인이 설치되어 있으며 명백한 맬웨어 징후는 없습니다 .

악의적 인 활동이되어야하는지 아닌지를 정직하게 의심합니다. 무슨 일이야?

(이미지에서 볼 수 있듯이 pnxcygqqemww , ryzypwbheguutkd 및 snplueo DNS 이름은 Chrome에서 요청한 이름입니다).

다음과 같이 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 링크에 따르면 Chrome에서 프록시 (오징어)를 사용할 access.log때 Chrome이 부팅 될 때 해당 오징어 로그 파일 에서 임의의 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

Chrome의 임의 DNS 요청에 대한 일련의 게시물 / 버그 보고서를 찾았습니다. 결론은 임의의 DNS 요청이 맬웨어 나 플러그인 또는 애드온에 의해 생성되지 않는다는 것입니다.

주소 표시 줄에서 검색 한 내용을 처리 할 수 ​​있는지 Chrome에서 요청합니다.

내가 찾은 최고의 설명은 아래 링크 에서 인용됩니다 .

한 단어로 검색어를 입력하면 Chrome에서 DNS 요청을 보내 한 단어로 된 호스트 이름인지 확인해야합니다. 예를 들어 "test"는 "test"를 검색하거나 " http : // test ". 검색어가 호스트 인 경우 크롬에는 '대신'테스트 '로 이동 하시겠습니까?'라는 정보 표시 줄이 표시됩니다. 성능상의 이유로 DNS 쿼리는 비동기식이어야합니다.

이제 일부 ISP는 존재하지 않는 도메인 이름 ( http://en.wikipedia.org/wiki/DNS_hijacking )에 대한 광고를 게재하기 시작했습니다 . 즉, Chrome은 항상 모든 단일 단어 쿼리에 대해 해당 정보 표시 줄을 표시합니다. 이것은 성가신 일이므로 크롬은 시작할 때 무작위로 3 개의 DNS 요청을 보내고, 모두 동일한 IP로 확인되면 해결하는 단일 단어 쿼리에 대해 "의미있는 것"정보 표시 줄을 표시하지 않는다는 것을 알고 있습니다. 그 IP에.

위의 링크 된 Wikipedia 항목을 가로채는 ISP 수준 또는 맬웨어 DNS를 넘어서 일부 유료 무선 액세스 포인트 또는 캡 티브 포털도 DNS를 가로 채고 있습니다. 무작위 요청은 Chrome을 시작할 때뿐만 아니라 무작위로 보이는 간격으로 이루어집니다. 적어도 현재 네트워크 인터페이스가 새 IP 주소를 얻을 때마다 발생합니다.

@Gilles의 테마와 관련된 또 다른 링크는 다음과 같습니다 . Chrome에서 넌센스 URL에 대한 비정상적인 HEAD 요청 . 따라서 질문에 프록시 테스트 설정 주제를 추가합니다. 프록시가 구성되면 요청이 프록시를 통해 이루어지기 때문에 프록시 로그가 표시됩니다. 그리고 DNS 요청을 해결하는 것은 프록시의 책임입니다.

온라인에서 더 자세한 정보가 부족하기 때문에 아래 명령으로 Chromium 소스 코드를 다운로드하여 사용했습니다.

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

아래 인용문은 Chromium 소스 코드 주석에서 복사 한 것입니다.

이 함수는 시작하는 동안 호출 할 수 있기 때문에 URL 가져 오기를 시작하면 20ms의 시간이 소요될 수 있습니다. 7 초를 지연시킵니다. 시작 후 시간이 오래 걸리지 만 여전히 결과를 신속하게 얻을 수 있습니다.

이 구성 요소는 임의로 생성 된 3 개의 존재하지 않는 호스트 이름으로 요청을 보냅니다. 동일한 호스트 이름으로 둘 이상의 리디렉션이있는 경우 ISP가 NXDOMAIN을 가로 채고 있음을 암시하며 검색 주소창에 특정 검색에 대해 '탐색 할 것입니까?'라는 정보 표시 줄을 표시할지 여부를 결정할 때 유사한 리디렉션 된 탐색을 '실패'로 처리해야합니다. 입력.

트리거 : "시작시 및 컴퓨터의 IP 주소가 변경 될 때"

7에서 15 자 사이의 임의의 호스트 이름을 생성합니다.

그 결론은 임의의 DNS 요청 이름이 악성 코드 동작의 징후가 아니라는 것입니다 . 그들은 프로브 크롬 (구글 크롬)에 대한 그것은 관련된 무엇을 할 수 있는지 배울 이상 검색에서 .

온라인에서 더 자세한 정보가 부족하기 때문에 조사에서 Chromium 소스를 다운로드했습니다. 이 기능을 다루는 논리는 파일에서 발견 할 수있다 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이 1 분 이상 DNS를 캐시하지 않는 이유는 무엇입니까?