September 26, 2022

Cross-Layer Security: A Holistic View of Internet Security 

By Henry Birge-Lee, Liang Wang, Grace Cimaszewski, Jennifer Rexford and Prateek Mittal

On February 3, 2022, attackers launched a highly effective attack against the Korean cryptocurrency exchange KLAYswap. We discussed the details of this attack in our earlier blog post “Attackers exploit fundamental flaw in the web’s security to steal $2 million in cryptocurrency.” However, in that post we only scratched the surface of potential countermeasures that could prevent such attacks. In this new post, we will discuss how we can defend the web ecosystem against attacks like these. This attack was composed of multiple exploits at different layers of the network stack. We term attacks like this,  “cross-layer attacks,” and offer our perspective on why they are so effective. Furthermore, we propose a practical defense strategy against them that we call “cross-layer security.” 

As we discuss below, cross-layer security involves security technologies at different layers of the network stack working in harmony to defend vulnerabilities that are difficult to catch at a single layer alone.

At a high level, the adversary’s attack affected many layers of the networking stack:

  • The network layer is responsible for providing reachability between hosts on the Internet. The first part of the adversary’s attack involved targeting the network layer with a Border Gateway Protocol (BGP) attack that manipulated routes to hijack traffic intended for the victim.
  • The session layer is responsible for secure end-to-end communication over the network. To attack the session layer, the adversary leveraged its attack on the network layer to obtain a digital certificate for the victim’s domain from a trusted Certificate Authority (CA). With this digital certificate the adversary established encrypted and secure TLS sessions with KLAYswap users.
  • The application layer is responsible for interpreting and processing data that is sent over the network. The adversary used the hijacked TLS sessions with KLAYswap customers to serve malicious Javascript code that compromised the KLAYswap web application and caused users to unknowingly transfer their funds to the adversary.

The difficulty of fully protecting against cross-layer vulnerabilities like these is that they exploit the interactions between the different layers involved: a vulnerability in the routing system can be used to exploit a weak link in the PKI, and even the web-development ecosystem is involved in this attack because of the way javascript is loaded. The cross-layer nature of these vulnerabilities often leads developers working in each layer to dismiss the vulnerability as a problem with other layers. 

There have been several attempts to secure the web against these kinds of attacks at the HTTP layer. Interestingly, these technologies often ended up dead-in-the-water (as was the case with HTTP pinning and Extended Validation certificates). This is because the HTTP layer alone does not have the routing information needed to properly detect these attacks and can only rely on information that is available to end-user applications. This potentially causes HTTP-only defenses to block connections when benign events take place, like when a domain chooses to move to a new hosting provider or changes its certificate configuration because these look very similar to routing attacks at the HTTP layer. 

Due to the cross-layer nature of these vulnerabilities, we need a different mindset to fix the problem: people at all layers need to fully deploy any security solutions that are realistic at that layer. As we will explain below, there is no silver bullet that can be quickly deployed at any layer; instead, our best hope is more modest (but easier to deploy) security improvements for all the layers involved. Working under a “the other layer will fix the problem” attitude simply perpetuates these vulnerabilities.

Below are some short-term and ideal long-term expectations for each layer of the stack involved in these attacks. While in theory, any layer implementing one of these “long-term” security improvements could drastically reduce the attack surface, these technologies have still not seen the type of deployment needed for us to rely on them in the short term. On the other hand, all the technologies in the short-term list have seen some degree of production-level/real-world deployment and are something members of these communities can start using today without much difficulty.

Short-Term ChangesLong-Term Goals
Web apps (application layer)Reduce the use of code loaded from external domainsSign and authenticate all code being executed
The PKI/TLS (session layer)Universally deploy multiple vantage point validationAdopt a technology to verify identity based on cryptographically-protected DNSSEC which provides security in the presence of powerful network attacks
Routing (network layer)Sign and verify routes with RPKI and follow the security practices outlined by MANRSDeploy BGPSec for near-complete elimination of routing attacks

To elaborate:

At the application layer: Web apps are downloaded over the Internet and are completely decentralized. For the time being, there is no mechanism in place to universally vouch for the authenticity of code or content that is contained in a web app. If an adversary can obtain a TLS certificate for google.com and intercept your connection to Google, your browser (right now) will have no way of knowing that it is being served content that did not actually come from Google’s servers. However, developers can remember that any third-party-dependency (particularly those loaded from different domains) can be a third-party-vulnerability and limit the use of third-party code on their website (or host third-party code locally to reduce the attack surface). Furthermore, both locally hosted and third-party hosted content can be secured with subresource integrity where a cryptographic hash (included on the webpage) vouches for the integrity of dependencies. This lets developers provide cryptographic signatures for the dependencies on their webpage. Doing this vastly reduces the attack surface forcing the attacks to target only a single connection with the victim’s web server as opposed to the many different connections involved in retrieving different dependencies.

