DNS Rebinding Attacks and NIDS

by James E. Gilbert

UMUC

November 10, 2012

Abstract

Although DNS Rebinding and Network Intrusion differ, both topics are similar in that they illustrate the need for cooperative efforts within the field of cybersecurity.  Successful defense against DNS rebinding attacks not only requires organizations that create active content to correct deficiencies in their programs, but also entails individual users enacting a variety of personal defensive measures.  Similarly, creating an effective network intrusion detection system necessitates a robust community that constantly adds to the library of known network threats.  Without this cooperation and involvement, defense against cyber attacks becomes myopic and increasingly less effective against ever-evolving threats.

Introduction

The following paper presents two articles discussing DNS rebinding attacks and Network Intrusion Detection System (NIDS), respectively.  DNS rebinding attacks threaten one of the core security concepts of internet browsers, the policy of same-origin.  Correctly executed, this attack can circumvent firewalls and hijack IP addresses.  The article by Jackson et al. (2009) outlines the topic’s vulnerabilities and countermeasures.  The authors also present relative strengths and weaknesses of the defensive measures, areas for improvement, an assessment and related works. 

The second article details how signature matching NIDS work and methods for refining the use of this mechanism.  Correctly implemented, NIDS provide an invaluable tool for system administrators to detect unauthorized network traffic.   In their article, Sommer and Paxson (2003) discuss how adding contextual signatures to a flexible platform like NIDS increases the efficiency of the system.  The authors discuss the mechanism’s contributions and limitations, areas for enhancement, testing of the system and related works.

Article 1 Citation

Jackson, C., Barth, A., Bortz, A., Shao, W., & Boneh, D. (2009). Protecting browsers from DNS rebinding attacks. In Proc. of the 14th ACM Conference on Computer and Communication Security (CCS), 2-2-26. New York, NY. doi:10.1145/1462148.1462150

Summary

One of the most important security principles employed by modern internet browsers is the concept of “same-origin.”  This principle separates honest from dishonest websites by “isolating content from distinct origins” (Jackson et al., 2009, p. 2-2).  This isolation provides a measure of trust for both individual users visiting web sites and organizations that allow active content through their firewalls.  A significant threat to this core security measure however, is DNS rebinding.  This cyberattack provides malicious individuals the ability to circumvent firewalls and hijack individual IP addresses.  The DNS rebinding attack is able to accomplish this through a weakening of the same-origin principle.  According to Jackson et al. (2009), DNS rebinding takes place when an attacker registers a domain name.  The name is delegated to a controlled DNS server with a short time-to-live (TTL).  When a victim views the fabricated site, the originating HTTP request is pointed toward a site containing malicious active content.  This establishes a connection that “rebinds” the malicious server to the target’s browser.  The separation between entities is subverted, leaving a single, compromised security origin.  This eventually leads to network vulnerabilities that allow for stolen information and pay-per-click advertising fraud.  The following paper summarizes an article by Jackson et al. that demonstrates not only what vulnerabilities exist from DNS rebinding, but also examples of attacks and recommended countermeasures (2009). 

Vulnerabilities and Attacks

Rebinding vulnerabilities generally fall into two major categories: standard and multipin.  Standard rebinding “uses a single browser technology (e.g., JavaScript, Java, or Flash Player) to connect to multiple IP addresses with the same host name” (Jackson et al., 2009, p. 2:7).  Examples of this variation include multiple A records, time-varying DNS, and pinning in current browsers.  Multipin rebinding on the other hand, use multiple plug-ins to try and rebind the target browser to the attacker’s server.  Because plug-ins “…restrict socket access based on the origin of the content opening the connection”, the attacker employs numerous plug-ins to “…pin the attacker’s host name to the same IP address” (Jackson et al., 2009, p. 2:8).  Instances of multipin rebinding vulnerabilities include a number of variations inherent to Java and Flash Player.

DNS rebinding attacks can also be categorized in two main areas: firewall circumvention and IP hijacking.  In the first instance, if the target is located behind a firewall then the attacker gains access to protected data once the connection is established.  For IP hijacking, DNS rebinding provides the attacker with use of the target’s IP address.  Often the intent of this attack is to control the host IP in order to send spam or defraud pay-per-click (PPC) advertisers.

