Отравление DNS-кэша: атаки и последствия

Введение

Кибератака с использованием скомпрометированных данных DNS

DNS-спуфинг, также известный как отравление кэша DNS, — это вид компьютерного взлома, при котором в кэш DNS-резольвера вводятся скомпрометированные данные системы доменных имен, что приводит к возврату сервером имен неверной записи, например, IP-адреса. В результате трафик перенаправляется на любой компьютер, выбранный злоумышленником.

Обзор системы доменных имен

Сервер системы доменных имен (DNS) преобразует удобочитаемое доменное имя (например, example.com) в числовой IP-адрес, который используется для маршрутизации коммуникаций между узлами. Как правило, если сервер не знает запрошенный адрес, он обращается к другому серверу, и этот процесс продолжается рекурсивно. Для повышения производительности сервер обычно запоминает (кеширует) эти преобразования на определенное время. Это означает, что при получении повторного запроса на то же преобразование он может ответить, не обращаясь к другим серверам, пока не истечет срок действия кэша. Если DNS-сервер получил неверное преобразование и кэшировал его для оптимизации производительности, он считается скомпрометированным и предоставляет ложные данные клиентам. В случае компрометации DNS-сервера он может возвращать неверный IP-адрес, перенаправляя трафик на другой компьютер (часто принадлежащий злоумышленнику).

Атаки с использованием кэша

Обычно компьютер, подключенный к сети, использует DNS-сервер, предоставляемый интернет-провайдером (ISP) или организацией пользователя. DNS-серверы используются в сети организации для повышения производительности разрешения имен путем кэширования ранее полученных результатов запросов. Атаки отравления DNS-сервера могут затронуть пользователей, обслуживаемых непосредственно скомпрометированным сервером, или тех, кто обслуживается косвенно через его нижестоящие серверы, если таковые имеются. Для проведения атаки с отравлением кэша злоумышленник использует уязвимости в программном обеспечении DNS. Сервер должен корректно проверять ответы DNS, чтобы убедиться в их подлинности (например, с помощью DNSSEC); в противном случае сервер может кэшировать неверные записи локально и предоставлять их другим пользователям, делающим аналогичные запросы. Эта атака может быть использована для перенаправления пользователей с легитимного веб-сайта на сайт, выбранный злоумышленником. Например, злоумышленник подменяет IP-адреса DNS-записей целевого веб-сайта на заданном DNS-сервере, заменяя их IP-адресом сервера, находящегося под его контролем. Затем злоумышленник создает на контролируемом сервере файлы с именами, соответствующими файлам на целевом сервере. Эти файлы обычно содержат вредоносный код, такой как компьютерные черви или вирусы. Пользователь, чей компьютер обращается к отравленному DNS-серверу, обманом заставляет себя принять контент с неавторизованного сервера и непреднамеренно загружает вредоносный код. Этот метод также может использоваться для фишинговых атак, когда создается поддельная версия легитимного веб-сайта для сбора личной информации, такой как банковские и данные кредитных/дебетовых карт. Уязвимость систем к отравлению кэша DNS выходит за рамки его непосредственных последствий, поскольку она подвергает пользователей дополнительным рискам, таким как фишинг, внедрение вредоносного ПО, отказ в обслуживании и угон веб-сайтов из-за уязвимостей системы. Различные методы, от использования тактик социальной инженерии до эксплуатации слабостей в программном обеспечении DNS-сервера, могут привести к этим атакам.

Normally, a networked computer uses a DNS server provided by an Internet service provider (ISP) or the computer user's organization. DNS servers are used in an organization's network to improve resolution response performance by caching previously obtained query results. Poisoning attacks on a single DNS server can affect the users serviced directly by the compromised server or those serviced indirectly by its downstream server(s) if applicable. To perform a cache poisoning attack, the attacker exploits flaws in the DNS software. A server should correctly validate DNS responses to ensure that they are from an authoritative source (for example by using DNSSEC); otherwise the server might end up caching the incorrect entries locally and serve them to other users that make the same request. This attack can be used to redirect users from a website to another site of the attacker's choosing. For example, an attacker spoofs the IP address DNS entries for a target website on a given DNS server and replaces them with the IP address of a server under their control. The attacker then creates files on the server under their control with names matching those on the target server. These files usually contain malicious content, such as computer worms or viruses. A user whose computer has referenced the poisoned DNS server gets tricked into accepting content coming from a non authentic server and unknowingly downloads the malicious content. This technique can also be used for phishing attacks, where a fake version of a genuine website is created to gather personal details such as bank and credit/debit card details. The vulnerability of systems to DNS cache poisoning goes beyond its immediate effects as it can open users up to further risks such as phishing, malware injections, denial of service, and website hijacking due to system vulnerabilities. Various methods, ranging from the use of social engineering tactics to the exploitation of weaknesses present in the DNS server software, can lead to these attacks.

