Cellular backhaul and core networks have traditionally been considered as Walled Garden, with their security ensured by physical isolation. Therefore, prior security studies primarily focused on radio access networks with limited treatment of backhaul and core network interfaces. In this paper, we performed a security evaluation of real-world GPRS Tunnelling Protocol (GTP) deployments. GTP is the fundamental protocol for user traffic management between base stations and core networks (inside the Walled Garden) from 3G to 5G, thus often assumed inaccessible and non-exploitable from the Internet. However, our study reveals for the first time the troubling state of GTP access control in real-world deployments. Aided by a semi-automated tool, our measurements discovered around 749,000 valid GTP hosts accessible via the public Internet, spanning across 1,176 service providers in 162 countries. Our results demonstrate potential exposure of mobile core network infrastructures to external threats. We then evaluated the attack surface of exposed GTP infrastructures, and found out that as many as 38 types of GTP messages can be misused to launch various attacks such as denial-of-service and session hijacking. Our experiments using open source 4G and 5G projects in isolated lab environments further confirm the feasibility of those GTP-based attacks, including remote hijacking of user traffic sent through cellular core networks. In addition to threats against cellular networks and their subscribers, exposed GTP devices could also be weaponized to launch large-scale reflective denial-of-services (RDoS) attacks. We hope our findings will increase awareness of GTP vulnerabilities among operators and the security community, highlighting the urgent need to further strengthen security in cellular core networks.

As 5G and future generations of mobile networks aim to provide faster and more secure wireless connections, 5G broadcast messages remain unprotected. Hence, a user device cannot verify the identity of a base station before establishing the connection and starting the registration procedure. This long-existing loophole enables various types of fake base station (FBS) attacks. To protect end-users from these attacks, a practical solution is to introduce a digital signature for these broadcast messages. However, an FBS may also have the ability to relay a digitally signed broadcast message from a benign base station to bypass the protection. Considering that a relayed message needs extra time to reach a user device, a time-bounded defense mechanism can be used on top of the digital signature to offer replay protection. Although previous work proposed such a solution, none have implemented it or evaluated it against relay attacks. Hence, to evaluate the performance of our proposed digital signature scheme and the time-bounded defense, we implemented the solution against relay attacks using an open-source 5G system. Our results show that the overhead introduced is acceptable and that the time-bounded defense is effective against relay attacks.

5G messaging services, based on Global System for Mobile Communications Association (GSMA) Rich Communication Service (RCS) and 3rd Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS), have been deployed globally by more than 90 mobile operators serving over 421 million monthly active users via 1.2 billion devices. Despite the widespread use, security research of 5G messaging remains sparse. In this paper, we present a comprehensive security analysis and measurement of 5G messaging services, assisted by a semi-automated testing tool we developed. We considered both carrier-side deployment and phone-side software implementations by testing against three large operators, each with hundreds of millions of subscribers, and six popular 5G messaging-enabled devices. We uncovered 4 categories of vulnerabilities, allowing for a wide range of attacks, including Man-In-The-Middle (MITM) attacks, zero-click remote information leakage, phone storage exhaustion and mobile data consumption, and Denial-of-Services (DoS) attacks. Our study underscores the need for further security enhancements in security specifications, implementation, and deployment of 5G messaging services.

In this paper, we present a new DNS amplification attack, named TsuKing. Instead of exploiting individual DNS resolvers independently to achieve an amplification effect, TsuKing deftly coordinates numerous vulnerable DNS resolvers and crafted queries together to form potent DoS amplifiers. We demconstrate that with TsuKing, an initial small amplification factor can inrease exponentially through the internal layers of coordinated amplifiers, resulting in an extremely powerful amplification attack. TsuKing has three variants, including DNSRetry, DNSChain, and DNSLoop, all of which exploit a suite of inconsistent DNS implementations to achieve enormous amplification effect. With comprehensive measurements, we found that about 14.5% of 1.3M open DNS resolvers are potentially vulnerable to TsuKing. Real-world controlled evaluations indicated that attackers can achieve a packet amplification factor of at least 3,700X (DNSChain). We have reported vulnerabilities to affected vendors and provided them with mitigation recommendations. We have received positive responses from 6 vendors, including Unbound, MikroTik, and AliDNS, and 3 CVEs were assigned. Some of them are implementing our recommendations.

The fifth-generation(5G) cellular network is entering an era of rapid development. Not only is 5G supposed to be fast, it also offers enhanced security based on 5G security specifications developed by the 3rd Generation Partnership Project (3GPP). However, little is known about 5G security in real world deployment. This paper analyzes 5G security features and measures their implementation in commercial 5G networks. By collecting and analyzing signaling messages between a cell phone and several commercial 5G networks, we measured multiple aspects of 5G security in real world deployment including, crypto algorithms used in the control plane, user plane (UP) security activation, subscriber identifier protection, and initial None-Access Stratum(NAS) message protection. We evaluated the compliance of commercial 5G networks with 5G security specifications. The results show that major discrepancy exists between 5G security standards and real world deployment, especially in the areas of UP protection and subscriber identifier protection. Therefore, well-known security risks, such as user data leakage, location exposure and Denial-of-Service(DoS) attacks, still apply to 5G commercial networks.