At the session layer: CAs need to establish the identity of customers requesting certificates and, while there are proposals to use cryptographic DNSSEC to verify identity (like DANE), the status quo is to verify identity via network communications with the domains listed in certificate requests. Thus, global routing attacks are likely to be very effective against CAs unless we make more substantial changes to the way certificates are issued. But this does not mean all hope is lost. Many network attacks are not global but are actually localized to a specific part of the Internet. CAs are capable of mitigating these attacks by verifying domains from several vantage points spread throughout the Internet. This allows some of the CAs vantage points to be unaffected by the attack and communicate with the legitimate domain owner. Our group at Princeton designed multiple vantage point validation and worked with the world’s largest web PKI CA Let’s Encrypt to develop the first ever production deployment of it. CAs can and should use multiple vantage points to verify domains making them immune to localized network attacks and ensuring that they see a global perspective on routing.

At the network layer: In routing, protecting against all BGP attacks is difficult. It requires expensive public-key operations on every BGP update using a protocol called BGPsec that current routers do not support. However, recently there has been significantly increased adoption of a technology called the Resource Public Key Infrastructure (RPKI) that prevents global attacks by establishing a cryptographic database of which networks on the Internet control which IP address blocks. Importantly, when properly configured, RPKI also specifies what size IP prefix should be announced which prevents global and highly-effective sub-prefix attacks. In a sub-prefix attack the adversary announces a longer, more-specific IP prefix than the victim and benefits from longest-prefix-match routing to have its announcement preferred by the vast majority of the Internet. RPKI is fully compatible with current router hardware. The only downside is that RPKI can still be evaded with certain local BGP attacks where, instead of claiming to own the victim’s IP address which is checked against the database, an adversary simply claims to be an Internet provider of the victim. The full map of which networks are connected to which other networks is not currently secured by the RPKI. This leaves a window for some types of BGP attacks which we have seen in the wild. However the impact of these attacks is significantly reduced and often affects only a part of the Internet. In addition, the MANRS project provides recommendations for best operational practices including RPKI that help prevent and mitigate BGP hijacks.

Using Cross-Layer Security to Defend Cross-Layer Attacks

Looking across these layers we see a common trend: in every layer there are proposed security technologies that could potentially stop attacks like the KLAYswap attack. However, these technologies all face deployment challenges. In addition, there are more modest technologies that are seeing extensive real-world deployment today. But each of these deployed technologies alone can be evaded by an adaptive adversary. For example, RPKI can be evaded by local attacks, multiple-vantage-point validation can be evaded by global attacks, etc. However, if we instead look at the benefit offered by all of these technologies together deployed at different layers, things look more promising. Below is a table summarizing this:

Security Technology/LayerGood at detecting routing attacks which affect the entire InternetGood at detecting routing attacks which affect part of the InternetLimits the number of potential targets for routing attacks
RPKI at the Network LayerYesNoNo
Multiple-Vantage-Point Validation at the Session LayerNoYesNo
Subresource Integrity and Locally Hosted Content at the Application LayerNoNoYes

This synergy of security technologies deployed at different layers is what we call cross-layer-security. RPKI alone can be evaded by clever adversaries (using attack techniques we are seeing more and more in the wild). However, the attacks that evade RPKI tend to be local (i.e., not affecting the entire Internet). This synergizes with multiple-vantage-point validation that is best at catching local attacks. Furthermore, because even these two technologies working together do not fully eliminate the attack surface, improvements at the web layer that reduce the reliance on code loaded from external domains help to even further reduce the attack surface. At the end of the day, the entire web ecosystem can benefit tremendously from each layer deploying security technologies that leverage the information and tools available exclusively to that layer. Furthermore, when working in unison, these technologies together can do something that none of them could do alone: stop cross-layer attacks.

Cross-layer attacks are surprisingly effective because no one layer has enough information about the attack to completely prevent it. Hopefully, each layer does have the ability to protect against a different portion of the attack surface. If developers across these different communitie know what type of security is realistic and expected of their layer in the stack, we will see some meaningful improvements.

Even though the ideal endgame is to deploy a security technology that is capable of fully defending against cross-layer attacks, we have not yet seen wide scale adoption of any such technology. In the meantime if we continue to solely focus security against cross-layer attacks in a single layer, these attacks will take significantly longer to protect against. Changing our mindset and seeing the strengths and weaknesses of each layer lets us protect against these attacks much more quickly by increasing the use of  synergistic technologies at different layers that have already seen real-world deployment.

