Fixing DNS Interception
By Jonathan Landis
HTTP/3 is moving to a new protocol using UDP. To support the move, DNS is using a new record type, confusingly called HTTPS like the protocol used for web traffic, to instruct clients where and how to connect. Cloudflare published an accessible introduction to these topics in 2020. Support for the new protocols has grown since then.
Security testing tools are not ready for these changes. Caliber noticed the new DNS record type in the wild while doing mobile app testing on an iOS app. Mobile app testing requires traffic interception and one method uses redirection based on spoofed DNS records. This method has the advantage that we can selectively forward only certain traffic to our proxy to avoid interfering with platform features. The Python script dnschef had been doing the job well up until now because we only needed to determine which domains the app uses and then tamper with A and AAAA records.
But the new HTTPS record in DNS includes information both about the HTTP protocol version supported by the server and also IPv4 and IPv6 addresses where they can be reached. The design goal of the new HTTPS record is to include everything the client needs to establish an HTTPS connection in a single DNS request. Hence DNS redirection won't work unless tools like dnschef support the HTTPS records. Caliber built the support and published PRs to get those changes out to security testers everywhere.
To help understand the new HTTPS record type, we query cloudflare.com using the Python dnslib client. The dnschef.py script uses dnslib internally. Use version 0.9.23 or later of dnslib, which has merged in our changes. For testing purposes, you can also use the Bind9 "dig" utility that also supports HTTPS records in DNS. We tested dig version 9.18.19 and the output is very similar to the below.
In the response, the part highlighted in orange contains information in key=value format. The "alpn" field indicates that the server supports HTTP/3 and HTTP/2. The "ipv4hint" and "ip6hint" fields are our primary interest, as they function similarly to A and AAAA records.
The interception capability in dnschef uses the new section header shown below, which you put in a configuration file. Essentially we supply the entire HTTPS record. In this example we remove the "alpn" field as an attempt to downgrade the HTTP protocol version.
When dnschef starts up it indicates that our configuration is active, as shown in orange. On the next line it confirms that our tampering has succeeded after attempting a query.
On the client side, we receive our tampered record when connecting to the local DNS server. Success!
Our PR for dnslib has already been merged, but dnschef is unmaintained so you will need to use our fork of dnschef or merge our changes into your own fork. We also submitted a PR to the Kali repo. Cheers!
Why Caliber Security Partners?
Caliber Security is a thirteen-year-old security services firm, we hire only senior-level and experienced consultants. Our services include web and mobile application security testing, as well as network penetration testing, wireless security testing, social engineering, staff augmentation, and contract-to-hire services.
Please reach out to us if you have any questions or if we can be of any service to you. You can contact us through the web form or by email at info@calibersecurity.com.