Attacks/Breaches

Client-Side DNS Attack Emerges From Academic Research

A new DNS cache poisoning attack is developed as part of the research toward a dissertation.

The rise of speculative execution side-channel vulnerabilities is having an interesting side effect: More researchers from academia are finding their names in CVEs and bounty notices, and, in turn, those from the security business side are finding themselves collaborating more with those academics. 

A recent DNS cache-poisoning attack that exploits a vulnerability found in mDNSResponder, a component used in name resolution in a variety of operating systems, illustrates one of the ways in which academic research is having an impact on commercial computing on a far faster cycle than the years typically associated with research and publication at universities.

A team of researchers, led by Ph.D. candidate Fatemah Alharbi, at the University of California, Riverside, discovered the attack as part of Alharbi's doctoral research. "We found that the client-side DNS cache poisoning attack has never been technically and practically studied before; thus, I decided to choose this project as my first project in my PhD study," Alharbi told Dark Reading in an email interview.

Alharbi's group began to research the possible attack on Android and Ubuntu Linux. Once they demonstrated a successful attack, they moved on to see whether the same vulnerability existed for MacOS and Windows.

"As expected, we found the needed vulnerability to launch the attack and succeeded in poisoning the DNS cache of these two operating systems as well," she said. "[As a result], one of the machine users can launch the attack and poisons the DNS cache (without any root or admin privileges) with a malicious DNS mapping. Since there is no complete isolation between users, another user (even the admin) visiting the same domain will end up visiting the webserver that is controlled by the attacker instead of the legitimate webserver."

The attack itself takes advantage of the fact that the OS DNS cache used by mDNSResponder is shared among all the users of a given machine — and that cache is generally without explicit protection. "Client devices are typically not considered to be part of the DNS hierarchy and therefore have not been considered by defenses against DNS cache poisoning," Alharbi said.

The research team disclosed the attack to the vendors and was recognized by Apple in the security notes for macOS Mojave 10.14.3, Security Update 2019-001 High Sierra, and Security Update 2019-001 Sierra. Aside from the mitigation that may come through operating system updates, there are few good options available on the client system.

"One easy and fast solution is to disable the DNS cache," Alharbi said. "The downside about this is that the client has to wait for the DNS response after the DNS resolution process is complete for each DNS query she sends."

Another downside, she noted, is that the dependence entirely on the DNS server (and the additional traffic that represents) could make the DNS resolver more vulnerable to DDoS attacks.

The paper describing the attack and potential remediation will be published in the proceedings of IEEE International Conference on Computer Communications (INFOCOM) 2019, in Paris this May.

 

 

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

Related Content:

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
High Stress Levels Impacting CISOs Physically, Mentally
Jai Vijayan, Freelance writer,  2/14/2019
Valentine's Emails Laced with Gandcrab Ransomware
Kelly Sheridan, Staff Editor, Dark Reading,  2/14/2019
Making the Case for a Cybersecurity Moon Shot
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  2/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-8980
PUBLISHED: 2019-02-21
A memory leak in the kernel_read_file function in fs/exec.c in the Linux kernel through 4.20.11 allows attackers to cause a denial of service (memory consumption) by triggering vfs_read failures.
CVE-2019-8979
PUBLISHED: 2019-02-21
Koseven through 3.3.9, and Kohana through 3.3.6, has SQL Injection when the order_by() parameter can be controlled.
CVE-2013-7469
PUBLISHED: 2019-02-21
Seafile through 6.2.11 always uses the same Initialization Vector (IV) with Cipher Block Chaining (CBC) Mode to encrypt private data, making it easier to conduct chosen-plaintext attacks or dictionary attacks.
CVE-2018-20146
PUBLISHED: 2019-02-21
An issue was discovered in Liquidware ProfileUnity before 6.8.0 with Liquidware FlexApp before 6.8.0. A local user could obtain administrator rights, as demonstrated by use of PowerShell.
CVE-2019-5727
PUBLISHED: 2019-02-21
Splunk Web in Splunk Enterprise 6.5.x before 6.5.5, 6.4.x before 6.4.9, 6.3.x before 6.3.12, 6.2.x before 6.2.14, 6.1.x before 6.1.14, and 6.0.x before 6.0.15 and Splunk Light before 6.6.0 has Persistent XSS, aka SPL-138827.