Defense (Contributions and Strengths)

Until recently, the primary defense against DNS rebinding attacks was “DNS pinning.”  Pinning involves routing all network connections from a specific host to the same IP address.  This technique helps enforce the separation between malicious content and authentic server traffic.  Unfortunately as a result of browser plug-ins and the vulnerabilities they represent, pinning is no longer effective.  To defend against these newest vulnerabilities, Jackson et al. recommend changes to three mechanisms: plug-ins, firewalls, and servers.  Depending on the active content, plug-ins either defaults to allow (Java) or deny (Flash Player) socket-level access.  The inclusion of additional policy checks provides a secondary line of defense against DNS rebinding attacks independent of the browser operations.  Firewalls can be employed to defend against this threat because the mechanism prevents “…external host names from resolving to internal IP addresses” (Jackson et al., 2009, p. 2:20).  Three variations that can be employed for this defense include enterprise, consumer and software firewalls.  Lastly, individuals and organizations can defend against DNS rebinding attacks with Host Header checking as HTTP requires a host header that corresponds to the server name. 

Pinning Pitfalls (Weaknesses and Limitations)

One of the major limitations that arise from defense against DNS rebinding attacks are the nuances inherent to correct execution of DNS pinning.  Two of these subtle variations include common pin database and cache.  With the common pin database, defending against a multipin attacks requires browser technologies sharing a common pin database.  This in turn necessitates exposing the pin database to an interface; a decision browser vendors are reluctant to do because of the difficulty involved.  The other major weakness with pinning defenses involves the browser’s cache.  Requiring objects in the cache to be retrieved by both the URL and IP address, ensures additional security but also degrades system performance.

Smarter Pinning (Possible Improvements)

As with most security considerations, DNS pinning trades availability for security.  This does not have to be the case with regards to DNS defenses.  Often times, pinning necessitates a shorter TTL to provide for more robust server operation.  While this boosts the availability of the system, it also increases the chance for a DNS rebinding attack.  To maintain a high degree of protection without performance degradation, Jackson et al. recommends varying alternate parameters within the pinning policy (2009).  Examples of this include pin width and other variations of width heuristics.

Evaluation

Jackson et al. demonstrated the severity of this type of attack with a proof-of-concept experiment.  The test consisted of applying various DNS rebinding exploits using Flash Player, Live Connect and Java.  The purpose of the assessment was to measure the cost and effort of employing multipin attacks against a network.  The results showed that vulnerabilities from DNS rebinding attacks are widespread and inexpensive.  Almost 90% of browsers were found to be vulnerable to this type of cyber threat.  The outcome from the experiment showed that an attacker employing this technique can hijack 100,000 IP addresses for less than $100 (Jackson et al., 2009, p. 2:3, p), with a 54% success rate (Jackson et al., 2009, p. 2:14).

Related Works
In Week 4, CSEC 640 reviewed topics related to TCP/IP Vulnerabilities.  One of the articles recommended was entitled “Security Vulnerabilities in DNS and DNSSEC” (Ariyapperuma & Mitchell, 2007).  The article was significant in that it also discussed the security issues related to DNS and showed the gaps in security from employing individual countermeasures versus multilayered security.  Authentication and integrity were major concerns as DNS was found to be susceptible to cache poisoning and man-in-the-middle attacks.  The article was relevant to the findings presented by Jackson et al. in that it introduced DNSSEC as a potential solution to DNS’s security flaws.  Ariyapperuma and Mitchell identify this secure DNS protocol as a means to address the data integrity and source spoofing concerns but go on to discuss a host of flaws inherent to DNSSEC.  Among these include limited protection against buffer overruns, DDoS attacks and the risk of compromise to the cryptographic keys.  Similar to DNS pinning, DNSSEC also requires particular settings for the TTL to be effective.  Configured correctly, DNSSEC is an adequate protection for integrity and authentication issues and is able to detect name based authentication attacks.  By examining another means of defending DNS vulnerabilities and the corresponding pitfalls, Ariyapperuma & Mitchell’s article was instrumental in seeing the need for a defense-in-depth strategy for protecting DNS. 