Attackers exploit fundamental flaw in the web’s security to steal $2 million in cryptocurrency

By Henry Birge-Lee, Liang Wang, Grace Cimaszewski, Jennifer Rexford and Prateek Mittal

On Thursday, Feb. 3, 2022, attackers stole approximately $2 million worth of cryptocurrency from users of the Korean crypto exchange KLAYswap. This theft, which was detailed in a Korean-language blog post by the security firm S2W, exploited systemic vulnerabilities in the Internet’s routing ecosystem and in the Public Key Infrastructure (PKI), leaving the Internet’s most sensitive financial, medical and other websites vulnerable to attack.

Remarkably, years earlier, researchers at Princeton University predicted such attacks in the wild and successfully developed initial countermeasures against it, which we will describe here. But unless these flaws are addressed holistically, a vast number of applications can be compromised by the exact same type of attack.

Unlike many attacks that are caused by zero-day vulnerabilities (which are often patched rapidly) or a blatant disregard for security precautions, the KLAYswap attack was not related to any software or security configuration used by KLAYswap. Rather, it was a well-crafted example of a cross-layer attack exploiting weaknesses across the routing system, public key infrastructure, and web development practices. We’ll discuss defenses more in a subsequent blog post, but protecting against this attack demands security improvements across all layers of the web ecosystem.

The vulnerabilities exploited in this attack have not been mitigated. They are just as viable today as they were when this attack was launched. That is because the hack exploited structural vulnerabilities in the trust the PKI places in the Internet’s routing infrastructure

Postmortem

The February 3 attack happened precisely at 1:04:18 a.m. GMT (10:04 a.m. Korean Time), when KLAYswap was compromised using a fundamental vulnerability in the trust placed in various layers of the web’s architecture. 

KLAYswap is an online cryptocurrency exchange that offers users a web interface for trading cryptocurrency. As part of their platform, KLAYswap relied on a javascript library written by Korean tech company Kakao Corp. When users were on the cryptocurrency exchange, their browsers would load Kakao’s javascript library directly from Kakao’s servers at the following URL (see diagram):

https://developers[.]kakao.com/sdk/js/kakao.min.js

It was actually this URL that was the attacker’s target, not any of the resources operated by KLAYswap itself. Attackers exploited a technique known as a Border Gateway Protocol (BGP) hijack to launch this attack. A BGP hijack happens when a malicious network essentially lies to neighboring networks about what Internet addresses (or IP addresses) it can reach. If the neighboring networks believe this lie, they will route the victim’s traffic to the malicious network for delivery instead of the networks connecting to the legitimate owner of those IP addresses, allowing it to be hijacked. 

Specifically, the domain name in the URL above: developers.kakao.com resolves to two IP addresses: 121.53.104.157 and 211.249.221.246. Packets going to these IP addresses are supposed to be routed to Kakao. During the attack, the adversary’s malicious network announced two IP prefixes (i.e., blocks of IP addresses that are used when routing traffic) that caused traffic to these addresses to be routed to the adversary

When KLAYswap customers requested kakao.min.js from the adversary, the adversary served them a malicious javascript file that caused users’ cryptocurrency transactions to transfer funds to the adversary instead of the intended destination. After running the attack for several hours, the adversary withdrew its route and cashed out by converting its coins to untraceable currencies. By the time the dust settled, the adversary had stolen approximately $2 million worth of various currencies from users of KLAYswap and walked away with approximately $1 million dollars worth of various cryptocurrencies. (Some losses were due to fees and exchange rates associated with exfiltrating the currencies from the KLAYswap ecosystem.) 

But what about cryptography?

The second and most dangerous element of the attack was its neutralization of the Internet’s encryption defenses. While there is a moderate level of complexity associated with BGP hijacks, they do happen relatively often (some of the most egregious examples involve China Telecom routing about 15 percent of Internet traffic through its network for 18 minutes and Pakistan Telecom accidently taking down Youtube in a botched attempt at local censorship). 

What is unprecedented in this attack (to our knowledge) is the complete bypassing of the cryptographic protections offered by the TLS protocol. TLS is the workhorse of encryption of the World Wide Web and is part of the reason the web is trusted with more and more secure applications like financial services and medical systems. Among other security properties, TLS is designed to protect the confidentiality and integrity of user data. TLS allows a web service and a client (like a user of KLAYswap) to securely exchange data even over a potentially untrusted network (like the adversary’s network in the event of this attack) and also ensure (in theory) they are talking to the legitimate endpoint. 