Варианты

В следующих вариантах записи для сервера будут скомпрометированы и перенаправлены на сервер имен злоумышленника по IP-адресу. Эти атаки предполагают, что сервер имен для [имя домена] является...
Для осуществления этих атак злоумышленник должен заставить целевой DNS-сервер сделать запрос к домену, контролируемому одним из серверов имен злоумышленника.

Профилактика и смягчение последствий

Многие атаки на DNS-серверы могут быть предотвращены, если меньше доверять информации, передаваемой им другими DNS-серверами, и игнорировать любые DNS-записи, возвращаемые в ответ, которые не имеют прямого отношения к запросу. Например, версии BIND 9.5.0 P1 и выше выполняют эти проверки. Рандомизация исходного порта для DNS-запросов в сочетании с использованием криптографически безопасных случайных чисел для выбора как исходного порта, так и 16-битной криптографической нонсы может значительно снизить вероятность успешных атак типа «гонка» на DNS. Однако, когда маршрутизаторы, брандмауэры, прокси и другие шлюзовые устройства выполняют преобразование сетевых адресов (NAT) или, более конкретно, преобразование адресов портов (PAT), они могут переписывать исходные порты для отслеживания состояния соединения. При изменении исходных портов устройства PAT могут удалять случайность исходного порта, реализованную серверами имен и усеченными решателями. Secure DNS (DNSSEC) использует криптографические цифровые подписи, подписанные доверенным открытым ключом, для определения подлинности данных. DNSSEC может противодействовать атакам отравления кэша. В 2010 году DNSSEC был реализован в серверах корневой зоны Интернета, но его также необходимо развернуть на всех серверах доменов верхнего уровня. Готовность этих серверов к DNSSEC показана в списке доменов верхнего уровня Интернета. По состоянию на 2020 год все оригинальные TLD поддерживают DNSSEC, как и TLD с кодом страны большинства крупных стран, но многие TLD с кодом страны все еще не поддерживают его. Этот тип атаки может быть смягчен на транспортном или прикладном уровне путем выполнения сквозной проверки после установления соединения. Распространенным примером этого является использование безопасности транспортного уровня и цифровых подписей. Например, используя HTTPS (защищенную версию HTTP), пользователи могут проверить, является ли цифровой сертификат сервера действительным и принадлежит ли он ожидаемому владельцу веб-сайта. Аналогично, программа удаленного входа в систему с защищенной оболочкой проверяет цифровые сертификаты на конечных точках (если они известны) перед началом сеанса. Для приложений, которые автоматически загружают обновления, приложение может встраивать копию сертификата подписи локально и проверять подпись, хранящуюся в обновлении программного обеспечения, по отношению к встроенному сертификату.

Many cache poisoning attacks against DNS servers can be prevented by being less trusting of the information passed to them by other DNS servers, and ignoring any DNS records passed back that are not directly relevant to the query. For example, versions of BIND 9.5.0 P1 and above perform these checks. Source port randomization for DNS requests, combined with the use of cryptographically secure random numbers for selecting both the source port and the 16 bit cryptographic nonce, can greatly reduce the probability of successful DNS race attacks. However, when routers, firewalls, proxies, and other gateway devices perform network address translation (NAT), or more specifically, port address translation (PAT), they may rewrite source ports in order to track connection state. When modifying source ports, PAT devices may remove source port randomness implemented by nameservers and stub resolvers. Secure DNS (DNSSEC) uses cryptographic digital signatures signed with a trusted public key certificate to determine the authenticity of data. DNSSEC can counter cache poisoning attacks. In 2010 DNSSEC was implemented in the Internet root zone servers., but needs to be deployed on all top level domain servers as well. The DNSSEC readiness of these is shown in the list of Internet top level domains. As of 2020, all of the original TLDs support DNSSEC, as do country code TLDs of most large countries, but many country code TLDs still do not. This kind of attack can be mitigated at the transport layer or application layer by performing end to end validation once a connection is established. A common example of this is the use of Transport Layer Security and digital signatures. For example, by using HTTPS (the secure version of HTTP), users may check whether the server's digital certificate is valid and belongs to a website's expected owner. Similarly, the secure shell remote login program checks digital certificates at endpoints (if known) before proceeding with the session. For applications that download updates automatically, the application can embed a copy of the signing certificate locally and validate the signature stored in the software update against the embedded certificate.