Chrome: 임의의 DNS 이름을 사용한 DNS 요청: 악성 코드인가요?

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 클라이언트에서도 이러한 현상이 발생한다는 사실을 발견하기 시작했습니다. 이번에도 일부 악성 브라우저 플러그인 때문일 수 있다고 생각했습니다.

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

내 Chrome 브라우저에는 상당히 무해한 플러그인이 설치되어 있습니다.맬웨어의 명백한 징후가 없습니다..

이것이 악의적인 활동인지 진심으로 의심됩니다. 뭐가 문제 야?

(그림이 보여주듯이,pnxcygqemww,rezpubhgutked, 그리고스프루이오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 링크에 따라 Chrome에서 프록시(Squid)를 사용할 때 access.logChrome이 시작될 때 해당 Squid 로그 파일에서 임의의 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

답변1

Chrome에서 발생하는 임의의 DNS 요청에 대한 일련의 게시물/버그 보고서를 발견했습니다. 결론은 이러한 무작위 DNS 요청은 맬웨어나 플러그인 또는 추가 기능에 의해 생성되지 않는다는 것입니다.

이러한 요청은 주소 표시줄에서 검색을 처리할 수 있는지 확인하기 위해 Chrome에서 수행됩니다.

내가 찾은 가장 좋은 설명은 아래에 인용되어 있습니다.협회.

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

이제 일부 ISP에서는 존재하지 않는 도메인( http://en.wikipedia.org/wiki/DNS_hijacking), 이는 Chrome이 항상 모든 단어 검색에 대해 해당 정보 표시줄을 표시함을 의미합니다. 이것이 짜증스럽기 때문에 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을 가져오는 데 20밀리초가 걸릴 수 있으므로 시작 후 이를 수행할 수 있을 만큼 충분히 길기를 바라면서 7초 동안 지연하지만 여전히 결과를 빠르게 반환합니다.

이 구성 요소는 무작위로 생성된 세 개의 호스트 이름에 요청을 보내므로 존재하지 않을 수 있습니다. 두 개 이상의 리디렉션이 동일한 호스트 이름에 대한 경우 이는 ISP가 NXDOMAIN을 하이재킹하고 있다는 신호이며 검색 주소창은 사용자에게 특정 검색에 대해 "탐색하시겠습니까?" 표시줄을 표시할지 여부를 결정할 때 유사한 리디렉션을 포함해야 합니다. "실패한" 입력으로 표시됩니다.

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

7~15자를 포함하는 임의의 호스트 이름을 생성합니다.

내 결론은이러한 무작위 DNS 요청 이름은 맬웨어 동작을 나타내지 않습니다.;그들은조사Chromium(및 Google Chrome)이 무엇을 할 수 있는지 이해하도록 하세요.적어도 검색해봐.

온라인에서 더 신뢰할 수 있는 세부 정보가 부족했기 때문에 조사의 일환으로 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를 캐시하지 않는 이유는 무엇입니까?

관련 정보