Chrome: requêtes DNS avec des noms DNS aléatoires: malware?
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 j'ai maintenus.
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é à certains logiciels malveillants Windows. Cependant, j'ai commencé à remarquer que cela venait aussi des clients Linux et Mac, récemment. Encore une fois, je pensais que cela pourrait ê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é, en utilisant l'URL chrome: // net-internals/# dns, j'ai trouvé des demandes similaires dans mes statistiques DNS Chrome page.
Mon navigateur Chrome a des plug-ins plutôt inoffensifs installés et aucun signe apparent de malware.
J'ai des doutes honnêtes sur le fait qu'il s'agisse ou non d'une activité malveillante. Qu'est-ce qui se passe?
(Comme on le voit sur l'image, pnxcygqqemww, ryzypwbheguutkd, et snplueo les demandes de noms DNS faites par Chrome).
Renifler l'activité DNS à l'ouverture du navigateur Chrome, avec:
Sudo tcpdump -n port 53
Je peux voir les requêtes DNS suivantes, et encore les requêtes aléatoires à 10:20:34:
Ouverture de Chrome:
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)
Après quelques secondes, les requêtes DNS aléatoires mentionnées apparaissent en effet:
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)
De plus, selon le lien @Gilles, lorsque vous utilisez un proxy (Squid) dans Chrome, vous pouvez voir les noms DNS aléatoires dans le fichier journal Squid access.log Correspondant, lorsque Chrome démarre:
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 bogues sur les demandes DNS aléatoires faites par Chrome. La conclusion est que les requêtes DNS aléatoires ne sont ni générées par des logiciels malveillants ni par des plugins ou des modules complémentaires.
Les demandes sont effectuées par Chrome pour savoir s'il peut gérer les recherches effectuées à partir de sa barre d'adresse.
La meilleure explication que j'ai trouvée est citée ci-dessous lien .
Si vous saisissez une requête de recherche à mot unique, chrome doit envoyer une demande DNS pour vérifier s'il peut s'agir d'un nom d'hôte à mot unique: par exemple, "test" peut être une recherche pour "test" ou une navigation vers " http: // test ". Si la requête finit par être un hôte, chrome affiche une barre d'informations qui demande "avez-vous signifie passer à "test" à la place ". Pour des raisons de performances, la requête DNS doit être asynchrone.
Maintenant, certains FAI ont commencé à diffuser des annonces pour des noms de domaine inexistants ( http://en.wikipedia.org/wiki/DNS_hijacking ), ce qui signifie Chrome montrerait toujours que infobar pour chaque requête sur un seul mot. Comme c'est ennuyeux, chrome envoie maintenant trois requêtes DNS aléatoires au démarrage, et si elles se résolvent toutes (sur la même IP, je pense), elle sait maintenant pour ne pas afficher la barre d'informations "vouliez-vous dire" pour les requêtes à mot unique qui se résolvent vers cette adresse IP.
Au-delà du niveau du FAI ou du DNS malveillant détournant l'entrée Wikipédia liée ci-dessus, certains points d'accès sans fil payants ou portails captifs détournent également le DNS. Les demandes aléatoires sont faites à des intervalles apparemment aléatoires, et pas seulement au démarrage de Chrome. Au moins, ils se produisent chaque fois que l'interface réseau actuelle obtient une nouvelle adresse IP.
Voici un autre lien lié au thème de @Gilles: inhabituel HEAD demandes d'URL non-sens de Chrome . Par conséquent, ajoutant à la question le sujet de la configuration du test de proxy. Vous finissez par voir les journaux de proxy car, lorsqu'un proxy est configuré, les demandes sont effectuées via le proxy; et, c'est au proxy de résoudre les demandes DNS.
En l'absence de détails plus solides en ligne, j'ai téléchargé et parcouru 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 de Chromium:
Étant donné que cette fonction peut être appelée au démarrage, lorsque le démarrage d'une récupération d'URL peut prendre jusqu'à 20 ms, nous retardons sept secondes, ce qui, espérons-le, est assez long pour être après le démarrage, mais nous obtenons toujours des résultats rapidement.
Ce composant envoie des requêtes à trois noms d'hôte générés de manière aléatoire et donc probablement inexistants. Si au moins deux redirections vers le même nom d'hôte, cela suggère que le FAI détourne NXDOMAIN, et l'omnibox devrait traiter les navigations redirigées similaires comme "échouées" lors de la décision d'inviter l'utilisateur avec un "avez-vous l'intention de naviguer" dans la barre d'informations pour certaines recherches contributions.
déclencheur: "Au démarrage et lorsque l'adresse IP de l'ordinateur change."
Nous générons un nom d'hôte aléatoire avec entre 7 et 15 caractères.
Ma conclusion est que ces noms de requête DNS aléatoires ne sont pas une manifestation du comportement d'un malware ; ce sont des sondes pour Chrome (et Google Chrome) pour savoir ce qu'il peut faire concernant au moins les recherches .
Faute de détails plus solides en ligne, j'ai téléchargé les sources de chrome dans mon enquête. La logique de cette fonctionnalité se trouve dans le fichier, src/chrome/browser/intranet_redirect_detector.cc et 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 à cas mixtes - Malware dans mon réseau? .
Légèrement lié: Pourquoi Chromium ne cache-t-il pas DNS pendant plus d'une minute?