We also found vulnerability in cryptographic material among the signed domains, which allows to subvert the security of the DNSSEC signatures, hence exposing the affected domains to attacks. The vulnerabilities are introduced by the registrars and DNS hosting providers which deploy DNSSEC incorrectly. The vulnerabilities are found in domains of popular and large registrars such as Network Solutions and GoDaddy.
The measurement results indicate that the majority of signed domains do not gain security benefits by adopting cryptographic defences. Incorrect adoption of cryptographic protection generates an illusion of security causing the domain owners to believe that their clients are protected hence do not deploy additional measures to guarantee security.
We recently developed and set up an automated tool, [15], to measure and report progress in DNSSEC adoption and to evaluate misconfigurations and incorrect adoptions that lead to insecurity, https://dnssec.cad.sit.fraunhofer.de. Our online service allows to check which domains are vulnerable, and to obtain statistics for the status of domains overall.
81.2.2 Border Gateway Protocol (BGP)
The Border Gateway Protocol (BGP) computes routes between the tens of thousands of smaller networks, called Autonomous Systems (ASes), which make up the Internet. ASes range from large ISPs and content providers to small businesses and universities. In essence, BGP computes the routes that packets should take between a source and any destination in the Internet.
BGP Prefix Hijacks
BGP does not have any security integrated into it, hence is vulnerable to traffic hijacks whereby an attacking AS is able to divert traffic through an incorrect route, which typically includes attacker controlled links. This is done by advertising a prefix which the attacking AS does not own. This allows attackers to attract traffic not destined to them, and exposes the traffic to eavesdropping, censorship, distribution of malware and more. Indeed, BGP has a history of devastating attacks and configuration errors. Consequently, nation states and corporations are in constant danger from attacks that utilize BGP’s insecurity to disconnect ASes from the Internet and to launch highly effective man‐in‐the‐middle attacks.
Prefix hijacks are effective and easy to launch, with the extra benefit of a plausible excuse: benign configuration errors [17]. Every year there are thousands of prefix hijacks, some due to misconfigurations, while others are attacks [18–20], and many others go under the radar [21]. See for instance a recent hijacking event (Fig. 81.3) which allowed attackers to eavesdrop on traffic over a long period of time without being detected.
Fig. 81.3Traffic hijacking event illustrated by Renesys
In this attack, the traffic was exchanged between end points in Mexico and the US. The traffic was hijacked by an attacker ISP in Eastern Europe. To avoid detection, the attackers were rerouting the traffic back to the destination. This allowed the attack to go undetected for over half a year.
BGP Security
Today’s agenda for securing BGP routing relies on Route‐origin validation (ROV) [RFC6483, RFC6811] via the Resource Public Key Infrastructure (RPKI) [RFC6480], to protect against prefix hijacks.
RPKI deployment is still very limited and, as a result, prefix and subprefix hijacking remain highly successful. Indeed, to the present date only about 6% of IP prefixes in BGP tables are certified [22].
RPKI certificates bind an IP‐prefix with the number and public key of its origin AS, i. e., the AS that “owns” that prefix. The prefix owner can then use its RPKI private key to sign a Route Origin Authorization (ROA) specifying which ASes are allowed to advertise in BGP that IP prefix (or its subprefixes). BGP routers can then utilize the information in that ROA to do route‐origin validation (ROV), i. e., reject BGP announcements specifying unauthorized origin ASes for that prefix.
In a recent work we found that only a small number of ASes apply ROV [23]. Worse, a large fraction of signed prefixes are misconfigured [24, 25], further demotivating the adoption of ROV. Fig. 81.4 presents the results of measurement of the status of ROAs available in the January 2016 RPKI database, and the corresponding BGP announcements observed in Route Views, from [23]. The results include mismatches between ROAs and BGP announcements and show that a significant number (about 9%) of invalid BGP announcements, emitted by over 700 organizations, are misconfigured. A few of these may be actual prefix or subprefix hijacking attacks. Yet, the majority is surely a result of configuration errors. ROV performing BGP router would drop all of these announcements, thereby refusing to route a significant amount of legitimate traffic, causing loss of revenue and complaints from customers. To illustrate the problems we refer to two real life examples of incorrectly issued ROAs, for more details see [23]. The first example in Fig. 81.5 illustrates Orange (previously France Telecom), a large French ISP, which issued a ROA for the 194.2.0.0/15 prefix with origin AS 3215. Orange has several customers.
Fig. 81.4Status of ROAs
Fig. 81.5Misconfigured ROA by Orange. (Cohen et al. [23])
For example, Danone announces the (sub)prefix 194.2.35.0/24 with origin AS 1272. Most of these customers, including Danone and two more in the figure, did not issue a ROA. Hence, the BGP announcements made by these customers are invalid according to RPKI and any ROV performing AS will discard all paths to these companies. In the second example, Fig. 81.6, Swisscom, a large Swiss ISP, issued a ROA for the prefix 81.62.0.0/15, with origin AS 3303. Swisscom also advertises several BGP announcements, for this prefix and for subprefixes, e. g. 81.63.0.0/16. However, the ROA is generated incorrectly, allowing an attacker to launch prefix hijacks. For example, to hijack all traffic to the prefix 81.63.0.0/16, the attacker can send BGP announcements with AS‐path 666‐3303‐81.63.0.0/17 and with AS‐path 666‐3303‐81.63.128.0/17 (where 666 is a malicious AS).
Fig. 81.6Misconfigured ROA by Swisscom. (Cohen et al. [23])
81.2.3 Small Office/Home Office (SOHO) Routers
A Small Office/Home Office (SOHO) router is a network device that connects computer networks by relaying packets between internal and external interfaces. SOHO routers often also perform a Network Address Translation (NAT) [RFC2663] functionality, run services such as DHCP [RFC2131], DNS [RFC1035], and are responsible for the connection and configuration of end devices to the Internet. All communication between the end hosts on the local networks and the Internet services (e. g. web, email, video conferencing) traverses the SOHO router. SOHO routers typically provide web interfaces for convenient and easy configurations of the network, devices and the router itself. Connection to the administrative interface provides information about the network, the connected devices, the traffic and more.
SOHO Routers Security
The security of SOHO routers is critical for the privacy and stability of the clients and services in the Internet – yet the attacks against SOHO routers are widespread. During the last two decades multiple vulnerabilities were reported [5, 9] in popular SOHO routers, e. g., BT home routers, Linksys, D‐link. The vulnerabilities include buffer overflows, traditional web attacks (e. g., XSS and CSRF), Denial of Service (DoS) attacks and authentication bypass attacks. For instance, a recent vulnerability in ARRIS SURFboard router utilizing CSRF enabled attackers to disrupt Internet connections of SOHO networks [7]. The attacks against SOHO routers along with the multiple vulnerabilities published in CVEs raised awareness to the importance of protecting network devices, and patches were issued.
There is a range of protective strategies both enterprises and individuals can employ to improve SOHO router security. We report on results of our Internet scale evaluation of SOHO routers security, focusing on a specific set of vulnerabilities called authentication bypass; details follow. Such vulnerabilities allow attackers to perform privileged operations in firmwar
e without being granted the valid credentials of an authorized user. Authentication bypass vulnerabilities can be caused in a number of ways, and result in attackers successfully connecting to the administrative configuration interface. The vulnerabilities that can be exploited to connect to administrative interface of a SOHO router include: insecure connection whereby the credentials are sent in clear text and hence can be inspected by a Man‐in‐the‐Middle (MitM) attacker, a vulnerability in the authentication procedure allowing the attacker to obtain the credentials by exploiting a vulnerability in software or firmware, e. g., buffer overflow, a vulnerability in web interface, e. g., SQL injection or CSRF, implementation mistakes whereby the credentials are hardcoded into the webpage, or sent in response to the connecting client, or simply using the default credentials configured by the router vendors or the firmware of an Internet Service Provider (ISP), without changing them.
We list the fraction of open routers per country in Fig. 81.7. More than 6.2 Mio. of SOHO routers use port 80 for communication to the configuration interface.
Fig. 81.7Fraction of open devices per country
Using the REALM that the routers return, recover the router vendor, and check the default credentials used by that vendor, selected open routers are listed in Fig. 81.8.
Fig. 81.8Selected REALMs returned by open SOHO routers
Finally, our study shows that a large fraction of SOHO routers are using default credentials. These credentials can be looked up on routers’ vendors websites. We list the most common passwords in Fig. 81.9.
Fig. 81.9Top popular default credentials
Configuring secure credentials is critical for security, and especially security of SOHO networks. Unfortunately, home users often lack the required expertise or understanding to change default passwords. On the other hand, in many countries we tested the Internet Service Providers (ISPs) prefer not to take responsibility for their clients, and hence refuse to distribute patches to mitigate the problems. Indeed, aligned with our results in Fig. 81.7, in countries with large fraction of open devices the ISPs do not add “security” to the services that they provide, and do not support procedures for distribution of patches to clients to change the default network credentials.
The only way to resolve this unfortunate situation is to create policies and legislation that would enforce the ISPs to add “security” to the services that they provide to home networks.
81.3 Vulnerable Internet Infrastructure Foils Application Defences
In this section we provide a few selected security services and explain how they can be foiled when run over insecure Internet Infrastructure.
81.3.1 Password Recovery
Password recovery is a widely used mechanism to enable users to recover their credentials if they are lost or forgotten. Password recovery is supported by banks, financial services, online shops and more. For example, see Fig. 81.10 for a password recovery print screen of paypal.
Fig. 81.10Password recovery on the Paypal website
The user enters his email address, and the password or a link allowing to reset the password is sent to the provided email address.
An attacker that can poison the DNS server on paypal’s network, say injecting a mapping saying that Alice is at IP address 6.6.6.6 (which in fact is the attacker’s controlled machine) will cause the email server on paypal’s network to send Alice’s credentials for paypal to an attacker. To do this the attacker will enter the email address of Alice into the password recovery box: [email protected]. As a result, the attacker can intercept all the communication between paypal and Alice.
81.3.2 Web Certificates
Web certificates are needed to enable clients to verify the identity of servers to which they connect. Web certificates contain the keys which can be used to establish a secure connection with SSL/TLS to the target server, as well as the identity of the server. For instance, when connecting to a bank www.commerzbank.de, the client needs to verify that the machine the connection is established to is indeed that of a bank, and not of an attacker. When the web server of Commerzbank provides a certificate binding its identity to secret keys, the client can use it to establish a secure connection to the server. Web sites that do not use SSL/TLS expose clients to attacks, since the communication to those sites can be inspected and modified, e. g., causing the client to download a malware or to expose its private information, such as credit card number, to an attacker.
The generation of a certificate requires checking that the entity requesting a certificate is the owner of the domain. For instance, that the entity requesting a certificate for Commerzbank.de is indeed the owner of domain Commerzbank.de. Otherwise the attacker would be able to issue certificate for Commerzbank.de and impersonate the website of Commerzbank, stealing clients’ credentials. The verification of the identity during certificate generation procedure is (typically) done by sending an email to the server in a domain for which the certificate was requested. If the attacker controls routing (via prefix hijacking) it can receive all the communication including the email verifying the identity for the certificate. Similarly, if the attacker poisons the DNS entry, the email will be sent to an attacker controlled host.
81.3.3 Anti‐Spam Defences
Spam is a huge problem in the Internet, causing detrimental financial losses and exposing to attacks, such as malware distribution and credentials theft by luring users to malicious websites.
Anti‐spam defences allow email servers to verify that an email arrives from authentic sources, and not from spammers, by checking that the sender of the email is real and not spoofed. For instance, if the “from” header of an email message contains [email protected], the email was sent by someone from Commerzbank and not by a spammer, tricking the client into accepting the email as authentic.
Spam can be used to steal credentials, money, and even for distribution of malware.
Most popular defences for sender authentication are DNS based. The idea is that a real sender creates a record and places in its DNS server, that says which email servers is allowed to send email on behalf of its domain. For instance, Commerzbank can place a record saying that only an email server mail.commerzbank.de at IP address 1.2.3.4 is allowed to send an email on behalf of Commerzbank. All the email servers supporting anti‐spam will request this record from Commerzbank before accepting the email as authentic. An attacker sending an email from machine at IP 6.6.6.6 impersonating Commerzbank will not be able to trick the email servers to accept its emails, since its email is sent from an IP address that was not authorized by Commerzbank.de.
However, attacks against the DNS infrastructure or prefix hijacking attacks can enable attackers to circumvent the defences and to distribute SPAM. Indeed, attackers often perform DNS cache poisoning as well as BGP prefix hijacking to distribute spam bypassing anti‐spam defences.
81.4 Conclusions
In this work we reviewed selected fundamental building blocks in the Internet which are critical for security of clients and services. Our experimental evaluation shows that, although frequent attacks and although defences exist, these building blocks are still unprotected. We show that there are challenges and obstacles towards adoption of the defences that need to be addressed both with respect to misconfigurations and vulnerable deployments as well as with respect to the lack of motivation to adopt security. Deploying security at Internet foundations is critical, in particular, we show that when the fundamental building blocks of the Internet are vulnerable, security of clients and services can be circumvented. This also applies to security mechanisms, which also depend on secure Internet infrastructure.
References
1.
J. Stewart, DNS cache poisoning, the next generation, 2003.
2.
D. K
aminsky, “It’s the End of the Cache As We Know It,” Black Hat conference, 08 2008.
3.
A. Herzberg und H. Shulman, “Security of patched DNS,” Computer Security – ESORICS 2012 – 17th European Symposium on Research in Computer Security, Pisa, Italy, 10–12 09 2012.
4.
A. Herzberg und H. Shulman, “Vulnerable delegation of DNS resolution,” ESORICS 2013 – 18th European Symposium on Research in Computer Security, Egham, UK, 9–13 09 2013.
5.
A. Herzberg und H. Shulman, “Fragmentation Considered Poisonous: or onedomain-to-rule-them-all.org,” IEEE CNS 2013. The Conference on Communications and Network Security, Washington, D.C.,US, 2013.
6.
D. Anderson, Splinternet behind the great firewall of china, 11 Hrsg., Bd. 10, 2012.
7.
M. Hu, Taxonomy of the snowden disclosures, Bd. 72, Wash & Lee L. Rev., 2015, pp. 1679–1989.
8.
P. Levis, “The collateral damage of internet censorship by DNS injection,” ACM SIGCOMM Computer Communication Review, Nr. 3, 2012.
9.
K. Schomp, T. Callahan, M. Rabinovich und M. Allman, “Assessing DNS vulnerability to record injection,” in Passive and Active Measurement, Springer, 2014, pp. 214–223.Crossref
Digital Marketplaces Unleashed Page 124