In 5G networks, base stations, namely gNBs (5G NodeB, as per 3GPP nomenclature) periodically broadcast the system information messages including network identifiers to facilitate User Equipment (UE) to connect to the network. As in prior generations, the system information messages in 5G are transmitted in clear text without any security protection. Therefore, an adversary could spoof a legitimate gNB to become a man-on-the-side (MOTS) or man-in-the-middle (MITM) attacker. This vulnerability is being studied by 3GPP and a number of solutions have been proposed in the Technical Report (TR 33.809), including a promising solution namely Digital Signing Network Function (DSnF). In this paper, we provided an evaluation of DSnF, including the practicality of its assumption, feasibility of its certificate trans-mission within the system information message, and quantitative analysis of its performance. Our evaluation results show that DSnF is practical in general. Initial results from this paper have been provided to 3GPP and incorporated into TR 33.809.

Content Delivery Networks (CDNs) are critical Internet infrastructure. Besides high availability and high performance, CDNs also provide security services such as anti-DoS and Web Application Firewalls to CDN-powered websites. However, the massive resources of CDNs may also be leveraged by attackers exploiting their architectural, implementation, or operational weaknesses. In this paper, we show that today's CDN operation is overly loose in customer-controlled forwarding policy and the lack of origin validation leads to a wide range of abuse cases such as DoS attack and stealthy port scan. We systematically study these abuse cases and demonstrate their feasibility in popular CDNs. Further, we evaluate the impact of these abuses by discovering that there are millions of CDN edge servers, and a substantial fraction of them can be abused. Lastly, we propose mitigation solutions against such abuses and discuss their feasibility.

The Host header is a security-critical component in an HTTP request, as it is used as the basis for enforcing security and caching policies. While the current specification is generally clear on how host-related protocol fields should be parsed and interpreted, we find that the implementations are problematic. We tested a variety of widely deployed HTTP implementations and discover a wide range of non-compliant and inconsistent host processing behaviours. The particular problem is that when facing a carefully crafted HTTP request with ambiguous host fields (e.g., with multiple Host headers), two different HTTP implementations often accept and understand it differently when operating on the same request in sequence. We show a number of techniques to induce inconsistent interpretations of host between HTTP implementations and how the inconsistency leads to severe attacks such as HTTP cache poisoning and security policy bypass. The prevalence of the problem highlights the potential negative impact of gaps between the specifications and implementations of Internet protocols.

Content Delivery Network (CDN) and Hypertext Transfer Protocol Secure (HTTPS) are two popular but independent web technologies, each of which has been well studied individually and independently. This paper provides a systematic study on how these two work together. We examined 20 popular CDN providers and 10,721 of their customer web sites using HTTPS. Our study reveals various problems with the current HTTPS practice adopted by CDN providers, such as widespread use of invalid certificates, private key sharing, neglected revocation of stale certificates, and insecure back-end communication. While some of those problems are operational issues only, others are rooted in the fundamental semantic conflict between the end-to-end nature of HTTPS and the man-in-the-middle nature of CDN involving multiple parties in a delegated service. To address the delegation problem when HTTPS meets CDN, we proposed and implemented a lightweight solution based on DANE (DNS-based Authentication of Named Entities), an emerging IETF protocol complementing the current Web PKI model. Our implementation demonstrates that it is feasible for HTTPS to work with CDN securely and efficiently. This paper intends to provide a context for future discussion within security and CDN community on more preferable solutions.

It is well known that the Border Gateway Protocol (BGP), the IETF standard interdomain routing protocol, is vulnerable to a variety of attacks, and that a single misconfigured or malicious BGP speaker could result in large-scale service disruption. In this paper, we present Pretty Secure BGP (psBGP) ---a proposal for securing BGP, including an architectural overview, design details for significant aspects, and preliminary security and operational analysis. psBGP differs from other security proposals (e.g., S-BGP and soBGP) in that it makes use of a single-level PKI for AS number authentication, a decentralized trust model for verifying the propriety of IP prefix origin, and a rating-based stepwise approach for AS_PATH (integrity) verification. psBGP trades off the strong security guarantees of S-BGP for presumed-simpler operation, e.g., using a PKI with a simple structure, with a small number of certificate types, and of manageable size. psBGP is designed to successfully defend against various (nonmalicious and malicious) threats from uncoordinated BGP speakers, and to be incrementally deployed with incremental benefits.

Google went down for 15 to 60 minutes around 22:10, May 07, 2005 UTC. This was explained by Google as having been caused by internal DNS misconfigurations. Another vulnerable protocol which could have caused such service outage is BGP. To pursue the latter possibility further, we explore how BGP was functioning during that period of time using the RouteViews BGP data set. Interestingly, our investigation reveals that one autonomous system (i.e., AS 174 operated by Cogent), which is apparently independent from Google, mysteriously originated routes for one of the IP prefixes assigned to Google (134.233.161.0/24) immediately prior to the service outage. As a result, 49.1% of ASes re-advertising routes for 64.233.161.0/24 switched to the incorrect path. Those poisoned ASes directly serve 1500 IP prefixes, and span a broad range of geographic locations. Since this erroneous prefix origination apparently has not occurred previously, or after this specific instance, we consider that it might have been the result of malicious activity (e.g., compromise of one or more BGP speakers) and contributed at least partially to Google's service outage.