Conclusion

DNS rebinding was first seen over 10 years ago.  The attack is so popular because of the level of access it provides to a target’s host as well as the relatively low cost it requires to carry out.  Pinning provided an initial countermeasure for the threat, but increased functionality in the form of plug-ins and “intratechnology communication” rendered this defense mechanism inadequate.  Accordingly, Jackson et al. have recommended a number of additional security measures in the form of policy changes to active content programs such as Flash Player and Java, as well as network countermeasures related to firewalls, plug-ins, and servers.  According to the authors, their suggestions to the makers of Flash Player and Java have been met with positive results and patches have been created and distributed.  Unfortunately user recommendations have been met with limited success as some of the individual countermeasures have been known to degrade system performance.  As malicious users continue to reinvent the decade old DNS rebinding attack to circumvent modern countermeasures, additional work is needed to protect critical network infrastructure.  If individual organizations are unwilling or unable to accomplish this task, will the function default to the government to direct or finance the defense of the Internet?

Article 2 Citation

Sommer, R. & Paxson, V. (2003). Enhancing byte-level network intrusion detection signatures with context. In Proc. of the 10th ACM Conference on Computer and Communications Security (CCS), 262-271. New York, NY. doi:10.1145/948109.948145

Summary

Intrusion Detection Systems (IDS) generally fall into two categories: Anomaly-based and Misuse detection.  Anomaly-based IDSs employ a system baseline to detect any variances from the norm.  Misuse detection on the other hand looks for specific attack indicators.  This type of mechanism includes host-based IDSs (HIDS) and network-based IDSs (NIDS) to inspect system logs and network traffic.  One of the more popular variations of misuse detection uses signature matching to look for cyber threats.  Attack patterns are established and automatically referenced by software and hardware mechanisms. This technique is widely accepted for its simplicity, its precision, and the strength derived from a large community of contributors.  System administrators are more familiar with this concept having used the widely available open-source IDSs, Snort and Bro.  The following paper summarizes an article by Sommer and Paxson which compares the strengths and weaknesses of Bro in comparison to another system; in this case Snort.  Improvements for the system are assessed as well as additional works related to the system.

Contributions and Strengths

Signature-matching systems are widely used due to their relative strengths: simplicity, precision, and being open-sourced.  By isolating what patterns represent threats, a relatively simple program can efficiently locate these signatures and alert to their presence.  Next, signature-matching enables exact patterns to be written in order to identify nuanced system threats.  Finally, as new threats emerge, having a large community of users contributing to a signature library harnesses the combined strength of many individuals.  The strength from Bro’s network analysis is that it is “policy-neutral.”  The mechanism does not interpret an event as good or bad; rather, Bro simply matches incoming activity to its collection of signatures.  Positively identified correlations execute previously established scripts to define which responses are carried out.  This flexibility provides Bro with a unique advantage over other IDSs in that it can incorporate components and libraries from other software.

Weaknesses and Limitations

Although powerful and widely-accepted, signature-matching does possess a significant limitation.  Only established attacks with corresponding signatures can be detected by this type of IDS.  In addition only very detailed signatures will catch attacks.  Loose signatures run the risk of returning a significant amount of false positives.  This problem can be overcome if the matcher is provided with additional information about potential attacks.  Bro also possesses some limitations as a result of its configuration.  Signature-matching on large sets of patterns can be cumbersome “…because each signature has to be coded as part of a script function” (Sommer & Paxson, 2003, p. 263).  In addition, although Bro represents a highly flexible IDS, Snort possesses a larger collection of signatures.  To leverage the relative strengths of both programs, Sommer and Paxson recommend integrating Snort’s set into Bro’s more flexible architecture through a conversion program (2003). 

Possible Improvements

Previously identified, a potential weakness inherent to signature-matching is the lack of additional context.  To correct this deficiency, Sommer and Paxson incorporate the concept of contextual signatures into Bro.  Traditional NIDS signature-matching is enhanced by adding “full regular expressions instead of fixed strings” and “giving the signature engine a notion of full connection state” (Sommer & Paxson, 2003, p. 263).  Regular expressions increases versatility by allowing for additional “…syntactic context with which to sharpen textual searches (Sommer & Paxson, 2003, p. 264).  In the following experiments Sommer and Paxson enhanced Bro with contextual signatures through a corresponding Python script.  This program converted Snort configurations into syntax compatible with Bro.