Yet, ironically, KLAYswap and Kakao were properly using TLS, and it was not a vulnerability in the TLS protocol that was exploited during the attack. Instead, the attack exploited the false trust that TLS places in the routing infrastructure. TLS relies on the Public Key Infrastructure (PKI) to confirm the identity of the web servers. The PKI is tasked with distributing digitally signed certificates that verify the server’s identity (in this case the domain name like developers.kakao.com) and the server’s cryptographic key. If a server presents a valid certificate, even if there is another network in the middle, a client can encrypt data that only the real server can read.

Using its BGP hijack, the adversary first targeted the PKI and launched a man-in-the-middle attack on the certificate distribution process.  Only after it had acquired a valid digital certificate for the target domain did it aim its attack towards real users by serving its malicious javascript file over an encrypted connection.

Certificate Authorities (or CAs, the entities that sign digital certificates in the PKI) have a similar identity problem to the one in TLS connections. CAs are approached by customers with requests to sign certificates. The CA needs to make sure the customer requesting a certificate actually controls the associated domain name. To verify identity (and thus bootstrap trust for the entire TLS ecosystem), CAs perform domain control validation requiring users to prove control of the domain listed in their certificate requests. Since the server might be getting a TLS certificate for the first time, domain control validation is often performed over no-security-attached HTTP. 

But now we are back to square one: the adversary simply needs to perform a BGP hijack to attract the domain control validation traffic from the CA, pretend to be the victim website, and serve the content the CA requested. After receiving a signed certificate for the victim’s domain, the adversary can serve real users over the supposedly “secure” TLS connection. This is indeed what happened in the KLAYswap attack and makes the attack particularly scary for other secure applications across the Internet. The attackers hijacked developers.kakao.com, approached the certificate authority ZeroSSL, requested a certificate for developers.kakao.com, and served this certificate to KLAYswap users that were downloading the javascript library over presumably “secure” TLS.

While Princeton researchers anticipated this attack and effectively deployed the first countermeasures against it, fully securing the web from it is still an ongoing effort.

Ever since our live demo of this type of attack at HotPETS’17 and our USENIX Security ‘18 paper “Bamboozling Certificate Authorities with BGP” that developed a taxonomy of BGP attacks on the PKI, we have actively been working on developing defenses against it. The defense that has had the biggest impact (that our group developed in our 2018 USENIX Security paper) is known as multiple vantage point domain control verification. 

In multiple vantage point verification, a CA performs domain control validation from many vantage points spread throughout the Internet instead of a single vantage point that can easily be affected by a BGP attack. As we measured in our 2021 USENIX Security paper, this is effective because many BGP attacks are localized to only a part of the Internet, so it becomes significantly less likely that an adversary will hijack all of a CAs diverse vantage points (compared to traditional domain control validation). We have worked with Let’s Encrypt, the world’s largest web PKI CA, to fully deploy multiple vantage point validation, and every certificate they sign is validated using this technology (over a billion since the deployment in Feb 2020). Cloudflare also has developed a deployment as well, which is available for other interested CAs.

But multiple vantage point validation at just a single CA is still not enough. The Internet is only as strong as its weakest link. Currently, Let’s Encrypt is the only certificate authority using multiple vantage point validation and an adversary can, for many domains, pick which CA to use in an attack. To prevent this, we advocate for universal adoption through the CA/Browser Forum (the governing body for CAs). 

Additionally, some BGP attacks can still fool all of a CA’s vantage points. To reduce the impact of BGP attacks, we need security improvements in the routing infrastructure as well. In the short term, deployed routing technologies like the Resource Public Key Infrastructure (RPKI) could significantly limit the spread of BGP attacks and make them much less likely to be successful. Today only about 35 percent of the global routing table is covered by RPKI, but this is rapidly growing as more networks adopt this new technology. In the long run, we need a much more secure underlying routing layer for the Internet. Examples of this are BGPsec, where routers cryptographically sign and verify BGP update messages (although current router hardware cannot perform the cryptographic operations quickly enough) and clean-slate initiatives like SCION that change the format of IP packets to offer significantly more secure packet forwarding and routing decisions.

Overall, seeing an adversary execute this attack in the real world puts immense importance on securing the PKI from routing attacks. Moving forward with RPKI and multiple vantage point domain validation is a must if we want to continue trusting the web with secure applications. In the meantime, thousands of secure applications that trust TLS to protect against network attacks are vulnerable the same way KLAYswap was.