Undetected Attacks on Anti-Malware Agents Using DNS Spoofing
Written by: Asaf Nadler
The article is based on a research project carried out by researchers from Akamai Technologies and Ben-Gurion University of the Negev, which was recently published as an academic paper in Elsevier’s Computers & Security journal.1
Akamai researchers in conjunction with researchers from Ben-Gurion University and Deutsche Telekom Innovation Labs Israel discovered a multifaceted DNS spoofing threat utilizing anti-malware technologies.
This threat was first discovered using the McAfee Endpoint Security Agent and was responsibly disclosed, resulting in a CVE and patch to remediate the threat.
This sophisticated attack can achieve both the alert fatigue that plagues security teams everywhere and allow attacks to propagate undetected.
Akamai analyzed the DNS traffic of more than 60 million users in over 30 countries during the month of November 2020, which led to the discovery that these services were used by 2.6 million endpoints and servers to perform more than 108 million file scans every day, thus putting these machines and their users at risk.
Thanks to significant adoption of HTTPS, DNS spoofing is not what it used to be. The idea of diverting traffic from legitimate servers toward fraudulent ones has lost its effectiveness, because users have become more aware. When researchers keep finding sophisticated means to perform DNS spoofing,2, 3 browsing users who observe the infamous red padlock icon in the address bar instantly become alerted and go back. Depending on the browser they’re using, they might even explicitly be warned that the page they’re attempting to reach is unsafe.
Although we’ve made significant progress as a community in this regard, there are still instances in which the outcome of DNS spoofing attacks can go undetected. In this article, we describe a DNS spoofing attack that goes unnoticed by users. The attack targets anti-malware agents, installed on endpoints and servers, causing them to misclassify malicious scanned files as benign files. In simple terms, an anti-malware solution designed to protect users against ransomware, for example, will just let the ransomware execute without the user being aware of it until it’s too late. This is just one example of how this can be used in the wild — and a very timely one, considering the prevalence of ransomware out there today.
DNS anti-malware lists
Before diving into the attack, let’s discuss DNS anti-malware list (DNSAML) services in general. DNSAML services are a specific form of DNS blocklists operated by security companies to provide their anti-malware agents with knowledge of recent threats. For instance, whenever a user downloads a suspected file from the internet, the installed anti-malware agent may query its DNSAML service to see whether that file is known to be malicious. If the DNSAML service response indicates that the file is malicious, then the agent can delete or quarantine the file, and alert the user.
Why would an agent need to query a DNSAML service? All of us have been presenting in a meeting when our anti-malware agent says it needs to be updated. What do we do? Often we opt to postpone the update, sometimes until our machine forces a restart. Vendors know this, so when our agent comes across a suspicious file that isn’t matched against its local database of threats, it needs to query the most up-to-date threat database: the DNSAML service.
And as you would have guessed by the name, the query made by the agent to the DNSAML service takes place over the DNS protocol, not the encrypted DNS-over-HTTPS or DNS-over-TLS. The query is made to the plain-text, insecure DNS protocol, which is susceptible to DNS spoofing attacks as mentioned above.
A file comes in that looks suspicious, but there’s no signature known locally, so the malware agent queries the DNSAML. What does that query actually look like?
The query is typically composed of a string that uniquely identifies the file; i.e., a signature. The response is frequently an action code instructing the agent what to do with the file. There are action codes associated with legitimate actions (e.g., allow execution) and others with malicious actions (e.g., delete or quarantine).
Since the query-response interaction between the agent and the DNSAML services take place over the DNS protocol, the query is a DNS query that includes a fully qualified domain name with the signature. The response is a DNS response with an IPv4 address that encodes the action code. The interaction between the agent and the DNSAML is demonstrated in the figure below through an example in which a user downloads a file (1), and the agent sends its signature (2-4) to the DNSAML service, which responds (5) so the agent can take action (6).
The attack builds on existing DNS spoofing attacks to alter the action code within the response from the DNSAML service to the agent. The action code is altered in order to instruct the agent to take the action opposite to the one suggested by the DNSAML service.
When the original scanned file is malicious and the attack is used to convey to the agent that it’s benign, it’s referred to as a silencing attack. The silencing attack is beneficial for attackers who seek to deliver malware while going unnoticed by the anti-malware agent. The silencing attack is depicted in the figure below through an example in which the attacker alters the response of the McAfee ESTP agent for Windows to “trick” the agent into misclassifying the malicious file as benign.
The opposite of the silencing attack is the false alert attack, in which benign files will be incorrectly identified as malicious. The false alert attack is beneficial for attackers who seek to drive victims to a state of alert fatigue causing them to turn off or replace their anti-malware protection.
The video below demonstrates the silencing attack when carried out on the McAfee Endpoint Security for Windows agent. The attack was responsibly disclosed to McAfee, who issued a CVE report, and released a new version in which plain-text DNS is no longer used, thus preventing the attack.
The impact of the attack
Every anti-malware agent that uses plain-text DNS to query a DNSAML service is potentially vulnerable. To evaluate the number of such agents worldwide, we analyzed the DNS traffic of more than 60 million users in over 30 countries during the month of November 2020.
In the evaluation, we identified DNSAML services by looking for DNS queries that contain hash signatures and a large volume of traffic4 to domains registered by security companies. Overall, we found 55 DNSAML services operated by McAfee, Sophos, ESET, Symantec, Tenable, Team Cymru, etc. These services were used by 2.6 million endpoints and servers to perform more than 108 million file scans every day, thus putting these machines and their users at risk.
The results of the evaluation were significantly higher than what we anticipated. The 55 services, 2.6 million susceptible machines, and 108 million file scans daily do not correspond with the fact that the concept of DNS blocklists — which was established in 1998, long before DNS spoofing attacks were established — is outdated. Additionally, original DNS blocklists were typically used to block spamming IP addresses, so no one anticipated their use for file scanning by notable security companies, and certainly not at this scale.
At the time of writing, we are not aware of this attack ever being launched “in the wild.” This is likely due to a combination of reasons, including the high complexity of the attack as it requires DNS spoofing and our responsible disclosure. Following the disclosure, some of the services either stopped operating on plain-text DNS (e.g., McAfee) or carried out other steps to dramatically reduce the number of potential victims. Unfortunately, though, plain-text DNS is still used by anti-malware agents for the sake of file classification.
Conclusions and recommendations
As mentioned in the introduction, although DNS spoofing attacks still exist, they are not nearly as newsworthy as they used to be because they are seemingly less of a threat than the myriad other threats present since the wide adoption of DNS and HTTPS. However, as you can see in this article, DNS spoofing attacks are still possible to do (and can go undetected) even with the proper protocols in place. DNS spoofing is especially still effective in non-browsing activities, in which decisions are being made based on DNS queries, without the awareness of the user, thus allowing DNS spoofing attackers to operate silently and effectively. The recommendation is well-known, but must still be emphasized: Plain-text DNS is insecure, and any application, including anti-malware solutions, must not use it to make decisions.
As we saw in our recent article about the analysis of the Conti ransomware gang’s TTPs, just because a remediation recommendation is known doesn’t make it trivial. Just because something is simple doesn’t mean it’s not effective, as is showcased in this post. The recommendation is as simple as it gets, and yet could deter a sophisticated attack. All applications, including anti-malware, must avoid decision-making based on the insecure plain-text DNS. Alternatives to plain-text DNS include DNS-over-HTTPS and DNS-over-TLS, and in the case of signature lookups, REST APIs over HTTPS might be just as good.
1. Nadler, Asaf, Ron Bitton, Oleg Brodt, and Asaf Shabtai. "On the Vulnerability of Anti-Malware Solutions to DNS Attacks." Computers & Security 116 (2022):102687.
2. Man, Keyu, Zhiyun Qian, Zhongjie Wang, Xiaofeng Zheng, Youjun Huang, and Haixin Duan. "DNS cache poisoning attack reloaded: Revolutions with side channels." CCS ‘20: Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security (October 2020): 1337-1350.
3. Klein, Amit. "Cross layer attacks and how to use them (for DNS cache poisoning, device tracking and more)." 2021 IEEE Symposium on Security and Privacy (SP). (2021). https://doi.org/10.48550/arXiv.2012.07432
4. Nadler, Asaf, Avi Aminov, and Asaf Shabtai. "Detection of malicious and low throughput data exfiltration over the DNS protocol." Computers & Security 80 (2019): 36-53.