Why is this relevant?
Because of the performance and security guarantees of QUIC, it gained a lot of traction in the industry. Already a major portion of Google’s traffic is done via QUIC. Multiple other well-known companies also started developing their own implementations, e.g., Microsoft, Facebook, CloudFlare, Mozilla, Apple and Akamai, just to name a few. Furthermore, the decision was made to use QUIC as the new transport layer protocol for the HTTP3 standard which was standardized in 2022. This makes QUIC the basis of a major portion of future web traffic, increasing its relevance and posing one of the most significant changes to the web’s underlying protocol stack since it was first conceived in 1989.
The likelihood that you or your company will be confronted with or already use QUIC, is pretty high. On a first glance, all the security features of QUIC look compelling but it is paramount that these promises are challenged.
Security Challenges with QUIC
Using QUIC comes with some pitfalls in terms of network security. The most prominent one is that QUIC is built on top of UDP. Most firewalls handle TCP and UDP traffic separately and often differently. A pretty basic example would be a network that disallows the usage of web services by blocking all TCP traffic (the currently still used transport layer protocol for the web). However, if UDP traffic is not restricted, the existence of QUIC still allows clients to reach parts of the web, e.g., all Google websites and services. This issue was already presented at BlackHat by C. Pearce and C. Vincent in 2016.
Even if network admins are aware that QUIC is being used, the usage of the connection-less UDP protocol inherits further risks. All the common transport layer firewalls (e.g., iptables) can no longer track connection states, degrading them to less effective stateless firewalls. Allowing QUIC traffic for your webservers will likely make the network vulnerable to attacks like UDP hole punching, which utilizes the stateless nature of UDP to bypass inbound traffic restrictions. If you want to read more about this issue, please refer to the tech report paper we published in 2021.
Of course, there are applications for network protection that allow to evaluate the protocol layers above UDP and TCP. However, as QUIC makes security and privacy a first-class citizen and encrypts most of the protocol information, the insight into connections is very limited. Research by L. Decker in 2020 showed that many of the existing intrusion detection systems (IDS) and intrusion prevention systems (IPS) struggle with detecting malicious actions like command and control (C2) traffic.
Methods to secure environments using QUIC will take time to mature. But besides securing environments around QUIC, it is always interesting to ask if is it possible to utilize the protocol itself to execute attacks? The QUICforge research was aimed to explore this topic further.
Weaponizing QUIC
With the QUICforge paper, we looked into client-side request forgery attacks. This means that the attacker is always the client of the QUIC connection. The QUIC server which the client aims to exploit is called the victim. The attacker tries to trick the victim into sending one or multiple datagrams to another target.
It is almost impossible to entirely avoid the forging of requests in network protocols. At some point all network protocols send at least one packet on a yet unvalidated path. For an endpoint, it is impossible to tell if a source address is legit or spoofed. In the aspect of security, the primary question is what an attacker could do with the forged requests. From an attacker’s perspective, there are two primary goals of request forgery. The first goal is to bypass network restrictions as the server can reach other (internal) hosts which are not directly reachable from the attacker. The second goal is to leverage resources of the victim (e.g. bandwidth).
We found three request forgery techniques in QUIC where packets can be sent to an arbitrary target by spoofing the source IP address and/or port. With one of the techniques, we showed the possibility of protocol impersonation and with the other two, we uncovered amplification vectors that were verified in real-world implementations of QUIC.
Protocol Impersonation
With one of the techniques, we showed that it is possible to craft payloads that are interpreted by the target as another UDP-based protocol than QUIC. As a proof of concept, we demonstrated how to send a valid DNS request for an arbitrary host name. This could potentially be used to poison internal DNS caches as the capability of forging DNS requests removes a lot of uncertainty with timing of these attacks.
While there are some limitations for the possible payload, it should be assumed that various other UDP-based protocols can be impersonated as well. As the attack is based solely on the protocol itself and not based on a bug, every QUIC server is vulnerable to it and there is no built-in fix for the issue. Until addressed in a future QUIC version, it should be assumed that this attack is valid. Administrators must consider additional network security controls to limit the exploitability.
Traffic Amplification
Likely, the more known attack through request forgery is traffic amplification. This vulnerability is exploitable, if the victim sends significantly more bytes to the target than the attacker needs to send to the victim to forge the request. This can be utilized for (D)DoS attacks, as an attacker can profit from the bandwidth of the server.
Theoretically, the QUIC specification considers these types of attacks and limits the amount of bytes sent on any unvalidated path to three times the amount of received bytes. However, we identified pitfalls and edge cases for implementing the various features of QUIC where this limit might be surpassed. To uncover if these issues actually occur in the real world, we built an evaluation setup with 13 open-source implementations of QUIC servers (please refer to the Section 2.3 for more detailed information about the test setup). The evaluation showed that almost all implementations varied in the assessed parameters showing a general discrepancy between specification and implementations. Five of 13 implementations missed the identified pitfalls and exerted high amplification factors. We contacted the vendors of all affected servers in a responsible disclosure and the issues were fixed or the features causing the issues can be turned off.
Yet, our experiments highlight the importance of challenging the security claims by the QUIC specification and test the implementations against these claims.
While being promising on paper, the change to the novel QUIC protocol will also cause novel security challenges which network administrators and blue teams have to be aware of.