Evaluation

To assess the effectiveness of their recommendations, Sommer and Paxson ran Snort and Bro against traces collected from two separate networks.  The test sought to evaluate the two IDSs in terms of run-time performance and alerts generated.  Although a significant amount of data for the test was recorded, determining exact statistics between Snort and Bro was problematic for a number of reasons.  Comparing two NIDS presents issues in terms of assessing pattern recognition and performance.  Internal semantics and differences in reported data from each system makes direct assessment less than straightforward.  The ultimate conclusion was that the enhanced version of Bro achieved a number of improvements over Snort in terms of quality alerts identified.  Sommer and Paxson concluded this outcome was achieved with a flexible platform like Bro building upon Snort’s established signature library.

Related Works

Sommer and Paxson’s bibliography lists a number of additional articles which should be referenced for further research.  Two DARPA articles written by Lippmann et al. (1999, 2000) are described as being “comprehensive evaluations” of this system.  The authors discuss in their “Related Work” section other types of NIDS that build upon Snort rules.  For alternatives or enhancements to Snort and Bro, Debar and Morin (2002) assess several other types of commercial IDSs.

Conclusion

Sommer and Paxson’s research shows the value of signature-based detection with added context.  If the intent is to accurately identify threats while decreasing the potential for false alarms, additional threat information becomes a necessity.  Contextual signatures excel at this requirement using regular expressions rather than fixed strings.  To employ this technique effectively however, a flexible IDS platform like Bro is required.  The major limitation with Bro is that the system lacks the sizable database maintained by the more-widely used Snort IDS.  Bro’s adaptability was again a significant asset as the authors were able to import Snort’s signature library into Bro.  This resulted in a more robust network intrusion detector.  Additional articles cited by Sommer and Paxson show a number of other researchers with similar goals: using Snort to enhance a more robust and efficient IDS.  It would seem that as long as Snort remains open-source, security professionals can continue to adapt their extensive library.  The question remains, how long will Snort’s pervasiveness in the field exist in the face of more effective security solutions?

References

Ariyapperuma, S. & Mitchell, C. J. (2007). Security vulnerabilities in DNS and DNSSEC.

In Proc. of the Second International Conference on Availability, Reliability and Security, 335-342. Washington, DC. doi:10.1109/ARES.2007.139

Debar, H. & Morin, B. (2002). Evaluation of the diagnostic capabilities of commercial intrusion

detection systems. In Proc. Recent Advances in Intrusion Detection, number 2516 in Lecture Notes in Computer Science. Springer-Verlag.

Jackson, C., Barth, A., Bortz, A., Shao, W., & Boneh, D. (2009). Protecting browsers

from DNS rebinding attacks. In Proc. of the 14th ACM Conference on Computer and Communication Security (CCS), 2-2-26. New York, NY. doi:10.1145/1462148.1462150

Lippmann, R., Cunningham, R. K., Fried, D. J., Graf, I., Kendall, K. R., Webster, S. E. and

Zissman, M. A. (1999). Results of the 1998 DARPA offline intrusion detection evaluation. In Proc. Recent Advances in Intrusion Detection.

Lippmann, R., Haines, J.W., Fried, D. J., Korba, J. & Das, K. (2000). The 1999 DARPA off-

line intrusion detection evaluation. Computer Networks, 34(4):579–595.

Sommer, R. (2003). Bro: An open source network intrusion detection system. In Proc. of

DFN-Arbeitstagung über Kommunikationsnetze, 1-17. Stuttgart, Germany. Retrieved from: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.60.5410&rep=rep1&type=pdf

Sommer, R. & Paxson, V. (2003). Enhancing byte-level network intrusion detection

signatures with context. In Proc. of the 10th ACM Conference on Computer and Communications Security (CCS), 262-271. New York, NY. doi:10.1145/948109.948145